RAG : comment connecter une IA aux données de votre entreprise ?

Vous avez probablement déjà testé ChatGPT, Claude ou Gemini. Posez-leur une question générale et ils peuvent répondre sur énormément de sujets. Demandez-leur en revanche quelle procédure votre entreprise applique lorsqu’un client rencontre un problème très précis, et les choses se compliquent.

La raison est assez simple : le modèle ne connaît pas vos procédures internes, vos contrats, votre catalogue, votre documentation technique ou les informations contenues dans votre logiciel métier.

Pour utiliser ces connaissances, plusieurs approches existent. Le RAG, pour Retrieval-Augmented Generation, est l’une des plus courantes.

Son principe est assez simple : plutôt que d’essayer de faire apprendre toute la documentation de l’entreprise au modèle, le système va chercher les informations utiles au moment où une question lui est posée, puis les lui fournit pour construire sa réponse.

Voyons ce qu’il se passe réellement derrière ce mécanisme.

RAG : de quoi parle-t-on exactement ?

Prenons une entreprise qui possède 2 000 documents techniques : procédures d’installation, notices, documentation produit, fiches de maintenance, comptes rendus d’intervention... Un collaborateur demande à un assistant interne : « Quelle est la procédure prévue lorsqu’un client rencontre le problème X ? »

Un modèle d’IA seul ne peut pas connaître la réponse si cette procédure est propre à l’entreprise et qu’elle ne lui a jamais été fournie. Avec un RAG, le fonctionnement est différent.

Le système recherche d’abord, parmi les 2 000 documents, les passages susceptibles de répondre à la question. Il peut par exemple retrouver trois extraits d’une procédure de maintenance et d’une notice technique.

Ces extraits sont ensuite transmis au modèle avec la question initiale. Le modèle dispose alors du contexte nécessaire pour rédiger sa réponse. Selon l'application, celle-ci peut également indiquer les documents utilisés afin que le collaborateur puisse vérifier l'information.

Le RAG ajoute donc une étape de recherche d’informations avant la génération de la réponse. C’est ce qui explique son nom :

• Retrieval : le système récupère les informations pertinentes ;
• Augmented : ces informations viennent enrichir la demande envoyée au modèle ;
• Generation : le modèle génère sa réponse à partir de la question et du contexte récupéré.

Cette distinction est importante : le modèle n’a pas soudainement « appris » les 2 000 documents. Ils restent dans le système d’information de l’entreprise. Seuls les éléments jugés utiles pour répondre à la demande lui sont transmis.

Pourquoi une IA ne connaît-elle pas les données de votre entreprise ?

Les modèles proposés par OpenAI, Anthropic, Google, Mistral et d’autres acteurs sont entraînés sur de très grandes quantités de données. Cela leur permet de comprendre une question, de manipuler du langage et de disposer de nombreuses connaissances générales.

Mais ils n’ont évidemment pas accès par défaut à votre CRM, votre documentation interne ou aux PDF stockés sur votre serveur. Même lorsqu’une information concerne votre entreprise et existe publiquement, rien ne garantit que le modèle la connaisse, qu'elle soit à jour ou qu’il la restitue correctement.

Il faut donc distinguer deux choses : ce que le modèle sait déjà et les informations que votre application met à sa disposition pour traiter une demande précise. C'est justement sur cette seconde partie que travaille un système RAG.

Cela permet par exemple de créer un assistant capable de répondre à partir d’une documentation interne sans attendre qu’un nouveau modèle soit entraîné chaque fois qu’une procédure change.

Comment fonctionne un RAG ?

Dans son principe, le parcours peut être résumé ainsi :

Sources de l’entreprise → préparation et indexation → recherche → informations pertinentes → modèle IA → réponse

Dans un projet réel, chaque étape demande néanmoins quelques choix. La qualité du résultat dépend autant de la manière dont les données sont préparées et recherchées que du modèle utilisé à la fin.

1. Récupérer les données

Tout commence par les informations auxquelles le système doit pouvoir accéder. Reprenons nos 2 000 documents techniques. Ils peuvent être stockés sous forme de PDF, de pages dans une base de connaissances, de données dans un CMS ou provenir de plusieurs outils différents.

