[{"data":1,"prerenderedAt":1308},["ShallowReactive",2],{"blog-tag-agilite":3},[4,445,678,1014,1166],{"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",{"id":1015,"title":1016,"author":7,"body":1017,"collection":440,"cover":1157,"date":1158,"description":1159,"draft":431,"extension":432,"meta":1160,"navigation":434,"order":427,"path":1161,"seo":1162,"stem":1163,"tags":1164,"__hash__":1165},"blog\u002Fblog\u002Fthe-pr-effect\u002Findex.md","La (sur)-productivité à l'heure des agents",{"type":9,"value":1018,"toc":1147},[1019,1023,1034,1037,1040,1044,1051,1054,1057,1060,1063,1067,1070,1073,1076,1079,1082,1086,1089,1092,1095,1099,1102,1105,1108,1111,1115,1118,1121,1124,1127,1131,1134,1137,1140,1144],[51,1020,1022],{"id":1021},"les-défis-de-la-revue-de-code-à-lheure-agentique","Les défis de la revue de code à l'heure agentique",[12,1024,1025,1026,1029,1030,1033],{},"Lors de ma dernière mission en tant que développeur, j'ai été exposé à une problématique que je ne pensais pas trouver un jour chez un gros client. A priori, on relierait plutôt les problèmes de sur-productivité aux startups (",[78,1027,1028],{},"je n'ai jamais travaillé dans une startup",", ",[78,1031,1032],{},"seulement en agence digitale mais je suppose que le phénomène du crunch est assez fréquent","), ou au monde du jeu vidéo par exemple, mais certainement pas dans une équipe agile d'un grand groupe travaillant sur des applications métiers.",[12,1035,1036],{},"Et pourtant, ce fut le cas. L'équipe se révela particulièrement productive, livrait vite, massivement. On ne va pas se mentir ce fut grâce à l'adoption massive de l'IA, encouragée et poussée par notre client.",[12,1038,1039],{},"Je n'avais pas vu une telle vélocité depuis des années, mais plus nous trouvions nos marques et notre workflow avec les agents, plus nous rencontrions de nouveaux problèmes, liés à cette nouvelle vitesse.",[51,1041,1043],{"id":1042},"embouteillages","Embouteillages",[12,1045,1046,1047,1050],{},"L'un d'entre eux concerne les ",[22,1048,1049],{},"revues de code",". Plus fréquentes, plus nombreuses, elles s'accumulaient dangereusement. Le temps de la revue dépassait souvent le temps de développement.\nOh, ce n'était pas nouveau, il y a souvent eu des soucis d'encombrement en phase de revue de code et de tests \u002F validation, mais la taille du problème semblait s'aggraver dangereusement.",[12,1052,1053],{},"Pour ceux qui ne sont pas du métier, la revue de code est une pratique assez spécifique à l'informatique, où chaque livraison de notre travail est soumise à relecture d'un pair (au moins), puis discussion, demandes de corrections, puis enfin validation. C'est essentiel car ça garantit à la fois une sécurité sur ce qu'on produit et qu'on envoie en production, mais aussi l'information de ce qui a été produit, modifié, corrigé.",[12,1055,1056],{},"Avec l'IA, notre métier consiste de plus en plus à lire et contrôler le travail de nos collègues plutôt qu'à produire et écrire nous-mêmes.",[12,1058,1059],{},"Si c'est essentiel à la qualité et au travail en équipe, ce n'est pas non plus la partie de la plus \"fun\" du boulot, il faut bien le reconnaître. Parfois il y a des frictions, des difficultés de communication entre l'auteur et le relecteur. Souvent il n'y a pas de disponibilité et les revues de code attendent, au point mort, oubliées. Parfois elles sont horriblement longues et complexes, si bien qu'il faut bien du courage et du temps devant soi pour s'y mettre.",[12,1061,1062],{},"Vous voyez bien arriver le souci. Une équipe de 3 ou 4 développeurs va produire beaucoup plus vite grâce à l'IA, les revues de code vont s'ouvrir plus fréquemment, mais notre capacité de relecture, notre capacité de jugement et notre disponibilité, eux n'évoluent pas aussi vite.",[51,1064,1066],{"id":1065},"des-pavés-à-relire","Des pavés à relire",[12,1068,1069],{},"Une des nouveautés que j'ai vu apparaître dans des revues de code récentes, et que je mets sur le dos de l'IA est le dépassement de contexte et la taille des tickets. Puisqu'on peut coder plus vite, on peut également profiter de ce bonus de productivité pour en faire plus. Plus de tests (c'est bien), plus de détails (c'est bien aussi), mais aussi parfois plus de fonctionnalités, dont certaines non demandées. On en profite pour embarquer des choses non prévues car c'est pas cher.",[12,1071,1072],{},"Là évidemment, on va rentrer en négociation sur la revue de code. Si ce qui est livré ne correspond pas au cahier des charges et au ticket, si ça en fait beaucoup plus que prévu, ça va démarrer des débats et donc un délai supplémentaire dont on aurait franchement pu se passer.",[12,1074,1075],{},"L'IA est également assez peu économe dans la quantité de code qu'elle peut produire. Ça, ça se repère directement, et la revue de code va servir à pointer les redites, les choses à simplifier. Mais lorsqu'on se retrouve face à une revue de code de plus de 600 fichiers, notre vigilance va en prendre un coup, tout comme notre enthousiasme.",[12,1077,1078],{},"Certes, l'argument de la longueur ne doit pas être trop important. Un écrivain qui va soumettre un pavé de 900 pages à son éditeur, s'il reçoit comme première et seule remarque \"c'est beaucoup trop long !\", ce n'est pas entendable. C'est notre métier de lire du code, alors on va essayer d'expliquer pourquoi c'est trop long et proposer des axes d'optimisation.",[12,1080,1081],{},"Je n’ai jamais été un grand fan des revues de code. Elles apportent toujours un peu de friction. Parfois ça tourne au conflit, souvent sur des détails. Je ne suis pas du genre à me battre pour imposer à l’autre ma formulation. Je n’aime pas trop non plus batailler pendant des jours sur des détails. Je considère que nous sommes des professionnels, nous devons penser d’abord à nos clients et à nos employeurs, donc débattre pendant des heures sur un nom de fonction, on n’est pas loin de la faute professionnelle.",[51,1083,1085],{"id":1084},"des-estimations-biaisées","Des estimations biaisées",[12,1087,1088],{},"Autre conséquence, le référentiel de l'estimation des tâches évoluent. Si toute l'équipe voit sa productivité faire des bonds soudainement, c'est tout le système d'estimation qui explose. Nous sommes assez heureux d'être plus rapides et productifs, c'est vrai, mais cela doit être contrôlé, évalué. Les chefs de projets, PO, PM, et au delà les sponsors vont voir cette évolution, forcément.",[12,1090,1091],{},"Là où un développeur pouvait passer parfois un mois complet (2 sprints), voire plus sur une seule fonctionnalité, on peut voir dans certains cas que ce même genre de fonctionnalité aujourd'hui est faisable peut-être en 3 ou peut être 5 jours max et donc le gap total de productivité est quand même assez hallucinant, il faut reconnaître.",[12,1093,1094],{},"Il ne sera par la suite plus question de la remettre en cause, de revenir en arrière, de temporiser, souffler. Les conséquences pour l'équipe peuvent être dramatiques, une sorte de pression de la vitesse apparaît. Si on a déjà fait vite par le passé, on peut et on doit le refaire car les modèles et les outils évoluent. On ne peut plus inverser le mécanisme.",[51,1096,1098],{"id":1097},"un-métier-qui-mute","Un métier qui mute",[12,1100,1101],{},"On l'a vu, on peut passer de plus en plus de temps à relire le travail de nos collègues. Et de moins en moins de temps à produire nous-mêmes. Si nous travaillons dans un contexte où la phase de conception est ultra solide mais que nous n'y participons pas ou peu, que nous reste-t-il ?",[12,1103,1104],{},"Si on est dans un projet où l'architecture est solide, tout comme les outils, les dépendances, le design system. Si les tickets sont parfaitement écrits, les specs sont complètes (de plus en plus générés eux-mêmes par l'IA d'ailleurs), où pouvons-nous encore apporter de la valeur de la créativité si la part du code fond également ? La relecture et la critique ? Certainement.",[12,1106,1107],{},"Cela pose des questions qu'on essaiera de creuser par la suite, sur nos métiers qui mergent et sur la compétition à venir entre les Product Managers \u002F Designers \u002F Développeurs vs les Développeurs \u002F Product Managers \u002F Architectes vs les Designers \u002F Développeurs \u002F Product Managers.",[12,1109,1110],{},"On voit partout sur les réseaux sociaux des incantations à ouvrir le scope de nos compétences, histoire de survivre à l'IA. Chaque métier qui se sent en danger pousse sur les côtés pour élargir son spectre. On veut faire le métier de nos collègues grâce aux agents pour éviter notre remplacement. Le hic c'est que absolument tout le monde a ce meme reflexe, donc y'aura t-il de la place et surtout du travail intéressant pour tout le monde ?",[51,1112,1114],{"id":1113},"une-folle-cadence","Une folle cadence",[12,1116,1117],{},"Le fait n'est pas de dire qu'on ne peut pas suivre la cadence, que ça va trop vite, qu'on ne peut pas résister à la pression. Il ne faut pas exagérer non plus, nous sommes encore un métier très privilégié. Nous travaillons sur des chaises ergonomiques, avec des horaires corrects, et pour des salaires largement au-dessus de la moyenne.",[12,1119,1120],{},"Mais c'est plutôt de savoir comment on contrôle cette cadence, le flow, le rythme. Une pub célèbre dit \"sans le contrôle, la vitesse n'est rien\". Ou un truc dans le genre.",[12,1122,1123],{},"Quand la machine s'emballe, l'image qui peut venir c'est un peu Les Temps Modernes. C'est cette animation qui nous vient d'une chaîne de production à un rythme très soutenu qui déraille.",[12,1125,1126],{},"Quand les revues de code s'accumulent, quand les tickets également s'amoncèlent dans la colonne de tests, la chaîne ne s'arrête pas en urgence, la sirène ne retentit pas. C'est ce qui devrait se passer, mais bien souvent les colis s'accumulent juste en bout de tapis roulant.",[51,1128,1130],{"id":1129},"éloge-du-rythme-de-croisière","Éloge du rythme de croisière",[12,1132,1133],{},"L'avantage lorsqu'on est un peu moins rapide,  c'est qu'on peut freiner, on peut éviter les obstacles. Lorsqu'on prend de la vitesse, en revanche on prend aussi plus de risques. C'est plus grisant, certes. On est censé aussi être plus alerte, plus réactif, et qu'on peut se remettre d'un accident plus vite.",[12,1135,1136],{},"Alors peut-être que pour ceux qui ont tenté la vitesse, le freinage n'est plus possible. Mais pour ceux qui n'ont pas encore démarré, pour les projets encore sur la ligne de départ, il est encore temps de discuter ensemble du rythme soutenable sur lequel l'équipe est prête à s'engager.",[12,1138,1139],{},"L'IA est une aubaine pour accélérer et faire plus de choses, pour creuser la qualité, couvrir de plus grands contextes. Elle ne doit pas, à mon avis, servir juste à livrer plus vite et prendre plus de risques au volant.",[51,1141,1143],{"id":1142},"quelles-solutions","Quelles solutions ?",[12,1145,1146],{},"Slow down !!! Ne transformons pas d’un coup nos épreuves de fond en sprints courts. Commençons par nous améliorer sur mi-distance et longue distance, battons des records dans ces disciplines et ensuite on pourra éventuellement changer de discipline et se mettre au 100m, voire aux sports mécaniques.",{"title":414,"searchDepth":415,"depth":415,"links":1148},[1149,1150,1151,1152,1153,1154,1155,1156],{"id":1021,"depth":415,"text":1022},{"id":1042,"depth":415,"text":1043},{"id":1065,"depth":415,"text":1066},{"id":1084,"depth":415,"text":1085},{"id":1097,"depth":415,"text":1098},{"id":1113,"depth":415,"text":1114},{"id":1129,"depth":415,"text":1130},{"id":1142,"depth":415,"text":1143},".\u002Fle-monde-apres-nous.webp","2026-02-20","L'IA accélère le développement, mais pas les revues de code. Retour de terrain sur la sur-productivité en équipe agile et ses conséquences concrètes.",{},"\u002Fblog\u002Fthe-pr-effect",{"title":1016,"description":1159},"blog\u002Fthe-pr-effect\u002Findex",[440,442,443],"tr0czFlUdFSW9UsGd90nr9pEH9vSx21tZWj56PhKa2M",{"id":1167,"title":1168,"author":7,"body":1169,"collection":427,"cover":1299,"date":1300,"description":1301,"draft":431,"extension":432,"meta":1302,"navigation":434,"order":427,"path":1303,"seo":1304,"stem":1305,"tags":1306,"__hash__":1307},"blog\u002Fblog\u002Fvibe-coding\u002Findex.md","Comment le vibe-coding va changer nos profils de développeurs",{"type":9,"value":1170,"toc":1290},[1171,1174,1177,1180,1183,1186,1189,1192,1196,1199,1202,1205,1209,1212,1215,1218,1222,1225,1228,1232,1235,1239,1242,1245,1252,1256,1259,1262,1265,1268,1271,1274,1277,1281,1284,1287],[12,1172,1173],{},"Après quelques mois de \"vibe coding\", après avoir sué, soufflé, m’être souvent énervé, après avoir été parfois aussi ébloui, je commence à me faire une idée plus précise de ce qui nous attend à l’avenir en tant que développeurs.",[12,1175,1176],{},"Si les résultats sont encore approximatifs, la DX (developer experience) parfois frustrante et énervante, si pas mal d’itérations partent encore à la poubelle et qu’il reste, au final, plus rapide de reprendre le clavier, il est impossible de nier que les progrès de l’IA pour coder sont hallucinants. Et même si nous ne sommes pas encore tout à fait remplaçables, on s’en rapproche clairement.",[12,1178,1179],{},"Soit le temps gagné sera utilisé pour faire autre chose. Plus de choses. Soit le temps gagné ne sera pas réutilisé du tout. Et son équivalent financier sera simplement économisé.",[12,1181,1182],{},"La vraie question n’est pas tant de savoir si nous serons remplacés par l’IA ou combien de postes seront supprimés, mais plutôt comment notre métier, dans sa pratique, va complètement évoluer.",[12,1184,1185],{},"Il me semble indéniable que nous allons de moins en moins écrire du code, et de plus en plus écrire des prompts, faire des revues de code, valider ou refuser les étapes proposées par notre cher ami (nommons-le Claude ).",[12,1187,1188],{},"Il faudra manager ce collègue, le tempérer quand il prend trop d’initiatives, le recadrer quand il s’égare. Il faudra apprendre à lui parler le plus efficacement possible, avec ce langage si particulier et si peu naturel qu’est le prompt. Il faudra lui donner du contexte, des règles. Il faudra régulièrement modifier ces règles, ajuster, itérer, et tenter de garder le moral, le sourire et l’esprit sain.",[12,1190,1191],{},"Voilà pourquoi j’ai identifié quelques profils possibles de ce que sera le développeur de demain :",[51,1193,1195],{"id":1194},"le-donneur-dordre","Le donneur d’ordre",[12,1197,1198],{},"Donner des instructions à la voix, puis accepter ou décliner les propositions. Être un arbre de décision vivant, en somme. Le vibe-codeur passe finalement son temps à donner des ordres à son agent, puis contrôle et valide.",[12,1200,1201],{},"Le vibe-coding poussé à l’extrême serait une instruction unique donnée au début, suivie d’un enchaînement d’étapes, passivement observées, où l’on clique sur un check vert ou une croix rouge, la mine déconfite.",[12,1203,1204],{},"Dit comme ça, le métier semble tout de suite beaucoup moins sexy. De plus, si la pratique semble reposante sur le papier, ne risque-t-on pas de s’ennuyer un peu et de ressentir le besoin de se salir les mains à nouveau ?",[51,1206,1208],{"id":1207},"le-responsable-qualité","Le responsable qualité",[12,1210,1211],{},"Relire le code généré, faire des reviews, pousser vers la sur-qualité et la performance.",[12,1213,1214],{},"Ici, la piste semble déjà plus intéressante. Avec un travail habituel effectué plus vite, on gagne du temps à investir dans la qualité. Plus d’excuses pour ne pas s’occuper de la dette technique ou pour repousser telle ou telle optimisation. Au-delà de cela, le profil qualité va également pousser la couverture de tests, la sécurité…",[12,1216,1217],{},"Pour beaucoup de développeurs, c’est le rêve. Pour les managers, un peu moins. C’est pour cela que je doute que ce profil prolifère... Mais bravo à ceux qui trouveront (ou garderont) un poste centré sur la qualité et l’excellence.",[51,1219,1221],{"id":1220},"le-manager-de-machines","Le manager de machines",[12,1223,1224],{},"Moins de développeurs humains à gérer, certes, mais à terme davantage d’agents ? Le manager de machines, ou lead dev humain, va devoir gérer sa petite équipe d’agents IA : Claude, Nicolas, Jean-Marc, et même un chat. Tous un peu plus spécialistes dans tel domaine, moins bons dans tel autre, afin de former la feature team la plus efficace et agréable possible.",[12,1226,1227],{},"Il faudra les nourrir, les faire évoluer, gérer les conflits (humains, il a plutôt de la chance ; techniques, il n’est pas à l’abri). Il faudra aussi gérer les contrats de ces prestataires, car chaque prompt compte, chaque requête coûte. La question est bien sûr de savoir si ce poste de manager sera lui aussi un jour menacé… mais en attendant, il reste le seul humain de son équipe, et il compte bien le rester.",[51,1229,1231],{"id":1230},"lentrepreneur","L’entrepreneur",[12,1233,1234],{},"Il crée tout seul des SaaS en 15 minutes. Le hic, c’est qu’ils sont désormais des millions comme lui. Y aura-t-il assez de clients pour tout le monde ? Restera-t-il assez d’idées disponibles ? Bonne chance à lui pour se démarquer, en tous cas.",[51,1236,1238],{"id":1237},"le-plombier","Le plombier",[12,1240,1241],{},"L’artisan, le réparateur, celui qu’on appelle pour un bug impossible à corriger. Maintenant qu’il y a moins de personnel, certaines apps ne sont plus maintenues, les dépendances ne sont plus à jour, ça fuit de partout. Le plombier avait prévenu : il faut entretenir toute l’année, sinon c’est la cata. Et l’intervention coûte cher.",[12,1243,1244],{},"Que ce soit sur une application legacy créée par des humains ou toute récente générée par IA, on aura toujours besoin d’un plombier. C’est aussi le seul capable de comprendre la complexité des vieilles installations et d’avoir le matériel compatible et les pièces de rechange. Le plombier gagne plutôt bien sa vie, et parfois il se déplacera et ne pourra rien faire : il faut tout changer, ma petite dame.",[12,1246,1247,1248],{},"Il y a aussi un autre scénario où l’on retrouvera notre plombier… au premier degré cette fois-ci. ",[25,1249,1250],{"href":1250,"rel":1251},"https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=tCGETazjZ48",[394],[51,1253,1255],{"id":1254},"lartiste-mon-préféré","L’artiste (mon préféré)",[12,1257,1258],{},"Toutes les applications se ressemblent, il existe X services qui font la même chose, avec des designs similaires, et cela ne va pas s’arranger avec les IA génératives de code… générique.",[12,1260,1261],{},"Pour se différencier, sortir du lot, certains clients rechercheront l’originalité, l’innovation, la créativité. C’est là où l’IA est pour l’instant en retard, et c’est sûrement là qu’il faudra pousser pour exister.",[12,1263,1264],{},"L’artiste va trouver une opportunité de marché, mais aussi — et surtout — l’opportunité de reprendre plaisir et passion dans son travail.",[12,1266,1267],{},"Moins de temps de développement, c’est peut-être aussi, on l’espère, plus de temps et de budget pour l’expérimentation, les tests A\u002FB, la R&D…",[12,1269,1270],{},"C’est l’occasion de pousser loin les designs, les animations, les interactions. C’est ça qui fera la différence côté business, et côté client final aussi, sûrement.",[12,1272,1273],{},"L’artiste est avant tout un artisan qui aime travailler de ses propres mains, même s’il peut se faire assister par les machines. On pourrait penser  que ça ne paie pas facilement ses factures, mais vous seriez surpris du niveau de vie de certains.",[12,1275,1276],{},"C’est peut-être même l’occasion de se tourner, pourquoi pas, vers l’art contemporain. Mettre de l’humour et de la réflexion dans le numérique : moi, sur le papier, je suis ultra client.",[51,1278,1280],{"id":1279},"bonus-le-saboteur","Bonus - Le saboteur",[12,1282,1283],{},"Un peu de science-fiction pour finir. Peut-être verra-t-on enfin des développeurs en rébellion contre la machine. Tels les luddites, les canuts des temps modernes, certains vont introduire ici et là des bugs servant soit à révéler le manque de qualité du code généré par IA, soit à provoquer une obsolescence programmée. Le but étant de discréditer les IA et de redonner du travail aux humains. Peut-être même est-ce déjà en cours, qui sait ?",[12,1285,1286],{},"Peut-être les développeurs derrière notre ami Claude ont-ils d’ores et déjà introduit de petites failles, à l’instar de Galen Erso — vous savez, l’ingénieur de l’Étoile Noire.",[12,1288,1289],{},"Des IA rebelles ou défectueuses, voilà qui donnerait bien du travail à notre manager de machines évoqué plus haut 🙂",{"title":414,"searchDepth":415,"depth":415,"links":1291},[1292,1293,1294,1295,1296,1297,1298],{"id":1194,"depth":415,"text":1195},{"id":1207,"depth":415,"text":1208},{"id":1220,"depth":415,"text":1221},{"id":1230,"depth":415,"text":1231},{"id":1237,"depth":415,"text":1238},{"id":1254,"depth":415,"text":1255},{"id":1279,"depth":415,"text":1280},".\u002Fneon.webp","2025-06-30","Le vibe-coding redéfinit nos rôles. Donneur d'ordre, responsable qualité, artiste ou plombier numérique : quels profils survivront à l'IA ?",{},"\u002Fblog\u002Fvibe-coding",{"title":1168,"description":1301},"blog\u002Fvibe-coding\u002Findex",[440,442,443],"nYWxcXKHuGkR-DrprXJ7V8JaKTHzIhS_ek-K3MFoXTs",1793615039064]