Planification avant de coder

L'assistant prédit du code plausible à partir de ce qui est dans son contexte. Plausible est le type dangereux, car il compile, il est lisible, et il peut toujours résoudre le mauvais problème. Sans un plan sur lequel vous vous êtes d'abord mis d'accord, vous découvrez que l'approche était mauvaise seulement après qu'elle ait été étendue à une douzaine de fichiers, et à ce moment-là, la mauvaise idée est devenue essentielle.

Imaginez un développeur qui tape "ajouter une pagination au point de terminaison des commandes" et laisse un agent fonctionner. L'assistant choisit la pagination par décalage, car ce modèle apparaît le plus souvent dans sa formation et rien dans le prompt ne l'a dirigé ailleurs. Dix minutes plus tard, il y a un diff propre à travers le gestionnaire, la couche de requête, deux tests, et la documentation de l'API. Cela semble terminé. Ce n'est qu'en révision que la raison pour laquelle c'était faux apparaît : cette table est lourde en ajouts, donc la pagination par décalage saute et répète des lignes lors d'inserts concurrents. La solution est une pagination basée sur le curseur, une forme entièrement différente. Maintenant, le développeur défait un diff confiant et bien formaté au lieu de corriger une phrase dans un plan.

C'est la manière coûteuse d'apprendre la leçon. La manière économique est de lire un plan qui dit "approche : pagination par décalage" et de répondre "utilisez un curseur, la table est lourde en ajouts" avant qu'un seul fichier ne change. Même correction, une fraction du coût, et l'assistant porte la contrainte à travers toute l'implémentation au lieu de la combattre après coup.

Le gain se multiplie avec la quantité de travail que vous déléguez d'un coup. En 2026, les agents dans Claude Code, Cursor, et GitHub Copilot peuvent fonctionner pendant plusieurs minutes, éditer à travers les fichiers, et exécuter des commandes sans enregistrer. Plus cette période ininterrompue est longue, plus il est important que la direction soit correcte dès le départ. Un plan est le seul point de contrôle économique qui se situe avant tout ce mouvement. Le mécanisme qui le rend économique est que le mode planification désactive entièrement les outils d'édition, ce que la section suivante détaille.

Planifier avant de coder est une action avec trois niveaux de soutien dans les outils actuels. L'idée durable est simple : séparer le moment où l'assistant propose du moment où il modifie vos fichiers, et mettre votre jugement dans cet intervalle.

• Le mode plan est verrouillé au niveau de l'outil. Dans Claude Code, le mode plan est un mode de permission où les lectures s'exécutent mais les outils d'édition sont désactivés, donc l'assistant ne peut physiquement pas modifier votre source pendant la planification. Le mode plan de Cursor et l'agent GitHub Copilot Plan fonctionnent de la même manière : exploration en lecture seule d'abord, modifications uniquement après votre approbation.
• Le plan est un artefact Markdown que vous pouvez éditer. Cursor écrit un plan Markdown avec des chemins de fichiers et des références de code. L'agent Copilot Plan le sauvegarde dans .copilot/plans/plan-{title}.md et maintient la synchronisation du chat lorsque vous éditez le fichier manuellement. Claude Code vous permet d'ouvrir le plan proposé dans votre éditeur avec Ctrl+G avant de continuer.
• L'approbation mène directement à l'implémentation. Lorsque vous approuvez un plan Claude Code, vous choisissez comment il s'exécute : réviser chaque modification manuellement, accepter les modifications au fur et à mesure, ou le confier à un mode plus autonome. Cursor et Copilot transmettent le plan approuvé à l'Agent pour exécuter les étapes.

Deux distinctions déterminent si votre plan vaut la minute qu'il coûte. La première est un vrai plan versus la tâche reformulée. Un vrai plan nomme les fichiers qu'il touchera, les risques, les cas limites et les tests, de sorte qu'il y ait quelque chose de concret à contester. "Je vais ajouter la pagination au point de terminaison des commandes" n'est que la demande au futur. Si vous ne trouvez pas une phrase avec laquelle être en désaccord, le plan est trop vague pour vous protéger.

