Specs Driven Vibe Coding : 3/3 : Hermes

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.

1. 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
2. Le second article traitait des **skills de Matt Pocock**, une version un peu moins dense et plus orientée dev
3. Dans ce troisième, on a tenté de créer notre propre workflow, avec Hermes, sa mémoire, ses bots… et un twist qu'on n'avait pas vraiment vu venir.

Contexte

Cette fois, le terrain de jeu était une landing / marketing page. Rien de monstrueux côté produit, mais un double objectif clairement affiché :

1. Concevoir et développer la page (Astro côté front, design sur Figma / Paper)
2. Migrer l'agent sur un serveur dédié, un mini-PC d'entrée de gamme qui a bien 10 ans, et le piloter depuis Hermes Desktop… ou depuis le téléphone.

Autrement dit : continuer la logique specs-driven des deux premieres experiences, mais changer aussi le où et le comment on travaille avec l'agent. Moins collé à un IDE local, plus proche d'une présence distante, joignable depuis n'importe où.

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).

Stack utilisée

Le spoil annoncé dès le premier article se concrétisait enfin : app desktop, modèles chinois, contrôle à distance depuis une messagerie. On y était.

Intro : écrire sa propre méthode

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 : garder l'esprit, pas le framework.

On a donc écrit nos propres versions des briques qui avaient marché :

• un /grill-me maison, pour stress-tester les décisions avant de coder
• un /to-specs pour formaliser le besoin en spec technique et fonctionnelle
• /to-issues pour découper ecrire les ticket dans Linear
• du contexte design, de la littérature, des capacités un peu plus poussées côté UI/UX (le point faible récurrent des deux premiers essais)
• et aussi un branchement vers Obsidian, notre « second cerveau », comme base documentaire

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 ».

La hype des bots

L'autre promesse qui nous a hypé tout l'été, c'étaient les bots.

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.

Pour le workflow qu'on voulait tester, c'était exactement le point : l'agent n'habite plus seulement l'IDE, il habite un canal de communication.

Ressenti

Sur le fond, on était convaincus.

• Les concepts tiennent la route : skills perso, mémoire, auto-amélioration, tickets Linear, design un peu mieux outillé.
• Les perfs étaient là, le résultat aussi : on avançait, on livrait, on itérait.
• 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.

Le petit bémol, honnêtement assez prosaïque : les 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.

Et puis...

... le drame

Un dimanche matin, notre fier mini-PC a refusé de rebooter, juste après une mise à jour serveur.

Disparu Hermes. Envolée la mémoire. (Techniquement on peut récupérer le SSD, oui… mais bon.)

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.

And now : Cursor !

Il a fallu rebondir. Et là, on a essayé Cursor, un peu en reculant, pas ultra emballés au départ à l'idée de donner des sous à Elon Musk et Grok.

Sauf que Cursor cochait, d'un coup, la plupart des cases qu'on cherchait avec Hermes :

• agents dans le cloud, ou sur d'autres machines
• contrôle depuis le mobile
• des (Grok) bots
• la possibilité d'utiliser des modèles différents
• des intégrations vraiment propres avec GitLab et Figma

Le verdict, pour le moment, est sans appel : ça marche du tonnerre.

Ironique, après une série qui partait de Claude Code, passait par OpenCode / 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.

End game

Sur trois essais (BMAD, skills Pocock, Hermes + skills maison), quelques constantes ressortent :

1. Planifier aide, surtout sur plusieurs sessions. Mais la cérémonie trop lourde se paie cash (BMAD).
2. Les skills légères et customisables passent mieux en solo que les frameworks « équipe virtuelle » complète.
3. Tickets + MCP (Linear, GitLab…) restent utiles… surtout pour nous. Les agents, eux, pourraient souvent s'en passer.
4. Design / UX restent le terrain où il faut encore pousser le contexte soi-même.
5. La mémoire et le remote changent vraiment le game, jusqu'au jour où le hardware lâche.
6. 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.

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.

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.

Pour aller plus loin

• Hermes Agent (Nous Research) : https://hermes-agent.nousresearch.com/
• Skills Matt Pocock : mattpocock/skills
• Article 1 : BMAD
• Article 2 : Skills Pocock