BMAD vs Spec-Kit vs OpenSpec : comparaison de 3 outils spec-driven AI sur un projet réel

Arrête. Avant de taper ton prochain prompt dans ton éditeur IA et d’espérer que la magie opère, pose-toi une question : est-ce que tu as vraiment défini ce que tu bâtis? Le prompting ad hoc, c’est efficace pour des tâches isolées. Mais sur un projet de taille réelle, avec des interdépendances et des décisions d’architecture, tu finis souvent avec du code qui répond à la question que tu as posée plutôt qu’au problème que tu voulais résoudre. Le spec-driven AI est une approche qui tente de corriger ça en forçant la clarification en amont. Trois outils ont émergé dans cet espace : BMAD, Spec-Kit et OpenSpec. Je les ai testés tous les trois sur le même projet en février 2026. Ce que tu vas apprendre:

• Ce que l’approche spec-driven change concrètement dans un workflow IA
• Les forces et limites réelles de BMAD v6.0.3, Spec-Kit v0.1.6 et OpenSpec v1.2.0
• Les résultats sur 13 dimensions d’évaluation avec les scores finaux
• Dans quel contexte chaque outil gagne (et perd)
• Ce que cette comparaison révèle sur l’état du spec-driven en 2025-2026

Ce que le spec-driven AI change vraiment

L’idée centrale est simple : avant de demander à l’IA d’écrire du code, tu lui fournis une spécification structurée du comportement attendu. Pas une description vague dans un prompt. Une spec formelle qui décrit les entrées, les sorties, les cas limites, les contraintes de performance, les décisions d’architecture. Le gain est réel. Quand l’IA part d’une spec claire, elle génère moins de code qui « fait semblant » de fonctionner. Les allers-retours de correction diminuent parce que l’outil a une cible précise à atteindre plutôt qu’une intention floue à interpréter. Sur des projets complexes avec plusieurs modules interdépendants, la différence entre partir d’une spec et partir d’un prompt narratif devient rapidement évidente. Sauf que la vraie affaire, c’est que rédiger une bonne spec est difficile. C’est là que BMAD, Spec-Kit et OpenSpec interviennent différemment : ils t’aident à construire cette spec, mais avec des philosophies et des niveaux de friction très différents.

Le spec-driven n’est pas une promesse de code parfait au premier essai. C’est une structure qui réduit l’entropie d’un projet IA. La distinction compte parce que les trois outils testés ici la réalisent de façons très différentes, avec des compromis très différents.

Méthodologie : un même projet, 13 dimensions

Pour rendre la comparaison honnête, j’ai soumis les trois outils au même projet : une API de gestion de contenu avec plusieurs types d’entités, des règles de validation métier non triviales, et des besoins d’intégration avec des services externes. Un projet assez représentatif d’un MVP B2B sérieux sans être un monolithe enterprise. Les 13 dimensions d’évaluation couvrent deux zones distinctes : la qualité du code généré d’un côté (exactitude, couverture des cas limites, maintenabilité, performance du code produit), et l’expérience de travail réelle de l’autre (courbe d’apprentissage, vitesse de mise en route, qualité du workflow proposé, intégration IDE, support des iterations, gestion du contexte long, documentation, coût et viabilité à long terme). La 13e dimension est une note d’impression globale qui tient compte de l’expérience au-delà des critères formels. Les évaluations ont été faites en février 2026, avec les versions précises suivantes : BMAD v6.0.3 (testé en mode Full et en mode Quick, deux workflows distincts dans le même outil), Spec-Kit v0.1.6 et OpenSpec v1.2.0.

BMAD : la puissance qui demande un investissement

BMAD est l’outil le plus ambitieux des trois. Son mode Full déploie 12 agents spécialisés qui se passent le relais à travers un workflow structuré : un agent collecte les exigences, un autre valide la cohérence de la spec, un autre génère l’architecture, etc. C’est impressionnant sur papier, et ça l’est aussi en pratique, mais pas sans coût.

