RAG en entreprise : pourquoi c'est un tournant

Il existe peu de sujets techniques dont la compréhension par les directions générales soit aussi décisive que celle du RAG. Derrière cet acronyme — retrieval-augmented generation, génération augmentée par la recherche — se cache une idée simple : plutôt que de demander à un modèle de langage de répondre à partir de ce qu'il a mémorisé pendant son entraînement, on lui fournit les documents pertinents au moment de la question et on lui demande de répondre à partir d'eux.

Cette nuance paraît technique. Elle change pourtant la nature même de ce que l'IA peut faire dans une entreprise.

Un modèle généraliste, aussi puissant soit-il, ne connaît ni vos procédures internes, ni vos contrats clients, ni l'historique de vos décisions techniques. Interrogé sur ces sujets, il produit une réponse plausible et souvent fausse — ce que l'on appelle une hallucination, terme malheureux qui donne l'impression d'un dysfonctionnement alors qu'il s'agit du comportement normal d'un système entraîné à produire du texte vraisemblable. Le RAG déplace le problème : le modèle ne devine plus, il lit. Sa réponse s'appuie sur des documents identifiables, et il devient possible de citer la source.

C'est cette traçabilité, plus que la qualité des réponses, qui fait du RAG un tournant en entreprise. Une réponse juste mais invérifiable a peu de valeur dans un contexte professionnel : personne ne prendra une décision d'investissement, ne répondra à un client ou ne signera un document sur la base d'une affirmation dont l'origine est inconnue. Un système capable de dire « voici la réponse, et voici le paragraphe du contrat sur lequel elle se fonde » entre dans une catégorie différente. Il devient auditable, contestable, et donc utilisable dans des processus qui engagent l'organisation.

Cela dit, l'expérience de terrain conduit à tempérer l'enthousiasme sur un point précis. Le RAG n'est pas une technologie difficile à mettre en œuvre — un prototype fonctionnel se construit en quelques jours. Ce qui est difficile, c'est tout ce qui l'entoure.

L'illustration qui suit est un condensé : elle rassemble des situations distinctes en un seul récit, sans correspondre à un client identifiable. Une direction juridique souhaite un assistant capable de répondre aux questions sur le corpus contractuel de l'entreprise. Le prototype, construit sur quelques dizaines de contrats, impressionne tout le monde. Le passage à l'échelle révèle trois obstacles que personne n'avait anticipés. D'abord, le corpus réel contient plusieurs versions du même contrat, sans que rien n'indique laquelle fait foi — le système répond correctement, mais à partir d'un avenant caduc. Ensuite, les droits d'accès : certains contrats ne doivent être visibles que par certaines personnes, et un moteur de recherche qui ignore cette contrainte crée une fuite d'information à grande échelle. Enfin, la qualité documentaire : une part significative des documents sont des PDF scannés, illisibles pour la machine, et personne dans l'organisation ne le savait avec précision.

Aucun de ces trois obstacles n'est un problème d'intelligence artificielle. Ce sont des problèmes de gouvernance documentaire que le projet IA a simplement rendus visibles.

C'est un schéma que nous observons avec constance : les projets RAG échouent rarement sur le modèle, presque toujours sur le corpus. La question qui décide du succès n'est pas « quel modèle utiliser ? » mais « sur quel ensemble documentaire, maintenu par qui, avec quelles règles d'accès et quelle politique de version ? ». Chez KAIROS Impulse, nous commençons donc systématiquement par un audit du corpus avant toute discussion d'architecture. C'est moins spectaculaire qu'une démonstration, et c'est ce qui détermine si le système tiendra au-delà du pilote.

Il faut également poser la question du périmètre. La tentation est de viser large : un assistant qui répond à tout, sur toute la base documentaire de l'entreprise. C'est la voie la plus sûre vers un système médiocre partout. Les déploiements qui réussissent sont étroits et profonds — un corpus délimité, une population d'utilisateurs identifiée, des questions dont on connaît la nature. Un assistant qui répond parfaitement aux questions sur les procédures de conformité vaut mieux qu'un assistant qui répond approximativement à tout.

Une objection revient fréquemment : pourquoi ne pas simplement entraîner un modèle sur nos données plutôt que de mettre en place cette mécanique de recherche ? Parce que le fine-tuning répond à une autre question. Il apprend au modèle un style, un format, un vocabulaire métier — il ne lui apprend pas des faits qu'il pourra restituer avec précision et citer. Et il fige la connaissance au moment de l'entraînement, alors qu'un corpus d'entreprise change tous les jours. Dans la grande majorité des cas d'usage documentaires, le RAG est la bonne réponse, et le fine-tuning une complication coûteuse.

Reste la dimension humaine, qui décide souvent de l'adoption. Un assistant documentaire est utilisé s'il inspire confiance, et la confiance ne vient pas du taux de réponses correctes — elle vient de la lisibilité des sources et de la capacité du système à reconnaître qu'il ne sait pas. Un assistant qui répond « je n'ai pas trouvé d'élément permettant de répondre » gagne plus de crédibilité qu'un assistant qui produit une synthèse élégante à partir de documents marginalement pertinents. C'est un choix de conception, pas un paramètre technique.

Trois questions, donc, avant d'engager un projet RAG. Le corpus visé est-il à jour, versionné et complet, ou allons-nous découvrir sa réalité en cours de route ? Les règles d'accès aux documents sont-elles formalisées et exploitables par un système automatisé ? Et sommes-nous prêts à accepter qu'un assistant honnête réponde parfois qu'il ne sait pas, plutôt qu'un assistant brillant qui se trompe avec assurance ?