RAG IA : faites parler vos données d’entreprise

Un assistant qui répond à partir de vos documents, en citant ses sources.

Le RAG, pour retrieval augmented generation, se traduit par génération augmentée par récupération ou génération par enrichissement contextuel. Cette architecture RAG fait répondre une intelligence artificielle générative à partir de vos propres documents plutôt que de ses connaissances générales. Avant de rédiger, les systèmes RAG effectuent une recherche sémantique pour retrouver les informations pertinentes dans votre base, puis le modèle formule sa réponse à partir de ces informations récupérées en indiquant leurs sources. C’est la différence entre un consultant qui improvise et un collaborateur qui ouvre le bon classeur avant de vous répondre. Graciet & Co met en œuvre ces dispositifs avec Ocade RAG, la solution développée par Ocade Fusion.

Qu’est-ce que le RAG en intelligence artificielle ?

Un modèle de langage seul, un LLM comme GPT ou ses équivalents, sait parler de tout sauf de vous. Ces modèles de langage, ou LLM, ignorent vos documents, ne citent aucune source et comblent les vides en inventant : leurs connaissances s’arrêtent à leurs données d’entraînement. La génération augmentée par récupération remplace cette improvisation par une réponse tirée de vos fichiers, vérifiable ligne à ligne. Le RAG améliore la précision des réponses en les ancrant dans des sources de connaissances externes au modèle.

Face à une intelligence artificielle, le vrai problème n’est pas l’hallucination, un humain se trompe aussi, mais l’impossibilité de vérifier. Le RAG rend l’IA auditable, ce qui débloque les usages qui engagent l’entreprise et fonde une confiance accrue des utilisateurs.

Un second effet du RAG est souvent décisif : la base de connaissances se met à jour sans réentraîner le modèle. Un changement de tarif ou de procédure est répercuté le jour même, là où les données d’entraînement d’un modèle restent figées.

Quelle différence avec un modèle affiné sur vos données ?

La confusion entre RAG et réglage fin vient d’une fausse symétrie : on croit choisir entre deux façons de faire apprendre vos données à l’IA. En réalité, le réglage fin n’enseigne pas des connaissances, il enseigne un comportement, un ton, un format. Le RAG, lui, apporte les connaissances. Ce ne sont pas deux options concurrentes, ce sont deux étages différents.

La règle de décision tient en deux cas. Si le problème est « l’IA ne connaît pas nos informations », c’est du RAG. Si le problème est « l’IA connaît nos informations mais ne les formule pas comme nous », c’est du réglage fin, et c’est rare.

En entreprise, le RAG l’emporte presque toujours pour une raison prosaïque : vos données bougent. Modifier un tarif dans une base RAG, c’est remplacer un fichier ; le corriger dans un modèle affiné suppose de relancer tout l’entraînement. Et l’ancien tarif reste malgré tout dissous quelque part dans le modèle, sans qu’on puisse le localiser ni l’effacer. S’ajoutent trois écarts décisifs : les modèles RAG citent leurs sources, ils permettent de retirer une information de la base, et ils coûtent nettement moins cher à mettre en œuvre. C’est pourquoi l’utilisation du RAG dans les systèmes d’entreprise s’est imposée plus vite que le réglage fin.

Comment fonctionne un système RAG ?

Une architecture RAG combine deux mécanismes que tout oppose : la récupération d’informations pertinentes et la génération de texte. Le RAG, génération augmentée par récupération, doit sa qualité à la première autant qu’à la seconde. Le modèle de récupération d’informations cherche, le modèle de génération rédige. Un RAG fonctionne en deux phases. La première prépare la base et ne s’exécute qu’au démarrage, puis à chaque mise à jour de vos documents. La seconde se rejoue intégralement à chaque question posée.

Découper : vos documents sont d’abord découpés en passages autonomes. C’est l’étape la plus déterminante et la plus sous-estimée : un découpage mal fait coupe une procédure en deux, et le système ne retrouvera jamais la bonne réponse.

