Concevoir un agent d’IA RAG : corpus fiable et réponses traçables

Cette page s'adresse aux directeurs métier, SI ou données qui doivent décider sur quelles sources un agent peut s'appuyer, et comment prouver d'où vient chaque réponse. Un agent d'IA avec RAG va chercher l'information au bon endroit avant de répondre ou d'agir : l'enjeu est de réduire l'improvisation du modèle par un socle documentaire traçable.

Elle couvre le périmètre du corpus, les réglages de récupération, la conduite à tenir en cas d'incertitude et les tests du dispositif.

Quand un agent a besoin d'aller chercher avant de répondre

Un LLM dépend de ses données d'entraînement, figées dans le temps : il peut répondre de façon plausible mais obsolète ou non conforme. La génération augmentée par récupération le connecte à des connaissances externes (documents, bases internes, interfaces applicatives) pour des réponses vérifiables, sans réentraînement. Une erreur rare, assurée et sans source apparente, coûte plus cher qu'une erreur fréquente et visible.

Le besoin devient critique dès que vos contenus changent ou que vous devez justifier « d'où vient » une affirmation, pour quatre bénéfices.

• Précision métier : ancrer la génération sur des documents validés plutôt que sur des probabilités.
• Traçabilité : relier chaque réponse à des extraits et à une version documentaire.
• Mise à jour : actualiser la connaissance en modifiant le corpus plutôt qu'en réentraînant le modèle.
• Maîtrise du périmètre : limiter ce que l'agent a le droit d'utiliser.

Dès que « répondre » doit être auditable, il faut relier la réponse à une source identifiable. Le RAG en est un moyen, pas le seul : une base structurée ou un catalogue de réponses validées sont aussi traçables. Il s'impose quand la connaissance utile est dispersée dans des textes, volumineuse et mouvante ; il devient une lourdeur quand la réponse tient dans un champ de votre système de gestion.

Un agent qui cherche puis répond reste au niveau 1, lecture seule, des quatre niveaux de droits des agents d'IA ; il monte de niveau dès qu'il ouvre un ticket ou déclenche un outil. Le cadre amont (objectif, autonomie, spécification, recette) relève de la méthode pour créer un agent d'IA.

La chaîne d'un agent RAG : interpréter, décider, récupérer, composer, agir

Une chaîne de récupération « standard » combine recherche et génération : on convertit la question, on cherche des passages proches, on les injecte dans le contexte, le modèle rédige. Dans un cadre agentique s'ajoute une couche de planification : l'agent analyse la demande, choisit une source, lance des sous-requêtes, puis synthétise, en cinq temps.

• Interpréter la demande : objectif, contraintes, ambiguïtés.
• Décider du plan de récupération : où chercher, combien, avec quels filtres.
• Récupérer des passages pertinents, et idéalement les dédupliquer.
• Composer une réponse : synthèse, extraits, citations.
• Agir ou escalader : outil, ticket, transfert à un humain si nécessaire.

La couche agentique change surtout le troisième temps : face à des résultats pauvres, elle peut relancer la recherche, changer de corpus ou poser une question de clarification, là où une chaîne linéaire rend toujours quelque chose. Cette capacité à appeler des outils rattache l'agent RAG aux agents orientés tâches, l'une des sept familles d'agents décrites dans le pilier.

Cette souplesse se paie en latence et en appels : la boucle se borne par un nombre maximal d'itérations, chacune journalisée.

Gouverner le corpus : sources, fraîcheur, versions, droits

Une base RAG utile n'est pas un dossier de PDF empilés mais un système gouverné. Le point clé est la fraîcheur : qui met à jour, à quel rythme, et comment l'agent reconnaît la version la plus récente. Sans gestion des versions, les réponses sont justes mais datées, un défaut très difficile à détecter en production.

Quatre questions à trancher avant d'indexer quoi que ce soit

Ces décisions se prennent une fois, par écrit : ce sont des répartitions de responsabilité, qui se traduisent en champs concrets attachés à chaque extrait indexé.

La liste blanche de sources, et ce que l'agent n'a pas le droit d'ouvrir

La meilleure optimisation est une règle de périmètre claire : un agent connecté a besoin d'un « droit de chercher » explicite (sources, espaces, données personnelles, environnements). Sans ce cadrage, la recherche est trop large (bruit, contradictions) ou trop restrictive (« je ne sais pas » permanent). Trois règles l'écrivent.

