Les démos d’agents sont impressionnantes. Vous montrez une tâche à l’agent, il la décompose, appelle les bons outils, traite les réponses et livre un résultat. Les parties prenantes applaudissent. Les investisseurs hochent la tête. Votre équipe se sent bien.
Puis vous déployez.
Les agents en production sont humiliants. Les vrais utilisateurs ne suivent pas de script. Ils envoient des requêtes vagues, changent d’avis en pleine tâche et trouvent des cas limites que vous n’aviez jamais imaginés. L’agent qui semblait brillant en démo commence à envoyer les mauvais courriels, supprimer les mauvais fichiers et exécuter avec assurance exactement ce que personne n’a demandé.
L’écart entre la démo et la production n’est pas une question de technologie sous-jacente. C’est la différence entre des conditions contrôlées et le chaos. Cet article couvre ce qui fait que les agents fonctionnent vraiment quand de vrais utilisateurs les touchent.
Pourquoi les agents de démo échouent en production
Les utilisateurs ne suivent pas le script
En démo, vous préparez des requêtes parfaites. « Réserve une rencontre avec John mardi prochain à 14 h pour discuter de la feuille de route Q3. » Clair. Complet. Sans ambiguïté.
En production, vous recevez « fais le truc » et « peux-tu t’occuper de ce courriel de tantôt » et « organise quelque chose avec l’équipe dans le courant de la semaine prochaine j’imagine. »
Les vrais utilisateurs présument un contexte que vous n’avez pas. Ils font référence à des conversations d’il y a trois jours. Ils utilisent des pronoms sans antécédent. Ils se contredisent dans un seul message.
Les agents qui fonctionnent en production gèrent l’ambiguïté avec grâce. Ils posent des questions de clarification quand c’est nécessaire. Ils font des hypothèses raisonnables et les énoncent explicitement. Ils ne devinent pas sur les décisions importantes.
Les appels d’outils ont des conséquences réelles
Les environnements de démo sont isolés. Les API simulées retournent des réponses prévisibles. Rien ne se passe vraiment quand l’agent « envoie » un courriel ou « crée » un événement de calendrier.
La production, c’est différent. Ce courriel part à une vraie personne. Cette invitation bloque du vrai temps. Cette écriture en base de données modifie de vraies données. Cet appel API coûte du vrai argent.
Un seul mauvais appel d’outil peut être catastrophique. Un agent qui envoie avec assurance un courriel agressif à votre plus gros client n’est pas un bug qu’on corrige discrètement. Un agent qui supprime des données de production n’est pas quelque chose qu’on annule avec un git revert.
« Oups » n’est pas un message d’erreur acceptable quand les conséquences sont réelles.
Les workflows multi-étapes amplifient les erreurs
Voici un calcul qui devrait vous inquiéter : si chaque étape d’un workflow a un taux de succès de 95 %, un workflow en 5 étapes ne réussit que 77 % du temps. Un workflow en 10 étapes ? 60 %.
Et ça suppose que les erreurs sont indépendantes. En réalité, les erreurs précoces cascadent. L’agent interprète mal l’étape 2, et maintenant les étapes 3 à 10 travaillent à partir d’une prémisse viciée. Le résultat final n’est pas juste 5 % erroné — il est complètement faux d’une façon qui semblait correcte à chaque étape individuelle.
Les workflows autonomes complexes ont besoin de correction d’erreurs à chaque étape, pas seulement à la fin.
Les limites de contexte arrivent plus vite qu’on pense
Les longues conversations remplissent la fenêtre de contexte. L’agent qui se souvenait parfaitement de vos préférences à la première minute les a oubliées à la trentième. Les utilisateurs s’attendent à une continuité que vous ne pouvez pas fournir.
La synthèse semble être la solution, mais les résumés perdent des détails. Le détail qui semblait anodin au moment de la synthèse s’avère critique trois tours plus tard. L’agent est maintenant confiant mais dans l’erreur parce qu’il ne se souvient littéralement plus de l’information qui le corrigerait.
L’architecture d’un agent de production
La recherche d’Anthropic sur la construction d’agents efficaces met en lumière un constat contre-intuitif : les agents simples battent les agents complexes.
Les agents simples battent les agents complexes
Les agents de production les plus fiables ne sont pas des systèmes autonomes sophistiqués avec des chaînes de raisonnement complexes. Ce sont des patterns simples et composables qui font des choses spécifiques bien.
Les frameworks complexes avec orchestration multi-agents et systèmes de planification élaborés ont l’air impressionnants. Ils ont aussi plus de modes de défaillance, sont plus difficiles à déboguer, et sous-performent souvent les approches plus simples sur des tâches réelles.
Commencez avec l’agent le plus simple qui pourrait fonctionner. Ajoutez de la complexité seulement quand vous avez la preuve que c’est nécessaire. La plupart du temps, vous n’en aurez pas besoin.
Codez en dur ce que vous pouvez
Toutes les décisions n’ont pas besoin du jugement d’un LLM. Si un utilisateur demande « supprime tout », ça devrait déclencher un flow de confirmation codé en dur, pas un LLM qui évalue s’il doit procéder.
Utilisez du routage déterministe pour les patterns connus. De la validation par règles avant les actions. Des garde-fous explicites qui ne dépendent pas du jugement du modèle.
Réservez le raisonnement LLM aux décisions vraiment incertaines où la flexibilité compte. Pour tout le reste, le code est plus fiable que l’inférence.
Humain dans la boucle par défaut
Les pratiques d’OpenAI pour la gouvernance des systèmes agentiques insistent sur le fait de garder les humains impliqués, surtout pour les décisions à fort enjeu.
Les actions à haut risque devraient toujours exiger une approbation. Les sorties à faible confiance devraient escalader vers un humain. Les utilisateurs devraient pouvoir demander un transfert humain à tout moment.
Ce n’est pas une limitation. C’est une fonctionnalité. Les humains attrapent des erreurs que l’agent manque. La rétroaction des humains améliore l’agent au fil du temps. Et les utilisateurs font davantage confiance aux systèmes quand ils savent qu’un humain est disponible.
Cinq contrôles essentiels pour tout agent de production
Contrôle 1 : Classification des actions
Toutes les actions ne se valent pas. Classez-les par risque :
Actions sécuritaires : lecture seule et réversibles. Chercher de l’information. Rédiger une réponse pour révision. Générer un rapport. Si ça échoue, rien de grave.
Actions risquées : création de données ou envoi de messages. Créer des événements de calendrier. Envoyer des courriels. Publier sur Slack. Les erreurs sont visibles et embarrassantes, mais généralement réparables.
Actions dangereuses : conséquences significatives. Suppression de données. Transactions financières. Actions qui affectent les clients. Les erreurs ici peuvent être catastrophiques.
Chaque catégorie a besoin d’exigences d’approbation différentes. Les actions sécuritaires peuvent procéder automatiquement. Les actions risquées peuvent nécessiter une confirmation. Les actions dangereuses exigent une approbation humaine explicite à chaque fois.
Contrôle 2 : Seuils de confiance
Votre agent devrait savoir quand il est incertain. Intégrez de l’estimation de confiance et définissez des seuils pour différents comportements.
Confiance élevée : procéder normalement. Confiance moyenne : énoncer les hypothèses explicitement, demander confirmation. Confiance faible : demander des clarifications avant de procéder. Confiance très faible : escalader vers un humain.
« Je ne suis pas certain de comprendre — pouvez-vous préciser ? » est une bien meilleure réponse que d’exécuter la mauvaise chose avec assurance.
Contrôle 3 : Limites de débit par type d’action
Combien de courriels votre agent peut-il envoyer par heure ? Combien d’écritures en base par minute ? Combien d’appels API par seconde ?
Sans limites, les agents confus entrent dans des boucles incontrôlées. Ils réessaient la même action échouée indéfiniment. Ils envoient la même notification cent fois. Ils brûlent votre budget API en quelques minutes.
Définissez des limites différentes selon le niveau de risque. Les opérations de lecture peuvent être plus libérales. Les opérations d’écriture ont besoin de contraintes plus serrées. Les opérations dangereuses ont besoin des limites les plus strictes.
Contrôle 4 : Logging exhaustif
Chaque appel d’outil devrait être journalisé avec le contexte complet. Quelle était l’entrée ? Qu’est-ce que l’agent a décidé ? Quelle était la sortie ? Quel était le raisonnement ? Quand est-ce arrivé ?
Sans logs, déboguer les problèmes de production est de la pure devinette. Avec des logs, vous pouvez retracer exactement ce qui s’est passé, comprendre pourquoi, et corriger.
Les logs permettent aussi la conformité et l’audit. Quand quelqu’un demande « pourquoi l’agent a-t-il fait ça ? », vous devez pouvoir répondre.
Contrôle 5 : Interrupteurs d’urgence
Vous avez besoin de pouvoir mettre votre agent sur pause immédiatement. Pas « après que la tâche en cours se termine. » Immédiatement.
Intégrez des capacités de rollback quand c’est possible. Si l’agent vient d’envoyer dix courriels, pouvez-vous les annuler ? S’il a créé des enregistrements, pouvez-vous les supprimer ?
Quand vous activez l’interrupteur d’urgence, avisez les utilisateurs concernés que l’agent est en pause. Ayez un processus clair pour revoir ce qui s’est passé et reprendre quand c’est prêt.
Gérer les échecs d’agents avec grâce
Quand les appels d’outils échouent
Les API externes tombent. Les bases de données expirent. Les services plantent. Votre agent doit gérer ça.
Réessayez avec un backoff, mais pas indéfiniment. Trois tentatives avec un backoff exponentiel, c’est raisonnable. Des tentatives infinies, c’est la recette pour des coûts incontrôlés et des tâches coincées.
Quand les tentatives échouent, repliez-vous sur des alternatives si elles existent. Si aucune alternative ne fonctionne, dites à l’utilisateur ce qui se passe. « Je n’ai pas pu envoyer ce courriel parce que le serveur de messagerie est en panne. Voulez-vous que je réessaie dans quelques minutes, ou préférez-vous l’envoyer manuellement ? »
Ne laissez jamais des tâches à moitié complétées sans en informer l’utilisateur.
Quand l’agent se perd
Détectez la confusion. Des actions répétées avec la même entrée signifient généralement que quelque chose ne va pas. Des sorties contradictoires en séquence suggèrent que l’agent est bloqué. Des réponses qui ne traitent pas la question de l’utilisateur indiquent une incompréhension.
Quand vous détectez de la confusion, réinitialisez le contexte avec un résumé de ce qui a été accompli et de ce qui reste en attente. Demandez à l’utilisateur de clarifier. Si ça ne fonctionne pas, escaladez vers un humain.
Quand les utilisateurs sont malveillants
Certains utilisateurs essaieront de casser votre agent. Tentatives de prompt injection. Demandes d’actions nuisibles. Astuces ingénieuses pour contourner les garde-fous.
Construisez des garde-fous en entrée et en sortie. Validez ce qui entre. Validez ce qui sort. Ne présumez pas que le jugement du modèle est suffisant pour les décisions critiques en matière de sécurité.
Quand des cas limites imprévus surgissent
Vous ne pouvez pas tout anticiper. Quand quelque chose d’inattendu arrive, journalisez tout. Dégradez gracieusement vers un processus manuel. « J’ai rencontré quelque chose d’inattendu et je n’ai pas pu terminer automatiquement. Voici ce que j’essayais de faire — pouvez-vous m’aider à finir ? »
Après l’incident, revoyez ce qui s’est passé. Corrigez le problème sous-jacent. Ajoutez le cas limite à votre suite de tests pour que ça ne se reproduise pas.
La pyramide de tests pour les agents
Tests unitaires
Testez que les fonctions individuelles d’outils marchent correctement. Les entrées sont validées. Les sorties sont formatées de façon cohérente. Les cas d’erreur retournent des réponses appropriées.
C’est du test logiciel normal. Ne le sautez pas parce que vous travaillez avec de l’IA.
Tests d’intégration
Testez que les chaînes d’outils s’exécutent de bout en bout. La sortie de l’outil A alimente correctement l’outil B. La gestion d’erreurs se déclenche quand elle le doit. Le logging capture les données attendues.
Tests adversariaux
Essayez de casser votre agent. Envoyez des tentatives de prompt injection. Donnez des entrées confuses. Demandez des choses que l’agent ne devrait pas faire.
Si vous ne testez pas les cas adversariaux, vos utilisateurs les trouveront pour vous. Mieux vaut les trouver en premier.
Tests de chaos
Que se passe-t-il quand les API externes tombent ? Quand le contexte est plein ? Avec cent utilisateurs simultanés ? Quand l’agent reçoit des instructions contradictoires ?
Les tests de chaos révèlent des modes de défaillance que vous ne trouverez d’aucune autre façon.
Patterns qui fonctionnent
L’assistant avec garde-fous
L’agent peut faire beaucoup de choses, mais les actions dangereuses sont mises en file d’attente pour approbation humaine. La plupart des requêtes sont traitées automatiquement. Les requêtes à haut risque passent par une révision humaine.
Ce pattern maximise l’automatisation tout en maintenant la sécurité. Les utilisateurs obtiennent des réponses rapides pour les tâches routinières. Les tâches risquées bénéficient d’une supervision humaine.
Le travailleur spécialisé
L’agent fait une seule chose extrêmement bien. Portée étroite. Expertise approfondie. Limites claires qui empêchent le dépassement.
Les agents spécialisés sont plus faciles à tester, plus faciles à valider, et plus fiables que les agents généralistes qui essaient de tout faire.
L’amplificateur humain
L’agent prépare, l’humain décide. La recherche et la synthèse sont automatisées. L’analyse et les recommandations sont générées. Mais les actions finales exigent une confirmation humaine.
Ce pattern capture la majorité des gains de productivité tout en gardant les humains aux commandes des décisions qui comptent.
Métriques pour les agents de production
Mesurez ce qui compte :
Taux de complétion des tâches. À quelle fréquence l’agent complète-t-il avec succès ce que les utilisateurs demandent ?
Taux d’escalade. À quelle fréquence a-t-il besoin d’aide humaine ? Trop élevé signifie qu’il n’est pas utile. Trop bas pourrait signifier qu’il n’escalade pas quand il le devrait.
Taux d’erreur par type d’action. Certaines actions échouent-elles plus que d’autres ? C’est là qu’il faut concentrer les améliorations.
Satisfaction des utilisateurs. Un simple pouce en haut/en bas sur les réponses de l’agent. Les tendances comptent plus que les valeurs absolues.
Coût par tâche réussie. Dépensez-vous efficacement ? Les coûts scalent-ils de façon appropriée avec l’utilisation ?
Temps de complétion. L’agent est-il vraiment plus rapide que les alternatives manuelles ?
Construire pour la production dès le premier jour
Les agents sont puissants. Ils sont aussi dangereux si construits sans soin. Les agents qui fonctionnent en production ne sont pas les plus sophistiqués — ce sont les plus contrôlés.
Des architectures simples avec des limites claires. Des garde-fous codés en dur pour les situations prévisibles. De la supervision humaine pour les décisions à fort enjeu. Un logging exhaustif pour le débogage. Des interrupteurs d’urgence pour les crises.
Intégrez tout ça dès le départ. Ajouter de la sécurité après coup à un système qui n’a pas été conçu pour ça est beaucoup plus difficile que de bien le construire la première fois.
L’objectif n’est pas de bâtir un système autonome qui n’a jamais besoin d’intervention humaine. C’est de bâtir un système qui gère les tâches routinières de façon fiable et sait quand demander de l’aide. C’est ça, un vrai agent de production.
Vous construisez des agents et voulez vous assurer qu’ils sont prêts pour la production ? Nous aidons les équipes à implémenter les contrôles et les patterns d’architecture qui rendent les agents fiables. Contactez-nous.