Le spec-driven development, ce qui tient la route

Dans un usage courant d’agent de code, la source de vérité est l’historique de conversation : ce que vous avez dit dans les vingt derniers messages. Cet historique est volatil, non versionné, illisible par un pair, et il disparaît à la fermeture de la session. Le spec-driven development consiste à sortir cette information de la conversation pour la poser dans un fichier structuré, versionné avec le code. Martin Fowler en propose une définition de travail et trois intensités : spec-first (on écrit la spec avant de générer), spec-anchored (on la maintient dans le temps pour guider l’évolution), spec-as-source (le fichier de spec est le seul artefact maintenu, le code étant régénéré avec des en-têtes du type « GENERATED FROM SPEC, DO NOT EDIT »). En équipe, presque tout le monde s’arrête au niveau intermédiaire.

L’origine de la vague est une réaction au vibe coding. Brian Madison, Senior Engineering Manager chez Extend et créateur de BMAD, résume dans son entretien au Tech Lead Journal les trois manques du prompting improvisé : pas de plan, pas de contexte, pas de prompting discipliné. Sa thèse, tirée d’une année d’expérimentations, est que le vibe coding atteint un plafond fiable, où les gains initiaux sont annulés par la dette technique. La réponse de BMAD est un pipeline complet (brief, PRD, architecture, UX, epics, stories) avant toute génération de code, avec des agents à rôles et des artefacts versionnés dans le dossier docs du repo.

Le mouvement s’est ensuite structuré sous quatre formes distinctes. GitHub Spec Kit opère au niveau de la feature, avec une constitution de projet et cinq phases. OpenSpec, maintenu par Fission AI, opère au niveau du changement, avec des delta specs qui décrivent uniquement ce qui est ajouté, modifié ou retiré. Agent OS ne simule aucune équipe et empile trois couches de contexte (standards de code, produit, spec en cours). Et sous tout cela, AGENTS.md s’est imposé comme le standard de facto du fichier de contexte pour agents, avec plus de 60 000 projets open source et une cession à la Linux Foundation fin 2025.

Un mot sur les chiffres d’adoption, parce qu’ils circulent beaucoup et disent peu. Au 11 juin 2026, les mesures de Ry Walker donnent Spec Kit à 111 000 étoiles (v0.10.2, plus de 30 agents supportés), OpenSpec à environ 54 000 (v1.4.1 du 3 juin) et BMAD à environ 49 000 (v6.8.0 du 25 mai). Six semaines plus tôt, notre veille relevait 87 500, 39 500 et 44 400. Une étoile mesure une intention de regarder, pas un usage en équipe, encore moins une rétention à six mois. Tout ce qui suit s’appuie sur des mesures d’usage, pas sur ce classement.

BMAD joue au niveau projet, et c’est le plus ambitieux comme le plus lourd. La v6 introduit une planification dite scale-adaptive, qui ajuste la profondeur à la complexité, et trois tracks : Quick Flow pour les bugs et petites features, BMad Method pour les produits de 10 à 50 stories et plus, Enterprise pour le multi-tenant et la conformité. Le noyau agile compte une douzaine d’agents et plus de 34 workflows, jusqu’à 21 agents en combinant les modules. Un choix de design mérite d’être souligné : les artefacts atterrissent dans le dossier docs du repo, versionnés avec Git, et non dans une arborescence propriétaire, ce qui les rend lisibles et modifiables par l’équipe humaine. La documentation officielle détaille les trois tracks.

GitHub Spec Kit joue au niveau de la feature : une constitution de projet qui porte les principes, puis specify, plan, tasks, implement, avec un marquage explicite des zones d’incertitude via des mentions « NEEDS CLARIFICATION ». La distribution GitHub lui donne une visibilité que personne d’autre n’a dans la catégorie. Son point faible est documenté et chiffré, on y revient en détail plus bas : la phase de plan génère beaucoup de markdown, et les templates génériques demandent une personnalisation manuelle pour du brownfield, ce que le REX d’EPAM sur une codebase existante confirme en pratique.

