Votre agent ne connaît rien de votre entreprise : RAG corrige ça

Un agent bien construit sur un modèle généraliste ne connaît toujours rien de votre entreprise. Il ne connaît pas votre documentation, il n'a pas vos politiques, et quand on lui pose une question à laquelle il ne sait pas répondre, il répond avec la même assurance que s'il savait. RAG (Retrieval-Augmented Generation, génération augmentée par recherche) comble ce vide avec un processus en trois étapes : il récupère les documents qui comptent pour la question, les met dans le contexte et génère la réponse sur cette base. Dans ce post, je parcours le module « Introduction to Foundry IQ » sur Microsoft Learn du début à la fin. Vous verrez ce qui manque à un agent seul, comment fonctionne le processus, ce que RAG unifie et d'où vient l'information. Et pourquoi les instructions de récupération finissent par définir le résultat. Et quoi mesurer quand la base est vivante.

Ce qui manque à un agent seul

Il y a cinq limites, et chacune apparaît au même moment : quand l'agent de démonstration arrive dans l'entreprise et qu'on lui pose quelque chose de spécifique. Les cinq plaintes :

Date limite des connaissances. Le modèle a été entraîné jusqu'à une date. Votre release de la semaine dernière, le nouvel organigramme ou la politique révisée hier ne sont pas dans ses données.
Pas d'accès aux données privées. Il n'a jamais vu vos informations, donc il répond de façon générique : cela convient à n'importe qui, pas à votre entreprise.
Contexte manquant. Il ignore les exigences internes et répond comme si votre entreprise n'avait pas de règles propres.
Réponses fabriquées. Quand il ne trouve pas la réponse, il l'invente avec le même ton assuré. Sur une politique de vacances ou tout ce qui touche à la conformité, c'est un problème sérieux.
Ingénierie dupliquée. Chaque équipe qui en a besoin reconstruit son propre pipeline de récupération à partir de zéro.

RAG en trois étapes

Le processus comporte trois étapes coordonnées. Récupérer : chercher dans les bases de connaissances le contenu pertinent pour la question de l'utilisateur. Augmenter : ajouter ce contexte factuel à la requête. Générer : répondre en combinant ce que le modèle sait avec l'information récupérée.