• Liste blanche de sources : corpus validés, espaces autorisés, points d'accès applicatifs nommés un par un.
• Règles par type de question : ce qui est autorisé pour le support ne l'est pas forcément pour le juridique.
• Politique de données sensibles : masquage, refus ou escalade humaine selon le cas.

Cette liste dit quelles sources entrent, pas comment on s'y branche : comptes de service, quotas et séparation des environnements relèvent de l'intégration d'un agent d'IA.

Préparer la donnée : découpage, métadonnées, indexation

La récupération n'a rien d'un mécanisme unique : quatre mécanismes couvrent la plupart des besoins, et ils se choisissent selon la nature des contenus, pas par défaut.

• Recherche vectorielle : question et documents ramenés à des vecteurs, puis sélection des passages les plus proches.
• Recherche lexicale : elle retrouve les références, codes et libellés exacts que la paraphrase fait perdre.
• Recherche hybride : elle combine les deux signaux précédents.
• Filtre sur métadonnées structurées (client, date, pays, statut) : il règle seul des cas où aucun calcul de proximité n'aide.

Tous imposent la même préparation, découper, attacher des métadonnées et indexer, sous-estimée parce qu'invisible : c'est pourtant là que vous avez le plus de prise sans changer de modèle.

Découper selon la structure, pas selon un nombre de caractères

La taille des chunks, ces fragments de texte indexés puis injectés dans le contexte, est un arbitrage : trop long, un chunk dilue le signal et alourdit coût et latence ; trop court, il casse la cohérence. Découpez selon la structure logique (titres, sections, tableaux) plutôt que selon un nombre fixe de caractères : le document dit déjà où sont ses unités de sens.

Le découpage est donc orienté usage : une politique RH se lit par article et supporte des extraits longs ; une documentation applicative se lit par fonction et demande des extraits courts mais complets. La règle s'écrit par type de document.

Les métadonnées minimales, et la chaîne de traitement qui les produit

Chaque extrait porte un jeu de métadonnées sans lequel aucun filtre ne fonctionnera : source, date, version, responsable, type de document, langue, périmètre. L'indexation se contrôle à l'entrée : exclure brouillons, doublons et contenus non validés coûte une règle et évite des semaines de diagnostic, car deux versions contradictoires produisent une réponse assurée tirée de la mauvaise.

Pour rendre le système maintenable, pensez « chaîne de traitement » et non « prompt ». Six étapes la décrivent, en deux flux découplés : un flux par lots pour alimenter la base, un flux temps réel pour répondre.

• Ingestion : récupération des documents validés et des métadonnées associées.
• Prétraitement : nettoyage, découpage en chunks, détection de langue et de version.
• Indexation : calcul des vecteurs et insertion dans l'index.
• Récupération : sélection des k meilleurs passages (top-k), filtres et réordonnancement des résultats (re-ranking).
• Génération : réponse ancrée sur les extraits, avec citations si requis.
• Supervision : journaux, alertes sur la latence, taux de « je ne sais pas », retours utilisateurs.

Régler la récupération pour injecter moins, mais mieux

La pertinence dépend de la qualité des candidats récupérés, et ces candidats se règlent, alors que le modèle se subit. Injecter moins, mais mieux, réduit les tokens, le coût et le risque d'erreur : un contexte encombré pousse le modèle à lisser entre des extraits qui se contredisent.

Top-k, filtres, re-ranking, recherche hybride : l'effet de chaque levier

Ces réglages changent plus la qualité que dix itérations de prompt, et chacun comporte un risque symétrique. Réglez-les un par un, en mesurant après chaque changement : réglés ensemble, ils rendent impossible d'attribuer une amélioration à sa cause.

Router la question vers le bon corpus, selon l'intention et le risque

Une récupération simple interroge un seul corpus, même quand la question en impose plusieurs. Le routage décide « où chercher » avant de chercher, sur deux critères. L'intention : on classifie la demande (support, juridique, produit) puis on sélectionne les sources autorisées pour cette catégorie. Le risque : sur certains sujets, citations obligatoires, seuils élevés et escalade s'imposent.

Le recoupement va plus loin : interroger plusieurs récupérateurs spécialisés (documentation produit, historique de tickets) et croiser leurs passages, au prix d'un index de plus à maintenir par récupérateur. Ce routage choisit un corpus, jamais un agent : dès que la question devient « quel agent traite cette demande », vous avez changé de problème.

Savoir ne pas répondre, et tracer ce qui a été récupéré

La fiabilité se joue aussi dans la capacité à refuser de répondre : une récupération bien conçue réduit le risque d'hallucination, elle ne l'annule pas. Décidez à l'avance, par écrit, ce qui se passe quand les passages retrouvés ne sont pas assez bons : cette « stratégie d'incertitude » ne s'obtient pas en le demandant poliment au modèle.

