Fine-tuning ou RAG : l'arbre de décision qui évite six mois d'erreur

---

title: "Fine-tuning ou RAG : l'arbre de décision qui évite six mois d'erreur" seoTitle: "Fine-tuning ou RAG : l'arbre de décision" description: "La plupart des équipes qui financent un fine-tuning voulaient en réalité du RAG. Voici le test qui tranche en une demi-journée, les quatre questions à poser dans l'ordre, et ce que chaque voie coûte réellement." seoDescription: "Fine-tuning ou RAG : le test qui tranche en une demi-journée, les quatre questions à poser dans l'ordre et le coût réel de chaque voie." date: "2026-09-22" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "qualité"] category: "IA & Automatisation" keywords: ["fine-tuning ou RAG", "fine-tuning LLM", "RAG entreprise", "choisir entre fine-tuning et RAG", "adapter un LLM", "jeu d'évaluation LLM", "coût fine-tuning", "intégration LLM production", "spécialiser un modèle", "assistant documentaire"]

Une équipe produit nous appelle après quatre mois de travail. Ils ont fine-tuné un modèle sur 3 200 paires question-réponse extraites de leur documentation et de leurs tickets de support, dépensé un peu moins de 30 000 € entre les jours-homme et le calcul, et leur assistant se trompe toujours sur les prix, les délais de livraison et les conditions de garantie. Leur conclusion, en arrivant : le jeu d'entraînement est trop petit, il faut recommencer avec 10 000 exemples.

C'est la mauvaise conclusion, et elle coûte les six mois suivants. Le modèle ne se trompe pas parce qu'il a vu trop peu d'exemples. Il se trompe parce que les prix ont changé depuis l'extraction du jeu de données, que les conditions de garantie varient selon le pays, et qu'aucun de ces faits n'a de raison d'être stocké dans des poids de réseau de neurones. Ce qu'ils voulaient, depuis le début, c'était du RAG.

Cette confusion est de loin l'erreur d'architecture la plus chère que nous rencontrons sur les projets IA que nous reprenons. Elle ne se voit pas au moment où elle est commise, parce que le fine-tuning produit toujours un résultat : le modèle répond, avec le bon ton, dans le bon format, avec l'air de savoir. L'erreur n'apparaît qu'au moment où quelqu'un vérifie les faits, c'est-à-dire souvent après la mise en production.

Les deux questions qu'on confond

Le fine-tuning et le RAG ne répondent pas à la même question, et la plupart des débats techniques s'enlisent parce que personne ne l'a énoncé clairement.

Le fine-tuning modifie le comportement du modèle. Il lui apprend une manière de répondre : un format de sortie, un registre de langue, une façon de raisonner sur un type de tâche, un vocabulaire métier, une structure de classification. Il agit sur la forme et sur le réflexe, pas sur les faits.

Le RAG fournit de la matière au moment de la question. Il ne change rien au modèle : il place sous ses yeux les documents pertinents avant qu'il ne réponde. Il agit sur les faits, et uniquement sur eux.

La conséquence pratique est simple et elle tranche la majorité des cas : si l'information peut changer, elle n'a rien à faire dans un fine-tuning. Un tarif, un stock, une procédure interne, une clause contractuelle, un nom de responsable, un statut de commande — tout cela bouge. Le jour où ça bouge, un modèle fine-tuné continue d'affirmer l'ancienne version avec le même aplomb, et rien dans sa réponse n'indique qu'elle est périmée. Un RAG, lui, lit le document à jour.

L'inverse est vrai aussi, et c'est l'autre moitié de l'erreur : on ne corrige pas un problème de forme en empilant des documents. Si le modèle produit du JSON invalide une fois sur dix, si ses réponses font trois paragraphes quand il en faudrait deux phrases, ou s'il refuse de classer un ticket dans vos catégories maison, augmenter la taille du contexte n'y changera rien de durable.

Le test qui tranche en une demi-journée

Avant toute décision d'architecture, il y a un test à faire, et il prend une demi-journée. Nous l'appelons le test du copier-coller.

Prenez vingt à trente cas où votre système se trompe aujourd'hui. Pour chacun, ouvrez le modèle de base — sans fine-tuning, sans RAG, juste l'API — et collez dans le prompt, à la main, le document qui contient la bonne réponse. Puis posez la question.

Trois résultats possibles, et chacun désigne une voie différente.

Le modèle répond juste dans plus de 90 % des cas. Votre problème est un problème de récupération, pas de modèle. Vous avez besoin d'un RAG, ou d'un meilleur RAG si vous en avez déjà un. Le fine-tuning est hors sujet : le modèle sait déjà faire, à condition qu'on lui donne la bonne page. C'est de très loin le cas le plus fréquent, et c'est aussi celui où la dépense en fine-tuning est la plus pure perte.

Le modèle se trompe encore alors qu'il a la réponse sous les yeux. Là, quelque chose d'autre est en cause : la tâche demande un raisonnement que le modèle ne fait pas, le format attendu est trop spécifique, ou le vocabulaire métier lui échappe. C'est le terrain légitime du fine-tuning — ou, avant lui, d'un travail de prompt sérieux.

