Agents, MCP, LRM, contexte : le glossaire de la transformation agentique

En dix-huit mois, le vocabulaire de l'IA s'est complexifié plus vite que la capacité des organisations à l'assimiler, et ce décalage a un coût réel : il faut savoir de quoi on parle pour valider des budgets, avec des équipes techniques qui parlent un jargon encore plus vivant que des punchlines de street slam, et des décisions de « faire ou acheter » prises sur des bases qu'on espère communes. 

ByteByteGo, une newsletter technique largement suivie dans la communauté des architectes logiciels, publiait cette semaine un glossaire des termes IA à connaître. L'exercice est utile, et il mérite d'être prolongé pour un public dirigeant, parce que ces notions ne sont pas que du vocabulaire d'ingénieur : elles déterminent directement ce qu'une organisation peut raisonnablement promettre, et ce qu'elle doit exiger d'un éditeur ou d'un intégrateur avant de signer. 

Commençons par le terme le plus galvaudé de tous : l'IA agentique. Un agent IA n'est pas un chatbot plus intelligent. C'est un système qui comprend un objectif, construit un plan pour l'atteindre, appelle des outils et des API pour agir dans le monde réel, évalue les résultats obtenus, et corrige sa trajectoire jusqu'à atteindre l'objectif fixé. La différence avec l'IA générative classique (un copilote qui répond à une requête) est une différence de nature, pas de degré : l'agent ne répond plus, il agit. C'est précisément la distinction que la méthodologie Meridian pose en ouverture de sa déclinaison agentique : l'IA générative augmente l'humain, l'IA agentique intègre un nouvel acteur dans le modèle opératoire de l'entreprise. Ce n'est pas un outil de plus dans la boîte à outils. C'est un collaborateur autonome qu'il faut superviser, auditer et dont il faut gérer la montée en compétence, au même titre qu'un collaborateur humain junior. 

Le deuxième terme à maîtriser est moins généralisé : le Large Reasoning Model, ou LRM. Un LRM est un modèle entraîné pour décomposer un problème complexe en sous-problèmes et raisonner sur chacun d'eux avant de produire une réponse, plutôt que de générer directement un texte plausible token après token. C'est ce qui permet à un agent de gérer une tâche à plusieurs étapes, par exemple reconstituer un dossier de conformité à partir de dix documents sources hétérogènes, plutôt que de simplement résumer un texte. Pour un dirigeant, la question qui compte n'est pas « quel modèle utilisez-vous », mais « vos cas d'usage nécessitent-ils réellement du raisonnement multi-étapes, ou un modèle plus simple et moins coûteux suffirait-il ? ». C'est une question d'architecture et de FinOps, elle se doit d'être centrale dans toute prise de décision. 

Troisième notion, sans doute la plus structurante sur le plan opérationnel : le contexte, et la discipline qui consiste à le piloter, le context engineering. Le contexte, c'est l'ensemble des informations qu'un modèle reçoit au moment de produire sa réponse : l'historique de la conversation, les instructions système, les documents ou extraits injectés, les résultats des outils déjà appelés, la mémoire de ce que l'agent a fait aux étapes précédentes. Un modèle ne « sait » que ce qui se trouve dans cette fenêtre à l'instant T ; au-delà, il n'a ni mémoire ni accès, même si l'information existe quelque part ailleurs dans le système d'information de l'entreprise. Le context engineering est l'ingénierie qui consiste à décider ce qui entre dans cette fenêtre, dans quel ordre, sous quelle forme condensée, et ce qu'il faut en faire sortir au bon moment pour qu'elle ne soit ni saturée ni diluée. C'est une discipline encore jeune, mais qu'une part croissante de la communauté technique considère déjà comme ayant supplanté le prompt engineering en tant que compétence critique : un prompt parfaitement écrit ne sert à rien si le modèle reçoit, au même moment, trois versions contradictoires d'un même document ou vingt pages de bruit sans rapport avec la tâche. Pour un agent qui enchaîne plusieurs étapes et plusieurs appels d'outils, une fenêtre de contexte mal gérée est la cause la plus fréquente de dérive silencieuse : l'agent ne « ment » pas, il raisonne correctement sur un contexte mal construit. 

