Définition · La Semaine IA

Fine-tuning : c'est quoi, et quand l'utiliser plutôt que le RAG ?

9 min de lecture · mis à jour en juin 2026

On te vend le fine-tuning comme la réponse à « je veux une IA sur mes données ». Dans 80 % des cas, c’est faux, et tu vas brûler du temps et de l’argent à entraîner un modèle qui hallucine sur tes propres documents. Le fine-tuning ne sert pas à apprendre des faits — il sert à apprendre un comportement. Cette page pose la définition propre, tranche la question qui revient à chaque fois (fine-tuning ou RAG ?), donne les vrais ordres de grandeur de coût et de données, et liste les pièges qui transforment un projet d’affinage en gouffre.

La définition en une phrase (et le mot qui change tout)

Fine-tuning (affinage) : reprendre un modèle déjà entraîné et poursuivre son entraînement sur tes propres exemples pour ajuster son comportement par défaut.

Le mot qui change tout, c’est comportement. Tu ne pars pas d’une page blanche — entraîner un LLM depuis zéro coûte des millions et n’a aucun sens pour 99,9 % des projets. Tu prends un modèle de base (GPT, Llama, Mistral) qui a déjà avalé une fraction colossale du texte humain, et tu lui montres quelques centaines d’exemples « voici une entrée, voici la sortie que je veux ». À chaque exemple, on ajuste très légèrement ses poids (les réglages internes du modèle). Au bout du compte, le modèle a internalisé ta façon de répondre : tu n’as plus besoin de la lui réexpliquer dans chaque prompt.

La métaphore honnête : le fine-tuning, ce n’est pas donner de nouveaux livres à lire au modèle. C’est lui faire faire des exercices corrigés jusqu’à ce qu’il prenne le pli. Il ne ressort pas plus savant — il ressort plus dressé sur une tâche précise.

Ce que le fine-tuning n’est pas : ce n’est pas du RAG (tu ne vas rien chercher au moment de la requête), ce n’est pas un moyen fiable d’injecter des connaissances à jour (on y revient, c’est le piège n°1), et ce n’est presque jamais la première chose à essayer.

Fine-tuning vs RAG : la seule grille de décision qui compte

C’est la question qui revient dans chaque réunion produit, et la confusion coûte cher. Voici la ligne de partage, nette :

Le fine-tuning change comment le modèle répond. Le ton, le format, le style, la tâche. C’est gravé dans les poids, donc figé au moment de l’entraînement.
Le RAG change sur quoi le modèle répond. Les faits, les données fraîches, tes documents privés. C’est récupéré à la volée, donc toujours à jour si ta base l’est.

Tu veux…	Outil
Une sortie toujours dans le même format JSON / la même structure	Fine-tuning
Répondre à partir de ta doc produit qui change chaque semaine	RAG
Un ton de marque constant, sans le rappeler à chaque prompt	Fine-tuning
Citer des sources vérifiables (support, legal, médical)	RAG
Classer des tickets dans tes 12 catégories métier	Fine-tuning
Donner accès à des données privées sans les enfouir dans un modèle	RAG

Le test rapide : si la bonne réponse à ta question change avec le temps ou dépend d’un document précis, c’est du RAG. Si la bonne réponse dépend d’un comportement stable que tu veux par défaut, c’est du fine-tuning. Et la vérité de terrain, c’est que les deux ne s’opposent pas : on fine-tune un modèle pour qu’il exploite mieux le contexte qu’un RAG lui fournit (suivre les sources, répondre dans le bon format). La plupart des produits sérieux font les deux — mais commencent par le RAG, parce qu’il livre un résultat sans dataset à construire.

Le coût réel et les données nécessaires (pas ce qu’on croit)

Deux mythes à démonter avant de chiffrer un projet.

Mythe n°1 : « il faut des dizaines de milliers d’exemples ». Faux pour la plupart des cas. L’étude LIMA de Meta (2023) a montré qu’un modèle fine-tuné sur 1 000 exemples soigneusement choisis atteignait un alignement remarquable — la qualité du dataset écrase la quantité. En pratique, pour un comportement bien borné (format, ton, classification), 50 à quelques centaines d’exemples de très haute qualité battent 10 000 exemples bruités. Un dataset sale apprend au modèle tes incohérences.

Mythe n°2 : « l’entraînement coûte cher ». Rarement le poste principal. Un fine-tuning via API (OpenAI, Mistral) sur un petit jeu de données se chiffre en général de quelques dollars à quelques dizaines de dollars. Le vrai coût est ailleurs :

