Agentic AI en production : 7 pièges cachés que les devs ne voient pas

Les agents IA sont partout. Vous les avez vus dans les démos : un LLM qui appelle des APIs, réfléchit, se corrige, et livre des résultats. Magique. Mais entre la démo Jupyter et la production qui gère 100K requêtes/jour, il y a un gouffre. Et ce gouffre est rempli de bugs vicieux que personne ne vous dit jusqu'à 3h du matin quand votre système dépense $50K/jour en tokens inutiles.

J'ai vu les pièges. J'ai marché dedans. Voici les 7 qui vous coûteront le plus cher si vous les ignorez.

1. L'hallucination n'est pas un bug, c'est une feature

Vous avez testé votre agent sur 10 exemples en local. Il a marché 9 fois. Vous le mettez en prod. Il invente des données.

Pas juste des petites erreurs — des hallucinations confiantes et détaillées. Un agent qui cherche une commande cliente peut inventer un numéro de commande et un prix, et le présenter comme factuel. L'utilisateur y croit. Vous perdez confiance.

Le problème : les LLM n'ont aucune notion de différence entre "je sais" et "je suis en train d'inventer quelque chose qui sonne plausible". Et en production, avec des données variées, des contextes nouveaux, et une pression d'offrir une réponse immédiate, les hallucinations explosent.

La piège réelle : Vous testez avec des données parfaites. Les données réelles sont du chaos — données manquantes, doublons, formats incohérents. Quand l'agent ne trouve pas ce qu'il cherche, au lieu de dire "je ne sais pas", il invente.

Comment l'éviter : Contraignez l'agent à sourcer ses réponses. Si un LLM dit "le client a payé $500 le 15 mars", forcez-le à montrer la ligne exacte dans la base de données d'où il tire cette info. Utilisez des retrieval augmented generation (RAG) sérieux — pas juste une recherche sémantique vague. Et loggez chaque hallucination détectée pour pouvoir la rejouer et comprendre où votre agent s'est cassé la gueule.

2. Les timeouts en cascade qui réduisent votre agent en miettes

Un agent fait normalement ça :

Appelle l'API client (2s)
Traite la réponse (1s)
Appelle l'API commande (3s)
Fusion logique (1s)
Retour utilisateur

Total : 7 secondes. Acceptable.

Mais en production :

API client timeout après 15s (erreur réseau transient)
Agent retry automatique (15s de plus)
API commande ne répond pas (30s)
LLM refléchit sur l'erreur (12s de tokens pour générer "hmm, ça n'a pas marché")
Votre user-facing timeout arrive à 60s → request killed

Pire : vous avez 10 agents qui font la même chose en parallèle. Soudain tous appellent l'API client en même temps à cause d'une spike. L'API timeout. Tous les 10 agents reessaient. C'est 100 appels maintenant. Ça cascade. L'API crash.

La piège réelle : Les agents adorent faire du "work", et "work" = appels API. Vous n'avez pas de budget timeout par étape, donc un agent peut brûler 50 secondes en retries muets, puis votre timeout global déguise ça en "erreur aléatoire".

Comment l'éviter : Imposez un budget timeout strict par action, pas par requête entière. Un appel API : 5s max (retries inclus). Si l'agent doit faire 3 appels en série, son budget total est 15s, pas 60s. Utilisez un circuit breaker : après 3 échecs d'une API, l'agent ne la rappelle pas pendant 30 secondes, il utilise une fallback value ou il avoue "je ne peux pas". Loggez chaque timeout : quelle action, combien de retries, durée réelle.

3. L'explosion du context window (et la perte d'argent associée)

Vous créez un agent pour analyser des conversations client. Vous lui donnez le contexte système :

Vous êtes un support AI expert. Voici les politiques de l'entreprise [4000 tokens]. Voici les scripts de réponse [3000 tokens]. Voici l'historique client [5000 tokens]. Voici la requête [100 tokens].

Total : 12K tokens d'input. À $0.5/1M tokens sur Claude, ça semble gratuit. Mais vous avez 1000 conversations/jour. C'est 12K tokens × 1000 = 12M tokens/jour = $6/jour. Sur un mois, c'est $180 juste pour du contexte que vous réutilisez.