Le mode Full de BMAD produit des specs d’une profondeur que les deux autres outils n’atteignent pas. Les cas limites sont mieux couverts. Les décisions d’architecture sont documentées avec leurs justifications. Quand tu arrives à la phase de génération de code, l’IA part d’une base beaucoup plus solide. Sur notre projet de test, la qualité du code généré à partir des specs BMAD Full était la plus élevée des trois outils sur les dimensions techniques. Sauf qu’en pratique, le workflow Full est lourd. Le temps de mise en route est significatif. Pour un développeur solo sur un projet qui évolue vite, le coût en friction upfront peut neutraliser le gain en qualité en aval. C’est là que le mode Quick de BMAD entre en jeu : il coupe plusieurs étapes du workflow et sacrifie de la profondeur pour gagner en vitesse.

Le truc avec BMAD : le mode Full est objectivement le plus rigoureux des trois outils, mais son overhead de démarrage le réserve à des projets où tu peux justifier cet investissement initial. Le mode Quick est plus accessible, mais il commence à ressembler à Spec-Kit sans être aussi léger. Les scores finaux le reflètent : BMAD Full obtient 3.65/5 et BMAD Quick obtient 3.74/5. C’est intéressant que le mode Quick surpasse légèrement le mode Full dans notre évaluation globale, ce qui suggère que la friction du mode Full dépasse son bénéfice pour le type de projet qu’on a testé. BMAD gagne si : tu travailles sur un projet avec des exigences complexes et stables, avec du temps pour un onboarding sérieux, et dans un contexte d’équipe où les specs détaillées ont de la valeur au-delà de la génération de code. BMAD perd si : ton projet pivote souvent, tu travailles seul avec des délais serrés, ou tu veux entrer dans le flow rapidement sans investissement de démarrage élevé.

Spec-Kit : la vitesse qui coûte en profondeur

Spec-Kit v0.1.6 prend le pari inverse de BMAD. La philosophie est explicitement orientée vers la rapidité de démarrage : tu peux être opérationnel en quelques minutes, le workflow est plus court, et l’outil ne te demande pas de remplir des dizaines de champs avant de commencer à travailler. Sur les dimensions de courbe d’apprentissage et de vitesse de mise en route, Spec-Kit gagne facilement. C’est l’outil le plus accessible des trois pour un développeur qui découvre l’approche spec-driven. Le workflow proposé est assez intuitif pour qu’on puisse l’utiliser sans lire toute la documentation d’abord.

Sauf que cette accessibilité a un prix direct sur la qualité des specs produites. Spec-Kit v0.1.6 génère des spécifications moins profondes. Les cas limites sont moins bien couverts. Les décisions d’architecture sont souvent absentes ou vagues. Sur notre projet de test, plusieurs contraintes métier importantes n’ont pas été capturées dans la spec Spec-Kit sans qu’on les ajoute manuellement, ce qui renvoie en partie au problème qu’on voulait résoudre. Il faut aussi noter que Spec-Kit est en version 0.1.6 : c’est un outil jeune, et ça paraît. L’intégration IDE est plus limitée que les deux autres. La gestion du contexte long est moins solide. Et sur certaines dimensions techniques de notre évaluation, les résultats étaient nettement en dessous de BMAD et OpenSpec. Le score final de 2.77/5 est le plus bas des trois outils. Ce n’est pas une condamnation définitive, c’est une version précoce d’un outil qui a une vision claire mais pas encore les moyens de la réaliser complètement.

Le hic avec Spec-Kit : à ce stade de maturité, l’outil est intéressant pour explorer l’approche spec-driven sans engagement lourd, mais il n’est pas prêt pour des projets sérieux. La spec qu’il génère nécessite trop de complément manuel pour constituer une vraie fondation. Spec-Kit gagne si : tu veux tester l’approche spec-driven avec un minimum de friction, ou si tu travailles sur un projet simple avec peu de cas limites et des exigences stables. Spec-Kit perd si : ton projet a des règles métier complexes, des intégrations multiples, ou si tu as besoin d’une spec qui tient debout sans travail manuel additionnel.

OpenSpec : la flexibilité qui domine

OpenSpec v1.2.0 est l’outil qui a le plus surpris dans ce test. Avec un score final de 4.00/5, c’est le meilleur résultat des quatre configurations évaluées, et ce n’est pas une victoire par défaut. Ce qui distingue OpenSpec en premier, c’est son approche de l’intégration IDE. Avec 24 outils intégrés par défaut dans ses skills, OpenSpec s’insère dans un environnement de développement existant de façon beaucoup plus naturelle que BMAD ou Spec-Kit. Tu ne quittes pas ton éditeur pour aller remplir une interface externe : le workflow spec-driven s’intègre dans le contexte où tu travailles déjà.

