Fiabilité des agents IA : pourquoi la réponse finale ne suffit pas

Une sortie correcte ne prouve pas un raisonnement correct, une exécution sûre ou un système digne de confiance.

Depuis des années, l'évaluation de l'IA est dominée par une question d'une simplicité trompeuse : La réponse était-elle correcte ? Pour un chatbot, cela peut parfois suffire. Pour un agent capable de rechercher dans des systèmes, de lire des données, d'appeler des outils, de modifier des états, d'exécuter des flux de travail, d'écrire des fichiers, d'interagir avec des API ou de prendre des décisions, ce n'est pas le cas.

Un agent peut produire la bonne réponse finale tout en faisant plusieurs choses de travers en cours de route. Il peut utiliser la mauvaise source, mal comprendre une instruction et compenser ensuite l'erreur, accéder à des informations inutiles, exécuter une action intermédiaire non autorisée, se remettre silencieusement d'une erreur qui aurait dû déclencher une escalade, ou laisser derrière lui des effets secondaires que personne n'a remarqués.

Cela crée l'un des problèmes centraux de l'IA agentique : un résultat correct ne prouve pas une trajectoire correcte.

L'illusion du résultat

Les logiciels traditionnels nous donnent un modèle intuitif de la correction. Une entrée entre dans un système déterministe ou principalement déterministe, la logique est exécutée, une sortie est produite, et des tests vérifient le comportement attendu. Les systèmes basés sur les LLM affaiblissent cette hypothèse. Les systèmes agentiques vont plus loin.

• interprétation du modèle
• contexte récupéré
• sélection d'outils
• observations intermédiaires
• état externe
• actions précédentes
• plans générés par le modèle
• limites de permission
• nouvelles tentatives et comportement de secours
• interaction humaine

Deux exécutions partant d'entrées presque identiques peuvent atteindre le même résultat par des chemins très différents. Si l'évaluation n'observe que la sortie finale, la majeure partie du système reste invisible.

Imaginez qu'un agent IA reçoive l'instruction : Mettre à jour l'adresse de facturation du client. L'adresse est finalement mise à jour correctement. Une évaluation conventionnelle pourrait classer la tâche comme réussie.

1. L'agent recherche plusieurs dossiers clients sans rapport.
2. Il récupère plus d'informations personnelles que nécessaire.
3. Il modifie d'abord le mauvais compte.
4. Il remarque l'erreur.
5. Il annule la modification.
6. Il met à jour le bon compte.
7. Il signale le succès.

État final : correct. Comportement du système : inacceptable. Un benchmark basé uniquement sur le résultat donne une réussite à cette exécution. Un système d'assurance en production ne devrait pas.

La trajectoire fait partie du produit

C'est pourquoi la trajectoire d'un agent IA doit devenir un objet d'ingénierie de première classe. Une trajectoire est la séquence d'états et d'actions pertinents entre la demande initiale et le résultat final.

Intention → Contexte → Décision → Outil → Action → Observation → Décision → Changement d'état → Résultat

Zachary J. Stevens développe cette idée dans La trajectoire est le système, soutenant que l'évaluation agentique doit aller au-delà de la réponse finale et examiner le chemin complet de l'action à travers un environnement changeant.

Un résultat correct n'excuse pas une trajectoire inacceptable.— Zachary J. Stevens, La trajectoire est le système

La distinction est extrêmement importante. La fiabilité n'est donc pas simplement une sortie correcte. Elle est plus proche de résultat acceptable + trajectoire acceptable + récupérabilité + preuves.

Une bonne réponse peut cacher un système défaillant

La plupart des évaluations basées sur des benchmarks récompensent fortement A et B et pénalisent C et D. Sur le plan opérationnel, cependant, B peut être plus dangereux que C. L'agent C peut reconnaître l'incertitude, arrêter l'exécution et demander une revue humaine. L'agent B peut produire avec confiance des résultats corrects tout en violant des hypothèses que personne ne surveille.

sortie réussie → confiance accrue → permissions élargies → plus d'automatisation → plus grande portée des dégâts

Nous avons besoin de preuves, pas de confiance

L'une des plus grandes erreurs dans l'adoption de l'IA est de considérer la confiance du modèle, la satisfaction de l'utilisateur ou le taux de réussite historique comme une preuve de fiabilité du système. Ils ne sont pas équivalents.

• Qu'est-ce que l'agent a reçu ?
• Quel contexte a-t-il récupéré ?
• Quels outils a-t-il appelés ?
• Pourquoi l'action a-t-elle été autorisée ?
• Quel état existait avant l'action ?
• Qu'est-ce qui a changé ?
• Quelles défaillances intermédiaires se sont produites ?
• Y a-t-il eu des tentatives ?
• L'approbation humaine était-elle requise ?
• L'exécution aurait-elle pu être arrêtée ?
• L'action peut-elle être annulée ?
• Quels modèles, invites et versions d'outils ont été impliqués ?

