# SpecScore vs Kiro Canonical: https://specscore.md/fr/vs/kiro/ [Développement piloté par les spécifications](https://specscore.md/fr/spec-driven-development/) (SDD) signifie écrire ce que le logiciel doit faire avant qu’un agent d’IA n’écrive le code. [Kiro](https://kiro.dev/), d’Amazon Web Services (AWS), est un environnement de développement agentique — un éditeur, une [interface en ligne de commande](https://specscore.md/fr/cli/) (CLI) et une application web — qui transforme un prompt en Kiro specs : exigences, une conception et des tâches. Ces exigences utilisent [EARS](https://kiro.dev/docs/specs/feature-specs/) (Easy Approach to Requirements Syntax), des phrases de la forme « WHEN quelque chose se produit, THE SYSTEM SHALL faire quelque chose ». [SpecScore](https://specscore.md/fr/) est un format [à code source ouvert](https://github.com/specscore/specscore) pour la spécification elle-même, plus un CLI qui vérifie les fichiers. L’[intégration continue](https://specscore.md/fr/validators/) (CI) — une vérification automatique à chaque changement proposé — peut rejeter une spécification SpecScore qui rompt le format. ## Ce qu'ils partagent. - Les deux traitent une spécification écrite comme ce à partir de quoi un agent doit construire, et non comme la transcription d’une conversation. - Les deux conservent cette spécification en Markdown dans le projet, afin qu’elle se relise comme du code. - Les deux découpent le travail en exigences, une conception et des tâches. Kiro génère ces trois fichiers. SpecScore est un format qu’une équipe peut garder après la fin de la session. ## Ce que Kiro fait bien. La documentation propre de Kiro, lue le 30 octobre 2026, décrit le produit. La page des spécifications de fonctionnalité était marquée comme mise à jour le 4 août 2026. ### Des exigences dans une forme de phrase fixe Les Kiro specs placent le comportement dans `requirements.md` selon un motif EARS : WHEN une condition est vraie, THE SYSTEM SHALL faire une chose. La documentation donne l’exemple d’un formulaire avec des données invalides, et le système affiche une erreur de validation à côté du champ. Cette forme est plus facile à tester qu’un paragraphe vague. ### Un chemin complet du prompt aux tâches Une spécification de fonctionnalité passe par les exigences, la conception (`design.md`) et les tâches (`tasks.md`). Vous pouvez partir des exigences ou d’une conception. Quick Spec exécute les trois sans arrêt d’approbation entre elles. Les Bugfix specs sont un chemin distinct. La documentation décrit aussi l’exécution de tâches indépendantes en parallèle, par vagues, à partir du graphe de dépendances dans `tasks.md`. ### Des vérifications dans le produit Analyze Requirements, disponible dans l’IDE et le CLI, cherche les incohérences, l’ambiguïté, les contraintes en conflit et les manques avant la conception. Correctness — des tests basés sur les propriétés, tirés de ces lignes EARS — est indiqué pour l’IDE seulement, pas pour le CLI, le web ou le mobile, dans le tableau de capacités des specs. ## Comparaison des fonctionnalités. Kiro est un produit qui rédige des spécifications. SpecScore est le format qu’un dépôt peut vérifier. Le tableau compare ces rôles. | Capacité | Kiro | SpecScore | | --- | --- | --- | | Rôle principal | IDE agentique, CLI et application web qui rédigent des spécifications et mettent en œuvre les tâches | **Format de spécification ouvert + CLI** | | Fichiers de spécification | `requirements.md` (ou `bugfix.md`), `design.md`, `tasks.md` | **Une arborescence spec/** en Markdown + YAML | | Syntaxe des exigences | Motif EARS : WHEN … THE SYSTEM SHALL … | **Identifiants d’exigences** (`REQ: slug`) et critères d’acceptation [Étant donné/Quand/Alors](https://specscore.md/acceptance-criteria-specification) | | Vérifier la spécification | Analyze Requirements dans l’IDE et le CLI. Tests basés sur les propriétés dans l’IDE. Non décrit comme un linter de format pour votre propre CI. | **specscore spec lint** dans la CI. `/score` est une note d’IA distincte et manuelle. | | Où cela s’exécute | Kiro IDE, Kiro CLI, Kiro web. Certaines vérifications n’existent que dans l’IDE. | **N’importe quel dépôt** — un binaire Go, sans compte Kiro | | Licence | La [licence Kiro](https://kiro.dev/license/) dit que l’IDE et le CLI sont de l’AWS Content sous l’AWS Customer Agreement. Kiro Crew est un [dépôt public](https://github.com/kirodotdev/KiroCrew) distinct. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) pour le format · [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) pour le CLI | | Prix | Un palier gratuit et des offres payantes. Les chiffres bougent — voir les [tarifs Kiro](https://kiro.dev/pricing/), lus le 30 octobre 2026. | **Sans frais** pour le format ni pour le CLI | ## Ce que SpecScore apporte en plus. ### Le format fait échouer la CI de lui-même L’analyse de Kiro s’exécute dans Kiro. La vérification de SpecScore est une commande. Le [flux dogfood](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) de ce dépôt exécute `specscore spec lint` sur chaque pull request et sur main. Une spécification cassée fait échouer l’exécution comme le ferait un test cassé. La skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) note le libellé avec des relecteurs d’IA ; cette passe est manuelle, et le flux ci-dessus ne l’exécute pas. ``` $ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors) ``` ### La spécification n’est pas liée à un seul IDE Les Kiro specs sont du Markdown, vous pouvez donc les lire sans le produit. Le flux qui les crée et les exécute est celui de Kiro. Une arborescence SpecScore, ce sont les mêmes fichiers pour Claude Code, Cursor, Copilot ou aucun agent — le CLI n’appelle pas de modèle pour linter. ### Les exigences gardent un identifiant La documentation de Kiro décrit la traçabilité comme le suivi d’une exigence à travers l’implémentation. Elle ne décrit pas d’identifiant stable qui survive à une réécriture. SpecScore désigne une exigence par `REQ: slug` et un critère d’acceptation par son propre identifiant. ### EARS et Étant donné/Quand/Alors répondent à des questions différentes EARS, tel que Kiro le documente, est une phrase de comportement du système. Les critères d’acceptation SpecScore sont des scénarios Étant donné/Quand/Alors liés à un identifiant d’exigence. Vous pouvez écrire une ligne EARS dans la prose et garder quand même le scénario dans le fichier SpecScore que le linter vérifie. Les patrons de phrase sont dans [la syntaxe des exigences EARS](https://specscore.md/articles/ears-requirements/). ## Quand choisir l'un ou l'autre. ### Choisissez Kiro quand… - Vous voulez un IDE agentique AWS qui rédige exigences, conception et tâches à partir d’un prompt, puis met les tâches en œuvre. - Vous voulez des phrases EARS et, dans l’IDE, des tests basés sur les propriétés générés à partir d’elles. - Votre équipe se standardise déjà sur l’éditeur, le CLI ou l’application web de Kiro. ### Utilisez SpecScore quand… - La spécification doit rester valide dans la CI après la fin de la session de l’agent, dans un dépôt qui n’exige pas Kiro. - Vous avez besoin d’identifiants d’exigences, d’un statut de cycle de vie et d’un résultat de lint déterministe. - Vous voulez le format [à code source ouvert](https://github.com/specscore/specscore) et un vérificateur qui soit un seul binaire. ## Kiro peut rédiger. SpecScore peut servir de barrière. Rien ici ne remplace l’éditeur de Kiro. Si Kiro est l’endroit où l’équipe écrit le prompt, laissez-le rédiger. Si la spécification doit survivre comme fichier relu, écrivez ce contrat dans SpecScore et laissez `specscore spec lint` faire échouer la pull request quand la structure casse. Les deux fichiers peuvent cohabiter dans le même dépôt. Choisissez Kiro pour la session. Choisissez SpecScore pour l’artefact qu’une exécution de CI peut refuser. ## Sources. Les pages publiques ci-dessous ont été lues le 30 octobre 2026. Les prix, les noms d’offres et les versions changent. - [Documentation Kiro — Specs](https://kiro.dev/docs/specs/) - [Documentation Kiro — spécifications de fonctionnalité et EARS](https://kiro.dev/docs/specs/feature-specs/) - [Kiro — À propos](https://kiro.dev/about/) - [Kiro — Licence](https://kiro.dev/license/) - [Kiro — Tarifs](https://kiro.dev/pricing/) - [specscore/specscore — flux CI dogfood](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specstudio-skills — skill /score](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)