Spec Kit en Full-Stack Réel : Comment 17 Sprints ont Mené le Suivi des Habitudes en Production

Spec-Driven Development a réussi à aboutir non pas à une démo d'une soirée, mais à une véritable version complète full-stack. Le cas LifeSync décrit 17 sprints de développement d'un suivi des habitudes et des objectifs, deux référentiels séparés, des centaines de tests et un lancement en production — et conduit à la conclusion principale : à grande échelle, SDD est précieux non pas pour la vitesse de génération de code, mais pour empêcher la perte de contrôle lorsque le backend, le frontend et l'infrastructure commencent à tirer le projet dans des directions différentes. L'étude de cas utilise un service B2C pour les habitudes et les objectifs comme exemple.

Le backend est construit sur Spring Boot 3.5 et Java 21, organisé selon une architecture hexagonale sur six modules Maven, utilise jOOQ au lieu de JPA, Kafka pour la logique événementielle, JWT RS256 et OpenAPI 3.1 comme contrat d'API principal.

Le frontend est construit sur React 19, TypeScript 5.9, Vite 8, TanStack React Query, Zustand et shadcn/ui avec Tailwind CSS. Au cours de 17 sprints, le projet est passé à 251 tests côté serveur et 77 tests côté client, a reçu 19 migrations Liquibase et a été lancé en production : backend déployé sur Railway, frontend sur Vercel.

L'insight central du cas est que l'échelle exigeait une discipline différente pour travailler avec l'IA. Si un petit projet pouvait se contenter d'un chat pensant et d'un environnement d'exécution, l'auteur en est venu à un schéma de trois chats pour le projet full-stack. Un contexte séparé est nécessaire pour le backend, un séparé pour le frontend, et un autre pour coordonner les décisions communes qui affectent les deux référentiels : déploiement, fonctionnalités transversales, changements d'API et rétrospectives.

Ceci est complété par deux fichiers de constitution différents. Pour le backend, le document a grandi au fil du temps d'un modèle à 437 lignes et a intégré des règles sur les migrations, les commits, le style et OpenAPI. Pour le frontend, la constitution était beaucoup plus compacte — 137 lignes, parce que la pile et les modèles étaient plus strictement définis dès le départ.

Un accent particulier est mis sur la commande speckit.analyze, que l'auteur utilise comme une boucle de retour obligatoire après chaque sprint. Elle ne remplace pas les tests et ne prétend pas être un linter, mais réconcilie entre spec.

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

Selon l'auteur, c'est exactement ce type d'analyse qui a aidé à détecter un problème critique dans le sprint Kafka du backend : la publication d'événements sur plusieurs cas d'usage se produisait à l'intérieur d'une transaction sans un try-catch protecteur. Dans l'environnement de test, l'erreur ne s'est pas manifestée parce que Kafka dans les conteneurs était toujours disponible, mais en cas d'échec réel, cela aurait pu restaurer des données déjà sauvegardé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é améliorée et les vérifications d'intégration ont été élargies.

Un autre pilier important est l'approche API-first en tant que contrat entre les deux référentiels. Dans le projet, un module séparé est alloué à cela avec une spécification OpenAPI d'environ 2.669 lignes et 32 endpoints.

Le backend génère les interfaces de contrôleurs Java à partir de celle-ci, et le frontend utilise le même YAML comme unique source de vérité et maintient manuellement les types TypeScript pour les scénarios réels d'interface utilisateur. L'auteur note spécifiquement que speckit.analyze ne peut pas valider automatiquement la cohérence entre deux référentiels, les vérifications entre référentiels doivent donc toujours être effectuées manuellement par le contexte de coordination.

Mais même sous cette forme, le schéma réduit le risque de désynchronisation silencieuse entre le serveur et l'interface : si l'API change, elle est d'abord enregistrée dans la spécification, puis apparaît à l'étape de génération d'interface ou de compilation du frontend. La conclusion pratique de ce cas est assez stricte : SDD s'adapte bien à l'échelle, mais seulement si vous le traitez comme un système de gestion des changements, pas comme un moyen de demander à l'IA d'écrire une fonctionnalité. Sur des tâches courtes, vous pourriez ne pas remarquer la différence, mais au cours de dizaines de sprints, les éléments ennuyeux du processus commencent à s'amortir — constitutions vivantes, contextes séparés, artefacts formels et vérifications régulières de leur cohérence.

Le cas est intéressant car il montre SDD non pas sur un MVP jouet, mais sur un projet qui a déjà la production, une boucle de test, des référentiels séparés et un coût réel des erreurs architecturales et de contrat.