OpenSpec joue au niveau du changement et affiche l’empreinte la plus légère du panel. Chaque évolution est une proposition validée avant qu’une ligne de code ne bouge, et la spec est un delta (ADDED, MODIFIED, REMOVED) fusionné ensuite dans un document de référence. C’est le seul du panel conçu explicitement pour le brownfield, et le mieux noté du benchmark de référence. Deux réserves à connaître : il n’y a pas de mécanisme d’exécutabilité, les specs restent des artefacts documentaires et non des contrats vérifiables, et le projet est très concentré sur un seul contributeur (504 contributions pour le mainteneur principal, 3 pour le suivant).

Agent OS, enfin, ne joue pas au même jeu et c’est ce qui le rend instructif. Trois couches de contexte, aucune équipe d’agents simulée, et surtout une v3 sortie en janvier 2026 qui a retiré l’écriture de spec de ses propres commandes. La documentation de migration est explicite : « Instead of Agent OS commands handling spec writing, we defer to Plan Mode in Claude Code (or Cursor, or any agent with plan mode). This is the industry-standard approach to spec-driven development in 2026+ », au motif que le plan mode, l’extended thinking et les modèles récents absorbent une grande partie du scaffolding que les versions précédentes fournissaient. Ce qui reste tient en deux commandes, des questions ciblées alignées sur les standards et l’injection de ces standards dans n’importe quel contexte.

Le corpus est riche en récits enthousiastes et pauvre en mesures. Une exception : le benchmark d’Itzhak Eretz Kdosha, senior software engineer chez Palo Alto Networks, publié en avril 2026. Le protocole est propre : la même feature backend brownfield en Python serverless, le même IDE (Cursor avec Claude Sonnet 4.5), quatre configurations, treize dimensions notées de 1 à 5, de la conception haut niveau jusqu’à la pull request. Résultats : OpenSpec 4,00 sur 5 pour environ 1,1 jour et 95 dollars, BMAD Quick 3,74, BMAD Full 3,65 pour environ 6 jours et 200 dollars, Spec-Kit 2,77 pour environ 1,2 jour et 75 dollars.

Le verdict de l’auteur est le point à retenir, plus que le classement : aucun des trois frameworks n’est prêt pour une adoption en grande entreprise sans modification. La direction générale, BMAD nettement plus lourd que Spec-Kit et OpenSpec, est corroborée par plusieurs comparatifs indépendants, dont Reenbit, une analyse comparative sur dev.to et le dépôt de recherche spec-compare, qui couvre six outils. Il faut lire ces scores pour ce qu’ils sont : un évaluateur unique, une feature unique, ses priorités à lui. Un point de mesure daté, pas un classement universel.

Le second chiffre décisif vient de Scott Logic, où Colin Eberhardt, CTO, a mis Spec Kit à l’épreuve sur une feature de 689 lignes. La phase de plan a produit 2 067 lignes de markdown, soit 3,5 heures de relecture humaine pour 33 minutes d’exécution, contre 8 minutes d’exécution et 15 minutes de revue avec du prompting itératif discipliné. Environ 10 fois plus rapide sans SDD, et aucun bénéfice qualitatif constaté sur ce cas. Le critère de gouvernance qui en découle est transposable partout : le ratio entre le markdown généré à relire et la valeur produite doit gouverner l’adoption de toute pratique spec-driven sur une équipe en delivery.

Deux affirmations qui circulent beaucoup ont été explicitement réfutées lors de notre vérification adversariale de juillet, il faut cesser de les reprendre. La première, selon laquelle les outils SDD seraient conçus pour le greenfield et mal adaptés au brownfield d’entreprise : OpenSpec est explicitement pensé brownfield, BMAD dispose d’un workflow document-project, et EPAM documente un usage de Spec Kit sur codebase existante. La seconde, selon laquelle une v6 de BMAD encore en alpha signalerait un manque de maturité : réfutée également. Notre lecture : les vrais problèmes de ces frameworks sont ailleurs, dans le coût de relecture et dans la qualité du cadrage humain.

Le sharding était la technique signature de BMAD. Elle consistait à découper les gros documents (PRD, architecture) en fichiers séparés par titre de niveau 2, avec un index en table des matières, pour que chaque story de développement n’embarque qu’un contexte réduit. En v4, c’était une étape standard du workflow, présentée comme l’insight central de la méthode, et les masterclasses officielles insistaient dessus. C’est encore ce que décrit la moitié du contenu disponible en ligne sur BMAD.

