Une démonstration d’agent IA est facile à réussir. On choisit trois cas favorables, on ajuste les instructions jusqu’à ce qu’ils passent, et le résultat impressionne.
La production est un autre métier. Ce qui suit vient de systèmes que nous exploitons pour des clients, avec des volumes réels et des utilisateurs qui n’ont pas envie de vérifier chaque réponse.
Le jeu d’évaluation avant le prompt
C’est le premier livrable de nos missions, avant toute écriture d’instructions : entre 150 et 300 cas réels, tirés de l’historique du client, avec la réponse attendue pour chacun.
Sans ce référentiel, toute modification est un pari. On ajuste une instruction pour corriger un cas signalé, et on dégrade silencieusement dix cas qui fonctionnaient. Avec le jeu d’évaluation exécuté à chaque changement, l’effet est mesuré en quelques minutes.
Les métriques que nous suivons sont au nombre de quatre : le taux de réponse correcte, le taux d’abstention (l’agent dit qu’il ne sait pas), la latence médiane et le coût par tâche. Une amélioration du premier au détriment du deuxième est souvent une régression déguisée.
Les garde-fous vivent dans le code
Une consigne du type « ne modifie jamais une commande déjà expédiée » est une intention, pas une sécurité. Elle sera respectée la plupart du temps, ce qui est précisément le problème.
Nous classons chaque outil exposé à l’agent en trois niveaux. Lecture seule, sans risque. Écriture réversible, journalisée. Action irréversible, soumise à validation humaine explicite. Ce classement est appliqué dans le code de l’outil, avec ses propres tests, indépendamment de ce que le modèle décide.
S’y ajoutent trois limites dures : nombre maximal d’étapes, budget de jetons par tâche, délai d’exécution. Au-delà, l’agent s’arrête et transmet à un humain avec l’historique complet de son raisonnement.
La qualité des outils fait la qualité de l’agent
C’est le constat qui surprend le plus nos clients. Sur nos projets, améliorer la description et le comportement des outils exposés produit un gain de qualité largement supérieur à un changement de modèle.
Un outil dont la description est ambiguë, qui renvoie null en cas d’erreur ou qui accepte des paramètres trop libres produit un agent erratique. Un outil au périmètre étroit, à la description sans ambiguïté, qui valide strictement ses entrées et renvoie des erreurs explicites produit un agent prévisible.
Autrement dit : c’est de l’ingénierie logicielle classique, pas de la magie.
Journaliser le raisonnement, pas seulement le résultat
Quand un agent se trompe, connaître sa réponse ne sert à rien. Il faut savoir quels outils il a appelés, avec quels paramètres, ce qu’ils ont renvoyé et à quel moment il a bifurqué.
Nous journalisons donc l’intégralité de la boucle. Le volume est important — plusieurs mégaoctets par jour sur les systèmes actifs — et le coût de stockage est négligeable devant le temps gagné au premier incident.
Ce que l’on peut raisonnablement promettre
Sur les déploiements que nous suivons, un agent bien conçu traite de 40 % à 65 % des tâches d’un flux répétitif sans intervention humaine, avec un taux d’erreur mesuré entre 1 % et 3 %. Le reste est escaladé, et c’est un bon résultat, pas un échec.
Toute promesse d’automatisation totale devrait éveiller la méfiance.