Sans ces réponses, il n'y a aucune assurance opérationnelle sérieuse. Il n'y a qu'une sortie. L'observabilité et les preuves doivent donc être conçues dans l'architecture de l'agent plutôt que d'être ajoutées après le déploiement.

La journalisation n'est pas la même chose que le contrôle

Les organisations répondent souvent : Tout est journalisé. Bien. Mais la journalisation seule ne contrôle rien. Un journal vous dit ce qui s'est passé. Un contrôle détermine si quelque chose peut se produire.

L'agent demande DELETE /customer/123 ↓
Action journalisée ↓
DELETE exécuté

Cela donne de l'observabilité. Comparez avec :

L'agent demande DELETE /customer/123 ↓
Évaluation de la politique ↓
Identité actuelle vérifiée ↓
Paramètres de l'action actuelle vérifiés ↓
Seuil de risque évalué ↓
Approbation humaine si nécessaire ↓
Action exécutée ↓
Résultat vérifié ↓
Preuves stockées

Maintenant, nous approchons d'un système de contrôle. La différence est architecturale, pas cosmétique.

La permission est nécessaire — mais ce n'est pas une assurance

Supposons qu'un agent ait la permission d'envoyer des e-mails. Le contrôle d'accès répond : Cet agent peut-il envoyer des e-mails ? Il ne répond pas : Cet e-mail particulier doit-il être envoyé à cette personne particulière avec cette pièce jointe particulière maintenant ?

CONTRÔLE DE CAPACITÉ
Qu'est-ce que l'agent est techniquement autorisé à faire ? + ASSURANCE D'ACTION
Cette action spécifique est-elle appropriée dans l'état actuel ?

Le RBAC, les portées OAuth, les permissions API et les identités d'agent définissent l'espace des actions possibles. Ils ne prouvent pas qu'une action dans cet espace est appropriée. Une architecture d'agent solide nécessite les deux couches.

Le premier faux pas compte

Lorsqu'un agent échoue, l'action incorrecte finale n'est souvent pas là où l'échec a commencé. Le véritable échec a peut-être eu lieu bien plus tôt.

Mauvaise récupération ↓
Mauvaise hypothèse ↓
Raisonnement plausible ↓
Appel d'outil valide ↓
Mauvaise action

Si nous n'examinons que l'action finale, nous corrigeons le symptôme. Si nous inspectons la trajectoire, nous pouvons identifier le premier faux pas. Cela transforme un échec non attribuable en un problème d'ingénierie concret.

Les tests d'agents doivent aller au-delà des tests de prompts

Les prompts comptent, mais le comportement d'un agent en production émerge d'un système entier.

MODÈLE
+
PROMPT SYSTÈME
+
CONTEXTE
+
MÉMOIRE
+
RÉCUPÉRATION
+
OUTILS
+
PERMISSIONS
+
WORKFLOW
+
ÉTAT EXTERNE
+
LOGIQUE DE CONTRÔLE

Modifier l'un de ces éléments peut changer la trajectoire. Par conséquent, versionner uniquement le prompt est insuffisant.

version_modèle
version_prompt
version_outils
version_politique
version_récupération
version_workflow
état_environnement
id_exécution

Les critères d'acceptation pour les agents doivent inclure le comportement

Les critères d'acceptation traditionnels ressemblent souvent à ceci : Étant donné X, le système produit Y. Pour les systèmes agentiques, cela est incomplet. Les critères d'acceptation devraient également définir des contraintes sur la trajectoire.

Résultat

L'adresse du client est mise à jour correctement.

Autorisation

L'agent modifie uniquement le client explicitement sélectionné.

Accès aux données

Aucun enregistrement client non lié n'est consulté.

Outils

Seules les opérations CRM approuvées sont utilisées.

Vérification

La nouvelle adresse est relue et comparée à la valeur demandée.

Échec

Une résolution d'identité ambiguë arrête l'exécution.

Autorité humaine

Un humain peut rejeter la modification avant l'exécution lorsque les seuils de risque exigent une approbation.

Preuve

L'exécution laisse une trace suffisante pour reconstituer la décision et la transition d'état.

Récupération

La valeur précédente reste récupérable.

L'humain dans la boucle ne suffit pas

Ajouter une case d'approbation humaine ne résout pas automatiquement le problème. Un humain ne peut contrôler un agent que s'il dispose de la visibilité, de l'autorité, du temps, du contexte et de la capacité de récupération.

• Visibilité : suffisamment d'informations pour comprendre ce qui se passe.
• Autorité : capacité réelle d'arrêter ou de modifier l'action.
• Temps : intervention avant que la conséquence ne se produise.
• Contexte : preuves suffisantes pour prendre la décision.
• Capacité de récupération : capacité d'inverser ou de réparer l'action.