Avant de réfléchir au modèle d’IA, il faut déjà savoir quelles informations doivent être utilisées, où elles se trouvent et sous quelle forme elles peuvent être récupérées. Il faut aussi se demander lesquelles font réellement foi. Deux procédures qui donnent des instructions différentes pour le même problème ne deviennent pas plus cohérentes parce qu'une IA les lit.

2. Préparer les contenus

Envoyer systématiquement 2 000 documents au modèle à chaque question serait particulièrement inefficace et, dans beaucoup de cas, techniquement impossible ou inutilement coûteux.

Les contenus sont donc généralement préparés avant d’être utilisés. Cela peut demander d’extraire le texte de certains fichiers, supprimer des éléments inutiles, conserver des métadonnées importantes puis découper les documents en morceaux plus petits.

On parle souvent de chunking. Un manuel de 150 pages peut par exemple être découpé en plusieurs centaines de passages correspondant à des sections, des paragraphes ou des groupes d’informations cohérents. Le découpage n'est pas anodin. Un morceau trop large peut contenir beaucoup d'informations inutiles. Trop petit, il peut perdre le contexte nécessaire pour comprendre ce qu'il raconte.

3. Permettre une recherche par le sens

Une recherche classique fonctionne très bien lorsque l’on connaît les mots présents dans le document. Mais les utilisateurs ne formulent pas nécessairement leurs questions avec les mêmes termes que ceux utilisés dans la documentation.

Imaginez qu'une procédure parle de : « réinitialisation des identifiants d’accès » alors que le collaborateur recherche : « un client a oublié son mot de passe ».

Une recherche reposant uniquement sur des mots identiques peut avoir du mal à faire le rapprochement. C'est là qu'interviennent souvent les embeddings. Sans entrer dans les mathématiques, un embedding est une représentation numérique du sens d’un contenu. Il permet à un système de comparer des textes selon leur proximité sémantique, même lorsqu’ils n’emploient pas exactement les mêmes mots.

Les passages préparés précédemment peuvent ainsi être transformés en embeddings puis enregistrés dans un système permettant de les rechercher efficacement.

4. Stocker et retrouver ces représentations

On rencontre alors souvent le terme de base vectorielle. Son rôle est notamment de stocker ces représentations et de permettre de retrouver rapidement les éléments qui semblent proches d'une question.

Il existe plusieurs manières de mettre en place cette couche de recherche. Une base vectorielle dédiée n'est d'ailleurs pas systématiquement nécessaire : le choix dépend du volume de données, de l'infrastructure existante, des fonctionnalités recherchées et des contraintes du projet. L’important est surtout de comprendre son rôle dans l’ensemble : retrouver les bonnes informations avant d'interroger le modèle.

5. Rechercher les passages pertinents

Notre collaborateur pose maintenant sa question : « Quelle est la procédure lorsqu'un client rencontre le problème X ? »

Le système analyse la demande et lance une recherche dans les données disponibles. Il peut retrouver, par exemple :

• un passage d’une procédure décrivant le problème X ;
• une partie de la documentation du produit concerné ;
• une note précisant une exception pour certains clients.

La recherche peut s'appuyer sur la proximité sémantique, mais pas uniquement. Selon le projet, on peut également utiliser des mots-clés, des filtres, des métadonnées, des catégories ou combiner plusieurs méthodes.

Si le collaborateur travaille sur le produit A, il peut par exemple être utile d'exclure les documents concernant le produit B avant même de comparer leur contenu.

6. Donner le contexte au modèle

Les informations sélectionnées sont finalement ajoutées à la demande envoyée au modèle. Celui-ci reçoit alors quelque chose qui revient, de manière très simplifiée, à :

Voici la question de l’utilisateur. Voici les passages de notre documentation qui semblent pertinents. Réponds en t’appuyant sur ces informations.

Le modèle peut ensuite construire une réponse lisible à partir de ce contexte. On peut également lui demander d'indiquer lorsqu'une information manque, de citer ses sources ou de respecter certaines règles propres à l'application.

