RAG ou fine-tuning : lequel choisir pour ses documents métier ?
Pour interroger des documents métier, le RAG : il cherche les passages pertinents au moment de la question, cite ses sources et suit les mises à jour sans réentraînement. Le fine-tuning modifie le modèle pour lui apprendre un format ou un style, pas un contenu. On commence par un RAG évalué ; le fine-tuning ne se discute qu’ensuite, sur des mesures.
Que font vraiment le RAG et le fine-tuning ?
La question revient à chaque premier échange : « on nous a parlé de fine-tuning, faut-il entraîner un modèle sur nos documents ? » Pour un cas d’usage documentaire, la réponse est presque toujours non. Voici pourquoi, et comment reconnaître les situations où c’est l’inverse.
Le RAG (Retrieval-Augmented Generation) ne touche pas au modèle. Au moment où l’utilisateur pose sa question, le système cherche les passages pertinents dans vos documents, puis les fournit au modèle en lui demandant de répondre à partir de ces extraits seulement. Le modèle apporte la capacité à lire et à rédiger ; vos documents apportent la connaissance.
Le fine-tuning modifie le modèle lui-même, en le réentraînant sur des exemples. Il sert à installer un comportement : un format de sortie strict, un ton, une façon de classer, une terminologie très particulière. Il ne sert pas, contrairement à ce qu’on lit souvent, à « faire apprendre vos documents » au modèle. Les faits injectés par entraînement ressortent de façon imprévisible et sans source vérifiable.
Autrement dit : le RAG répond à « que sait-on ? », le fine-tuning à « comment doit-on répondre ? ».
Pourquoi entraîner un modèle ne lui apprend pas vos documents ?
Je peux répondre avec un cas que je connais de l’intérieur. En 2026, j’ai entraîné de zéro un modèle de langue de 188 millions de paramètres, Thadeus, orienté français, sur mon propre matériel : 3,74 milliards de jetons vus en 110 heures de calcul sur un Mac, avec un corpus assemblé pour l’occasion et un tokenizer construit pour le français. Chaque étape est mesurée et publiée.
Le résultat écrit un français correct. Mais quand on lui fournit des passages de documents et qu’on lui demande d’en tirer une réponse, il en reprend le vocabulaire et synthétise mal. Ce n’est pas un défaut de réglage : à cette taille et avec ce volume d’entraînement, c’est une limite structurelle, que j’ai notée comme telle. Aucun jeu d’exemples supplémentaire ne la corrigera.
La leçon vaut pour un DSI qui hésite : ce qu’un modèle sait faire vient de l’échelle de son entraînement, ce qu’il sait de votre entreprise doit venir de l’index. Entraîner pour transmettre un contenu, c’est utiliser l’outil le plus coûteux pour le résultat le moins fiable. La connaissance vit dans les documents, pas dans les poids.
Quels critères tranchent ?
| Critère | RAG | Fine-tuning |
|---|---|---|
| Les documents changent souvent | Adapté : il suffit de réindexer | Inadapté : il faut réentraîner |
| Besoin de citer les sources | Natif | Impossible |
| Traçabilité d’une réponse contestée | Le passage retrouvé est visible | Rien à montrer |
| Comportement ou format très spécifique | Limité | Adapté |
| Coût de mise en place | Faible à moyen | Élevé |
| Compétence interne requise | Modérée | Forte |
| Délai avant premier résultat | Jours | Semaines |
| Qui porte le risque à chaque mise à jour | L’index, automatiquement | Une nouvelle campagne d’entraînement |
Trois questions suffisent en général à trancher.
Vos documents évoluent-ils ? Si oui, et c’est presque toujours le cas, le RAG s’impose. Un fine-tuning est figé à la date de l’entraînement. Réentraîner à chaque mise à jour documentaire est intenable.
Devez-vous justifier les réponses ? Dans un contexte réglementé, technique ou contractuel, une réponse sans source est inutilisable. Seul le RAG permet d’afficher le passage exact dont la réponse est tirée.
Le problème est-il le savoir ou la forme ? Si le modèle répond juste mais mal, trop long, mauvais format, ton inadapté, commencez par les consignes et quelques exemples dans la requête. Le fine-tuning ne se justifie qu’une fois cette voie épuisée, et sur un volume d’exemples conséquent.
Que coûte réellement chaque option ?
Le coût visible du fine-tuning, c’est l’entraînement. Le coût réel, c’est la constitution du jeu de données : plusieurs centaines à plusieurs milliers d’exemples de qualité, produits et validés par vos experts métier. C’est ce poste qui fait déraper les budgets, pas les GPU.
Il y a un second coût, moins connu, et il est public. Chez OpenAI, d’après la page des tarifs consultée le 8 septembre 2026, entraîner GPT-4.1 coûte 25 $ par million de jetons d’entraînement, puis le modèle affiné se paie 3 $ par million de jetons en entrée et 12 $ en sortie, contre 2 $ et 8 $ pour le même modèle non affiné. Une inférence 50 % plus chère, à vie, pour chaque question posée. Chez Mistral, la page des tarifs ne propose l’affinage que sur des modèles de classification, avec 2 $ par mois de stockage par modèle affiné. Le modèle vous coûte même quand personne ne l’utilise.
Côté RAG, le coût est à l’exécution : chaque question déclenche une recherche puis un appel au modèle avec quelques milliers de jetons de contexte. Cela se maîtrise, par une sélection plus fine des passages, la mise en cache, un modèle plus petit pour les questions simples, et cela se mesure dès le prototype. J’ai détaillé ce poste, avec un scénario chiffré, dans combien coûte un assistant IA sur les documents internes.
Quand le fine-tuning se justifie-t-il quand même ?
Quand le problème est la forme et qu’elle se répète : un format de sortie strict que les consignes n’obtiennent pas de façon stable, une classification à grand volume, une terminologie que le modèle de base écorche. Dans ces cas, un jeu d’exemples validé par le métier et un modèle affiné rendent le comportement prévisible.
Il faut alors accepter ce que « réentraîner » veut dire en exploitation. J’en ai un exemple sous les yeux tous les jours : mon robot de trading, dont le modèle de décision se réentraîne toutes les six heures, avec une comparaison systématique au modèle en place et un refus de promotion en cas de régression. Ça tourne, en continu, depuis des mois. Mais c’est une machinerie : un banc d’évaluation, une procédure de retour arrière, une supervision. Personne ne l’aurait montée pour un cas où réindexer un document suffisait.
Comment décider sur vos documents plutôt que sur un avis ?
Avec un jeu d’évaluation écrit avant le code : trente à cinquante questions réelles, la réponse attendue à chacune, le document qui la contient, validés par les personnes qui poseront ces questions. On construit un RAG restreint, sur un corpus limité et un groupe d’utilisateurs identifié, et on mesure.
Les chiffres disent alors d’où vient le problème. Sur Mnemo, mon moteur de recherche sur mes propres notes, les premières réponses étaient mauvaises sur les noms propres, les sigles et les références personnelles. Un réflexe aurait été de réentraîner quelque chose. Le jeu d’évaluation a montré que le bon passage n’était pas retrouvé : le problème était la recherche, pas la rédaction. Changer le modèle d’embeddings a fait passer la première réponse correcte de 30 % à 90 % des vingt requêtes du banc, sur mon corpus personnel. Aucun fine-tuning n’aurait touché à ça.
C’est la règle générale : si la recherche rate, on travaille le découpage, l’indexation et l’embedding ; si la recherche est bonne et la réponse mauvaise, on travaille les consignes ; et c’est seulement dans ce second cas, une fois les consignes épuisées, que le fine-tuning entre dans la discussion.
Et si ce n’est ni l’un ni l’autre ?
Une bonne partie des questions qu’on me pose ne relève d’aucun des deux. Retrouver un document par sa référence, filtrer des dossiers par date et par statut, vérifier qu’un champ obligatoire est rempli : une recherche plein texte et quelques règles font mieux, plus vite, pour beaucoup moins cher.
Le réflexe utile avant de trancher : formuler dix questions réelles que le futur système devra traiter. Si sept d’entre elles se résolvent par un filtre ou une recherche par mots-clés, vous n’avez pas un problème d’IA générative. Et si vous hésitez encore, décrivez votre cas d’usage : la première réponse consiste souvent à dire lequel des trois chemins s’applique.