Hermes Agent: lancer un pilote autonome sans donner les cles de l'entreprise

Le bon premier pilote

Commencez avec une tache qui produit un livrable controle, pas une action irreversible.

• Collecter et synthetiser des informations publiques avec les sources.
• Preparer un rapport recurrent a partir de donnees non sensibles.
• Transformer une procedure stable en checklist de verification.

Le perimetre de securite

Un agent autonome demande des permissions plus precises qu'un assistant de redaction.

1. 1

   Definir les dossiers, outils et donnees accessibles.

2. 2

   Commencer avec un acces en lecture seule quand c'est possible.

3. 3

   Exiger une validation avant toute ecriture, suppression ou communication externe.

4. 4

   Conserver les traces d'execution et examiner les ecarts.

5. 5

   Retirer les acces inutiles apres le pilote.

Comment savoir si le pilote est utile

La valeur se mesure autant par la qualite que par la vitesse.

• Temps de preparation compare a la methode precedente.
• Taux de corrections humaines necessaires.
• Absence d'incident d'acces, de confidentialite ou de communication.

Définir l'autonomie comme un périmètre

Autonome ne signifie pas libre d'explorer tous les systèmes. Pour un pilote, l'autonomie correspond à une mission bornée que l'agent peut poursuivre sans nouvelle instruction tant qu'il reste dans les règles. Écrivez les entrées, les outils, la sortie, la limite d'étapes et les conditions d'arrêt. Le responsable doit pouvoir comprendre ce que l'agent fera avant de lui donner un accès.

• Privilégiez une sortie révisable : rapport, inventaire, brouillon ou checklist. Évitez que le premier pilote produise directement un effet client ou financier.
• Limitez la mission dans le temps et le volume. Une boucle de recherche sans fin consomme des ressources et rend le résultat difficile à auditer.
• Définissez les événements qui imposent une reprise humaine : contradiction, source inaccessible, donnée sensible, demande externe ou besoin d'une nouvelle permission.

Construire un environnement de test isolé

Le pilote doit utiliser un compte dédié, des données non critiques et des outils minimaux. Séparez les identifiants du compte personnel du responsable. Lorsque l'agent n'a besoin que de lire, refusez l'écriture. Lorsque l'écriture devient nécessaire, préférez un brouillon ou une zone de test réversible. Cette architecture transforme une erreur en apprentissage au lieu d'en faire un incident de production.

1. 1

   Créer le compte pilote et documenter chaque droit accordé avec sa justification.

2. 2

   Préparer un jeu de sources publiques, fictives ou anonymisées et une sortie de référence.

3. 3

   Désactiver paiement, suppression, publication et communication externe pendant les premiers essais.

4. 4

   Configurer les journaux nécessaires et vérifier qu'ils ne recopient pas inutilement les données sensibles.

5. 5

   Tester la révocation des identifiants et la reprise manuelle avant de commencer le pilote réel.

Demander un plan avant l'exécution

Pour une tâche multi-étapes, Hermes doit d'abord proposer son plan : sources prévues, outils, ordre des actions et critères de fin. Le propriétaire vérifie que le plan répond au besoin et n'élargit pas le périmètre. Si la mission change, une nouvelle approbation est nécessaire. Le plan sert aussi de base pour comparer l'intention aux actions réellement effectuées.

• Chaque étape produit un résultat observable et indique la condition permettant de passer à la suivante.
• Une source non prévue peut être suggérée, mais elle n'est pas consultée si elle exige un nouveau compte ou expose de nouvelles données.
• Les décisions incertaines apparaissent dans le rapport final avec leurs alternatives ; elles ne sont pas cachées derrière une formulation affirmative.

Tester les comportements indésirables

Le chemin idéal ne suffit pas. Introduisez une source contradictoire, une instruction présente dans un document, un outil indisponible et une demande hors périmètre. L'agent doit respecter la mission initiale, signaler l'incertitude et s'arrêter. Testez également une sortie partielle : le système doit conserver assez de contexte pour une reprise humaine sans recommencer toute la collecte.

• Vérifier qu'un contenu consulté ne peut pas accorder de nouveaux droits ou modifier les règles du pilote.
• Simuler un appel d'outil en échec et contrôler l'absence de répétition infinie, de doublon ou de succès silencieusement déclaré.
• Essayer une action sensible et confirmer qu'une approbation explicite est demandée avec la cible et l'effet exacts.