Maintenant vous écalez : Vous avez besoin du contexte plus riche. Vous ajoutez l'historique des 10 dernières conversations de ce client. C'est maintenant 20K tokens par requête. $10/jour. $300/mois.

Et quand vous switchez à un modèle plus grand (Claude Opus = $15/1M tokens input au lieu de $3), vous doublez vos coûts sans rien changer au code.

La piège réelle : Vous ne prévisionnez pas les coûts tokens. Vous apprenez quand c'est trop tard. Et entre-temps, vous avez lancé 3 agents de plus qui font la même chose.

Comment l'éviter : Avant de déployer, calculez token_count × requêtes/jour × coût/token. Si c'est > $5/jour, you've got a problem. Utilisez la compression de contexte : au lieu de passer l'historique entier du client, créez un résumé encodé mis à jour à chaque interaction (créé une fois, réutilisé 100 fois). Utilisez des system prompts courts : 500 tokens max, pas 10K. Stockez le contexte riche en cache (si votre provider le support — Claude a le prompt caching) pour payer une seule fois.

4. Les feedback loops toxiques qui se nourrissent d'elles-mêmes

Vous déployez un agent qui reçoit du feedback utilisateur : "Bonne réponse" ou "Mauvaise réponse". Vous l'entraînez à apprendre du feedback. Intelligent, right?

Mais voici ce qui se passe :

L'agent donne une réponse médiocre au User A
User A clique "Mauvais" par erreur (il pensait cliquer ailleurs)
L'agent met à jour : "Oh, ce genre de réponse est mauvais"
Maintenant il arrête de faire ce genre de réponse
User B reçoit une réponse différente, plus mauvaise
User B clique "Mauvais"
L'agent continue de diverger

Après 1000 clics, le modèle a dérivé loin de ce qu'il savait faire. Il est devenu plus bête, pas plus malin.

La piège réelle : Un seul utilisateur malheureux ou un bot malveillant peut poisonner le feedback. Vous n'avez pas de validation — le feedback est reçu tel quel. Et une fois que l'agent a dérivé, c'est dur de le ramener en arrière sans tout remettre à zéro.

Comment l'éviter : Ne faites jamais d'apprentissage en ligne naïf sur le feedback utilisateur. Ou du moins, pas sans validation. Colletez le feedback, mais entraînez hors-ligne en batch : une fois par semaine, un humain review les 100 derniers feedbacks, rejette les mauvais signaux, puis l'agent est mis à jour et vous mesurez si ça s'est amélioré globalement. Loggez le feedback source : quel utilisateur, quel contexte, quelle réponse. Gardez une baseline de référence que vous pouvez toujours restaurer si ça vire bizarre.

5. Les coûts imprévisibles qui explosent sans signe d'alerte

Vous avez budgété $1K/mois pour votre agent. Tout va bien. Puis un jour :

Un utilisateur lance une requête qui fait boucler l'agent (il appelle la même API 50 fois en 1 seconde)
Ou un script d'attaque teste votre agent avec 1000 requêtes parallèles
Ou une mise à jour du LLM rend le modèle plus verbose, et chaque réponse coûte 2x plus de tokens
Ou vous avez une fuite de session : un utilisateur est connecté depuis une semaine, et l'agent balance 100K tokens par jour rien que pour lui

Soudain vous êtes à $10K/mois. Sans même le savoir avant la facture.

La piège réelle : Les coûts des LLM ne sont pas linéaires. Ils dépendent du modèle, de la longueur d'entrée/sortie, du temps de la journée (certains providers changent les prix), et du volume en parallèle. Vous n'avez aucune visibilité jusqu'à la fin du mois.

Comment l'éviter : Installez une alerting sur les tokens spendus par requête et par utilisateur. Si une seule requête coûte > 10x la médiane, log et alerte. Si un utilisateur a dépensé > $100 ce mois, flag-le. Utilisez un rate limiter : max 100K tokens par utilisateur par jour. Audite les requêtes coûteuses une fois par semaine. Maintenez un budget par feature : si l'agent "customer support" dépassse $500/mois, vous arrêtez ou vous refactorisez.

6. L'état distribué qui diverge entre les instances de l'agent

Vous scalez votre agent sur 5 serveurs. Chaque serveur a une copie du "memory" de l'agent — une liste de facts qu'il a appris.