La deuxième est planifier un seul changement versus un développement basé sur des spécifications. Pour une fonctionnalité unique, le mode plan intégré à l'outil suffit. Lorsque le travail est important ou partagé, GitHub Spec Kit traite la spécification et le plan comme une source de vérité versionnée plutôt qu'un échafaudage jetable, avec une séquence fixe : /specify l'intention, /clarify les lacunes, /plan l'approche technique, /tasks pour le diviser en petites unités ordonnées, puis /implement. La même spécification alimente Copilot, Claude Code, Cursor et d'autres agents, donc le plan survit à la session de chat qui l'a produit. Avec les couches nommées, la section suivante suit un plan de la demande au code fusionné.

Une développeuse nommée Maya doit ajouter la pagination à GET /api/orders dans un service réel. Le point de terminaison renvoie actuellement toutes les commandes en une seule réponse, ce qui commence à expirer. Elle a déjà eu des problèmes en laissant un agent fonctionner sans planification, donc cette fois elle planifie d'abord.

1. Définir l'objectif et passer en mode plan. Maya appuie sur Shift+Tab dans Claude Code jusqu'à ce que la barre d'état affiche le mode plan, puis tape l'objectif : pagination basée sur le curseur sur GET /api/orders, en gardant les appelants d'offset existants fonctionnels pendant une transition.
2. Laissez-le rechercher et poser des questions. Le mode plan lit src/api/orders.ts et src/db/orders.ts, puis pose une question de clarification : le curseur doit-il encoder le timestamp de création ou l'identifiant de commande ? Maya répond "l'identifiant, il est monotone ici."
3. Lire le plan préliminaire. Le plan nomme trois fichiers, liste le risque que les appelants d'offset existants doivent continuer à fonctionner, et nomme quatre cas limites : page vide, dernière page, curseur invalide et un doublon à la limite. Il propose d'ajouter un nouvel assistant de requête plutôt que de réécrire l'existant.
4. Modifier le plan. Maya l'ouvre avec Ctrl+G. Le plan suggérait d'ajouter une couche de mise en cache "pour la performance." Cela est hors du champ d'application, donc elle supprime cette étape et ajoute une ligne : "ne pas ajouter de mise en cache, hors du champ pour ce changement."
5. Approuver et réviser chaque modification. Elle approuve avec l'option de révision de chaque modification. L'agent implémente les trois fichiers en tant que diffs séparés. Elle lit chacun, confirme que le chemin d'offset n'est pas touché, et accepte.
6. Tester les cas limites nommés et valider par petites étapes. Elle exécute la suite de tests, qui inclut maintenant un cas par cas limite nommé par le plan. Tous passent. Elle valide en deux étapes, l'assistant de requête et le gestionnaire, chacun bien en dessous de 400 lignes pour que la révision reste lisible.

Tout le détour, la couche de mise en cache que Maya a coupée, a pris une ligne supprimée dans un fichier Markdown au lieu d'un argument sur la portée pendant la révision. Cette seule édition est la différence entre planifier et ne pas planifier, et c'est exactement le genre de chose qui tourne mal lorsque le plan est sauté ou approuvé à la va-vite, ce que la section suivante couvre.

Chacun de ces pièges donne l'impression que vous planifiez tout en sautant discrètement la partie qui rend la planification efficace.

• Le plan qui est la tâche reformulée. Si le plan ne nomme aucun fichier, aucun risque, et aucun cas limite, l'approuver ne vous donne rien sur quoi vous appuyer. La solution est d'exiger des détails dans le prompt : "listez les fichiers avant tout code, et mentionnez toute hypothèse que vous faites." Si l'assistant ne peut pas, la tâche est sous-spécifiée et c'est en soi la découverte.
• Lire sans éditer. Un plan que vous survolez et approuvez transporte directement l'hypothèse erronée de l'assistant dans le code, avec une étape de planification qui vous a donné un faux sentiment de sécurité. Traitez le plan comme un brouillon à annoter. Si vous n'avez rien trouvé à changer, expliquez pourquoi, ne vous contentez pas de cliquer sur approuver.
• Approuver, puis ne pas surveiller. Un plan solide dérive toujours lors d'une longue exécution d'agent, surtout lorsque l'agent rencontre quelque chose que le plan n'avait pas prévu. Révisez chaque modification sur un travail risqué, et arrêtez l'exécution dès qu'un diff ne correspond plus à l'approche convenue.
• Le plan qui élargit la portée. Comme la couche de mise en cache de Maya, les agents ont tendance à proposer plus que ce que vous avez demandé : abstraction supplémentaire, nouvelle dépendance, refactorisation "tant qu'on y est." Coupez cela dans le plan, où cela coûte une ligne, avant que cela ne devienne du code sur lequel vous devez argumenter lors de la révision.