Indexer : ces passages sont ensuite indexés dans une base vectorielle, où vos données deviennent des représentations numériques appelées embeddings. Ces embeddings autorisent une recherche sémantique, par le sens et non par les mots exacts. Un utilisateur qui demande « combien de temps pour être remboursé » retrouve ainsi un passage intitulé « délai de traitement des avoirs ».

Chercher : le RAG effectue une recherche sémantique qui compare l’embedding de la question à ceux des passages et remonte les plus proches par le sens. Cette récupération d’informations pertinentes conditionne tout ce qui suit.

Trier : sur vingt passages remontés, le RAG conserve les cinq réellement pertinents. C’est ce filtre, le réordonnancement, qui sépare un RAG correct d’un RAG qui répond à côté.

Rédiger : le modèle de génération formule la réponse à partir des informations récupérées uniquement. Les passages retenus deviennent son contexte de travail, et les sources sont indiquées. Un travail de prompt engineering encadre cette étape : la consigne donnée au modèle détermine s’il s’autorise ou non à sortir des documents fournis.

Vérifier : citer une source ne prouve rien, encore faut-il qu’elle dise ce que la réponse affirme. Le système compare chaque affirmation aux passages qui l’ont produite. Ce qui ne s’y trouve pas est signalé au lieu d’être affiché.

Les embeddings sont une façon de ranger vos textes par sujet plutôt que par mots : chaque passage devient un point dans un espace où la proximité traduit la proximité de sens. Le système sait ainsi que les expressions « je n’arrive pas à me connecter » et « réinitialiser son mot de passe » traitent de la même chose, alors qu’elles n’ont aucun mot en commun. C’est cette recherche sémantique qui permet de trouver la bonne réponse même quand l’utilisateur emploie d’autres mots que ceux du document.

Vos documents peuvent-ils alimenter un assistant ?

Nous regardons vos documents avant de parler d’outil. Un premier échange suffit à savoir si le sujet tient.

Prendre contact

Pourquoi le découpage des documents décide de tout

Les systèmes RAG ne lisent jamais vos documents en entier : ils ne voient que les informations récupérées. Un passage mal découpé est un passage définitivement perdu, quelle que soit la qualité du modèle derrière.

Trois façons de rater le découpage d’un document se retrouvent dans la quasi-totalité des projets que nous reprenons.

Couper au milieu d’une idée

Une procédure en six étapes tranchée après la troisième produit une réponse à moitié fausse, le pire cas parce qu’elle a l’air complète.

Découper trop large

Un chapitre entier remonté pour une question précise noie l’information utile.

Perdre le contexte

Un passage qui dit « le délai est de 15 jours » sans préciser de quoi il parle est inexploitable une fois sorti de son document. L’enrichissement contextuel consiste précisément à rendre chaque passage porteur de son propre contexte.

Un seul critère commande donc le découpage : un passage doit être compréhensible seul, par quelqu’un qui n’a pas lu le reste. Ce critère est éditorial avant d’être technique.

Découper un document pour un RAG rejoint exactement le travail que nous menons pour la visibilité dans les moteurs génératifs : un contenu cité par une IA est un contenu dont chaque section se tient seule. Les deux relèvent de la même discipline éditoriale. Un RAG bien construit commence rarement par du code.

Huit applications concrètes du RAG en entreprise

Une base de connaissances interrogeable permet de construire des chatbots et assistants virtuels ainsi que des agents connectés à vos systèmes.

Chatbot documentaire

Un assistant qui répond aux questions à partir d’une base de connaissances choisie, en citant ses sources, c’est le point d’entrée le plus fréquent, et le plus exigeant. Il ne se juge pas au taux de bonnes réponses, mais à ce qu’il fait quand il ne sait pas : un assistant qui répond à 70 % des questions et oriente clairement pour le reste est adopté dès la première semaine.

Agents connectés

