Construire : le mode plan comme point de départ

Objectifs

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

• Démarrer chaque changement par un plan relu, enregistré dans plan.md
• Savoir quand le mode automatique devient raisonnable
• Articuler les fichiers Markdown avec les outils existants (Jira, outil d’exigences)

Ce qui change

Traditionnellement, un développeur lit la conception et commence à coder. Le « comment » — quels fichiers, quels tests — reste dans sa tête, au mieux dans un commentaire de ticket. Le premier élément que voit un relecteur est le diff final, quand toute reprise coûte cher.

Dans un cycle AI-native, la session démarre en mode plan : Claude lit intent.md et spec.md, interroge l’ingénieur, et produit un plan que l’on itère jusqu’à satisfaction, enregistré dans plan.md pour que les étapes suivantes puissent s’y référer.

Pour démarrer

• Prérequis : l’intention (intent.md ou spec.md) si elle existe ; un CLAUDE.md aide (leçon 5).
• Infrastructure : Claude Code, avec accès au dépôt.

Mise en œuvre

1. Démarrez la session en mode plan. Tant que l’ingénieur n’a pas accepté le plan, Claude ne peut pas modifier les fichiers.
2. Donnez intent.md et spec.md, et demandez un plan d’implémentation qui nomme les fichiers modifiés, l’ordre du travail et les tests qui prouveront le résultat.
3. Interrogez le plan : que pourrait casser ce changement ? Quelle étape est la plus risquée ? Quelles options Claude a-t-il écartées ?
4. Itérez jusqu’à ce qu’un ingénieur qui n’a pas vu la conversation puisse implémenter le changement à partir du plan seul.
5. Enregistrez plan.md : il rejoint la piste d’audit, et la revue de pull request (leçon 10) confrontera le diff à ce plan.
6. Acceptez le plan et laissez Claude implémenter. Avec un plan solide, l’implémentation tient souvent en une passe. Si le plan change en cours de route, mettez à jour plan.md dans le même commit ; un hook peut imposer cette synchronisation.

# Plan : suivi des remboursements (d'après intent.md et spec.md)
## Fichiers modifiés
espace/src/remboursements/PanneauEtat.tsx (nouveau), remb-api/routes/etat.py, remb-api/tests/test_etat.py
## Ordre du travail
1. Point d'accès d'état derrière l'authentification existante (E1, E2, E3).
2. Panneau branché sur ce point d'accès, avec un cache de 60 secondes.
## Risques
L'ancien système limite à 50 requêtes par seconde : le panneau doit mettre en cache (point de tension 2).
## Preuve
test_etat.py couvre les quatre états (E2) et échoue sur tout champ en trop (E3).

Le mode automatique, plus tard

Le mode automatique de Claude Code laisse Claude agir sans demander d’autorisation pour chaque action courante : un modèle classificateur distinct examine les actions avant leur exécution et bloque celles qui dépassent la demande, visent une infrastructure non reconnue ou semblent dictées par un contenu hostile lu par Claude ; les règles « ask » explicites imposent toujours une confirmation. Depuis la version 2.1.283, c’est le mode de départ des sessions interactives. Le guide propose de l’utiliser une fois le plan itéré et approuvé. À mesure que les garde-fous des autres pratiques mûrissent — un CLAUDE.md affiné, des skills qui encodent les politiques, des hooks qui bloquent les actions dangereuses, des tests que Claude peut lancer —, il devient le mode par défaut pour le travail courant : une spécification serrée, un rayon d’impact réduit, et du code déjà couvert par les tests.

Les outils existants et la source de vérité

Vos processus suivent déjà des artefacts ailleurs : tickets dans Jira, exigences dans un outil de traçabilité réglementaire, maquettes dans Figma, validations par un comité de changement. Les auditeurs et les régulateurs les acceptent : le cycle AI-native doit s’y adapter. Pour chaque type d’artefact, désignez une seule source de vérité :

• le dépôt fait foi : les fichiers Markdown sont l’enregistrement officiel, l’outil existant y renvoie ; c’est la configuration la plus simple pour une organisation pilotée par l’ingénierie ;
• l’outil existant fait foi : Jira, ServiceNow ou l’outil d’exigences garde l’enregistrement, les fichiers Markdown sont des copies de travail ; Claude lit l’enregistrement en début de session et y écrit le résultat par un connecteur MCP ;
• le lien comme minimum : chaque fichier note l’identifiant de l’enregistrement, et chaque enregistrement note l’empreinte du commit du fichier. C’est un bon point de départ pendant la transition.

Gouvernance et mesure

La revue de conception a lieu avant la génération du code, quand changer de cap revient à modifier un document. Le plan, ses révisions et la personne qui l’a accepté sont tracés ; les changements courants sont validés par l’ingénieur, les changements plus risqués par un responsable technique ou un architecte.

• Indicateur avancé : la part des changements fusionnés dès la première passe d’implémentation, et le délai entre l’approbation du plan et la fusion.
• Indicateur retardé : le nombre de cycles de reprise par changement, et la fréquence à laquelle le diff fusionné correspond encore au plan.md.

À vous de jouer

Un plan qu’un autre pourrait suivre. Sur un petit changement réel, démarrez Claude Code en mode plan, donnez-lui l’intention et la spécification, puis posez les trois questions de la leçon : qu’est-ce qui pourrait casser, quelle étape est la plus risquée, quelles options ont été écartées ? Enregistrez le plan.md, et faites le test final : confiez-le à un collègue qui n’a pas vu la conversation. Peut-il implémenter sans vous poser de question ?

Sources officielles : Claude Code plan mode as the default starting point (Claude Academy) · The AI-native SDLC playbook — Stage 3: Build · Permission modes · Claude Code auto mode

Points clés à retenir

• Chaque changement commence en mode plan : fichiers, ordre, tests, risques, relus avant toute ligne de code
• plan.md entre dans la piste d’audit et sert de référence à la revue
• Le mode automatique devient raisonnable quand les garde-fous des autres pratiques sont en place
• Pour chaque artefact, une seule source de vérité, ou au minimum un lien dans les deux sens