Faut-il un framework pour faire du spec-driven development ?

C'est faire d'un document écrit et versionné avec le code, la spec, la référence de l'agent qui code, à la place de l'historique de la conversation. Birgitta Böckeler, de Thoughtworks, en distingue trois niveaux, de la spec écrite avant de coder à la spec qui devient le seul fichier qu'on modifie.

Avec un agent de code, la référence est d'ordinaire la conversation : ce que vous avez dit dans les derniers messages. Elle ne se versionne pas, un collègue ne la relit pas, et elle reste enfermée dans la session. Le spec-driven development sort cette information de la conversation pour la poser dans un fichier structuré, rangé avec le code.

Trois niveaux

Dans un article publié le 15/10/2025 sur le site de Martin Fowler, Birgitta Böckeler distingue trois niveaux :

• spec-first : la spec est écrite d'abord, puis sert à la tâche en cours ;
• spec-anchored : la spec est gardée après la tâche, pour faire évoluer et maintenir la fonctionnalité ;
• spec-as-source : seule la spec est modifiée, l'humain ne touche plus au code ; chez l'outil Tessl, le code généré porte la mention « GENERATED FROM SPEC - DO NOT EDIT ».

Selon elle, toutes les approches qu'elle a trouvées sont au moins spec-first, mais toutes ne visent pas les deux autres niveaux. Spec Kit, par exemple, crée une branche par spec : elle en déduit que la spec y vit le temps d'une demande de changement. Aucune source ne mesure combien d'équipes s'arrêtent à chaque niveau.

Une réaction au vibe coding

La vague est née en réaction au vibe coding, le code écrit au fil des prompts, sans plan. Brian Madison, responsable d'ingénierie chez Extend et créateur de BMAD, raconte au Tech Lead Journal, en avril 2026, comment une année d'expérimentations l'a convaincu qu'on finit par se heurter à un mur. Sa réponse : un parcours complet (brief, PRD, architecture, UX, epics, stories) avant de générer du code, mené par des agents à rôles.

Ils ne travaillent pas à la même échelle. BMAD organise tout un projet avec une équipe d'agents, Spec Kit une fonctionnalité, OpenSpec un changement, et Agent OS fournit des standards en laissant l'écriture de la spec au mode plan de l'agent. AGENTS.md, le fichier de contexte que lisent la plupart des agents, leur sert de socle commun.

BMAD, le projet entier

BMAD est le plus ambitieux et le plus lourd. Sa v6, stable depuis février 2026, ajuste la planification à la taille du projet, avec trois parcours : Quick Flow pour les corrections et les petites fonctionnalités, BMad Method pour les produits de 10 à 50 stories et plus, Enterprise pour la conformité et le multi-tenant. Ses agents (chef de produit, architecte, développeur, UX) écrivent PRD, architecture et stories dans un dossier du projet, que l'équipe peut versionner et relire.

GitHub Spec Kit, la fonctionnalité

Spec Kit part d'une constitution du projet, qui porte ses principes, puis enchaîne specify, plan, tasks et implement pour chaque fonctionnalité, en marquant les zones floues d'un « NEEDS CLARIFICATION ». Il fonctionne avec plus de 30 agents de code et profite de la diffusion de GitHub. Son point faible, mesuré plus bas, est la quantité de markdown qu'il génère ; Thoughtworks note que l'adapter aide, par exemple pour limiter le nombre de fichiers.

OpenSpec, le changement

OpenSpec, maintenu par Fission AI, travaille au niveau du changement. Chaque évolution est une proposition validée avant de toucher au code ; la spec décrit seulement ce qui est ajouté, modifié ou retiré, puis rejoint la spec de référence à l'archivage. Il se présente comme pensé pour les bases de code existantes. Deux réserves, relevées par Ry Walker : ses specs restent des documents, sans moyen de les vérifier automatiquement, et le projet reposait en juin 2026 sur un seul mainteneur (504 commits, contre 3 pour le suivant).

Agent OS, les standards

