Agents IA en production : les cinq garde-fous à poser

Mettre un agent IA en production n'a pas grand-chose à voir avec en faire la démonstration. Un prototype d'agent impressionne en dix minutes. Il lit une demande, appelle trois outils, met à jour une fiche et renvoie un compte rendu propre. Puis on le met en service, et les questions changent de nature : que se passe-t-il quand l'outil appelé renvoie une erreur silencieuse, quand la demande contient une instruction cachée, quand l'agent boucle sur une tâche impossible à 2 heures du matin ?

Passer un agent IA en production ne consiste pas à améliorer sa qualité moyenne. Cela consiste à borner son comportement dans les cas où il se trompe, ce qui arrivera. La différence entre un agent qui tient six mois et un agent qu'on débranche au bout de trois semaines ne se joue presque jamais sur le modèle : elle se joue sur cinq garde-fous, tous ennuyeux à construire et tous indispensables.

Chacun est présenté ici avec le mode de défaillance qu'il couvre et le coût opérationnel qu'il ajoute, parce qu'aucun n'est gratuit. Si vous n'avez le temps que pour deux d'entre eux, prenez le premier et le quatrième : ils bornent le dégât et permettent de comprendre ce qui s'est passé.

Agent IA en production : les modes de défaillance à couvrir

Un agent est une boucle : il observe, décide, appelle un outil, observe le résultat, recommence. Cette boucle échoue de cinq façons caractéristiques, et chaque garde-fou répond à l'une d'elles.

Notez qu'aucun de ces modes n'est propre à l'intelligence artificielle. Ce sont les défaillances classiques de tout système qui agit sur le monde. Ce que l'agent change, c'est la vitesse à laquelle il les enchaîne et l'absence d'un chemin d'exécution fixe permettant de les anticiper.

Garde-fou 1 : le budget d'actions

Un agent doit avoir un plafond dur sur trois compteurs, vérifiés à chaque tour de boucle et non en fin d'exécution : le nombre d'appels d'outils, le nombre de tokens consommés, et la durée totale. Quand un plafond est atteint, l'agent s'arrête et remonte un état incomplet plutôt que de continuer.

Des valeurs de départ raisonnables pour un agent de traitement de demande : 15 appels d'outils, 150 000 tokens, 120 secondes. Elles paraissent basses. C'est volontaire : sur des tâches bien cadrées, 90 % des exécutions réussies consomment moins du tiers de ces plafonds. Les 10 % qui les atteignent sont, presque toujours, des exécutions qui n'allaient nulle part.

Coût opérationnel : faible en développement, réel en exploitation. Vous devez décider quoi faire des exécutions interrompues, et prévoir une file de reprise manuelle. Comptez que 3 à 8 % des demandes y atterrissent les premières semaines, puis moins de 2 % une fois les plafonds calibrés.

Garde-fou 2 : la liste blanche d'outils

Le réflexe naturel consiste à donner à l'agent l'accès à tout ce qui pourrait servir. C'est l'erreur structurante. Un agent doit disposer de la plus petite liste d'outils qui lui permette de faire son travail, et cette liste doit varier selon la tâche : l'agent qui répond à une demande d'information n'a pas besoin de l'outil qui modifie une commande.

Trois règles de conception :

• Des outils à granularité fine. Un outil « mettre à jour la fiche client » qui accepte n'importe quel champ est un outil dangereux. Trois outils qui modifient chacun un champ précis sont contrôlables.
• Des permissions portées par l'outil, pas par l'agent. L'outil vérifie lui-même que l'identifiant concerné entre dans le périmètre autorisé pour la session en cours. Ne comptez jamais sur la consigne pour tenir cette frontière : elle est du texte, et le texte se contourne.
• Une séparation lecture / écriture. Les outils qui écrivent forment un sous-ensemble explicite, journalisé différemment, et soumis au garde-fou suivant.

C'est aussi la principale défense contre l'injection de consignes dans les contenus que l'agent lit. Une page web ou un document piégé peut convaincre un modèle d'appeler un outil ; il ne peut pas lui donner un outil qu'il n'a pas. Le sujet est développé dans notre article sur l'injection de prompt, et il constitue le premier risque des classements de sécurité applicative dédiés aux applications à base de modèles de langage.

Coût opérationnel : c'est le garde-fou le plus coûteux à mettre en place. Découper des outils fins et porter les contrôles côté outil représente typiquement 30 à 40 % de l'effort de développement de l'agent. C'est aussi celui qui évite l'incident dont on ne se remet pas. Les protocoles standardisés d'exposition d'outils, comme celui que nous avons décrit dans notre présentation du protocole MCP, aident sur la plomberie mais ne dispensent pas de cette réflexion de périmètre.

