RAG sans illusions

Le devis était déjà sur la table quand je suis arrivé. Fine-tuning d’un modèle open-weights sur les données de l’entreprise, quatre mois de chantier, un budget à cinq chiffres bien tassés. Le dirigeant voulait « une IA qui connaisse notre métier ». Le prestataire lui avait vendu exactement ça, avec les bons mots.

J’ai demandé combien de documents étaient concernés. Personne ne savait. On a compté ensemble, dans le dossier partagé du service. Une quarantaine de fichiers, dont une bonne part de versions successives du même document. Le tout tenait dans quelques centaines de pages.

Il n’avait pas besoin d’un fine-tune. À vrai dire, il n’avait même pas besoin d’un RAG.

Ce que fait un RAG, en clair

RAG, retrieval-augmented generation. Trois verbes suffisent à le décrire : découper, retrouver, coller. On découpe les documents en morceaux, on les indexe pour pouvoir les retrouver par proximité de sens, et au moment de la question on colle les morceaux pertinents dans le prompt du modèle. Le modèle rédige à partir de ce qu’on vient de lui mettre sous les yeux.

Ce n’est pas une mémoire. Ce n’est pas un apprentissage. C’est une recherche documentaire avec une étape de rédaction au bout.

Cette phrase-là fait retomber la moitié des projets, et c’est une bonne nouvelle. Une fois le RAG décrit comme une recherche documentaire, les questions à se poser cessent d’être celles d’un ingénieur IA. Ce sont celles d’un documentaliste. Elles sont beaucoup plus faciles à instruire avec un dirigeant.

L’échelle décide, pas la mode

En dessous d’un certain volume, la réponse technique tient en une ligne : mettez les documents dans le contexte. Pas d’embeddings, pas de découpage, pas de base vectorielle. Vous chargez les textes dans le prompt, vous activez le cache de contexte pour ne pas les repayer à chaque question, et vous avez un assistant qui répond sur vos documents en une après-midi. C’est aussi ce que recommande la littérature technique depuis un moment pour les petits corpus, mais ça ne se vend pas, donc ça se dit peu.

Au-dessus, oui, il faut indexer. Mais indexer ne veut pas dire monter une infrastructure. sqlite-vec fait de la recherche vectorielle dans un fichier SQLite unique, sans serveur, sans conteneur, sans dépendance. Si l’entreprise a déjà un PostgreSQL en production, pgvector fait le travail dans la base existante. Le cluster spécialisé se justifie quand on gère des millions de vecteurs et des dizaines d’utilisateurs simultanés. Aucune des PME que j’accompagne n’en est là, et la plupart n’y seront jamais.

C’est exactement l’ennui calibré dont je parlais à propos des stacks logicielles, appliqué cette fois à la couche IA. La technologie la plus ennuyeuse qui résout le problème est presque toujours la bonne, et le discernement pour la reconnaître est ce que vingt-cinq ans de terrain vous laissent une fois la mode passée.

Le coût que le POC ne montre jamais

Le pilote fonctionne toujours. C’est sa fonction. Trois documents propres, cinq questions préparées, une démo de vingt minutes qui impressionne le comité de direction. Le coût réel arrive après, et il n’est jamais là où on l’attend.

Il n’est pas dans le GPU. Il est dans le fonds documentaire.

Un RAG branché sur un espace partagé mal tenu ne produit pas de l’intelligence. Il produit de l’archéologie confiante. Deux versions de la même procédure cohabitent depuis 2023, l’une périmée, l’autre en vigueur, rien ne les distingue formellement : le modèle en choisira une, et il l’affirmera du même ton assuré dans les deux cas. Le RAG ne trie pas. Il amplifie ce que vous lui donnez, y compris le désordre.

Viennent ensuite les droits. Un index qui ignore les permissions de la source transforme un moteur de réponse en fuite de données interne, discrètement, sans qu’aucun contrôle ne se déclenche. C’est le sujet dont on parle le moins en avant-vente et celui qui me préoccupe le plus en mission.

