# Chaque ambiguïté dans votre spécification est un token que votre agent brûle.

Canonical: https://specscore.md/fr/

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) — comme JSON (JavaScript Object Notation) pour les données — avec une interface en ligne de commande (CLI) que vos agents appellent pour les interroger et les modifier, comme `jq` pour JSON.

Dernière mise à jour : 30 octobre 2026

Puis une question de clarification en plein développement. Puis un correctif après le déploiement. Puis ce contexte qu'il faut réexpliquer sans cesse.

 Open source sur GitHub Skills IA pour votre agent Installer le CLI

## Un format pour les spécifications que vous écrivez déjà.

**SpecScore est un format Markdown + YAML** pour les features, les exigences et les critères d'acceptation. Il définit une structure que votre équipe et vos agents d'IA comprennent tous deux — et ce sont simplement des fichiers dans votre dépôt.

Un projet SpecScore s'articule autour de trois types d'artefacts au long d'un cycle de vie : une **Idea** capture une orientation encore en gestation ; une spécification de **Feature** fige le comportement convenu ; un**Plan** décompose la feature en tâches ordonnées, chacune citant les critères d'acceptation qu'elle satisfait.

**Pourquoi votre agent s'en soucie.** La structure étant lisible par une machine, les agents d'IA peuvent interroger la spécification via le CLI au lieu de lire chaque fichier. Demandez *« sur quoi devrais-je travailler ensuite ? »*et le CLI renvoie les features ouvertes et les questions en suspens. La même forme que votre équipe révise ; beaucoup moins de contexte que l'agent doit charger.

 Feature → Exigences → Critères d'acceptation → Scénarios. idea → feature → plan EXEMPLE ideas/apply-discount.md

```
# Idea: Discount codes at checkout **Status:** Approved **Date:** 2026-05-19 **Owner:** cart-team **Promotes To:** features/apply-discount ## Problem Statement How might we let returning customers redeem a single promo code at checkout without breaking the existing cart math or the site-wide promotion engine? ## Recommended Direction A registered user can apply **one** valid code per cart. Codes are time-bounded and replaceable. Stacking with site-wide promotions follows a deterministic tiebreak rule (higher discount wins; site-wide wins on tie).
```

 EXEMPLE features/checkout/apply-discount.md

```
--- status: approved owners: [cart-team] --- # Feature: Apply Discount A registered user can apply one valid discount code to their cart at checkout. ## Requirements ### R1 — Single-code limit - **AC-1** The cart accepts at most one discount code at a time. - **AC-2** Applying a second code replaces the first, with a visible confirmation. - **AC-3** Removing the code restores the original cart total. ### R2 — Code validity - **AC-1** A code is valid only if `valid_from` ≤ now ≤ `valid_until` . - **AC-2** Invalid codes show a specific error message. ### R3 — Discount application - **AC-1** Percentage discounts apply to subtotal, not shipping. - **AC-2** Discount totals round down to the nearest cent. - **AC-3** Stacking with site-wide promotions follows the higher-of rule. ## Scenario: Apply a valid percent-off code **GIVEN** a cart with subtotal $50.00 and shipping $10.00 **WHEN** the user applies code `SAVE20` (20% off) **THEN** the cart shows subtotal $40.00, shipping $10.00, total $50.00
```

 EXEMPLE plans/apply-discount/README.md

```
# Plan: Apply Discount **Status:** approved **Features:** - [apply-discount](../../features/apply-discount.md) **Author:** cart-team **Effort:** M **Impact:** high ## Context The apply-discount Feature is Approved. This plan breaks it into ordered tasks; each task cites the acceptance criteria it satisfies. ## Tasks ### T1 — Accept a `code` field on the cart Cites: R1.AC-1, R1.AC-2, R1.AC-3 ### T2 — Validate code time-window Cites: R2.AC-1, R2.AC-2 ### T3 — Apply percentage to subtotal, round down Cites: R3.AC-1, R3.AC-2 ### T4 — Higher-of tiebreak vs site-wide promo Cites: R3.AC-3 ### T5 — Confirmation toast on apply / replace Cites: R1.AC-2
```

## Les spécifications sont hiérarchiques. Votre arbre de spécifications aussi.

