BMad, Superpower, OpenSpec : trois reboots d'un même projet en Spec-Driven Development
Un peu de contexte : lead tech fullstack depuis plus de 20 ans, j'avais déjà le site vitrine de Black Speech Production pour mon association d'organisation de concerts à Nantes, mais qui avait surtout besoin d'une grosse mise à jour, fonctionnelle et technique.
Ce site était statique, la contribution manuelle est lourde. Résultat : plusieurs années sans la moindre évolution.
Autant repartir d'une page blanche, et en profiter pour tester l'IA sur ce chantier.
C'est donc un projet perso, c'est-à-dire pas de deadline, des sessions de travail espacées et irrégulières.
Sur cette refonte, j'ai exploré le vibe coding, puis testé trois outils de Spec-Driven Development.
Voici mon retour d'expérience.
Le vibe coding : on avance, mais on ne construit rien
Premier reboot vers mai 2025 avec Junie, pour les améliorations fonctionnelles et techniques du site web.
En Next.js, avec un design system via Storybook, deux technos que je connaissais déjà.
Je suis parti avec mon idée en tête, sans plan écrit.
Le code avançait bien, mais lentement, pour des raisons qui tenaient autant à moi qu'à l'outil : les plans générés par Junie pour chaque tâche étaient solides, l'intégration à l'IDE aussi.
La génération des stories Storybook, elle, s'en sortait très bien.
Le design system n'était pas vraiment utile à ce stade : une seule IHM était en cible pour le moment.
Mon mode opératoire n'aidait pas non plus : j'ouvrais le code, je regardais ce qui manquait, puis je demandais à Junie de traiter ce manque, un point à la fois.
J'avais aussi anticipé plein de besoins d'évolutions, ce qui a alourdi la quantité de travail à réaliser, incompatible avec le temps que je pouvais apporter au projet, et je n'étais pas focus sur un MVP.
Résultat : je n'ai jamais fini, avec une grosse coupure entre deux sessions jusqu'à fin 2025, et perte complète de l'état d'avancement à la reprise.
Le vrai problème n'était pourtant ni la vitesse ni la qualité du code : c'était l'absence de fil conducteur entre deux sessions espacées, et l'absence de priorisation des tâches restantes.
Rien qui capture ce qui avait été décidé, rien à relire pour reprendre le contexte, rien pour savoir par quoi continuer.
C'est cette absence de mémoire écrite, associée à cette coupure de plusieurs mois, qui a fini par me convaincre qu'il fallait autre chose.
J'ai tenté de construire mon propre workflow sous Junie pour résoudre ce problème : une bonne intuition, mais trop chronophage à mettre en place par rapport à ma disponibilité sur ce projet.
Ma veille techno et des échanges avec des collègues m'ont fait découvrir que d'autres avaient déjà formalisé cette même idée : le Spec-Driven Development (SDD), une méthode qui s'ajoute par-dessus un agent de code IA comme Junie ou Claude Code. Pas un agent en soi donc, mais du contexte et des instructions pour un agent.
J'avais envie de la tester, et de rebooter le projet une nouvelle fois.
BMad : puissant pour brainstormer, mais à cadrer sérieusement
Deuxième reboot, en février 2026, cette fois avec BMad (Breakthrough Method for Agile AI-Driven Development, open source, plus de 52 000 étoiles GitHub), mon premier outil de SDD, utilisé par-dessus Junie.
L'outil organise 21 agents spécialisés répartis en rôles agiles (product owner, architecte, développeur, testeur) sur quatre phases : analyse (brainstorming, recherche), planning (PRD, specs techniques), solutioning (architecture) puis implémentation, avec un découpage façon Scrum en « story files » et sprints qui isolent le contexte de chaque tâche.
La phase de brainstorming est solide, même utilisée en solo avec l'équipe d'agents de BMad.
Sur ce site web, c'était aussi l'occasion de découvrir une nouvelle techno : je suis parti sur du Rust.
Autre point fort : la sauvegarde des tâches à faire dans les story files rend la reprise du travail beaucoup plus simple.
Exactement ce qui manquait en vibe coding pur : pas de plan d'action global pour le projet, juste des plans éphémères par tâche.
Le côté multi-agents est aussi un vrai plus : avoir plusieurs rôles spécialisés en parallèle donne plusieurs points de vue sur le même problème, chacun challenge les autres.
Le découpage façon Scrum en story files et sprints est bien pensé, mais lourd à porter pour un développeur solo.
Le brainstorming, par nature, pousse à anticiper plein de choses et à se projeter dans un futur lointain : je n'avais pas ce temps-là à donner au projet.
Sur ce projet précis, il est monté trop haut : d'un site web, le brainstorming a fini par dessiner une suite entière d'applications.
Trop ambitieux, alors que seul le site web était ma vraie priorité.
Deux frictions supplémentaires :
- Consommation de tokens élevée : le brainstorming en profondeur a un coût.
-
Du drift : ajuster la spec ou la solution hors du cadre prévu (la review de fin de sprint) au lieu de passer par elle.
bmad-helpaide à savoir où reprendre, mais pousse à avancer dans le plan existant, pas à ajuster la spec ou le plan d'action : ce qui évite le drift, c'est de faire remonter chaque ajustement via cette review, portée par les retours de démo.
Encore faut-il, en amont, que la spec soit bien rédigée et stable : BMad pousse dans cette direction, mais ce n'était pas mon cas, le périmètre était trop vaste suite au brainstorming.
Ce mode opératoire ne me convenait pas en solo dev.
La dérive du brainstorming n'a pas été inutile : elle m'a aidé à mieux cerner mon besoin réel.
Mais c'est bien cette dérive, en plus de la consommation de tokens, qui m'a poussé à rebooter à nouveau plutôt que de m'acharner sur BMad.
BMad reste, pour moi, l'outil à sortir pour cadrer une idée floue.
Pas pour driver l'exécution au quotidien sur un scope instable ou en solo.
Superpower : rapide sur un POC, mais le drift devient irrécupérable
Troisième reboot, en mai 2026 après une nouvelle pause, avec Superpower cette fois, créé par Jesse Vincent (obra), devenu le plugin le plus étoilé de l'écosystème Claude Code avec plus de 280 000 étoiles GitHub.
Sa version du SDD tient en trois documents dans l'ordre : la spec dit quoi construire, le plan dit dans quel ordre, le code suit le plan, avec du TDD red-green-refactor (tests d'abord, code ensuite, refactor une fois que ça passe) et une phase de brainstorming en amont, plus simple que celle de BMad et bien adaptée à un petit projet comme le mien, donc moins gourmande en tokens.
Nouvelle techno, une fois de plus : je suis parti sur Astro.
La motivation du redémarrage était justement de réduire le scope à la seule chose qui comptait : le site web.
Et ça s'est vu : pas de dérive côté scope cette fois, et c'est rapide, idéal pour sortir une petite application.
Il y a aussi eu un passage par Claude Code sur cette phase, en complément de Superpower.
Point positif à garder : les propositions de design accompagnées d'une démo HTML étaient un vrai plus, ça donnait quelque chose de concret à valider avant de coder.
Deux frictions, cette fois côté durée de vie du projet :
- Le drift post-POC : contrairement à BMad, celui-là devient vite compliqué à rattraper une fois les ajustements accumulés. Un effet yo-yo s'installe, des allers-retours entre spec et code qui ne se stabilisent jamais.
- Des specs difficiles à ajuster une fois posées : plus compliqué qu'avec BMad. C'est ce qui a motivé le passage à OpenSpec.
OpenSpec : pas de reboot, juste un switch, et le drift s'arrête
En juin 2026, pour OpenSpec (Fission-AI, open source, plus de 67 000 étoiles GitHub), pas de nouveau reboot : un simple switch d'outil sur le projet existant.
Le repo y est structuré en deux espaces :
openspec/specs/, la source de vérité du comportement actuel, et openspec/changes/, où toute évolution significative doit d'abord passer par une proposition de changement (proposal, design, tasks) validée avant que quoi que ce soit ne soit codé.
C'est exactement ce qui a fermé la boucle que BMad et Superpower laissaient ouverte : cette validation en amont, plus la traçabilité de l'archive, mettent fin au drift.
Autre point fort : une fois le projet initialisé, il ne reste que trois commandes à connaître. propose crée la proposition de changement. apply lance l'implémentation, guidée par cette proposition. archive merge ensuite la proposition dans la spec globale et archive le changement, pour la traçabilité.
À la bascule, le code et les specs laissés par Superpower ont servi de base pour repartir avec OpenSpec.
J'ai ensuite ajouté des fonctionnalités sans repartir de zéro, y compris pour des changements de plus grande ampleur.
L'approche changement + rétro spec fonctionne bien pour mon contexte projet.
Je la trouve même plus adaptée à un mode kanban, itératif, qu'à un enchaînement séquentiel classique de phases.
La contrepartie : proposal, design et tasks se valident souvent d'un bloc, avec moins d'humain dans la boucle sur la production de ces trois fichiers qu'entre les phases bien séparées de BMad ou Superpower, et une réflexion en amont plus légère.
On a moins la main, mais sur des petits changements, ajuster les trois fichiers reste rapide.
Ça compense largement le manque de recul par rapport à un vrai temps de recadrage phase par phase.
Ce que je retiens
Le fil rouge de ces trois outils, c'est la mémoire : capturer ce qui a été décidé et pourquoi, pour ne pas repartir de zéro à chaque session.
C'est exactement ce qui manquait en vibe coding, et que les trois SDD testés résolvent chacun à leur manière, avec plus ou moins de rigueur.
Ça a aussi un impact sur la gestion de projet au sens large : ces specs et ces plans d'actions vivent dans le repo, alors qu'on gère souvent ce suivi ailleurs, hors du dépôt git.
Le SDD change la donne par rapport au vibe coding, quelque soit l'outil retenu au final : le vrai saut est de sortir du mode « on avance sans rien capturer ».
Mais les trois outils ne jouent pas le même rôle :
- BMad pour brainstormer un scope flou, seul ou en équipe.
- Superpower pour sortir un POC vite.
- OpenSpec pour tout ce qui doit durer sans repartir en drift.
C'est celui que je recommande par défaut aujourd'hui.
| BMad | Superpower | OpenSpec | |
|---|---|---|---|
| Cas d'usage idéal | Cadrer un scope flou, en groupe | Sortir un POC vite | Faire durer un projet sans drift |
| Méthode de travail | Scrum (story files, sprints) | Cycle en V (spec verrouillée avant le code) | Kanban (proposition par proposition, itératif) |
| Terrain de jeu | Greenfield, scope encore flou | Greenfield, POC rapide | Brownfield, projet qui évolue dans la durée |
| Gestion du drift | Rattrapable, demande de reprendre la main régulièrement | Devient vite irrécupérable après le POC | Stoppé par la validation en amont et le merge dans la spec à l'archivage |
| Coût en tokens | Élevé (brainstorming en profondeur) | Modéré | Faible, changement par changement |
| Vitesse | Lente au démarrage, phase d'analyse longue | Très rapide | Rapide, et régulière dans la durée |
| Étoiles GitHub | Plus de 52 000 | Plus de 280 000 | Plus de 67 000 |
Un bémol méthodologique : chaque reboot changeait aussi de stack technique (Next.js/Storybook, puis Rust, puis Astro), sauf le passage de Superpower à OpenSpec qui a gardé le même code.
La comparaison n'est donc pas un test en environnement parfaitement contrôlé : une partie de la lourdeur ressentie sous BMad tient peut-être aussi à l'apprentissage de Rust, à mon scope ambitieux et à mon organisation, pas seulement à l'outil.
La vraie bonne pratique, commune aux trois, c'est de relire ce que produit l'agent à chaque étape, pas de tout valider en bloc à la fin.
Ce qui change d'un outil à l'autre, c'est à quel point cette relecture est imposée plutôt que laissée à ma discipline.
Sur ce spectre, BMad est le plus permissif : rien n'oblige à y revenir, tout repose sur moi.
Superpower muscle le début, spec et plan, puis relâche la garde une fois le code lancé.
OpenSpec est le seul des trois à en faire une étape obligatoire, à chaque changement, du premier jour à aujourd'hui.
Un autre avantage commun aux trois, bien que ce soit une pratique manuelle de mon côté et non une fonctionnalité imposée par l'outil : la séparation entre planification et implémentation permet de choisir un modèle LLM à forte réflexion pour établir la liste des actions, puis de basculer sur un modèle plus direct, donc plus rapide et moins coûteux, pour l'implémentation.
Ce type d'outils évolue vite, ça vaut le coup de continuer à explorer et tester au fil des sorties.
Je suis justement en train de tester ECC (Everything Claude Code, plus de 247 000 étoiles GitHub), un système d'optimisation pour agents IA (skills, mémoire, sécurité), la suite logique de cette série.
Et les réflexions issues du brainstorming BMad ne sont pas perdues pour autant : le site web est en production sur blackspeech.net, mais l'idée d'en faire une suite d'applications reste valable, pour une prochaine fois.
Ce projet m'a aussi permis d'explorer de nouvelles technos et concepts au passage : Rust, Astro, RTK, Scaleway, Netlify, GEO (Generative Engine Optimization, le référencement pensé pour les moteurs IA), entre autres.
Cette version 2 a mis du temps à sortir, entre les pauses qui se sont enchaînées avant d'y arriver, mais le résultat dépasse les attentes que j'avais au lancement du projet.
En complément, ces trois outils, je les ai aussi testés sur d'autres projets.
BMad, pour du brainstorming, une fiche produit et un cadrage de solution.
Superpower, avec le même retour : bon pour un POC ou un besoin bien délimité, pas pour du long cours.
OpenSpec, je l'ai adopté sur deux projets différents, celui-ci et un autre.
Sources :
Top comments (0)