Agents IA : les 3 erreurs courantes (et leurs solutions)
C’est un constat largement partagé dans l’Hexagone : tout le monde parle d’agents, mais très peu d’organisations les déploient réellement en production. Là où les chatbots d’entreprise restent relativement simples à lancer, les agents se heurtent rapidement à des frictions techniques bien concrètes. Le problème ne vient pas de l’intelligence des modèles, désormais largement au niveau, mais de l’ingénierie et du contexte dans lesquels ils sont intégrés. Retour sur les trois principaux points de blocage, et les solutions techniques pour les lever.
1. Disposer de la bonne donnée au bon moment
Garbage in, garbage out. Si l’adage était déjà vrai pour les chatbots d’entreprise, avec les agents il devient une règle d’or. “Les LLM possèdent une grande connaissance du monde, mais ils ne vous connaissent pas, ils ne connaissent pas votre entreprise, ni les informations nécessaires pour répondre à la question”, rappelle Steve Kearns, directeur général de la Recherche chez Elastic.
Le défi se complique encore lorsqu'on réalise que toutes les requêtes ne demandent pas le même type de réponse. "Parfois, ce que vous voulez, c'est le document unique qui contient la bonne réponse. Mais parfois, je veux regarder en arrière dans le temps et demander : 'Combien de dossiers ce client a-t-il ouverts sur ce sujet ?'. C'est une requête beaucoup plus complexe où la réponse n'est pas un document, mais un nombre", explique le responsable d'Elastic. Dans le premier cas, l'agent doit retrouver un passage précis dans un PDF. Dans le second, il doit agréger des métadonnées sur plusieurs dizaines de tickets. Deux logiques de recherche complètement différentes. Si l'agent puise dans le mauvais document ou ne trouve qu'une réponse partielle, il produira une réponse fausse avec une confiance trompeuse.
Pour répondre à ce défi, Elastic mise sur la recherche hybride. L'idée : ne pas se contenter de chercher les mots-clés exacts, mais combiner recherche lexicale et recherche vectorielle pour capter le sens de la requête. "Je pourrais écrire 'oil' (pétrole) et vouloir dire 'gas' (essence). Dans le contexte, je peux dire qu'ils signifient la même chose, alors que 'cooking oil' (huile de cuisson) est très différent de l'essence", illustre Steve Kearns. Et ici, la qualité des modèles d'embedding devient aussi déterminante que celle du LLM lui-même. "Le LLM est important pour orchestrer les outils à utiliser, mais pour extraire la meilleure réponse de vos données, les modèles d'embedding sont un pilier critique de votre réussite", insiste-t-il.
Concrètement si vous ne traitez que du texte, privilégiez un modèle d'embedding compact et rapide plutôt qu'un multimodal plus lourd. En revanche, pour ces agents multilingues (anglais / français, par exemple), optez pour un modèle unique qui couvre toutes vos langues. "Avoir un modèle d'embedding textuel multilingue unique est très efficace. Cela fonctionne même mieux que des modèles par langue unique", affirme Steve Kearns.
2. De la bonne gestion de la fenêtre de contexte
Une fois la bonne donnée récupérée, encore faut-il la faire entrer dans la fenêtre de contexte du LLM sans tout casser. Car si les fenêtres de contexte ont explosé en taille ces derniers mois (certains modèles affichent désormais des millions de tokens), elles restent limitées, coûteuses, et surtout sujettes à des phénomènes de dégradation. "Le volume de données entrant dans la fenêtre de contexte doit être maîtrisé", prévient Steve Kearns. Trop d'informations provoque le phénomène dit du "Lost in the Middle." Le modèle perd littéralement de l'information noyée au milieu d'un contexte surchargé.
"Si vous avez une mauvaise pertinence, vous êtes obligé d'apporter plus de données et de laisser le LLM essayer de trier ce qui est pertinent", résume le responsable d'Elastic. Résultat : des réponses plus lentes, plus coûteuses, et souvent moins fiables. Le problème s'aggrave au fil d'une conversation longue, où l'historique de l’agent s'accumule et finit par saturer la fenêtre disponible.
La première règle pour éviter la saturation : ne pas envoyer de contexte inutile. "N'apportez pas de contexte qui n'est pas nécessaire", martèle Steve Kearns. Si la pertinence de la recherche est bonne en amont, la quantité de données à injecter diminue drastiquement. "Je reprends, l’exemple du dossier client. Si je peux vous donner une réponse qui est un seul chiffre, soudainement la fenêtre de contexte ne fait qu'un caractère de long. Mais si je vous donnais tous les tickets des sept dernières semaines, cela pourrait représenter des dizaines de milliers de tokens", détaille le spécialiste.
L'autre levier consiste à construire une couche sémantique qui injecte des métadonnées sur l'utilisateur et l'entreprise directement dans le system prompt : département, historique des cinq dernières questions, structure des données disponibles. Une sorte de "connaissance résumée" qui oriente le modèle sans surcharger le contexte à chaque tour de conversation.
3. Une gouvernance simple augmente la précision et réduit les risques
Un agent qui ne fait que répondre à des questions reste un chatbot amélioré. La vraie valeur des agents réside dans leur capacité à agir. Mais cette autonomie ouvre deux risques majeurs. Le premier est celui de l'accès : l'agent pourrait consulter ou manipuler des données auxquelles l'utilisateur n'a pas le droit d'accéder. Le second est celui de l'erreur de jugement : face à une boîte à outils trop large, le modèle peut choisir le mauvais outil ou l'utiliser de manière inappropriée. "Plus vous fournissez d'outils, plus le modèle a du mal à choisir le bon", prévient Steve Kearns. Ces deux risques suffisent à paralyser les projets en production.
La solution passe par un principe de sécurité simple mais non négociable, l'agent doit toujours agir avec les permissions strictes de l'utilisateur humain qui lui parle. "La seule réponse correcte est d”utiliser les même droits stricts de l'utilisateur humain", insiste Steve Kearns. Pas de "super-droits", pas de compte système omnipotent. La seconde règle : limiter la boîte à outils. "Pour chaque agent, vous devez être très réfléchi sur les outils que vous fournissez", poursuit-il. Plutôt qu'un agent généraliste avec cent outils disponibles, mieux vaut créer des agents spécialisés avec un accès aux seuls outils nécessaires à leur mission.
La confiance, le point clé de l’adoption à l’échelle
Au final, le choix entre GPT-5.2, Claude 4.5 ou Gemini 3 (par exemple) importe peu si l'architecture autour du modèle est bancale. La réussite des agents en production se joue dans l'ingénierie des données et du contexte. "La confiance des utilisateurs est dure à gagner mais facile à perdre. Si l'agent IA répond faux avec assurance trop souvent, vos utilisateurs perdront confiance et iront faire le travail manuellement", rappelle Steve Kearns. Une seule erreur affichée avec aplomb suffit à détruire des semaines de développement.
C'est pourquoi l'architecture technique doit viser la robustesse avant la complexité. Anthropic l'a parfaitement compris avec Claude Code, son agent de code qui figure parmi les meilleurs du marché : tout est dans le scaffold, dans l'ingénierie du contexte qui entoure le modèle. Ne commencez pas par choisir le LLM le plus puissant. Commencez par construire une infrastructure solide de récupération de données, une gestion intelligente du contexte, et une gouvernance stricte des outils. C'est là que se joue la différence entre un POC et un agent en production.