Une liste plate de cinquante Features devient vite un dépotoir. SpecScore garde l'arbre navigable : les parents portent le périmètre, les enfants portent le détail, et la structure des répertoires reflète la structure du produit telle que votre équipe la conçoit déjà.

**Les questions ouvertes remontent.** Les questions non résolues, à n'importe quelle profondeur, apparaissent dans l'index de chaque parent. Vous voyez ce qui bloque une version depuis le sommet de l'arbre, sans avoir à fouiller pour le trouver.

La plupart des outils de spécification partent du principe qu'une liste plate suffit. Et cela fonctionne — jusqu'au jour où ce n'est plus le cas. SpecScore est conçu pour le moment où la question « où réside cette Feature ? » devient essentielle.

[Voir en direct sur specscore-cli →](https://specscore.studio/app/github.com/specscore/specscore-cli/spec/features/cli?op=explore)

 DE specscore-cli/spec/features/cli/

```
spec/features/cli/ ├── agent/ │ └── setup/ ├── feature/ │ ├── change-status/ │ ├── deps/ │ ├── info/ │ ├── list/ │ ├── new/ │ ├── refs/ │ └── tree/ ├── idea/ │ ├── change-status/ │ ├── new/ │ └── relocate/ ├── spec/ │ └── lint/ │ ├── issue-rules/ ← sous-sous-Feature │ └── plan-rules/ ├── task/ │ ├── info/ │ ├── list/ │ └── new/ └── … 10 autres Features de premier niveau
```

## Ce qui casse quand il n'est pas là.

- ### 🌀 Les spécifications se désynchronisent. La spécification dans le document, le fil sur Slack et le code dans la PR divergent en silence pendant des semaines. Personne ne sait quelle version de la discussion fait foi. Le remède Une seule spécification canonique, dans le dépôt, versionnée avec le code. `specscore lint` s'exécute en CI à chaque push ; l'historique git constitue la piste d'audit. La spécification, le fil et la PR ne peuvent plus diverger en silence — ils partagent le même fichier sous révision.
- ### 🌫️ Les critères d'acceptation restent flous. *« Gérer les erreurs avec élégance »* devait signifier*« afficher un toast et annuler. »* Ou était-ce*« enregistrer dans les logs et réessayer ? »* L'agent doit deviner. Le remède Le linter détecte les critères ambigus avant même qu'une seule ligne de code ne soit écrite. Le verbe échoue au lint car il manque d'objet ou de condition concrète. Corriger l'avertissement oblige à expliciter ce que*« gérer »* veut réellement dire.
- ### 🤖 Les agents livrent la mauvaise chose. Les humains interpolent, posent des questions, précisent. Les agents d'IA, non — ils implémentent le motif le plus fréquent dans leurs données d'entraînement. Le code passe la revue parce qu'il fait**quelque chose** de sensé. Mais ce n'est pas ce que vous vouliez dire. Le remède Une entrée structurée. Les agents d'IA analysent les identifiants REQ, AC et les scénarios `GIVEN / WHEN / THEN`de manière déterministe — rien à interpoler. Chaque tâche du Plan doit citer les AC qu'elle satisfait, de sorte que ce qui est construit soit toujours vérifiable par rapport à ce qui a été spécifié.
- ### 🔁 Vous payez deux fois pour une spécification ambiguë. L'agent construit quelque chose à partir d'un brief flou, vous voyez que c'est erroné et vous lui redemandez — de quatre manières différentes. Chaque fonction inachevée et chaque nouvelle tentative se paient en tokens. Plus la spécification est vague, plus les allers-retours s'accumulent avant d'obtenir le bon résultat. Le remède Passez la spécification au linter avant que l'agent ne commence.`specscore lint` rejette d'entrée les verbes vagues et les critères d'acceptation manquants, permettant à l'agent d'implémenter un brief précis en une seule passe au lieu de tâtonner entre les essais. L'exécution la moins chère est celle que vous n'avez pas à recommencer.
- ### 💸 Les agents paient pour relire vos spécifications. Un agent d'IA qui répond à *« de quoi dépend cette feature ? »* lit le README entier de la feature. Puis chaque index parent. Puis les features sœurs au cas où. Chaque requête est une nouvelle analyse syntaxique. Les tokens s'envolent ; la latence grimpe ; la facture avec. Le remède Des requêtes structurées plutôt que la lecture de fichiers.`specscore feature tree` renvoie la hiérarchie en YAML ; `feature deps` parcourt la chaîne transitive de dépendances ; `feature info`expose le statut, le propriétaire et les questions ouvertes — chacun en un seul appel. L'agent navigue dans le graphe, pas dans la prose.
- ### 🔗 Le code oublie sa spécification. Six mois plus tard, vous déboguez une fonction et personne ne se souvient de quelle feature elle découle. Le lien entre code et spécification résidait dans la tête de quelqu'un, et cette personne est partie. La PR qui l'a introduite a disparu dans les archives. Le remède Des annotations dans le code source. Des commentaires tels que`// specscore: features/checkout/apply-discount/R1.AC-2`rendent le lien lisible par une machine et résistent aux refactorisations.`specscore code deps` répond à*« quelle spécification ce fichier implémente-t-il ? »* en un seul appel ; le linter signale les références pointant vers des spécifications supprimées.
- ### 🏷️ Les changements de statut s'égarent. Vous passez une feature de *Draft* à *Approved*dans son README, mais le features-index parent continue de l'afficher comme Draft. Trois semaines plus tard, un agent lisant l'index croit qu'elle est toujours en cours de révision. L'état réside à deux endroits, et ils se contredisent. Le remède `specscore feature change-status` réécrit le champ Status de la feature et resynchronise la ligne de l'index en une seule étape atomique — si le lint échoue, la réécriture est annulée. L'état existe en un lieu unique et canonique ; l'index est une vue générée de cet état.
- ### 📋 Les spécifications oublient ce qu'elles ignorent. Une spécification se lit comme si elle était close — jusqu'à ce que vous réalisiez que la question*« et que fait-on pour les fuseaux horaires ? »* s'est perdue dans un fil Slack il y a deux mois et n'a jamais atteint le document. Vous êtes en pleine implémentation et personne ne sait quelle était la réponse. Le remède Chaque feature SpecScore comporte une section obligatoire**Outstanding Questions**. Le linter rejette les features qui l'omettent — vide est accepté (`"None at this time."`), mais absente ne l'est pas. Les questions non résolues sont visibles dans le document, consultables via le CLI et impossibles à oublier.

## La façon la plus simple de commencer : SpecStudio Skills pour agents d'IA.

[SpecStudio Skills](https://github.com/specscore/specstudio-skills)est un plugin Claude Code qui transforme le cycle de vie de SpecScore en quatre commandes slash. Installez-le une fois, puis exécutez-les dans l'ordre — de l'idée brute jusqu'au plan exécutable.

```
$ /plugin marketplace add specscore/ai-marketplace $ /plugin install specstudio@specscore
```

 Claude Code autocomplétion

```
> /specstudio: /specstudio:ideate Ajuster une idée brute en une SpecScore Idea /specstudio:specify Transformer une Idea approuvée en spécification de Feature /specstudio:plan Décomposer une Feature en un Plan de tâches /specstudio:implement Exécuter la prochaine tâche du Plan
```

 /ideate → /specify → /plan → /implement Claude Code /ideate

```
> /ideate Réfléchissons à ce que devrait être l'écran du panier pour le tunnel de commande.
```

 Claude Code /specify

```
> /specify Spécifions spec/ideas/checkout-basket.md
```

 Claude Code /plan

```
> /plan Planifier l'implémentation de spec/features/checkout/basket/README.md
```

 Claude Code /implement

```
> /implement Exécuter spec/plans/checkout-basket/README.md
```

Gratuit pour tout usage, y compris commercial. Le code du plugin est disponible sur[specscore/specstudio-skills](https://github.com/specscore/specstudio-skills) — sous licence MIT.

## Vérifiez votre spécification en deux passes.

Un linter déterministe et rapide, puis une revue par IA plus approfondie — exécutés sur la spécification que vous venez de voir. Deux passes, deux formes de certitude.

### Exécutez le linter.

 deterministic

```
$ 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) # exit code 1
```

Le même résultat à chaque exécution. Gratuit, rapide, s'exécute à chaque commit.

### Révisez et évaluez avec l'IA.

 non-deterministic

```
> /score apply-discount.md Grade: B — ready with edits AC-2 vague trigger — name the actor and event AC-3 no error path for an expired code prose reads clean; criteria need tightening
```

Lit pour en saisir le sens, comme un réviseur humain.

## Voici ce qu'il ne détectera pas.

Un linter qui prétend tout détecter ment. SpecScore est un système en couches — un linter déterministe, un réviseur par IA et votre propre jugement — et chaque couche a des limites réelles. Nous les avons toutes documentées : ce que le linter détecte, ce que l'IA détecte et ce qui relève toujours de vous car aucun outil ne peut encore s'en charger.

[Ce que le linter ne détectera pas →](/fr/validators/#limits)

## Ce qui est fourni.

### Le format

Markdown + YAML. Fonctionne dans n'importe quel éditeur de texte. Aucun nouvel outil requis pour commencer à écrire.

### Le linter

CLI en Go. Valide la structure, les références et l'intégrité. Quitte avec un code d'erreur non nul en cas d'échec — fonctionne dans votre terminal et dans votre CI.

## Apportez vos propres outils.

SpecScore, ce sont simplement des fichiers dans votre dépôt. Aucun SaaS auquel s'abonner. Aucun orchestrateur imposé. Utilisez-le avec Linear, Jira, GitHub Projects, du simple Markdown dans un dossier, ou même sans aucun gestionnaire de projet. Le format et le linter se moquent de l'endroit où vivent vos tickets.

## Comment SpecScore se compare.

Le développement piloté par les spécifications est un domaine effervescent. Voici où se positionne SpecScore face aux alternatives — en toute franchise.

 Plain Markdown Le choix par défaut. SpecScore est ce vers quoi votre Markdown évolue. OpenSpec Une bonne rampe de lancement. SpecScore apporte les garde-fous. Spec Kit Spec Kit est le workflow. SpecScore est l'artefact. Datarim Datarim exécute le pipeline. SpecScore est ce qui subsiste après. CodeSpeak CodeSpeak parie sur un compilateur. SpecScore parie sur un format. Kiro Kiro rédige la spec dans son IDE. SpecScore est le format que la CI peut linter. Tessl Tessl défend la spec comme source. SpecScore linte la spec à côté du code. BMAD Method BMAD déroule la boucle agile. SpecScore est l’artefact qu’une pull request peut vérifier. Task Master AI Task Master découpe un PRD en tâches. SpecScore est la spec que ces tâches peuvent citer.

[Voir le comparatif complet →](/fr/vs/)

## Vous préférez le CLI ?

Vous n'utilisez pas d'agents d'IA, ou vous avez besoin de valider vos spécifications dans votre pipeline de CI ? Il y a un CLI pour cela. S'installe en 60 secondes — sans compte, sans télémétrie, fonctionne sur n'importe quel dossier de spécifications en Markdown.

 Linux / macOS Windows

```
$ curl -fsSL https://specscore.md/install/get-cli | sh
```

```
> irm https://specscore.md/install/get-cli.ps1 | iex
```

Passez le linter sur l'exemple de spécification fourni avec le binaire :

```
$ specscore lint examples/checkout/apply-discount.md
```

Observez le résultat :

```
examples/checkout/apply-discount.md ✓ R1 has acceptance criteria ✓ R2 has acceptance criteria ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found ✗ section "Open Questions" missing 3 problems exit 1
```

Lire la [documentation complète](/docs/) · [Contribuer sur GitHub](https://github.com/specscore/specscore)

## Bâti sur SpecScore.

- ### DataTug Explorez les schémas de bases de données, composez et exécutez des requêtes et comprenez les résultats avec DataTug. SpecScore guide ses exigences et critères d'acceptation. [datatug.app →](https://datatug.app)[Outils du workflow →](https://datatug.app/en/under-the-hood/tools-we-built/)
- ### MeaningGraph Registre ouvert de modèles de données et de définitions sémantiques, conservées dans vos propres dépôts Git et reliées aux modèles et au code. [meaninggraph.io →](https://meaninggraph.io/)[Parcourir le registre →](https://meaninggraph.io/registry/)
- ### Codegrapher Moteur de graphe de code pour une exploration rapide du code et une liaison bidirectionnelle entre spécifications et code. [codegrapher.dev →](https://codegrapher.dev/)
- ### DALgo Couche d'accès aux données en Go, spécifiée avec SpecScore. [dal-go.github.io →](https://dal-go.github.io/)
- ### inGitDB Base de données versionnée adossée à Git, spécifiée avec SpecScore. [ingitdb.com →](https://ingitdb.com/)
- ### Rehearse Couche de preuve d'acceptation : exécute réellement les critères d'acceptation d'une spécification, avec des vérifications réutilisables et sans code d'adaptation. [rehearse.ink →](https://rehearse.ink)
- ### SpecScore Studio Interface web pour visualiser et éditer les spécifications SpecScore. [specscore.studio →](https://specscore.studio)

## Des questions ?

Voici les questions qui reviennent le plus souvent. Chacune renvoie vers la réponse complète sur la [page FAQ](/fr/faq/).

 En quoi SpecScore diffère-t-il de spec-kit ?

spec-kit est une méthodologie ; SpecScore est un format de stockage pour les spécifications que vous écrivez, assorti d'un CLI. Ils se complètent — une extension spec-kit écrivant en SpecScore est en préparation.

 Réponse complète → En quoi les SpecStudio Skills diffèrent-elles de Superpowers et agent-skills ?

L'esprit est similaire — tous trois guident les agents d'IA à travers ideate → specify → plan → implement. SpecStudio Skills écrit des artefacts au format SpecScore et utilise le CLI `specscore` pour les requêtes et les changements d'état ; les autres lisent et écrivent directement les fichiers. Choisissez SpecStudio quand la consommation de tokens compte.

 Réponse complète → Pourquoi un CLI — pourquoi ne pas simplement installer des skills ?

Les skills ne peuvent pas garantir de façon fiable l'intégrité référentielle, renvoyer des requêtes filtrées sans lire chaque fichier, ni modifier le bon champ de statut au bon moment. Le CLI accomplit chacune de ces tâches en un seul appel. Les skills doivent lire chaque fichier pour parvenir au même résultat.

 Réponse complète → Pourquoi « SpecScore » — qu'est-ce qui est noté ?

Deux lectures, toutes deux intentionnelles. Partition — une partition structurée d'exigences. Et une note de qualité au sens propre — le linter du CLI fournit la note déterministe, et la skill`/score` attribue une note de A à F évaluée par l'IA sur la maturité de l'artefact.

 Réponse complète → Où sont les chiffres sur l'économie de tokens ?

Une comparaison méthodique côte à côte est en cours de préparation avant l'article sur Habr. Structurellement : le CLI renvoie une liste courte et structurée ; un agent sans CLI lit N documents à la place.

 Réponse complète → Quelle est la licence de SpecScore ?

La spécification et la documentation du dépôt public [specscore/specscore](https://github.com/specscore/specscore) sont sous [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE). L'interface en ligne de commande (CLI) de référence dans [specscore/specscore-cli](https://github.com/specscore/specscore-cli) est sous [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE).

 Réponse complète → SpecScore impose-t-il un outil d'IA précis ?

Non. Les spécifications sont des fichiers texte dans le dépôt. La CLI est un binaire local. Les AI Skills de ce site enveloppent cette CLI pour les agents qui savent exécuter des skills. Le format n'impose pas un fournisseur.

 Réponse complète → Qu'est-ce que le développement piloté par les spécifications (SDD) ?

Le développement piloté par les spécifications (SDD) consiste à écrire une spécification testable — exigences et critères d'acceptation — avant le code, puis à vérifier le résultat contre cette spécification. SpecScore est un format de fichier pour ces spécifications.

 Réponse complète →

## Définissez la réussite. Puis faites-lui une place.

SpecScore définit ce que signifie « terminé ». Un engagement hebdomadaire aide à choisir la suite. Reliez les deux par une courte revue des résultats.

 Choisir votre prochain résultat terminé → Découvrir CommittedMe (en anglais) →