Quatrième notion, la base de données vectorielle. Il s'agit d'une base qui ne stocke pas du texte brut, mais des représentations numériques (des vecteurs) qui capturent le sens et les caractéristiques d'un contenu, qu'il s'agisse de texte, d'image, de son ou de vidéo. Deux documents qui parlent du même sujet avec des mots différents auront des vecteurs proches. C'est ce qui permet à un agent de « retrouver » une information pertinente sans qu'elle contienne exactement les mots de la question posée. 

Ce qui nous amène directement au cinquième terme, le RAG (Retrieval Augmented Generation). Le RAG est la technique qui consiste à injecter dans le contexte d'un modèle l'information pertinente au moment où elle est nécessaire, le plus souvent extraite d'une base vectorielle, mais aussi parfois par API, requête SQL ou recherche hybride. C'est le RAG qui permet à un agent de répondre en s'appuyant sur les documents internes d'une entreprise plutôt que sur les seules connaissances générales du modèle, avec un risque d'hallucination considérablement réduit, à condition que le corpus source soit lui-même correctement gouverné. 

Sixième terme, le plus récent et sans doute le plus structurant pour 2026 et 2027 : le Model Context Protocol, ou MCP. C'est un protocole ouvert qui standardise la façon dont une application IA se connecte à des outils et des API externes. Avant le MCP, chaque intégration entre un agent et un système métier était un développement sur mesure, coûteux à maintenir. Le MCP introduit une interface commune : un client MCP, intégré dans l'application IA, communique avec des serveurs MCP qui exposent les capacités d'un système (un CRM, un ERP, une base documentaire) de façon normalisée. C'est l'équivalent, pour les agents IA, de ce que les API REST ont été pour le web il y a quinze ans : une couche d'interopérabilité qui transforme un paysage d'intégrations artisanales en infrastructure réutilisable. 

Pourquoi ce glossaire mérite-t-il d'être pris au sérieux par un comité de direction plutôt que délégué entièrement à la DSI ? Parce que ces six notions correspondent très exactement à des couches identifiées dans l'architecture de référence d'une AI Factory :

• La couche « Connaissance & contexte » d'une AI Factory repose précisément sur le context engineering : le RAG et les bases vectorielles en sont des techniques d'exécution, pas des synonymes, au service d'un corpus gouverné, tracé, et d'une fenêtre de contexte pensée comme une ressource à piloter plutôt que comme un espace infini.

• La couche « Agents & orchestration » repose sur les systèmes multi-agents, les workflows et le protocole d'outillage, c'est-à-dire le MCP.

• La couche « Modèles » arbitre, pour chaque cas d'usage, entre un modèle plus léger et rapide et un LRM plus coûteux mais capable de raisonnement multi-étapes. Ignorer ce vocabulaire, ce n'est pas seulement un inconfort en réunion : c'est se priver de la capacité à challenger un prestataire sur son architecture, à comparer deux offres sur des bases objectives, ou à comprendre pourquoi une facture de tokens explose d'un mois sur l'autre. 

C'est aussi, dans le référentiel GAME (Greenfield AI Maturity Evaluation), un signal direct sur la dimension D6, Talents & Culture : une organisation ne peut pas exploiter et maintenir ce qu'elle ne comprend pas, et l'adhésion des utilisateurs commence par une littératie minimale partagée entre le métier, la technique et la direction.

Ce glossaire n'épuise évidemment pas le sujet. Il existe une couche entière de notions complémentaires, de l'évaluation des systèmes multi-agents aux protocoles émergents de communication entre agents (A2A, ACP), en passant par les questions de gouvernance et de traçabilité que l'AI Act rend désormais opposables.

En attendant, la leçon est simple : avant de lancer ou d'accélérer un projet agentique, assurez-vous que votre comité de direction partage un vocabulaire minimal avec vos équipes techniques. Ce n'est pas un exercice académique. C'est la condition pour poser les bonnes questions à vos prestataires, pour dimensionner correctement votre AI Factory, et pour éviter que la complexité du langage ne devienne, en elle-même, un facteur de risque dans votre transformation IA. 

Un dernier point, souvent négligé : ce vocabulaire évolue vite, et il continuera d'évoluer. L'enjeu est bien d'installer, au sein de votre organisation, un réflexe de mise à jour continue de cette littératie partagée, au même rythme que l'évolution technologique elle-même. C'est un investissement modeste au regard d'un arbitrage dans le flou.