Comment garder votre agent de codage IA sur les rails : explorer, planifier, puis construire

Quand les gens utilisent pour la première fois un outil de codage agentique comme Claude Code ou Cursor, ils ont tendance à taper une demande d'une ligne et à espérer. Parfois ça marche. Souvent, l'agent construit avec assurance la mauvaise chose — en résolvant un problème que vous n'aviez pas posé, en touchant des fichiers auxquels vous ne vous attendiez pas, ou en ignorant le cas limite qui comptait vraiment.

La solution n'est pas un modèle plus intelligent. C'est un workflow : explorer d'abord, puis planifier, puis construire. C'est le schéma qu'Anthropic recommande dans son guide officiel des bonnes pratiques de Claude Code, et la même idée s'applique à tout agent capable de lire votre dépôt avant de le modifier.

Pourquoi sauter directement au code échoue

Un agent IA travaille dans une fenêtre de contexte limitée — le journal en cours de votre conversation, plus chaque fichier qu'il lit et chaque commande qu'il exécute. Deux choses tournent mal quand vous sautez la planification :

1. L'agent devine l'intention. Il ne peut pas lire dans vos pensées, donc un prompt vague donne une implémentation plausible mais fausse.
2. Les erreurs s'accumulent silencieusement. Une fois que l'agent commence à modifier, une mauvaise hypothèse à l'étape une est enfouie sous dix autres changements avant que vous ne vous en aperceviez.

Séparer la réflexion de l'action attrape la mauvaise hypothèse tant qu'elle est encore bon marché à corriger — une phrase de correction au lieu d'un retour arrière sur 12 fichiers.

Étape 1 : explorez en mode lecture seule

La plupart des agents sérieux disposent désormais d'un mode où ils peuvent lire et analyser mais ne peuvent rien modifier. Dans Claude Code, on l'appelle plan mode : un état en lecture seule où l'agent lit des fichiers et répond aux questions sans modifier, exécuter de commandes qui changent l'état, ni faire de commit.

Commencez par demander à l'agent de comprendre le code, pas de le changer :

Read /src/auth and explain how we handle sessions and login.
Also look at how we manage environment variables for secrets.

Vous construisez un contexte partagé et vérifiez que l'agent comprend réellement votre base de code avant de lui faire confiance pour la modifier.

Étape 2 : demandez un plan, puis poussez dessus

Une fois que l'agent a exploré, demandez un plan concret avant tout code :

I want to add Google OAuth login. What files need to change?
What's the session flow? Write a step-by-step plan — don't write code yet.

L'agent renvoie un plan numéroté : quels fichiers il va toucher, le nouveau flux de session, où il stockera les jetons. Maintenant, n'acceptez pas le premier jet. C'est le moment le moins coûteux pour rectifier le tir. Poussez sur les lacunes :

• « Que se passe-t-il si le callback OAuth échoue à mi-chemin ? »
• « Nous avons déjà un assistant refreshToken dans src/auth/tokens.ts — réutilise-le au lieu d'en écrire un nouveau. »
• « Limite-toi au flux de connexion uniquement. Ne touche pas au code existant de réinitialisation de mot de passe. »

Quelques minutes à affiner le plan ici vous épargnent une heure à démêler une mauvaise implémentation plus tard.

Étape 3 : construisez avec un moyen de vérifier

C'est seulement maintenant que vous laissez l'agent écrire du code — et vous lui donnez un moyen de vérifier son propre travail. L'ajout le plus puissant à n'importe quel prompt est une étape de vérification que l'agent peut exécuter lui-même :

Implement the OAuth flow from your plan. Write a test for the callback
handler covering the failure case, run the test suite, and fix any failures.

Sans une vérification qu'il peut exécuter — tests, une compilation, une capture d'écran à comparer — « ça a l'air terminé » est le seul signal dont dispose l'agent, et vous devenez le détecteur d'erreurs pour chaque faute. Avec une vérification, la boucle se referme d'elle-même : l'agent écrit, exécute le test, lit le résultat et itère jusqu'à ce qu'il passe. Demandez-lui de montrer la sortie réelle des tests plutôt que de simplement prétendre au succès.

Étape 4 : sachez quand sauter le plan

La planification a un coût, et elle n'en vaut pas toujours la peine. Si le changement est petit et la portée évidente — corriger une faute de frappe, ajouter une ligne de log, renommer une variable — demandez simplement à l'agent de le faire directement. Une bonne règle empirique tirée du guide d'Anthropic : si vous pouvez décrire le diff en une phrase, sautez le plan. Réservez le cycle explorer-planifier-construire au travail qui s'étend sur plusieurs fichiers, utilise une approche dont vous n'êtes pas sûr, ou touche du code que vous connaissez mal.

Un filet de sécurité : rectifiez tôt et utilisez les points de contrôle

Même avec un bon plan, les agents dérivent. Deux habitudes vous gardent aux commandes :

• Interrompez dès qu'il déraille. N'attendez pas que l'agent termine une mauvaise approche. Dans Claude Code, Esc l'arrête en pleine action avec le contexte préservé, pour que vous puissiez le réorienter.
• Utilisez les points de contrôle pour expérimenter librement. Claude Code prend un instantané de vos fichiers avant chaque changement, donc vous pouvez demander à l'agent d'essayer quelque chose de risqué, et si ça ne marche pas, revenir en arrière (Esc Esc ou /rewind) et tenter une approche différente. (Les points de contrôle suivent les propres modifications de l'agent, pas les processus externes — c'est une commodité, pas un substitut à git.)

Et si vous vous surprenez à corriger la même erreur plus de deux fois, le contexte est probablement pollué par des tentatives ratées. Effacez-le et redémarrez avec un prompt plus net qui intègre ce que vous venez d'apprendre — une session propre avec un meilleur prompt l'emporte presque toujours sur une longue session pleine d'impasses.

À retenir

Explorer, planifier, construire, vérifier. Cela semble plus lent pour la première tâche et se rentabilise dès la deuxième. Vous cessez d'obtenir du code sûr de lui mais faux, et vous commencez à obtenir un agent qui construit ce que vous vouliez vraiment dire.