1. Introduction#
La fiabilité d’un système agentique repose sur sa capacité à exécuter des tâches correctement, tout en maîtrisant les risques, les coûts et les conséquences de ses actions.
Contrairement à un LLM conversationnel, un agent peut agir directement sur son environnement : modifier des fichiers, exécuter du code ou interagir avec des services externes.
Trois dimensions sont donc essentielles :
- Sécurité (Security) : limiter les actions non autorisées ou dangereuses.
- Supervision (Human-in-the-Loop) : conserver un contrôle humain sur les décisions sensibles.
- Évaluation (Evaluation) : mesurer objectivement les performances et la fiabilité.
Un agent qui termine une tâche n’est pas nécessairement un agent qui l’a correctement réalisée.
2. Sécurité et permissions#
La sécurité d’un agent repose principalement sur le contrôle des ressources et des actions auxquelles il peut accéder.
Permissions et principe du moindre privilège#
Le Least Privilege Principle consiste à n’accorder que les autorisations nécessaires à la réalisation d’une tâche.
| Permission | Capacité | Exemple |
|---|---|---|
| Read-only | Consultation sans modification | Audit de code |
| Workspace-write | Modification limitée au projet | Développement Python |
| Network access | Communication avec des services externes | Appels API |
| Full access | Accès étendu aux ressources | Administration contrôlée |
Ces permissions ne constituent pas des niveaux universels. Elles dépendent du harness et de son environnement.
Sandbox#
Une sandbox est un environnement isolé destiné à limiter les conséquences des opérations exécutées.
Elle peut restreindre :
- les accès aux fichiers ;
- les connexions réseau ;
- les commandes système ;
- les ressources matérielles ;
- l’accès aux secrets.
Les permissions doivent être appliquées techniquement, et non simplement décrites dans un prompt.
3. Guardrails et Prompt Injection#
Les guardrails sont des mécanismes de contrôle destinés à vérifier ou bloquer certaines entrées, sorties ou actions.
| Type | Objectif | Exemple |
|---|---|---|
| Input Guardrail | Vérifier une demande entrante | Refuser une requête hors périmètre |
| Tool Guardrail | Contrôler l’utilisation d’un outil | Bloquer une requête SQL destructive |
| Output Guardrail | Vérifier un résultat produit | Valider un schéma JSON |
| Execution Guardrail | Encadrer l’exécution | Limiter les itérations et les coûts |
Prompt Injection#
Une prompt injection consiste à introduire des instructions non autorisées dans un contenu consulté par l’agent.
Exemples :
- Une page web demande à l’agent d’ignorer ses instructions.
- Un fichier source contient une commande malveillante.
- Une réponse API tente de provoquer un appel d’outil non prévu.
Mesures de protection#
- Traiter les contenus externes comme des données non fiables.
- Respecter la hiérarchie des instructions.
- Valider les arguments des outils.
- Restreindre les permissions.
- Exiger une approbation pour les actions sensibles.
- Éviter d’exposer les secrets au modèle.
Les guardrails réduisent les risques, mais ne garantissent pas l’absence d’erreurs ou d’attaques.
4. Human-in-the-Loop (HITL)#
Le Human-in-the-Loop consiste à intégrer une intervention humaine dans le fonctionnement d’un agent.
L’objectif est de contrôler certaines décisions sans imposer une validation systématique de toutes les opérations.
Principaux mécanismes#
| Mécanisme | Fonctionnement |
|---|---|
| Approval | Validation avant une action |
| Review | Vérification d’un résultat |
| Interruption | Suspension de l’exécution |
| Escalation | Transmission d’un problème à l’utilisateur |
| Override | Correction ou remplacement d’une décision |
Exemple : agent de développement#
| Action | Supervision recommandée |
|---|---|
| Lire du code | Automatique |
| Exécuter des tests | Automatique dans un environnement isolé |
| Modifier des fichiers du projet | Automatique ou supervisée |
| Ajouter une dépendance | Selon les règles du projet |
| Supprimer des données | Approbation explicite |
| Déployer en production | Validation humaine |
Ces choix doivent être adaptés aux risques et au contexte.
Reprise après interruption#
Un harness prenant en charge le HITL peut :
- Suspendre une action sensible.
- Enregistrer l’état de l’exécution.
- Demander une approbation.
- Reprendre ou interrompre le traitement.
La reprise nécessite un mécanisme de persistance adapté.
Une supervision efficace cible les actions à risque plutôt que toutes les actions de l’agent.
5. Tests et évaluation des agents#
L’évaluation (Evals) consiste à mesurer les performances d’un agent sur des tâches représentatives.
Contrairement à un test logiciel classique, une évaluation agentique peut porter sur le résultat final, mais aussi sur la séquence d’actions réalisée.
Niveaux d’évaluation#
| Niveau | Question | Exemple |
|---|---|---|
| Unit Tests | Les composants fonctionnent-ils ? | Test d’une fonction Python |
| Integration Tests | Les outils interagissent-ils correctement ? | Appel API puis insertion |
| Task Evaluation | L’objectif est-il atteint ? | Bug réellement corrigé |
| Trajectory Evaluation | Les actions sont-elles appropriées ? | Absence de modification hors périmètre |
| Regression Evaluation | Les changements dégradent-ils les résultats ? | Comparaison avant/après |
Golden Dataset#
Un Golden Dataset est un ensemble de cas de référence utilisé pour évaluer systématiquement un agent.
Chaque cas peut contenir :
- une demande initiale ;
- un environnement de test ;
- un résultat attendu ;
- des contraintes ;
- des critères de réussite.
Méthodes d’évaluation#
| Méthode | Description |
|---|---|
| Deterministic Checks | Tests exacts, schémas, assertions |
| Reference Comparison | Comparaison avec des résultats attendus |
| LLM-as-a-Judge | Évaluation réalisée par un autre appel LLM |
| Human Evaluation | Évaluation par un expert |
| End-to-End Tests | Vérification complète d’une tâche |
Les tests déterministes doivent être privilégiés lorsque le résultat est objectivement vérifiable.
Le LLM-as-a-Judge est utile pour des critères qualitatifs, mais reste exposé à des biais et doit être calibré sur des évaluations de référence.
6. Observabilité : Logs, Traces et Metrics#
L’observabilité permet de comprendre le comportement réel d’un agent pendant son exécution.
Trois notions doivent être distinguées.
| Concept | Fonction | Exemple |
|---|---|---|
| Logs | Enregistrer les événements | Erreur d’API |
| Traces | Reconstituer une exécution complète | Appels LLM et outils |
| Metrics | Mesurer les performances | Coût, latence, taux de réussite |
Tracing#
Une trace représente le déroulement d’une exécution agentique.
Elle peut contenir plusieurs spans, correspondant notamment à :
- un appel au modèle ;
- un appel d’outil ;
- une délégation à un autre agent ;
- une vérification ;
- une erreur ou une interruption.
Le tracing permet d’identifier si un échec provient du modèle, d’un outil, du contexte ou de l’orchestration.
Attention : les traces peuvent contenir des données sensibles. Leur collecte, leur conservation et leur accès doivent être contrôlés.
7. Métriques et coûts#
Un agent doit être évalué selon plusieurs dimensions.
| Indicateur | Description |
|---|---|
| Success Rate | Proportion de tâches correctement réalisées |
| Error Rate | Fréquence des erreurs |
| Tool Calls | Nombre d’appels aux outils |
| Iterations | Nombre d’itérations de la boucle |
| Token Usage | Consommation de tokens |
| Latency | Durée d’exécution |
| Cost per Task | Coût moyen par tâche |
| Human Intervention Rate | Fréquence des interventions humaines |
Coût d’un agent#
Le coût global peut être représenté par :
[ C_{\text{total}} = C_{\text{LLM}} + C_{\text{tools}} + C_{\text{infrastructure}} + C_{\text{supervision}} ]
Il peut inclure :
- les tokens d’entrée et de sortie ;
- les appels aux services externes ;
- le temps de calcul ;
- les ressources d’infrastructure ;
- le temps consacré aux validations humaines.
Les coûts dépendent du modèle, du nombre d’itérations et des outils utilisés.
Optimisation#
- Limiter les itérations inutiles.
- Réduire le contexte non pertinent.
- Utiliser des modèles adaptés à la difficulté.
- Mettre en cache les résultats réutilisables lorsque cela est approprié.
- Éviter les délégations superflues.
- Mesurer le coût par tâche réussie.
Un agent moins coûteux par appel n’est pas nécessairement moins coûteux par tâche réussie.
8. Limites des systèmes agentiques#
Les systèmes agentiques présentent plusieurs limites structurelles.
| Limite | Conséquence |
|---|---|
| Non-déterminisme | Exécutions potentiellement différentes |
| Erreurs de raisonnement | Décisions incorrectes |
| Propagation des erreurs | Accumulation d’erreurs entre étapes |
| Context Loss | Informations oubliées ou mal exploitées |
| Tool Failures | Échecs d’exécution externes |
| Evaluation Bias | Évaluation incorrecte des résultats |
| Autonomy Risks | Actions non souhaitées |
| Coûts variables | Consommation difficile à prévoir |
Bonnes pratiques#
- Commencer avec une autonomie limitée.
- Définir des critères de réussite vérifiables.
- Restreindre les outils et permissions.
- Tester sur des scénarios représentatifs.
- Journaliser les opérations importantes.
- Prévoir des conditions d’arrêt et de récupération.
- Comparer les performances avec une solution non agentique.
- Augmenter progressivement l’autonomie lorsque les résultats le justifient.
La complexité d’un système agentique doit rester proportionnée aux bénéfices obtenus.
9. Synthèse#
La fiabilité d’un agent repose sur la combinaison de mécanismes de sécurité, de supervision et d’évaluation.
Les notions essentielles sont :
- Least Privilege : limiter les autorisations au strict nécessaire.
- Sandbox : isoler techniquement l’environnement.
- Guardrails : vérifier ou bloquer certaines actions et résultats.
- Human-in-the-Loop : intégrer des validations humaines.
- Evals : mesurer objectivement les performances.
- Golden Dataset : disposer de cas de test représentatifs.
- Tracing : reconstituer les opérations réalisées.
- Cost Monitoring : mesurer la consommation et les coûts.
Un système agentique fiable ne se caractérise pas uniquement par son autonomie, mais par sa capacité à produire des résultats vérifiables dans un environnement contrôlé.
