Bâtir des agents IA qui survivent à la production

La plupart des démos d’agents fonctionnent. La plupart des agents qu’on m’appelle pour réparer fonctionnaient aussi, en démo. L’écart, ce n’est presque jamais le modèle : ce sont les outils, le contexte, les evals manquantes, et le fait que personne ne pouvait voir ce que l’agent avait fait le jour où tout a dérapé.

C’est ce que je passe en revue avec les équipes avant que leur premier agent parte en production. C’est volontairement agnostique : les idées tiennent peu importe le SDK ou le modèle choisi.

Première question : avez-vous vraiment besoin d’un agent?

Un agent, c’est un modèle qui décide, étape par étape, quel outil appeler ensuite, jusqu’à ce qu’il décide qu’il a fini. Cette autonomie est tout l’intérêt et tout le coût : chaque décision est une décision que vous ne pouvez pas entièrement prévoir, tester ni budgéter d’avance.

Trois formes, de la plus simple à la plus autonome. Un seul appel au LLM : une entrée, une sortie. Workflow : vous pouvez dessiner les étapes sur un tableau blanc, donc le code contrôle le flux et le modèle s’occupe des parties floues. Agent : le chemin dépend réellement de ce qu’on découvre en cours de route.

🎮 Agent, workflow ou simple appel au LLM?

1 / 9 · Pointage: 0

Choisissez la forme la plus simple qui fait le travail.

Un seul appelWorkflowAgent

Suivant →

/ 9

↺ Recommencer

La boucle de base

Enlevez les frameworks et chaque agent a les mêmes parties : un modèle qui décide, des outils qu’il peut utiliser, le contexte qu’il voit, une condition d’arrêt, et des garde-fous autour de tout ça.

1. 📥Bâtir le contexteTâche, instructions, connaissances pertinentes, historique jusqu'ici.
2. ↓→
3. 🧠Le modèle décideRéponse finale, ou quels outils appeler.
4. ↓→
5. 🛠️Exécuter les outilsValider, vérifier l'approbation, exécuter avec un délai maximal.
6. ↓→
7. 📝Tracer et ajouterTracer l'étape, nettoyer le résultat, compacter au besoin.

↺ Recommencer jusqu'à une réponse finale, ou jusqu'à épuisement du budget d'étapes ou de coût

Voici la même boucle en pseudocode agnostique :

function run_agent(task, tools, limits):
    context = build_initial_context(task)
    steps = 0
    cost = 0

    loop:
        if steps >= limits.max_steps or cost >= limits.max_cost:
            return stop("budget_exceeded", context)

        decision = model.decide(context, tools.descriptions)
        trace.record(step=steps, input=context, output=decision)
        cost += decision.cost
        steps += 1

        if decision.type == "final_answer":
            return validate_and_return(decision.answer)

        for call in decision.tool_calls:
            if not tools.exists(call.name):
                result = error("Unknown tool: " + call.name)
            else if requires_approval(call):
                result = request_human_approval(call)   # may pause the run
            else:
                result = tools.execute(call, timeout=limits.tool_timeout)

            trace.record(step=steps, tool=call, result=result)
            context = append(context, call, sanitize(result))

        context = compact_if_needed(context)

Regardez tout ce qu’il y a à part l’appel au modèle : budgets stricts, tracing, étape d’approbation, nettoyage, compaction. Ce sont ces lignes-là qui séparent un agent de production d’une démo.

Concevoir les outils

D’après mon expérience, c’est ici que la qualité d’un agent se gagne ou se perd. Le modèle ne peut pas être meilleur que les actions que vous lui donnez et les descriptions que vous écrivez pour elles.

Décrivez vos outils comme si vous accueilliez un nouvel employé : ce que fait l’outil, quand l’utiliser, quand ne pas l’utiliser, le sens de chaque paramètre, les unités et les limites. « Retourne jusqu’à 50 commandes, les plus récentes en premier. Utilisez since pour remonter plus loin » évite au modèle de deviner.

