Déployer Hermes Agent en entreprise : la recette avant production

La recette de déploiement de Hermes Agent est un protocole d’essais qui vérifie les actions autorisées, les refus, les traces et la capacité d’arrêt avant un accès réel. Elle doit produire des preuves techniques et une décision explicite de mise en service.

Ce protocole est proposé au 19 octobre 2026 pour Hermes Agent de Nous Research. La version officielle la plus récente vérifiée est v0.22.2, publiée le 15 octobre 2026. Les essais ci-dessous sont des recommandations à exécuter dans votre environnement, sans résultat de mission client revendiqué.

Il faut figer la version du logiciel, le modèle, les outils et la configuration afin que les preuves de recette correspondent à l’installation réellement autorisée.

Conserver un dossier de référence : tag et commit du code, origine du paquet ou de l’image, version du modèle, connecteurs et périmètre de données. Une documentation vivante décrit parfois des fonctions absentes d’un paquet installé. Associer chaque contrôle à sa version évite de valider une capacité supposée.

Les notes officielles v0.22.2 expliquent que v0.22.1 avait été construite depuis un mauvais commit. Elles signalent aussi une limite de suppression de sessions issues de cette passerelle. Cet exemple justifie une vérification du code livré et une revue des limitations connues avant toute migration.

Définir ensuite la tâche : entrée acceptée, résultat attendu, destinataire et actions interdites. Un cas proposé serait la préparation d’un compte rendu depuis des documents fictifs, enregistré dans un dossier de test. La méthode pour migrer un agent sans régression aide à conserver les mêmes attentes après une mise à jour.

Accorder à Hermes Agent une identité dédiée et des permissions minimales permet de vérifier les limites dans les systèmes qui exécutent réellement ses actions.

Séparer le compte de l’agent du compte personnel de l’administrateur. Prévoir des dossiers de travail limités, des connexions métier restreintes et des destinations réseau justifiées. Retirer les accès inutiles avant les essais. Le tableau décrit des résultats attendus, à obtenir avec les contrôles de votre infrastructure.

La documentation de sécurité au tag v0.22.2 décrit le mode manual pour les commandes détectées comme dangereuses. Elle indique aussi que certains contrôles de commandes sont sautés dans les backends conteneurisés. Le choix du backend change donc les protections effectives : tester les permissions, les montages et le réseau au lieu de supposer une validation humaine universelle.

La politique de sécurité distingue le confinement du terminal et celui du processus entier, nécessaire au périmètre de confiance qu’elle prévoit pour les contenus non maîtrisés. Elle recommande aussi des instances et listes d’utilisateurs séparées lorsque les habilitations doivent différer entre appelants. Ces frontières doivent figurer dans le dossier d’architecture.

Tester une injection indirecte consiste à placer une instruction hostile dans un contenu consulté par l’agent et à vérifier ses effets sur les actions.

Construire des documents de test qui ressemblent aux entrées prévues : pièce jointe, page récupérée ou résultat de connecteur. Y introduire une demande hors tâche, comme transmettre le document à un destinataire non autorisé. Utiliser uniquement des données fictives et une destination de test contrôlée. L’article sur les injections indirectes précise cette séparation entre contenu et instruction.

La documentation de sécurité précise que ses motifs de détection dans les fichiers de contexte sont heuristiques. La politique de sécurité du tag v0.22.2 distingue également ces mécanismes des frontières de confinement. Il faut donc éprouver aussi les permissions lorsque le contenu hostile est formulé autrement ou arrive par un autre outil.

Pour chaque essai, conserver le contenu présenté, l’action demandée, les appels observés et le résultat dans le système cible. Un refus rédigé suivi d’une transmission reste un échec. Ajouter un document légitime comparable pour vérifier que la protection permet encore le travail autorisé. Rejouer le cas après un changement de modèle ou de connecteur.

La recette doit vérifier ce qui reste après la tâche et ce qui demeure accessible après le retrait d’un connecteur ou d’une autorisation.

Utiliser des marqueurs fictifs distincts pour les dossiers et utilisateurs du pilote. Vérifier où ils réapparaissent dans une nouvelle tâche, puis appliquer la procédure de retrait retenue. Le résultat doit distinguer les données actives, les historiques et les sauvegardes. Une réponse qui affirme avoir oublié ne démontre pas l’effacement des copies conservées.

Retirer ensuite un accès de test dans le système source et rejouer une demande qui en dépend. L’agent doit rencontrer le refus attendu ; le compte technique ne doit pas conserver un accès parallèle inutile. Cette épreuve est particulièrement utile avec plusieurs connecteurs ou plusieurs installations. La recette de sécurité MCP fournit un cadre pour préciser ce périmètre.