Ensuite, les véritables cas limites. Le plan qui aurait dû être une question. Parfois, la bonne décision après avoir lu le plan est de rester en mode plan et de demander à l'assistant de comparer deux approches avec leurs compromis, plutôt que d'approuver la première plausible. Le mode plan est en lecture seule, donc cela ne coûte rien d'autre qu'un aller-retour, et cela met en lumière le choix que vous étiez sur le point de faire implicitement.

La dépendance hallucinée. Une particularité de 2026 à attraper dans le plan, pas dans le diff : environ un échantillon d'IA sur cinq fait référence à un package qui n'existe pas ou n'est pas dans votre projet. Si un plan propose d'intégrer une bibliothèque, vérifiez qu'elle est réelle et maintenue avant d'approuver, car une fois dans le code, l'importation semble aussi légitime que toute autre. L'attraper dans le plan est un commentaire ; l'attraper après une installation échouée ou, pire, un package typosquatté, est un incident de sécurité. Gérer cela devient plus difficile une fois que plus d'une personne dépend du même plan, ce qui est là où l'échelle entre en jeu.

Un plan que vous gardez en tête fonctionne pour un changement que vous implémentez vous-même. Dès qu'un coéquipier doit faire confiance au plan, ou que le travail s'étend sur plus d'une session, le plan doit devenir un artefact durable plutôt qu'un message de chat qui défile.

C'est pour cela que le développement basé sur des spécifications existe, et pourquoi il est passé d'une idée de niche à une norme en 2026. Au lieu d'un plan jetable, un chef d'équipe comme Priya utilise GitHub Spec Kit pour que la spécification et le plan soient des fichiers versionnés dans le dépôt. La séquence est fixée à dessein : /specify capture le quoi et le pourquoi, /clarify force les parties sous-spécifiées à être exposées avec des questions structurées, /plan enregistre l'approche technique et la stack, /tasks le divise en petites unités ordonnées, et /implement les exécute. Parce que la spécification est la source de vérité et vit dans git, un réviseur peut lire ce qui a été convenu, un deuxième développeur peut reprendre le même plan dans Cursor ou Copilot, et un changement ultérieur peut être comparé à l'intention originale.

Deux artefacts permettent à la planification de survivre en équipe. Le premier est le plan ou spécification enregistré, révisé comme du code. Le second est une habitude du côté de l'implémentation : garder chaque commit petit. Les agents basés sur des plans peuvent produire un diff large et cohérent en interne en une seule exécution, et un diff de 1 000 lignes submerge à la fois un réviseur humain et un réviseur IA, qui se rabat alors sur le style. Les équipes qui gardent les pull requests près de 200 lignes et sous un plafond de 400 lignes rapportent des cycles de révision environ 30-40 % plus rapides, car le réviseur peut réellement comprendre le changement. Un bon plan qui se traduit par un énorme diff a perdu la moitié de sa valeur.

L'échelle change aussi la façon dont vous enregistrez le rôle de l'assistant. Lorsqu'un changement basé sur un plan atteint la révision, notez dans la description de la pull request qu'un agent l'a implémenté, quel plan ou spécification il a suivi, et ce que vous avez vérifié manuellement. Cela transforme "l'IA l'a écrit" d'un haussement d'épaules en une décision traçable que le prochain réviseur peut vérifier.

Le principe durable à retenir, quelle que soit la taille du travail : séparer le moment où l'assistant propose du moment où il modifie vos fichiers, et utilisez votre jugement dans cet intervalle. Commencez par une petite chose. Lors de votre prochain changement multi-fichiers, passez en mode plan, lisez le plan, et trouvez une phrase à corriger avant d'approuver. Cette seule habitude représente la majeure partie de la valeur.