Un chatbot lit et répond ; un agent interroge vos systèmes en direct, ERP, CRM, agenda, et peut interagir avec eux. Le chatbot vous dit ce que prévoit la procédure de retour, l’agent vous dit où en est votre colis. Ocade RAG expose ses conversations à vos systèmes métier, l’orchestration étant confiée à n8n.

Génération de documents

Le RAG produit une proposition commerciale ou une réponse à appel d’offres à partir de vos contenus existants. Le gain n’est pas dans la rédaction mais dans la recherche : le temps passé à retrouver la fiche méthodologie de l’an dernier ou la formulation déjà validée.

Rédaction assistée

Ocade RAG s’expose comme source documentaire via un connecteur MCP : votre base devient interrogeable depuis l’assistant que vos équipes utilisent déjà. Rien à réapprendre, aucun copier-coller. C’est l’usage le plus adopté, parce qu’il ne demande aucun changement d’habitude.

Plugins et extensions métier

Un RAG n’a de valeur que là où le travail se fait. Nous amenons l’assistant dans les outils en place : site WordPress, outils métier, interfaces sur mesure quand ni un chat ni un formulaire ne conviennent. Le socle reste toujours le même, Ocade RAG : une seule base, plusieurs points d’entrée.

Qualité et scoring

Révisions et quiz

Ocade RAG génère des questionnaires depuis votre base : intégration des nouveaux arrivants, contrôle des acquis après formation. Un questionnaire d’intégration demande une journée de rédaction et se périme dès que l’offre bouge. Ici, il se régénère depuis les documents à jour en quelques minutes.

Gouvernance et coûts

Un RAG ne se livre pas, il se pilote : coût, usages, qualité des réponses, conformité. Le journal des requêtes est l’instrument principal, et il révèle bien plus que prévu : les questions sans réponse indiquent ce qui manque dans la base, les questions répétées ce qui devrait être expliqué ailleurs, sur votre site ou dans une procédure.

Préparer les données : le vrai travail d’un projet RAG

La qualité d’un RAG se joue avant l’outil, sur quatre chantiers documentaires que les projets sous-estiment presque toujours.

L’approche courante d’un projet RAG consiste à brancher un serveur de fichiers entier et à laisser le système se débrouiller. Elle produit des assistants qui répondent avec une procédure abrogée ou un tarif de l’an dernier, sans que rien ne signale l’erreur.

Ocade RAG prend le chemin inverse : ce qui n’est pas maîtrisé n’entre pas dans la base de connaissances. Chaque source a un propriétaire identifié, une date et un statut. Un fonds documentaire trié bat toujours dix mille PDF déversés en vrac.

La reprise éditoriale rend chaque passage compréhensible seul, ce qu’on appelle son enrichissement contextuel : expliciter les sujets, remplacer les renvois, dater les informations périssables. Ce travail ne disparaît pas avec un meilleur modèle : aucune version future de l’IA ne devinera laquelle de vos trois procédures fait foi. C’est une décision d’entreprise, pas un problème technique.

Cette reprise éditoriale produit une valeur qui dépasse le projet RAG : un fonds documentaire trié, daté, avec des propriétaires identifiés est un actif que vous gardez, quel que soit l’outil derrière.

Dans la plupart des systèmes RAG, la base est une copie synchronisée d’un serveur de fichiers. Cette architecture produit la panne la plus fréquente en production : un document supprimé du serveur reste dans la base et continue d’alimenter les réponses, sans que personne ne le remarque.

Dans Ocade RAG, la base de connaissances n’est pas une copie : c’est l’original. Vous déposez et modifiez vos documents directement dans l’outil. Modifier un document, c’est mettre à jour la base ; le supprimer, c’est le retirer des réponses.

Dans un RAG, le risque n’est pas qu’un salarié ouvre un fichier interdit, c’est qu’il en obtienne le contenu sans jamais voir le fichier. Une grille salariale reste dans un dossier verrouillé, mais l’assistant en a lu le contenu et le restitue en une phrase. La fuite passe par la réponse, sans laisser de trace d’accès au document.