La flexibilité d’OpenSpec se manifeste aussi dans sa gestion des itérations. Sur des projets qui évoluent, pouvoir mettre à jour la spec et régénérer des sections spécifiques sans reprendre le workflow depuis le début est un avantage concret. BMAD Full est plus rigide sur ce point. OpenSpec traite la spec comme un artefact vivant plutôt qu’un document de départ qu’on ne touche plus. La qualité du code généré à partir des specs OpenSpec est élevée, et les specs elles-mêmes atteignent une profondeur intermédiaire : moins détaillées que BMAD Full sur les cas très complexes, mais significativement plus complètes que Spec-Kit. Pour la majorité des projets de taille réelle, ce niveau de profondeur est suffisant.

Le bémol honnête avec OpenSpec : sa richesse en intégrations (24 outils par défaut) peut être une source de confusion au démarrage. Il y a plus à configurer pour exploiter pleinement l’outil, et la documentation de certains skills avancés est encore incomplète à la date de notre test. Ce n’est pas insurmontable, mais c’est un coût réel pour un développeur solo qui veut aller vite.

Ce qu’OpenSpec fait mieux : il traite le spec-driven comme un workflow continu plutôt qu’une phase de démarrage. Sur un projet qui évolue, c’est la différence entre un outil qu’on utilise une fois et un outil qu’on utilise tout au long du projet. OpenSpec gagne si : ton projet a une durée de vie réelle, avec des exigences qui vont changer, dans un contexte où l’intégration IDE compte et où tu veux un équilibre entre profondeur de spec et vitesse de travail. OpenSpec perd si : ton projet a des exigences si complexes que seul le niveau de rigueur de BMAD Full suffit, ou si tu as besoin d’un outil qui te guide très explicitement à travers chaque étape du processus.

Tableau comparatif : les 13 dimensions

Une précision sur le tableau : certaines dimensions comme « impression globale » ne sont pas réductibles à des critères binaires. Elles reflètent l’expérience accumulée sur la durée du test et les moments où l’outil t’a aidé ou freiné de façon non anticipée. C’est subjectif par nature, mais c’est aussi ce qui distingue une comparaison basée sur usage réel d’un benchmark purement technique.

Quel outil choisir selon ton contexte

La bonne réponse dépend de trois variables : la complexité de ton projet, ta tolérance à la friction de démarrage, et l’importance de l’intégration IDE dans ton workflow. Tu choisis OpenSpec v1.2.0 si : Tu veux le meilleur équilibre global. Il domine sur 13 dimensions, son intégration IDE est sans comparaison avec les deux autres, et sa flexibilité sur les itérations en fait l’outil le plus adapté à des projets de durée réelle. C’est le choix par défaut pour la plupart des développeurs qui veulent adopter l’approche spec-driven sérieusement. Tu choisis BMAD Full v6.0.3 si : Ton projet a des exigences d’une complexité exceptionnelle, avec des règles métier très denses, des contraintes de performance précises à documenter, et un contexte d’équipe où les specs formelles ont de la valeur indépendamment de la génération de code. L’overhead de démarrage se justifie seulement dans ces conditions. Tu choisis BMAD Quick v6.0.3 si : Tu veux la rigueur de BMAD avec moins de friction. Le score de 3.74/5 montre que ce mode est souvent le meilleur compromis dans l’écosystème BMAD. Si tu hésite entre BMAD Full et Quick, commence par Quick. Tu évites Spec-Kit v0.1.6 pour l’instant si : Tu as un projet sérieux avec une deadline. Reviens dans quelques versions. Le projet a une direction intéressante, mais v0.1.6 n’est pas encore à la hauteur de ce qu’un développeur professionnel a besoin.

Verdict de la comparaison : OpenSpec v1.2.0 est le choix gagnant pour la majorité des contextes en 2026. BMAD reste pertinent pour les projets à haute complexité. Spec-Kit est un pari sur une version future.

