Le système RAG cherche des réponses. Le RAG agentique pose d'abord les bonnes questions.

Le RAG a permis aux IA d'aller chercher l'information au bon endroit. Le RAG agentique leur apprend à réfléchir avant de chercher. Ce n'est pas une rupture. C'est la suite logique, et elle change pas mal de choses.

Le RAG classique a tenu ses promesses, jusqu'à un certain point

Le principe du RAG (Retrieval-Augmented Generation) est simple : au lieu de se fier uniquement à ce qu'un modèle de langage « sait », on lui donne accès à une base de connaissances externe. Il cherche l'information pertinente, puis génère sa réponse en s'appuyant dessus.

Ça fonctionne. Pour des questions directes, dans un corpus bien structuré, un RAG bien conçu fait gagner un temps considérable. Un technicien cherche une procédure dans 400 pages de documentation ? Il pose la question, il obtient la réponse avec la source. Trois secondes au lieu de vingt minutes.

Mais dès qu'on sort du cas simple, les limites apparaissent.

Le RAG classique cherche une fois, génère une fois. Si l'information récupérée n'est pas la bonne, il ne le sait pas. Si la question nécessite de croiser plusieurs sources, il ne sait pas le faire. Si la requête est ambiguë, il ne demande pas de précision, il devine. Mal.

Ce n'est pas un défaut de conception. C'est une architecture pensée pour un usage précis. Le problème, c'est qu'on lui demande de plus en plus de faire ce pour quoi il n'a pas été conçu.

Ce que le RAG agentique change concrètement

Le RAG agentique ne remplace pas le RAG. Il le prolonge en ajoutant une couche d'intelligence dans le processus de recherche lui-même.

Concrètement, un agent IA s'interpose entre la question de l'utilisateur et la base de connaissances. Cet agent ne se contente pas de transmettre la requête. Il la décompose, planifie les étapes de recherche, évalue la pertinence de ce qu'il trouve, et décide s'il doit chercher davantage, ailleurs, ou autrement.

Prenons un exemple. Marie, responsable qualité dans une entreprise manufacturière de Laval, demande : « Est-ce que notre procédure d'inspection des soudures est conforme à la dernière version de la norme CSA W47.1 ? »

Un RAG classique va chercher dans la documentation interne ce qui ressemble à « inspection des soudures » et générer une réponse basée sur ce qu'il trouve. Si la norme a été mise à jour et que le document interne ne le reflète pas, il ne le signalera pas.

Un RAG agentique va décomposer la question. D'abord, trouver la procédure interne. Ensuite, identifier les exigences de la norme. Puis comparer les deux. Et si l'information sur la norme n'est pas dans la base, l'agent peut aller la chercher dans une source externe, ou signaler qu'il manque un élément pour répondre correctement. Chaque étape est évaluée avant de passer à la suivante.

La différence n'est pas cosmétique. Elle est structurelle.

La vraie question n'est pas technique. Elle est métier.

Il serait tentant de voir le RAG agentique comme un simple upgrade technologique. Meilleur moteur, mêmes routes.

Ce n'est pas le cas.

Un système qui raisonne en plusieurs étapes, qui croise des sources, qui évalue la qualité de ses propres résultats, c'est un système qui expose les failles de votre documentation, de vos processus, de votre gouvernance de l'information.

Si vos documents sont mal structurés, un RAG classique donne des réponses approximatives. Un RAG agentique, lui, va tourner en boucle, chercher dans trois endroits différents, et finir par assembler une réponse incohérente à partir de fragments contradictoires. Avec plus d'assurance qu'avant.

Dit autrement : le RAG agentique amplifie la qualité de votre base de connaissances. Dans les deux sens. Si vos données sont bonnes, les résultats sont remarquablement meilleurs. Si elles ne le sont pas, les résultats sont remarquablement pires, et plus difficiles à détecter.

Ce qui ne change pas avec le RAG agentique

Quelques constantes méritent d'être rappelées.

La qualité des données reste le facteur déterminant. Aucune architecture, aussi sophistiquée soit-elle, ne compense un corpus mal organisé, obsolète ou incomplet. Les hallucinations ne disparaissent pas. Elles peuvent même devenir plus élaborées, parce que l'agent a plus d'espace pour construire des raisonnements plausibles à partir de prémisses fausses.

Le besoin de cadrage métier augmente, il ne diminue pas. Un RAG classique mal configuré donne de mauvaises réponses. Un RAG agentique mal cadré prend de mauvaises décisions en chaîne, avec une autonomie qui rend les erreurs plus difficiles à repérer.

Et surtout : un système plus puissant n'est pas un système plus simple à déployer. La complexité architecturale augmente. Les coûts de calcul aussi. Le nombre de points de défaillance se multiplie. Ce n'est pas un argument contre le RAG agentique, c'est un argument pour ne pas le déployer sans savoir exactement pourquoi on en a besoin.

Le bon outil au bon endroit, au bon moment

Il y a deux types de situations.

Celles où un RAG classique suffit. Une base de connaissances propre, des questions directes, un besoin de réponses rapides et sourcées. Un technicien qui cherche une procédure, un employé qui vérifie une politique interne, un client qui pose une question sur un produit. Pour ces cas, ajouter une couche agentique serait du surengineering coûteux.

Et celles où le RAG agentique apporte une vraie valeur. Des questions complexes qui nécessitent de croiser plusieurs sources. Des corpus hétérogènes (documentation technique, bases de données, courriels, rapports). Des contextes où la réponse correcte demande un raisonnement en plusieurs étapes, pas juste une recherche de similarité.

La différence entre les deux ne se détermine pas par la technologie. Elle se détermine par le diagnostic.

Le RAG agentique est une évolution, pas une destination

Le discours ambiant présente le RAG agentique comme la prochaine étape incontournable. C'est partiellement vrai. C'est effectivement une maturation importante de l'architecture RAG, et les cas d'usage pertinents vont se multiplier.

Mais « pertinent » est le mot clé.

Le RAG agentique fonctionne quand il est déployé dans un contexte bien compris, sur des données bien structurées, avec des objectifs clairs. Il échoue, comme tout le reste, quand on saute l'étape du cadrage pour aller directement à l'implémentation.

L'IA évolue vite. Les architectures se sophistiquent. Mais le principe reste le même : comprendre le problème avant de choisir la solution. Plus l'outil est puissant, plus cette étape compte.

Vous explorez le RAG ou le RAG agentique pour votre organisation ? La première question n'est pas « quelle architecture choisir ». C'est « quel problème concret essayez-vous de résoudre, et vos données sont-elles prêtes ». C'est ce type d'accompagnement qu'on sait faire.