Gouvernance Hermes Agent : poser des règles sans tuer l’autonomie

Pourquoi la gouvernance est le vrai sujet apres l’installation

Installer Hermes Agent, c’est la partie facile. Le vrai travail commence quand les workers tournent et que tu realises qu’ils peuvent tout faire : ecrire des fichiers, executer des commandes, modifier du code, envoyer des messages. Sans cadre, un agent bien intentionne peut faire des degats en quelques secondes.

Le probleme n’est pas la malveillance. C’est l’absence de limites claires. Un worker qui a acces a tout ton systeme va faire ce que tu lui demandes, mais aussi ce que tu n’as pas pense a lui interdire. La gouvernance, c’est l’inverse du frein : c’est le garde-fou qui permet d’accelerer sans risque.

Si tu deployes Hermes pour des taches reelles, la question n’est pas « est-ce que ca marche » mais « qu’est-ce qui peut mal tourner et comment je le controle ». C’est le sujet que tout le monde decouvre apres la premiere semaine d’enthousiasme, quand le premier worker fait une action que personne n’avait prevue.

Communauté Kavyro

Le vrai sujet n’est pas d’ajouter un agent de plus.

Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.

Cas concrets Arbitrages utiles Questions réelles Accès gratuit

Rejoindre la communauté

Tu arrives avec ton sujet, tu repars avec plus de clarté.

Definir le perimetre de chaque worker Hermes

Un worker Hermes sans perimetre, c’est un stagiaire a qui tu donnes les cles du serveur sans lui dire ce qu’il a le droit de toucher. La premiere regle de gouvernance, c’est de definir ce que chaque worker peut et ne peut pas faire, et de le faire avant le premier lancement.

Concretement, ca passe par trois decisions :

• Un repertoire de travail limite. Chaque worker ecrit dans son propre espace. Pas d’acces au systeme, pas de modification des fichiers critiques. Si un worker doit lire une base, tu lui donnes un acces en lecture seule, pas un shell root. Hermes permet de configurer ces chemins dans le fichier de profil de chaque worker.
• Des outils restreints par profil. Tous les workers n’ont pas besoin de tous les outils. Un worker redactionnel n’a pas a executer du code. Un worker technique n’a pas a envoyer des emails. Hermes permet de lier des outils specifiques a chaque profil. C’est une fonctionnalite souvent sous-estimee mais qui fait la difference entre un worker maitrisable et un worker dangereux.
• Un contexte defini a l’avance. Le worker sait quel projet il sert, quelles sont ses sources autorisees, et ou il peut ecrire le resultat. Tout ce qui sort de ce cadre doit etre bloque ou escalade vers un humain.

Le piege classique, c’est de donner trop de permissions « au cas ou ». On se dit que le worker aura peut-etre besoin d’acceder a tel dossier ou tel outil plus tard. Resiste. Ajoute des droits quand le besoin est prouve, pas par anticipation. Un worker avec trop de permissions est un risque qui n’attend qu’une mauvaise consigne pour se concretiser.

Regles de validation : ce qui passe seul, ce qui demande un humain

Tous les workers n’ont pas le meme niveau d’autonomie. Certaines actions peuvent etre executees sans controle humain. D’autres doivent etre validees avant d’etre appliquees. La cle, c’est de definir la regle avant le besoin, pas au moment ou le worker demande. Si tu improvises la validation quand le worker est deja en train d’executer, tu prends une decision sous pression.

Voici comment trancher selon le type d’action :

1. Actions reversibles (lire un fichier, generer un draft, analyser des donnees) : peuvent passer en automatique. Le risque est faible, le cout d’une erreur est nul. C’est la que l’autonomie apporte le plus de valeur.
2. Actions irreversibles (supprimer, modifier en production, envoyer un message a un client, payer) : validation humaine obligatoire. Hermes peut bloquer l’action et notifier un humain pour approbation via son systeme de hooks de validation.
3. Actions a cout variable (appels API payants, calculs longs) : seuil de declenchement avec alerte. Si le worker depasse un certain volume, il doit demander la permission avant de continuer.

La regle est simple : plus l’action est couteuse ou difficile a annuler, plus le niveau de validation doit etre haut. J’ai detaille le fonctionnement des validations dans un article sur la demande de validation par un agent IA, avec des exemples concrets de configuration Hermes.

Un bon reflexe : commence avec validation humaine sur tout, puis assouplis au fur et a mesure que tu fais confiance au worker. C’est plus safe que l’inverse, et ca t’oblige a comprendre ce que chaque worker fait vraiment avant de lui donner de l’autonomie.

