Aller au contenu principal
Leçon 2 sur 14 · Le playbook du cycle de développement AI-native

Planifier : formaliser l'intention dans intent.md

Leçon 2 sur 14 Mis à jour le 5 novembre 2026 Avancé
Sur cette page
  1. Objectifs
  2. Ce qui change
  3. Pour démarrer
  4. Mise en œuvre
  5. Exemple
  6. Gouvernance
  7. Mesurer
  8. À vous de jouer
  9. Points clés à retenir

Objectifs

À l’issue de cette leçon, vous serez capable de :

  • Expliquer ce qu’est un fichier intent.md et pourquoi il remplace une partie du circuit de recueil des besoins
  • Mettre en place un lieu versionné pour les intentions de l’organisation

Ce qui change

Dans un cycle traditionnel, une idée passe par le backlog, les user stories, les points d’estimation et les réunions d’affinage avant que quiconque puisse agir. La responsabilité change de main à chaque relais : ce qui arrive aux développeurs est à plusieurs étapes de distance de ce que voulait la personne à l’origine.

Dans un cycle AI-native, la personne qui a l’idée la travaille avec Claude jusqu’à produire un intent.md : une proto-spécification, dans ses propres mots, qui dit ce qui est voulu, pourquoi, et sous quelles contraintes. Une intention peut aussi naître d’un ticket, ou d’une alerte de production (leçon 13).

Pour démarrer

  • Prérequis : aucun.
  • Infrastructure : un accès à Claude pour les personnes non techniques (claude.ai ou Cowork) ; un modèle de fichier intent.md partagé ; un lieu versionné pour les intentions, suivi par le product owner. Pour un seul produit, le plus simple est un dossier intent/ dans le dépôt du produit, ce qui garde la chaîne de documents à côté du code qui en découle ; un dépôt dédié ne se justifie que si les intentions couvrent de nombreux dépôts.

La mise en place est une tâche ponctuelle de l’équipe plateforme. Ensuite, les contributeurs qui ne connaissent pas Git n’ont pas à l’utiliser : un connecteur vers le gestionnaire de versions (GitHub, par exemple) permet à Claude d’enregistrer le fichier pour eux depuis claude.ai ou Cowork.

Mise en œuvre

  1. La personne à l’origine de l’idée décrit le problème à Claude, avec ses mots : ce qu’elle ne peut pas faire aujourd’hui, qui est concerné, ce que serait « mieux », ce qui est hors sujet.
  2. Claude pose les questions qu’un analyste poserait — périmètre, utilisateurs, contraintes, critères de réussite — jusqu’à ce que l’idée soit concrète.
  3. Claude rédige l’intent.md selon le modèle de l’organisation, qu’une skill peut encoder : problème, résultat attendu, utilisateurs et systèmes concernés, contraintes, questions ouvertes.
  4. La personne corrige ce que Claude a mal compris.
  5. Le fichier est enregistré dans le lieu partagé, avec son auteur et son horodatage ; le product owner le prend en charge.

Exemple

# Intention : suivi des remboursements dans l'espace adhérent
Auteur : C. Martin (relation adhérents). Statut : brouillon.

## Problème
Les adhérents appellent pour savoir où en est leur remboursement.
Ces appels occupent environ un tiers du temps des conseillers.

## Résultat attendu
L'adhérent voit dans son espace l'état de chaque remboursement, la prochaine étape et une date estimée.

## Utilisateurs et systèmes concernés
Conseillers, équipe de l'espace adhérent, API de remboursement.

## Contraintes
Aucune nouvelle donnée de santé exposée dans la session. Authentification existante uniquement.

## Questions ouvertes
Les professionnels de santé partenaires doivent-ils y avoir accès ?

Gouvernance

L’historique Git du lieu des intentions enregistre l’auteur, la date et toutes les révisions. Le product owner approuve : la décision d’accepter ou de refuser l’intention, qui l’envoie vers la conception (leçon 3), est tracée par la fusion ou la clôture de la revue.

Mesurer

  • Indicateur avancé : le délai entre la première conversation et l’intent.md enregistré, lu dans l’historique Git. L’objectif est de passer d’un cycle de recueil de plusieurs semaines à quelques heures.
  • Indicateur retardé : le taux de survie, c’est-à-dire la part des intentions acceptées par le product owner plutôt que fermées ; et le nombre de modifications de l’intent.md après le premier commit de la spécification.
De l'idée à l'intent.md Quatre étapes : décrire le problème avec ses mots ; Claude questionne comme un analyste ; Claude rédige l'intent.md selon le modèle ; la personne corrige et l'enregistre, le product owner le prend en charge. PLANIFIER De l'idée à l'intent.md 1 Décrire Le problème, avec vos mots 2 Questionner Claude joue l'analyste 3 Rédiger intent.md selon le modèle 4 Enregistrer Auteur, date, revue du PO Ce qui est voulu, pourquoi, et sous quelles contraintes, dans les mots de la personne à l'origine.
D'après la leçon « Capture as intent.md » (Claude Academy, The AI-native SDLC playbook) et la documentation de Claude Code.

À vous de jouer

Votre premier intent.md. Prenez une irritation réelle de votre service, que personne n’a encore formalisée. Décrivez-la à Claude avec vos mots et laissez-le vous interroger jusqu’à ce que l’idée soit concrète, puis faites-lui rédiger l’intent.md selon un modèle à cinq rubriques : problème, résultat attendu, utilisateurs et systèmes, contraintes, questions ouvertes. Corrigez ce qu’il a mal compris, faites relire par la personne qui jouerait le rôle de product owner, et notez le temps écoulé de la première phrase au fichier enregistré.

Sources officielles : Capture as intent.md (Claude Academy) · The AI-native SDLC playbook — Stage 1: Plan

Points clés à retenir

  • intent.md dit ce qui est voulu, pourquoi et sous quelles contraintes, dans les mots de la personne à l’origine
  • Claude joue l’analyste : il pose les questions, rédige selon le modèle, la personne corrige
  • Un lieu versionné, souvent un dossier intent/ dans le dépôt, garde l’auteur, la date et les révisions
  • Mesurez le délai jusqu’à l’intention enregistrée et la part des intentions acceptées