Dès qu’il s’agit de connecter un modèle de langage à des connaissances spécifiques à une entreprise, la même question revient dans presque toutes nos conversations clients : faut-il faire du RAG (retrieval-augmented generation) ou du fine-tuning ? La question est légitime, mais elle part souvent d’une fausse symétrie. Ce ne sont pas deux variantes de la même solution : ce sont deux réponses à deux problèmes différents, et la confusion entre les deux coûte cher, en argent comme en temps.

Ce guide détaille ce que fait réellement chaque approche, ce qu’elle coûte en pratique, et surtout comment trancher sans se tromper selon votre situation.

Cette confusion n’est pas propre aux équipes non techniques : on la retrouve régulièrement chez des développeurs expérimentés, simplement parce que les deux approches partagent un vocabulaire proche et s’appuient toutes deux sur le même modèle de base. La différence se joue entièrement dans ce qu’on fait de ce modèle une fois choisi, pas dans le modèle lui-même.

Le RAG : donner accès à des documents à jour

Le RAG consiste à aller chercher les informations pertinentes dans une base documentaire au moment de la question, puis à les fournir au modèle comme contexte avant qu’il ne génère sa réponse. C’est l’approche à privilégier quand vos données changent souvent et quand vous avez besoin de traçabilité : on peut savoir exactement quel document a servi à générer une réponse, ce qui est précieux dès qu’un enjeu de confiance ou d’audit entre en jeu.

  • Mise à jour des connaissances quasi immédiate : ajouter un document à la base suffit, pas besoin de ré-entraîner quoi que ce soit
  • Sources citables, utile pour la confiance des utilisateurs et pour l’audit interne
  • Coût de mise en place généralement plus faible, souvent quelques milliers d’euros pour un premier périmètre
  • Fonctionne bien même avec des volumes de documents modestes, dès quelques centaines de pages

La contrepartie : la qualité du RAG dépend fortement de la qualité de l’indexation et du découpage des documents. Une base documentaire mal structurée, avec des informations contradictoires ou obsolètes, produit un RAG qui répond avec assurance à côté de la question. La préparation des données, souvent sous-estimée, est en réalité la moitié du travail.

Le fine-tuning : apprendre un style ou un comportement

Le fine-tuning consiste à ré-entraîner partiellement un modèle sur des exemples spécifiques. Il est pertinent quand l’enjeu n’est pas l’accès à une information, mais l’adoption d’un ton, d’un format de réponse ou d’un comportement particulier et stable dans le temps : reproduire la voix de marque d’un service client, respecter systématiquement un format de sortie structuré, ou internaliser un raisonnement métier récurrent que le simple contexte ne suffit pas à transmettre de façon fiable.

Le fine-tuning est structurellement plus coûteux que le RAG : il demande un jeu de données d’exemples de qualité, souvent plusieurs centaines à quelques milliers d’exemples annotés, une infrastructure d’entraînement, et surtout un cycle de ré-entraînement à chaque fois que le comportement souhaité évolue. C’est un investissement qui se justifie quand le comportement visé est stable et bien défini, pas quand il est encore en train de se préciser.

Le RAG répond à « quelles informations le modèle doit-il connaître ? ». Le fine-tuning répond à « comment le modèle doit-il se comporter ? ».

Le piège le plus fréquent : fine-tuner pour résoudre un problème de données

Dans la majorité des projets ratés que nous avons vus passer, l’erreur est la même : une équipe choisit le fine-tuning en espérant que le modèle « apprenne » les informations spécifiques à l’entreprise, alors que le vrai besoin était un accès fiable à une base documentaire à jour. Le résultat est un modèle ré-entraîné, coûteux, qui reste incapable de répondre correctement dès qu’un document change, ce qui arrive presque tout de suite dans n’importe quelle entreprise vivante.

Le test simple à se poser avant de choisir : si l’information change plus d’une fois par trimestre, ou si elle doit être traçable jusqu’à sa source, c’est un problème de RAG, pas de fine-tuning. Si le comportement souhaité est un style ou un format qui ne varie presque jamais, le fine-tuning devient une option raisonnable, mais rarement la première à essayer.

Et si on combinait les deux ?