Le moteur de recherche et le modèle restent deux choses distinctes. Si la recherche sélectionne une procédure obsolète, passer d'un modèle à un autre ne corrigera pas nécessairement le problème : le nouveau modèle recevra toujours la mauvaise information.

Quelles données peut-on connecter à un RAG ?

L’image du « dossier de PDF connecté à ChatGPT » permet de comprendre rapidement le concept, mais elle devient vite réductrice. Un RAG peut exploiter des informations provenant de nombreuses sources :

• documentation interne ;
• PDF et documents bureautiques ;
• pages web ;
• base de connaissances ;
• CMS ;
• catalogue produit ;
• base de données ;
• CRM ;
• logiciel métier ;
• API ;
• plusieurs de ces sources simultanément.

Toutes les données ne doivent pas forcément être traitées de la même manière. Une documentation technique qui évolue peu peut être préparée et indexée à l’avance. À l'inverse, le statut actuel d’une commande ou le stock disponible d’un produit doit probablement être récupéré directement depuis le logiciel qui détient cette information.

Prenons une question comme :

« Quelle pièce dois-je commander pour réparer le modèle X et en avons-nous actuellement en stock ? »

La documentation permettant d'identifier la pièce peut être recherchée dans une base de connaissances indexée. Le niveau de stock, lui, peut devoir être demandé en temps réel à l'ERP. Un système réel peut donc combiner recherche documentaire, appels à des API, bases de données et règles métier. C'est aussi la raison pour laquelle « connecter une IA à nos données » ne correspond pas à une architecture unique.

RAG, prompt, fine-tuning et entraînement : quelles différences ?

Fournir directement des informations dans le prompt

La solution la plus simple consiste à donner directement au modèle les informations dont il a besoin. Vous pouvez par exemple lui transmettre une procédure de deux pages puis lui poser une question à son sujet.

Pour un petit volume de données connu à l'avance, cela peut parfaitement suffire. Le problème apparaît lorsque l'application doit travailler avec des centaines de documents et déterminer elle-même lesquels sont utiles à chaque demande. Le RAG automatise justement cette recherche de contexte.

Utiliser un RAG

Avec un RAG, l'application recherche dynamiquement les informations pertinentes avant de solliciter le modèle. C'est particulièrement intéressant lorsque les connaissances sont nombreuses, évolutives ou réparties dans différentes sources.

La documentation peut alors être mise à jour indépendamment du modèle. Il faudra éventuellement mettre à jour son indexation, mais pas réentraîner une IA chaque fois qu'une notice change.

Faire du fine-tuning

Le fine-tuning consiste à partir d'un modèle existant et à poursuivre son entraînement sur des exemples spécifiques. Il peut être utile pour apprendre au modèle à mieux reproduire certains comportements, respecter un format particulier ou réaliser une tâche spécialisée de manière plus constante.

En revanche, ce n'est généralement pas la méthode choisie pour lui faire mémoriser toute la documentation d'une entreprise.

Si votre problème est : « je veux que l'IA puisse retrouver la procédure actuelle parmi 5 000 documents », le RAG répond beaucoup plus directement à ce besoin.

Si votre problème est : « je veux que le modèle réalise toujours cette tâche selon ce format et ces exemples », le fine-tuning peut devenir une piste à étudier.

Les deux approches peuvent d'ailleurs être combinées.

Entraîner un modèle

Enfin, entraîner un modèle complet signifie construire ou entraîner beaucoup plus profondément un modèle à partir de grandes quantités de données. On change complètement d'échelle en matière de données, d'infrastructure, de compétences et de coût.

Pour la grande majorité des projets d'entreprise consistant à utiliser des connaissances internes, ce n'est tout simplement pas le sujet.

À quoi peut servir un RAG dans une entreprise ?

Le RAG devient intéressant dès qu'une tâche dépend d'un volume de connaissances suffisamment important pour qu'il ne soit pas raisonnable de tout fournir manuellement à chaque demande.

Un assistant sur la documentation interne

