J'ai passé un samedi pluvieux à lire d'une traite les sept release notes de Hermes Agent. C'est le genre d'activité de week-end qui sonne ennuyeux quand on en parle, mais qui est franchement passionnant si tu es du genre à aimer regarder un projet se construire sous tes yeux. À la fin, j'avais un mur couvert de post-its, quatre cafés au compteur, et une vision assez nette de ce qui s'était passé.
Entre le premier tag public le 12 mars 2026 et la sortie de v0.8.0 le 8 avril, Hermes Agent a publié sept versions numérotées en vingt-sept jours. En moyenne, une version tous les quatre jours. Le total des PR sur l'ensemble de ces versions se compte en quatre chiffres. Le nombre de contributeurs est passé de soixante-trois au lancement à bien plus de deux cents.
Ces chiffres ne sont pas la partie intéressante. Ce qui est intéressant, c'est que les versions ne ressemblent pas à un flot continu et indifférencié de PR. Elles se répartissent en quatre phases bien distinctes, et on voit le projet changer de focus à peu près toutes les semaines.
Phase 1 : Les fondations (v0.2.0)
v0.2.0, sortie le 12 mars, c'est le lancement public. Sa mission : livrer un squelette fonctionnel. Le gateway de messagerie multi-plateforme (Telegram, Discord, Slack, WhatsApp, Signal, IMAP/SMTP et Home Assistant dans un seul processus), un client natif Model Context Protocol, un système de skills avec plus de soixante-dix skills intégrés, un routeur centralisé de providers avec un seul point d'entrée call_llm(), et l'isolation par git worktree + les checkpoints du système de fichiers — le filet de sécurité pour un agent qui a le droit de modifier ta machine. L'intégration ACP avec VS Code, Zed et JetBrains a fait en sorte que ce ne soit pas qu'un truc de terminal dès le premier jour.
C'est la version « voilà ce que ce truc est ». Tout ce qui suit repose sur ces cinq décisions.
Phase 2 : L'expansion (v0.3.0 – v0.5.0)
Les trois versions suivantes, entre le 17 mars et le 28 mars, avaient pour but d'étendre la surface dans toutes les directions.
v0.3.0, le 17 mars, a ajouté le streaming sur toute la boucle agent, les hooks du système de plugins, et la première grosse intégration mémoire — Honcho comme provider de mémoire. C'est cette version qui a transformé Hermes, de « un processus avec des outils » à « un processus avec un écosystème de plugins vivant et une couche de mémoire ».
v0.4.0, sortie le 23 mars, portait sur l'expansion des plateformes : WhatsApp Business API, Signal avec support complet des pièces jointes, et une poignée d'adaptateurs gateway supplémentaires. Plus de portes d'entrée pour le même agent.
v0.5.0, le 28 mars, était une version de consolidation. Corrections de concurrence, race conditions sur les sessions, traitement des résultats d'outils, particularités des providers. Le genre de travail qui ne fait pas de bande-annonce, mais sans lequel rien au-dessus ne tient.
En lisant ces trois versions ensemble, on voit le projet essayer de répondre à une question : « maintenant qu'on a un noyau, quelle part du monde réel on peut atteindre depuis, sans le casser au passage ? » La réponse, à la fin de v0.5.0 : la quasi-totalité.
Phase 3 : La durabilité (v0.6.0 – v0.7.0)
Ensuite, le focus change. v0.6.0 le 30 mars et v0.7.0 le 3 avril cherchent à rendre le truc durable.
v0.6.0 a introduit les Profiles — Hermes en multi-instance, où une seule installation peut faire tourner plusieurs agents totalement isolés, chacun avec sa propre config, sa mémoire, ses sessions, ses skills et ses services gateway. Elle a aussi livré le mode serveur MCP, qui permet à Hermes de s'exposer à d'autres clients MCP comme Claude Desktop ou Cursor, plus un conteneur Docker officiel. Et elle a posé les chaînes de fallback ordonnées entre providers, le moment où l'histoire « changer de provider sans tout reconstruire » commence à avoir du mordant. Deux nouvelles plateformes de messagerie, Feishu/Lark et WeCom, ont rejoint le gateway.
v0.7.0, la version résilience, est celle où l'architecture est devenue véritablement défensive. Providers de mémoire interchangeables — la mémoire devient une ABC de provider que des tiers peuvent implémenter, avec Honcho comme plugin de référence. Pools de credentials au sein d'un même provider avec rotation thread-safe par moindre utilisation et failover sur 401. Backend navigateur anti-détection Camofox pour le travail web furtif. Aperçus de diff en ligne pour les opérations d'écriture et de patch. Continuité de session du serveur API via les headers X-Hermes-Session-Id. Un audit de sécurité contre l'exfiltration de secrets, où les réponses LLM sont scannées à la recherche de credentials encodés en Base64 ou URL.
À la fin de v0.7.0, le projet avait cessé de ressembler à un truc nouveau pour commencer à ressembler à de l'infrastructure. Le genre qu'on met sous un cron job sans se faire de souci.
Phase 4 : L'intelligence (v0.8.0)
Ce qui nous amène au 8 avril et à v0.8.0, la version dont j'ai parlé dans les deux articles précédents. Le titre, c'est la boucle de guidance tool-use GPT/Codex auto-optimisée — l'agent qui diagnostique et corrige ses propres modes de défaillance sur les modèles OpenAI par du benchmarking comportemental automatisé. Mais replacée dans l'arc en quatre phases, cette version fait quelque chose de précis : c'est la première où le projet a tourné son regard vers l'intérieur, sur la qualité de raisonnement de l'agent lui-même, après trois semaines d'expansion vers l'extérieur. Changement de modèle en live avec /model, Gemini gratuit, MiMo v2 Pro gratuit, notifications de tâches en arrière-plan, timeouts d'inactivité, boutons d'approbation, MCP OAuth 2.1 PKCE, scan de malware OSV pour les extensions MCP. 209 PR. 82 issues résolues. Cinq jours après v0.7.0.
Ce que le rythme raconte
En regardant tout ça comme un arc continu, trois choses sautent aux yeux.
Les versions ont des thèmes, et les thèmes ne se répètent pas. Fondations, expansion, durabilité, intelligence. Personne ne semble avoir décrété que ça devait se passer comme ça — le projet se comporte juste comme s'il sentait ce qui vient ensuite. Ça signifie généralement qu'un petit groupe de personnes surveille l'ensemble de la surface de très près, et que tout le monde tire dans la même direction parce que la direction est évidente.
Les PR viennent de beaucoup de mains. Ce n'est pas un mainteneur et six figurants. Les release notes sont parsemées de pseudos que je ne connais pas. Des pull requests anonymes de gens qui ont débarqué la semaine dernière. Le projet se comporte comme une scène, pas comme une codebase. Et les scènes, quand elles fonctionnent, livrent beaucoup plus vite que les équipes.
La vélocité n'est pas juste un décompte — elle se cumule. v0.2.0 a livré le routeur. v0.6.0 a posé les chaînes de fallback par-dessus. v0.7.0 a posé les pools de credentials par-dessus. v0.8.0 a posé le changement de modèle en live avec /model par-dessus les trois. Chaque version n'est pas un ensemble de fonctionnalités parti de zéro, c'est une couche qui suppose que la version précédente est stable. Tu ne peux pas faire ça si les versions ne sont pas réellement stables. Donc soit les tests fonctionnent, soit la vélocité aurait déjà tué le projet. Ce n'est pas le cas, et ça veut dire quelque chose.
Précision : je ne fais pas partie de l'équipe Hermes. Je suis un fan qui lit les release notes pour le plaisir et qui tient ce site parce que le projet est plus intéressant que ce que sa vitrine marketing laisse penser. Ce que tu regardes, à travers ces vingt-sept jours, ce sont sept versions qui prouvent que l'ingénierie d'agents côté open source est devenue nettement plus intéressante en mars et avril 2026. Je ne sais pas ce que sera v0.9.0. Quoi que ce soit, je lirai les notes le jour de la sortie.