Dans un article précédent (Agentic Delivery System : industrialiser le développement logiciel avec des agents IA sans perdre le contrôle), l'idée centrale était simple : l'état de l'art n'est pas agent-first. Il est craft-first, agent-accelerated.
Autrement dit, les agents IA ne doivent pas remplacer la discipline logicielle. Ils doivent l'exécuter plus vite, plus systématiquement et avec plus de traçabilité.
La question suivante est donc très concrète : comment piloter ces agents au quotidien ? Comment passer d'une vision d'Agentic Delivery System à une mécanique réellement utilisable par une équipe produit, engineering et ops ?
C'est là qu'un outil comme Hermes Agent devient intéressant.
Hermes ne doit pas être regardé seulement comme un autre assistant de code. Son intérêt est ailleurs : il peut jouer le rôle d'une couche de pilotage agentique, capable de combiner mémoire persistante, skills, context files, toolsets, subagents, automatisations, canaux de communication et intégrations.
Le point important n'est pas de dire qu'Hermes remplace Codex, Claude Code, Cursor, Devin ou les autres outils. Le point important est de comprendre où il peut se placer dans une architecture d'exécution : au-dessus des tâches, comme chef d'orchestre opérationnel.
Hermes comme couche de pilotage
Un Agentic Delivery System a besoin de trois choses.
D'abord, une méthode : intention, specs, BDD, architecture, craftsmanship, tests, sécurité, livraison et ROI.
Ensuite, des agents spécialisés : recherche, produit, architecture, UX, BDD, TDD, implémentation, sécurité, DevOps, review.
Enfin, une couche de pilotage : un endroit où ces agents peuvent être déclenchés, contextualisés, limités, observés et améliorés.
Hermes est intéressant parce qu'il adresse cette troisième couche.
Sa documentation met en avant plusieurs primitives utiles pour cela : un système de skills, une mémoire persistante, des context files de projet, des checkpoints, des toolsets, des tâches planifiées, une délégation à des subagents et une présence possible sur plusieurs surfaces : terminal, desktop, web dashboard ou canaux de messagerie.
Pris séparément, chacun de ces éléments est utile. Pris ensemble, ils dessinent une architecture : Hermes peut devenir le centre de commande d'une agent factory.
Le cas concret : ReleasePilot
Prenons le même cas fil rouge que dans l'article précédent : ReleasePilot.
ReleasePilot est une plateforme qui transforme les feedbacks clients, tickets support, signaux produit et incidents de production en décisions priorisées, specs vérifiables, tickets engineering, PR assistées et notes de release.
Le cas d'usage à piloter avec Hermes est volontairement précis :
Construire le module Signal Clustering, capable de regrouper automatiquement des feedbacks similaires, de proposer une priorité produit, puis de générer une spec exploitable par l'équipe engineering.
Ce n'est pas une petite tâche de code. C'est une tranche produit complète :
- analyse des feedbacks ;
- modèle de domaine ;
- règles de regroupement ;
- critères de confiance ;
- UX de validation humaine ;
- scénarios BDD ;
- tests rouges ;
- implémentation ;
- feature flag ;
- sécurité ;
- observabilité ;
- mesure du ROI.
Le rôle d'Hermes n'est pas de coder tout cela en une seule passe. Son rôle est de piloter la séquence, de garder le contexte, de déclencher les bons agents, de produire les bons livrables et de forcer les gates.
Étape 1 : créer un profil Hermes dédié
La première décision est organisationnelle : ne pas utiliser un agent générique pour tous les projets.
Dans Hermes, les profils permettent de travailler avec des configurations, sessions, skills et mémoires isolées. Pour un projet comme ReleasePilot, je créerais un profil dédié :
hermes --profile releasepilotL'objectif est simple : séparer le contexte de ReleasePilot du reste.
La mémoire du profil peut retenir des éléments durables : stack technique, conventions de code, préférences de revue, règles de sécurité, style d'architecture, noms des bounded contexts, définition de la qualité.
Mais cette mémoire doit rester concise. Elle n'est pas un dumping ground. Les faits courts vont en mémoire. Les procédures longues vont dans les skills. Les décisions structurantes vont dans les ADR.
Étape 2 : rendre le contexte projet explicite
Hermes peut découvrir et utiliser des fichiers de contexte comme .hermes.md, AGENTS.md, CLAUDE.md ou d'autres fichiers de règles projet.
C'est une pratique centrale.
Avant de demander à Hermes de piloter des agents, il faut documenter le terrain :
- comment installer le projet ;
- comment lancer les tests ;
- comment exécuter le lint et le typecheck ;
- comment créer une migration ;
- comment nommer une branche ;
- comment écrire une PR ;
- quels dossiers ne doivent pas être modifiés sans validation ;
- quels secrets ne doivent jamais être exposés ;
- quels gates sont obligatoires avant merge.
Cette étape paraît banale. Elle ne l'est pas.
Un agent ne peut pas appliquer des standards que l'équipe n'a jamais formulés. L'IA agentique force donc une hygiène d'ingénierie : expliciter le cadre avant d'accélérer l'exécution.
Étape 3 : transformer la méthode en skills
Hermes s'appuie sur un système de skills : des documents d'instructions que l'agent charge à la demande, selon le besoin. La documentation précise que les skills sont disponibles comme commandes et qu'ils suivent une logique de progressive disclosure.
Pour ReleasePilot, je ne créerais pas un skill unique appelé “build feature”. Ce serait trop large.
Je créerais une suite de skills spécialisés :
/releasepilot-research: analyser feedbacks, concurrents, contraintes produit ;/releasepilot-domain: formaliser bounded contexts, entités, invariants ;/releasepilot-bdd: produire exemples métier et scénarios Gherkin ;/releasepilot-architecture: proposer ADR, interfaces, flux, risques ;/releasepilot-tdd: écrire les tests rouges avant l'implémentation ;/releasepilot-implementation: implémenter par petits incréments ;/releasepilot-security-review: vérifier données sensibles, permissions, injections et intégrations ;/releasepilot-pr-review: relire le diff, les tests, les risques et la Definition of Done ;/releasepilot-roi: mesurer temps gagné, défauts évités, cycle time et coût agent.
Ce découpage est essentiel. Il empêche Hermes de se comporter comme un agent omnipotent. Il l'oblige à piloter un processus.
Étape 4 : déléguer à des subagents avec des périmètres limités
La délégation à des subagents est l'une des primitives les plus intéressantes dans une logique de pilotage. Hermes peut déléguer des tâches à des agents enfants avec leur propre contexte et des toolsets restreints.
Dans notre cas, le workflow pourrait ressembler à ceci :
- Hermes reçoit la demande : “Construire Signal Clustering pour ReleasePilot”.
- Hermes refuse de coder immédiatement.
- Il déclenche un subagent Research en lecture seule.
- Il déclenche un subagent Domain pour produire le modèle métier.
- Il déclenche un subagent BDD pour générer les exemples et les scénarios.
- Il déclenche un subagent Architecture pour proposer les ADR.
- Il demande validation humaine.
- Il déclenche un subagent TDD pour écrire les tests rouges.
- Il déclenche un agent Implementation avec droits d'écriture limités.
- Il déclenche Security Review et PR Review.
- Il produit un résumé exécutable pour merge ou reprise.
Le détail important est le mot “limité”.
Le subagent Research n'a pas besoin d'écrire dans le repo. Le subagent BDD peut écrire dans features/ ou docs/specs/, mais pas modifier l'authentification. Le subagent TDD peut créer des tests, mais pas changer l'implémentation. L'agent Implementation peut modifier une zone précise, mais pas toucher aux secrets, à la CI ou aux migrations critiques sans gate humain.
L'autonomie devient acceptable quand elle est bornée.
Étape 5 : imposer BDD, TDD et feature flags dans l'orchestration
Le piège serait d'utiliser Hermes pour aller plus vite vers le code.
Le bon usage est l'inverse : utiliser Hermes pour empêcher l'équipe et les agents de sauter les étapes.
Pour Signal Clustering, la séquence doit être stricte :
- Intent validé.
- Exemples métier validés.
- Scénarios BDD validés.
- ADR validé.
- Feature flag défini.
- Tests rouges écrits.
- Implémentation minimale.
- Tests verts.
- Refactoring.
- Security review.
- PR review.
- Observabilité.
- Rollout contrôlé.
Hermes devient alors un gardien de cadence. Il ne remplace pas le tech lead. Il applique la discipline que le tech lead a rendue explicite.
Exemple de règle de pilotage :
Ne pas déclencher l'agent d'implémentation tant que :
- les scénarios BDD ne sont pas validés ;
- l'ADR n'est pas accepté ;
- les tests rouges n'existent pas ;
- le feature flag et son owner ne sont pas définis.C'est là que l'on passe d'un assistant de génération à une mécanique d'ingénierie.
Étape 6 : utiliser les checkpoints et les gates
Hermes documente un mécanisme de checkpoints qui permet de revenir en arrière après des modifications de fichiers. Dans une logique d'Agentic Delivery System, c'est une brique importante.
Avant chaque phase d'écriture, Hermes devrait créer ou s'appuyer sur un checkpoint :
- avant génération des specs ;
- avant création des tests ;
- avant implémentation ;
- avant refactoring ;
- avant corrections de CI ;
- avant préparation de PR.
Mais le rollback technique ne suffit pas. Il faut aussi des gates humains.
Un humain doit valider :
- les décisions produit ;
- les arbitrages d'architecture ;
- les droits d'accès ;
- les changements de données ;
- la sécurité ;
- le passage en production.
Les agents peuvent préparer, vérifier, résumer, exécuter. Ils ne doivent pas absorber silencieusement la responsabilité.
Étape 7 : automatiser la boucle de suivi avec cron et dashboard
L'autre force d'Hermes est sa capacité à sortir du mode conversation unique.
Avec des tâches planifiées, un gateway ou un dashboard, Hermes peut suivre la vie du projet au-delà de la session de développement.
Pour ReleasePilot, on peut imaginer plusieurs routines :
- chaque matin : résumé des PR ouvertes, CI rouges, risques et blocages ;
- après chaque merge : vérification des notes de release et du flag associé ;
- chaque semaine : analyse du cycle time, des reprises de PR et de la dette ajoutée ;
- après rollout : synthèse des métriques produit et incidents ;
- chaque mois : proposition d'amélioration des skills Hermes.
C'est un point souvent sous-estimé. L'agentic engineering ne s'arrête pas au merge. Il doit intégrer la production, l'observabilité et l'apprentissage.
Hermes, Codex et Claude Code : composer plutôt qu'opposer
Il serait réducteur d'opposer Hermes à Codex ou Claude Code.
Dans une architecture mature, ces outils peuvent avoir des rôles différents.
Hermes peut être la couche de pilotage, de mémoire, de skills, de subagents, d'automatisation et de routage.
Codex ou Claude Code peuvent être utilisés comme agents d'exécution très proches du repo, du terminal et du diff.
GitHub Copilot coding agent, Jules ou Devin peuvent intervenir sur des tâches asynchrones ou des tickets bien bornés.
MCP peut connecter les agents aux systèmes externes, mais avec des permissions strictes.
La maturité ne consiste donc pas à chercher “l'outil qui fait tout”. Elle consiste à dessiner une topologie : qui orchestre, qui exécute, qui vérifie, qui approuve, qui mesure.
Le livrable attendu
À la fin du workflow Signal Clustering, Hermes ne devrait pas seulement produire du code.
Il devrait produire un dossier de livraison complet :
- une note d'intention ;
- une spec produit ;
- des scénarios BDD ;
- un ADR ;
- des tests rouges puis verts ;
- une implémentation bornée ;
- un feature flag documenté ;
- une analyse sécurité ;
- une PR lisible ;
- une note de release ;
- une liste de métriques à suivre ;
- une proposition d'amélioration des skills si le workflow a révélé un apprentissage utile.
C'est ce niveau de livrable qui transforme l'usage des agents en capacité d'organisation.
Les risques spécifiques à Hermes
Un outil puissant crée aussi de nouveaux risques.
Hermes peut retenir de l'information, charger des skills, utiliser des toolsets, déléguer à des subagents, automatiser des tâches et interagir depuis plusieurs canaux.
Chaque capacité doit être gouvernée.
Les principaux risques sont connus :
- mémoire trop large ou mal curée ;
- skills qui contiennent des instructions obsolètes ;
- subagents avec trop de permissions ;
- toolsets activés par défaut sans besoin réel ;
- automatisations cron qui agissent sans revue ;
- exposition de secrets ;
- prompt injection via contenus externes ;
- confusion entre suggestion et décision ;
- absence de traçabilité sur les changements.
La bonne posture n'est pas de refuser l'autonomie. C'est de la borner.
Conclusion
Hermes devient intéressant quand on cesse de le regarder comme un simple agent conversationnel.
Son potentiel est de devenir une couche de pilotage : mémoire, skills, subagents, toolsets, checkpoints, automatisations et canaux.
Mais cette puissance ne vaut que si elle est branchée sur une discipline d'ingénierie : BDD, TDD, red-green-refactor, architecture explicite, feature flags, sécurité, review et ROI.
Le bon modèle n'est pas “Hermes code à notre place”.
Le bon modèle est : Hermes orchestre un système où le jugement humain est rendu exécutable par des agents spécialisés.
C'est cette bascule qui compte.
Pas plus d'IA. Plus d'ingénierie rendue opérable.