Gestion du contexte

Le contexte, c’est tout ce que le modèle voit au moment de décider. Les modèles deviennent pires, pas meilleurs, quand vous les noyez. Je le vois en quatre couches :

1. Instructions stables : rôle, règles, format de sortie, ce qui est interdit. Courtes et précises.
2. Tâche : l’objet de cette exécution.
3. Connaissances pertinentes : documents récupérés, fiche client, extraits de politiques.
4. Historique de travail : les appels d’outils et leurs résultats jusqu’ici.

Récupération (retrieval) : ne préchargez pas tout. Gardez ce que vous injectez court et sourcé, et testez la récupération isolément : si le bon document n’est pas récupéré, aucun prompt ne réparera la réponse.

La mémoire entre les exécutions est puissante et risquée, parce que l’information erronée persiste et s’accumule. Stockez-la explicitement, rendez-la consultable et permettez aux humains de la corriger ou de la supprimer.

Garde-fous et humain dans la boucle

Le prompt est une demande; les garde-fous sont une contrainte. « Ne jamais rembourser plus de 500 $ » dans le prompt système, c’est un souhait. Un outil de remboursement qui rejette les montants de plus de 500 $, c’est un garde-fou.

Mettez les limites dans le code des outils, dans les accès (moindre privilège, limité à l’utilisateur ou au client) et dans la validation de la sortie finale. Ensuite, classez chaque outil selon le risque :

Risque	Exemples	Par défaut
Lecture	Chercher de l’information	En libre accès, dans les limites de débit et les règles d’accès aux données
Écriture réversible	Brouillons, notes internes, étiquettes	Automatisée une fois que les evals montrent que c’est fiable
Irréversible ou externe	Courriels aux clients, argent, suppressions, permissions	Approbation humaine, au moins au lancement

Une étape d’approbation fonctionne seulement si le réviseur voit exactement ce qui va se passer (le vrai courriel, le vrai montant), pourquoi, et peut approuver, rejeter ou modifier. Si les réviseurs approuvent tout sans lire, l’étape est devenue du théâtre.

Évaluation

S’il y a une seule chose à retenir : ne livrez pas un agent sans jeu d’evals, et ne changez pas un prompt ou un modèle sans le rouler.

1. 1

   Rassembler de vrais cas

   Commencez avec 20 à 50 exemples réels tirés de tickets, de demandes historiques et de traces. Incluez les cas faciles, fréquents et laids.

2. 2

   Définir ce qui est bon

   Parfois une réponse exacte. Plus souvent des critères : bons outils appelés, aucune action interdite, bon montant, bonne politique citée.

3. 3

   Noter de façon déterministe d'abord

   La sortie se parse-t-elle? A-t-il appelé issue_refund à tort? Moins de N étapes? Rapide, pas cher, sans dérive.

4. 4

   Rouler avant chaque changement

   Prompt, description d'outil, récupération ou modèle : roulez le jeu au complet, comparez avec la baseline, regardez quels cas ont bougé. Roulez chaque cas plusieurs fois.

5. 5

   Le faire grossir sans arrêt

   Chaque échec en production devient un nouveau cas d'eval.

Pour les sorties ouvertes, vous utiliserez probablement un LLM comme juge. Traitez-le comme une composante qui a besoin de sa propre validation :

• Calibrez-le avec des humains. Faites noter un échantillon par des personnes et vérifiez que le juge est d’accord assez souvent pour qu’on s’y fie.
• Donnez-lui une grille précise. « Note la qualité de 1 à 10 », c’est du bruit; « Indique-t-elle le montant du remboursement? », c’est du signal.
• Surveillez les biais connus, comme la préférence pour les réponses plus longues ou la première option. Mélangez l’ordre.
• Figez la version du juge, sinon vous prendrez un changement du juge pour un changement de l’agent.

🧠 Outils et evals : testez-vous

Pointage: 0 / 6

