Comment éviter le mode plan avec la SDD : passer des idées aux preuves

Le mode plan apparaît quand l’équipe ou l’agent produit beaucoup d’intentions mais peu de preuves. Les documents s’allongent, les étapes semblent logiques, mais personne ne sait encore si le comportement fonctionne. Avec Codex ou Claude Code, ce piège est courant : l’agent peut très bien expliquer ce qu’il va faire sans livrer un changement vérifié.

• Repérer les plans qui ne mentionnent ni fichier, ni comportement observable, ni test, ni critère d’acceptation.
• Refuser les lots trop larges qui mélangent architecture, UI, données, tests et refactor.
• Demander une preuve rapide : changement minimal, commande de test, capture, diff ou scénario validé.

La SDD commence par une spécification assez précise pour guider l’agent, mais assez courte pour être exécutée. Une bonne spec décrit le problème, l’utilisateur, le comportement attendu, les contraintes, les cas limites et ce qui prouve que le travail est fini. Elle remplace le flou par un contrat de vérification.

• Écrire le comportement en phrases testables : quand, alors, avec quelle donnée, dans quel contexte.
• Ajouter les exclusions explicites pour empêcher l’agent de refactorer ou d’étendre le scope inutilement.
• Définir les critères d’acceptation avant d’écrire ou générer le code.

Un agent de code travaille mieux quand chaque lot a une frontière claire. Le bon découpage réduit le nombre de fichiers touchés, isole les risques et permet de vérifier vite. Au lieu de demander une fonctionnalité complète en une passe, la SDD pousse à livrer une tranche réelle : modèle, route, composant, état vide, test, puis intégration.

• Limiter chaque lot à un comportement vérifiable et à quelques fichiers cohérents.
• Faire terminer chaque lot par une validation : test automatisé, scénario manuel ou inspection du rendu.
• Garder un journal des décisions pour éviter que l’agent réinvente le plan au lot suivant.

Codex et Claude Code deviennent plus fiables quand ils ont une cible de validation. Les tests ne servent pas seulement à éviter les régressions ; ils servent à guider l’implémentation. Même un test léger, une checklist ou un scénario Playwright vaut mieux qu’un plan abstrait sans vérification.

• Demander à l’agent de lire le code existant, proposer le lot, écrire ou ajuster le test, puis implémenter.
• Utiliser les critères d’acceptation comme checklist de revue, pas comme décoration dans un document.
• Exiger le résultat des commandes de validation ou une explication claire si un test ne peut pas tourner.

La dernière étape est celle qui tue le mode plan : ouvrir le produit, exécuter le scénario, regarder le rendu, vérifier les états et confirmer que le comportement répond à la spec. Une PR qui passe les tests peut encore être mauvaise si l’expérience réelle est confuse. La SDD relie donc code, tests et usage.

• Vérifier desktop, mobile, états vides, erreurs, chargement et permissions quand le risque le justifie.
• Comparer le résultat à la spec initiale avant d’ajouter de nouvelles idées.
• Transformer les écarts en nouveaux petits lots plutôt qu’en grand plan de rattrapage.