Ce que cette comparaison révèle sur le spec-driven en 2025-2026

Le spec-driven AI n’est pas une tendance de surface. Il correspond à un vrai problème dans l’adoption de l’IA pour le développement : les LLMs sont excellents pour exécuter des instructions précises, mais ils ne peuvent pas compenser une définition floue de ce qu’on veut construire. Plus les modèles deviennent puissants, plus la qualité de la spec en amont devient le facteur limitant. Ce que cette comparaison montre aussi, c’est que l’espace est encore jeune. Spec-Kit en v0.1.6 est un signe que des nouveaux entrants testent des approches différentes. OpenSpec en v1.2.0 a atteint un bon niveau de maturité mais sa documentation reste incomplète sur des fonctionnalités avancées. BMAD en v6.0.3 est l’outil le plus établi, et ça se voit dans la complétude de son workflow, mais aussi dans sa difficulté à s’adapter à des flux de travail plus légers.

L’intégration IDE est l’enjeu qui va définir les gagnants à moyen terme. Les 24 outils intégrés par défaut dans OpenSpec ne sont pas un détail marketing : ils signifient que l’outil s’insère dans le flux de travail existant d’un développeur plutôt que de demander un changement de contexte. Les outils spec-driven qui vont gagner dans les prochaines versions sont ceux qui réduisent la friction entre la définition de la spec et l’exécution dans l’IDE. Il y a aussi une question de philosophie qui se clarifie dans cette comparaison. BMAD pense la spec comme un document de départ, complet et validé avant de commencer le code. OpenSpec pense la spec comme un artefact vivant qui évolue avec le projet. Ces deux philosophies ne sont pas réconciliables dans un seul outil, et c’est correct : elles correspondent à deux types de projets et deux façons de travailler différentes.

Ce que je retiens : le spec-driven AI structure mieux les projets complexes que le prompting ad hoc, mais l’outil que tu choisis doit correspondre à ta façon réelle de travailler. Un outil rigoureux utilisé à moitié parce qu’il est trop lourd produit de moins bons résultats qu’un outil plus léger utilisé de façon cohérente. Le dernier point est peut-être le plus important. Les trois outils testés ici ont tous une prémisse correcte : clarifier ce qu’on bâtit avant de toucher au code améliore la qualité du résultat final. Mais la valeur réelle ne vient pas de l’outil en soi. Elle vient de la discipline d’utiliser le processus de spec pour forcer les décisions difficiles : qu’est-ce que cet endpoint doit vraiment faire, quels sont les cas limites qui importent, quelle est l’interface que l’utilisateur final va réellement utiliser. Un bon workflow spec-driven te force à avoir ces conversations avec toi-même ou ton équipe avant de demander à l’IA de produire du code. C’est ce changement de pratique qui compte, plus que le score de l’outil qui le supporte.

Verdict final

OpenSpec v1.2.0 est le meilleur outil spec-driven disponible en ce moment pour la majorité des développeurs. BMAD v6.0.3 en mode Quick est le meilleur choix alternatif si tu veux un workflow plus guidé ou si ton projet a une complexité qui justifie le mode Full. Spec-Kit v0.1.6 mérite d’être surveillé dans quelques versions mais n’est pas encore recommandable pour du travail sérieux. Le spec-driven AI est une approche qui vaut la peine d’être adoptée. La friction de démarrage est réelle mais elle est compensée sur des projets de durée réelle. Le bon moment pour commencer avec un de ces outils, c’est ton prochain projet, pas dans six mois.

Tests effectués en février 2026 sur les versions v6.0.3 (BMAD), v0.1.6 (Spec-Kit) et v1.2.0 (OpenSpec). Les scores sont basés sur l’évaluation d’un projet de test unique et reflètent un contexte de développeur solo sur un projet MVP B2B. Les résultats peuvent varier selon la complexité du projet et le profil du développeur.

Texte par David Cyr

David Cyr

L'Opérateur AI · Fondateur Taverne AI

Opérateur québécois. J'ai construit LeadLoup, un mandat acheteur véhicules pour Complexe Kia, et plusieurs systèmes IA en production. À la Taverne, je teste des outils qu'on me paie pour utiliser, et je dis si c'est utile ou si c'est de la marde.

À propos·Méthodologie