Les trois niveaux d'une stratégie d'incertitude

Le dispositif se construit en escalier, du réglage automatique au transfert humain. Chaque niveau se déclenche sur une condition mesurable, jamais sur une appréciation du modèle.

• Seuil sur la qualité de la récupération : en dessous, pas de génération « affirmative ».
• Réponse contrôlée : « Je n'ai pas trouvé d'information dans les sources autorisées », accompagnée d'une question de précision.
• Escalade : transfert vers un humain avec le contexte, les extraits déjà récupérés et les journaux.

Un score de similarité n'est pas une probabilité que la réponse soit juste : il mesure une proximité entre question et passage, et un extrait très bien classé peut être périmé ou hors périmètre. Un seuil se calibre donc sur un jeu de tests aux réponses connues, et se recalibre à chaque changement de vectorisation, de découpage ou de corpus.

Le deuxième niveau est le plus rentable : une question de clarification transforme une demande ambiguë en demande traitable, là où un refus sec renvoie l'utilisateur à son point de départ. Suivez le taux de « je ne sais pas » : à zéro, le seuil est trop bas ; trop haut, le corpus ou les filtres sont en cause.

Tracer la recherche : droits, journaux et versions d'index

Connecter un agent à des sources augmente sa surface d'exposition, même sans droit d'écriture. Un extrait récupéré est un texte extérieur qui entre dans le contexte : s'il contient des instructions (ignorer les consignes, appeler tel outil), rien ne les distingue de la demande de l'utilisateur. Traitez les extraits comme des données citées, jamais comme des consignes.

• Délimiter explicitement les extraits dans le prompt.
• N'exécuter aucun outil sur la seule foi d'un passage récupéré.
• Surveiller le corpus lui-même : un document altéré ou versé par un tiers suffit à retourner l'agent.

En production, la traçabilité couvre la recherche (quels documents, avec quels scores) comme la décision qui en découle. Trois points de vigilance se posent avant l'ouverture aux utilisateurs, jamais après un incident.

• Droits d'accès minimaux, appliqués avant l'injection : permissions par source, environnement et rôle, et filtrage des extraits sur les droits de l'utilisateur, car un passage injecté est un passage divulgué.
• Journalisation utile, et minimisée : requête, sources, identifiants et versions des extraits, scores, décision. Journaliser le texte intégral recopie vos documents sensibles dans un second système : conservez des références et restreignez l'accès.
• Gestion des versions : documents, index et prompts de génération, pour pouvoir rejouer un cas à l'identique.

Sans gestion des versions, vous ne pouvez ni expliquer une réponse passée, ni la reproduire, ni prouver qu'une correction documentaire a été prise en compte par l'agent.

Recetter la récupération et corriger ce qui échoue

Un agent d'IA avec RAG ne se valide pas à l'intuition : il se teste comme un système de recherche, sur un jeu de tests en trois couches.

• Questions réellement posées : tickets, e-mails, demandes internes.
• Cas limites : ambiguïtés, synonymes, versions contradictoires, demandes multi-intentions.
• Cas à haut risque, traités à part : juridique, finance, RH, sécurité, conformité.

Définissez ensuite des critères d'acceptation : citation obligatoire, exactitude factuelle, refus en l'absence de source, latence maximale. Sans eux, vous optimisez au hasard.

Ce qu'on mesure : pertinence, couverture, exactitude, latence, coût

Évaluer une récupération, c'est séparer la recherche de la génération. Côté recherche, vous arbitrez entre recall (retrouver ce qu'il faut) et précision (éviter le bruit) ; côté génération, vous mesurez l'exactitude et l'ancrage sur les extraits.

• Pertinence : la part des passages réellement utiles dans le top-k. Alerte : beaucoup d'extraits « proches » mais non exploitables.
• Couverture : la capacité à retrouver le bon document. Alerte : des réponses correctes seulement sur les questions « faciles ».
• Exactitude : la conformité de la réponse aux sources. Alerte : l'ajout d'informations absentes des extraits.
• Latence et coût : le temps bout en bout et le volume consommé. Alerte : top-k trop haut, relances fréquentes.

Du symptôme au réglage, puis au re-test

Quand la réponse est mauvaise, la cause est presque toujours en amont de la génération. Partez du symptôme observé, remontez à la cause probable, ne touchez qu'un réglage à la fois, et sachez d'avance à quoi vous reconnaîtrez que c'est réglé.

