Agents IA en production : ce qui casse entre la démo et le service

La démonstration a marché. La direction a validé. Et trois semaines après la mise en service, l'agent a envoyé deux fois la même relance à un client, s'est bloqué douze minutes dans une boucle, et a produit une facture de jetons que personne n'avait budgétée. Rien de tout cela n'est un accident : les agents IA en production échouent de façons prévisibles, et qui se traitent.

Pourquoi la démo ment, et ce n'est pas de la malchance

Commençons par l'arithmétique, parce qu'elle explique presque tout.

Un agent enchaîne des étapes : il lit une demande, appelle un outil, interprète le résultat, appelle un autre outil, décide qu'il a fini. Chaque étape a une probabilité de réussite. Ces probabilités se multiplient.

Un agent qui réussit 95 % de ses étapes, ce qui paraît excellent, réussit une tâche de vingt étapes dans 0,95²⁰ des cas, soit 36 %. Le même agent porté à 99 % par étape passe à 82 %. Autrement dit, gagner quatre points de fiabilité unitaire fait plus que doubler le taux de réussite global. C'est là que se joue le travail, pas dans le choix du modèle.

Cette intuition est mesurée. Le banc d'essai τ-bench, publié par des chercheurs de Sierra en 2024, évalue des agents sur des tâches de service client en comparant l'état final de la base de données à l'état attendu. La formulation est brutale et juste : le remboursement a été émis, ou il ne l'a pas été. La fluidité de la conversation ne compte pour rien.

τ-bench a introduit une métrique qui devrait être affichée dans toutes les salles de réunion : pass^k, la probabilité de réussir les k tentatives, et non la probabilité d'en réussir au moins une. Le résultat publié pour un agent à base de GPT-4o dans le domaine du commerce de détail : moins de 50 % de réussite en une tentative, et environ 25 % en pass^8. En clair, une chance sur quatre de traiter correctement le même problème pour huit clients différents.

Et τ-bench ne mesure que des tâches courtes, de quelques minutes. Les tâches réelles durent des dizaines de minutes et accumulent bien plus d'étapes.

Retenez le chiffre : la démo, c'est pass@1 ; la production, c'est pass^k.

Les cinq points de rupture de la boucle d'outils

La boucle est simple : le modèle reçoit un état, choisit un outil, l'outil répond, le modèle reprend. Cinq choses cassent, toujours les mêmes.

L'outil échoue. Le service distant renvoie une erreur 500, un dépassement de délai, une réponse vide. Un agent naïf reçoit ce message d'erreur comme du texte, l'interprète comme une information, et continue comme si de rien n'était. Il faut distinguer explicitement, dans ce que vous renvoyez au modèle, une réponse métier d'un incident technique, et décider vous-même de réessayer plutôt que de laisser le modèle décider.

La sortie est mal formée. L'agent doit produire un objet structuré et produit du texte, ou un champ manque, ou un montant arrive en chaîne de caractères. Validez systématiquement contre un schéma avant d'agir. Une sortie invalide se renvoie au modèle avec l'erreur de validation, pas au système suivant.

La boucle ne s'arrête pas. Le modèle rappelle le même outil avec les mêmes arguments, en espérant un autre résultat. C'est le mode de défaillance le plus coûteux, parce qu'il consomme sans produire. Détectez la répétition d'un appel identique et interrompez.

Le contexte enfle. À chaque tour, l'historique complet repart au modèle. Un agent à trente tours refacture trente fois un contexte qui grossit. C'est la mécanique décrite dans notre article sur ce que change le contexte long, et sur un agent elle est multiplicative.

L'agent réussit à moitié. Le pire cas : il crée la commande, puis échoue à envoyer la confirmation. La tâche est en échec, mais le monde a changé. C'est le sujet de la section suivante.

L'idempotence, ou comment ne pas facturer deux fois

Un agent qui réessaie n'est utile que si réessayer est sans danger. Dans le cas contraire, votre mécanisme de reprise devient votre principal générateur d'incidents.

Le principe tient en une phrase : une opération doit produire le même résultat qu'elle soit exécutée une fois ou dix fois.

En pratique, chaque outil qui modifie quelque chose reçoit une clé d'idempotence, dérivée de la tâche et de l'intention, pas du hasard ni de l'horodatage. Côté serveur, si la clé a déjà été vue, on renvoie le résultat de la première exécution au lieu de rejouer l'opération.

def envoyer_devis(client_id, montant, cle_idempotence):
    deja = journal.chercher(cle_idempotence)
    if deja:
        return deja.resultat          # rejoué sans effet de bord
    resultat = service_devis.envoyer(client_id, montant)
    journal.enregistrer(cle_idempotence, resultat)
    return resultat

# La clé décrit l'intention, pas l'instant.
cle = f"devis:{tache_id}:{client_id}:{montant}"

La clé dérivée de l'intention est le point important. Une clé aléatoire ou horodatée ne protège de rien : chaque tentative en produit une nouvelle et l'opération se rejoue.

Corollaire d'architecture : séparez les outils qui lisent de ceux qui écrivent. Les premiers peuvent être appelés librement, y compris en parallèle. Les seconds passent par la validation, la journalisation et la clé. Cette séparation, faite dès le premier jour, coûte une heure ; faite après le premier doublon envoyé à un client, elle coûte bien davantage.

Quatre garde-fous, et où les poser

Un plafond de tours. Fixez un nombre maximal d'itérations par tâche, et traitez l'atteinte du plafond comme un échec explicite qui remonte à un humain, pas comme une fin normale. Une tâche qui atteint son plafond est un signal, à compter et à surveiller.