La construction du dataset. Rassembler, nettoyer et surtout relire à la main quelques centaines d’exemples « entrée → sortie idéale » : c’est du temps humain, et c’est là que se joue 90 % du résultat.
L’inférence. Un modèle fine-tuné via API est souvent facturé plus cher au token que le modèle de base. Sur du volume, ça peut dépasser le coût d’un prompt un peu plus long. Ce calcul de coût et de latence à l’inférence rejoint les arbitrages d’infrastructure détaillés dans l’édition Cerebras vs Nvidia.
La maintenance. Un fine-tuning vieillit. Quand le fournisseur sort un meilleur modèle de base, ton modèle affiné sur l’ancien devient un boulet — il faut tout refaire.

Si tu fine-tunes un modèle open-weight toi-même (Llama, Mistral), le LoRA change la donne : au lieu de réajuster des milliards de poids, tu gèles le modèle et tu entraînes de petites matrices additionnelles greffées dessus (la famille de méthodes dite PEFT, pour parameter-efficient fine-tuning — l’affinage qui ne touche qu’une fraction des paramètres). Tu affines sur un seul GPU, et tu obtiens un « adaptateur » de quelques mégaoctets que tu charges ou retires à la demande. C’est aujourd’hui la voie par défaut pour fine-tuner soi-même sans louer une ferme de GPU.

Les cas d’usage où le fine-tuning gagne vraiment (pour un founder)

Le fine-tuning se justifie quand un comportement précis revient à chaque requête et que ton prompt système enfle pour l’obtenir. Les cas concrets où il bat le prompt-engineering :

Format de sortie strict et constant. Tu as besoin que le modèle réponde toujours en JSON valide selon ton schéma, ou en suivant une grille d’évaluation maison. Un modèle fine-tuné y arrive de façon bien plus fiable qu’un prompt bourré d’exemples — et ton prompt rétrécit, donc le coût et la latence baissent.
Classification dans tes catégories métier. Trier des tickets, des leads, des transactions dans 10-15 catégories qui te sont propres. C’est l’usage classique où une centaine d’exemples par catégorie surpasse un gros prompt few-shot, plus cher à chaque appel.
Ton et style de marque. Un style maison difficile à décrire en mots (« écris comme nous ») mais facile à montrer par l’exemple. Plus efficace de le démontrer par 200 exemples que de le décrire dans un prompt de trois pages.
Spécialisation d’un petit modèle. Fine-tuner un modèle plus petit (donc moins cher, plus rapide) pour qu’il égale un gros modèle généraliste sur ta tâche précise. C’est le pari de la spécialisation au cœur des désaccords stratégiques entre labos qu’on décortiquait dans l’édition sur les trois patrons d’IA qui se contredisent : gros modèle généraliste ou flotte de petits modèles affinés ?

Le point commun de ces quatre cas : un comportement répétitif et bien défini, pas un besoin de connaissances fraîches. Dès que le mot « à jour » ou « nos documents » apparaît, repasse côté RAG.

Les pièges qui font rater un fine-tuning

Un fine-tuning raté ne plante pas bruyamment : il produit un modèle qui a l’air de marcher et déraille en silence. Les écueils récurrents :

Vouloir y injecter des connaissances. Le piège n°1. Le fine-tuning apprend un comportement, pas une base de faits fiable. Un modèle fine-tuné sur ta doc paraphrase vaguement, invente les détails, et doit être réentraîné à chaque mise à jour. Pour des faits, c’est le RAG. Toujours.
Un dataset sale ou déséquilibré. Le modèle apprend exactement ce que tu lui montres, défauts compris. Des exemples incohérents, une catégorie sur-représentée, des sorties bâclées : tu fabriques un modèle qui reproduit tes erreurs avec aplomb.
L’oubli catastrophique (catastrophic forgetting). Sur-entraîner sur une tâche étroite peut dégrader les capacités générales du modèle : il devient excellent sur ton format et médiocre sur tout le reste. Le LoRA limite le risque, sans l’annuler.
Pas d’évaluation. Comme pour le RAG : « ça a l’air mieux » n’est pas une métrique. Garde un jeu de test que le modèle n’a jamais vu, et mesure avant/après contre le modèle de base + un bon prompt. Souvent, le prompt bien écrit suffit — et t’épargne tout le projet.
Fine-tuner trop tôt. L’ordre rationnel : (1) un bon prompt, (2) du few-shot dans le prompt, (3) du RAG si le besoin est factuel, (4) le fine-tuning seulement si un comportement stable résiste encore. Sauter directement à l’étape 4 est le réflexe le plus coûteux du débutant.

Le fine-tuning en une phrase pour ton board