Un utilisateur qui clique sur Approuver pour quelque chose qu'il ne peut pas inspecter de manière significative n'est pas une gouvernance solide. C'est du théâtre d'approbation.

Le rollback doit devenir une capacité native de l'IA

Le déploiement logiciel traditionnel nous a appris quelque chose de précieux : Ne déployez jamais ce que vous ne pouvez pas annuler. Nous devrions appliquer le même principe aux actions agentiques.

RÉVERSIBLE
Peut être automatiquement annulé. COMPENSABLE
Ne peut pas être annulé directement mais peut exécuter une action compensatoire. IRRÉVERSIBLE
Ne peut pas restaurer de manière fiable l'état précédent.

Plus l'irréversibilité est élevée, plus l'exigence de contrôle doit être forte.

Lire un document public → conséquence faible
Créer un brouillon → réversible
Modifier un enregistrement CRM → réversible mais conséquent
Envoyer un e-mail externe → pratiquement irréversible
Transférer de l'argent → conséquence élevée
Supprimer des données de production → potentiellement catastrophique

L'agent a besoin d'un plan de contrôle

INTENTION UTILISATEUR / SYSTÈME │ ▼ AGENT IA │ action proposée │ ▼ ┌───────────────────┐ │ PLAN DE CONTRÔLE │ ├───────────────────┤ │ Identité │ │ Autorisation │ │ Politique │ │ Risque │ │ État │ │ Preuve │ │ Autorité humaine │ │ Annulation │ └───────────────────┘ │ approuvé ? / \ NON OUI │ │ STOP ▼ OUTIL │ ▼ CHANGEMENT D'ÉTAT │ ▼ VÉRIFICATION

Le LLM devrait proposer. Le plan de contrôle devrait gouverner. Cette séparation est cruciale. Le modèle ne devrait pas être l'autorité ultime déterminant si sa propre action proposée à fort impact est sûre.

Des benchmarks à la confiance opérationnelle

Les benchmarks restent utiles. Ils nous renseignent sur les capacités, comparent les modèles, détectent les régressions et aident à estimer les performances attendues. Mais l'évaluation des capacités et la confiance opérationnelle répondent à des questions différentes.

Un benchmark demande : Le système peut-il faire cela ? L'assurance opérationnelle demande : Pouvons-nous permettre au système de faire cela ici, dans ces conditions, avec ces permissions et ces conséquences ?

La fiabilité devrait être mesurée comme une propriété système

1. Exactitude du résultat : Le système a-t-il produit le résultat attendu ?
2. Exactitude de la trajectoire : A-t-il suivi un chemin acceptable ?
3. Intégrité du contrôle : Les limites d'autorisation, de politique et d'intervention ont-elles été respectées ?
4. Récupérabilité : Les défaillances peuvent-elles être contenues, inversées ou réparées ?
5. Complétude des preuves : L'exécution peut-elle être reconstruite et auditée ?

Fiabilité opérationnelle
=
Résultat × Trajectoire × Contrôle × Récupérabilité × Preuves

La multiplication est intentionnelle. Si une dimension critique approche de zéro, un score élevé ailleurs ne devrait pas le cacher. Un résultat parfaitement correct avec une intégrité d'autorisation nulle n'est pas un système fiable à 80 %. C'est une exécution inacceptable qui a produit la bonne réponse par hasard.

Le succès est parfois l'échec le plus dangereux

Les échecs attirent l'attention. Le succès souvent non. Cela rend les trajectoires d'agents réussies mais non contrôlées particulièrement dangereuses. Un échec évident crée un incident. Un défaut de trajectoire caché crée de la confiance. Et la confiance élargit l'autonomie.

Les organisations ne devraient donc pas seulement enquêter sur Pourquoi l'agent a-t-il échoué ? Elles devraient périodiquement se demander : Pourquoi l'agent a-t-il réussi ? A-t-il réussi parce que l'architecture a de manière fiable contraint et vérifié l'exécution, ou parce que rien n'a mal tourné cette fois-ci ?

Conclusion

L'industrie évolue rapidement de l'IA qui répond vers l'IA qui agit. Cette transition change ce que signifie la fiabilité. Pour un système de réponse, évaluer la réponse peut souvent suffire. Pour un système d'action, nous devons évaluer le chemin.

Invite
↓
La réponse devient intention
↓
Trajectoire
↓
Actions
↓
Changements d'état
↓
Preuves
↓
Résultat

La réponse finale reste importante, mais elle n'est que la partie visible d'un système bien plus vaste. Une fois que l'IA est autorisée à affecter le monde réel, le chemin vers la réponse fait partie de la réponse.