L'agent est aussi bon que le contexte qu'on lui donne

En 2023-2024, l’IA en entreprise s’est souvent résumée à un triptyque : données, recherche augmentée par récupération (RAG) et pipeline de données. En 2025-2026, le différenciateur se déplace vers le contexte : objectifs, contraintes, environnement d’action, et capacité à tenir un fil.

Table des matières

Deux visions de l’IA : nourrir un modèle ou briefer un collaborateur

Quand on parle de « la data », on pense d’abord entraînement de modèles, qualité des jeux de données et pipelines. Dans cette logique, la recherche augmentée par récupération (RAG) sert surtout à donner au modèle un accès rapide à la connaissance interne, sans réentraîner.

Le « contexte », lui, ne se limite pas à des documents. Il regroupe ce que le système doit comprendre ici et maintenant : instructions, mémoire, outils disponibles, état du monde, règles de l’entreprise et temporalité.

La bascule mentale est simple et change tout : avec la data, on optimise un moteur statistique ; avec le context, on manage un agent. Autrement dit, on cesse de se demander « quelles données lui injecter » et on commence à écrire un brief : quoi faire, pourquoi, et sous quelles contraintes.

Quand la thèse « data-first » se heurte aux opérations

Dans les faits, les RAG 2023-2024 ont brillé sur des questions ponctuelles. Ils ont souvent plafonné dès qu’il faut enchaîner plusieurs étapes, garder une cohérence, et décider sous contraintes.

Trois limites reviennent en production : des systèmes sans état (chaque question est traitée comme un monde séparé), une confusion bruit/signal quand la recherche remonte trop de contenu, et une difficulté à suivre un plan d’action sur plusieurs tours. Même avec des réponses exactes, l’utilisateur se retrouve avec une sortie correcte mais inutilisable.

En pratique, les échecs typiques se voient vite : le modèle n’arbitre pas entre délai et budget, ignore une règle de conformité, ou change de priorité d’un message à l’autre. Le problème n’est pas seulement « il manque un document », c’est « il manque une situation ».

Prenons une gestion de sinistre en assurance. Retrouver la clause d’un contrat ne suffit pas si l’agent ne sait pas l’objectif (décider ou escalader), la contrainte (plafond d’indemnisation, délai légal), l’historique client, et l’outil à utiliser pour vérifier une pièce. Sans context, le système récite, mais il ne traite pas.

Ce que recouvre le « context engineering », loin des recettes de formulation

Le context engineering (ingénierie du contexte) consiste à concevoir ce que l’IA voit au moment où elle raisonne, et dans quel ordre. Ce n’est pas une astuce de formulation : c’est une architecture d’information, pilotée par le besoin métier, comme le décrit notamment Anthropic sur l’ingénierie du contexte pour les agents .

On peut décomposer le context en cinq briques complémentaires :

Contexte d’instructions : rôle, objectifs, critères de réussite, politique d’escalade.
Contexte de connaissance : sources internes, RAG mieux cadré, documents « canoniques ».
Contexte de mémoire : court terme (conversation) et long terme (historique, préférences, cas similaires).
Contexte d’outils : interfaces de programmation (APIs), droits, résultats d’exécution, erreurs.
Contexte environnemental/temps : date, état des systèmes, événements, fenêtres de maintenance.

Toutefois, tout ne rentre pas. Les modèles ont un budget de contexte, c’est-à-dire une fenêtre de contexte (context window) limitée, qui coûte en calcul, en latence et en euros. D’où la règle d’or : assembler de façon dynamique et sélective, plutôt qu’empiler des pages « au cas où ».

Comment RAG se transforme en moteur de context

RAG ne disparaît pas, il change de rôle. Il devient une pièce d’un moteur de context, capable d’aller chercher juste ce qu’il faut, au bon moment, et parfois de ne rien chercher.

Cette évolution est souvent décrite comme une recherche « agentique » : récupération conditionnelle, stratégies multiples (sémantique, mots-clés, structuré), routage par domaine, et itérations jusqu’à obtenir un signal exploitable. Nvidia détaille cette différence entre RAG « traditionnel » et RAG agentique dans son analyse sur les agents et la connaissance dynamique .

Dans ce contexte, on voit émerger un chaînage inspiré du vieux extract-transform-load (ETL), mais adapté aux contenus non structurés : parse-transform-index (PTI). L’idée : parser (extraire), transformer (résumer, annoter, relier), puis indexer avec des métadonnées utiles au tri.

À court terme, un risque devient central : l’empoisonnement du contexte (context poisoning), quand une source mal contrôlée injecte du faux, du contradictoire ou du périmé. Les parades passent par du filtrage, du reclassement (reranking), de la vérification et une hiérarchie de sources de confiance.

Ce que cela change côté business : architecture, métiers, gouvernance

Pour les équipes, la conséquence la plus visible est une nouvelle couche : orchestration et contrôle. Elle gère droits d’accès, traçabilité, exécution en bac à sable (sandbox) et intervention humaine dans la boucle (human-in-the-loop), surtout sur les décisions à risque.

Côté organisation, les compétences se déplacent. On a toujours besoin de données propres, mais il faut aussi des profils capables d’écrire et maintenir le brief : responsables de processus, spécialistes de gouvernance de l’IA, et « context engineers » à la frontière entre métier et technique.

L’économie des projets change aussi. On investit moins dans un « grand chantier data » uniquement en amont, et davantage dans l’itération continue : ajuster règles, exceptions, mémoire, outillage, et critères d’évaluation. Le retour sur investissement dépend alors de la maintenabilité du context, pas seulement du volume de documents indexés.

Cinq étapes pour démarrer sans se tromper de cible

Choisir un cas d’usage agentique, avec plusieurs étapes et un vrai acte de décision, plutôt qu’un simple questions-réponses.
Formaliser le brief : objectif, contraintes, définition du “bon résultat”, et quand escalader vers un humain.
Cartographier sources, outils et droits ; ajouter un socle minimal de métadonnées et de sources « de référence ».
Mettre en place une évaluation par étages : récupération, assemblage du context, raisonnement, puis action.
Définir des garde-fous : seuils de risque, approbation humaine, et journaux d’audit exploitables.

Conclusion : le contexte n’enterre pas la donnée, il la remet au service de l’exécution orientée objectifs. L’avantage compétitif se joue dans la qualité du brief, la mémoire, l’orchestration et la gouvernance, plus que dans l’empilement de contenus. La promesse est forte, mais la difficulté se déplace : gérer règles, exceptions et maintenance continue, comme on le ferait avec une équipe.