flowchart LR
    Q[Votre question à l'agent] --> R[Récupérer : la base cherche les documents qui comptent]
    R --> A[Augmenter : le contexte s'ajoute à votre question]
    A --> G[Générer : le modèle répond sur cette base]
    G --> C[La réponse arrive avec la citation qui la soutient]

En clair : l'agent ne devine plus ; d'abord il cherche dans vos documents, lit ce qu'il a trouvé, et seulement ensuite il répond par-dessus, avec la source en vue. La citation qui arrive à la fin est la preuve qu'il a lu.

Trois avantages en découlent, et ils changent le quotidien. Mises à jour en temps réel : vous avez changé le document de politiques et la prochaine question lit déjà la nouvelle version, sans réentraîner quoi que ce soit. Transparence de l'origine : la réponse arrive avec la citation qui la soutient. Base factuelle : ce que dit l'agent est ancré dans un document, pas dans la probabilité statistique du mot suivant.

Et une clarification qui évite un mauvais chemin : pas besoin de réentraîner le modèle ni de changer de LLM (grand modèle de langage, le modèle qui répond). RAG connecte l'agent aux sources de connaissances de l'organisation ; l'avantage principal est que les réponses s'appuient sur l'information actuelle de l'entreprise et que la source reste en vue.

Pourquoi le construire à la main fait mal

Construire RAG à la main implique de fragmenter les documents (les couper en morceaux cherchables), de créer des index vectoriels (la structure qui permet de chercher par sens et pas seulement par mot exact) et d'optimiser la récupération — et ce travail entier se répète pour chaque équipe qui en a besoin. C'est le travail que Foundry IQ unifie : la plateforme de connaissances managée de Microsoft, basée sur Azure AI Search, où les bases de connaissances se créent une fois et sont ensuite utilisées par plusieurs agents. Ce n'est pas seulement le démarrage : c'est le pipeline qu'il faut maintenir chaque fois qu'une source de données change. La promesse est directe : l'investissement d'indexation se fait une seule fois et tous les agents que vous connectez l'héritent.

Des bases par domaine, pas par dossier

La décision d'organisation qui change le plus le résultat : les bases se regroupent par domaine métier, pas par emplacement technique. « Documentation du produit » et « politiques RH » sont des domaines ; le dossier partagé de l'équipe commerciale est un emplacement. Une seule base peut combiner SharePoint, Blob Storage (le stockage de fichiers d'Azure), OneLake et l'index de recherche que vous avez déjà, le tout sous une seule source unifiée.

Quand vous ajoutez une source, la plateforme détecte, fragmente, vectorise (convertit le texte en nombres qui représentent son sens, pour pouvoir chercher par idée) et indexe automatiquement — et réindexe quand la source change. C'est là que réside l'économie : la base se définit une fois et tout agent connecté hérite des améliorations à l'instant. Vous avez réparé l'indexation d'un document et tous les agents qui consomment cette base l'ont reçue sans autre formalité.

Les six sources de données

D'où vient l'information, et quand chaque source convient :

Index Azure AI Search : déjà indexé, avec classification sémantique, scoring personnalisé et facettes (filtres par attribut, comme dans une boutique en ligne). Pour quand vous avez déjà un index construit.
Azure Blob Storage : accès direct aux fichiers de documents. Pour téléverser des fichiers et les avoir là.
Le web : en temps réel via Bing. Pour le contenu public qui change souvent.
SharePoint distant : requêtes en temps réel avec la gouvernance de Microsoft 365, en respectant les permissions héritées telles qu'elles existent.
SharePoint indexé : exige votre propre pipeline d'indexation.
OneLake : données non structurées de Microsoft Fabric.

SharePoint distant et SharePoint indexé méritent la comparaison. Le distant interroge les sites sans rien indexer et laisse les permissions actuelles décider. L'indexé vous donne le contrôle sur l'indexation en échange de la construction et de la maintenance de ce pipeline. Et quand les résultats importants doivent apparaître en premier, les profils de scoring priorisent les champs selon la logique métier. Un détail à garder clair : les profils de scoring ordonnent les résultats ; ils ne chiffrent pas les données ni ne configurent la fragmentation.

Comment la plateforme décide quoi récupérer

Quand une question arrive, la plateforme l'analyse et choisit une stratégie : mot-clé pour les questions factuelles, sémantique avec expansion des requêtes pour les complexes. Ensuite elle classe les résultats par pertinence et les livre avec des citations. Ce flux fait que la réponse vienne avec la référence et non avec une invention. Trois techniques améliorent encore cette récupération : les profils de scoring, la classification sémantique et les analyseurs personnalisés. Il n'y a pas une seule façon de chercher ; la plateforme choisit selon ce qu'on lui demande.

Le contrat : les instructions

C'est ici que se joue la qualité. Les instructions de l'agent sont le contrat avec la base de connaissances, et elles doivent spécifier trois choses.

Quand récupérer : toujours interroger la base avant de répondre, et ne jamais répondre à partir des données d'entraînement du modèle. Comment citer : avec le format exact 【doc_id:search_id†source_name】, pour que chaque phrase sourcée soit traçable. Que faire quand il n'y a pas d'information : une réponse alternative déclarée, au lieu d'une tentative de deviner.

L'exemple est un assistant RH, avec quatre règles, toutes des ordres clairs que l'agent ne peut pas sauter : toujours chercher dans la base de connaissances ; ne jamais répondre à partir des données d'entraînement ; citer dans le format ; et s'il n'y a pas d'information, répondre « I don't have that information in our current documentation. Please contact HR directly at hr@company.com ».

Il y a un cas qui le rend concret : « Quelle est notre politique de vacances ? » Il y a trois chemins possibles. L'agent peut répondre avec ce qu'il sait de l'entraînement : réponse générique, incorrecte. Il peut chercher correctement et répondre sans citation : correcte, mais non vérifiable. Le seul acceptable est de récupérer depuis la base, citer le document et raisonner dessus. Sans instructions qui obligent à cela, l'agent reste sur les deux premiers chemins.

L'exemple : un agent de support technique

Le schéma se répète avec un autre cas : un agent de support qui répond aux questions produit en interrogeant la base de connaissances de la documentation, au lieu de dépendre de ce que le modèle retient, chaque réponse arrivant accompagnée de la citation du document source. Même contrat que l'assistant RH, autre base. Le détail à ne pas perdre : l'agent n'a pas été réécrit ; ce qui a changé, c'est la base qu'il interroge et les instructions qui lui disent quand l'utiliser. Quand la documentation change, le support répond différemment sans toucher à l'agent.

Tester et superviser

L'arc se ferme avec la pratique qui soutient tout cela dans la durée : tester et superviser la récupération de l'agent pour maintenir la qualité en production. Base et agent se testent ensemble : le contrat d'instructions ne se valide que contre une base vivante. Tester, c'est poser de vraies questions et regarder si les citations arrivent ; superviser, c'est regarder à nouveau quand la base a changé. Et une base qui répond bien aujourd'hui peut se périmer ; sans supervision, ce déclin passe inaperçu jusqu'à ce que quelqu'un se plaigne.

De la lecture à l'exécution

Ce qui manque est l'étape qui n'a pas été exécutée ici : l'exercice « Integrate an AI agent with Foundry IQ », qui exige un abonnement Azure. Le post a parcouru le processus, les sources, le contrat d'instructions et les cas d'exemple ; il reste à les essayer contre votre propre base.

Si vous revenez sur ce post le jour où la base sera en production, ces deux mesures sont le premier contrôle. Il y en a deux, et aucune n'apparaît seule dans le tableau de bord : la latence de la récupération (combien de temps met la réponse depuis qu'elle interroge la base) et la couverture des citations (quelle proportion de phrases arrivent avec leur source). Sans ces deux chiffres, « ça répond bien » est une impression. L'ordre est déjà dans le post : d'abord la base, ensuite les instructions, ensuite les tests avec de vraies questions, et seulement après la supervision. Le parcours est là ; les chiffres, c'est à vous de les mettre.

Mon avis

Ce qui définit le résultat, ce sont les instructions. La plateforme fait le travail lourd : elle indexe, réindexe, choisit la stratégie et livre des citations. Mais si le contrat que vous écrivez ne dit pas quand chercher, comment citer et quoi faire sans données, l'agent se comportera comme le modèle seul. La différence : maintenant il le fait sur l'information de votre entreprise. Traitez ce bloc comme ce que c'est : la spécification de votre agent.

---

*Source : le module « Introduction to Foundry IQ » de Microsoft Learn.*