Un collaborateur peut poser une question directement au lieu de parcourir plusieurs espaces de documentation. Le système recherche les procédures pertinentes et construit une réponse en indiquant éventuellement ses sources. L'intérêt dépend évidemment de la qualité de la documentation disponible. Un RAG ne peut pas retrouver une procédure qui n'a jamais été documentée.

Un moteur de recherche technique

Dans une documentation contenant des milliers de pages, la recherche sémantique permet de formuler une question avec ses propres mots. Cela peut être particulièrement utile lorsque la terminologie utilisée par les personnes qui cherchent diffère de celle des personnes qui ont écrit les documents.

Une recherche dans un catalogue complexe

Un catalogue contenant des milliers de références peut être difficile à parcourir avec des filtres traditionnels uniquement. Une recherche sémantique peut aider à retrouver des produits à partir d'un besoin exprimé en langage naturel, puis les données structurées du catalogue peuvent prendre le relais pour filtrer selon des critères précis.

Une aide au support client

Un outil peut rechercher les informations correspondant au problème décrit par un client dans la documentation produit, les procédures de support ou l'historique pertinent. Selon le niveau d'automatisation souhaité, la réponse peut rester une suggestion proposée à un opérateur plutôt qu'être envoyée automatiquement au client.

L'analyse de dossiers ou de contrats

Le même principe peut servir à retrouver des clauses, comparer certains éléments ou identifier les passages utiles dans un ensemble documentaire. Sur des documents juridiques, financiers ou particulièrement sensibles, les exigences de vérification, de traçabilité et de droits d'accès deviennent évidemment centrales.

Une base de connaissances spécialisée dans un outil métier

Le RAG peut aussi être une brique parmi d'autres dans un processus beaucoup plus large. C'est notamment le cas sur le projet La Joaillerie, développé par AZTK.

L'outil traite des informations issues de photos selon un processus comprenant plusieurs étapes : reconnaissance du texte, exploitation de connaissances spécialisées dans la bijouterie, puis contrôle et correction des informations. Une partie de ce système utilise une logique RAG afin de mettre à disposition de l'IA des connaissances propres au domaine au moment du traitement.

Le RAG n'est donc pas nécessairement visible sous la forme d'un chatbot. Il peut fonctionner en arrière-plan d'une fonctionnalité métier très spécifique.

Un RAG peut-il quand même inventer une réponse ?

Oui. Donner au modèle accès à une base de connaissances réduit certains problèmes, mais ne garantit pas que chaque réponse sera exacte. Plusieurs choses peuvent mal se passer.

Les données peuvent être mauvaises

Une procédure obsolète reste une procédure obsolète, même lorsqu'elle est parfaitement retrouvée par le système. Les documents peuvent également être incomplets, contradictoires ou mal structurés.Avant de chercher à améliorer l'IA, il faut parfois commencer par regarder ce qu'on lui donne à lire.

Le bon document peut ne pas être retrouvé

Une information peut exister dans la base sans apparaître parmi les résultats de la recherche. Cela peut venir du découpage des documents, de la manière dont la question a été interprétée, des paramètres de recherche ou de la méthode utilisée pour classer les résultats.

C'est l'une des difficultés principales lors du développement d'un RAG : il ne suffit pas de vérifier que la réponse finale « semble bonne ». Il faut aussi observer quelles informations ont réellement été retrouvées pour comprendre pourquoi le système répond correctement ou non.

Le contexte récupéré peut être insuffisant

Un passage isolé peut perdre une information présente quelques paragraphes plus loin. À l'inverse, transmettre trop de passages peut ajouter du bruit et rendre la réponse moins précise. Il faut donc trouver un équilibre adapté aux documents et aux questions traitées.

Le modèle peut mal utiliser une bonne information

Même avec les bons documents, le modèle reste génératif. Il peut interpréter incorrectement un passage, combiner des éléments qui ne devraient pas l'être ou produire une affirmation qui n'est pas réellement supportée par les sources.

Pour certains usages, on peut réduire ce risque en contraignant davantage la réponse, en exigeant des citations, en ajoutant des contrôles ou en faisant intervenir une validation humaine.

Les droits d'accès doivent suivre les données

Un assistant interne ne doit pas permettre à n'importe quel collaborateur d'obtenir une information simplement parce qu'elle existe quelque part dans la base documentaire.