Le modèle répond juste sur le fond mais mal sur la forme. Bonne réponse, mauvais format, mauvais ton, mauvaise longueur, structure inconstante d'un appel à l'autre. C'est le cas d'école du fine-tuning, et c'est aussi celui où il fonctionne le mieux, avec le moins d'exemples.

Ce test n'est pas une formalité. Sur les projets IA que nous auditons, il renverse la décision initiale environ deux fois sur trois. Il coûte une demi-journée ; la décision qu'il corrige coûte des mois.

L'arbre de décision, dans l'ordre

Les quatre questions ci-dessous se posent dans cet ordre. Chacune peut clore le débat : si la réponse est nette, on s'arrête là.

1. L'information peut-elle changer ?

Si oui, RAG. Sans discussion. Un fait qui a une date de péremption ne se met pas dans des poids. La question n'est même pas de savoir s'il change souvent : il suffit qu'il puisse changer. Un catalogue produit qui bouge deux fois par an suffit à disqualifier le fine-tuning, parce que la fenêtre entre le changement et le réentraînement est une fenêtre pendant laquelle votre système ment à vos clients.

2. Le volume de connaissances dépasse-t-il ce qui tient dans un contexte ?

Si votre corpus tient en 10 000 jetons et qu'il est stable, ne construisez ni RAG ni fine-tuning : mettez-le dans le prompt système et activez le cache de prompt. Nous voyons régulièrement des équipes monter une base vectorielle pour 40 pages de documentation. C'est trois semaines d'infrastructure pour un problème qui se règle avec un fichier et un cache, et cela ajoute une étape qui peut échouer là où il n'y en avait pas.

À l'inverse, au-delà de quelques centaines de pages, le RAG devient la seule option raisonnable, et le vrai sujet devient la qualité de la récupération — c'est là que se joue l'essentiel, et la plupart des réponses à côté viennent de l'étape de récupération, pas du modèle.

3. Ce qui cloche, est-ce le fond ou la forme ?

C'est la question à laquelle le test du copier-coller répond. Fond manquant : RAG. Forme instable, registre inadapté, tâche de classification maison, format de sortie strict : fine-tuning, ou d'abord prompt et exemples.

Un signe utile pour distinguer les deux : demandez-vous si un humain compétent mais extérieur à votre entreprise pourrait répondre correctement avec le document sous les yeux. Si oui, c'est du fond, donc du RAG. S'il faudrait lui expliquer vos conventions internes pendant une heure avant qu'il ne produise le bon format, c'est du comportement, donc potentiellement du fine-tuning.

4. Avez-vous 500 à 1 000 exemples propres, et pouvez-vous les maintenir ?

C'est le seuil concret en dessous duquel un fine-tuning n'a pas d'intérêt sur un modèle récent. Et « propres » veut dire quelque chose de précis : des exemples représentatifs de l'usage réel, cohérents entre eux, relus, sans les contradictions qui viennent de ce que trois personnes ont annoté selon trois logiques différentes.

La plupart des équipes échouent sur cette question sans se l'être posée. Elles extraient 3 000 lignes d'un outil de ticketing, constatent que la qualité est médiocre, et compensent par le volume. Un jeu de 600 exemples relus bat systématiquement un jeu de 5 000 exemples bruts. Si vous ne pouvez pas produire les 600, la réponse n'est pas de prendre les 5 000 : c'est que le fine-tuning n'est pas votre prochaine étape.

Ce que le fine-tuning coûte vraiment

Le coût de calcul est la partie visible, et c'est la moins importante. Un fine-tuning léger sur un modèle de taille moyenne se chiffre en centaines d'euros. Ce n'est pas là que part l'argent.

La constitution du jeu de données. Compter entre 10 et 20 jours-homme pour produire, relire et arbitrer 800 exemples de qualité sur un domaine métier. C'est le poste principal, et il est presque toujours absent du devis initial.

Le jeu d'évaluation. Sans lui, vous ne saurez pas si le fine-tuning a amélioré quoi que ce soit — vous saurez seulement qu'il a changé quelque chose. Il faut au minimum une centaine de cas réels avec la réponse attendue, tenus à l'écart de l'entraînement. C'est le même actif que celui qui manque à tout agent qui marche huit fois sur dix sans qu'on sache pourquoi, et il se construit avant, pas après.

Le verrouillage. Un modèle fine-tuné est attaché à une version d'un modèle de base. Quand le fournisseur sort la génération suivante — c'est-à-dire tous les six à douze mois — votre modèle spécialisé reste sur l'ancienne, et l'écart de qualité finit par dépasser le gain de la spécialisation. Il faut alors refaire le fine-tuning, donc rejouer le jeu de données, donc l'avoir maintenu. Les équipes qui n'ont pas prévu ce cycle se retrouvent avec un actif qui se dégrade tout seul.

Le réentraînement. Chaque évolution du besoin repasse par le cycle complet. Là où un RAG se met à jour en remplaçant un document, un fine-tuning se met à jour en recommençant.

