RAG en entreprise : retrouver l'information sans réentraîner un modèle

Un assistant qui répond à partir des procédures, contrats et notes de l'entreprise paraît souvent plus simple qu'il ne l'est. Le raccourci est tentant : on verse les documents dans un modèle, puis on pose des questions. Or le modèle ne devient pas, par ce geste, le dépositaire fiable d'un patrimoine documentaire. Il faut d'abord savoir quel document il doit consulter, quelle version fait foi et ce que l'utilisateur a le droit de voir.

C'est précisément le rôle du RAG, pour retrieval-augmented generation. L'expression désigne une architecture dans laquelle le système cherche des passages dans un corpus avant de demander au modèle de formuler une réponse. Le principe a été formalisé dans un travail de recherche sur la génération augmentée par récupération. En entreprise, son intérêt ne tient pas au sigle : il évite de confondre la connaissance générale d'un modèle avec les règles propres à une organisation.

Un RAG bien conçu ne promet donc pas que la machine « sait » tout. Il met en place une chaîne de consultation. Une question arrive, le système identifie les passages pertinents, les transmet au modèle avec des instructions, puis présente une réponse qui doit renvoyer vers ses sources. C'est une différence de nature. La réponse peut être utile parce qu'elle est vérifiable, et non parce qu'elle a l'air convaincante.

Le RAG répond à un problème de recherche, pas à tous les problèmes de l'IA

Prenons une direction commerciale qui cherche la procédure applicable à une remise exceptionnelle. Le document pertinent peut être une note mise à jour la veille, perdue parmi des dossiers très proches. Sans recherche, un assistant généraliste n'a aucune raison de connaître cette règle. Avec un RAG, il peut retrouver le passage, en indiquer le titre et aider à le reformuler. Il ne remplace pas la source ; il réduit le temps nécessaire pour y revenir.

Cette mécanique explique pourquoi un RAG est souvent préférable au réentraînement pour des documents qui changent. Modifier une procédure ne devrait pas déclencher un chantier de modèle. Il doit suffire de réindexer le document, d'archiver l'ancienne version et de rendre la nouvelle disponible. Le modèle reste une brique de langage ; le corpus reste la référence. Pour un premier périmètre, un cadrage de projet IA sert surtout à établir cette frontière : quelles données alimentent la réponse, qui les maintient et quel résultat sera considéré comme acceptable.

Le RAG ne supprime pas les erreurs. Si la recherche ramène un mauvais passage, si le document est obsolète ou si la question dépasse les sources disponibles, le modèle peut produire une réponse fragile. Il faut donc lui permettre de dire qu'il ne sait pas, d'afficher les extraits utilisés et de ne pas répondre hors périmètre. Le cadre de gestion des risques de l'IA du NIST rappelle une discipline utile : gérer les risques dans la conception, le déploiement et l'évaluation, plutôt que les découvrir une fois l'outil ouvert à tous.

La qualité du corpus décide de la qualité des réponses

Le mot « document » masque plusieurs difficultés. Un PDF scanné, un tableau de prix, une procédure contradictoire et une boîte mail ne se découpent pas de la même manière. Les découper en fragments trop courts fait disparaître les conditions et les exceptions. Les garder trop longs dilue la recherche et surcharge le contexte envoyé au modèle. Il n'existe pas de réglage universel ; il faut tester le corpus réel et des questions réelles.

Vient ensuite le sujet que les démonstrations évitent volontiers : les droits d'accès. Un assistant RH ne doit pas retrouver une note de rémunération parce qu'elle ressemble sémantiquement à une question générale sur les salaires. Les autorisations doivent être appliquées avant la génération, au niveau des documents et, lorsque c'est nécessaire, de leurs fragments. Les recommandations de la CNIL sur le développement de systèmes d'IA invitent à intégrer la protection des données dès la conception. Dans un RAG, cela se traduit par des sources identifiées, des rôles définis et une conservation des traces adaptée au cas d'usage.

Le test ne peut pas se réduire à quelques questions écrites par l'équipe projet. Il faut constituer un jeu de questions représentatives : celles auxquelles l'assistant doit répondre, celles auxquelles il doit renvoyer vers un humain, et celles auxquelles il ne doit pas avoir accès. On mesure alors la qualité de la récupération, la fidélité de la réponse au passage retrouvé et la lisibilité des sources. Une réponse brève avec une citation précise vaut mieux qu'une synthèse élégante impossible à contrôler.

Commencer par une source de vérité identifiable

Le premier projet RAG pertinent ne couvre pas « toute la connaissance de l'entreprise ». Il part d'un corpus borné, déjà utile et dont un responsable accepte d'assumer la mise à jour. Documentation produit, procédures de support ou référentiel qualité : le bon candidat est celui où la recherche prend du temps et où une réponse erronée peut être détectée.

Cette approche laisse aussi une place aux choix d'infrastructure. Selon la sensibilité des données, le niveau de contrôle attendu et les outils déjà en place, l'hébergement et les connecteurs ne seront pas les mêmes. Les enjeux abordés par l'hébergement souverain des modèles et des données ne disparaissent pas parce que le système se limite à de la recherche documentaire. Ils doivent être décidés avant la connexion au corpus, pas après.

Le RAG devient intéressant lorsqu'il remet l'information de l'entreprise au centre de la réponse et rend possible son contrôle. Pour y parvenir, la question n'est pas seulement « quel modèle choisir ? ». Elle est plus exigeante : quelle source de vérité veut-on rendre consultable, par qui, et avec quelle preuve ?