SpecScore vs Plain Markdown
La plupart des équipes disposent déjà de « spécifications » — sous forme de Markdown ad-hoc dans un dossier docs, de pages Notion ou de tickets Jira. C'est gratuit, déjà en place et fonctionnel. SpecScore est le même Markdown, avec la structure qu'un agent d'IA peut linter, interroger et relier directement au code.
Ce qu'ils ont en commun.
Ce que le choix par défaut fait bien.
Le Markdown brut, Notion et Jira sont le standard par défaut historique. Ils l'ont mérité.
Zéro courbe d'apprentissage
Aucun schéma, aucun champ obligatoire, aucun CLI dans le flux. Ouvrez un fichier, commencez à écrire. Pour une note ponctuelle ou un micro-projet, c'est idéal — la structure dont vous n'avez pas besoin n'est que friction.
Déjà installé
Votre équipe utilise déjà Notion, Confluence ou un dossier docs/. Rien à adopter, rien à migrer. L'option avec le moins de friction est celle que vous utilisez déjà.
Universellement portable
Le Markdown brut s'ouvre partout et survit à n'importe quel outil. SpecScore s'appuie précisément sur cette propriété — c'est pourquoi SpecScore est aussi du Markdown, pas une base de données.
Comparaison des fonctionnalités.
La différence n'est pas le fichier — c'est ce qu'un agent peut en faire.
| Capacité | Plain Markdown / Notion | SpecScore |
|---|---|---|
| Format | Markdown libre / docs | Markdown + frontmatter YAML (structuré) |
| Où vivent les exigences | Jira, Notion, Slack, la tête de quelqu'un | Dans le dépôt, aux côtés du code |
| « Cette spécification est-elle complète ? » | Un humain la lit et décide | specscore lint — automatique |
| Détection d'ambiguïté | Aucune — les verbes flous passent inaperçus | Verbes flous, AC manquants, références orphelines signalés |
| Identifiants d'exigences / AC | Aucun | Identifiants adressables par machine (REQ: slug) |
| État du cycle de vie | Implicite, s'il est suivi | Appliqué — Draft → Approved → Implementing → Stable |
| Traçabilité code-vers-spécification | Aucune | Annotations specscore: + trailers Verifies: |
| Navigation par les agents | Lire chaque fichier pour trouver quelque chose | Interroger le graphe de spécifications depuis le CLI |
| Porte de qualité en CI | Aucune | specscore lint quitte avec un code non nul, comme un linter |
| Courbe d'apprentissage | Nulle | Un format à apprendre (progressif) |
| Coût / licence | Gratuit | Gratuit, open source |
Où SpecScore va plus loin.
L'ambiguïté est détectée, pas interprétée
Avec des spécifications informelles, chaque interaction avec un agent commence par une interprétation — « le login devrait fonctionner » est un coup de dé entre correct et plausible-mais-faux. Le lint de SpecScore signale le verbe flou et le critère d'acceptation manquant avant qu'un agent n'agisse.
$ specscore lint auth/login.md ✗ R1 "should work" — non mesurable ✗ R1 no acceptance criteria
La mauvaise interprétation cesse de faire boule de neige
Un agent interprète mal une exigence, un deuxième bâtit dessus, un troisième dépend des deux — et vous ne vous en apercevez que trois agents plus tard. Des critères d'acceptation structurés donnent à chaque agent les mêmes conditions de validation, évitant toute dérive d'interprétation.
Le code remonte jusqu'à la spécification
Les documents simples n'ont aucun lien avec le code qui les implémente. SpecScore ajoute des annotations specscore: dans le code et des trailers Verifies:dans les commits — specscore code refs répond de manière déterministe à « quel code implémente cette exigence ? »
Une seule spécification au lieu de quarante tickets
Un nouveau coéquipier (ou un agent vierge) lit une spécification de feature avec tout son contexte, au lieu de devoir reconstituer l'intention à travers quarante tickets Jira et un fil Slack.
Les agents interrogent au lieu de relire
Dans un dossier de docs, savoir « qu'est-ce qui est en cours ? » implique d'ouvrir des fichiers. Dans SpecScore, c'est specscore feature list — le graphe répond depuis le CLI, afin que les agents ne saturent pas leur contexte en relisant tout le dépôt.
La qualité est appliquée en CI
Les spécifications libres n'ont pas de garde-fou — une spécification à moitié écrite est fusionnée aussi facilement qu'une spécification complète. specscore lint quitte avec un code non nul face aux anomalies, tout comme ESLint ou go vet protègent le code.
Quand utiliser chacun.
Plain Markdown convient quand…
- C'est une note ponctuelle, un spike ou un projet trop modeste pour nécessiter de la structure.
- Aucun agent d'IA ne construira à partir du doc — un humain le lit et le comprend naturellement.
- Vous notez une idée approximative, pas une exigence destinée à être implémentée.
Adoptez SpecScore quand…
- Un agent d'IA construit à partir de la spécification — l'ambiguïté devient alors du code erroné.
- Plusieurs agents ou développeurs s'appuient sur les mêmes exigences.
- Vous avez besoin de savoir quel code implémente quelle exigence.
- « Cette spécification est-elle prête ? » doit trouver sa réponse via un outil, pas une réunion.
- Le projet est assez vaste pour que tout relire ne passe plus à l'échelle.
Faites évoluer les spécifications que vous avez déjà.
Vous n'avez pas à convertir votre backlog ni à changer vos outils. Choisissez votre prochaine feature, rédigez une spécification SpecScore pour elle et lancez specscore lint — observez si elle repère un point que votre ticket avait omis. Ajoutez des annotations specscore:lors de son implémentation. N'étendez l'usage au sprint suivant que si cela vous a aidé.
Le Markdown brut est la rampe de lancement. SpecScore est ce vers quoi il évolue.
Autres comparaisons.
Le même format, à côté d’autres outils de développement piloté par les spécifications :
Tous ensemble, sur une page : meilleurs outils de développement piloté par les spécifications en 2026.
Retour
Cette comparaison repose sur une documentation et un code source publics. Quelque chose est faux ou périmé ? ouvrez un ticket de correction. Voulez-vous que nous comparions SpecScore à un autre outil ? demandez-en une.