C'est cette structure de coût qui explique pourquoi, quand nous intervenons en reprise de projet IA sur un système fine-tuné qui dérive, la première décision est presque toujours de basculer la partie factuelle vers du RAG et de ne garder le fine-tuning que là où il porte réellement quelque chose — quand il porte quelque chose.

Ce que le RAG coûte vraiment

Le RAG n'est pas gratuit non plus, et le présenter comme l'option facile est l'autre moitié du malentendu.

Les jetons. Chaque requête envoie les documents récupérés au modèle. Cinq extraits de 800 jetons, c'est 4 000 jetons d'entrée par question, à chaque question, pour chaque utilisateur. C'est le mécanisme qui transforme un POC à 40 € par mois en facture à quatre chiffres, et les leviers pour le reprendre en main sont connus mais ils se posent dès la conception.

La latence. Vous ajoutez une recherche, souvent un reclassement, parfois une reformulation de la requête, avant même le premier jeton généré. Comptez 300 à 900 ms de plus qu'un appel direct. Sur un assistant conversationnel, cela se sent.

La maintenance de l'index. Les documents changent, il faut les réindexer. Les droits d'accès varient selon l'utilisateur, il faut les filtrer à la récupération sous peine de fuite. Les formats sont hétérogènes, il faut les convertir. Cette plomberie est le vrai travail d'un RAG en production, et elle ne s'arrête jamais.

La qualité de la récupération. C'est le point dur. Un RAG mal réglé donne des réponses fausses avec la même assurance qu'un modèle fine-tuné périmé, à la différence près qu'on peut le mesurer et le corriger sans réentraîner quoi que ce soit.

Les cas où la réponse n'est ni l'un ni l'autre

Trois situations reviennent souvent, où la bonne décision est de ne faire ni l'un ni l'autre.

Le prompt n'a jamais été travaillé sérieusement. Un prompt système structuré, avec cinq à dix exemples bien choisis, règle une part considérable des problèmes de format et de ton attribués au modèle. C'est quelques heures de travail contre plusieurs semaines. Faites-le d'abord, systématiquement : c'est aussi le seul moyen d'avoir une base de comparaison honnête pour juger ce qu'apporte la suite.

La sortie structurée suffit. Si le problème est un JSON invalide ou un champ manquant, les modes de sortie contrainte des API actuelles résolvent le sujet sans entraînement. Fine-tuner pour obtenir un format valide est une dépense inutile depuis deux ans.

Le problème est en amont du modèle. Données sales, périmètre flou, cas d'usage jamais cadré. Aucun choix d'architecture ne rattrape cela, et c'est fréquemment ce qui bloque réellement un POC IA qui ne passe pas en production.

Combiner les deux : l'ordre compte

Les deux approches se combinent très bien, et sur les systèmes matures c'est souvent la bonne configuration : un RAG pour les faits, un fine-tuning léger pour le comportement — respecter un format de réponse, adopter le vocabulaire maison, savoir dire « je ne sais pas » quand les documents récupérés ne contiennent pas la réponse.

Mais l'ordre n'est pas négociable : RAG d'abord, fine-tuning ensuite, jamais l'inverse. Deux raisons. D'une part, le RAG résout souvent tout, et vous économisez la seconde étape. D'autre part, fine-tuner avant d'avoir stabilisé la récupération revient à entraîner un modèle à bien répondre à partir d'un contexte qui va changer — vous figez un comportement adapté à un système qui n'existera plus dans deux mois.

Si vous êtes déjà engagé dans la mauvaise voie

Le réflexe naturel est de terminer ce qui est commencé. C'est rarement le bon calcul, mais tout n'est pas perdu non plus.

Ce qui se récupère : le jeu de données. Les paires question-réponse constituées pour l'entraînement font un excellent jeu d'évaluation, et un bon socle de corpus pour l'indexation. Les quatre mois de l'équipe du début de cet article n'étaient pas entièrement perdus — leurs 3 200 paires ont servi, comme jeu d'évaluation et comme base documentaire.

Ce qui ne se récupère pas : les poids eux-mêmes, si le problème était factuel. Un modèle entraîné sur des tarifs de mars ne devient pas correct en avril.

La bascule se fait en deux semaines dans la plupart des cas : indexer le corpus existant, brancher la récupération, mesurer sur le jeu d'évaluation déjà constitué, comparer aux performances du modèle fine-tuné. La comparaison chiffrée est ce qui permet de trancher sans débat d'opinion — et elle penche presque toujours du même côté quand le problème était factuel.

Par où commencer

Faites le test du copier-coller cette semaine, sur vingt cas d'échec réels. Il ne demande ni infrastructure, ni budget, ni décision préalable, et il vous dira laquelle des trois voies — récupération, comportement, ou simplement un meilleur prompt — correspond à votre problème.

Si le modèle répond juste quand vous lui donnez le document, arrêtez tout projet de fine-tuning en cours et mettez l'effort sur la récupération. C'est la décision qui économise les six mois du titre, et elle se prend en une demi-journée.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.