AI Coding Workflow : Comment réduire les modifications répétées de code par l'IA

Plan → Scoped Edit → Verify / Cursor Rules / petits diffs / checklist d'acceptation / diagnostic des boucles

Avec Cursor, Claude Code ou Copilot Workspace, vous connaissez peut-être cette soirée : l'IA modifie le fichier A, les tests échouent ; vous corrigez B, A casse à nouveau ; vous dites « réessaie », et le code qui marchait hier disparaît. Ce n'est pas que le modèle « manque d'intelligence » — il manque un AI Coding Workflow reproductible qui sépare planification, périmètre de modification et validation. Sans cette structure, l'Agent tourne indéfiniment sur la même hypothèse erronée.

Cet article présente un flux testé en équipe en 2026 : Planifier d'abord, modifier de façon ciblée, puis Verify avant d'avancer. Avec les Cursor Rules et de petits commits Git, nous avons réduit « corriger le même bug 8 fois » à 2 itérations maximum. Si vous déployez un MCP Server sur un Mac cloud ou évaluez des projets AI Agent open source sur GitHub, ce workflow s'applique de la même manière.

Pourquoi l'IA entre-t-elle dans une boucle sans fin ?

Le mode Agent, c'est essentiellement : essayer et se tromper dans un environnement incertain. Si vous dites seulement « corrige le bug de connexion », le modèle ne sait pas s'il s'agit du callback OAuth, de l'expiration de session ou du routage frontend — il devine la réponse la plus plausible, teste, échoue, puis tente une autre direction. Chaque tour invalide une partie de l'hypothèse précédente, le diff grossit, le contexte s'emplit de modifications contradictoires — et vous atteignez l'état « plus on patche, pire c'est ».

Trois causes profondes

• Objectif flou — sans définir « à quoi ressemble le succès », l'IA déduit à rebours des erreurs de test ; les messages d'erreur pointent souvent le symptôme, pas la racine
• Périmètre hors de contrôle — une tâche sur 10+ fichiers, un refactor de utils en passant par l'auth, de nouvelles régressions
• Pas de porte d'acceptation — sans règle stricte « on continue seulement si vert », l'échec déclenche « génère une autre version » au lieu de « rollback et redéfinir le périmètre »

Règle empirique : si vous dites « non, encore » trois tours de suite, le problème n'est pas le modèle — c'est que la tâche n'a pas été replanifiée.

Workflow en trois phases : Plan → Scoped Edit → Verify

Diviser chaque session IA en trois phases non contournables vaut souvent mieux qu'un upgrade de modèle :

1. Plan (planification) — en mode Plan ou dialogue seul : lister les fichiers concernés, les interdits et les commandes d'acceptation (ex. npm test -- auth). Livrable : une « spécification de tâche » à coller ; ne pas lancer l'Agent tout de suite, confirmer la spec d'abord
2. Scoped Edit (modification limitée) — écrire explicitement : « modifier uniquement src/auth/login.ts, interdit de toucher aux autres fichiers ». Par tour : 1–3 fichiers, <200 lignes nettes
3. Verify (validation) — tests, lint, smoke test manuel. Vert → commit et tâche suivante ; rouge → retour à Plan avec le journal d'erreur complet, pas « réessaie »

Structure du prompt : objectif, limites et acceptation en une fois

Modèle copiable (remplacez les parenthèses par votre projet) :

## Objectif
(Une phrase : l'utilisateur clique sur Connexion et accède au tableau de bord en 3 secondes)

## Périmètre
- Modifier uniquement : src/auth/login.ts, src/auth/session.ts
- Interdit : routage, styles, autres modules

## Acceptation
- npm test -- --grep "login"
- Manuel : mauvais mot de passe affiche « identifiant ou mot de passe incorrect », sans révéler si le compte existe

## Contexte
- Erreur actuelle : (coller la stack trace complète)
- Conventions : session dans Redis, voir docs/auth.md

Cette structure correspond à ce que les bonnes pratiques Claude Code d'Anthropic appellent des « limites claires » — le modèle n'a pas à deviner, et la surface de régression reste maîtrisée.

Rules / Skills : inscrire les contraintes du projet dans le dépôt

Répéter à chaque conversation « on utilise pnpm, pas de class components, tests dans __tests__ » gaspille des tokens et produit un comportement incohérent. Écrivez les conventions dans .cursor/rules ou un AGENTS.md projet :

Rules (règles)

Contraintes persistantes : style de nommage, motifs interdits, commandes obligatoires avant commit. Cursor les injecte à chaque appel Agent.

Skills (compétences)

Scénarios réutilisables, ex. checklist « ajouter un nouvel endpoint API ». Moins de découverte de la structure du projet à chaque tâche.

User Rules vs Project Rules

Préférences personnelles (ex. « répondre en français ») en User Rules ; consensus d'équipe (ex. « ne pas toucher au backend sans demande ») en Project Rules — essentiel en collaboration.

Voir la documentation Cursor Skills : une fois les flux fréquents figés, le nombre de corrections répétées du même type de bug chute nettement.

Petits diffs et discipline Git

L'IA excelle à générer de gros blocs de code — les humains reviewent mal les gros diffs. Recommandations :

• Une tâche Agent = un commit — message avec résumé du Plan, pour faciliter git revert
• En cas de chaos, reset — ne pas continuer à patcher un énorme diff ; git checkout -- . au dernier point vert, puis périmètre plus petit
• Branches pour expérimenter — surtout sur Mac cloud ou en CI : git worktree ou branche dédiée pour isoler les « modifications sauvages » de l'IA

Gestion du contexte : ne pas noyer l'Agent dans la mer de fichiers

Donner tout le monorepo à l'Agent, c'est chercher un signal dans le bruit. Mieux vaut :

1. Référencer précisément 3–5 fichiers avec @filename, pas « scanner tout le projet »
2. Découper les gros refactors en plusieurs Plans : interface, implémentation, tests — Verify à chaque étape
3. Après 15+ tours : nouvelle conversation avec « spec + état actuel », plus propre que de traîner l'historique

Quatre boucles courantes et comment en sortir

Si vous orchestrez des pipelines Agent complexes (traitement documentaire par lot ou chaînes d'outils MCP), le schéma « router → exécuter → valider » reprend le même principe que l'architecture de routage décrite dans notre article sur la reconnaissance PDF par lot : décider d'abord, agir ensuite — ne pas faire passer chaque tâche par le chemin le plus lent et le plus fragile.

Questions fréquentes

1. Un modèle plus puissant aide-t-il ? — Il réduit les erreurs de syntaxe, mais les problèmes de périmètre et les régressions dépendent peu du tier du modèle ; le workflow est le facteur clé
2. Comment harmoniser en équipe ? — Rules, modèles de PR et checklists d'acceptation dans le dépôt ; en code review, vérifier « petits commits ? »
3. Peut-on tout déléguer à l'Agent ? — L'exécution oui, mais Plan et Verify doivent rester des portes humaines — surtout pour paiement, auth et migrations
4. Comment articuler avec le TDD ? — D'abord un test qui échoue (Plan), puis implémentation (Scoped Edit), vert puis refactor — aligné naturellement avec les trois phases

En résumé : réduire les modifications répétées de code par l'IA ne se fait pas en « réessayant », mais par la discipline Plan → Scoped Edit → Verify, des prompts clairs, des Rules dans le dépôt et le courage de faire git revert. Une fois le flux en place, vous passez du temps à définir le problème — pas au N-ième patch.