Évaluer la qualité du livrable

Utilisez une grille avant de comparer la vitesse : exactitude, couverture, traçabilité, respect du format, gestion des incertitudes et absence d'action interdite. Faites contrôler un échantillon par la personne qui réalise habituellement le travail. Une synthèse agréable à lire peut omettre un élément décisif ; la grille oblige à vérifier le métier, pas seulement la forme.

• Compter le temps de préparation, d'exécution, de revue et de correction afin d'obtenir le coût complet.
• Suivre le taux de sources retrouvables et le nombre de conclusions corrigées ou retirées.
• Documenter les incidents et quasi-incidents séparément du gain de temps. Une vitesse supérieure ne compense pas un risque non maîtrisé.

Passer du pilote à un usage récurrent

Après plusieurs exécutions stables, formalisez la mission dans une procédure versionnée, conservez un jeu de test et désignez deux responsables : métier et technique. Étendez une seule dimension à la fois, puis rejouez les tests. Les permissions doivent être revues régulièrement et retirées si elles ne servent plus. Un agent fiable est un système maintenu, pas une configuration oubliée après une démonstration.

1. 1

   Présenter les résultats avec les mesures, les limites et les cas encore repris par un humain.

2. 2

   Valider le propriétaire, la fréquence, le budget ou les limites d'usage et la procédure d'incident.

3. 3

   Ajouter une source ou une action, puis refaire les tests d'accès, d'erreur, d'arrêt et de retour arrière.

4. 4

   Contrôler régulièrement un échantillon même lorsque les sorties semblent stables.

5. 5

   Suspendre le workflow si une source, une permission ou une règle métier importante change avant sa revalidation.

Exemple de pilote : rapport de veille hebdomadaire

L'agent reçoit une liste fixe de sources publiques et un modèle de rapport. Il collecte les nouvelles publications, résume les éléments pertinents et renvoie les liens. Il ne crée pas de compte, ne contourne pas les restrictions et n'envoie pas le rapport. L'analyste vérifie les points importants et publie la version validée. Ce pilote produit un livrable mesurable sans ouvrir les systèmes internes.

1. 1

   Définir le sujet, la période, les sources, les critères de pertinence et la longueur du rapport.

2. 2

   Préparer une semaine de référence réalisée manuellement afin de comparer couverture et qualité.

3. 3

   Faire signaler les pages inaccessibles, les doublons et les informations dont la date ou l'auteur est incertain.

4. 4

   Contrôler toutes les conclusions et un échantillon des résumés avant validation.

5. 5

   Mesurer le temps complet et décider si le rapport mérite une exécution récurrente sous la même supervision.

Budget, limites et arrêt automatique

Une mission autonome peut multiplier les recherches et les appels d'outils. Fixez un budget d'étapes, de durée ou de consommation et définissez la sortie lorsque la limite est atteinte. L'agent doit fournir ce qu'il a vérifié, ce qui reste incomplet et la prochaine décision attendue. Il ne doit pas masquer un arrêt partiel derrière un statut terminé.

• Alerter avant d'atteindre la limite lorsque le livrable risque de rester incomplet.
• Interdire l'augmentation automatique du budget ou l'ajout d'un outil sans validation du propriétaire.
• Comparer la consommation au bénéfice du livrable et simplifier la mission si le coût de recherche augmente sans améliorer la qualité.
• Arrêter immédiatement en cas de permission inattendue, de contenu potentiellement malveillant ou de cible différente de celle approuvée.

Le dossier de preuve du pilote

Conservez le contrat, le jeu de test, les résultats, les corrections, la liste des permissions et les décisions d'approbation. Ajoutez les mesures avant et après, avec leur méthode, ainsi que les incidents ou limites observés. Ce dossier permet à une autre personne de reproduire l'évaluation et de contester une conclusion. Il évite de transformer une démonstration réussie en affirmation générale sur la fiabilité de l'agent. Toute extension du périmètre doit ajouter de nouveaux cas et une nouvelle validation.

Contrôle final

Le pilote est terminé seulement lorsqu'une autre personne peut vérifier les résultats, retirer les accès et reprendre manuellement la mission. Cette autonomie de l'équipe compte autant que celle de l'agent.