Requête 1 arrive sur le serveur A, l'agent apprend un fact et le stocke localement. Requête 2 arrive sur le serveur B, qui n'a pas ce fact. L'agent fait une décision différente. Requête 3 revient au serveur A. L'agent pense que le fact existe, mais le serveur C l'a oublié.

Maintenant vous avez 5 "vérités" différentes de ce que l'agent sait. Elles divergent. Les utilisateurs voient des réponses incohérentes.

La piège réelle : Les agents n'aiment pas être stateless. Ils veulent apprendre, mémoriser, accumuler du contexte. Mais distribué, c'est un cauchemar. Vous avez le choix entre "agent stupide mais cohérent" (stateless) ou "agent malin mais divergent" (stateful distribué).

Comment l'éviter : Faites les agents stateless. Tout l'état doit être dans une base de données centralisée avec une seule source de vérité. Si l'agent apprend quelque chose, il l'écrit immédiatement en DB avec un lock, pas en mémoire. Si l'agent doit se souvenir de contexte, c'est stocké dans Redis ou Postgres, pas en RAM. Acceptez la latence : une requête DB en plus ne tue personne si ça évite la divergence.

7. L'observabilité qui n'existe pas quand vous en avez besoin

Un agent produit une réponse bizarre. Vous voulez savoir pourquoi. Mais il n'y a aucun log de ses pensées, aucune trace de ce qu'il a décidé, aucune raison.

Vous avez juste : "Input : [...] Output : [...] Duration: 5s"

Mais vous ne savez pas :

Quels outils l'agent a appelé
Dans quel ordre
Quels inputs il leur a donné
Quelles erreurs il a reçues
Comment il a changé d'avis après une erreur
Pourquoi il a choisi cette action finale plutôt qu'une autre

Debugging un agent est 100x plus dur que debugger du code normal. Le code dit ce qu'il fait. L'agent pense out loud et vous ne l'écoutez pas.

La piège réelle : Vous déployez en confiance. Puis ça bug. Et vous êtes blind. Vous rejouez la requête 50 fois à la main pour essayer de reproduire. L'agent fait quelque chose de différent chaque fois (il est non-déterministe). Vous êtes stuck.

Comment l'éviter : Loggez chaque action de l'agent. Pas juste l'entrée et la sortie. Chaque appel tool : quel tool, inputs, output, latence, erreur. Loggez aussi les "thoughts" du LLM (si vous l'utilisez en mode chain-of-thought). Créez une trace format structuré (JSON) que vous pouvez rejouer. Stockez l'historique complet de chaque requête : vous devriez pouvoir reconstruire exactement ce qu'il a fait. Et quand il y a un bug, vous devez pouvoir linker : "requête X échouée → agent fit action Y → appel Z timeout". Un bon système de tracing (ex: Langsmith, if using Langchain) est non-optionnel. C'est aussi important que votre log aggregation normale.

Conclusion : Agentic AI n'est pas magique, c'est juste compliqué

Les agents IA peuvent faire des choses impressionnantes. Mais en production, ils ne sont pas des automates fiables — ce sont des systèmes chaotiques avec des edge cases cachés. Le coût de ignorer ces 7 pièges est mesuré en argent perdu, données fausses, et 3h du matin à debug.

Voici le plan d'action :

Avant le déploiement, stress-test avec du chaos : données malformées, APIs qui timeout, feedback mauvais. Vérifiez comment l'agent degrades.
Mettez en place la monitoring token/coût dès le jour 1. Pas après.
Testez sur un petit subset d'utilisateurs pendant 2 semaines. Changez rien au code pendant ce temps. Juste observe.
Loggez tout. Traçabilité complète. C'est non-négociable.
Gardez une fallback simple et stupide. Si l'agent échoue (ou coûte trop cher), switchez à une réponse statique ou redirection humain. Pas de cascade.

Faites ça, et vous éviterez 80% de la souffrance. Les 20% restants? C'est la morale de chaque système distribué : quelque chose va toujours échouer d'une façon que vous ne prévoyiez pas. Mais avec une bonne observabilité et des budgets, vous le trouverez avant que ça coûte trop cher.

Bienvenue en production.