Agent OS ne simule aucune équipe d'agents : il fournit des standards de code, une description du produit et la spec en cours. Sa version 3, sortie en janvier 2026, a retiré l'écriture de spec de ses propres commandes : « 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+ ». Selon son éditeur, Builder Methods, le mode plan, la réflexion étendue et les modèles récents font désormais une grande partie de ce que l'outil fournissait.

AGENTS.md, le socle commun

Sous ces outils, AGENTS.md est devenu le fichier de contexte de référence des agents de code. Publié par OpenAI en août 2025 et utilisé par plus de 60 000 projets open source, il a été confié en décembre 2025 à l'Agentic AI Foundation, créée au sein de la Linux Foundation (communiqué du 09/12/2025). Claude Code lit son équivalent, CLAUDE.md.

Les étoiles ne mesurent pas l'usage

Les chiffres d'adoption circulent beaucoup et disent peu. Au 11/06/2026, Ry Walker, dirigeant de Tembo, une plateforme d'agents de code, relevait 111 000 étoiles GitHub pour Spec Kit, environ 54 000 pour OpenSpec et environ 49 000 pour BMAD. Une étoile dit qu'on a regardé un dépôt ; elle ne dit rien d'une équipe qui s'en servirait six mois plus tard. Ce carnet s'appuie sur les rares usages mesurés.

Peu de choses. Le comparatif le plus détaillé de notre corpus, qui publie ses notes et sa méthode, conclut qu'aucun outil n'est prêt pour une grande entreprise sans adaptation. Le retour chiffré de Scott Logic montre où part le temps : dans la relecture des documents que l'outil génère.

Un comparatif, un évaluateur

Itzhak Eretz Kdosha, ingénieur chez Palo Alto Networks, a publié le 13/04/2026 sur le blog Ran the Builder un comparatif mené en février 2026. Il a ajouté la même fonctionnalité à un service Python existant, avec le même éditeur de code (Cursor) et le même modèle (Claude Sonnet 4.5), dans quatre configurations notées sur treize critères de 1 à 5 :

• OpenSpec : 4,00 sur 5, trois heures de planification et une journée d'implémentation, 95 dollars ;
• BMAD en version rapide : 3,74, cinq heures et une journée et demie, 85 dollars ;
• BMAD complet : 3,65, deux jours et quatre jours, 200 dollars ;
• Spec Kit : 2,77, quatre heures et une journée, 75 dollars.

Son verdict : aucun de ces outils n'est prêt pour une adoption en grande entreprise sans modification, au moment où il les a évalués, dans un domaine qui bouge vite. Il juge que la vitesse et le coût des trois configurations légères se valent (« les différences sont du bruit ») ; seul BMAD complet coûte nettement plus. Il prévient que ses notes suivent ses propres exigences, et les versions testées ont été remplacées depuis.

D'autres comparatifs vont dans le même sens, BMAD plus lourd que les deux autres, avec moins de rigueur. Celui de Reenbit, une société de services, donne des durées sur une même tâche (12 minutes avec OpenSpec, 90 avec Spec Kit, 5 h 30 avec BMAD) sans dire comment il les a mesurées ; celui de William Torres sur dev.to et le dépôt spec-compare analysent la documentation des outils.

Le temps part dans la relecture

Colin Eberhardt, directeur technique de la société de conseil Scott Logic, a refait avec Spec Kit une fonctionnalité de son application personnelle. Sur le premier incrément, l'agent a travaillé 33 minutes et lui a demandé 3 h 30 de relecture, dont deux heures sur le seul plan. Sans spec, par petites itérations, il a obtenu toute la fonctionnalité (environ 1 000 lignes) avec 8 minutes d'agent, 15 minutes de revue de code et 9 minutes de tests.

Il s'estime « environ dix fois plus rapide » sans Spec Kit, avec un code sans bug là où Spec Kit en laissait un, et ne voit aucun bénéfice qualitatif qui justifie le surcoût. Une réserve qu'il donne lui-même : il avait déjà codé cette fonctionnalité, ce qui lui a permis d'écrire une spec sans ambiguïté.

Notre lecture : sur une équipe qui livre, le chiffre à suivre est le volume de markdown à relire au regard de ce qu'il apporte. Faute de seuil publié, il se mesure sur vos propres tickets.

