Le RAG expliqué aux dirigeants de PME : brancher l'IA sur vos propres documents

Le problème que le RAG résout

Un modèle de langage a été entraîné sur des textes publics, à une date donnée. Il ne connaît ni vos contrats, ni vos procédures, ni l'historique de vos clients. Si vous lui posez une question sur votre entreprise, il produira une réponse plausible et fausse, avec le même aplomb que pour une réponse juste. C'est le comportement qui a durablement grillé l'IA auprès de beaucoup de dirigeants.

Le RAG, pour Retrieval-Augmented Generation, littéralement génération augmentée par la recherche, corrige cela par une idée simple : on ne demande pas au modèle de savoir, on lui donne à lire. Avant de répondre, le système va chercher dans vos documents les passages pertinents, puis demande au modèle de répondre en s'appuyant uniquement sur ces passages, en citant ses sources.

Comment ça marche, sans jargon

1. On découpe vos documents en morceaux de taille raisonnable, un paragraphe ou une section. Un contrat de 40 pages devient quelques dizaines de morceaux autonomes.
2. On calcule une empreinte de sens pour chaque morceau. C'est une suite de nombres qui situe le texte dans un espace où deux textes de sens proche sont proches. C'est ce qui permet de retrouver « délai de résiliation » quand la question dit « comment on arrête le contrat ».
3. On stocke ces empreintes dans une base spécialisée.
4. À la question posée, on calcule la même empreinte et on récupère les morceaux les plus proches.
5. On assemble la réponse : le modèle reçoit la question et ces morceaux, avec la consigne de répondre à partir d'eux et de dire quand l'information n'y est pas.

Ce que ça change concrètement dans une PME

• La recherche interne devient une conversation. Plutôt que de chercher le bon fichier, on pose la question et on obtient la réponse avec le lien vers la source.
• L'onboarding s'accélère. Un nouvel arrivant interroge la mémoire de l'entreprise au lieu de mobiliser un collègue pour chaque question.
• Les savoirs des experts survivent à leur départ, à condition d'avoir été écrits quelque part avant.
• Les réponses clients se standardisent sur ce qui est réellement écrit dans vos contrats et procédures, pas sur le souvenir de chacun.

Les conditions de réussite, et elles sont exigeantes

Le RAG ne compense pas l'absence de matière. C'est le point que nous répétons le plus souvent en cadrage, parce qu'il détermine le résultat plus que tout choix technique.

• Il faut des documents. Si le savoir est dans les têtes, il faut le mettre par écrit avant. Aucun outil ne lit dans les pensées.
• Il faut une seule version de la vérité. Trois versions d'une procédure dans trois dossiers différents produisent un système qui répond au hasard, et une réponse au hasard est pire qu'aucune réponse.
• Il faut gérer les droits d'accès. Un assistant qui répond à tout le monde sur les salaires est un incident, pas une fonctionnalité. Les droits doivent s'appliquer à la recherche, pas seulement à l'affichage.
• Il faut entretenir. Un document mis à jour doit être réindexé, sinon le système répond avec la version d'avant, sans le signaler.

Où passent vos données

Trois éléments sortent potentiellement de chez vous : les documents envoyés au calcul d'empreintes, la question de l'utilisateur, et les passages transmis au modèle pour rédiger la réponse. Selon votre exigence, on peut tout garder en interne avec des modèles auto-hébergés, ou n'externaliser que la génération vers une API dont les conditions contractuelles excluent l'entraînement sur vos données. Ce sont deux niveaux de coût et de qualité différents, et c'est un arbitrage de direction, pas un choix technique.

Notre pratique par défaut : la base documentaire et l'index restent sur votre infrastructure ou sur des serveurs en France, la génération passe par une API avec un engagement contractuel de non-réutilisation. Quand la sensibilité l'impose, tout reste en interne.

Faut-il faire du RAG, ou autre chose ?

Le RAG répond bien aux questions dont la réponse est écrite quelque part. Il répond mal à trois familles de besoins, et les confondre est la cause d'échec la plus fréquente.

• Les questions de calcul sur des données structurées (« quel chiffre d'affaires ce mois-ci ») relèvent d'une requête dans votre base, pas d'une recherche sémantique.
• Les questions qui exigent une synthèse de tout le corpus (« quels sont les thèmes récurrents dans nos réclamations ») demandent un traitement par lots, pas une recherche des dix passages les plus proches.
• Les actions (« crée le devis ») relèvent d'une automatisation avec des règles, éventuellement déclenchée par l'assistant, mais pas du RAG lui-même.

En pratique, un système utile combine les trois : de la recherche documentaire pour ce qui est écrit, des requêtes pour ce qui est chiffré, et de l'automatisation pour ce qui doit être fait. Le sujet n'est pas de choisir la technique, il est de savoir laquelle s'applique à quelle question.

Par où commencer

Choisissez un corpus étroit et à forte valeur : les procédures d'un service, la documentation d'un produit, l'historique des réponses clients. Vérifiez que ce corpus est à jour et unique. Construisez un premier assistant sur ce périmètre, mesurez le taux de réponses justes sur une trentaine de questions réelles posées par les équipes, et n'élargissez qu'ensuite. Un assistant excellent sur un domaine est adopté ; un assistant moyen sur tout est abandonné en trois semaines.

Questions fréquentes