Les ingénieurs démarrent les sessions Claude Code en mode plan, donnent à Claude le fichier spec.md approuvé de l'Étape 2 : Conception, et le laissent les interroger, en itérant sur le plan jusqu'à ce qu'ils en soient satisfaits.
Ce qui change
| Traditionnel | Natif IA |
|---|---|
| Un ingénieur lit la conception et commence à écrire du code. La manière dont le changement sera effectué, jusqu'aux fichiers et aux tests concernés, reste dans la tête de l'ingénieur ou, au mieux, dans un commentaire de ticket. Personne d'autre ne peut le relire. La première chose qu'un relecteur voit est le diff terminé, et à ce stade, les retouches sont lentes. | Le travail commence par un plan écrit que Claude produit en mode plan, où il peut lire la base de code sans rien modifier. L'ingénieur corrige le plan avant que le code ne soit écrit, et la version approuvée est validée sous le nom plan.md afin que les étapes ultérieures puissent s'y référer. |
Pour commencer
- Prérequis : L'artefact d'intention (
intent.mdouspec.md) s'il en existe un, et le fichierCLAUDE.mdest utile. - Infrastructure : Claude Code avec accès au dépôt.
Comment l'exécuter
- L'ingénieur démarre la session en mode plan avec Claude.
- L'ingénieur donne à Claude les fichiers
intent.mdetspec.mdet demande un plan d'implémentation qui nomme les fichiers modifiés, l'ordre du travail, et les tests qui le prouvent. - Interrogez le plan en demandant ce que le changement pourrait casser, quelle étape est la plus risquée, et quelles autres options Claude a choisi de ne pas retenir.
- Itérez jusqu'à ce qu'un ingénieur qui n'a jamais vu la conversation puisse implémenter le changement à partir du seul plan.
- Validez le plan approuvé sous le nom
plan.md. Le plan rejoint la piste d'audit, et le scénario de relecture de PR (Étape 5 : Déploiement) vérifie le diff final par rapport à celui-ci. - Acceptez le plan et laissez Claude l'implémenter. Avec un plan solide, l'implémentation se fait souvent en une seule passe.
- Lorsque l'implémentation s'écarte du plan, mettez à jour
plan.mddans le même commit. Envisagez d'utiliser un hook pour imposer la synchronisation entre les deux.
À quoi cela ressemble
Le plan ci-dessous concerne un changement chez un assureur : un panneau dans le portail client qui affiche le statut d'une réclamation. Le panneau appelle le backend du portail, claims-api, qui lit les données de claims-core, un système interne plus ancien.
plan.md :
# Plan: claims status self-service (from intent.md and spec.md)
## Files that change
portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py, claims-api/tests/test_status.py
## Order of work
1. Add the status endpoint behind existing auth (R1, R2, R3).
2. Panel against the endpoint, with the 60-second cache (R1, R4).
3. Wire into the portal nav.
## Risks
The claims-core API rate-limits at 50 rps; the panel must cache (spec concern 3).
## Proof
test_status.py covers the four claim states (R2) and fails on any extra field (R3); screenshot matches the approved mock.R1 à R4 sont les exigences numérotées dans spec.md, et la préoccupation 3 est un risque signalé par spec.md. Parce que le plan les cite, un relecteur peut vérifier le plan par rapport à la spécification ligne par ligne.
Considérations de gouvernance
La relecture de conception a lieu avant que le moindre code ne soit généré, à un moment où changer de direction revient encore à modifier un document. Le mode plan impose cela de lui-même, puisque Claude ne peut pas modifier de fichiers avant que l'ingénieur n'accepte le plan. Le plan et ses révisions sont journalisés avec l'identité de la personne qui les a acceptés. Les changements de routine sont approuvés par l'ingénieur, et tout ce que l'organisation classe comme présentant un risque plus élevé est transmis à un tech lead ou à un architecte.
Comment le mesurer
- Indicateur avancé : Part des changements qui sont fusionnés dès la première passe d'implémentation, et délai entre l'approbation du plan et la PR fusionnée, avec les données requises dans les métadonnées de la PR.
- Indicateur retardé : Cycles de retouches par changement, toujours à partir des métadonnées de la PR, et fréquence à laquelle le diff fusionné correspond encore au
plan.mdvalidé.
Claude Code en mode auto
Claude Code peut également s'exécuter en mode auto(s’ouvre dans un nouvel onglet), où l'ingénieur itère sur le plan et l'approuve, puis Claude applique chaque changement sans invite à chaque modification. À mesure que les garde-fous des scénarios ultérieurs mûrissent (un CLAUDE.md ajusté, des Compétences qui encodent la politique, des hooks qui bloquent les actions dangereuses, et une suite de tests que Claude peut exécuter), le mode auto devient la valeur par défaut pour le travail de routine : un spec.md précis, un rayon d'impact réduit, et du code déjà couvert par les tests.
Le changement s'opère désormais, non plus vers l'utilisateur observant l'agent effectuer les modifications et relisant les actions, mais vers la relecture des artefacts après des sessions autonomes plus longues. Le mode auto permet en outre le parallélisme entre les individus et l'équipe lorsqu'il est utilisé avec des worktrees, et il est fondamental pour exécuter le SDLC de manière autonome et boucler la boucle comme décrit à l'Étape 6 : Maintenance.
Systèmes existants et source de vérité
Les processus SDLC existants suivent probablement déjà les artefacts, simplement pas dans des fichiers Markdown. Les éléments de travail peuvent se trouver dans Jira, les exigences dans un outil intégrant une traçabilité réglementaire, les conceptions dans Figma, et les approbations de changement auprès d'un comité de changement. Ces systèmes sont difficiles à déplacer car les auditeurs et les régulateurs les acceptent déjà et que d'autres équipes en dépendent, si bien que le SDLC natif IA doit s'adapter à ce qui existe. Pour chaque artefact que le processus produit, un système doit être désigné comme source de vérité et les autres en conservent une copie ou un lien.
Les configurations ci-dessous peuvent être mises en place pour disposer d'une source de vérité unique, le choix pouvant différer selon l'artefact :
- Le dépôt comme source de vérité. Les artefacts Markdown constituent l'enregistrement de référence, et le système existant référence les fichiers au sein des commits. Cela peut être l'une des configurations les plus propres pour les organisations pilotées par l'ingénierie, car tous les enregistrements vivent dans un seul outil avec une seule autorité d'horodatage.
- Le système existant fait foi. Jira, ServiceNow, ou l'outil d'exigences détient l'enregistrement de référence, et les artefacts Markdown sont des copies de travail. Claude lit l'enregistrement au début de la session et réécrit le résultat via un connecteur Model Context Protocol (MCP) dans la même session que celle qui a produit la spécification ou le plan.
- La liaison comme exigence minimale. Tous les artefacts notent l'identifiant de l'enregistrement, et tous les enregistrements existants contiennent le SHA de commit du fichier Markdown. L'option de liaison est un bon point de départ lors de la transition vers le SDLC natif IA, car il existe alors deux sources de vérité.
Le système existant et le système natif IA privilégiant le Markdown peuvent tous deux coexister, à condition qu'il existe un lien entre les deux ou que l'un soit déclaré source de vérité.