Garde-fou 3 : le point d'arrêt humain

Toute action irréversible s'arrête devant un humain. La définition de l'irréversible est locale, mais elle inclut presque toujours : l'envoi d'un message vers l'extérieur, la modification d'un engagement contractuel ou tarifaire, la suppression de données, tout mouvement financier, et toute action portant sur plus de N enregistrements d'un coup.

La validation doit être conçue pour être rapide, sinon elle sera contournée. Trois conditions :

1. Le validateur voit ce qui va être fait, pas le raisonnement de l'agent. Un résumé de trois lignes et le contenu exact de l'action.
2. La validation se fait là où travaille le validateur : messagerie interne, outil métier, pas une console dédiée qu'il faudra penser à ouvrir.
3. L'absence de réponse au bout d'un délai défini annule l'action au lieu de la déclencher. Le silence n'est jamais un accord.

Coût opérationnel : c'est le garde-fou qui rogne le gain annoncé. Un agent dont 40 % des actions passent en validation ne fait pas gagner 40 % de temps de moins qu'annoncé, il en fait gagner beaucoup moins, parce que l'interruption a un coût propre. La bonne trajectoire consiste à démarrer avec une validation large, puis à retirer du périmètre les catégories d'actions dont le taux de correction humaine est tombé sous 1 % sur plusieurs centaines de cas.

Garde-fou 4 : le journal auditable

Sans journal, un incident sur un agent est indébrouillable : la sortie ne permet pas de reconstituer le chemin. Le journal doit enregistrer, pour chaque exécution et chaque tour de boucle : l'horodatage, l'identifiant de session, la version exacte du modèle et de la consigne, l'outil appelé avec ses paramètres, le résultat renvoyé (tronqué si volumineux), et l'état des compteurs de budget.

Deux exigences qu'on oublie systématiquement :

• La version de la consigne. Un agent dont on ne sait pas quel prompt tournait le jour de l'incident n'est pas auditable. Versionnez les consignes comme du code.
• La corrélation. Un identifiant unique doit relier la demande d'origine, tous les appels d'outils et l'action finale. C'est ce qui permet de répondre en dix minutes à « pourquoi ce client a-t-il reçu ce message ? ».

Attention à la conservation : ces journaux contiennent des données métier, souvent personnelles. Ils entrent dans votre politique de conservation au même titre que le reste, avec une durée définie et une purge effective.

Coût opérationnel : modéré. Comptez quelques jours de développement, et un volume de stockage qui surprend au démarrage. Un agent traitant 500 demandes par jour produit facilement plusieurs gigaoctets de journaux par mois si vous conservez les contenus intégraux. Tronquez les charges utiles au-delà de quelques kilo-octets, en gardant une empreinte pour vérification.

Garde-fou 5 : le plan de retour arrière

Le dernier garde-fou est le plus négligé parce qu'il ne sert que le jour où tout va mal. Il tient en trois éléments écrits avant l'ouverture du service :

• Un interrupteur qui suspend l'agent sans le désinstaller, actionnable par une personne d'astreinte qui n'est pas son développeur.
• Un mode dégradé défini : que fait-on des demandes pendant la suspension ? File d'attente, traitement manuel, message d'attente. La réponse doit exister avant la panne.
• Une procédure de réparation : comment identifie-t-on les actions erronées déjà passées, et comment les corrige-t-on. Le journal du garde-fou 4 est ce qui rend cette procédure possible.

Ajoutez-y le versionnement : consigne, liste d'outils et modèle forment un triplet qu'on doit pouvoir remettre dans un état antérieur connu, testé, en une commande.

Coût opérationnel : faible en construction, réel en discipline. C'est un exercice à répéter à blanc une fois par trimestre, faute de quoi la procédure existe sur le papier et personne ne sait l'exécuter.

Par où commencer

Ces cinq garde-fous ne remplacent pas le travail de sécurisation en amont, décrit dans notre article sur la façon de sécuriser un agent IA, ni la compréhension de ce qu'un agent sait et ne sait pas faire, posée dans notre définition de l'agent IA. Ils s'ajoutent, et ils s'ajoutent avant la mise en service, pas après le premier incident.

L'ordre d'implémentation qui donne le meilleur retour : budget d'actions et journal auditable d'abord, en une semaine, parce qu'ils bornent le dégât et le rendent lisible. Point d'arrêt humain ensuite, large puis progressivement réduit. Liste blanche d'outils en parallèle du développement, jamais après. Plan de retour arrière écrit et répété avant l'ouverture.

Un agent IA en production qui tient dans la durée n'est pas celui qui se trompe le moins. C'est celui dont les erreurs coûtent peu, se voient tout de suite, et se corrigent sans réunion de crise.