Le prototype n'est pas le produit
Trois jours pour une démonstration convaincante, trois mois pour un service que l'on ose brancher sur des données réelles. Voici ce qui occupe ces trois mois.
Le premier poste est l'évaluation. Sans jeu de test, il n'existe aucun moyen honnête de dire si une modification améliore ou dégrade le système.
Une démonstration se juge sur dix questions choisies par celui qui la présente. Un service en production reçoit des milliers de questions que personne n'a choisies : mal orthographiées, ambiguës, hors sujet, parfois malveillantes. L'écart entre les deux, c'est tout le travail.
Construire le jeu d'évaluation avant tout le reste
Nous commençons chaque projet d'agent par la même étape, avant d'écrire la moindre consigne définitive : constituer un jeu d'évaluation. Cent à deux cents cas réels, tirés des demandes que l'agent devra traiter, avec pour chacun la réponse attendue ou, à défaut, les critères d'une bonne réponse.
Ce jeu sert trois fois :
- Pour décider. Changer de modèle, reformuler une consigne, ajouter un outil : chaque modification est mesurée sur le même jeu, et l'on garde ce qui améliore le score.
- Pour se protéger. Une correction qui règle un cas en casse souvent trois autres. Sans jeu de test, on ne le découvre qu'en production.
- Pour discuter avec le métier. « 87 % de réponses correctes sur 150 cas représentatifs » est une phrase qu'un directeur peut accepter ou refuser. « Ça marche plutôt bien » n'en est pas une.
Le jeu doit contenir les cas difficiles : les demandes ambiguës, celles qui sortent du périmètre, celles où la bonne réponse est « je ne sais pas ». Un agent qui répond avec assurance à tout est plus dangereux qu'un agent qui sait s'arrêter.
Les garde-fous : décider de ce que l'agent n'a pas le droit de faire
Un agent, contrairement à un simple assistant conversationnel, agit : il interroge une base, envoie un courriel, crée une commande. Chaque outil qu'on lui donne est une porte ouverte. La question n'est donc pas seulement « que doit-il faire ? », mais « que doit-il être incapable de faire ? ».
- Des droits minimaux. L'agent se connecte avec un compte dédié, en lecture seule partout où l'écriture n'est pas indispensable.
- Une validation humaine sur les actions irréversibles. Envoyer, payer, supprimer, publier : l'agent prépare, un humain confirme.
- Des limites explicites. Nombre d'appels d'outils par demande, montant maximal, liste fermée de destinataires. Une boucle infinie coûte de l'argent avant de coûter la confiance.
- Un filtrage des entrées. Un document ou un courriel lu par l'agent peut contenir des instructions déguisées. Ce que l'agent lit est une donnée, jamais un ordre.
Les coûts : ce qui était négligeable devient une ligne budgétaire
En démonstration, le coût d'un appel au modèle est invisible. En production, il se multiplie par le nombre d'utilisateurs, par le nombre d'étapes qu'enchaîne l'agent et par la longueur du contexte qu'on lui envoie à chaque étape. Un agent qui relit tout l'historique de la conversation à chaque tour voit sa facture croître bien plus vite que son usage.
Trois réflexes limitent la dérive : mesurer le coût par demande dès le premier jour, réserver le modèle le plus puissant aux étapes qui en ont besoin, et mettre en cache ce qui se répète. Le bon indicateur n'est pas le coût mensuel, c'est le coût par demande traitée avec succès.
La supervision humaine n'est pas un aveu d'échec
Beaucoup de projets visent l'autonomie complète dès le départ. C'est la meilleure façon de ne jamais passer en production. Nous préférons une montée progressive :
- Mode suggestion. L'agent propose, un humain valide chaque réponse. On mesure le taux d'acceptation.
- Mode supervisé. L'agent traite seul les cas où il est sûr de lui ; les autres partent vers un humain.
- Mode autonome, sur un périmètre restreint, avec un contrôle par échantillon.
Chaque palier se franchit sur la foi des chiffres, pas d'une impression. Et chaque correction faite par un humain enrichit le jeu d'évaluation : la supervision devient la principale source d'amélioration du système.
Prévoir le jour où le modèle ne répond pas
Un service d'IA dépend presque toujours d'un fournisseur externe. Ce fournisseur aura des lenteurs, des pannes, des limites de débit, et il fera évoluer ses modèles. Chacun de ces événements doit avoir été anticipé :
- Un délai maximal pour chaque appel, au-delà duquel l'agent abandonne proprement plutôt que de laisser l'utilisateur attendre indéfiniment.
- Un mode dégradé : transmettre la demande à un humain, ou proposer de réessayer plus tard, avec un message clair.
- Une version de modèle figée, explicitement choisie. Quand le fournisseur en propose une nouvelle, on la fait passer par le jeu d'évaluation avant de l'adopter, comme n'importe quelle mise à jour.
Ce sont des précautions banales pour tout logiciel qui dépend d'un service tiers. Elles sont pourtant presque toujours absentes des prototypes.
Observer ce qui se passe vraiment
Enfin, un agent en production doit être observable. Pour chaque demande, il faut pouvoir retrouver ce qui a été reçu, les outils appelés, les réponses obtenues, le coût et le temps de traitement. Sans cette trace, la moindre réclamation d'un utilisateur devient une enquête impossible.
Un agent IA est un logiciel comme un autre : il se teste, se surveille et se maintient. La part de magie s'arrête à la démonstration.
Si vous avez un prototype qui fonctionne et que vous hésitez à franchir le pas, commencez par la question la plus simple : sur combien de cas réels l'avez-vous mesuré ?