La solution courante consiste à tout indexer dans une base unique, puis à masquer ce que chaque utilisateur n’a pas le droit de voir. Elle est séduisante sur le papier et fragile à l’usage : le système a déjà lu la donnée sensible, et il suffit d’une erreur de configuration ou d’une question formulée autrement pour la faire ressortir.

Ocade RAG sépare plutôt les bases, à raison d’une par métier. Le service client, les achats et la documentation technique disposent chacun de leur propre espace de travail, avec ses propres documents. Le système ne peut pas divulguer ce qu’il n’a jamais lu.

Le marché : que proposent les grandes plateformes ?

AWS, Microsoft, Google et IBM vendent la même brique RAG intégrée à leur cloud : base vectorielle, modèle d’embeddings, recherche sémantique et génération. Ces offres sont excellentes pour une entreprise déjà installée chez eux.

AWS propose le RAG comme un service parmi d’autres, pour les équipes techniques déjà installées chez lui. Microsoft Azure est le mieux placé sur la bureautique : l’assistant lit là où les documents vivent déjà. Google Cloud met en avant la qualité de la recherche sémantique elle-même, héritage de son métier d’origine, et le traitement du NLP sur de gros volumes hétérogènes. IBM met en avant la gouvernance avant la performance, ce qui convient particulièrement aux secteurs régulés.

Ces quatre offres sont solides et nous ne prétendons pas faire mieux sur leur terrain. Elles supposent simplement que vos documents vivent déjà chez elles, et relèvent toutes de sociétés de droit américain, quel que soit le pays où sont physiquement les serveurs.

Ce qu’il faut regarder avant de signer avec une plateforme RAG

On ne mesure pas l’enfermement en arrivant, mais le jour où l’on veut partir. Ce qui vous retient n’est pas le contrat : c’est tout le travail accompli sur vos documents, le tri, les règles de découpage, les réglages obtenus par itérations successives. Rien de cela ne se transfère d’une plateforme à l’autre. Changer de prestataire ne coûte pas un préavis, cela coûte de refaire le projet.

Avant de signer avec une plateforme, la bonne question n’est donc pas « combien ça coûte » mais « qu’est-ce que j’emporte si je pars ».

Le second point à examiner est le mode de facturation. Le coût à l’usage récompense l’échec et punit le succès : plus l’assistant est utilisé, plus il coûte. On finit par restreindre l’usage pour tenir le budget, c’est-à-dire par brider l’outil qu’on vient de payer.

Soyons honnêtes : nous n’échappons pas complètement à cette facturation au volume. Tant que la génération des réponses passe par un modèle appelé à distance, elle reste proportionnelle à l’usage, chez nous comme chez les grandes plateformes.

La différence entre ces plateformes et notre dispositif porte sur l’étendue de ce qui varie. Chez elles, tout est facturé à l’usage : l’indexation, le stockage, la recherche, l’hébergement et la génération. Chez nous, l’infrastructure est à prix fixe et seule la génération des réponses varie. C’est une part de la facture au lieu de la totalité.

Ce que nous faisons différemment

Sur un projet RAG, notre différence ne se situe pas sur la technologie : les briques sont accessibles à tout le monde.

Nous travaillons les documents, pas seulement l’outil

Trier, écarter les versions obsolètes, identifier les propriétaires, découper selon la logique du document : c’est le travail le moins spectaculaire et le plus long. Verser un dossier partagé dans un outil produit une démonstration réussie le premier jour et un assistant abandonné au troisième mois.

Nous réglons le comportement métier par métier

Le comportement d’un assistant se paramètre selon le métier qu’il sert. Un assistant juridique doit citer ses sources et refuser de conclure sans elles ; un assistant service client doit aller droit au but. La plupart des déploiements gardent la configuration par défaut, celle qui répond toujours, y compris quand elle ne sait pas.