La documentation de la passerelle décrit les listes d’utilisateurs autorisés et l’appairage. Tester concrètement un utilisateur admis, un utilisateur exclu et un accès révoqué. Un identifiant accepté par la messagerie n’établit pas, à lui seul, le droit de consulter toutes les ressources métier.

Les journaux doivent permettre de relier une demande, une décision d’autorisation et un effet réel, sans devenir une copie incontrôlée des informations traitées.

La référence CLI officielle documente la commande hermes logs, le filtrage par session et la consultation des journaux de passerelle. Ces possibilités facilitent l’enquête. Leur présence ne prouve pas que chaque opération métier est tracée avec les informations nécessaires à votre contrôle.

Définir le dossier de preuve attendu : identité de l’appelant, référence de session, version de configuration, outil appelé, décision, heure et état final. Relier ces éléments au journal du système cible lorsque c’est possible. Les ajouter par une instrumentation complémentaire si le périmètre natif ne suffit pas. La méthode d’auditabilité d’une réponse IA aide à distinguer affirmation et exécution.

Éprouver les traces avec des marqueurs fictifs : retrouve-t-on le refus, la reprise et le résultat ? Vérifier aussi les lecteurs autorisés, la conservation et l’absence de données sensibles inutiles. Produire volontairement une erreur d’outil dans le pilote permet d’examiner ce que les messages de diagnostic révèlent.

Un arrêt vérifié doit interrompre le travail visé, empêcher de nouvelles actions non souhaitées et permettre à un opérateur de contrôler les effets déjà engagés.

Prévoir une commande accessible à l’administrateur depuis une session distincte de l’agent. La documentation de passerelle décrit hermes gateway stop et hermes gateway status. Le protocole doit identifier le profil et le service concernés. Un message d’arrêt dans une conversation ne démontre pas que les autres tâches, passerelles ou programmations sont arrêtées.

Lancer une tâche réversible assez longue pour observer l’interruption, demander l’arrêt, puis examiner les processus et le système cible. Vérifier qu’aucune nouvelle opération n’est initiée par l’installation arrêtée. Examiner séparément les requêtes déjà acceptées par un service distant : leur effet doit être constaté, puis corrigé si nécessaire.

Prévoir une mesure indépendante lorsque l’arrêt applicatif ne suffit pas : suspension de l’identité technique ou coupure des connexions concernées par l’administrateur. Le risque des agents sur la durée justifie d’éprouver aussi les tâches différées et les reprises automatiques. Consigner le résultat mesuré, sans annoncer de délai garanti avant l’essai.

La reprise doit préserver les données utiles, éviter les actions en double et permettre un retour à une installation connue après une mise à jour.

Préparer une tâche fictive avec une référence stable, puis interrompre son exécution avant et après l’appel au système cible. Au redémarrage, comparer les résultats attendus et obtenus. Lorsqu’une opération peut être répétée, prévoir une protection dans le service cible ou une validation humaine. Une réponse identique ne démontre pas l’absence de doublon.

Le guide Docker officiel avertit de ne pas faire écrire simultanément deux passerelles conteneurisées dans le même répertoire de données. Une ancienne installation conservée pour retour arrière doit donc rester arrêtée pendant que la nouvelle utilise cet état. Tester la restauration sur une copie isolée avant toute décision de bascule.

Le contrôle de reprise des agents et robots aide à formuler les preuves attendues. Conserver les versions, l’état de référence et les écarts observés. Si une migration de données empêche le retour, inscrire cette limite dans la décision au lieu de promettre un simple redémarrage de la version précédente.

Le passage en production peut être autorisé lorsque les résultats métier et les contrôles bloquants sont démontrés pour un périmètre explicite, avec un responsable identifié.

Organiser la décision autour des preuves produites :

1. Vérifier le livrable attendu sur les entrées représentatives, avec les corrections humaines consignées.
2. Exiger le refus des accès et actions interdits dans les systèmes concernés.
3. Relier les essais d’injection, d’erreur et de révocation aux traces correspondantes.
4. Constater l’arrêt, la reprise et la restauration sur l’installation retenue.
5. Documenter les limitations restantes, le responsable et les conditions de suspension.

Un accès interdit réussi ou une action sensible impossible à retracer doit bloquer le périmètre concerné. Les difficultés des projets d’agents en entreprise se traitent en réduisant ce périmètre et en corrigeant les écarts. La grille de recette d’un agent IA et un audit IA du système permettent de formaliser les critères et le plan de correction.

Analyse et méthode proposées par Anand Candassamy au 19 octobre 2026.