Spec Kit sur un vrai projet full-stack : comment 17 sprints ont mené un tracker d'habitudes en production

Le Spec-Driven Development a dépassé la démo d'une soirée pour aller jusqu'à une vraie livraison full-stack. Le cas LifeSync décrit 17 sprints de développement d'un tracker d'habitudes et d'objectifs, deux dépôts distincts, des centaines de tests et un passage en production. Sa conclusion principale : sur un gros projet, le SDD est utile non pour la vitesse de génération de code, mais parce qu'il évite de perdre le contrôle quand le backend, le frontend et l'infrastructure tirent le projet dans des directions différentes.

L'exemple est un service B2C d'habitudes et d'objectifs. Le backend repose sur Spring Boot 3.5 et Java 21, suit une architecture hexagonale répartie en six modules Maven, et utilise jOOQ à la place de JPA, Kafka pour la logique événementielle, JWT RS256 et OpenAPI 3.1 comme contrat principal de l'API. Le frontend est construit avec React 19, TypeScript 5.9, Vite 8, TanStack React Query, Zustand et shadcn/ui avec Tailwind CSS.

En 17 sprints, le projet est monté à 251 tests côté serveur et 77 côté client, a accumulé 19 migrations Liquibase et est passé en production : le backend est déployé sur Railway, le frontend sur Vercel.

L'idée centrale du cas : l'échelle a exigé une autre discipline de travail avec l'IA. Dans un petit projet, un chat de réflexion et un environnement d'exécution suffisaient. En full-stack, l'auteur est arrivé à un schéma de trois chats : un contexte pour le backend, un pour le frontend, et un dernier pour coordonner les décisions communes qui touchent les deux dépôts, comme le déploiement, les fonctionnalités transverses, les changements d'API et les rétrospectives.

S'y ajoutent deux fichiers de constitution distincts. Celui du backend est passé au fil du temps d'un modèle à 437 lignes et a absorbé des règles sur les migrations, les commits, le style et OpenAPI. La constitution du frontend est nettement plus compacte, avec 137 lignes, car le stack et les patterns y étaient définis de façon plus stricte dès le départ.

L'auteur insiste sur la commande speckit.analyze, qu'il utilise comme boucle de retour obligatoire après chaque sprint. Elle ne remplace pas les tests et ne prétend pas être un linter : elle recoupe entre eux spec.

md, plan.md, tasks.md et l'implémentation réelle.

Selon l'auteur, c'est cette analyse qui a permis de repérer un problème critique dans le sprint backend consacré à Kafka : dans plusieurs cas d'usage, la publication d'événements avait lieu à l'intérieur d'une transaction, sans try-catch de protection. L'erreur ne se manifestait pas en environnement de test, car Kafka dans les conteneurs était toujours disponible, mais lors d'une panne réelle, elle aurait pu annuler des données déjà enregistrées et laisser le système dans un état incohérent. Après l'analyse, une protection a été ajoutée au code, la logique de retry a été affinée et les vérifications d'intégration ont été étendues.

Un autre appui important est l'approche API-first comme contrat entre les deux dépôts. Le projet y consacre un module dédié, avec une spécification OpenAPI d'environ 2669 lignes et 32 endpoints. Le backend en génère les interfaces Java des contrôleurs, tandis que le frontend s'appuie sur le même YAML comme unique source de vérité et maintient à la main les types TypeScript adaptés aux scénarios réels de l'interface.

L'auteur souligne que speckit.analyze ne sait pas valider automatiquement la cohérence entre les deux dépôts à la fois ; les vérifications inter-dépôts doivent donc encore être faites à la main via le contexte de coordination. Même ainsi, le schéma réduit le risque de désynchronisation silencieuse entre serveur et interface : si l'API change, le changement est d'abord consigné dans la spécification, puis se manifeste lors de la génération des interfaces ou de la compilation du frontend.

La leçon pratique est plutôt sévère : le SDD passe à l'échelle, mais seulement si on le traite comme un système de gestion du changement et non comme un moyen de demander à l'IA d'écrire une fonctionnalité. Sur des tâches courtes, on peut ne pas voir la différence, mais sur des dizaines de sprints, ce sont justement les éléments ennuyeux du processus qui s'avèrent rentables : des constitutions vivantes, des contextes séparés, des artefacts formels et une vérification régulière de leur cohérence.

Le cas est intéressant parce qu'il montre le SDD non sur un MVP jouet, mais sur un projet qui a déjà une production, un circuit de tests, des dépôts séparés et un coût réel des erreurs d'architecture et de contrats.