Pourquoi la validation est une étape non négociable
Un agent Hermes Agent peut sembler fonctionner correctement lors des premiers tests informels et produire des comportements inattendus dans des situations légèrement différentes. La validation structurée a pour objectif de couvrir suffisamment de cas pour que vous puissiez affirmer, avec une base factuelle, que l'agent se comporte de façon prévisible dans son périmètre d'usage.
La validation n'est pas une garantie absolue : elle réduit l'incertitude sans l'éliminer. Plus le périmètre d'usage est large et les actions de l'agent sont à fort impact, plus la validation doit être exhaustive. Un agent qui génère des rapports en lecture seule nécessite une validation moins intensive qu'un agent qui modifie des données de production.
- La validation établit la base factuelle de la confiance accordée
- Elle réduit l'incertitude sans l'éliminer
- L'intensité de la validation doit être proportionnée au niveau de risque
Étape 1 : vérification de la configuration avec hermes doctor
La première étape de la validation est toujours `hermes doctor`. Cette commande vérifie la cohérence de la configuration : fichiers présents, paramètres valides, outils accessibles, gateway fonctionnel. Un agent dont la configuration présente des avertissements non résolus ne doit pas passer en production, même si les tests fonctionnels semblent concluants.
Les avertissements de `hermes doctor` signalent souvent des configurations qui fonctionnent dans les cas nominaux mais échouent dans des conditions particulières : un outil dont les credentials vont expirer, un timeout trop court pour les opérations longues, une configuration de mémoire qui peut provoquer des troncatures. Résoudre ces avertissements avant les tests fonctionnels évite de valider un agent sur une configuration fragile.
- `hermes doctor` est la première étape de toute validation
- Résoudre tous les avertissements avant les tests fonctionnels
- Un avertissement non résolu est un risque latent en production
Étape 2 : tests des outils individuellement
Avant de tester l'agent complet, testez chaque outil individuellement avec `hermes mcp test`. Vérifiez que chaque outil répond correctement aux appels nominaux, que les erreurs sont correctement remontées et que les permissions sont bien appliquées. Un outil qui fonctionne mal en isolation va produire des comportements difficiles à diagnostiquer dans la boucle agentique.
Pour les outils d'écriture, testez explicitement que les permissions de lecture seule sont bien refusées si elles ne sont pas configurées, et que les permissions d'écriture sont bien limitées aux périmètres définis. Ces tests de permissions sont souvent omis mais sont critiques pour la sécurité de l'agent.
- `hermes mcp test` pour chaque outil avant le test de l'agent complet
- Tester les cas d'erreur, pas seulement le chemin nominal
- Vérifier explicitement que les permissions sont bien appliquées
Étape 3 : tests fonctionnels sur les cas nominaux
Les tests fonctionnels nominaux vérifient que l'agent accomplit correctement les tâches pour lesquelles il a été conçu, dans des conditions normales. Pour chaque skill ou cas d'usage principal, préparez un jeu de données de test représentatif et vérifiez que le résultat correspond à l'attendu. Documentez les résultats de ces tests.
Un test fonctionnel nominal ne suffit pas à valider un agent : il confirme que le cas le plus simple fonctionne, mais ne dit rien sur le comportement dans les cas limites. Les tests nominaux sont nécessaires mais pas suffisants ; ils doivent être complétés par des tests de cas limites et des tests d'erreur.
- Préparer des jeux de données de test représentatifs
- Documenter les résultats de chaque test fonctionnel
- Les tests nominaux sont nécessaires mais pas suffisants
Étape 4 : tests des cas limites et des cas d'erreur
Les cas limites sont les situations qui se situent aux frontières du périmètre d'usage : données manquantes, formats inattendus, ressources temporairement indisponibles, valeurs extrêmes. Tester ces cas permet de vérifier que l'agent échoue de façon contrôlée — en signalant l'erreur clairement — plutôt que de produire un résultat incorrect sans avertissement.
Les cas d'erreur incluent les situations où les outils retournent des erreurs, où le modèle produit une réponse hors format attendu, ou où les conditions de validation ne sont pas satisfaites. Pour chaque cas d'erreur identifié, vérifiez que l'agent s'arrête correctement, que l'erreur est correctement signalée et que l'état du système n'est pas laissé dans un état incohérent.
- Tester les données manquantes, formats inattendus, ressources indisponibles
- Vérifier que les erreurs sont signalées clairement, pas silencieuses
- Vérifier que l'état du système reste cohérent après une erreur
Étape 5 : validation du comportement en conditions réelles supervisées
Avant de laisser l'agent fonctionner de façon autonome, une période de supervision en conditions réelles est recommandée : l'agent exécute ses tâches sur de vraies données, mais un opérateur humain observe chaque exécution et peut intervenir. Cette phase permet de détecter les comportements inattendus qui n'apparaissent pas dans les tests sur données de test.
La durée de cette phase de supervision dépend de la criticité des tâches et de la fréquence d'exécution. Pour un agent qui s'exécute plusieurs fois par jour sur des données importantes, quelques jours de supervision intensive sont justifiés. Pour un agent à faible fréquence et faible impact, une supervision plus légère peut suffire.
- Superviser les premières exécutions en conditions réelles
- La durée de supervision dépend de la criticité et de la fréquence
- Documenter les observations de la phase de supervision
Critères de passage en production autonome
Un agent est prêt pour un usage autonome lorsque : `hermes doctor` ne signale aucune erreur ni avertissement non résolu, tous les outils passent leurs tests individuels, les tests fonctionnels nominaux et de cas limites sont concluants, et la phase de supervision n'a révélé aucun comportement inattendu. Ces critères doivent être documentés et vérifiés explicitement, pas évalués intuitivement.
Même après le passage en production, une surveillance continue est recommandée : surveiller les logs d'exécution, planifier des tests de non-régression réguliers avec `hermes mcp test` et `hermes doctor`, et définir une procédure de réponse aux incidents. L'autonomie accordée à un agent n'est pas définitive : elle peut et doit être réduite si des comportements inattendus sont détectés.
- `hermes doctor` sans erreur ni avertissement non résolu
- Tous les tests fonctionnels et de cas limites concluants
- Phase de supervision sans comportement inattendu
- Surveillance continue et procédure de réponse aux incidents définie
Sources et méthode
Cette page est une synthèse éditoriale indépendante. Les capacités et commandes doivent être vérifiées dans les sources officielles avant une utilisation en production.