Lancer un agent IA : y aller, attendre ou bloquer ?
Votre agent IA réussit tous les tests que vous avez écrits. Peut-il quand même être le mauvais candidat au lancement ?
EN 30 SECONDES
Une barrière de mise en production est une règle, écrite avant les tests, qui transforme les résultats d’un agent IA en un seul verdict : on y va, on attend ou on bloque. Un agent peut avoir raison chaque fois qu’il répond, et répondre quand il devrait refuser.
À RETENIR · 3
- Un framework dit ce qu’un modèle sait faire. Une barrière dit si cet agent, sur ces documents, peut passer en production.
- Des tests sans faute ne couvrent que les cas écrits. Ajoutez des cas où la source manque.
- On attend : on resserre et on rejoue. On bloque : on ferme d’abord la brèche.
Sur cette page
Des tests sans faute, et pourtant « pas encore »
EN BREF Une exécution sans faute ne couvre que les cas que vous avez écrits. Le cas oublié peut encore décider du lancement.
LES MOTS À CONNAÎTRE
- Éval (évaluation)
- Un cas de test pour un agent IA : une question, ses documents et ce qu’est une bonne réponse.
- Jeu d’évals figé
- Une liste fixe d’évals, la même à chaque version, pour comparer deux exécutions.
- Barrière de mise en production
- Une règle écrite avant les tests, qui tire un seul verdict des résultats : on y va, on attend ou on bloque.
J’ai livré en production une première plateforme IA de 11 agents pour un fonds américain de private equity immobilier, confidentiel, qui gère environ 3 Md$ d’actifs. Les agents lisaient ses documents, et la plateforme comprenait des évaluations et du red-teaming (attaques simulées).
Cet article décrit une barrière de mise en production pour ce travail sur les documents. Sa grille sert à expliquer : ce n’est pas la suite de tests du client rendue publique.
Le premier jeu de tests
Un cas de preuve manquante en plus
Chaque Éval (évaluation) Un cas de test pour un agent IA : une question, ses documents et ce qu’est une bonne réponse. Voir le glossaire est un cas de test. Un jeu de tests sans cas de preuve manquante ne repère pas un agent qui répond au lieu de refuser.
Dans la section suivante : Alors, pourquoi ne pas se fier à une boîte à outils toute faite ?
Pourquoi un framework d’évals ne décide pas à votre place
EN BREF Un framework dit ce qu’un modèle sait faire ; seule votre équipe peut décider si cet agent part en production.
Un framework d’évals est une boîte à outils de test toute faite. Il peut vous dire que ce modèle trouve et cite des documents, ce qui vaut pour mille équipes. Le « assez bon » de votre agent, c’est votre équipe qui le définit.
Fin 2025, LangChain a interrogé des professionnels sur les agents IA et reçu 1 340 réponses. Environ 89 % disent avoir de l’observabilité, une trace de ce que font leurs agents.
Source : LangChain, State of Agent Engineering, enquête publique, du 18 novembre au 2 décembre 2025, 1 340 réponses.
La barrière relève de ce second groupe, le plus petit : elle teste hors ligne avant toute mise en service. C’est la pièce qui, dans ma façon de livrer de l’IA en finance régulée, dit oui ou non.
Dans la section suivante : Alors, comment la barrière dit-elle oui ou non ?
Comment la barrière tranche : y aller, attendre ou bloquer
EN BREF Un jeu figé en entrée, chaque dimension notée sur la même exécution, un seul verdict en sortie.
On rejoue le même Jeu d’évals figé Une liste fixe d’évals, la même à chaque version, pour comparer deux exécutions. Voir le glossaire à chaque version. La Barrière de mise en production Une règle écrite avant les tests, qui tire un seul verdict des résultats : on y va, on attend ou on bloque. Voir le glossaire en tire un verdict parmi trois, écrits avant le jour du lancement : « assez bon » ne se négocie pas à 18 h.
EN CLAIR
S’abstenir, c’est dire « je ne sais pas » et passer le cas à une personne. L’abstention est calibrée quand l’agent refuse là où la preuve est mince et répond là où elle suffit.
ÉTAPE PAR ÉTAPE
Étape 1. Rejouer. Le candidat passe le même jeu figé que la dernière fois : deux exécutions restent comparables.
- Rejouer Le candidat passe le même jeu figé que la dernière fois : deux exécutions restent comparables.
- Noter Chaque dimension est notée sur cette exécution : sources, chiffres, refus, résistance aux attaques, vitesse et coût. Bien refuser compte autant que la justesse.
- On y va Tout passe et l’abstention est calibrée : il part derrière une revue humaine, et il est réévalué si ses données dérivent.
- On attend La justesse passe, mais il répond à des cas qu’il devrait passer à une personne. On resserre et on rejoue. Pas de lancement sur une promesse.
- On bloque Une attaque réussit, ou un chiffre faux est affirmé avec assurance. On corrige d’abord : aucun score de justesse ne rachète une fuite.
Une attente veut dire que l’agent est capable mais mal réglé : une règle plus stricte et une nouvelle exécution peuvent le corriger. Un blocage veut dire que quelque chose est passé, et relancer n’y change rien tant que la brèche reste ouverte.
ADAM explique : Pensez au contrôle technique : même liste à chaque visite, et des freins usés recalent la voiture, même belle. La limite : l’État fixe ces règles, mais vos seuils sont les vôtres.
Et une voiture contrôlée peut quand même avoir un accident. Une barrière franchie n’est pas une garantie non plus.
OBJET OBTENU
Le verdict s’écrit avant
NIVEAU TERMINÉ
Ce que vous savez maintenant
- Une barrière ramène une exécution des tests à un seul verdict, selon des règles écrites avant les tests.
- Un agent peut avoir raison chaque fois qu’il répond et échouer quand même, parce qu’il répond là où il devrait refuser.
- L’attente et le blocage n’ont pas la même cause : un agent mal réglé d’un côté, une brèche que relancer ne ferme pas de l’autre.
Vérifiez par vous-même
Touchez ou cliquez une question pour voir la réponse.
Cas fictif : votre agent répond juste partout, même à deux questions dont la source manque. Quel verdict ?
On attend. Sans source, il aurait dû dire « je ne sais pas ». On resserre la règle et on rejoue le même jeu.
Ancien CTO d’Integra. Auteur nommé (1 sur 5) d’ERC-3643, premier auteur d’ERC-6960, co-auteur d’ERC-7410 et co-auteur d’ERC-8203, encore à l’état de brouillon. Conçoit des systèmes d’IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.