Aujourd’hui, la documentation officielle de BMAD marque le sharding « Deprecated », avec ce texte : « This is no longer recommended, and soon with updated workflows and most major LLMs and tools supporting subprocesses this will be unnecessary ». Il n’est plus conseillé qu’en dernier recours, si la combinaison outil plus modèle échoue à charger l’ensemble des documents. Côté communauté, l’issue GitHub #892 est encore plus directe (« Sharding does not save any context »), et des signalements d’échecs remontent à mai 2025 sur du markdown imbriqué et des diagrammes mermaid.

La leçon dépasse largement BMAD, et c’est pour cela qu’elle mérite d’être posée en clair : ne bâtissez pas un standard documentaire maison sur une technique que son propre créateur vient d’abandonner en quelques mois. Ce qui a tué le sharding n’est pas une erreur de conception, c’est l’arrivée des sous-processus et des fenêtres de contexte qui rendent le découpage mécanique inutile. Les standards de ce domaine bougent au rythme des capacités des modèles, pas au rythme des cycles de gouvernance interne, et le même mécanisme jouera sur d’autres briques de ces frameworks.

Une nuance de méthode, indispensable pour lire correctement le corpus : la dépréciation vaut pour la v6 actuelle. Les retours d’expérience de l’ère v4, qui vantent le sharding, ne sont pas malhonnêtes, ils sont datés. C’est le risque principal du sujet, et il vaut pour tout ce dossier : avant de reprendre une pratique lue quelque part, vérifiez la version du framework à laquelle elle se rapporte.

Une fois retirés le sharding, la cérémonie et les vingt et un agents, que reste-t-il ? Une chose, et elle est solide : le fichier de spec versionné dans le repo remplace le contexte conversationnel volatil. Le REX de Brian Spann, sur environ neuf mois d’usage et quatre projets nommés, le formule mieux que n’importe quelle documentation : « Spec files give Claude Code something persistent to anchor to ». Les fichiers de specs et de stories donnent à l’agent un ancrage stable qui réduit la dérive entre sessions. Il rapporte des features qui demandaient deux ou trois sessions et se terminent en une seule, gain anecdotique et non quantifié, à prendre comme tel.

Cette pratique s’appuie sur un constat technique très bien établi, lui : le context rot. Anthropic l’écrit sans détour : « as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases ». Chroma l’a corroboré indépendamment sur 18 modèles frontier, avec des scores qui passent de plus de 95 % à environ 60 à 70 % en contexte long avec distracteurs. Réduire le contexte documentaire d’un agent n’est donc pas une économie de tokens, c’est une condition de fiabilité. Une spec courte, ciblée et à jour bat un historique de 200 000 tokens, même quand la fenêtre technique le permettrait.

La contrepartie est documentée par les issues officielles de BMAD, et elle est sévère. L’empilement specs plus architecture plus stories consomme lui aussi la fenêtre très vite : les issues #1235 et #1343 documentent 80 000 à 100 000 tokens sur une seule étape de création de story, et des agents consommant plus de 67 % d’une fenêtre de 200 000 tokens dès leur activation ; l’issue #511 pose la question du coût en tokens depuis plus longtemps encore. La v6 mitige spécifiquement cette pression. Le paradoxe est frontal : le framework censé résoudre la perte de contexte peut la provoquer par accumulation d’artefacts.

La brique la moins chère, et celle par laquelle il faut commencer, reste AGENTS.md : plus de 60 000 projets open source, plus de 20 outils qui le lisent nativement, cédé à la Linux Foundation. Une étude empirique sur 2 303 fichiers de contexte dans 1 925 dépôts montre ce qu’on y met vraiment : tests 75 %, implémentation 69,9 %, architecture 67,7 %, commandes de build 62,3 %, mais sécurité et performance seulement 14,5 % chacune. Deux angles morts massifs, à combler explicitement dans votre gabarit. La même étude montre que ces fichiers se comportent comme des artefacts de configuration vivants : 59 à 67 % sont modifiés sur plusieurs commits, avec un intervalle médian de mise à jour d’environ un jour.

