Taproot 1.0 : Quand la spec n'est plus optionnelle

« Une bonne spec est l’input à plus fort levier que vous puissiez donner à une IA. » J’ai écrit cette phrase dans mon post sur le Spec-Driven Development. Elle reste vraie. Mais elle a une lacune : une spec qui n’est pas appliquée est une spec qui s’érode.

Dans ce même post, j’ai mentionné Taproot comme l’un des cinq frameworks — mon propre projet, construit précisément à partir de cette lacune. La version 1.0 est disponible. Il est temps de décrire ce qu’il fait différemment.

Le problème derrière le problème

Presque toutes les approches établies du Spec-Driven Development — PRDs, CLAUDE.md, user stories dans un wiki — partagent une même faiblesse : ce sont des suggestions. La spec se trouve dans le projet, le développeur est censé la consulter, l’agent IA est censé la prendre en compte, le reviewer est censé la vérifier. Tout le monde devrait. Personne n’est obligé.

Ça fonctionne tant que l’équipe est disciplinée et que la codebase reste petite. Dans les projets réels, le système dérive : les specs ne sont pas mises à jour, du code est écrit sans spec, une fonctionnalité contredit une décision d’architecture que plus personne ne lit. L’agent IA applique les règles de sécurité de manière sporadique — la protection CSRF est présente dans quatre formulaires sur cinq, absente dans le cinquième. Ce n’est pas un problème de méthode. C’est un problème d’application.

De la recommandation à la règle

Taproot repose sur une décision unique : la spec n’est pas un document à côté du code. C’est une condition de commit.

À chaque git commit, un hook pre-commit vérifie trois choses selon ce qui est commité :

• Nouvelle implémentation : La spec de comportement associée doit être complète (Definition of Ready) — acteurs nommés, critères d’acceptation définis, cas limites adressés.
• Code source : Les tests doivent passer, toutes les conditions configurées satisfaites (Definition of Done).
• Specs : Elles sont vérifiées par rapport aux vérités globales du projet dans taproot/global-truths/. Une spec qui dit implicitement « les prix sont affichés TVA incluse » est rejetée si la vérité globale indique « les prix sont toujours hors TVA ». La contradiction est détectée le jour où elle apparaît.

La différence avec « la spec devrait être cohérente » n’est pas de degré mais de nature. La discipline devient mécanique.

Les exigences comme fichiers de première classe

Les specs vivent comme des fichiers Markdown dans le dépôt, dans une hiérarchie à trois niveaux :

taproot/
├── password-reset/        ← Intent : pourquoi existe-t-il ?
│   ├── intent.md
│   └── request-reset/     ← Behaviour : que fait le système ?
│       ├── usecase.md
│       └── email-trigger/ ← Implementation : comment est-il construit ?
│           └── impl.md

Chaque fichier source est traçable à travers cette hiérarchie jusqu’à un intent. Inversement, chaque exigence sans code est visible, et chaque code sans exigence également. La traçabilité n’est pas une fonctionnalité à maintenir séparément — elle émerge de la structure.

La boucle de travail se réduit à deux commandes : /tr-ineed user authentication décrit une exigence, l’agent écrit la spec. /tr-implement taproot/auth/ construit le code, les tests et la traçabilité. Spec d’abord, code ensuite, le hook vérifie les deux.

Nouveau dans 1.0 : planification sur plusieurs exigences

La plupart des workflows agentiques sont conçus pour une exigence à la fois. Ça ne passe pas à l’échelle quand on veut laisser dix items à un agent avant une réunion.

/tr-plan construit un plan priorisé à partir du backlog et des specs non implémentées. /tr-plan-execute l’exécute — les items réalisables de manière autonome passent en continu, les items nécessitant une décision humaine font une pause. Quand vous revenez du café, les parties autonomes sont faites et les questions ouvertes sont clairement formulées.

Ce que Taproot n’est pas

Taproot écrit des intents, des use cases et des specs d’implémentation, gère un backlog et planifie l’exécution — des fonctions précédemment couvertes par un système de tickets et un business analyst. Pour de nombreux projets, c’est suffisant. Pour les grandes organisations avec leurs propres processus de parties prenantes, Taproot complète le système de tickets existant plutôt que de le remplacer : le ticket porte la décision métier, la spec Taproot porte la vérité technique, et les deux se référencent mutuellement.

Taproot n’est pas un nouvel agent. Il fonctionne avec Claude Code, Cursor ou Gemini. La logique réside dans les fichiers et le hook Git, pas dans un runtime propriétaire — changer d’agent affecte la configuration de l’adaptateur, pas les specs.

Et ce n’est pas du Waterfall. Les specs évoluent ; la différence est seulement que les changements sont suivis structurellement plutôt que de faire confiance aux bonnes intentions.

Démarrer

npx @imix/taproot init

Cela installe l’adaptateur et le hook pre-commit. Pour les codebases existantes, il y a /tr-discover, qui extrait une hiérarchie initiale — un point de départ utilisable pour les situations brownfield qu’on n’aborderait sinon jamais.

Le dépôt : github.com/imix/taproot. Licence MIT. Feedback et issues bienvenus.

La position

Le post précédent se terminait par la thèse que les meilleurs ingénieurs IA de 2026 seront ceux qui auront compris qu’une bonne spec est l’input à plus fort levier qu’on puisse donner. Taproot va un cran plus loin : une bonne spec est nécessaire mais pas suffisante. Il faut aussi un mécanisme qui garantit qu’elle produit réellement un effet — même quand l’équipe est fatiguée, que la deadline approche et que le reviewer est surchargé.

Si ça fonctionne, c’est la pratique qui le décidera. C’est pourquoi 1.0 est un début, pas une conclusion.

Taproot est développé chez Perito IT à Berne. Ateliers pratiques sur le Spec-Driven Development sur demande via perito.ch.