Ce tableau ne vaut qu'une fois branché sur une boucle en quatre temps, nourrie par un retour utilisateur minimal (utile ou inutile, et pourquoi).

• Observer : journaux structurés et échantillonnage des conversations.
• Qualifier : taguer chaque échec (recall, précision, obsolescence, ambiguïté), parce qu'un échec non qualifié se recompte indéfiniment.
• Corriger sur un seul axe : corpus, découpage, filtres, routage ou re-ranking.
• Rejouer le jeu de tests complet : le seul moment où l'on sait si le problème est réglé ou déplacé.

Continuez votre lecture

Selon l'étape où vous en êtes, trois articles prolongent celui-ci.

• Votre chaîne d'ingestion tient, mais il reste à décrire ce qui se passe quand une étape échoue : c'est le sujet de l'agent d'IA en workflow.
• Votre routage choisit un agent spécialisé et non plus seulement un corpus : rôles, protocoles d'échange et arbitrage des conflits relèvent de l'orchestration d'agents d'IA.
• Le corpus et la stratégie de récupération sont arrêtés, et il reste à choisir avec quoi les exécuter : modèles et outils se comparent sur une plateforme d'agent d'IA.

Et si ce qui vous manque est en amont, des contenus validés et versionnés sur lesquels un agent puisse s'ancrer, c'est la tâche qu'encadre la génération de contenus par une IA personnalisée.

FAQ sur les agents IA avec RAG

C'est quoi un RAG en IA ?

Le RAG, ou génération augmentée par récupération, connecte un modèle d'IA générative à une base de connaissances externe avant qu'il réponde. Le système récupère des passages pertinents (documents, bases internes, interfaces applicatives) et les injecte dans le contexte du modèle, pour des réponses plus à jour, plus spécifiques et plus contrôlables, sans réentraînement.

Qu'est-ce qu'un agent IA avec RAG ?

Un agent IA avec RAG combine la récupération documentaire dans un corpus autorisé et l'autonomie agentique pour planifier, décider et, si besoin, agir via des outils. À la différence d'une chaîne de récupération simple, il peut relancer une recherche, changer de source ou poser une question de clarification.

Comment fonctionne un agent IA avec RAG ?

Un agent IA avec RAG fonctionne en cinq temps : il interprète la demande, décide d'un plan de récupération, récupère les passages pertinents, compose une réponse ancrée sur ces extraits, puis agit ou escalade vers un humain. Chaque temps laisse une trace qui rend la réponse explicable après coup.

En quoi un agent IA avec RAG diffère-t-il d'un chatbot ou d'un LLM seul ?

Un agent IA avec RAG va chercher l'information dans des sources autorisées, cite ses extraits et peut exécuter des tâches au-delà du question-réponse. Un LLM seul répond à partir de connaissances apprises à l'entraînement, donc potentiellement obsolètes ; un chatbot classique suit des scripts sans aller chercher la connaissance.

Comment choisir une stratégie de retrieval efficace pour un agent IA avec RAG ?

Une stratégie de retrieval efficace se choisit selon le risque des questions et les sources disponibles, jamais selon un cadre technique. Elle combine un périmètre clair, un découpage orienté usage, des métadonnées exploitables, des réglages de top-k et de filtres, du re-ranking, et une recherche hybride pour les termes exacts.

Comment évaluer et améliorer la recherche documentaire d'un agent IA avec RAG ?

La recherche documentaire s'évalue sur un jeu de tests construit à partir de questions réellement posées, en mesurant séparément la récupération (pertinence, couverture) et la génération (exactitude, respect des sources). Les critères d'acceptation se fixent avant tout réglage, puis chaque changement se rejoue sur le jeu complet.

Comment limiter les hallucinations dans un agent IA avec RAG ?

Les hallucinations se limitent en ancrant chaque réponse sur des extraits cités, en réduisant le bruit injecté (top-k raisonnable, déduplication, re-ranking, filtres) et en écrivant une stratégie d'incertitude faite de seuils, de refus explicite et d'escalade humaine. La gouvernance du corpus compte autant : brouillons et doublons produisent des réponses assurées tirées du mauvais document.

Quels documents et formats donnent les meilleurs résultats pour une base RAG ?

Les meilleurs résultats viennent de contenus stables, structurés et gouvernés : documentation produit, politiques internes, bases de connaissances validées, contenus versionnés. Les données non structurées (fichiers bureautiques, e-mails, journaux) restent exploitables, mais demandent bien plus de nettoyage, de découpage et de métadonnées.