SpecScore vs Tessl
Développement piloté par les spécifications (SDD) signifie que la spécification du comportement prévu est écrite avant le code. Tessl (Tessl AI Ltd) est, au 30 octobre 2026, une plateforme d’habilitation des agents : un registre et un plan de contrôle pour les skills, règles et plugins que chargent les agents de programmation. « Spec as source » est l’affirmation la plus forte de l’essai de juin 2025 de Tessl : la spécification est l’artefact durable, et le code en est dérivé. SpecScore est un format de fichier à code source ouvert pour cette spécification, vérifié par une interface en ligne de commande (CLI). L’intégration continue (CI) — une vérification automatique à chaque changement proposé — exécute cette vérification dans ce dépôt.
Ce qu'ils partagent.
Ce que Tessl fait bien.
Deux surfaces Tessl distinctes se confondent facilement. Les notes ci-dessous les séparent, d’après des pages lues le 30 octobre 2026.
Un argument clair pour le spec as source
L’essai de Simon Maple du 27 juin 2025 dit qu’un document d’exigences produit (PRD) — de la prose écrite pour des personnes sur ce qu’il faut construire — se périme en général, tandis que le code devient la seule source de vérité. L’alternative de l’essai : la spécification est ce que vous changez, et un grand modèle de langage (LLM) en génère le code, les tests et la documentation. C’est une position réelle, pas un slogan.
Une plateforme pour le contexte de l’agent
La documentation de Tessl décrit un registre, une gouvernance qui analyse et note les skills, des évaluations et de l’observabilité entre agents. La documentation dit que les skills sont de simples artefacts dans votre dépôt, et que la plateforme fonctionne avec Claude Code, Cursor, Copilot, Gemini et d’autres. Noter, ici, signifie noter une skill, pas noter une spécification de produit.
Un tile officiel de développement piloté par les spécifications, avec des vérifications shell
Le tile tessl-labs/spec-driven-development, sous licence MIT dans le dépôt public du tile, apprend à un agent à interroger, écrire des fichiers .spec.md, attendre l’approbation, puis implémenter. La page du registre cite scripts/validate-specs.sh et scripts/check-spec-links.sh pour le frontmatter, targets et les liens [@test]. La même page dit que le tile est un contexte de pilotage : pas de commandes spéciales, pas de cadre logiciel.
Comparaison des fonctionnalités.
« Spec as source » est l’essai de Tessl. Le tile est un paquet de skills au-dessus de la plateforme actuelle. SpecScore est un format avec un linter versionné.
| Capacité | Tessl | SpecScore |
|---|---|---|
| Rôle principal | Plateforme de skills pour agents, plus un tile de développement piloté par les spécifications et un essai de 2025 sur le spec as source | Format de spécification ouvert + CLI |
| Ce qu’est la spécification | Essai : la source durable à partir de laquelle le code est généré. Tile : un .spec.md contre lequel l’agent implémente, et vous gardez le code. | Un contrat à côté du code. Le lint ne régénère pas le code. |
| Forme de la spécification | Tile : frontmatter YAML, globs targets et liens [@test] vers des fichiers de test | Markdown + YAML, REQ: slug, Étant donné/Quand/Alors |
| Vérifier la spécification | Scripts shell livrés avec le tile, pour le frontmatter et les liens de ce tile | specscore spec lint sur le format SpecScore, dans la CI de ce dépôt. /score est une note d’IA manuelle. |
| Licence | Le tile est MIT. La plateforme est un produit. La documentation ne publie pas le code source de la plateforme. | CC BY 4.0 pour le format · Apache-2.0 pour le CLI |
| Prix | La page d’accueil de Tessl, lue le 30 octobre 2026, décrit un palier gratuit (1 000 crédits par mois sur un espace de travail) et des offres entreprise payantes. | Sans frais pour le format ni pour le CLI |
Ce que SpecScore apporte en plus.
Un format publié, pas un script du tile
Les scripts shell du tile vérifient les fichiers .spec.md que ce tile a demandé à l’agent d’écrire. SpecScore vérifie un format documenté sur ce site. dogfood.yml installe une version épinglée de specscore et exécute specscore spec lint. /score n’est pas cette exécution : c’est une skill manuelle qui se termine avec un code non nul quand les relecteurs d’IA signalent des problèmes.
$ 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)
Vous gardez le code dans les deux cas — l’essai va plus loin
L’essai de 2025 dit que le code devrait être régénéré à partir de la spécification. Le tile, sur la page lue le 30 octobre 2026, fait implémenter l’agent contre une spécification approuvée et ne décrit pas de compilateur qui remplacerait votre arborescence source. SpecScore ne retire jamais le code. La spécification est le contrat relu ; le code reste le vôtre.
Identité de l’exigence
Le tile pointe une exigence vers des fichiers avec targets et [@test]. SpecScore nomme l’exigence REQ: slug pour qu’un plan, une tâche et un trailer de commit puissent la citer après le déplacement des fichiers.
Quand choisir l'un ou l'autre.
Choisissez Tessl quand…
- Vous avez besoin d’un registre, d’évaluations et d’une gouvernance pour des skills partagées entre de nombreux agents et dépôts.
- Vous voulez le déroulement de l’essai spec as source comme tile de pilotage : interroger, approuver un .spec.md, puis implémenter.
- Vous payez déjà la plateforme Tessl, ou vous l’essayez, et vous voulez son tile de spécification dans ce registre.
Utilisez SpecScore quand…
- Le format de spécification lui-même doit être valide dans la CI, y compris dans des dépôts qui n’installent pas Tessl.
- Vous voulez des identifiants d’exigences et un linter qui n’appelle pas de modèle.
- Vous voulez le format à code source ouvert sous une licence Creative Commons, distinct d’une plateforme de skills.
Spec as source, et une spécification que l’on peut linter.
L’essai de Tessl a raison : un PRD périmé perd face au code. Une vérification de format est ce qui permet à la spécification de rester ce en quoi vous avez confiance. SpecScore ne génère pas votre application à partir de la spécification. Il fait échouer la spécification dans la CI quand la structure, les liens ou le statut sont faux.
Utilisez Tessl si vous voulez la plateforme et le tile. Utilisez SpecScore si l’artefact dans git est ce que la pull request doit prouver.
Sources.
Les pages publiques ci-dessous ont été lues le 30 octobre 2026. Les prix, les noms d’offres et les versions changent.
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.