Si les données sources ont des niveaux d'accès différents, l'architecture du RAG doit en tenir compte.

Un document RH confidentiel, un contrat client et une notice publique ne peuvent pas nécessairement être interrogés avec les mêmes droits.

Les connaissances évoluent

Ajouter une base de connaissances à une application implique aussi de la maintenir.

Lorsqu'un document change, son index doit éventuellement être actualisé. Lorsqu'une source disparaît, les informations correspondantes ne doivent plus continuer à ressortir dans les recherches.

La fréquence et la méthode de synchronisation dépendent beaucoup des sources : une documentation mise à jour deux fois par an ne pose pas les mêmes contraintes qu'un catalogue modifié plusieurs centaines de fois par jour.

Dans quels cas un RAG est-il intéressant ?

Toutes les fonctionnalités IA n'ont pas besoin d'un RAG. Il devient particulièrement pertinent lorsque les réponses ou traitements dépendent d'un corpus de connaissances que le modèle ne possède pas naturellement.

Par exemple lorsque :

• le volume d'informations dépasse ce qu'il est raisonnable de fournir systématiquement dans une demande ;
• les connaissances sont spécifiques à l'entreprise ou à un domaine ;
• les données évoluent régulièrement ;
• l'utilisateur ne sait pas à l'avance quel document contient sa réponse ;
• il est utile de pouvoir identifier les sources utilisées ;
• une recherche classique par mots-clés montre ses limites.

À l'inverse, mettre en place toute une architecture RAG pour interroger trois paragraphes fixes n'a probablement pas beaucoup d'intérêt. Il faut également vérifier que le problème est réellement un problème de connaissance.

Si l'objectif consiste à déclencher une action dans un logiciel, modifier une fiche CRM ou enchaîner plusieurs tâches, on se rapproche davantage de problématiques d'outils, d'API et éventuellement d'agents IA.

Si la réponse dépend d'une donnée structurée et précise comme un prix, un stock, un statut, une requête directe dans la base de données ou l'API concernée peut être préférable à une recherche sémantique. Ces approches peuvent ensuite être combinées dans une même application.

Comment développer un RAG adapté aux données de son entreprise ?

Le choix du modèle est souvent la première question posée : OpenAI, Claude, Gemini, Mistral... Elle compte, évidemment. Mais elle arrive rarement seule.

Pour construire un système fiable, il faut aussi regarder les données disponibles, leur format, leur qualité, la fréquence à laquelle elles évoluent, les questions réellement posées par les utilisateurs et le niveau de précision attendu. Un projet commence donc souvent par des questions beaucoup moins spectaculaires :

À partir de là, il devient possible de choisir la stratégie d'indexation, le type de recherche, les éventuels filtres, le modèle utilisé pour produire la réponse et les mécanismes de contrôle.

Il faut également tester le système sur de vraies questions. Pas uniquement sur les cinq exemples qui ont servi à concevoir la démonstration, mais sur des formulations imprécises, des cas limites, des questions dont la réponse n'existe pas et des situations où plusieurs documents se contredisent.

Le RAG est surtout un problème de données et de recherche

Le RAG permet de construire des applications capables de travailler avec des connaissances que le modèle d'IA ne possède pas. Mais « connecter une IA à ses données » cache plusieurs sujets : récupérer les bonnes sources, les préparer, retrouver les bons passages, gérer les mises à jour, respecter les droits d'accès puis donner au modèle suffisamment de contexte pour qu'il puisse répondre.

Le modèle intervient donc à la fin d'une chaîne plus large. Si le système retrouve une ancienne procédure au lieu de la version actuelle, utiliser un modèle plus puissant ne changera pas la source qui lui a été fournie.

Pour évaluer un projet RAG, la question n'est donc pas uniquement « quel modèle allons-nous utiliser ? ». Il faut aussi pouvoir répondre à une question beaucoup plus concrète : lorsqu'un utilisateur pose une question, comment notre système va-t-il retrouver l'information dont il a réellement besoin ?

C’est souvent là que se joue la qualité d’un projet RAG !