Et enfin la réindexation. Les documents changent, l’index doit suivre, quelqu’un doit s’en occuper. Ce quelqu’un a un coût récurrent, dans le budget OPEX, comme n’importe quel outil.

Fine-tuner, mais pour quoi

La confusion la plus coûteuse que je rencontre est celle-ci : on croit qu’on fine-tune pour apprendre des choses au modèle. Non.

On fine-tune pour changer la façon dont il répond, pas ce qu’il sait. Le format de sortie, le ton, l’adhérence à une politique interne, une classification métier stable. Si le problème est « le modèle ignore nos tarifs 2026 », c’est un problème de connaissance, donc de récupération documentaire. Si le problème est « le modèle répond bien mais jamais dans le format attendu par notre outil », alors seulement la question du fine-tune se pose.

Poser cette distinction en réunion fait souvent gagner un trimestre.

Les quatre questions avant d’indexer quoi que ce soit

Elles se posent dans cet ordre, et l’ordre compte.

Combien de documents, réellement ? Pas la volumétrie du serveur de fichiers : le nombre de documents qui font autorité sur le sujet traité. On les compte, on ne les estime pas. Dans la moitié des cas, le compte réel tient dans un contexte de modèle et le projet change de nature séance tenante.
À quelle vitesse changent-ils ? Un corpus figé et un corpus vivant n’appellent pas la même architecture. Un catalogue produit qui bouge chaque semaine impose un pipeline de réindexation, donc un responsable, donc une ligne de budget. Un référentiel qualité stable depuis trois ans n’impose rien du tout.
Qui a le droit de lire quoi ? Si la réponse est « tout le monde voit tout », l’index est simple et le risque est réel. Si les droits sont segmentés, l’index doit les porter dès le premier jour. C’est structurant, ça ne se rattrape pas après.
Qui vérifie la réponse ? C’est le paradoxe que j’ai déjà décrit ici : pour valider ce qu’affirme la machine, il faut déjà connaître le sujet. Un RAG destiné à un expert lui fait gagner du temps. Le même RAG destiné à un novice lui donne une assurance qu’il n’a pas les moyens de contrôler.

Ce que j’installe en premier

Toujours la plus petite chose qui puisse fonctionner. Cinq documents, un prompt soigné, deux semaines d’usage réel avec trois personnes qui font le travail tous les jours. On mesure ce qui manque avant de construire ce qui manquerait peut-être.

Quand le volume justifie vraiment une plateforme, il existe des briques ouvertes et auto-hébergeables qui font le travail sans louer sa souveraineté au passage. Nosia, par exemple, fait du RAG auto-hébergé avec une API compatible OpenAI, ce qui laisse la porte de sortie ouverte. C’est le même critère que pour l’hébergement des modèles : ce qui compte n’est pas le drapeau sur le datacenter, c’est de pouvoir partir.

Et il arrive régulièrement que la conclusion soit : pas de RAG. Le dirigeant du devis à cinq chiffres a finalement rangé ses quarante documents, en a supprimé la moitié qui étaient périmés, et travaille depuis avec les vingt qui restent chargés dans le contexte. Ça lui a coûté trois jours de ménage documentaire et rien d’autre. Le ménage, il aurait de toute façon fallu le faire.

C’est souvent là qu’est la vraie valeur d’une mission de DSI à temps partagé sur ces sujets. Pas dans la plateforme qu’on installe, mais dans le projet qu’on évite, et dans l’ordre qu’on remet avant de brancher quoi que ce soit.

Un index n’est pas une connaissance. C’est une carte des endroits où elle est peut-être rangée. Utile, à condition de ne jamais confondre les deux.

Une carte n’est pas le territoire qu’elle représente, mais, si elle est correcte, elle a une structure semblable au territoire, ce qui explique son utilité. — Alfred Korzybski, Science and Sanity, 1933