Nous maîtrisons l’outil que nous livrons

Ocade RAG est développé par Ocade Fusion, notre société sœur. Cette maîtrise nous permet d’adapter le dispositif au besoin plutôt que d’adapter le besoin à une plateforme, et de placer le curseur de souveraineté là où le client en a réellement besoin, jusqu’à l’installation entièrement locale. Un intégrateur qui revend une solution cloud ne peut proposer que ce que son fournisseur a prévu.

Nous savons dire qu’un RAG n’est pas la réponse

Quand le problème vient d’une procédure illisible ou d’une organisation à clarifier, nous le disons au client, quitte à ne pas vendre le projet. Sur un marché où tout le monde propose la même chose, c’est ce qui distingue un conseil d’un catalogue.

Nous restons après la livraison

Un dispositif documentaire vit : les documents changent, les usages se déplacent, les modèles évoluent. Nous formons les équipes, mesurons la qualité des réponses dans la durée et ajustons les réglages. Un assistant livré puis abandonné se dégrade en quelques mois : c’est la première cause d’échec que nous rencontrons, bien avant la technique.

Par où commencer votre projet RAG

Nous ne recommandons jamais de démarrer un projet RAG en équipant toute l’entreprise d’un coup. Le premier chantier est un pilote sur un seul service, choisi pour produire un résultat visible rapidement : celui qui répond souvent aux mêmes questions, sur un fonds documentaire délimité et déjà à peu près à jour.

01 · État des lieux du fonds

Quels documents, qui en est propriétaire, de quand ils datent, qui a le droit de les lire. C’est court, et c’est là que se décide la réussite du reste.

02 · Préparation

Tri, mise à l’écart des versions obsolètes, découpage, reformulation de ce qui est illisible.

03 · Mise en service

Paramétrage métier de l’espace et constitution d’un jeu de questions de référence qui servira à mesurer la qualité.

04 · Usage réel et réglage

Une phase d’usage avec les utilisateurs concernés, pendant laquelle nous ajustons les réglages sur la base de leurs retours.

Deux points d’entrée sont à écarter formellement : ouvrir l’assistant à toute l’entreprise d’un coup, ou le brancher sur l’ensemble du serveur de fichiers. Les deux produisent des réponses approximatives et une confiance perdue en quelques semaines.

Ocade RAG, la solution que nous mettons en œuvre

Ocade RAG est la solution de génération augmentée par récupération développée par Ocade Fusion et déployée par Graciet & Co. Elle réunit dans un même outil la base de connaissances, le découpage, la recherche sémantique, la vérification des réponses et le banc d’essai qui mesure la qualité.

Son parti pris tient en trois points : des espaces de travail cloisonnés par métier, une base documentaire que vous administrez vous-même, et un curseur de souveraineté réglable jusqu’au modèle installé localement.

Demander une démonstration

Parlons de votre projet

Un pilote sur un espace métier, mesuré sur vos propres questions, avant tout engagement lourd.

Nous vous répondons sous 24 heures ouvrées.

Contactez-nous

Champs obligatoires (*)

Formulaire de contact

« * » indique les champs nécessaires

Pour en savoir plus sur les modalités de traitement de vos données, veuillez consulter notre politique de confidentialité relative à la protection de vos données personnelles récoltées par l’intermédiaire de ce site.

Questions fréquentes sur le RAG

Oui. Le RAG réduit fortement les hallucinations, il ne les supprime pas, et prétendre le contraire est le mensonge le plus répandu du marché. Le modèle peut combler un vide quand les informations récupérées ne couvrent que 80 % de la question, tirer d’une source juste une conclusion qu’elle ne contient pas, ou s’appuyer sur un document périmé. Le RAG améliore la précision sans la garantir.

Le déplacement à retenir tient en deux phrases. Sans RAG, une réponse fausse est indétectable ; avec RAG, elle est vérifiable. Le RAG ne rend pas l’IA infaillible, il la rend contrôlable.