1. 1. Quel outil est le plus facile à tester et à encadrer par des permissions?

   run_sql(query)get_customer_orders(customer_id, since)manage_data(mode, payload)

   Il fait une seule chose avec des entrées typées. Les requêtes arbitraires et les paramètres mode sont difficiles à tester et à limiter.

2. 2. L'agent a passé un ID client inconnu. Quelle erreur aide le plus?

   500 Internal Server ErrorErreur : introuvableID client introuvable. Les ID ressemblent à CUS-12345; utilisez search_customers pour le trouver par courriel.

   Elle dit ce qui s'est passé et quoi essayer ensuite, pour que le modèle se rattrape au lieu de tourner en rond.

3. 3. Où faut-il imposer « ne jamais rembourser plus de 500 $ »?

   Dans le prompt systèmeDans l'outil de remboursement, qui rejette les montants plus élevésDans la description de l'outil

   Les prompts sont des demandes. Le code et les accès sont une contrainte.

4. 4. Vous avez retouché la description d'un outil. Que faites-vous avant de merger?

   Essayer deux exemples à la mainRouler le jeu d'evals au complet et comparer quels cas ont changé par rapport à la baselineLivrer et surveiller le dashboard

   Une petite modification peut corriger trois cas et en briser cinq autres en silence.

5. 5. Les agents ne sont pas déterministes. Comment rouler chaque cas d'eval?

   Une fois, et se fier au résultatPlusieurs fois, en regardant le taux de réussiteSeulement s'il a échoué la dernière fois

   Une seule exécution dit peu de choses. Les taux de réussite montrent si un changement a vraiment aidé.

6. 6. Les scores de votre juge LLM ont bondi, mais vous n'avez rien changé. Cause probable?

   L'agent s'est amélioré tout seulLe modèle juge a changéLe jeu d'evals est trop gros

   Figez la version du juge, sinon ses changements ressemblent à des changements de l'agent.

↺ Recommencer

Observabilité

Quand un agent fait quelque chose de travers en production, la première question est : « Qu’est-ce qu’il a réellement fait? » Si vous ne pouvez pas y répondre en quelques minutes, vous n’êtes pas prêt à lancer.

Tracez chaque étape sous un même ID d’exécution : l’entrée, chaque appel au modèle (contexte et décision), chaque appel d’outil avec arguments et résultats, les approbations, la sortie finale, les erreurs, et les versions du prompt et du modèle. Les traces contiennent des données clients : appliquez les mêmes règles de rétention, d’accès et de caviardage que pour les systèmes sources.

Suivez le coût, la latence et le nombre d’étapes par exécution, par étape et par outil, et regardez la distribution : c’est dans la queue coûteuse que se cachent les boucles. Un budget qui vit seulement dans un dashboard n’arrête rien à 3 h du matin; imposez-le dans la boucle.

Captez la rétroaction (pouces, approbations rejetées, brouillons modifiés, escalades) et reliez-la à la trace. C’est votre principale source de nouveaux cas d’eval.

Les modes de défaillance à prévoir

Aucun n’est exotique. Retournez chaque carte pour voir les défenses.

🃏 Les quatre défaillances que je vois le plus

Touchez une carte pour la retourner

🔁 Les bouclesLe même appel, encore et encore. Défenses : plafonds d'étapes et de coût, détection des répétitions, erreurs qui suggèrent la suite, une façon de dire « je ne peux pas ».🔧 La mauvaise utilisation des outilsMauvais arguments, ou mauvais outil parce que les descriptions se chevauchent. Défenses : validation stricte, descriptions distinctes, evals sur le choix d'outil.💉 L'injection de prompt par les sorties d'outilsUn courriel, une page ou un ticket lu par l'agent peut contenir des instructions. Traitez-les comme non fiables, encadrez les actions sensibles, limitez l'impact.📉 La dérive silencieuse de la qualitéRien ne plante; ça devient juste moins bon. Figez les versions de modèle, roulez les evals selon un horaire, échantillonnez la production.

