Évaluer un agent IA : mesurer plutôt que croire
Votre agent IA affirme que son travail est terminé ? Mettez en place des tests indépendants, des preuves vérifiables et un contrôle avant livraison.
Votre agent IA dit que c'est terminé : comment le vérifier vraiment
Un agent IA vient de modifier votre code, de préparer une migration ou de rédiger un document. Vous lui demandez si c'est terminé. Il répond oui. Ce n'est pas une preuve : c'est une réponse produite par le même système qui a aussi fait le travail.
Le problème arrive quand un agent se retrouve à la fois en train d'agir et en train d'évaluer. Dans ce cas, il peut confirmer son intention plutôt que vérifier le résultat. Des tests manquants passent inaperçus, des revues tournent en rond, puis les défauts reviennent plus tard - souvent chez la personne qui s'est fiée au « c'est bon ».
La bonne réaction n'est pas de demander au modèle d'être « plus rigoureux ». Il faut sortir l'évaluation de son contexte : faire exécuter de vrais contrôles par un outil indépendant, conserver leurs résultats, puis seulement ensuite demander une revue séparée. Cette approche ne promet pas « zéro défaut ». Elle transforme surtout une affirmation difficile à auditer en éléments vérifiables, avec des limites assumées.
Voici une façon de structurer la boucle, attribuer un score sans lui faire dire plus qu'il ne peut, et éviter les faux « verts » qui donnent confiance à tort.
Pourquoi un agent ne devrait pas valider son propre travail
Quand un agent produit un résultat, il travaille avec un contexte : la demande initiale, ses hypothèses, les fichiers qu'il a lus et les choix qu'il a faits. Puis, si on lui demande de « contrôler » le résultat dans le même contexte, il ne repart pas de zéro. Il a déjà une idée de ce qu'il voulait faire - et il peut confondre intention et réussite.
Ce n'est pas forcément une question de mauvaise foi, ni même de modèle « mal conçu ». C'est surtout un problème de méthode : une vérification qui dépend du même contexte que la production est moins indépendante qu'elle n'en a l'air. Même si vous demandez « sois critique », ça ne remplace pas des preuves concrètes : preuve que la commande a vraiment tourné, que le bon environnement était en place, et que les exigences ont réellement été respectées.
Le risque opérationnel : l'impression que « ça converge »
Dans un projet réel, le signal d'alerte n'est pas toujours un échec spectaculaire. Le plus fréquent, c'est une suite de validations vagues : « ça semble correct », « les changements sont terminés », « les tests devraient passer ». L'équipe reprend alors le travail en supposant que le contrôle a eu lieu. Plus tard, un défaut apparaît lors d'une intégration, d'une livraison ou d'une décision métier.
Le coût vient à la fois du défaut et de la confiance mal placée. Il faut ensuite reconstituer ce qui a été testé, dans quel environnement, avec quelles données, et selon quel critère. Si rien n'a été conservé, la revue devient difficile à refaire, et le diagnostic ressemble à une enquête.
Séparer les rôles plutôt que multiplier les consignes
Une boucle solide distingue clairement quatre rôles. Dans une petite équipe, plusieurs rôles peuvent être portés par les mêmes outils ou les mêmes personnes, mais ils doivent rester séparés par fonction et par contexte.
- L'orchestrateur planifie les contrôles, lance les cycles, traite les problèmes d'infrastructure et prépare le compte rendu.
- Le constructeur - humain ou agent - produit le livrable et corrige les écarts identifiés.
- Le critique est un script déterministe : il exécute les commandes prévues, conserve leurs sorties et calcule le résultat. Il ne demande pas à un modèle « est-ce bon ? ».
- Le réviseur examine le même livrable depuis un contexte neuf, sans reprendre les justifications du constructeur. Il peut exiger une correction ou bloquer la livraison.
La règle simple : constructeur, critique et réviseur ne doivent pas être confondus dans un seul contexte. Si un même agent écrit le code, déclare les tests réussis sans les exécuter et s'auto-approuve, vous aurez l'impression d'un contrôle - mais pas l'indépendance.
Cette séparation ne rend pas l'évaluation parfaite. Elle coupe surtout un biais précis : l'auto-validation. Le reste dépend toujours de la qualité des critères, des tests choisis et des risques que l'équipe accepte de couvrir.
Mettre en place une boucle de contrôle indépendante
L'objectif n'est pas d'empiler une couche « IA » à chaque étape. C'est de figer les critères avant d'agir, puis de vérifier avec des commandes reproductibles. La méthode marche pour du code, un pipeline de données, une migration, ou un document qui sert à décider quelque chose.
1. Définir les critères avant de commencer
Pour chaque contrôle, précisez : son nom, la commande exécutée, son poids dans le score, et la condition exacte de réussite. Les poids doivent totaliser 100. Sans définition claire, l'équipe récupère une marge d'interprétation au moment où elle a besoin d'un « oui ».
{
"checks": [
{
"name": "tests_unitaires",
"cmd": "set -o pipefail; pytest -q",
"weight": 40
},
{
"name": "recherche_secrets",
"cmd": "gitleaks detect --no-banner",
"weight": 30
},
{
"name": "analyse_statique",
"cmd": "ruff check .",
"weight": 30
}
]
}
Adaptez cet exemple à votre stack et au risque réel du projet. Une application qui manipule des données personnelles ne peut pas se contenter de « tests unitaires passent ». Il faudra peut-être aussi vérifier les accès, les journaux, les emplacements de fichiers, ou les chemins d'erreur.
Et gardez les critères proportionnés : ajouter vingt contrôles peu pertinents n'augmente pas automatiquement la qualité. Ça augmente le coût d'exécution et la probabilité de blocages inutiles. Commencez par les vérifications qui attrapent les défauts les plus coûteux, puis élargissez après avoir vu des incidents.
2. Exécuter les commandes et conserver les preuves
Le rôle du critique : lancer les contrôles pour de vrai, capturer la sortie, et enregistrer le code de retour. Ensuite, vous pouvez afficher un résumé lisible, par exemple SCORE=55, GAPS=[tests_unitaires::échec] et GATE=failed. Les logs complets doivent rester accessibles, surtout en cas d'échec.
Le score se calcule simplement en additionnant les poids des contrôles réussis. Si les tests valent 40 points et l'analyse statique 30, un échec sur les tests ne « s'efface » pas parce que quelqu'un a dit « c'est bon ». Ici, tout dépend de l'exécution, pas du commentaire.
Conservez au minimum :
- les commandes lancées et leur version (si nécessaire pour reproduire) ;
- le code de sortie de chaque commande ;
- la sortie standard et l'erreur, ou un lien vers les journaux ;
- la version du livrable contrôlé (par exemple l'identifiant de commit) ;
- les contrôles non exécutés et pourquoi.
Un rapport du type « non vérifiable : environnement indisponible » est utile. Un rapport qui transforme silencieusement une absence de contrôle en « réussite », lui, est trompeur.
3. Corriger les écarts et limiter les cycles
Si le résultat est sous le seuil prévu, l'orchestrateur demande au constructeur de corriger l'écart prioritaire, puis relance les contrôles. En pratique, c'est souvent plus efficace de traiter une catégorie à la fois : d'abord les tests en échec, puis l'analyse sécurité, par exemple.
Fixez aussi une limite au nombre d'essais. Huit cycles peuvent suffire pour un processus automatisé, mais le « bon » nombre dépend du délai et du coût d'exécution. Si vous dépassez cette limite, ne bouclez pas sans comprendre : critères mal définis, dépendances instables, environnement incorrect, ou tâches trop larges. Relancer encore ne rend pas le système plus fiable.
Un résultat sous le seuil ne veut pas dire « le code est forcément mauvais ». Un service externe peut être indisponible, un outil peut être mal configuré. Le rapport doit distinguer ces cas : le constructeur ne corrige pas un incident d'infrastructure comme il corrige un test qui échoue.
4. Faire relire le livrable dans un contexte neuf
Une fois le seuil atteint, un réviseur indépendant examine le livrable et les preuves. Il ne doit pas recevoir « tout est bon » : il doit recevoir les critères, les résultats, les éléments non vérifiés, et, si nécessaire, les changements eux-mêmes.
Pour des livraisons à enjeu, vous pouvez regarder sous plusieurs angles : qualité, sécurité, conformité aux exigences métier. Deux ou trois réviseurs suffisent souvent, mais multiplier les avis ne compense pas des critères flous. Définissez ce que chaque revue doit examiner, et quel constat bloque la livraison.
La revue humaine reste pertinente quand l'effet est difficile à mesurer automatiquement : une décision d'accès, le sens d'une migration de données, ou l'usage d'un document par une équipe. Un test automatisé est bon pour vérifier une propriété définie ; il ne remplace pas le jugement quand la question est « est-ce suffisant ? ».
Les faux résultats verts à éviter
Un score élevé ne vaut que si les contrôles mesurent bien le livrable attendu. Les cas ci-dessous produisent des « verts » trompeurs : le rapport dit « réussi », mais l'équipe n'a pas vraiment vérifié ce qu'elle croit.
Un pipeline qui masque le code de sortie
Dans certains environnements shell, une commande comme pytest | tail peut renvoyer le code de sortie de tail plutôt que celui de pytest. Les tests échouent, mais la dernière commande réussit : au final, votre système peut enregistrer un « pass ».
Utilisez set -o pipefail quand vous enchaînez plusieurs outils, et vérifiez que votre script gère correctement les codes de sortie. Et testez le critique lui-même avec un cas volontairement en échec. Une « infra de contrôle » jamais testée, c'est une autre façon de produire des faux positifs.
Un délai d'exécution trop court
Si un test dépasse le délai autorisé, le processus peut être interrompu avant de produire un résultat exploitable. Selon la manière dont le script gère ce timeout, l'échec peut ressembler à une sortie vide, ou ne pas être relié à une vérification claire.
Le délai doit couvrir la durée habituelle avec une marge raisonnable. Surtout, un timeout doit devenir un état explicite - « expiré » ou « non vérifié » - et bloquer le passage quand le contrôle est obligatoire. Gardez les journaux bruts : une sortie vide ne dit pas si le test a réussi, échoué, ou n'a jamais démarré.
Une réponse positive... mais pour le mauvais service
Un serveur qui répond avec HTTP 200 ne prouve pas que la bonne application tourne. Si un port est déjà utilisé, le test peut interroger une autre instance et renvoyer un résultat techniquement valide - sans lien avec la version livrée.
Vérifiez l'identité du service : version, contenu attendu, donnée connue, ou éléments distinctifs. Le contrôle doit répondre à la question « est-ce bien la bonne application qui fonctionne ? », pas juste « quelque chose répond à cette adresse ? ».
Une référence réinitialisée pour faire disparaître une régression
Certains tests comparent un résultat à une référence, par exemple une capture d'écran ou un fichier de référence visuelle. Régénérer cette référence pour faire passer le contrôle peut effacer exactement le défaut que le test devait attraper.
La référence doit être mise à jour uniquement après une décision explicite : changement attendu, justification, revue, historique conservé. Mettre à jour « par réflexe » quand un test est rouge revient à désarmer l'alarme plutôt qu'à vérifier la cause.
Une porte de sécurité qui laisse passer l'incertain
Les contrôles de sécurité doivent jouer le rôle de portes de blocage, pas seulement de points dans un score global. Un secret exposé, une vulnérabilité grave ou un défaut d'authentification doit pouvoir bloquer la livraison même si tous les tests fonctionnels passent.
Le principe est le « fail-closed » : si le contrôle de sécurité est inconclusif, la livraison reste bloquée jusqu'à ce que l'équipe comprenne le résultat. Ça ne veut pas dire qu'un outil « prouve » l'absence de vulnérabilités. Ça veut dire qu'une incertitude importante ne doit pas être convertie en validation automatique.
Faire du score un outil de décision, pas une garantie
Le score aide à lire vite. Il ne résume pas toute la qualité d'un livrable, et il ne doit jamais remplacer des preuves détaillées. SCORE=100 signifie seulement : les contrôles définis ont réussi selon les règles prévues. Ça ne démontre pas que tous les risques ont été couverts, que les exigences sont complètes, ou que le produit respecte toutes les obligations applicables.
Cette nuance compte particulièrement pour les systèmes qui traitent des données personnelles ou s'insèrent dans des processus métier sensibles. Le respect du RGPD ne se résume pas à un scan automatique et à une suite de tests : il faut aussi comprendre les finalités, les données traitées, les responsabilités, et les mesures organisationnelles. Les vérifications techniques aident à maîtriser le risque, mais elles ne remplacent pas l'analyse de conformité.
Fixer un seuil adapté aux conséquences
Le seuil de passage n'est pas une constante universelle. Pour un prototype interne réversible, une équipe peut accepter certains contrôles manuels documentés. Pour une migration difficile à annuler ou une mise en production exposée, il faut des critères plus stricts.
Posez-vous quatre questions :
- Quel est le coût d'un défaut ? Un bug d'affichage n'a pas les mêmes conséquences qu'une fuite de données.
- Quels contrôles sont obligatoires ? Certains échecs doivent bloquer, même si le score global reste haut.
- Qu'est-ce qui reste hors mesure ? Les limites doivent apparaître dans le rapport.
- Qui accepte le risque résiduel ? Cette décision revient à une personne responsable, pas au score.
Ce choix évite deux dérives. La première : automatiser tout et traiter le résultat comme une vérité complète. La seconde : refuser l'automatisation parce qu'elle n'est pas parfaite. Dans la plupart des équipes, des contrôles reproductibles et ciblés valent mieux qu'une « validation déclarative » sans preuves.
Construire une boucle maintenable
Commencez avec quelques contrôles qui couvrent les défauts les plus probables et les plus coûteux. Faites échouer volontairement chaque contrôle une fois, pour vérifier que le système détecte bien l'échec. Ensuite, ajoutez de nouveaux contrôles après les incidents, les changements d'architecture, et les obligations du projet.
Évaluez aussi le coût d'exploitation : durée des vérifications, fréquence des faux blocages, temps pour comprendre un échec, et nombre de contournements. Si l'équipe ignore régulièrement les alertes, le problème n'est pas forcément son « manque de discipline ». Les contrôles sont peut-être trop bruyants, trop lents, ou mal alignés avec les risques réels.
L'objectif, c'est d'obtenir une discussion plus précise. Plutôt que « l'agent dit que c'est terminé », vous pouvez dire : « les tests et l'analyse statique ont réussi sur ce commit ; la revue sécurité reste en attente ; voici les journaux ». Cette formulation ne supprime pas l'incertitude. Elle la rend visible, et donc gérable.
Pour approfondir la méthode présentée dans le contenu d'origine, consultez l'article sur la boucle de test pour agents IA. Pour les vérifications de secrets, référez-vous aussi à la documentation de Gitleaks.
Conclusion : remplacer l'assurance par des preuves
Un agent qui dit que « c'est terminé » ne fournit pas, à lui seul, une preuve de réussite. Pour rendre la livraison plus fiable, fixez les contrôles avant le travail, exécutez-les via un critique indépendant, conservez les sorties, puis faites relire dans un contexte séparé. Traitez les risques sécurité comme des portes de blocage, et indiquez clairement ce que vous n'avez pas pu vérifier.
Le score est utile s'il accélère une décision informée. Il devient dangereux dès qu'on le confond avec une garantie. Commencez avec trois à cinq contrôles adaptés à votre projet, testez qu'ils détectent vraiment les échecs, puis améliorez la boucle au fil des incidents. L'objectif n'est pas un système théoriquement parfait : c'est un processus suffisamment fiable pour que l'équipe sache ce qu'elle a vérifié - et ce qu'elle n'a pas vérifié.