[{"data":1,"prerenderedAt":1014},["ShallowReactive",2],{"blog-tag-dev":3},[4,445,678],{"id":5,"title":6,"author":7,"body":8,"collection":427,"cover":428,"date":429,"description":430,"draft":431,"extension":432,"meta":433,"navigation":434,"order":427,"path":435,"seo":436,"stem":437,"tags":438,"__hash__":444},"blog\u002Fblog\u002Fspec-driven-hermes-03\u002Findex.md","Specs Driven Vibe Coding : 3\u002F3 : Hermes","JS Peru",{"type":9,"value":10,"toc":413},"minimark",[11,15,50,55,58,74,86,89,93,167,174,178,185,188,217,220,224,231,234,241,245,248,259,266,270,277,281,284,287,290,294,301,304,321,327,330,334,337,375,378,381,385],[12,13,14],"p",{},"Cette série en trois articles raconte mes expériences sur le développement assisté par l'IA, drivé par les specs. Les bons côtés, les frictions, les impasses, les surprises. L'évolution aussi.",[16,17,18,30,39],"ol",{},[19,20,21,29],"li",{},[22,23,24],"strong",{},[25,26,28],"a",{"href":27},"\u002Fblog\u002Fspec-driven-bmad-01","Le premier article parlait de BMAD",", une méthode qui met en scène une équipe d'agents IA jouant chacun leur rôle de collègues virtuels",[19,31,32,38],{},[22,33,34],{},[25,35,37],{"href":36},"\u002Fblog\u002Fspec-driven-skills-02","Le second article traitait des skills de Matt Pocock",", une version un peu moins dense et plus orientée dev",[19,40,41,42,45,46,49],{},"Dans ce troisième, on a tenté de créer ",[22,43,44],{},"notre propre workflow",", avec ",[22,47,48],{},"Hermes",", sa mémoire, ses bots… et un twist qu'on n'avait pas vraiment vu venir.",[51,52,54],"h2",{"id":53},"contexte","Contexte",[12,56,57],{},"Cette fois, le terrain de jeu était une landing \u002F marketing page. Rien de monstrueux côté produit, mais un double objectif clairement affiché :",[16,59,60,63],{},[19,61,62],{},"Concevoir et développer la page (Astro côté front, design sur Figma \u002F Paper)",[19,64,65,66,69,70,73],{},"Migrer l'agent sur un ",[22,67,68],{},"serveur dédié",", un mini-PC d'entrée de gamme qui a bien 10 ans, et le piloter depuis ",[22,71,72],{},"Hermes Desktop","… ou depuis le téléphone.",[12,75,76,77,81,82,85],{},"Autrement dit : continuer la logique specs-driven des deux premieres experiences, mais changer aussi le ",[78,79,80],"em",{},"où"," et le ",[78,83,84],{},"comment"," on travaille avec l'agent. Moins collé à un IDE local, plus proche d'une présence distante, joignable depuis n'importe où.",[12,87,88],{},"C'est d'ailleurs une des principales évolutions depuis quelques mois que je n'avais pas vu venir : quitter peu à peu l'IDE pour utiliser les applications desktop (Github Copilot App chez mon client Decahtlon, Hermes Desktop ici).",[51,90,92],{"id":91},"stack-utilisée","Stack utilisée",[94,95,96,107],"table",{},[97,98,99],"thead",{},[100,101,102,105],"tr",{},[103,104],"th",{},[103,106],{},[108,109,110,119,127,135,143,151,159],"tbody",{},[100,111,112,116],{},[113,114,115],"td",{},"Method",[113,117,118],{},"Skills custom + Hermes",[100,120,121,124],{},[113,122,123],{},"Provider",[113,125,126],{},"OpenCode Go + Nous Research",[100,128,129,132],{},[113,130,131],{},"Model",[113,133,134],{},"GLM 5.3 (principal) + GPT 5.6 Luna",[100,136,137,140],{},[113,138,139],{},"Coding App \u002F IDE",[113,141,142],{},"Hermes Desktop (+ Discord remote)",[100,144,145,148],{},[113,146,147],{},"App",[113,149,150],{},"Astro + design Figma \u002F Paper",[100,152,153,156],{},[113,154,155],{},"Tickets management",[113,157,158],{},"Linear",[100,160,161,164],{},[113,162,163],{},"Machine",[113,165,166],{},"Mini PC dédié",[12,168,169,170,173],{},"Le spoil annoncé dès le ",[25,171,172],{"href":27},"premier article"," se concrétisait enfin : app desktop, modèles chinois, contrôle à distance depuis une messagerie. On y était.",[51,175,177],{"id":176},"intro-écrire-sa-propre-méthode","Intro : écrire sa propre méthode",[12,179,180,181,184],{},"Après BMAD (trop dense, trop « réunionnite ») et les skills de Matt Pocock (plus légères, plus proches du dev, branchées à Linear), l'envie était claire : ",[22,182,183],{},"garder l'esprit",", pas le framework.",[12,186,187],{},"On a donc écrit nos propres versions des briques qui avaient marché :",[189,190,191,199,205,211,214],"ul",{},[19,192,193,194,198],{},"un ",[195,196,197],"code",{},"\u002Fgrill-me"," maison, pour stress-tester les décisions avant de coder",[19,200,193,201,204],{},[195,202,203],{},"\u002Fto-specs"," pour formaliser le besoin en spec technique et fonctionnelle",[19,206,207,210],{},[195,208,209],{},"\u002Fto-issues"," pour découper ecrire les ticket dans Linear",[19,212,213],{},"du contexte design, de la littérature, des capacités un peu plus poussées côté UI\u002FUX (le point faible récurrent des deux premiers essais)",[19,215,216],{},"et aussi un branchement vers Obsidian, notre « second cerveau », comme base documentaire",[12,218,219],{},"Rien de magique en soi : ce sont des skills, du markdown, du contexte. La différence, c'est qu'avec Hermes ça s'installait de façon assez fluide et naturelle. La mémoire et les capacités d'auto-amélioration du produit changeaient la sensation : moins « je recolle des fichiers dans un repo », plus « je nourris un agent qui s'installe dans mon environnement ».",[51,221,223],{"id":222},"la-hype-des-bots","La hype des bots",[12,225,226,227,230],{},"L'autre promesse qui nous a hypé tout l'été, c'étaient les ",[22,228,229],{},"bots",".",[12,232,233],{},"Pouvoir parler à l'agent, le lancer, le reprendre, le challenger depuis Discord (et potentiellement Slack, WhatsApp, à peu près toutes les messageries possibles), ça change le rapport au travail. On n'est plus forcément assis devant un iDE ou un terminal. On peut vérifier une démo, relancer un ticket, poser une question depuis le téléphone, dans le bus, en attendant que le café soit prêt.",[12,235,236,237,240],{},"Pour le ",[78,238,239],{},"workflow"," qu'on voulait tester, c'était exactement le point : l'agent n'habite plus seulement l'IDE, il habite un canal de communication.",[51,242,244],{"id":243},"ressenti","Ressenti",[12,246,247],{},"Sur le fond, on était convaincus.",[189,249,250,253,256],{},[19,251,252],{},"Les concepts tiennent la route : skills perso, mémoire, auto-amélioration, tickets Linear, design un peu mieux outillé.",[19,254,255],{},"Les perfs étaient là, le résultat aussi : on avançait, on livrait, on itérait.",[19,257,258],{},"Les possibilités ouvertes par le remote (Desktop + Discord + mini PC) donnaient vraiment l'impression d'un cran au-dessus des setups « Claude Code dans un terminal + IDE » du début de série.",[12,260,261,262,265],{},"Le petit bémol, honnêtement assez prosaïque : les ",[22,263,264],{},"mises à jour Desktop et server"," étaient quasi quotidiennes, et un peu longues. Rien de bloquant, mais assez pour rappeler que tu fais tourner un produit qui bouge très vite, sur une machine qui n'est plus ton MacBook du quotidien.",[51,267,269],{"id":268},"et-puis","Et puis...",[12,271,272],{},[273,274],"img",{"alt":275,"src":276},"Doom","\u002Fblog\u002Fspec-driven-hermes-03\u002Fhermes-doom.webp",[51,278,280],{"id":279},"le-drame","... le drame",[12,282,283],{},"Un dimanche matin, notre fier mini-PC a refusé de rebooter, juste après une mise à jour serveur.",[12,285,286],{},"Disparu Hermes. Envolée la mémoire. (Techniquement on peut récupérer le SSD, oui… mais bon.)",[12,288,289],{},"Tout le bel édifice « agent sur serveur + mémoire persistante + bots dans Discord » s'est volatilisé avec une machine morte. C'est un rappel un peu violent : ta stack agentique, si elle vit sur un seul boîtier sous ton bureau, elle a aussi la fragilité d'un disque et d'une alim.",[51,291,293],{"id":292},"and-now-cursor","And now : Cursor !",[12,295,296,297,300],{},"Il a fallu rebondir. Et là, on a essayé ",[22,298,299],{},"Cursor",", un peu en reculant, pas ultra emballés au départ à l'idée de donner des sous à Elon Musk et Grok.",[12,302,303],{},"Sauf que Cursor cochait, d'un coup, la plupart des cases qu'on cherchait avec Hermes :",[189,305,306,309,312,315,318],{},[19,307,308],{},"agents dans le cloud, ou sur d'autres machines",[19,310,311],{},"contrôle depuis le mobile",[19,313,314],{},"des (Grok) bots",[19,316,317],{},"la possibilité d'utiliser des modèles différents",[19,319,320],{},"des intégrations vraiment propres avec GitLab et Figma",[12,322,323,324,230],{},"Le verdict, pour le moment, est sans appel : ",[22,325,326],{},"ça marche du tonnerre",[12,328,329],{},"Ironique, après une série qui partait de Claude Code, passait par OpenCode \u002F GLM, s'enthousiasmait pour Hermes… et atterrit sur un outil qu'on regardait de travers. Mais c'est aussi la leçon de ces trois articles : plus que la méthode « gestion de projet », c'est l'outillage qui a bougé le plus vite en 2026. Et il ne faut jamais rien déclarer d'acquis.",[51,331,333],{"id":332},"end-game","End game",[12,335,336],{},"Sur trois essais (BMAD, skills Pocock, Hermes + skills maison), quelques constantes ressortent :",[16,338,339,345,351,357,363,369],{},[19,340,341,344],{},[22,342,343],{},"Planifier aide",", surtout sur plusieurs sessions. Mais la cérémonie trop lourde se paie cash (BMAD).",[19,346,347,350],{},[22,348,349],{},"Les skills légères et customisables"," passent mieux en solo que les frameworks « équipe virtuelle » complète.",[19,352,353,356],{},[22,354,355],{},"Tickets + MCP"," (Linear, GitLab…) restent utiles… surtout pour nous. Les agents, eux, pourraient souvent s'en passer.",[19,358,359,362],{},[22,360,361],{},"Design \u002F UX"," restent le terrain où il faut encore pousser le contexte soi-même.",[19,364,365,368],{},[22,366,367],{},"La mémoire et le remote"," changent vraiment le game, jusqu'au jour où le hardware lâche.",[19,370,371,374],{},[22,372,373],{},"Notre plus-value"," se concentre de plus en plus sur la conception, la validation, le goût, le design… et le choix (parfois contre-intuitif) des outils.",[12,376,377],{},"On a commencé la série avec une équipe de bots qui se parlaient entre eux pendant 800 lignes. On la finit avec un agent joignable depuis le téléphone, sur un cloud qu'on n'avait pas prévu d'aimer.",[12,379,380],{},"Le vibe coding drivé par les specs, ce n'est peut-être pas une méthode unique. C'est une attitude : écrire assez clair pour que demain, un autre agent (ou toi-même avec le cerveau en miettes) puisse reprendre sans tout réinventer. Le reste, c'est de l'outillage. Et l'outillage, en 2026, ça change avant même que tu aies fini d'écrire l'article.",[51,382,384],{"id":383},"pour-aller-plus-loin","Pour aller plus loin",[189,386,387,395,403,408],{},[19,388,389,390],{},"Hermes Agent (Nous Research) : ",[25,391,392],{"href":392,"rel":393},"https:\u002F\u002Fhermes-agent.nousresearch.com\u002F",[394],"nofollow",[19,396,397,398],{},"Skills Matt Pocock : ",[25,399,402],{"href":400,"rel":401},"https:\u002F\u002Fgithub.com\u002Fmattpocock\u002Fskills",[394],"mattpocock\u002Fskills",[19,404,405],{},[25,406,407],{"href":27},"Article 1 : BMAD",[19,409,410],{},[25,411,412],{"href":36},"Article 2 : Skills Pocock",{"title":414,"searchDepth":415,"depth":415,"links":416},"",2,[417,418,419,420,421,422,423,424,425,426],{"id":53,"depth":415,"text":54},{"id":91,"depth":415,"text":92},{"id":176,"depth":415,"text":177},{"id":222,"depth":415,"text":223},{"id":243,"depth":415,"text":244},{"id":268,"depth":415,"text":269},{"id":279,"depth":415,"text":280},{"id":292,"depth":415,"text":293},{"id":332,"depth":415,"text":333},{"id":383,"depth":415,"text":384},null,".\u002Fspec-driven-hermes-03.webp","2026-10-05","Trois retours d'expérience sur des frameworks\u002F méthodes pour développer \u002F vibe coder en étant drivé par les specs",false,"md",{},true,"\u002Fblog\u002Fspec-driven-hermes-03",{"title":6,"description":430},"blog\u002Fspec-driven-hermes-03\u002Findex",[439,440,441,442,443],"Tech","IA","Dev","développement","agilité","G3_MDtE5PhfLbyMccLhxM71mOOhO2lZCOp2lRR6a7ww",{"id":446,"title":447,"author":7,"body":448,"collection":427,"cover":671,"date":672,"description":430,"draft":431,"extension":432,"meta":673,"navigation":434,"order":427,"path":36,"seo":674,"stem":675,"tags":676,"__hash__":677},"blog\u002Fblog\u002Fspec-driven-skills-02\u002Findex.md","Specs Driven Vibe Coding : 2\u002F3 : Matt Pocock Skills",{"type":9,"value":449,"toc":663},[450,453,476,478,481,483,486,489,550,554,557,560,599,601,629,633,636,639,642,645,647],[12,451,452],{},"Cette série en trois articles raconte mes expériences sur le développement assisté par. Les bons côtés, les frictions, les impasses, les surprises. L'évolution aussi, on le verra.",[16,454,455,463,470],{},[19,456,457,29],{},[25,458,459,460],{"href":27},"Le premier article parlait de ",[22,461,462],{},"BMAD",[19,464,465,466,469],{},"Le second article traitera des ",[22,467,468],{},"skills de Matt Pocock",", qui sont une version un peu moins dense et plus orientée dev que BMAD",[19,471,472,473,475],{},"Dans le troisième, on essayera de créer notre propre workflow et on essayera ",[22,474,48],{}," et ses bots pour cela.",[51,477,54],{"id":53},[12,479,480],{},"Cette fois-ci, c'est une demo d'un futur produit SaaS qui a été conçu et développée, pour le compte d'une startup. Les contraintes étaient à la fois de pouvoir développer assez rapidement une demo montrable en avant-vente, avec un front et des features relativement limitées mais une archi backend la plus proche possible de la cible, afin de pouvoir scaler sans trop de pb, et surtout de poser les bases techniques et le socle permettant de gérer d'ores et déjà un peu de volume.\nIl fallait par exemple gérer les events SSE pour le temps réel, faire du multi-tenant, etc...",[51,482,92],{"id":91},[12,484,485],{},"La nouveauté par rapport à l'essai BMAD, c'est l'abandon de Claude Code. Pour des raisons diverses et variées, d'ailleurs (coûts, dramas constants avec Fable, notamment, changements soudains dans la tarification, limite des 5 heures, volonté de ne pas être trop lié à un provider...).",[12,487,488],{},"On passa donc chez OpenCode, et leur abonnement Go qui donne accès à un large choix de modèles chinois. Notamment GLM 5.2 qui s'annonçait très performant pour des coûts bien en dessous de ceux pratiqués par Anthropic.\nL'envie était aussi de pouvoir tester différents modèles, passer sur des modèles gratuits pour certaines tâches, utiliser Mistral également pour d'autres, tout en partageant les configs autour du AGENTS.md.",[94,490,491,499],{},[97,492,493],{},[100,494,495,497],{},[103,496],{},[103,498],{},[108,500,501,508,515,522,530,537,543],{},[100,502,503,505],{},[113,504,115],{},[113,506,507],{},"Skills",[100,509,510,512],{},[113,511,123],{},[113,513,514],{},"OpenCode Go",[100,516,517,519],{},[113,518,131],{},[113,520,521],{},"GLM 5.2",[100,523,524,527],{},[113,525,526],{},"Coding App\u002F IDE",[113,528,529],{},"Zed",[100,531,532,534],{},[113,533,147],{},[113,535,536],{},"SvelteKit \u002F PostGreSQL",[100,538,539,541],{},[113,540,155],{},[113,542,158],{},[100,544,545,547],{},[113,546,163],{},[113,548,549],{},"MacBook Pro",[51,551,553],{"id":552},"intro","Intro",[12,555,556],{},"Après BMAD et son équipe d'agents virtuels, je voulais quelque chose de plus léger, surtout pour la partie. Matt Pocock, connu pour ses cours TypeScript et son travail sur l'agentic coding, a publié sur GitHub un repo de skills qui a bcp fait parlé de lui. Chaque skill décrit un processus répétable : quand l'invoquer, les étapes à suivre, les pièges à éviter. Et comme c'est du markdown standard, ça marche avec OpenCode, Claude Code, Cursor ou Codex, sans être marié à un provider, ce qui tombait bien avec notre stack.",[12,558,559],{},"Pour ce projet, 4 skills ont structuré l'essentiel du travail :",[189,561,562,569,583,591],{},[19,563,564,568],{},[22,565,566],{},[195,567,197],{}," : avant d'écrire la moindre ligne de code, l'agent m'interviewe sur le plan ou la décision en cours, et ne s'arrête que quand chaque branche de l'arbre de décision est résolue. C'est frustrant parfois (on a juste envie qu'il code, ce fichu agent), mais c'est redoutablement efficace pour éviter le retravail. Multi-tenant ? Il a fallu clarifier le modèle d'isolation des données, la stratégie de routing, ce qui arrive quand un utilisateur appartient à deux tenants... Autant de questions auxquelles j'aurais autrement répondu en API par défaut, à moitié, et payées plus tard.",[19,570,571,576,577,582],{},[22,572,573],{},[195,574,575],{},"\u002Fto-spec"," : une fois l'alignement obtenu, l'agent synthétise la conversation en une spec (sans nouvelle interview, il formalise juste ce qu'on vient de discuter) et la publie dans le tracker. C'est la phase \"spec\" proprement dite : ce qui a remplacé la longue phase de planification de BMAD, mais en plus court et plus ancré dans le code réel. Dans la foulée, ",[22,578,579],{},[195,580,581],{},"to-tickets"," découpe la spec en tickets, des tickets qui traversent toute la stack verticalement plutôt que couche par couche, avec leurs dépendances de blocage, poussés nativement dans Linear.",[19,584,585,590],{},[22,586,587],{},[195,588,589],{},"\u002Fimplement",", pour lancer le travail sur les tickets. A vrai dire, avec un worflow de tickets et la connexion par mcp avec Linear, celui ci n'a pas servi longtemps. Par la suite, à chaque session, on parcourait le backlog, choisissait le ticket, sans forcément invouqer \u002Fimplement",[19,592,593,598],{},[22,594,595],{},[195,596,597],{},"\u002Fhandoff",", enfin, et c'est peut-être le plus précieux pour moi : il compresse la session en cours dans un document de passation, pensé pour qu'un autre agent, ou le même dans une session fraîche, puisse reprendre le travail sans rien perdre. La fenêtre de contexte se vidant à chaque session, ce document fait office de mémoire externe. Le soir, je ferme l'ordi, et plus tard dans la semaine on pouvait tout reprendre. Pocock appelle ça du \"memento-driven development\" : optimiser le codebase pour quelqu'un qui le redécouvre chaque matin, ce qui est exactement la condition de vie d'un agent.",[51,600,244],{"id":243},[189,602,603,606,609,612,615,618,621,624,626],{},[19,604,605],{},"La grande avancée pour moi a été de pouvoir créer les tickets Linear, connecter ce dernier à Gitlab, et automatiser presque entièrement la chaine. J'ai ajouté aux worflow la demande de code-review par un autre modele et agent, et surtout un skill pour ajouter une demo.",[19,607,608],{},"Dès lors, je pouvait choisir le ticket à implementer, donner juste à l'agent le numero de celui-ci, puis revenir quelques temps après pour voir la démo et pouvopir testé ce qui avait été developpé. Quelques retours mineurs plus tard, on pouvait relire le code, puis merger et la CI deployait l'app.",[19,610,611],{},"L'autre bonne idée c'est \u002Fhand-off qui m'a permis de pouvoir abandonner un travail à 18h15 et de courir aller chercher les enfants sans cette injonction qu'on se crée souvent de devoir finir un travail, le fameux 'un dernier detail et j'y vais'. Ici c'est plutot le contraire, on reprend quelques jours après le handoff, et on a un petit résumé \"Dans les épisodes précedents\" qui n'aide pas que l'agent pour être honnête.",[19,613,614],{},"Le \u002Fgrill-me était moins profond mais plus technique que celui de BMAD. Un peu long encore, peut-être serait-il interessant aussi de pouvoir découper en sessions thématiques plus courtes, comme des réunions de travail, des ateliers. On tombe aussi parfois dans le meme travers de l'interview, on nous bombarde de questions et certaines sont parfois hardues, ou arrivent trop tôt dans la reflexion. Mais globalement l'experience a engrangé un rendu de qualité.",[19,616,617],{},"La qualité des specs qui en sont sortis est assez bluffante. Et celle-ci a facilité l'implementation qui a coulé par la suite sans trop d'accrocs.",[19,619,620],{},"Clairement l'UI, l'UX, le design ne sont pas trop le domaine de ces skills. Mais ce n'est pas très grave, on peut completer par des étapes intermédiaire et à l'inverse de BMAD on a l'espace pour que ca n'interfère pas ou ne bloque l'essentiel des specs plutot très techniques.",[19,622,623],{},"Au final, le worflow était tellement bien rôdé que l'intervention humaine est à questionner. Si on a besoin de tickets JIRA pour pouvoir lancer ou reprendre une session de developpement, et globalement suivre le déroulé, on sent que les agents pas forcément. Ca peut les aider à structurer, mais on sent qu'au fond, ils pourraient s'en passer. Les notions de sprint, d'US, de tickets, d'agilité sont surtout et encore importantes pour nous, mais si on nous enleve l'execution et meme l'ecriture des tickets, on se retrouve assez vite assez secs.",[19,625],{},[19,627,628],{},"On voit que notre plus-value va se concentrer sur la conception d'une part, le test et la validation d'autre part, et je dirais quand meme l'UX, l'UI, le design qui sont encore des domaines où les specs ont un peu de mal à être générées par l'AI.",[51,630,632],{"id":631},"la-suite","La suite",[12,634,635],{},"Les skills de Matt Pocock ont l'avantage de pouvoir être invoqués à tous niveau (ou presque) d'un developpement : bug, mini amélioration, grosse feature, gros projet, je les ai trouvé plus versatiles que BMAD, et donc avec des possibilités de customisation plus fortes pour s'adapter à votre worflow.",[12,637,638],{},"Celui-ci evolue de toute façon énormément à l'air l'agentique, et ces skills sont peut être autant destinées aux agents eux-memes que surtout à nous, pour garder un contrôle et nous rapprocher de ce qu'on connait, notamment en entreprise.",[12,640,641],{},"Reste encore quelques frictions (mêmes les frictions restent utiles pour garder la connection et l'interêt de ce que l'on fait), et des interrogations sur le sens de nos worflows et outils \"classiques\" de developpement, lorsque nous perdons la plupart de l'execution.",[12,643,644],{},"Et vient l'envie de customiser et experimenter encore un peu plus tout en exercant plus de contrôle. On verra cela dans le prochain article où on va tenter de se passer de \"frameworks\" existants, en écrivant nos propres skills , notre propres méthodes avec Hermes, sa mémoire et ses capacités d'auto-amélioration.",[51,646,384],{"id":383},[189,648,649,657],{},[19,650,651,652],{},"Documentation Pocock : ",[25,653,656],{"href":654,"rel":655},"https:\u002F\u002Fwww.aihero.dev\u002Fskills",[394],"Skills sur AI Hero",[19,658,659,660],{},"Le repo GitHub : ",[25,661,402],{"href":400,"rel":662},[394],{"title":414,"searchDepth":415,"depth":415,"links":664},[665,666,667,668,669,670],{"id":53,"depth":415,"text":54},{"id":91,"depth":415,"text":92},{"id":552,"depth":415,"text":553},{"id":243,"depth":415,"text":244},{"id":631,"depth":415,"text":632},{"id":383,"depth":415,"text":384},".\u002Fspec-driven-skills-02.webp","2026-09-23",{},{"title":447,"description":430},"blog\u002Fspec-driven-skills-02\u002Findex",[439,440,441,442,443],"-5cU6A0yil8yFTpUCx3qEMCuIZXwIVEuIunUPpAtQv4",{"id":679,"title":680,"author":7,"body":681,"collection":427,"cover":1007,"date":1008,"description":430,"draft":431,"extension":432,"meta":1009,"navigation":434,"order":427,"path":27,"seo":1010,"stem":1011,"tags":1012,"__hash__":1013},"blog\u002Fblog\u002Fspec-driven-bmad-01\u002Findex.md","Specs Driven Vibe Coding : 1\u002F3 : BMAD",{"type":9,"value":682,"toc":994},[683,686,689,692,707,709,718,725,728,734,736,739,742,800,804,807,815,818,821,824,827,830,834,837,840,843,846,849,855,859,862,865,871,874,877,880,883,887,890,896,900,903,906,909,912,916,919,922,927,931,934,951,956,960,963,966,969,976,978],[12,684,685],{},"Il existe une façon de concevoir et développer du logiciel qui consiste à tout écrire avant de coder. Spécifications, architecture, user stories, tickets, tout est documenté, structuré, validé, attribué et planifié. Ensuite seulement, l'implémentation commence. C'est la façon qu'on utilise en entreprise, en équipe en général.",[12,687,688],{},"Mais justement, cette approche, on a voulu l'appliquer aussi au travail en solo. Ou pour être plus précis en solo mais accompagné par l'IA.\nOn l'aura testée trois fois ces derniers mois, sur trois projets différents, avec trois méthodes distinctes.",[12,690,691],{},"Cette série en trois articles raconte ces expériences. Les bons côtés, les frictions, les impasses, les surprises. L'évolution aussi, on le verra.",[16,693,694,699,703],{},[19,695,696,697,29],{},"Le premier article parle de ",[22,698,462],{},[19,700,465,701,469],{},[22,702,468],{},[19,704,472,705,475],{},[22,706,48],{},[51,708,54],{"id":53},[12,710,711,713,714,717],{},[22,712,462],{}," on l'a testé notamment sur le site sur lequel vous êtes, puis ",[78,715,716],{},"spoiler alert"," on l'a assez vite abandonné.",[12,719,720,721,724],{},"Mais on l'a aussi retrouvé quelques mois plus tard, car c'est la méthode qu'a choisie ",[22,722,723],{},"Decathlon"," comme workflow de référence pour le développement agentique, avec l'app GitHub Copilot.",[12,726,727],{},"Et là, on en parlera plus tard, l'expérience est quand même bien supérieure à ce que je vais vous raconter, et c'est étonnant quand on avait pratiqué GitHub Copilot ces dernières années, preuve que nos outils évoluent à une vitesse assez folle et qu'il ne faut jamais rien déclarer comme acquis en matière d'IA.",[12,729,730,731,733],{},"On le verra d'ailleurs au cours des 3 articles, plus que le workflow \"gestion de projet\", c'est aussi l'outillage qui va évoluer au cours de l'année 2026. On commenca avec Claude code dans un terminal + un IDE où on controle presque ligne de code par ligne de code, on finira surement ",[78,732,716],{}," avec une app desktop comme Copilot ou Hermes, sur des modèles chinois pilotés par telephone depuis Discord.",[51,735,92],{"id":91},[12,737,738],{},"Au cours des 3 articles, la stack va évoluer et pas seulement sur les frameworks. Les modèles, les providers, les machines hôtes même vont évoluer également.",[12,740,741],{},"Au moment de l'essai BMAD, en tous cas, notre stack était :",[94,743,744,752],{},[97,745,746],{},[100,747,748,750],{},[103,749],{},[103,751],{},[108,753,754,760,767,774,780,787,794],{},[100,755,756,758],{},[113,757,115],{},[113,759,462],{},[100,761,762,764],{},[113,763,123],{},[113,765,766],{},"Claude Code pro",[100,768,769,771],{},[113,770,131],{},[113,772,773],{},"Opus 4.5",[100,775,776,778],{},[113,777,526],{},[113,779,529],{},[100,781,782,784],{},[113,783,147],{},[113,785,786],{},"Nuxt",[100,788,789,791],{},[113,790,155],{},[113,792,793],{},"Gitlab",[100,795,796,798],{},[113,797,163],{},[113,799,549],{},[51,801,803],{"id":802},"intro-planifier-pour-mieux-développer","Intro : planifier pour mieux développer",[12,805,806],{},"Pour démarrer un développement, nous avons généralement 2 options :",[189,808,809,812],{},[19,810,811],{},"Partir tête baissée et découvrir le sujet en pratiquant",[19,813,814],{},"Commencer par une conception, une planification des tâches et ensuite coder",[12,816,817],{},"Les 2 peuvent avoir leurs avantages selon la taille et surtout la complexité de la tâche. À savoir si on doit fixer un bug connu, développer une fonctionnalité complète, ou carrément démarrer un projet, la phase de planification \u002F découpage sera plus ou moins nécessaire et poussée.",[12,819,820],{},"Pour les agents, c'est la même chose. Plus la tâche sera longue et nécessitera plusieurs sessions de travail, plus la planification sera indispensable. Mais cela est dû essentiellement à des limites techniques : la gestion de la mémoire, des fenêtres de contexte, l’efficacité qui décroît au-delà d’un certain temps au cours d’une même session…",[12,822,823],{},"Au global, l'agent codeur nous ressemblera, il sera plus productif sur des tâches courtes, bien définies et cadrées, il aura besoin de pauses (ou plutôt dans son cas d’arrêt complet pour reset), il aura besoin aussi et surtout de prendre des notes et d’avoir de la documentation à disposition, bien indexée, claire.",[12,825,826],{},"Comme nous, plus il perdra de temps à faire des recherches et à essayer de connecter à des outils auxquels il n’a pas d’accès, moins il sera créatif et productif, plus la journée passera trop vite, plus la motivation chutera et le stress augmentera, plus il sera bougon (non ça j'extrapole).\nBref l’agent codeur est un développeur comme les autres, même s’il ne daignera jamais l’avouer et nous encore moins.",[12,828,829],{},"Il aimera bien ne pas tout avoir en tête, et pouvoir piocher dans des specs bien écrites et une documentation bien gaulée pour pouvoir s'arrêter dans les temps et reprendre sans douleur son travail.",[51,831,833],{"id":832},"one-person-team","One person team",[12,835,836],{},"Néanmoins, il faut reconnaître que la tentation de foncer tête baissée est souvent la plus forte, surtout avec l’IA. On est pressé d’essayer un prompt et d'avoir un résultat en quelques minutes, curieux aussi de voir si notre agent sera capable de répondre au défi.",[12,838,839],{},"Planifier est préférable dans presque toutes les situations, mais il faut reconnaître que c’est peut-être fastidieux, surtout pour un prototype ou une idée à essayer, et qu’on doit mesurer si ça vaut le coup d'engager quelques heures à planifier avant d'agir. Ça tombe bien, l’IA est plutôt douée pour cela, et dispose dans la plupart des cas d’un mode \u002FPlan très efficace.",[12,841,842],{},"Le mode \u002Fplan sera pertinent et presque nécessaire pour des petites tâches comme des bugs, des petites améliorations, cela permettra de réaliser l’analyse, de lister les solutions, découper le travail et se rappeler du workflow souhaité à savoir par exemple l'écriture et l’implémentation de tests, différentes commandes pour builder, formater, etc… faire une review finale, et voire committer, pousser et ouvrir la PR. (cela dit, avec les modèles récents, écrire des markdown pour cadrer le workflow de développement, semble avoir de moins en moins de sens et les agents sont tout à fait capables de faire cela tout seuls).",[12,844,845],{},"Le plan vous aidera aussi à optimiser le prompt initial et le livrable en limitant les interactions, les retours et corrections et en tendant vers le plus possible vers le prompt initial unique et le one shot. Car si on accepte un plan bien gaulé, normalement tout s'enchaîne sans friction.",[12,847,848],{},"C’est parfait pour des petites tâches mais qu’en est-il pour des développements plus ambitieux, qui vont nécessiter plusieurs sessions \u002F jours ? On a toujours la possibilité de s’interrompre et d’enregistrer notre plan mis à jour pour une reprise extérieure. Cela va fonctionner si vous avez par exemple un abonnement pro Claude, et vous disposez de la mémoire (et leur donnez toutes vos données au passage, mais bon…). Disons que pour le moment ce n'est pas encore hyper optimal.",[12,850,851],{},[273,852],{"alt":853,"src":854},"Bot team","\u002Fblog\u002Fspec-driven-bmad-01\u002Frobots-reunion.webp",[51,856,858],{"id":857},"testons-bmad","Testons BMAD",[12,860,861],{},"On a donc testé BMAD au cours de quelques jours (ou plutôt quelques sessions de 5 heures entrecoupées de pauses fraîcheur) pour la conception et le développement du site sur lequel vous êtes.",[12,863,864],{},"Rien de bien compliqué mais un business modèle qui a évolué, pivoté, et surtout une direction artistique qu’on a pour la première fois confronté à l’IA. Le défi était ici de produire du contenu et une «patte graphique» la plus personnelle possible, en chassant au maximum le SLOP. On verra par la suite que ce fut un combat et une négociation permanente car avec BMAD ce n’est pas un seul agent qui travaillera avec vous mais une petite équipe de 6\u002F7 personnes qu’il faudra manager, corriger, challenger et parfois même s’embrouiller.",[12,866,867,868,230],{},"On passera sur l’installation du framework, un peu lourde je pense car le système est beaucoup basé sur les fichiers texte. On va donc avoir des dizaines de dossiers, autant de sous-dossiers et des centaines (!) de fichiers markdown s’ajouter dans notre projet alors qu’on a encore rien fait d’autre que lancer ",[195,869,870],{},"npx bmad-method install",[12,872,873],{},"Vous me direz ça ne change pas grand chose par rapport à un paquet npm classique, certes, mais si quand même un peu car on le verra on va aussi produire de la doc, des specs et tout un tas de fichiers qu'il faudra pour le coup garder et versionner, peut-être aussi séparer de la base de code tout en les synchronisant et cela pourra devenir un petit sujet de friction.",[12,875,876],{},"Bref, une fois installé, on se lance, assez facilement juste en démarrant une session et en chattant (sur Claude code,  donc , pour le moment, on verra par la suite l’évolution vers d'autres modèles ).",[12,878,879],{},"Les premiers moments seront d’ailleurs consacrés au dialogue, on va poser les bases de notre projet, puis on va vite arriver à l'aspect le plus marquant peut-être de BMAD à savoir le mode « interview». On va subir des rafales de questions pour cerner et cadrer notre projet, on va se faire challenger, bousculer peut être  on va couvrir la technique, le fonctionnel, le commercial, la sécurité, le SEO, le design, ... on va se projeter dans l’avenir, bref c’est assez dense, surtout si votre projet n’est encore qu’une vague idée.",[12,881,882],{},"Et ce n'est encore que le début.",[51,884,886],{"id":885},"le-brainstorming","Le brainstorming.",[12,888,889],{},"BMAD va vous demander de choisir parmi quelques techniques de brainstorming et vous poser tout un tas de questions parfois complètement abstraites pour pousser un peu plus vos concepts ou les recadrer. Personnellement j’ai essayé plusieurs techniques et la plupart ne m'ont pas convaincue. On peut même dire que certaines m'ont carrément ennuyé et agacé et j'ai dit STOP, changeons de technique, je ne vois pas l'intérêt de choisir entre bleu ou rouge, tempo rapide ou tempo lent, surface lisse ou rugueuse, non vraiment STOP.",[12,891,892],{},[273,893],{"alt":894,"src":895},"Bot team 02","\u002Fblog\u002Fspec-driven-bmad-01\u002Frobots-reunion-02.webp",[51,897,899],{"id":898},"rencontre-avec-notre-nouvelle-équipe-dagents","Rencontre avec notre nouvelle équipe d'agents",[12,901,902],{},"Je ne me souviens plus exactement à quel moment intervient la rencontre avec l'équipe. John, Alexa, Sandy, Kevin, Pamela et Donald (les prénoms ont été modifiés), respectivement architecte, UX designer, dev back, dev front et tech lead, feront leur entrée dans le process via une réunion.",[12,904,905],{},"On passera en revue les premiers éléments de la demande selon chaque spécialité, ils reformuleront et ils noteront les points à creuser, challenger, ou carrément explorer. Ce qui est assez drôle dans cette « party mode » c’est que nos amis ne s'adressent plus forcément à nous, mais vont parler entre eux, parfois pendant de longues minutes.",[12,907,908],{},"On se contente alors de lire les dialogues, c'est un délire, on se croirait dans un RPG, et au bout de quelques minutes où pour être honnête on peut avoir décroché, une question enfin vous est adressée : es-tu d'accord avec cela JS ? ‘ Euh … scrollons un peu de 800 lignes vers le haut et relisons si tu veux bien.",[12,910,911],{},"Selon votre disponibilité, vous serez arrivés à la fin de cette partie au bout de une ou 2 sessions, inutile de vous dire que c'est donc chronophage et dense. Un peu étrange donc, ces longues réunions avec vos collègues agents, car rappelons-le, dans la vraie vous ne parlez qu'à votre ordinateur.",[51,913,915],{"id":914},"rédaction-des-specs-et-démarrage-des-devs","Rédaction des specs et démarrage des devs",[12,917,918],{},"Normalement si tout c’est bien passé (dans notre cas on aura quand même lutté  surtout avec l’UX et le SEO), on pourra commencer à écrire les décisions d'architecture (ADR), les specs (PRD), puis le découpage en US.",[12,920,921],{},"Là, toute la magie opère, toute la doc s’écrit en quelques minutes, les tickets sont prêts, découpés, il n’y a plus qu’à, comme on dit. On pourra prendre les tickets 1 par 1 et lancer les implémentations dans des branches séparées, commiter, pousser, créer les PRs, merger, déployer en prod, tout se passe ensuite de façon assez fluide (tant qu'on ne parle pas design ou qualité de code).",[12,923,924],{},[273,925],{"alt":894,"src":926},"\u002Fblog\u002Fspec-driven-bmad-01\u002Frobots-mad.webp",[51,928,930],{"id":929},"les-failles","Les failles",[12,932,933],{},"Bon, ça c'est évidemment si tout va bien et si votre plan a été parfaitement écrit. Dans la réalité, on fera face à quelques désillusions.",[189,935,936,939,942,945,948],{},[19,937,938],{},"Des erreurs ont été disséminées à de nombreux endroits à partir d'une seule mauvaise réponse ou quelque chose qui est resté en suspens. Les conséquences sont assez pénibles, on demande la correction de la référence et ce n’est accompli que partiellement malgré l'affirmation du contraire. On devra revenir à de nombreuses reprises sur cette méprise.\nEn découle une certaine frustration, celle du Product Owner \u002F chef de projet d'avoir laissé passer des specs incorrectes et de se confronter à la rigidité de nos devs. Le paradoxe étant qu'à la base c'est nous le dev, rappelons-le ! Le monde à l'envers, je vous dis.",[19,940,941],{},"On plaide coupable: on a pas lu toute la littérature générée par le framework. En résulte des décisions qu'on n'a pas forcément validé ou qu'on aurait peut être formulé différemment, et par extension quelques déceptions sur le résultat fourni.",[19,943,944],{},"La problématique de la longue session où on doit prendre 3000 décisions est réelle. Dans la vraie vie cela s'étale sur plusieurs semaines, ici on condense tout sur quelques heures. On pourrait stopper avant, certes, mais à l'époque où j'ai testé BMAD on y était pas encouragé. On ne pouvait pas vraiment faire stop et quitter la session dans la minute, le système rédigeant alors le résumé pendant un certain temps, et si on ne voulait pas recommencer à zéro dès le lendemain, on se sentait obligé d'aller au bout de la pénible session en une seule fois.",[19,946,947],{},"Côté UX\u002Fdesign et aussi SEO, nos agents sont un peu trop scolaires. Difficile voire impossible de les faire aller vers quelque chose de créatif, original et avec ce fameux goût humain tant recherché. Ce n'est pas un pb lié uniquement à BMAD bien sûr, c'est lié évidemment mais les débats qu'on aura eu avec nos agents designers Sarah et Tristan ( désolé j'ai déjà oublié vos prénoms ) furent compliqués. Ce sont cela dit des experts et donc si le patron insiste, ils vont se plier à la demande, mais sans conviction. Ça ne serait pas un pb si leurs propositions étaient au niveau. Mais au final, on a dû se battre pas mal et leur faire revoir leur copie de nombreuses fois.",[19,949,950],{},"On ne peut pas virer et recruter d’autres agents. Donc on a dû faire avec Sarah et Tristan jusqu'au bout...",[12,952,953],{},[273,954],{"alt":894,"src":955},"\u002Fblog\u002Fspec-driven-bmad-01\u002Frobot-mad.webp",[51,957,959],{"id":958},"la-sortie-de-bmad-et-les-leçons-pour-la-suite","La sortie de BMAD et les leçons pour la suite.",[12,961,962],{},"Ce qui s'est passé, aussi, il faut être honnête c'est qu'on a complètement pivoté assez vite. Et donc une grande part des specs qui avaient été écrites sont devenues obsolètes.\nOn a gardé l'archi, la stack technique, mais pour tout le reste, on a fait reset et on a choisi d'avancer cette fois-ci sans plan. Par l'expérimentation, les essais.",[12,964,965],{},"Cela dit, on gardera quand même de BMAD un souvenir assez ému de quelques moments étonnants et drôles comme certaines questions \"psy\" de brainstorming, ou ces réunions de bots où on ne pouvait pas en placer une.",[12,967,968],{},"Et on cherchera à trouver un workflow plus personnel, plus souple pour pouvoir planifier et suivre un développement en solo, notamment pourquoi pas en branchant un système de suivi de ticket par exemple, en le branchant via MCP , tout comme Git.",[12,970,971,972,975],{},"On le trouvera un peu plus tard avec les skills de ",[22,973,974],{},"Matt Pocock",", qu'on branchera à Linear et Gitlab pour une expérience un peu plus complète et convaincante.",[51,977,384],{"id":383},[189,979,980,987],{},[19,981,982,983],{},"Documentation BMAD (FR) : ",[25,984,985],{"href":985,"rel":986},"https:\u002F\u002Fdocs.bmad-method.org\u002Ffr\u002F",[394],[19,988,989,990],{},"GitHub BMAD-METHOD : ",[25,991,992],{"href":992,"rel":993},"https:\u002F\u002Fgithub.com\u002Fbmad-code-org\u002FBMAD-METHOD",[394],{"title":414,"searchDepth":415,"depth":415,"links":995},[996,997,998,999,1000,1001,1002,1003,1004,1005,1006],{"id":53,"depth":415,"text":54},{"id":91,"depth":415,"text":92},{"id":802,"depth":415,"text":803},{"id":832,"depth":415,"text":833},{"id":857,"depth":415,"text":858},{"id":885,"depth":415,"text":886},{"id":898,"depth":415,"text":899},{"id":914,"depth":415,"text":915},{"id":929,"depth":415,"text":930},{"id":958,"depth":415,"text":959},{"id":383,"depth":415,"text":384},".\u002Fspec-driven-01.webp","2026-09-16",{},{"title":680,"description":430},"blog\u002Fspec-driven-bmad-01\u002Findex",[439,440,441,442,443],"ov6zpmhyHF__IDkbNRPOWNKSUfGRHj1_P9qBeCZGN5M",1793615039026]