Ce que j'aurais voulu savoir avant de déployer mon premier agent en production

La démo n'était pas le produit

La première fois que j'ai déployé un agent IA devant de vrais utilisateurs, je pensais surtout au modèle, au prompt et à l'orchestration. La démo fonctionnait. L'agent lisait une demande, décidait quoi faire, appelait un outil, rédigeait une réponse, puis justifiait son choix avec assez d'assurance pour impressionner l'équipe. J'avais passé du temps sur les cas évidents, les garde-fous, les exemples de few-shot et la couche d'intégration. Je savais qu'il restait des inconnues. Je ne savais pas encore lesquelles allaient vraiment coûter cher.

La production a déplacé le problème. Le vrai sujet était tout ce qui arrive quand l'agent quitte le notebook : données incomplètes, utilisateurs pressés, outils internes lents, conversations ambiguës, attentes contradictoires, coûts qui s'accumulent, et confiance qui peut disparaître après une seule réponse étrange. Avec le recul, j'aurais voulu entendre plus tôt que livrer un agent, ce n'est pas rendre une boucle autonome impressionnante. C'est concevoir un système que les humains peuvent comprendre, limiter, corriger et accepter dans leur travail quotidien.

Le prompt dérive sous charge réelle

Le premier piège a été la dérive de prompt. En test interne, les entrées se ressemblent. On écrit les scénarios, on sait ce que l'on veut vérifier, on corrige le prompt jusqu'à ce que les exemples passent. En production, les utilisateurs ne respectent pas cette géométrie. Ils mélangent deux demandes, oublient le contexte important, copient un e-mail trop long, utilisent leur vocabulaire métier, ou demandent une exception comme si elle était normale. L'agent reçoit alors un signal beaucoup moins propre que celui de la phase de validation, et le prompt commence à servir de compromis entre trop d'intentions.

J'ai appris à traiter le prompt comme du code exposé à la charge, pas comme une consigne stable. Il lui faut une version, des tests de non-régression, des exemples négatifs, des limites explicites et une trace de ce qui a changé. Quand une équipe modifie un prompt pour corriger un cas client sans rejouer les anciens cas, elle peut améliorer une branche et casser silencieusement trois autres comportements. C'est exactement le type de dette qui semble invisible pendant deux semaines, puis devient incompréhensible quand quelqu'un demande pourquoi l'agent répond différemment à une requête qui n'a pas changé.

Le meilleur correctif n'a pas été un prompt plus long. C'était de séparer les responsabilités : classifier l'intention, préparer les données, puis rédiger. Des sorties structurées quand il faut décider ; du texte libre seulement quand il faut communiquer. Plus l'agent porte de responsabilités dans un seul contexte, plus il devient difficile de savoir quelle partie du prompt a produit le comportement observé.

Le contexte est un budget, pas un confort

La deuxième surprise a été économique. Tant que l'on teste sur quelques dizaines de conversations, une grande fenêtre de contexte ressemble à une assurance qualité. On ajoute les instructions, l'historique, les documents, les résultats d'outils, les exemples, puis encore quelques règles parce que cela coûte moins cher que de trancher. À l'échelle, cette paresse devient une ligne de coût. Elle devient aussi une source de bruit. Un agent qui lit trop de contexte ne devient pas automatiquement plus intelligent. Il devient parfois plus hésitant, plus lent, et plus difficile à auditer.

J'aurais dû modéliser le coût par tâche dès le début : tokens d'entrée, tokens de sortie, appels d'outils, retries, échecs, fallbacks humains et latence acceptable. Un agent de production n'a pas un coût moyen abstrait. Il a un coût par workflow et par niveau de complexité. Les cas simples doivent rester simples. Les cas difficiles peuvent payer un contexte plus large, mais seulement si la valeur métier le justifie. Sinon on finit avec une architecture qui donne le même traitement coûteux à une demande banale et à une décision réellement sensible.

La bonne discipline est de couper le contexte sans couper la compréhension : récupérer moins mais mieux, résumer les historiques, garder des contrats courts entre étapes, router vers un modèle plus petit quand la tâche est mécanique, et sauver les artefacts utiles plutôt que rejouer toute la conversation. Ce travail semble moins excitant que choisir le dernier modèle, mais il détermine si l'agent peut survivre à son propre succès.

Les fallbacks ne sont pas un détail technique

Le troisième apprentissage a été brutal : un agent sans fallback explicite ment presque toujours sur sa maturité. Quand un outil échoue, quand une donnée manque, quand le modèle n'est pas sûr, quand une action est trop risquée, il faut savoir ce qui se passe. Pas en théorie. Dans l'interface. Dans les logs. Dans l'expérience utilisateur. Si le système se contente d'essayer encore, de reformuler, ou de produire une réponse plausible, il transforme un incident maîtrisable en perte de confiance.

Un bon fallback n'est pas seulement un message d'erreur. C'est une décision produit. Est-ce que l'agent demande une précision ? Est-ce qu'il passe la main à un humain ? Est-ce qu'il donne une réponse partielle ? Est-ce qu'il bloque l'action mais prépare un résumé exploitable ? Est-ce qu'il signale que la source manque ? Ces chemins doivent être conçus avant le lancement, sinon ils seront improvisés sous pression, au pire moment.

J'ai aussi appris à journaliser les fallbacks comme des signaux de roadmap. Un fallback fréquent n'est pas toujours un échec. C'est parfois la preuve que le périmètre est bien tenu. Mais s'il se répète sur une même intention utilisateur, il indique une intégration manquante, une règle mal comprise ou une donnée trop fragile. Les fallbacks sont le tableau de bord le plus honnête d'un agent en production.

Le dernier kilomètre est plus dur que le modèle

La partie que j'avais le plus sous-estimée est le dernier kilomètre : UX, confiance, monitoring, support et rythme d'amélioration. Les utilisateurs ne jugent pas un agent comme un benchmark. Ils le jugent au moment où il touche leur travail. Ils veulent savoir ce qu'il a compris, d'où vient sa réponse, ce qu'ils peuvent corriger, et ce qui se passera s'ils acceptent sa recommandation. Une réponse techniquement bonne peut échouer si elle arrive trop tard, si elle ne montre pas ses sources, ou si elle donne l'impression de prendre une décision à la place de l'utilisateur.

Le monitoring doit donc couvrir plus que la disponibilité. Je veux voir la latence par étape, les coûts par intention, les outils appelés, les documents récupérés, les refus, les escalades, les corrections manuelles, les notes utilisateur et les versions de prompt. Sans ces traces, chaque bug devient une enquête psychologique : le modèle a-t-il halluciné, la donnée était-elle mauvaise, le prompt a-t-il changé, ou l'utilisateur a-t-il demandé autre chose ? Avec ces traces, l'équipe peut améliorer le système comme un produit logiciel normal.

Ma checklist condensée aujourd'hui est simple. Définir une tâche étroite et utile. Versionner prompts, modèles et outils. Tester les cas heureux, ambigus et interdits. Calculer le coût par workflow. Prévoir les fallbacks avant le lancement. Montrer ce que l'agent sait, ne sait pas et a fait. Journaliser les décisions importantes. Revoir les traces chaque semaine avec produit et métier. Garder une sortie humaine claire. Et surtout, ne jamais confondre autonomie visible et fiabilité réelle. Un premier agent de production n'a pas besoin d'être spectaculaire. Il doit être digne de confiance quand le travail devient désordonné.