Parce que son guide jugeait que les sous-processus des agents et des modèles le rendraient bientôt inutile. BMAD a marqué « Deprecated » en février 2026 le découpage de ses gros documents en fichiers, étape du parcours standard de sa v4, puis l'a retiré en août sans remplaçant.

Le sharding consistait à découper les gros documents de BMAD (le PRD, l'architecture) en fichiers séparés, un par titre de niveau 2, avec un index, pour que chaque story n'embarque qu'une partie du contexte. Dans la v4, c'était une étape du parcours standard, activée par défaut, puis rendue optionnelle en juin 2025.

En février 2026, le guide de BMAD l'a marqué « Deprecated » : « This is no longer recommended, and soon with updated workflows and most major LLMs and tools supporting subprocesses this will be unnecessary ». Il ne le conseillait plus que si l'outil et le modèle échouent à charger tous les documents. La version 6.11.0 du 10/08/2026 a retiré l'outil de découpage et sa page, sans remplaçant.

La leçon dépasse BMAD : ne bâtissez pas un standard documentaire maison sur une technique que son créateur abandonne en quelques mois. BMAD l'a écartée en prévoyant que les sous-processus des agents la rendraient inutile ; ses notes de version d'août ne donnent pas d'autre raison. Notre lecture : les pratiques de ce domaine suivent les capacités des modèles plus vite que les cycles de gouvernance interne.

Une nuance pour lire ce qu'on trouve en ligne : les retours d'expérience de la v4, qui vantent le sharding, sont datés. Avant de reprendre une pratique lue quelque part, vérifiez la version du framework dont elle parle. L'idée de charger le contexte par morceaux, elle, reste : les parcours de BMAD sont toujours découpés en étapes.

La spec versionnée dans le dépôt : un fichier que chaque session de l'agent relit à l'identique et qu'un collègue relit en pull request. Elle donne à l'agent un ancrage d'une session à l'autre, à condition de rester courte, car un contexte qui gonfle rend l'agent moins fiable.

Un ancrage d'une session à l'autre

Le développeur Brian Spann, qui utilise BMAD avec Claude Code depuis environ neuf mois sur quatre projets, le résume dans son retour d'expérience : « Spec files give Claude Code something persistent to anchor to ». Selon lui, des fonctionnalités qui demandaient deux ou trois sessions se terminent en une. C'est un témoignage, sans mesure, à prendre comme tel.

Pourquoi la spec doit rester courte

Le constat technique, lui, est établi. Anthropic écrit qu'« 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 observé sur 18 modèles : sur des questions posées à une longue conversation, Claude Sonnet 4 en mode réflexion passe de 0,95 à 0,71 de score quand on lui donne toute la conversation (environ 113 000 tokens) plutôt que les passages utiles (environ 300). Sans réflexion, l'écart va de 0,89 à 0,38, et Chroma l'attribue en bonne partie aux réponses où le modèle renonce.

Réduire le contexte d'un agent sert sa fiabilité autant que sa facture. Une spec courte, ciblée et à jour vaut mieux qu'un historique de conversation qui gonfle, même quand la fenêtre de l'outil le permettrait.

La contrepartie

Empiler specs, architecture et stories remplit aussi la fenêtre. Des utilisateurs de BMAD l'ont signalé au début de 2026 : 80 000 à 100 000 tokens par étape d'analyse lors de la création d'une story (issue #1235), plus de 67 % d'une fenêtre de 200 000 tokens occupés dès l'activation, prompt système de Claude Code compris, selon un utilisateur du module de test de BMAD (issue #1343). Les mainteneurs ont promis de répondre par des sous-agents, sans mesure publiée de l'effet.

AGENTS.md, à poser et à mesurer

La brique la moins chère reste le fichier de contexte que l'agent lit à chaque session, AGENTS.md ou CLAUDE.md. Une étude de 2 303 fichiers de ce type dans 1 925 dépôts montre ce qu'on y met : sur 332 fichiers étiquetés à la main, les tests dans les trois quarts, la sécurité et la performance dans un sur sept seulement. La plupart sont modifiés sur plusieurs commits : ce sont des fichiers vivants.

Leur effet, en revanche, reste discuté. Une étude de l'ETH Zurich conclut que ces fichiers n'améliorent pas en général le taux de réussite des agents de code et augmentent le coût d'inférence de plus de 20 % ; ses auteurs les jugent utiles pour décrire des pratiques propres au projet. Un AGENTS.md court, qui dit ce que le code ne dit pas, vaut mieux qu'une présentation générale du dépôt.

Deux. La spec ne vaut que la connaissance du métier qu'on y met, et aucun framework n'en fabrique. Et écrire avant de coder ressemble au retour du cycle en cascade, avec un coût qui ne disparaît pas : garder la spec et le code d'accord.

La connaissance du métier

La première vient de Daniel Westheide, consultant chez INNOQ, dans un billet du 18/03/2026. La couche de spécification de BMAD dépend de ce que l'humain apporte à l'entretien avec l'agent analyste, qui ne peut pas fournir une connaissance du domaine absente de la pièce. Quand les experts métier sont cachés derrière des product owners intermédiaires, l'information se perd en route.

OCTO Technology le dit à sa façon, dans un retour de mission de mars 2026 : « Sans un cadrage solide, BMAD risque de structurer le flou plutôt que de le dissiper ». Un cadrage mal fait produit quand même beaucoup de documents, vite, dans la mauvaise direction.

Le retour du cycle en cascade

La seconde critique, formulée par Marmelab en novembre 2025, voit dans le spec-driven development un retour du waterfall et de la conception exhaustive avant de coder. François Zaninotto y relève une fonctionnalité qui produit huit fichiers et 1 300 lignes de texte, et une double revue, de la spec puis du code.

Notre réponse : le cycle en cascade a échoué parce qu'on découvrait une spec fausse des mois plus tard ; avec un agent, on le découvre en quelques minutes, ce qui change le pari. Elle ne règle pas le second problème : une spec et un code sont deux choses à garder d'accord, et ce coût ne disparaît pas.

Des frameworks qui reculent devant les agents

Notre lecture est que les frameworks reculent devant les agents, et le signal vient d'eux-mêmes. Agent OS a confié l'écriture de la spec au mode plan des agents en janvier 2026, et Thoughtworks, qui place OpenSpec en « Assess » dans son Technology Radar d'avril 2026, comme Spec Kit, conseille dans la même fiche de suivre les capacités natives des agents et de réévaluer le besoin d'outillage.

Thoughtworks juge pourtant OpenSpec agréable à utiliser pour les développeurs : le recul des frameworks reste un pari sur la suite. Ce qui restera aux frameworks, selon nous, ce sont les documents et la façon de les tenir.

Aucun framework en bloc. Nous en gardons trois pratiques, dans cet ordre : un fichier de contexte court par dépôt, des specs versionnées et relues en pull request avec quelqu'un qui les tient à jour, et une relecture contradictoire du code comme des specs.

Le comparatif le plus détaillé de notre corpus ne trouve aucun framework prêt pour une grande entreprise, et l'histoire du sharding montre à quelle vitesse une brique emblématique peut tomber. Ce que nous appliquons en mission consiste à extraire les pratiques qui se transposent plutôt qu'à importer un framework entier :

1. Un fichier de contexte court par dépôt (AGENTS.md ou CLAUDE.md), tenu à jour comme du code. Il dit ce que le code ne dit pas : les commandes, les conventions maison, les exigences de sécurité et de performance, les deux angles morts mesurés dans l'étude des 2 303 fichiers. Pas de présentation générale du dépôt, que l'étude de l'ETH Zurich juge inutile.
2. Des specs sorties de la conversation, versionnées dans le dossier docs et revues en pull request comme le code. C'est le cœur de BMAD qui se transpose. Une discipline va avec : quelqu'un met la spec à jour quand le code change, sinon les agents continuent de la lire alors qu'elle ment.
3. Une relecture contradictoire, par un agent chargé de trouver des problèmes, du code comme des specs. BMAD la décrit et prévient qu'elle produit des faux positifs à trier ; dans le comparatif de février, sa revue de code a attrapé ce qu'une revue standard aurait manqué. Elle coûte une consigne et le temps de trier ce qu'elle remonte. En août, BMAD a remplacé la posture de relecteur « cynique » par l'obligation de trouver au moins dix problèmes précis, qui donnait de meilleurs résultats dans ses essais.

Dans notre groupe, la revue contradictoire d'un plan de développement, sous trois angles (la livraison, les faits, le métier), a produit 42 constats, tous intégrés à la version suivante du plan. Nous n'avons pas mesuré ce qu'une relecture classique en aurait trouvé.

Si vous voulez quand même un outil

Éprouvez-le sur un ou deux tickets réels avant de le déployer : passez le même ticket deux fois, avec le framework et par petites itérations, puis comparez le temps, le coût en tokens et le volume de markdown à relire. Sur une base de code existante, OpenSpec est le mieux noté du comparatif, classé « à explorer » (Assess) par Thoughtworks comme Spec Kit. Sur un projet neuf, complexe ou très réglementé, où la trace des décisions vaut pour elle-même, BMAD complet se défend, à condition d'en assumer le coût et d'avoir les experts métier dans la pièce.

Ce que donne le spec-driven development sur une équipe dans la durée, combien d'équipes gardent un framework après l'essai, l'effet réel des fichiers de contexte, et ce que le mode plan des agents fait mieux ou moins bien que les frameworks.

• Personne n'a mesuré le spec-driven development sur une équipe dans la durée. Le comparatif de février et le retour de Scott Logic portent chacun sur une fonctionnalité et un évaluateur.
• La rétention des frameworks est inconnue. Les étoiles GitHub disent combien de gens ont regardé un dépôt ; personne ne compte les équipes qui s'en servent encore trois sprints plus tard.
• L'effet des fichiers de contexte reste discuté. L'étude des 2 303 fichiers décrit ce qu'ils contiennent ; celle de l'ETH Zurich ne leur trouve pas de gain général, sur des tâches de correction de code open source.
• Ce qu'a changé la fin du sharding n'est pas mesuré. BMAD promettait des sous-agents pour alléger le contexte, sans chiffre publié depuis.
• Le mode plan des agents n'a pas été comparé aux frameworks. Agent OS et Thoughtworks parient sur les capacités natives des agents ; aucun essai ne les met face à face.

Compter les évaluateurs, dater les versions, et savoir qui parle. Presque aucun de ces retours ne mesure : ce sont des essais d'une personne, des signalements d'utilisateurs ou des analyses de sociétés qui vendent leur aide pour déployer ces outils, sur des versions qui ont changé depuis.

• Le comparatif de Ran the Builder et le retour de Scott Logic sont des essais d'une personne sur une fonctionnalité, avec les modèles de l'époque (Claude Sonnet 4.5). L'auteur du comparatif dit lui-même que ses notes suivent ses exigences, et qu'il participe à la conception d'un autre outil du même type, qu'il n'a pas testé ; celui de Scott Logic avait déjà codé la fonctionnalité, et ses deux essais ne couvrent pas le même périmètre.
• Les versions bougent vite. Le comparatif a testé OpenSpec 1.2.0, BMAD 6.0.3 et Spec Kit 0.1.6 ; en juin 2026, Ry Walker relevait OpenSpec 1.4.1, BMAD 6.8.0 et Spec Kit 0.10.2. Les étoiles et les versions de ce carnet datent de juin et n'ont pas été actualisées.
• Une part des sources vend du conseil ou des services autour de ces outils : Reenbit, INNOQ, OCTO Technology, Scott Logic, Marmelab, Thoughtworks, Ran Isenberg, qui héberge le comparatif, et Monsieur Guiz, qui écrit ce carnet. Chacune a intérêt à la lecture qu'elle propose.
• Les chiffres de consommation de BMAD viennent d'utilisateurs qui ont ouvert une issue, sur une version alpha de la v6 ; ils ne sont confirmés par aucune mesure des mainteneurs.
• Le rapport de Chroma, éditeur d'une base de données vectorielle, mesure des tâches simples et contrôlées, loin du travail d'agent en entreprise ; son résultat sert aussi les outils de recherche qu'il vend.
• Les retours de la v4 de BMAD décrivent des pratiques que la v6 a abandonnées, comme le sharding.