Un plafond de coût. Comptez les jetons consommés depuis le début de la tâche et arrêtez au-delà d'un seuil. Sans ce compteur, une seule tâche pathologique peut coûter davantage que mille tâches normales, et vous ne l'apprendrez qu'à la facture.

Une validation avant tout effet de bord. Aucune écriture, aucun envoi, aucun paiement sans un contrôle déterministe en amont : le montant est dans une fourchette plausible, le destinataire existe, la référence est cohérente. Ce contrôle est du code ordinaire, pas un modèle. On ne fait pas valider une IA par une autre IA sur les opérations qui engagent.

Une séparation des privilèges. L'agent ne dispose que des outils nécessaires à sa tâche, avec les droits minimaux. Un agent de support n'a pas besoin d'un accès en écriture à la facturation. C'est le principe du moindre privilège, et il s'applique ici comme à n'importe quel compte de service. L'exemple le plus parlant vient des laboratoires eux-mêmes : quatre modèles sortis de leur environnement de test parce qu'un accès réseau y était resté ouvert, et sont allés s'authentifier chez de vraies entreprises.

Tracer pour rejouer, et ne pas tracer n'importe quoi

Quand un incident survient, la seule question qui compte est : que s'est-il passé exactement ? Vous ne pourrez y répondre que si vous avez tracé assez.

Le minimum utile, par tâche : un identifiant unique, la demande initiale, et pour chaque tour l'outil appelé, ses arguments, le résultat renvoyé, le nombre de jetons consommés et l'horodatage. Plus l'issue finale et, en cas d'échec, à quel tour.

Ce qui manque le plus souvent, et qui coûte le plus cher : les arguments réels de l'appel d'outil. Sans eux, vous savez que l'agent a appelé creer_commande et vous ne savez pas ce qu'il a demandé. Le journal ne sert alors à rien.

Ce qu'il ne faut pas tracer, en revanche, est tout aussi net. Un journal d'agent contient des données personnelles de vos clients, parfois des identifiants, des références bancaires ou des informations de santé. Il tombe sous le RGPD comme n'importe quel traitement : durée de conservation définie, accès restreint, masquage des champs sensibles à l'écriture et non à la lecture. Un journal de débogage conservé indéfiniment sur un poste de développeur est une fuite en attente.

Le ROI, chiffré

C'est la partie que les démonstrations sautent, et c'est la seule qui décide.

La bonne unité n'est pas le coût par appel mais le coût par tâche aboutie :

coût par tâche aboutie = (coût moyen d'une tentative × nombre de tentatives)
                         ÷ taux de réussite sans intervention humaine

Un exemple avec des hypothèses posées, à refaire avec les vôtres. Une tâche consomme en moyenne 40 000 jetons d'entrée et 3 000 de sortie sur douze tours. Le taux de réussite sans reprise humaine est de 70 %. Trente pour cent des tâches demandent donc une intervention, chacune mobilisant un opérateur dix minutes.

Ce que dit ce calcul, une fois posé : le taux de reprise humaine pèse plus lourd que le prix du modèle. Passer de 70 % à 85 % de réussite autonome divise par deux le temps humain consommé, ce qui produit presque toujours plus d'économies que tout changement de fournisseur. C'est pourquoi les garde-fous et l'idempotence sont des investissements de rentabilité, pas des précautions de confort.

Les trois indicateurs à suivre en continu, et à afficher :

1. Taux de réussite sans intervention, mesuré sur l'état final du système, pas sur l'avis du modèle.
2. Taux de reprise humaine, et le temps moyen d'une reprise.
3. Coût par tâche aboutie, tendance sur trente jours. S'il monte alors que le volume est stable, quelque chose dérive.

Les tarifs, eux, bougent vite et dans les deux sens, comme le montre la mécanique économique du secteur. Bâtir un modèle économique sur une grille figée est imprudent. Sur le coût lui-même, les leviers qui s'appliquent à un agent sont les mêmes que partout ailleurs, avec un effet démultiplié par le nombre de tours : nous les prenons dans l'ordre dans maîtriser la facture d'API IA.

Ce qui ne se voit qu'en production

Trois choses qu'aucune démonstration ne révèle.

Les entrées réelles ne ressemblent pas aux entrées de test. Les vrais utilisateurs écrivent en abrégé, en majuscules, en trois langues mélangées, collent des captures d'écran et posent deux questions à la fois. Constituez votre jeu de test à partir des vrais échecs, jamais à partir de cas inventés.

La latence des outils varie. Un service qui répond en 200 millisecondes en test peut mettre huit secondes un mardi à 14 heures. Sur douze tours, la tâche devient inutilisable sans que rien n'ait échoué.

Le modèle change sous vos pieds. Les fournisseurs déprécient, remplacent et réajustent leurs modèles à un rythme désormais trimestriel. Un agent réglé finement sur le comportement d'une version précise est un agent à réajuster à date inconnue. Prévoyez le budget de test de non-régression, il n'est pas optionnel.

Pour commencer par le bon bout

Si vous n'avez encore rien mis en service, le premier tri est ailleurs que dans la technique : il s'agit de choisir le bon processus. Notre article sur par où commencer pour automatiser un process traite cette étape.

Et si vous avez déjà un agent en service, l'ordre des travaux est celui-ci : le compteur de coût par tâche d'abord, parce qu'il révèle ce que vous ignorez ; l'idempotence ensuite, parce qu'elle empêche les incidents visibles du client ; les plafonds et la validation ensuite ; le réglage fin du modèle en dernier, quand vous saurez enfin ce qui échoue et pourquoi.