Sommaire
À l'ère où c'est l'IA qui écrit le code, la compétence à plus forte valeur se déplace de « écrire du code » vers « écrire la spécification ». La pratique qui incarne ce changement est le développement piloté par la spécification (Spec-Driven Development, SDD). En 2026, les grands outils — Claude Code, GitHub, AWS et d'autres — l'ont tous adopté, et il attire l'attention comme « l'étape suivante » après le vibe coding.
Cet article présente, pour les débutants, ce qu'est le développement piloté par la spécification, pourquoi il s'impose aujourd'hui, ses quatre étapes de base, les principaux outils, et quand l'utiliser plutôt que le vibe coding.
« Specify → Plan → Tasks → Implement »
— chaque étape laisse un document, pour que l'IA n'ait jamais à deviner
Specify
Décrivez ce que vous construisez, avec des mots.
Plan
Ajoutez la conception, la technique et les contraintes.
Tasks
Découpez en petites unités vérifiables.
Implement
L'IA construit en suivant la spécification.
1. Qu'est-ce que le Spec-Driven Development (SDD) ?
Le développement piloté par la spécification est une approche dans laquelle la « spécification » est la vedette du projet (le document central), et l'IA en déduit l'implémentation. Plutôt que de faire écrire le code à l'IA immédiatement, on commence par consigner « quoi construire et comment » dans un document structuré, et un agent IA lit cette spécification pour concevoir, découper et implémenter.
Imaginez « le plan avant de construire une maison ». Demandez à un charpentier de « simplement faire quelque chose de bien » sans plan, et le résultat varie, avec beaucoup de reprises. Un agent IA fonctionne pareil : une consigne floue engendre des suppositions. Fixez d'abord le plan — la spécification — et vous réduisez la marge laissée à l'IA pour partir dans sa propre implémentation.
💡 En une phrase : le SDD = « écrire la spécification avant le code ». La spécification est la source de vérité, et le code en est un dérivé généré à partir d'elle. Vue sous l'angle de l'ingénierie du contexte, la spécification est aussi le meilleur « contexte » que vous puissiez transmettre à l'IA.
2. Pourquoi maintenant ? Le « mur des trois mois » du vibe coding
Le vibe coding (construire en discutant ses idées au fil de l'eau) peut produire des prototypes à une vitesse fulgurante, mais il a tendance à s'effondrer à grande échelle. Les retours d'expérience et les praticiens décrivent souvent un code bâti sur l'élan qui heurte un « mur de dette technique » au bout d'environ trois mois, avec des coûts de maintenance qui explosent. Le code généré par l'IA reste en place, s'accumule en production, et devient impossible à corriger par la suite.
Le développement piloté par la spécification élimine cette « dérive des besoins » dès l'étape de conception. Fixer d'abord la spécification ajoute un effort en amont, mais réduit fortement les reprises en aval. GitHub rapporte que, avec son propre outillage, le nombre de cycles de « tout régénérer de zéro » a chuté d'environ un ordre de grandeur (chiffre communiqué par l'éditeur).
Rapide · idéal pour explorer
- Prototypage et validation ultra-rapides
- On explore la direction en discutant
- Mais tend à s'effondrer à grande échelle
- Les besoins dérivent et la dette s'accumule
Maintenable · idéal pour livrer
- La spécification est la source de vérité, donc moins de dérives
- Empêche la dérive des besoins par conception
- Davantage d'effort en amont
- Bien moins de reprises, plus facile à maintenir
On dit même qu'« en 2026, l'atout de l'ingénieur tient plus à sa capacité d'écrire des spécifications qu'à écrire du code ». Plus vous déléguez à l'IA, plus le rôle humain se déplace vers « définir précisément quoi construire ».
3. Le flux de base — quatre étapes
Les appellations varient un peu selon l'outil, mais le développement piloté par la spécification suit grosso modo les mêmes quatre étapes. L'essentiel est que chaque étape laisse un document (souvent un fichier Markdown) que l'étape suivante lit. L'astuce consiste à ne pas garder l'information dans la seule tête de l'IA.
① Specify
Décrivez quoi construire — fonctionnalités, objectif, utilisateurs, critères d'acceptation — avec des mots.
② Plan (conception)
Ajoutez comment le construire : architecture, bibliothèques que vous utiliserez et contraintes.
③ Tasks (découpage)
Découpez le plan en petites unités vérifiables que vous pouvez valider une à une.
④ Implement
L'IA construit chaque tâche en suivant la spécification. Les humains se concentrent sur la revue et l'approbation.
⚠️ La revue humaine est obligatoire : même en travail piloté par la spécification, ne sautez jamais la vérification du code généré par l'IA. Le SDD n'est pas un outil de type « lance et oublie » — c'est un mécanisme qui rend le pilotage par l'humain plus facile.
4. Les principaux outils (Spec Kit, Kiro, etc.)
En 2026, la plupart des grands agents de codage prennent en charge le SDD. Voici les exemples phares.
GitHub Spec Kit
Un CLI open source (plus de 90 000 étoiles sur GitHub). Il prend en charge Specify → Plan → Tasks → Implement et fonctionne avec plus de 30 agents, dont Claude Code et GitHub Copilot.
AWS Kiro
Il déroule Requirements → Design → Tasks avant de générer le moindre code, avec un routeur Auto qui choisit le meilleur modèle selon la tâche, disponible en CLI comme sur le web.
Autres
BMAD, OpenSpec, Tessl, Google Antigravity et Cursor proposent eux aussi leurs propres flux SDD. La plupart des grands outils le prennent en charge sous une forme ou une autre.
Vous n'avez même pas besoin d'un outil dédié — vous pouvez pratiquer l'état d'esprit simplement en « écrivant d'abord la spécification en Markdown, puis en la faisant lire à l'IA avant d'implémenter ». Cela rend aussi le problème de l'IA qui ignore vos règles moins probable, car vous transmettez la spécification sous la forme d'un document clair.
5. Quand l'utiliser plutôt que le vibe coding
Ce qui compte n'est pas « lequel est le bon » mais « quand utiliser lequel ». La réponse pratique pour 2026 est hybride — le vibe pour explorer, le piloté par la spécification pour livrer.
- Quand le vibe coding convient : valider une idée, des prototypes jetables, essayer quelque chose de petit tout seul. L'étape où l'on veut juste arriver vite à « quelque chose ».
- Quand le piloté par la spécification convient : les systèmes en production que vous maintiendrez sur le long terme, le développement en équipe, les produits où la spécification compte. Quand vous considérez l'ensemble du cycle de vie du développement.
Donc : commencez par le vibe pour trouver vite la direction, puis, une fois la décision de vous engager prise, posez-la dans une spécification et développez-la. Les deux ne s'opposent pas — la bonne démarche consiste à les employer pour des phases différentes.
6. Comment l'essayer dès aujourd'hui
Vous pouvez commencer modestement, sans installer le moindre outil dédié.
- Écrivez d'abord une spécification d'une page : pour la fonctionnalité voulue, notez en puces, en Markdown, « objectif, entrées/sorties, critères d'acceptation ».
- Faites lire la spécification à l'IA avant de demander du code : dites-lui « implémente strictement selon cette spécification ; pose-moi des questions sur tout ce qui est ambigu ». Ne vous contentez pas de dire « construis-le ».
- Découpez les tâches en petits morceaux : pas tout d'un coup — implémentez une fonctionnalité, passez en revue, puis la suivante. Consigner la procédure dans des Claude Skills améliore la reproductibilité.
- Gardez la spécification à jour : quand quelque chose change, corrigez la spécification avant le code. Maintenir la spécification comme source de vérité est le cœur du SDD.
💡 Cela aide aussi les débutants : quand vous construisez une application avec l'IA, le simple fait d'écrire d'abord la spécification relève nettement la qualité du résultat. C'est une astuce utilisable même si vous n'êtes pas à l'aise en programmation.
En résumé
Trois points clés sur le développement piloté par la spécification.
- Ce que c'est : écrire la « spécification » avant le code et faire implémenter l'IA en s'appuyant dessus comme source de vérité. La spécification est le document central.
- Pourquoi : parce que cela prévient la « dérive des besoins et la dette technique » du vibe coding dès l'étape de conception et réduit les reprises.
- Quand : un hybride — le vibe pour explorer, le piloté par la spécification pour livrer. La revue humaine est obligatoire.
Commencez par « écrire une spécification d'une page avant de construire ». À l'ère de l'IA, ceux qui montent ne sont pas ceux qui écrivent le code le plus vite, mais ceux qui savent définir précisément quoi construire. Lisez le vibe coding et l'ingénierie du contexte en complément pour avoir une vision d'ensemble du développement assisté par l'IA.
FAQ
Q. Un débutant en programmation peut-il faire du développement piloté par la spécification ?
R. Oui — c'est sans doute le plus efficace pour les débutants. Le simple fait d'organiser « quoi construire » avec des mots avant tout code stabilise la sortie de l'IA et en relève la qualité. Vous pouvez démarrer à partir de notes en Markdown, sans aucun outil dédié.
Q. Le vibe coding est-il désormais dépassé ?
R. Non. Pour l'exploration et le prototypage, le vibe coding reste le plus rapide. Ce n'est pas l'ancien contre le nouveau — les employer par phase est la norme en 2026 : le vibe pour explorer, le piloté par la spécification au moment de passer en production.
Q. À quel point la spécification doit-elle être détaillée ?
R. La règle est d'en mettre assez pour transmettre « objectif, entrées/sorties, critères d'acceptation ». Trop fine, elle devient rigide ; trop vague, l'IA devine. Comme pour les six parties d'un bon prompt, visez le juste milieu : précis mais souple.
Q. Le SDD rend-il la revue de code inutile ?
R. Non. La revue humaine reste obligatoire avec le développement piloté par la spécification. Le SDD est un mécanisme pour orienter l'IA dans la bonne direction, pas un outil pour sauter les vérifications. Vous ne livrez en toute sécurité que lorsqu'une personne passe en revue à la fois la spécification et l'implémentation.
