Meilleurs outils de développement piloté par les spécifications en 2026
SpecScore est un format de fichier ouvert et vérifiable par un linter pour les spécifications, écrit en Markdown et YAML (YAML Ain't Markup Language). Le développement piloté par les spécifications (SDD) est une pratique dans laquelle une spécification écrite est la source de vérité par rapport à laquelle le code est construit et vérifié. Les outils de développement piloté par les spécifications sont les formats, les workflows et les produits utilisés pour écrire, conserver et parfois vérifier ces spécifications. Un document d’exigences produit (PRD) est une prose qui énonce le problème et le périmètre avant que quiconque ne le découpe en tâches. L’approche simple de la syntaxe des exigences (EARS) est une phrase d’exigence de la forme « WHEN quelque chose se produit, THE SYSTEM SHALL faire quelque chose ». Une interface en ligne de commande (CLI) est un programme que vous lancez dans un terminal. L’intégration continue (CI) est une vérification automatique de chaque changement proposé.
Cette comparaison d’outils de développement piloté par les spécifications couvre GitHub Spec Kit, OpenSpec, Kiro, Tessl, la BMAD Method, Task Master AI, CodeSpeak, Datarim, le Markdown simple et SpecScore. Les pages et les dépôts publics ont été lus le 30 octobre 2026. Les commandes, la disposition des fichiers et ce qu’un produit vérifie peuvent changer ; les sources en bas nomment la page d’où vient chaque affirmation.
La distinction qui compte pour un dépôt est de savoir si la spécification peut faire échouer la CI par elle-même. Dans le dépôt du site web SpecScore, dogfood.yml installe le CLI SpecScore et exécute specscore spec lint sur les pull requests et sur les push vers main. La skill /score dans specstudio-skills est une évaluation manuelle par IA d’un artefact. Vous l’invoquez. Ce workflow non.
Outils de développement piloté par les spécifications, côte à côte.
Chaque ligne est un rôle, pas un score. Suivez le nom vers la comparaison SpecScore, ou le titre plus bas pour la source derrière la cellule.
| Outil | Ce que c’est | Comment les spécifications sont écrites et conservées | Validation automatique de la spécification | Licence | À qui cela convient |
|---|---|---|---|---|---|
| GitHub Spec Kit | Workflow d’agent qui produit des artefacts Markdown | Répertoire de fonctionnalité sous specs/ : spec.md, plan.md, tasks.md | /speckit.analyze signale les écarts entre artefacts dans la session de l’agent. Des extensions communautaires peuvent ajouter des contrôles. | MIT dans github/spec-kit | Une équipe qui veut un processus partagé pour l’agent |
| OpenSpec | Dossiers de changement et commandes d’agent pour s’accorder avant le code | Markdown simple sous openspec/changes/ : proposition, spécifications, conception, tâches | openspec validate vérifie la structure du changement et de la spécification et peut se terminer avec un code de sortie non nul, y compris depuis un script de CI. | MIT dans Fission-AI/OpenSpec | Une équipe qui veut un dossier de changement léger plus une vérification de structure |
| Kiro | IDE agentique, CLI et application web d’AWS qui rédige des spécifications | requirements.md en EARS, plus design.md et tasks.md | Analyze Requirements à l’intérieur de Kiro, avant la conception. La page des spécifications de fonctionnalité décrit cette vérification dans le produit. | L’IDE et le CLI sont AWS Content sous la licence Kiro (AWS Customer Agreement). | Quelqu’un qui veut que Kiro rédige les exigences, la conception et les tâches |
| Tessl | Plateforme de skills pour agents, plus un tile de développement piloté par les spécifications | Skills comme fichiers dans le dépôt. Le tile écrit .spec.md sous specs/. | Le tile livre scripts/validate-specs.sh et scripts/check-spec-links.sh. Ses GitHub Actions lintent le tile. | Le tile est MIT dans tesslio/spec-driven-development-tile. La plateforme est le produit de Tessl. | Une équipe qui normalise des skills d’agent, ou qui utilise les règles spécification-avant-le-code du tile |
| BMAD Method | Méthode agile pour le développement piloté par l’IA | Briefs, spécifications et architecture que vous pouvez emporter dans un autre workflow | Le README décrit les artefacts de la méthode et les workflows d’agent. Il ne documente pas de linter de format pour la CI. | MIT dans bmad-code-org/BMAD-METHOD, avec une mention de marque dans ce fichier. | Une équipe qui veut une méthode d’agent agile dimensionnée selon le changement |
| Task Master AI | Liste de tâches pour agents de programmation, obtenue en analysant un PRD | Prose de PRD, souvent .taskmaster/docs/prd.txt, puis des tâches générées | Le README décrit l’analyse d’un PRD en tâches. Il ne décrit pas de linter pour le PRD. | MIT avec une Commons Clause dans eyaltoledano/claude-task-master | Une équipe qui a déjà un PRD et veut le découper en tâches |
| CodeSpeak | Boîte à outils agentique qui transforme l’intention du chat en exigences reliées au code | Exigences structurées à l’intérieur du produit, reliées au code | Le site dit que les exigences sont appliquées à chaque changement, à l’intérieur du produit. | Conditions d’utilisation (en vigueur le 3 mars 2026) : CodeSpeak Ltd conserve le Service, y compris son code source. Le site du produit ne publie pas de dépôt de source pour la boîte à outils. | Une équipe qui veut l’intention capturée depuis les chats et maintenue reliée au code |
| Datarim | Workflow itératif pour Claude Code, Codex CLI, Cursor et Antigravity | /dr-prd écrit un PRD. Les tâches actives sont dans backlog.md. | /dr-compliance et /dr-dream lint s’exécutent quand vous invoquez ces commandes. | MIT dans Arcanada-one/datarim | Une équipe qui veut des commandes par étapes et un backlog dans le dépôt |
| Markdown simple | Un fichier Markdown ordinaire que vous écrivez et que vous commitez | N’importe quel fichier .md, dans le répertoire que vous choisissez | La relecture que vous faites en lisant, jusqu’à ce que vous ajoutiez un vérificateur | Pas de produit et pas de fichier de licence. Les conditions du fichier sont celles du dépôt. | Une note courte, un spike ou une relecture que vous ferez en lisant |
| SpecScore | Format de spécification ouvert plus un CLI qui linte les fichiers | Markdown + YAML dans un arbre spec/ | dogfood.yml exécute specscore spec lint sur les pull requests et les push vers main. /score est une évaluation manuelle par IA, et ce workflow ne l’exécute pas. | CC BY 4.0, format dans specscore/specscore. Apache-2.0, CLI dans specscore/specscore-cli. | Une équipe qui a besoin que le fichier de spécification fasse échouer la CI quand le format casse |
GitHub Spec Kit
GitHub Spec Kit est une boîte à outils ouverte qui remet à un agent de programmation un processus : Specify, Plan, Tasks, Implement et Converge. La page d’accueil de la documentation Spec Kit, datée du 28 septembre 2026, dit que chaque phase produit un artefact Markdown que la phase suivante lit.
Ces fichiers vivent dans un répertoire de fonctionnalité sous specs/. Le guide de mise à niveau, lu le 30 octobre 2026, donne des chemins tels que specs/001-my-feature/spec.md, avec plan.md et tasks.md à côté. La référence SDD agentique décrit /speckit.analyze comme un rapport d’incohérences entre la spécification, le plan et les tâches, sans modifier les fichiers. /speckit.clarify et /speckit.checklist sont d’autres commandes que vous lancez dans l’agent. La page d’accueil de la documentation nomme aussi des extensions communautaires, dont une appelée CI Guard, qui ajoutent des contrôles de conformité.
La licence est MIT, dans le dépôt public github/spec-kit. Spec Kit convient à une équipe qui veut ce processus et accepte de garder la spécification comme le Markdown que l’agent a écrit. Une mise côte à côte avec SpecScore est sur SpecScore vs Spec Kit.
OpenSpec
OpenSpec, de Fission-AI, garde chaque changement dans son propre dossier afin qu’une personne et un agent puissent s’accorder avant que le code soit écrit. Le README, lu le 30 octobre 2026, montre openspec/changes/add-dark-mode/ avec proposal.md, un répertoire specs/, design.md et tasks.md. Les exigences sont du Markdown simple : un énoncé SHALL et un scénario WHEN / THEN. Le même README dit qu’il prend en charge 30+ assistants d’IA.
openspec validate vérifie les changements et les spécifications à la recherche de problèmes structurels. La référence du CLI, lue le 30 octobre 2026, documente une sortie non nulle quand la validation échoue, et un extrait shell qu’un job de CI peut exécuter. Cette vérification est la structure de changement et de spécification d’OpenSpec.
La licence est MIT, dans Fission-AI/OpenSpec. OpenSpec convient à une équipe qui veut le dossier de changement et cette vérification de structure. Voir SpecScore vs OpenSpec.
Kiro
Kiro, d’Amazon Web Services (AWS), est un environnement de développement agentique : un éditeur, un CLI et une application web. La page des spécifications de fonctionnalité, mise à jour le 4 août 2026, fait passer une fonctionnalité par les exigences, la conception et les tâches. requirements.md utilise EARS. design.md et tasks.md sont à côté. Quick Spec peut exécuter les trois sans un arrêt d’approbation entre eux.
Analyze Requirements cherche les incohérences, l’ambiguïté, les contraintes en conflit et les manques avant la conception. Cette analyse s’exécute à l’intérieur de Kiro. La page des spécifications de fonctionnalité décrit la vérification dans le produit.
La licence Kiro, lue le 30 octobre 2026, dit que l’IDE et le CLI sont concédés comme AWS Content sous l’AWS Customer Agreement ou un autre accord écrit, et l’AWS Intellectual Property License. Kiro convient à quelqu’un qui veut que ce produit rédige les trois fichiers. Voir SpecScore vs Kiro. Les patrons de phrase sont dans la syntaxe des exigences EARS.
Tessl
La documentation de Tessl, lue le 30 octobre 2026, décrit une plateforme ouverte pour gérer des skills d’agent : un registre, de la gouvernance, des evals et des contrôles associés. Les skills, les règles et les documents sont des fichiers dans le dépôt.
Un artefact distinct, le tile de développement piloté par les spécifications, est publié depuis tesslio/spec-driven-development-tile et listé sur le registre Tessl. Le README du tile dit que l’agent écrit des fichiers .spec.md dans un répertoire specs/, avec un frontmatter YAML, des targets et des liens [@test]. Il documente scripts/validate-specs.sh et scripts/check-spec-links.sh, et des GitHub Actions qui lintent le tile lui-même.
La licence du tile est MIT, dans ce dépôt. La documentation décrit la plateforme du registre comme le produit de Tessl et n’indique pas de dépôt public pour l’ensemble de la plateforme. Tessl convient à une équipe qui normalise des skills, ou à une équipe qui veut le pilotage spécification-avant-le-code du tile. Voir SpecScore vs Tessl.
BMAD Method
Le README du dépôt BMAD Method, lu le 30 octobre 2026, décrit une méthode agile pour le développement piloté par l’IA. Il dit que vous pouvez utiliser la méthode de bout en bout, ou emporter ses briefs, ses spécifications et son architecture dans un workflow que vous avez déjà. La ligne stable nommée là est v6.12. v7 est décrit comme un aperçu sur la branche main. Le projet orthographie le nom BMad ; le dépôt est BMAD-METHOD.
Le README place au centre ces artefacts de planification et les skills d’agent qui les produisent. Il ne documente pas de commande qui linte un schéma de spécification fixe dans la CI.
La licence est MIT, dans bmad-code-org/BMAD-METHOD. Ce fichier de licence porte aussi une mention de marque pour BMad. La méthode convient à une équipe qui veut la boucle agile et gardera la spécification dans ces briefs et ces spécifications. Voir SpecScore vs la BMAD Method.
Task Master AI
Task Master AI est une liste de tâches pour agents de programmation IA. Le README, lu le 30 octobre 2026, recommande un PRD, souvent à .taskmaster/docs/prd.txt, et task-master parse-prd pour transformer cette prose en tâches. La documentation couvre la structure des tâches, les dépendances et les tags.
Le README traite le PRD comme une entrée et la liste de tâches comme ce à partir de quoi l’agent travaille. Il ne décrit pas de linter pour la formulation ou la structure du PRD.
La licence est MIT avec une Commons Clause, dans eyaltoledano/claude-task-master. Le README dit que vous pouvez construire des produits avec Task Master, et que vendre Task Master lui-même ou le proposer comme service hébergé est en dehors de cette concession. Il convient à une équipe qui veut le PRD découpé en tâches. Voir SpecScore vs Task Master AI.
CodeSpeak
Le site de CodeSpeak, lu le 30 octobre 2026, décrit une boîte à outils d’ingénierie agentique. Il capture l’intention depuis les chats d’agent, transforme cette intention en exigences structurées reliées au code, et dit qu’il applique ces exigences à chaque changement. Le site dit aussi qu’un outil web retrouve l’intention depuis les chats jusqu’au lancement du produit complet.
Les conditions d’utilisation, en vigueur le 3 mars 2026, établissent que CodeSpeak Ltd conserve le Service, y compris son logiciel et son code source. Le site du produit ne publie pas de dépôt de source pour cette boîte à outils, donc cette page ne nomme pas de licence logicielle pour elle.
CodeSpeak convient à une équipe qui veut des exigences capturées depuis la conversation et maintenues reliées au code à l’intérieur de ce produit. Voir SpecScore vs CodeSpeak.
Datarim
Le README de Datarim, qui porte un badge de version 4.9.0 et a été lu le 30 octobre 2026, décrit un workflow itératif pour Claude Code, Codex CLI, Cursor et Google Antigravity. /dr-prd génère un PRD. Les tâches actives sont dans backlog.md, avec l’historique terminé dans backlog-archive.md.
/dr-compliance vérifie une implémentation par rapport au PRD quand vous lancez cette commande. /dr-dream lint contrôle l’état d’une base de connaissances à la recherche de contradictions, d’orphelins, de liens cassés, de contenu périmé et de doublons. Ce sont des commandes du workflow.
La licence est MIT, dans Arcanada-one/datarim. Datarim convient à une équipe qui veut ces commandes par étapes auprès des agents que le README nomme. Voir SpecScore vs Datarim.
Markdown simple
Le Markdown simple est la spécification comme un fichier .md ordinaire : un titre, quelques puces, là où vous le commitez. Il n’y a pas de schéma. La relecture, c’est quelqu’un qui lit le fichier, jusqu’à ce que vous ajoutiez votre propre vérificateur.
Il n’y a pas de produit et pas de fichier de licence à lier. Les conditions du fichier sont la licence que vous appliquez au dépôt. Le Markdown simple convient à une note courte, à un spike ou à une équipe qui relira la prose en la lisant. Voir SpecScore vs Markdown simple.
SpecScore
SpecScore est un format pour la spécification — fonctionnalités, exigences et critères d’acceptation en Markdown avec YAML — et un CLI qui vérifie les fichiers. Le format vit dans specscore/specscore. Le CLI vit dans specscore/specscore-cli.
Comment écrire les critères pour qu’un agent puisse les vérifier est dans comment écrire des critères d’acceptation.
Un modèle de spécification de fonctionnalité en Markdown — exigences, critères d’acceptation, un plan et des tâches — est dans modèle de PRD en Markdown.
Le développement piloté par les spécifications avec Claude Code et Cursor — le fichier de fonctionnalité, le fichier d’instructions de l’agent et specscore spec lint dans la boucle sont décrits dans développement piloté par les spécifications avec Claude Code et Cursor.
Comment lancer ce linter en intégration continue est expliqué dans linter des spécifications en CI.
Dans le dépôt de ce site web, dogfood.yml installe ce CLI et exécute specscore spec lint sur les pull requests et sur les push vers main. Une spécification qui casse le format fait échouer ce job. La skill /score est une évaluation manuelle par IA : elle relance les réviseurs configurés quand vous le demandez, et le workflow dogfood ne l’appelle pas.
La licence du format est CC BY 4.0, dans specscore/specscore. La licence du CLI est Apache-2.0, dans specscore/specscore-cli. SpecScore convient à une équipe qui a besoin que la spécification fasse échouer la CI quand un titre, un lien ou un statut est faux, quel que soit l’agent qui a écrit le fichier. openspec validate est la vérification structurelle la plus proche parmi les autres outils ici ; elle vérifie la forme de changement propre à OpenSpec. Les comparaisons individuelles commencent à /vs/.
Comment choisir.
Choisissez GitHub Spec Kit, OpenSpec, la BMAD Method ou Datarim quand vous voulez un processus guidé et du Markdown que vous pouvez relire dans une pull request. Choisissez Kiro quand vous voulez que ce produit rédige des exigences EARS. Choisissez Task Master AI quand le PRD doit devenir une liste de tâches. Choisissez CodeSpeak quand l’intention doit être capturée depuis les chats à l’intérieur de ce produit. Choisissez Tessl quand le problème est les skills d’agent, avec le tile de spécification comme pilotage facultatif.
Choisissez SpecScore quand le fichier de spécification lui-même doit faire échouer la CI. La vérification dans ce dépôt est specscore spec lint dans dogfood.yml. Un workflow de la liste ci-dessus peut rester la façon dont la spécification est écrite.
Sources.
Lu le 30 octobre 2026, sauf lorsqu’une page imprime sa propre date de mise à jour. Les prix et les noms des plans sont omis parce qu’ils bougent.