Erreur 1 : définir un périmètre trop large dès le départ
La première erreur des débutants est de vouloir créer un agent qui fait tout : gère les emails, met à jour les fichiers, appelle plusieurs APIs et prend des décisions complexes, le tout dès la première configuration. Cette ambition est compréhensible mais contre-productive : un agent au périmètre trop large est difficile à tester, difficile à déboguer et difficile à maintenir.
Un périmètre bien défini est un périmètre étroit. Commencer par un agent qui accomplit une seule tâche bien définie, la valider complètement, puis étendre progressivement. Chaque extension du périmètre doit être traitée comme une nouvelle configuration à valider, pas comme un ajout mineur. La progression lente et méthodique produit des agents plus fiables que les configurations ambitieuses.
- Commencer par une seule tâche bien définie
- Chaque extension du périmètre est une nouvelle configuration à valider
- La progression lente produit des agents plus fiables
Erreur 2 : accorder des permissions sans réflexion
Lors de la configuration des outils, il est tentant d'accorder des permissions larges pour éviter les erreurs de permission lors des tests. Cette approche est risquée : un agent avec des permissions d'écriture sur l'ensemble du système de fichiers peut modifier ou supprimer des fichiers importants si le modèle prend une mauvaise décision. Les permissions accordées lors des tests ont tendance à rester en production.
La règle du moindre privilège s'applique strictement : chaque outil ne doit avoir que les permissions strictement nécessaires à son fonctionnement. Si un outil a besoin de lire un répertoire spécifique, ne lui accordez pas l'accès à l'ensemble du système de fichiers. Cette discipline demande un effort de configuration supplémentaire mais réduit considérablement la surface de risque.
- Ne jamais accorder des permissions larges pour simplifier les tests
- Appliquer le principe du moindre privilège à chaque outil
- Les permissions de test ont tendance à rester en production
Erreur 3 : négliger la configuration de la mémoire
Beaucoup de débutants activent la mémoire persistante sans comprendre ce qu'elle stocke et comment elle influence les décisions futures. La mémoire persistante peut sembler inoffensive au début, mais elle accumule des informations qui peuvent devenir contradictoires ou obsolètes et influencer les décisions de l'agent de façon subtile et difficile à diagnostiquer.
Une approche plus sûre pour les débutants est de commencer sans mémoire persistante, en mode session uniquement. Cela simplifie le comportement de l'agent et facilite le diagnostic : chaque session repart de zéro, ce qui rend les comportements plus prévisibles. La mémoire persistante peut être activée progressivement une fois que le comportement de base est bien compris.
- Commencer sans mémoire persistante pour simplifier le diagnostic
- Comprendre ce qui est stocké avant d'activer la persistance
- La mémoire persistante peut introduire des biais difficiles à détecter
Erreur 4 : automatiser avant de valider
L'une des erreurs les plus coûteuses est de mettre en place une automatisation — un cron, un déclencheur automatique — avant d'avoir validé que l'agent se comporte correctement dans tous les cas pertinents. Un agent qui s'exécute automatiquement et qui a un comportement incorrect peut produire des effets indésirables à grande échelle avant que le problème soit détecté.
La règle est simple : aucune automatisation avant validation complète. Et même après validation, commencer par une automatisation supervisée — où les exécutions automatiques sont loguées et revues régulièrement — avant de passer à une automatisation totalement autonome. Cette progression est décrite plus en détail dans la page sur l'automatisation progressive.
- Aucune automatisation avant validation complète
- Commencer par une automatisation supervisée avec revue des logs
- Un agent automatisé non validé peut produire des effets à grande échelle
Erreur 5 : ignorer les messages de hermes doctor
Les débutants ont tendance à ignorer les avertissements de `hermes doctor` lorsque l'agent semble fonctionner malgré eux. Cette attitude est risquée : les avertissements signalent des configurations qui fonctionnent dans les cas nominaux mais échouent dans des conditions particulières. Ignorer un avertissement, c'est accepter un risque latent dont vous ne connaissez pas le moment de déclenchement.
Chaque avertissement de `hermes doctor` mérite d'être compris, même si vous décidez de ne pas le corriger immédiatement. Comprendre pourquoi l'avertissement est émis vous permet d'évaluer le risque réel et de décider en connaissance de cause. Ignorer sans comprendre est la pire des options.
- Ne jamais ignorer les avertissements de `hermes doctor`
- Comprendre chaque avertissement avant de décider de le corriger ou non
- Un avertissement ignoré est un risque latent accepté sans évaluation
Erreur 6 : confondre un test réussi et un agent validé
Un test réussi sur le cas nominal ne signifie pas que l'agent est validé. La validation couvre les cas nominaux, les cas limites, les cas d'erreur et une phase de supervision en conditions réelles. Un agent qui réussit un test sur des données de test idéales peut échouer sur des données réelles légèrement différentes.
Cette confusion est particulièrement dangereuse pour les agents qui exécutent des actions irréversibles : modifier des fichiers, envoyer des messages, déclencher des processus. Pour ces agents, la validation doit être particulièrement exhaustive, et la phase de supervision en conditions réelles doit être suffisamment longue pour couvrir la variété des situations réelles.
- Un test nominal réussi n'est pas une validation complète
- La validation couvre nominaux, cas limites, erreurs et supervision réelle
- Les agents à actions irréversibles exigent une validation plus exhaustive
Erreur 7 : ne pas documenter les choix de configuration
Les débutants configurent souvent leur agent par essais et erreurs, sans documenter pourquoi ils ont fait tel ou tel choix. Quelques semaines plus tard, ils ne savent plus pourquoi une permission est configurée d'une certaine façon, pourquoi un outil a été exclu, ou pourquoi une règle de validation est définie ainsi. Cette absence de documentation rend la maintenance très difficile.
Documenter les choix de configuration au fur et à mesure — même brièvement — est une habitude qui s'acquiert dès le début. Un commentaire dans le fichier de configuration, une note dans un document partagé, ou un message de commit explicite suffisent. Cette documentation est votre mémoire externe : elle vous permettra de comprendre votre propre configuration dans six mois.
- Documenter les choix de configuration au fur et à mesure
- Un commentaire bref vaut mieux qu'aucune documentation
- La documentation est votre mémoire externe pour la maintenance future
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.