Limites de cout et de volume par worker

Un worker Hermes coute de l’argent : tokens API, temps de calcul, appels externes. Sans limite, un worker bouclant sur une tache mal formulee peut bruler un budget mensuel en une heure. C’est un classique : une consigne ambigue, un worker qui reessaye en boucle, et la facture API explose avant que tu aies le temps de reagir.

Les garde-fous minimaux a poser :

• Un budget token par session. Definis un plafond par worker et par tache. Si le worker depasse, il s’arrete et demande une instruction. Hermes permet de configurer ce seuil dans le profil du worker.
• Un nombre maximum d’iterations. Un worker qui tourne en boucle sur une correction doit etre interrompu apres N tentatives. C’est souvent le signe d’une consigne mal ecrite ou d’un probleme insoluble. Mieux vaut un arret propre qu’une boucle infinie qui coute cher.
• Un quota journalier. Certains workers peuvent etre utilises intensivement. Fixe un volume max par jour pour eviter les surprises sur la facture API. Tu peux le reinitialiser le lendemain si le besoin est legitime.

Ces limites ne sont pas du confort, ce sont des mecanismes de survie pour ton budget et ta tranquillite. Un worker bien configure avec des limites claires est plus fiable qu’un worker sans contrainte, parce que les contraintes l’obligent a arreter de persister sur une tache mal posee.

Logs et audit : ce qu’il faut garder

Quand un worker fait une erreur, tu dois pouvoir comprendre pourquoi. Les logs sont ta seule source de verite. Mais tout garder, c’est la porte ouverte au bruit et au cout de stockage. L’equilibre est de conserver ce qui permet de diagnostiquer un probleme sans noyer l’information utile dans des gigas de donnees.

L’essentiel a conserver : chaque action executee avec son timestamp, le worker concerne, et le resultat. Tu dois pouvoir reconstituer ce qui s’est passe. Ajoute les decisions de validation : ce qui a ete approuve, refuse, ou escalade. C’est ce qui permet d’ajuster les regles. Enfin, garde les erreurs et les echecs : c’est la que tu apprends. Un worker qui echoue systematiquement sur une meme tache a besoin d’une correction de perimetre ou de consigne, pas d’un redemarrage.

Inutile de garder le contenu complet de chaque reponse API. Un resume des actions et des decisions suffit pour l’audit. Le reste, tu peux le regenerer si necessaire. L’objectif n’est pas d’avoir une tracabilite parfaite de chaque token, mais de pouvoir repondre a la question : « qu’est-ce qui s’est passe et pourquoi ».

J’ai ecrit sur les points de controle en production pour les agents IA : ca complete bien la question des logs avec une approche plus large de la supervision et de la detection des anomalies.

Gouvernance sans usine a gaz : le minimum viable

La tentation, c’est de vouloir tout cadrer des le premier jour. Resultat : un systeme tellement verrouille que les workers ne peuvent plus rien faire d’utile. La gouvernance doit etre progressive. Tu commences avec les regles essentielles, tu observes, tu ajustes. C’est un cycle, pas un cahier des charges qu’on ecrit une fois pour toutes.

Le minimum viable pour demarrer :

1. Un perimetre strict : chaque worker a son dossier, ses outils, son contexte. Pas d’acces systeme, pas de droits non justifies.
2. Validation humaine sur les actions irreversibles : suppression, modification critique, envoi externe. Tout ce qui touche a la production ou aux clients.
3. Une limite de cout basse : 5 a 10 euros de budget token par jour et par worker. Tu ajusteras a la hausse quand tu auras confiance dans le comportement du worker.
4. Un fichier de logs simple : actions, decisions, erreurs. Un fichier texte par worker, horodate. Pas de base de donnees, pas d’outil complexe.

Avec ca, tu peux laisser tourner des workers en production sans stress. Le reste s’ajoute au fil des retours d’experience : alertes, tableaux de bord, regles plus fines. Mais les quatre piliers ci-dessus suffisent a eviter les catastrophes du premier mois.

La gouvernance, c’est un dialogue entre toi et tes workers. Tu poses des regles, tu observes ce qui se passe, tu ajustes. C’est vivant, pas un reglement grave dans le marbre. Et plus tu le fais tot, moins tu passes ton temps a eteindre des incendies.

Si tu veux aller plus loin sur le role de l’humain dans une equipe d’agents, j’ai ecrit comment organiser la collaboration entre humain et agents IA. La gouvernance n’est qu’une partie du sujet, mais c’est celle qui conditionne tout le reste.