Dans la pratique, beaucoup de systèmes robustes combinent les deux approches : un fine-tuning léger pour cadrer le ton et le format de sortie, et du RAG pour l’accès aux données à jour. C’est une architecture pertinente une fois que le système a fait ses preuves et que le comportement stable à fixer est réellement identifié. La priorité reste toutefois de commencer simple : le RAG seul suffit à la grande majorité des cas d’usage d’entreprise que nous rencontrons, en particulier pour un premier déploiement.

Ce que ça coûte, concrètement

Pour donner un ordre de grandeur : un premier système RAG bien cadré, sur un périmètre documentaire de quelques centaines à quelques milliers de pages, se met en place généralement en deux à quatre semaines. Un projet de fine-tuning sérieux, avec constitution du jeu de données, entraînement et validation, prend le plus souvent plusieurs semaines de plus et mobilise davantage de compétences spécialisées en amont. Ce n’est pas un argument contre le fine-tuning quand il est justifié : c’est une raison de plus pour être certain, avant de s’engager, que c’est bien le bon problème à résoudre.

Les erreurs techniques qui plombent un RAG

Choisir le RAG plutôt que le fine-tuning ne suffit pas à garantir un bon résultat : la qualité d’exécution fait une différence considérable, et on retrouve les mêmes erreurs d’un projet à l’autre. La première est un découpage des documents trop mécanique, par exemple par blocs de taille fixe sans respecter la structure du texte, ce qui coupe des idées en plein milieu et renvoie au modèle des fragments incohérents.

La deuxième erreur fréquente est l’absence de réordonnancement (reranking) après la recherche initiale : la première recherche documentaire renvoie souvent une dizaine de passages à peu près pertinents, et sans étape de tri supplémentaire pour ne garder que les meilleurs avant de les envoyer au modèle, la réponse finale se construit sur du bruit autant que sur du signal. La troisième est de négliger la mise à jour de l’index quand les documents sources changent : un RAG branché sur une base documentaire qui n’est plus synchronisée retombe exactement dans le problème qu’il était censé résoudre.

Un exemple chiffré

Pour une base de connaissances interne d’environ 800 documents (procédures, fiches produit, FAQ), un système RAG correctement cadré représente typiquement un investissement initial de 4 000 à 8 000 euros et deux à trois semaines de travail, incluant le nettoyage des documents sources, souvent la partie la plus longue. Le même périmètre traité par fine-tuning, en admettant qu’il s’agisse du bon choix technique, dépasse fréquemment 15 000 euros une fois comptés la constitution du jeu d’exemples annotés, l’entraînement et les itérations de validation, pour un résultat qui reste plus rigide face aux mises à jour fréquentes de contenu.

Les cas où le fine-tuning est clairement le bon choix

Pour être honnêtes sur les limites du RAG : il existe des situations où le fine-tuning n’est pas un raffinement de confort, mais la seule option qui fonctionne réellement. La première est la cohérence de ton sur un très grand volume d’interactions : un service client qui traite des milliers d’échanges par jour et veut une voix de marque identique à chaque fois obtient de meilleurs résultats avec un modèle dont le style a été appris, plutôt qu’avec des instructions répétées dans chaque prompt, qui finissent par être partiellement ignorées sur les cas complexes.

La deuxième situation concerne le respect strict d’un format de sortie : quand une application en aval attend une structure de données très précise et ne tolère aucune variation, un modèle fine-tuné sur des milliers d’exemples de ce format se montre plus fiable qu’un modèle instruit uniquement par le prompt. La troisième est l’internalisation d’un jargon ou d’un raisonnement métier très spécifique, qu’aucun document ne suffit à transmettre parce qu’il tient davantage d’un savoir-faire implicite que d’une information écrite quelque part : la façon dont des experts médicaux formulent un compte-rendu, par exemple, plutôt que son contenu factuel.

Dans les trois cas, un point commun : le comportement visé est stable, répété à très grande échelle, et clairement observable dans des exemples existants. C’est l’exact inverse d’un besoin encore flou ou d’une information amenée à changer, qui reste le terrain du RAG.

Notre recommandation

Sauf besoin très spécifique de comportement stable et bien défini, nous conseillons quasi systématiquement de démarrer par le RAG : plus rapide à mettre en place, plus facile à faire évoluer au fil des retours, et plus transparent pour vos équipes internes qui peuvent voir exactement quelles sources alimentent chaque réponse. Le fine-tuning arrive ensuite, une fois que le système a démontré sa valeur et que le comportement à figer est clairement identifié plutôt que supposé.