- Le Spec-Driven Development (SDD) remet au goût du jour une approche de type waterfall fondée sur la rédaction d’une documentation volumineuse avant de coder. Elle vise à structurer le travail pour les outils d’assistance au code par IA, mais risque de nuire à l’agilité
- La communauté open source a développé des outils qui génèrent automatiquement spécifications, plan d’implémentation et liste de tâches à partir d’un prompt initial et d’instructions, notamment Spec-Kit, Kiro, Tessl et la méthode BMad
- Mais à l’usage, plusieurs limites apparaissent, comme le manque de compréhension du contexte, la surdocumentation, la double revue de code ou un faux sentiment de sécurité. Sur de grandes bases de code, l’efficacité chute fortement
- L’article estime que le SDD, en cherchant à remplacer les développeurs, reproduit l’échec du modèle waterfall, et propose à la place une méthode de développement itérative fondée sur le langage naturel
- Une approche combinant les principes Agile et Lean Startup serait plus adaptée au développement moderne avec des agents de code, et la prochaine étape serait l’évolution des outils d’interaction visuelle
L’émergence du développement piloté par les spécifications (SDD)
- Le Spec-Driven Development (SDD) introduit un processus de rédaction de documents de spécification avant le code afin de fournir une méthode de développement structurée aux outils d’assistance au code par IA
- À partir d’un prompt initial et d’instructions, le LLM génère spécification produit, plan d’implémentation et liste de tâches
- Chaque document dépend de l’étape précédente, et l’utilisateur les révise pour affiner la spécification
- Les documents finalisés sont ensuite transmis à des agents de code comme Claude Code, Cursor et Copilot pour servir à l’écriture du code
- Parmi les outils représentatifs figurent Spec-Kit de GitHub, Kiro d’AWS, Tessl et la méthode BMad (BMM)
- L’analyse comparative Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl de Birgitta Böckeler est également mentionnée
Les problèmes de la documentation Markdown
- Les spécifications SDD prennent le plus souvent la forme de fichiers Markdown. À titre d’exemple, une implémentation simple réalisée avec GitHub Spec-Kit représente 8 fichiers et 1 300 lignes
- Avec Kiro, le cas d’ajout du champ « referred by » dans Atomic CRM est lui aussi réparti en de nombreux documents
- En pratique, les défauts suivants apparaissent
- Manque de compréhension du contexte (Context Blindness) : l’outil rate le contexte du code ou des fonctions existantes, ce qui impose toujours une revue experte
- Folie du Markdown (Markdown Madness) : la longueur des documents fait perdre beaucoup de temps, même pour repérer des erreurs simples
- Bureaucratie systématique (Systematic Bureaucracy) : répétitions inutiles et niveau de détail excessif génèrent de l’inefficacité
- Faux Agile (Faux Agile) : mauvais usage du concept de « User Story », qui rend l’ensemble confus
- Double revue de code (Double Code Review) : il faut vérifier à la fois le code présent dans les spécifications et l’implémentation réelle
- Faux sentiment de sécurité (False Sense of Security) : les agents ne suivent pas forcément les spécifications à la lettre
- Rendement décroissant (Diminishing Returns) : utile sur des projets au démarrage, mais de plus en plus lent à mesure que l’échelle augmente
- Comme la plupart des agents de code proposent déjà un plan mode et des fonctions de liste de tâches, l’apport supplémentaire du SDD reste limité et peut au contraire augmenter les coûts de développement
La revanche du chef de projet
- Les limites du SDD peuvent venir en partie de l’immaturité des outils, mais elles proviennent surtout d’un problème mal posé
- L’objectif implicite est de « retirer les développeurs du développement logiciel »
- La structure vise à remplacer les développeurs par des agents de code, puis à contrôler ces derniers par une planification détaillée
- Cette logique ressemble au modèle waterfall, dans lequel une documentation massive réduit le développeur à un simple rôle de traducteur
- Or le développement logiciel est un processus non déterministe (non-deterministic), et la planification ne suffit pas à supprimer l’incertitude (avec référence à l’article No Silver Bullet)
- Le SDD exige à la fois l’expertise d’un business analyst au stade des besoins et celle d’un développeur au stade de la conception. En pratique, seuls quelques profils capables d’assurer les deux rôles peuvent réellement l’utiliser
- Au final, comme les outils No Code, il promet un « développement sans développeurs », tout en finissant par nécessiter des développeurs
Une nouvelle alternative : le développement itératif en langage naturel
- La méthodologie Agile résout le problème du développement non déterministe en privilégiant l’adaptabilité plutôt que la prévisibilité
- Pour exploiter efficacement des agents de code, l’essentiel est de découper les exigences complexes en plusieurs problèmes simples
- L’article propose une procédure d’itération simple fondée sur les principes du Lean Startup
- Identifier l’hypothèse la plus risquée du produit
- Concevoir l’expérience minimale pour la valider
- Développer l’expérience puis itérer selon les résultats
- Exemple à l’appui : avec Claude Code, un outil de sculpture 3D (sculpt-3D) a été développé en environ 10 heures
- Sans spécifications formelles, les fonctionnalités ont été ajoutées progressivement à partir de consignes courtes
- Les implémentations erronées ont été corrigées immédiatement, permettant des itérations rapides
- Cette approche permet une convergence rapide sans documentation de type waterfall, et la combinaison d’Agile et des agents de code rend possible la construction de produits en temps réel
- En revanche, les agents de code restent centrés sur le texte et manquent d’interaction visuelle ; il faudra donc à l’avenir développer des outils renforçant les interfaces visuelles
Conclusion
- La méthodologie Agile avait déjà rendu les documents de spécification largement superflus, et le SDD est présenté ici comme une tentative de les ressusciter
- Le SDD, en tant qu’approche théorique cherchant à écarter les développeurs, fait manquer une occasion de renforcer les capacités d’une nouvelle génération de développeurs grâce aux agents de code
- Les agents de code sont comparés à un moteur à combustion interne : là où le SDD les enferme dans la logique de la locomotive, il faudrait les déployer sous des formes variées, comme l’automobile ou l’avion
- Enfin, si l’on tient compte de l’environnement, un usage mesuré des agents de code reste nécessaire
1 commentaires
Avis Hacker News
En tant que développeur, le plus grand gain de productivité que j’ai obtenu vient du fait d’avoir pris l’habitude de tout planifier à l’avance
À chaque ticket reçu, je le découpe en une grande liste de TODO pour clarifier dès le départ la conception, les dépendances et les spécifications
Cela me permet d’entrer plus souvent en état de flow quand je programme
Si cette approche fonctionne aussi pour les agents de codage IA, c’est parce qu’elle externalise le raisonnement en amont
J’ai détaillé cela dans mon article
En pratique, découper un problème et rédiger des spécifications est une bonne chose
Le vrai problème, ce sont les spécifications immuables. Si l’implémentation ne commence que plusieurs mois plus tard, les specs se figent
À l’inverse, Agile sert souvent d’excuse pour repousser la planification stratégique. Résultat : beaucoup de retravail
Au final, c’est une question d’équilibre, et je pense que « It depends » est une bonne devise aussi bien pour la vie que pour le développement
Si un LLM gère les specs, cela pourrait avoir l’avantage de réduire la charge de maintenance
L’article en question est ici
Quand les prévisions sont difficiles, on commence par un spike pour explorer le code et les bibliothèques
On produit à la fois un schéma idéal et un schéma tenant compte des contraintes réelles, afin d’éviter à long terme les pièges architecturaux
Après quelques mois de vibe coding, je suis passé ces 6 derniers mois au spec-driven development
Je passe 2 à 3 heures par jour à rédiger des specs, puis je déploie dans la journée des fonctionnalités testées
Écrire des specs ne m’a pas rendu moins agile. Au contraire, cela permet des itérations rapides sur des cycles de 8 heures
Les specs ne sont pas des prompts, mais des critères de validation de l’exactitude
Des tests end-to-end bien définis réduisent fortement les erreurs de l’IA
Le résultat change à chaque exécution et, au final, il faut de toute façon une validation humaine, ce qui peut être inefficace
Appeler « spec » une tâche d’une journée prête à confusion. Au fond, c’est juste l’ancien processus avec un nouveau nom
Ils interprètent souvent mal même des formules logiques simples, donc leur faire comprendre des specs en langage naturel est risqué
Je la donne ensuite à l’agent, qui implémente le tout tout seul, et moi je ne fais que vérifier de temps en temps
Pendant que l’IA travaille, moi je bricole ma voiture de course, donc c’est gagnant-gagnant
Au final, la seule chose importante, c’est que le code passe les tests
Cet article semble s’adresser à des gens qui ont déjà conclu que le « spec-based development n’est pas pour eux »
Pour moi, une spec est un point d’entrée contextuel pour le LLM
Si on fournit suffisamment d’éléments sur la structure du projet, les modèles, les fonctions et les exigences, le LLM comprend le contexte et peut l’étendre
En plus, si on laisse le LLM mettre lui-même à jour les specs, cela permet aussi des itérations Agile
Les tests servent de point d’ancrage au réel pour le LLM et évitent les hallucinations
Les tests sont à la fois de la documentation et un critère de qualité, et il faut gérer le LLM comme un développeur junior
On peut faire tourner plusieurs agents en parallèle et les faire se valider mutuellement via une couche de tests, avec des résultats étonnants
Grâce aux LLM, on peut simplement itérer l’ensemble des specs plus vite et à moindre coût, mais le principe reste le même
Des specs trop longues finissent au contraire par freiner la pensée exploratoire
Les LLM ne sont pas des systèmes déterministes mais probabilistes, donc nous devons désormais déboguer des specs plutôt que du code
Les développeurs doivent maintenant évoluer vers un rôle d’architecte de systèmes cognitifs
Il existe à la fois des specs de haut niveau et des specs détaillées de composants
J’ai essayé de créer un outil CLI avec Spec-Kit de GitHub, mais cela demandait beaucoup trop de corrections, analyses et réécritures
C’était frustrant par manque de feedback itératif, un peu comme en waterfall
Au final, au lieu d’essayer de comprendre pourquoi le code était mauvais, il valait mieux repartir de zéro
J’aime coder avec des LLM, mais le SDD m’a semblé être un workflow lourd et inefficace
Les LLM aiment le contexte, donc il faut les guider de façon répétée et explicite
Par exemple, quand on crée une app NextJS, il faut décrire clairement la connexion, le RBAC, l’implémentation pilotée par les tests, etc.
Il vaut mieux partir de petites unités puis ajouter les fonctionnalités progressivement
Le problème du waterfall, c’était les temps de cycle longs et le coût élevé des itérations
Avec le SDD, ces deux points sont réglés, donc je pense que ça va
Appeler waterfall des specs écrites en quelques heures, c’est exagéré
Si on entre trop vite dans un espace de solution complexe, il devient difficile de résoudre simplement le problème
Agile commence dans un petit espace puis l’élargit progressivement
Si elle est suffisamment détaillée, l’itération ralentit ; si elle ne l’est pas assez, le LLM ne fonctionne pas correctement
Au final, on retrouve la contradiction du waterfall appréciée des managers
Les LLM donnent les meilleurs résultats quand on leur fournit des instructions claires sur de petites unités
Elles rédigeront des specs sur plusieurs années, lanceront un LLM tous les 6 mois, puis rejetteront la faute sur les développeurs si ça échoue
C’est l’auteur du billet
Je trouve toujours intéressant de voir à quel point le débat waterfall vs agile reste vif
Lire le parcours de ceux qui trouvent de la valeur au SDD est aussi amusant
Mais j’utilise déjà un mode Plan avant l’implémentation, donc le SDD ne m’apporte pas vraiment de valeur supplémentaire
Il est aussi très rare qu’un agent de codage réalise parfaitement une implémentation du premier coup
Comme il faut de toute façon itérer, l’idée de Big Design Up Front perd son sens
En revanche, je crois que les agents de codage ouvrent bien un nouveau paradigme de développement
Cela m’a rappelé cette vidéo que j’avais vue autrefois
On y parlait de ce que les ingénieurs et les programmeurs pouvaient apprendre les uns des autres, et l’importance de la planification en amont m’avait marqué
On dit qu’Agile a tué les documents de spécification, mais en réalité il les a simplement découpés en des milliers de tickets Jira
L’IA peut enregistrer tous ces choix dispersés et ce contexte, puis poser des questions quand cela contredit des décisions passées
Elle pourrait donner des retours du type : « La raison pour laquelle Jim a écrit ce code ainsi il y a 5 ans est-elle toujours valable ? »
Cet article m’a semblé un peu étrange
Recevoir des specs incomplètes et résoudre le problème par essais-erreurs, c’est la même chose pour un développeur humain ou une IA
Si on sait clairement ce qu’on veut, il faut donner des instructions détaillées
Le fond de l’article parle peut-être en réalité de « mauvaises specs »
Globalement, cela ressemble surtout à une logique d’autodéfense de l’industrie Agile
J’ai testé le SDD avec plusieurs fichiers de specs Markdown, et ce qui s’est révélé vraiment efficace, c’était ** beads**
Cela permet à l’agent de se concentrer en suivant un arbre de tâches
Chaque tâche est découpée en TDD, et l’agent ne peut pas passer à l’étape suivante tant que les tests ne sont pas validés
L’agent va même jusqu’à indiquer les commandes de revue, ce qui facilite le code review
Spec-Kit est beaucoup trop lourd, donc beads est bien plus pratique
Le projet zmx, créé entièrement en mode vibe, a lui aussi été entièrement réécrit plus tard en s’appuyant sur le code de l’agent