Le déploiement

Je recommande rarement un lancement d’un seul coup.

1. 1

   Étape 1

   Mode fantôme (shadow)

   Roule sur de vraies entrées; les sorties ne vont nulle part. Comparez-les à ce que les humains ont fait.

2. 2

   Étape 2

   Mode assistant

   L'agent rédige; un humain révise et envoie tout.

3. 3

   Étape 3

   Autonomie partielle

   Les actions à faible risque s'exécutent automatiquement; les risquées exigent encore une approbation.

4. 4

   Étape 4

   Élargissement

   Élargissez la portée seulement quand les evals et les données de production le justifient.

Gardez un kill switch à chaque étape. Pour les leads qui approuvent : Qu’est-ce qu’il peut faire sans humain? Quelle est la pire action possible, et qu’est-ce qui l’en empêche? Comment saura-t-on qu’il se dégrade? Qui lit les traces, et à quelle fréquence?

Checklist de lancement

✅ Avant la mise en production de l'agent

0 / 34 complété

• Portée : on a confirmé, avec de vrais exemples, qu'un seul appel ou un workflow ne suffit pas.
• Portée : le rôle de l'agent, et ce qui est hors portée, sont écrits noir sur blanc.
• Portée : l'escalade vers un humain est un résultat défini et testé.
• Outils : chacun fait une seule chose et a une description claire, y compris quand ne pas l'utiliser.
• Outils : ceux qui modifient un état sont idempotents ou protégés contre les appels en double.
• Outils : les valeurs par défaut sont sécuritaires (petites pages, brouillons, dry-runs).
• Outils : les erreurs disent ce qui s'est passé et quoi essayer ensuite.
• Outils : les sorties sont réduites à ce dont le modèle a besoin.
• Contexte : les instructions système sont courtes et précises.
• Contexte : la récupération a été testée isolément.
• Contexte : les longues exécutions sont compactées sans perdre la tâche ni les contraintes.
• Contexte : la mémoire entre les exécutions, s'il y en a, est consultable et corrigeable.
• Garde-fous : les limites strictes vivent dans le code et les accès, pas seulement dans le prompt.
• Garde-fous : moindre privilège, limité à l'utilisateur ou au client.
• Garde-fous : les actions irréversibles et externes exigent une approbation humaine.
• Garde-fous : les demandes d'approbation montrent exactement ce qui va se passer.
• Garde-fous : les sorties finales sont validées avant d'être utilisées.
• Sécurité : toute sortie d'outil est traitée comme non fiable.
• Sécurité : l'injection de prompt est testée par chaque canal d'entrée que l'agent lit.
• Sécurité : le rayon d'impact d'une injection réussie est compris et acceptable.
• Evals : un jeu d'evals bâti à partir de vrais cas existe, incluant des cas difficiles et adverses.
• Evals : des vérifications déterministes sont utilisées partout où c'est possible.
• Evals : tout juge LLM est calibré avec une notation humaine.
• Evals : elles roulent avant chaque changement de prompt, d'outil, de récupération ou de modèle.
• Evals : elles roulent aussi selon un horaire pour détecter la dérive.
• Observabilité : chaque exécution est tracée de bout en bout sous un même ID, avec les versions du prompt et du modèle.
• Observabilité : le coût, la latence et le nombre d'étapes sont suivis par exécution, avec des alertes.
• Observabilité : des plafonds stricts d'étapes et de coût sont imposés dans la boucle.
• Observabilité : les traces respectent nos règles de rétention et d'accès aux données.
• Observabilité : la rétroaction des utilisateurs et des réviseurs est captée et reliée aux traces.
• Opérations : il y a un kill switch et un plan de repli manuel.
• Opérations : le déploiement est progressif (fantôme, assistant, autonomie partielle).
• Opérations : quelqu'un est responsable de réviser les traces et les échecs, à une fréquence établie.
• Opérations : les échecs en production deviennent de nouveaux cas d'eval.

↺ Réinitialiser