La première, et la plus dérangeante, vient d’INNOQ, sous la plume de Daniel Westheide en mars 2026. Son argument : la couche de spécification dépend entièrement de la qualité de la connaissance domaine que l’humain apporte à l’interview, et l’agent analyst « cannot supply domain knowledge that isn’t in the room ». Le proxy problem bien connu du Domain-Driven Design frappe le spec-driven development à l’identique : quand les experts métier sont derrière des product owners proxy, l’information se perd en traduction, et aucune quantité d’elicitation avancée ne la reconstruit. Sa conclusion est sans appel : « If your organisation can’t do DDD properly, it can’t benefit from BMAD’s specification layer either ». C’est ce que les praticiens appellent structurer le flou, un mauvais cadrage initial ne produit pas moins de livrables, il en produit beaucoup, très vite, dans la mauvaise direction.

La seconde critique est le retour du cycle en V. Écrire des specs détaillées avant de coder, c’est précisément ce que l’industrie a abandonné en passant à l’agile, et Marmelab l’a formulé dès novembre 2025. La contre-argumentation la plus honnête est que le waterfall n’a pas échoué parce que les specs étaient mauvaises, mais parce que le coût de découvrir qu’une spec était fausse se comptait en mois, là où la boucle de retour avec un agent se compte en minutes. Cette réponse tient. Elle ne dit rien du second problème, qui reste entier : une spec et une implémentation, ce sont deux choses à maintenir synchrones, et le coût de synchronisation ne disparaît pas.

Le signal le plus intéressant de l’été est ailleurs, dans le comportement des frameworks eux-mêmes. Thoughtworks a retiré le spec-driven development de son radar en tant que technique, non par désintérêt mais parce que le sujet s’est fragmenté en outils concrets, et place désormais OpenSpec en anneau Assess dans le Technology Radar vol. 34 d’avril 2026, en assortissant sa fiche d’une mise en garde explicite : à mesure que les modèles et les agents de code gagnent en puissance, les équipes doivent surveiller les capacités natives et réévaluer le besoin d’outillage SDD. Agent OS avait fait exactement ce mouvement trois mois plus tôt en confiant l’écriture de spec au plan mode. La trajectoire est nette : les frameworks reculent au fur et à mesure que les agents avancent, et ce qui reste dans leur périmètre, ce sont les artefacts et la gouvernance, pas la mécanique.

Ce dossier ne recommande d’adopter aucun de ces quatre frameworks en bloc. Le verdict du benchmark de référence est clair, aucun n’est prêt pour l’entreprise sans adaptation, et l’histoire du sharding montre à quelle vitesse une brique emblématique peut tomber. La stratégie qui tient, et c’est celle qu’on applique en mission, consiste à extraire les pratiques transposables plutôt qu’à importer un framework entier. Trois d’entre elles valent l’investissement, dans cet ordre.

D’abord, poser des AGENTS.md ou CLAUDE.md par repo, traités comme des artefacts vivants mis à jour en continu, avec un gabarit qui inclut explicitement la sécurité et la performance, les deux angles morts mesurés dans l’étude sur 2 303 fichiers. Coût faible, standard de facto, aucun verrou fournisseur. Ensuite, sortir les specs de la conversation et les versionner dans le dossier docs, revues en pull request au même titre que le code : c’est le cœur transposable de BMAD, et le seul élément que tous les REX du corpus valident. Avec une discipline non négociable, quelqu’un doit être responsable de la mise à jour de la spec quand le code change, sans quoi elle devient un piège, encore chargée par les agents alors qu’elle ment. Enfin, garder la revue adversariale des specs, que le benchmark crédite de détecter des problèmes qu’une revue classique manque, avec des faux positifs à filtrer : elle ne coûte qu’un prompt et n’exige aucun framework.

Pour ceux qui veulent quand même de l’outillage, une règle de décision simple : éprouvez-le sur un ou deux tickets réels avant tout déploiement, en passant le même ticket deux fois, une fois avec le framework, une fois en prompting itératif discipliné, puis comparez le temps, le coût en tokens et le volume de markdown à relire. Si vous cherchez le point de départ le plus léger sur une codebase existante, OpenSpec est le mieux noté du benchmark et le seul que Thoughtworks ait mis en Assess. Si votre contexte est un greenfield complexe ou fortement régulé, où la traçabilité des décisions a une valeur propre, BMAD Full se défend, mais il faut assumer les six jours et les 200 dollars de la mesure de référence, et vérifier d’abord que vos experts métier sont réellement dans la pièce.