Depuis un an, la promesse tenait en une phrase : décrivez ce que vous voulez, l'agent de code s'occupe du reste. Le résultat démarrait fort en démonstration, puis dérivait dès que le projet grossissait. En 2026, une méthode plus carrée s'installe pour corriger ce défaut. On l'appelle le développement piloté par spécification, ou spec-driven development. L'idée n'est pas neuve, mais elle prend une forme concrète et outillée.
Le principe : la spécification passe avant le code
Le développement piloté par spécification traite le document de spécification comme l'artefact central du projet. Le code devient une sortie régénérable, produite à partir de cette spécification par un humain, un agent, ou les deux. Autrement dit, on écrit d'abord ce que le logiciel doit faire, avec assez de précision pour qu'un agent puisse s'en servir, puis on lance la génération.
Le contraste avec le mode « on discute avec l'agent au fil de l'eau » est net. Ce mode fonctionne pour un prototype jetable. Il tient mal quand plusieurs personnes travaillent sur le même code, quand le projet doit vivre plusieurs mois, ou quand une correction ne doit pas en casser trois autres. Nous avions déjà décrit ce décrochage entre la démo et la production dans un article précédent.
L'outil qui a popularisé la démarche
Le projet le plus visible est Spec Kit, publié par GitHub. Sa page dépasse aujourd'hui 136 000 étoiles, un signal d'adoption fort dans l'écosystème des développeurs 1. Son mot d'ordre résume la logique : définir quoi construire avant de construire, avec n'importe quel agent de code. L'outil annonce la compatibilité avec une trentaine d'agents, dont GitHub Copilot et Claude Code.
Spec Kit organise le travail en six étapes qui donnent une bonne image de la méthode :
| Étape | Rôle |
|---|---|
| Constitution | Poser les principes qui gouvernent le projet |
| Specify | Décrire les besoins et les cas d'usage |
| Plan | Établir la stratégie technique |
| Tasks | Découper en tâches exécutables |
| Implement | Faire produire le code par l'agent |
| Converge | Vérifier que le code respecte la spécification |
Spec Kit n'est pas seul. AWS a livré Kiro autour de la même idée, et plusieurs éditeurs proposent leur propre variante. La démarche s'est donc diffusée chez la majorité des acteurs du secteur en 2026, ce qui la rend difficile à ignorer pour une équipe qui construit du logiciel.
Ce que la méthode change en pratique
Le premier effet est le premier essai. Quand la spécification est écrite avec soin, l'agent tape moins souvent à côté et on relance moins la génération complète. Les éditeurs avancent des gains de l'ordre de trois à dix fois sur le taux de réussite au premier essai pour des tâches non triviales. Ce chiffre provient de retours d'adoption communiqués par GitHub et AWS, et non d'une mesure indépendante ; il faut donc le lire comme une tendance annoncée, pas comme une garantie 2.
Le second effet touche un risque bien documenté. Les modèles inventent parfois des noms de bibliothèques qui n'existent pas. Une étude présentée à USENIX Security en 2025 mesurait que près de 20 % des paquets recommandés par les modèles testés n'existaient pas 3. Une spécification qui liste explicitement les dépendances autorisées réduit la surface de ce problème, car l'agent travaille dans un cadre borné plutôt que d'improviser.
Le troisième effet est humain. La spécification donne un point de référence lisible pour la revue. Au lieu de relire des centaines de lignes générées, on vérifie d'abord que la spécification dit la bonne chose, puis que le code s'y conforme. La charge de relecture se déplace vers un objet plus court et plus stable.
Le coût que personne ne met en avant
La méthode a un prix, et il tombe au début. Écrire une bonne spécification demande du temps et de la clarté sur le besoin. Une équipe qui n'arrivait pas à cadrer ses demandes avant l'IA n'y arrivera pas mieux en ajoutant un outil. La spécification devient aussi un document à maintenir : si elle diverge du code réel, elle induit en erreur au lieu d'aider. Enfin, l'étape de vérification finale reste nécessaire. Aucune spécification ne dispense de tester ce que l'agent a produit.
Notre lecture
Pour une PME ou une ETI qui fait développer du logiciel, sur mesure ou autour d'Odoo, le mouvement mérite attention pour une raison simple : il remet de la traçabilité là où le mode conversationnel n'en laissait aucune. Un devis, un cadrage, une recette client se raccrochent naturellement à une spécification écrite. C'est le même réflexe que dans un projet classique, appliqué à un flux de production accéléré.
Nous conseillons de ne pas attendre un gain de dix fois. Le vrai bénéfice observable, c'est moins de reprises et une revue qui porte sur un document au lieu d'un mur de code. Commencez sur un périmètre restreint, une fonctionnalité bien délimitée, et jugez sur vos propres chiffres. Un outil qui vous force à écrire ce que vous voulez avant de le construire a déjà, en soi, une vertu qui dépasse l'IA.
Sources
- GitHub Spec Kit (dépôt officiel) : https://github.com/github/spec-kit
- Augment Code, panorama des outils spec-driven 2026 : https://www.augmentcode.com/tools/best-spec-driven-development-tools
- Spilling the Sap: USENIX Security 2025, hallucination de paquets par les LLM : https://www.usenix.org/conference/usenixsecurity25
- Cloud Security Alliance, note de recherche sur le slopsquatting (avril 2026) : https://labs.cloudsecurityalliance.org/research/csa-research-note-slopsquatting-ai-supply-chain-20260419-csa/
Footnotes
-
Nombre d'étoiles du dépôt GitHub Spec Kit relevé sur la page du projet en septembre 2026 ; l'étoile mesure l'intérêt de la communauté de développeurs, pas un volume d'usage en production. ↩
-
Gains de trois à dix fois sur la réussite au premier essai : chiffres issus de retours d'adoption communiqués par GitHub et AWS, non confirmés par une évaluation indépendante. À traiter comme un ordre de grandeur annoncé. ↩
-
Étude sur l'hallucination de noms de paquets présentée à USENIX Security 2025 : environ 20 % des paquets recommandés par les modèles testés n'existaient pas. Le chiffre varie selon les modèles et les langages. ↩