# Meilleurs outils de développement piloté par les spécifications en 2026

Canonical: https://specscore.md/fr/spec-driven-development/tools/

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](https://specscore.md/fr/spec-driven-development/) (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](https://kiro.dev/docs/specs/feature-specs/) (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](https://specscore.md/fr/cli/) (CLI) est un programme que vous lancez dans un terminal. L’[intégration continue](https://specscore.md/fr/validators/) (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](https://github.com/github/spec-kit), [OpenSpec](https://github.com/Fission-AI/OpenSpec), [Kiro](https://kiro.dev/), [Tessl](https://docs.tessl.io/), la [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), [Task Master AI](https://github.com/eyaltoledano/claude-task-master), [CodeSpeak](https://codespeak.dev/), [Datarim](https://github.com/Arcanada-one/datarim), le Markdown simple et [SpecScore](https://specscore.md/fr/). 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](https://github.com/specscore/specscore/blob/main/.github/workflows/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](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) 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](https://specscore.md/fr/vs/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](https://github.com/github/spec-kit/blob/main/LICENSE) dans [github/spec-kit](https://github.com/github/spec-kit) | Une équipe qui veut un processus partagé pour l’agent |
| [OpenSpec](https://specscore.md/fr/vs/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](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE) dans [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | Une équipe qui veut un dossier de changement léger plus une vérification de structure |
| [Kiro](https://specscore.md/fr/vs/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](https://kiro.dev/license/) (AWS Customer Agreement). | Quelqu’un qui veut que Kiro rédige les exigences, la conception et les tâches |
| [Tessl](https://specscore.md/fr/vs/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](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) dans [tesslio/spec-driven-development-tile](https://github.com/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](https://specscore.md/fr/vs/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](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) dans [bmad-code-org/BMAD-METHOD](https://github.com/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](https://specscore.md/fr/vs/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](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE) dans [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | Une équipe qui a déjà un PRD et veut le découper en tâches |
| [CodeSpeak](https://specscore.md/fr/vs/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](https://codespeak.dev/terms-of-service) (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](https://specscore.md/fr/vs/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](https://github.com/Arcanada-one/datarim/blob/main/LICENSE) dans [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | Une équipe qui veut des commandes par étapes et un backlog dans le dépôt |
| [Markdown simple](https://specscore.md/fr/vs/plain-markdown/) | 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](https://specscore.md/fr/) | Format de spécification ouvert plus un CLI qui linte les fichiers | Markdown + YAML dans un arbre `spec/` | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) exécute `specscore spec lint` sur les pull requests et les push vers main. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) est une évaluation manuelle par IA, et ce workflow ne l’exécute pas. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE), format dans [specscore/specscore](https://github.com/specscore/specscore). [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), CLI dans [specscore/specscore-cli](https://github.com/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](https://github.github.io/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](https://github.github.io/spec-kit/upgrade.html), 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](https://github.github.io/spec-kit/reference/agentic-sdd.html) 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](https://github.com/github/spec-kit/blob/main/LICENSE), dans le dépôt public [github/spec-kit](https://github.com/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](https://specscore.md/fr/vs/spec-kit/).

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/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](https://github.com/Fission-AI/OpenSpec/blob/main/README.md), 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](https://openspec.dev/docs/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](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE), dans [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec). OpenSpec convient à une équipe qui veut le dossier de changement et cette vérification de structure. Voir [SpecScore vs OpenSpec](https://specscore.md/fr/vs/openspec/).

## Kiro

[Kiro](https://kiro.dev/), 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é](https://kiro.dev/docs/specs/feature-specs/), 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](https://kiro.dev/license/), 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](https://specscore.md/fr/vs/kiro/). Les patrons de phrase sont dans [la syntaxe des exigences EARS](https://specscore.md/fr/articles/ears-requirements/).

## Tessl

La [documentation de Tessl](https://docs.tessl.io/), 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](https://github.com/tesslio/spec-driven-development-tile) et listé sur le [registre Tessl](https://tessl.io/registry/tessl-labs/spec-driven-development). 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](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE), 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](https://specscore.md/fr/vs/tessl/).

## BMAD Method

Le README du dépôt [BMAD Method](https://github.com/bmad-code-org/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](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE), dans [bmad-code-org/BMAD-METHOD](https://github.com/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](https://specscore.md/fr/vs/bmad-method/).

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) 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](https://tryhamster.com/docs/taskmaster) 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](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE), dans [eyaltoledano/claude-task-master](https://github.com/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](https://specscore.md/fr/vs/task-master-ai/).

## CodeSpeak

Le site de [CodeSpeak](https://codespeak.dev/), 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](https://codespeak.dev/terms-of-service), 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](https://specscore.md/fr/vs/codespeak/).

## Datarim

Le README de [Datarim](https://github.com/Arcanada-one/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](https://github.com/Arcanada-one/datarim/blob/main/LICENSE), dans [Arcanada-one/datarim](https://github.com/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](https://specscore.md/fr/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](https://specscore.md/fr/vs/plain-markdown/).

## SpecScore

[SpecScore](https://specscore.md/fr/) 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](https://github.com/specscore/specscore). Le CLI vit dans [specscore/specscore-cli](https://github.com/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](https://specscore.md/fr/articles/acceptance-criteria/).

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](https://specscore.md/fr/articles/feature-spec-template/).

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](https://specscore.md/fr/articles/claude-code-specs/).

Comment lancer ce linter en intégration continue est expliqué dans [linter des spécifications en CI](https://specscore.md/fr/articles/lint-specs-in-ci/).

Dans le dépôt de ce site web, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/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](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) 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](https://github.com/specscore/specscore/blob/main/LICENSE), dans [specscore/specscore](https://github.com/specscore/specscore). La licence du CLI est [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), dans [specscore/specscore-cli](https://github.com/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/](https://specscore.md/fr/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](https://github.com/specscore/specscore/blob/main/.github/workflows/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.

- [Documentation GitHub Spec Kit (page datée du 28 septembre 2026)](https://github.github.io/spec-kit/)
- [Spec Kit — Référence SDD agentique](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit — Guide de mise à niveau (chemins specs/)](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit — licence MIT](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec — README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [Référence du CLI OpenSpec — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec — licence MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Documentation Kiro — spécifications de fonctionnalité et EARS (mise à jour le 4 août 2026)](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — Licence](https://kiro.dev/license/)
- [Documentation Tessl — Qu’est-ce que Tessl ?](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tile Tessl de développement piloté par les spécifications — licence MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)
- [bmad-code-org/BMAD-METHOD — README](https://github.com/bmad-code-org/BMAD-METHOD)
- [BMAD-METHOD — licence MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)
- [eyaltoledano/claude-task-master — README](https://github.com/eyaltoledano/claude-task-master)
- [Task Master — MIT avec Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak — Conditions d’utilisation (en vigueur le 3 mars 2026)](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim — README (badge 4.9.0)](https://github.com/Arcanada-one/datarim)
- [Datarim — licence MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)
- [specscore/specscore — dogfood.yml (specscore spec lint)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills — skill /score (évaluation manuelle par IA)](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md)
- [specscore/specscore — CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli — Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)