Si tu dois le pitcher à quelqu’un qui ne code pas : « C’est entraîner une IA à répondre dans notre format et notre ton par défaut — utile quand un comportement revient sans cesse, inutile pour lui apprendre des faits à jour, qui relèvent du RAG. »

La hiérarchie à retenir tient en une ligne : prompt d’abord, RAG pour les faits, fine-tuning pour le comportement. Le fine-tuning est un excellent outil rangé tout en bas de la liste, pas en haut. Quand tu y arrives pour de bon, le vrai travail n’est pas l’entraînement — qui est presque gratuit — mais la qualité brutale de tes quelques centaines d’exemples. Soigne le dataset, le reste suit. Et avant de lancer quoi que ce soit, repose-toi la seule question qui tranche : est-ce que je veux changer comment le modèle répond, ou sur quoi il répond ? Pour la vue d’ensemble, voir la page pilier comprendre l’IA générative.

Le fine-tuning, ce n'est pas donner de nouveaux livres à lire au modèle. C'est lui faire faire des exercices corrigés jusqu'à ce qu'il prenne le pli.

Questions fréquentes

Fine-tuning IA, c'est quoi exactement ?

Le fine-tuning (affinage en français), c'est le fait de reprendre un modèle déjà entraîné et de poursuivre son entraînement sur tes propres exemples pour ajuster son comportement. Tu ne pars pas de zéro : tu modifies à la marge les poids d'un modèle existant (GPT, Llama, Mistral) avec quelques centaines à quelques milliers d'exemples « entrée → sortie idéale ». Le résultat est un modèle qui répond dans un format, un ton ou un style précis sans qu'on ait à le lui rappeler dans chaque prompt. Ça change comment le modèle répond, pas ce qu'il sait.

Quelle est la différence entre fine-tuning et RAG ?

Le fine-tuning modifie les poids du modèle pour changer son comportement par défaut (ton, format, style, tâche spécialisée) ; le RAG ne touche pas au modèle et va chercher de l'information au moment de la requête pour l'injecter dans le prompt. Règle simple : fine-tuning pour changer comment le modèle répond, RAG pour changer sur quoi il répond. Pour des faits qui changent ou des données privées à jour, c'est presque toujours le RAG. Beaucoup de produits sérieux combinent les deux.

Combien coûte un fine-tuning et combien de données faut-il ?

Côté données, l'erreur classique est de croire qu'il en faut des dizaines de milliers : 50 à quelques centaines d'exemples de très haute qualité battent souvent 10 000 exemples bruités. Côté coût, l'entraînement d'un fine-tuning via API (OpenAI, Mistral) se chiffre en général de quelques dollars à quelques dizaines de dollars pour un petit jeu de données. Le vrai coût n'est pas l'entraînement : c'est la construction et la relecture du jeu de données, et l'inférence sur un modèle fine-tuné, souvent facturée plus cher que le modèle de base.

Le fine-tuning permet-il d'ajouter des connaissances à un modèle ?

Mal, et c'est le piège le plus courant. Le fine-tuning sert à apprendre un comportement ou un format, pas à injecter des faits fiables et à jour. Tenter d'« apprendre » ta base documentaire par fine-tuning donne un modèle qui paraphrase vaguement, hallucine sur les détails, et qu'il faut réentraîner à chaque mise à jour. Pour des faits, des chiffres ou des documents privés qui évoluent, le RAG est l'outil adapté : tu mets à jour ta base, la réponse suivante est à jour, sans réentraînement.

C'est quoi le LoRA et le PEFT en fine-tuning ?

Le fine-tuning complet réajuste tous les poids du modèle : lourd et coûteux. Le PEFT (parameter-efficient fine-tuning) ne touche qu'une petite fraction des paramètres. Sa méthode la plus connue, le LoRA (low-rank adaptation), gèle les poids du modèle et entraîne à la place de petites matrices additionnelles greffées sur ses couches. Résultat : on affine un modèle de plusieurs milliards de paramètres sur un seul GPU, et on obtient un « adaptateur » de quelques mégaoctets qu'on peut charger ou retirer à la demande. C'est aujourd'hui la voie par défaut pour fine-tuner un modèle open-weight soi-même.

Quand le fine-tuning vaut-il vraiment le coup pour un founder ?

Quand un comportement précis revient à chaque requête et que ton prompt système devient énorme pour l'obtenir : classification dans tes catégories métier, sortie dans un format strict, ton de marque constant, ou un style maison difficile à décrire en mots. Le fine-tuning permet alors de raccourcir le prompt (donc baisser le coût et la latence) tout en fiabilisant la sortie. À l'inverse, si ton besoin est « répondre sur nos documents à jour », commence par le RAG : tu auras un résultat en un week-end, sans dataset à construire.