Un RAG entièrement souverain, hébergé chez le client, est réaliste aujourd’hui, mais pas gratuitement ni pour tous les usages. Ocade RAG fonctionne aussi avec un modèle de langage installé localement : aucune donnée ne sort de l’entreprise, et plus rien ne se facture à la question.

L’arbitrage d’un dispositif souverain porte sur la performance. Un modèle local demande une machine adaptée et rend des réponses un peu moins fines que les meilleurs modèles du marché. Mais la qualité d’un RAG dépend davantage de la préparation des documents que de la puissance du modèle : un fonds documentaire bien trié avec un modèle local répond mieux qu’un fonds en vrac avec le meilleur modèle du monde.

La souveraineté d’un dispositif RAG n’est d’ailleurs pas binaire. On peut garder chez soi les documents, la base et l’indexation, donc l’essentiel du patrimoine, et n’appeler un modèle extérieur que pour la rédaction des réponses.

Un système RAG ne sait pas ce qui n’est pas écrit : l’essentiel du savoir d’une entreprise est dans la tête des gens. Il ne révèle pas ce savoir, il révèle son absence. Il compte mal, aussi : les questions portant sur un ensemble, « combien de contrats arrivent à échéance », appellent une requête sur une base de données. Il croise mal plusieurs documents éloignés. Et il n’arbitre pas les contradictions.

Le cas le plus instructif est celui où le dispositif déçoit alors que tout a été bien fait : le vrai problème n’était pas l’accès à l’information.

Un dispositif RAG se chiffre au cas par cas, pour une raison précise : l’écart de coût entre deux projets vient rarement de la technique, il vient de l’état des documents. Deux entreprises de taille identique peuvent différer d’un facteur cinq.

Trois postes composent le budget : la mise en place, dont la part documentaire domine ; le fonctionnement mensuel, proportionnel à l’usage ; et la maintenance de l’infrastructure, récurrente et systématiquement oubliée des comparatifs. Bonne nouvelle sur le deuxième poste : le réglage qui répond le mieux est aussi le moins cher.

Quand la donnée est structurée, une base de données fait mieux. Quand il y a peu de documents, un moteur de recherche suffit. Quand la réponse est toujours la même, un contenu bien écrit fait mieux. Quand l’enjeu ne tolère aucune erreur, l’humain reste la réponse.

Et le cas que nous rencontrons le plus souvent : quand le problème n’est pas l’information. Un RAG posé sur un problème d’organisation le rend visible sans le régler.

La qualité d’un RAG ne se mesure pas d’un bloc : quatre indicateurs se regardent séparément. Le bon passage a-t-il été retrouvé ? Si non, tout le reste est sans objet. La réponse s’appuie-t-elle réellement dessus ? Est-elle complète ? Et le refus fonctionne-t-il, sur des questions volontairement hors périmètre ?

Ce dernier indicateur, la capacité de l’assistant à dire qu’il ne sait pas, est le meilleur prédicteur de l’adoption. Il n’est presque jamais mesuré.

L’essentiel à retenir

Le RAG, retrieval augmented generation ou génération augmentée par récupération, fait répondre une intelligence artificielle générative à partir de vos documents plutôt que de ses connaissances générales. Les systèmes RAG découpent et indexent votre base en embeddings, puis associent RAG et recherche sémantique pour retrouver les informations pertinentes à chaque question, avant de rédiger une réponse sourcée et vérifiable.

Huit applications découlent d’une base de connaissances interrogeable : chatbot documentaire, agents connectés, génération de documents, rédaction assistée, extensions métier, banc d’essai qualité, questionnaires et gouvernance.

Dans un projet RAG, la difficulté n’est presque jamais technique. Elle tient à l’état de vos documents : un fonds bien trié avec un modèle modeste répond mieux qu’un fonds en vrac avec le meilleur modèle du monde.