#Pourquoi cette question revient sans cesse

Vous avez installé Ollama, choisi un modèle 7B ou 14B, et vous voulez maintenant qu'il "connaisse" votre domaine : votre documentation interne, le vocabulaire métier, vos décisions de jurisprudence, vos tickets support. Deux chemins s'ouvrent — fine-tuning ou RAG — et la communauté en parle souvent comme si c'étaient des alternatives interchangeables. Elles ne le sont pas.

Le piège : le fine-tuning a une aura de "vraie IA", on imagine un modèle qui devient expert. Le RAG paraît bricolé, du "copier-coller" automatisé. La réalité industrielle est inverse — RAG est devenu le standard pour 80% des cas d'usage entreprise, et le fine-tuning est réservé à des problèmes précis où il apporte ce que le RAG ne peut pas.

Le résumé en une phrase

RAG = donner au modèle un accès dynamique à de la connaissance externe. Fine-tuning = changer le comportement intrinsèque du modèle (style, format, raisonnement, langue spécialisée).

#Les deux approches en 1 minute

#RAG (Retrieval-Augmented Generation)

Le RAG indexe vos documents (PDF, Markdown, base de données, code) dans une base vectorielle (Chroma, Qdrant, Weaviate). Au moment d'une question, le système retrouve les passages pertinents par similarité sémantique, les injecte dans le prompt, et le LLM génère sa réponse en s'appuyant dessus. Le modèle reste générique, c'est le contexte qui devient spécialisé.

Ce que ça change: Le modèle peut citer vos données, sourcer ses réponses, et accéder à des connaissances qu'il n'avait pas pendant l'entraînement.
Ce que ça ne change pas: Le style de réponse, le ton, la capacité à raisonner dans un format précis, le vocabulaire technique très spécialisé.
Coût marginal d'ajout de doc: Quelques secondes : on indexe le nouveau document, c'est tout.

#Fine-tuning (LoRA / QLoRA / full)

Le fine-tuning ré-entraîne le modèle (ou une partie de ses poids, via LoRA) sur un dataset de paires entrée/sortie représentatives de ce que vous voulez qu'il fasse. La connaissance et le comportement sont absorbés dans les poids du modèle.

Ce que ça change: Le comportement par défaut : style, format de sortie, conventions, vocabulaire métier profond, raisonnement implicite.
Ce que ça ne change pas (bien): L'accès à des informations factuelles fraîches — un modèle fine-tuné en mars sur vos procédures ne saura rien des procédures écrites en avril.
Coût marginal d'ajout de doc: Un nouveau training run complet à chaque mise à jour significative du dataset.

→

Test mental rapide

Si la question est "comment le modèle peut-il savoir X ?", la réponse est presque toujours RAG. Si la question est "comment le modèle peut-il répondre comme ça ?", c'est probablement du fine-tuning.

#Matrice décisionnelle

Plutôt qu'un "ça dépend", voici les critères qui tranchent vraiment, ligne par ligne.

Connaissance factuelle qui change souvent: RAG. Le fine-tuning est obsolète au moment où le dataset est mis à jour. Toute documentation produit, base de tickets, FAQ, jurisprudence appartient à cette catégorie.
Style, ton, format de sortie spécifique: Fine-tuning. Aucun nombre d'exemples dans un prompt ne remplace 500 paires d'entraînement bien construites pour ancrer un format JSON strict, un ton corporate, ou une structure de rapport.
Vocabulaire métier extrêmement spécialisé: Fine-tuning, surtout si la langue est mal couverte par le pré-entraînement (juridique fr, médical, dialectes). Le RAG ne suffit pas si le modèle ne comprend pas les termes au départ.
Traçabilité et citation des sources: RAG. Vous pouvez afficher "d'après le document X, paragraphe Y". Avec un modèle fine-tuné, impossible de prouver d'où vient une affirmation.
Données ultra-confidentielles, jamais en RAM partagée: Fine-tuning avec poids stockés localement. Le RAG implique d'injecter les passages dans le contexte à chaque requête — sur infra mutualisée, ça peut poser problème.
Réponse rapide en moins de 200ms (chatbot, agent inline): Fine-tuning. Le RAG ajoute 100-500ms de retrieval + un contexte plus long à traiter. Sur du temps réel critique, ça pèse.
Volume de connaissance énorme (> 100k pages): RAG. Vous ne pouvez pas raisonnablement fine-tuner sur 100k documents — et même si vous le faisiez, le modèle hallucinerait sur les détails.
Dataset d'entraînement de qualité disponible: Si vous n'avez pas au moins 500-1000 paires entrée/sortie propres, le fine-tuning va dégrader le modèle plus qu'autre chose. Démarrez en RAG.

#5 cas d'usage type

#1. Chatbot support sur documentation produit

Verdict: RAG, sans hésiter.
Pourquoi: La doc change tout le temps (nouvelles features, correctifs, deprecations). Un fine-tune serait obsolète en 3 semaines, et le client veut une réponse sourcée ("voir section X du manuel"), pas une affirmation opaque.
Stack typique: Ollama (mistral 7B ou qwen2.5 14B) + Qdrant/Chroma + nomic-embed-text + Open WebUI ou AnythingLLM.

#2. Extracteur d'informations structurées (factures, CV, contrats)

Verdict: Fine-tuning, ou prompting avancé avec JSON mode.
Pourquoi: Le format de sortie doit être strictement le même à chaque fois (mêmes champs, même typage, mêmes valeurs par défaut). Un prompt même bien écrit dérive sur 5% des cas, ce qui casse un pipeline. Un LoRA sur 800 exemples annotés règle ça définitivement.
Stack typique: Unsloth ou Axolotl pour entraîner, export GGUF, déploiement Ollama. Si la base de "connaissance" sur les types de documents évolue, on peut combiner avec un RAG léger.

#3. Assistant juridique sur jurisprudence française

Verdict: Hybride — RAG d'abord, fine-tune ensuite si le vocabulaire reste faible.
Pourquoi: Le corpus de jurisprudence est gigantesque et change tous les mois (RAG obligatoire pour l'actualité des décisions). Mais le vocabulaire juridique français est mal couvert par la plupart des modèles open-weight, et un fine-tune léger (LoRA sur 2-3000 exemples de Q/R juridiques) améliore significativement la compréhension des termes avant que le RAG entre en jeu.
Stack typique: Légifrance/Doctrine en source → Qdrant + reranker BGE → LLM 14B fine-tuné LoRA sur le jargon juridique fr.

#4. Générateur de code adapté à une codebase interne

Verdict: RAG (lecture des fichiers du repo), pas de fine-tuning sauf cas très particulier.
Pourquoi: Une codebase évolue chaque jour. Un fine-tune serait obsolète à chaque sprint. Les meilleurs assistants code (Continue.dev, Aider) lisent dynamiquement les fichiers concernés via du RAG sur l'AST ou les embeddings de code.
Stack typique: Continue.dev + qwen2.5-coder 14B ou devstral via Ollama, retrieval intégré au plugin.

#5. Style éditorial maison (newsletter, rapports, fiches produit)

Verdict: Fine-tuning pur.
Pourquoi: Le contenu est nouveau à chaque fois (rien à "retrouver"), mais le ton, la structure, le rythme des phrases, l'usage du "vous", des intertitres, doivent être absolument cohérents. C'est exactement ce que le fine-tuning encode bien.
Stack typique: 200-500 articles bien rédigés → format Alpaca ou ChatML → QLoRA sur mistral 7B avec Unsloth → export GGUF, modelfile Ollama avec system prompt complémentaire.

#Les coûts cachés des deux approches

Les comparatifs publics se limitent souvent à "prix d'une GPU pour 4h d'entraînement". La réalité opérationnelle est plus dure des deux côtés.

#Coûts cachés du RAG

Qualité du chunking: Le découpage des documents conditionne tout. Mal fait, le retrieval ramène des bouts hors contexte, le LLM hallucine et personne ne comprend pourquoi. C'est rarement "juste mettre les PDF dans Chroma" : il faut souvent du chunking par section, parfois un pré-traitement OCR pour les scans.
Latence cumulée: Embedding de la query + recherche vectorielle + (optionnel) reranker + contexte rallongé pour le LLM. Sur un setup mal optimisé, on peut passer de 400ms (LLM seul) à 2-3s (RAG complet). À budgéter dès la conception.
Maintenance de la base: Quand un document est supprimé ou mis à jour, il faut le retirer/réindexer. Sur des sources externes (web, API), prévoir un job de rafraîchissement. Plus la stack vit, plus c'est du travail.
Qualité du modèle d'embeddings: Pour du français, les embeddings par défaut (text-embedding-ada like) sont médiocres. nomic-embed-text, BGE-M3 ou Solon font la différence — mais ça veut dire connaître les options.

#Coûts cachés du fine-tuning

Préparation du dataset: C'est 80% du travail. Récolter, nettoyer, formatter en paires instruction/réponse, dédupliquer, équilibrer les classes. Sur 4 semaines de projet de fine-tuning, comptez 3 semaines de data prep et 1 semaine d'entraînement.
Risque de régression: Un fine-tune mal calibré dégrade le modèle sur ses capacités générales (le "catastrophic forgetting"). Le modèle devient bon sur votre tâche et nul sur le reste. Il faut tester sur un benchmark générique avant/après.
Re-training à chaque évolution: Le dataset s'enrichit avec le temps. Chaque release demande de relancer 2-12h de GPU, de re-valider, de redéployer. Versionner les datasets et les checkpoints devient obligatoire.
Hardware d'entraînement: Inférer un 7B Q4 demande 5 Go de VRAM, mais l'entraîner (même en QLoRA) demande 12-16 Go au minimum. Le fine-tuning a un seuil d'entrée matériel plus haut que l'inférence.

Sous-estimation classique

Les équipes qui débutent surestiment le coût du RAG ("il faut tout indexer") et sous-estiment celui du fine-tuning ("on a 200 exemples ça suffira"). La réalité est l'inverse : un RAG basique se monte en 2 jours, un fine-tune utile demande 2 à 4 semaines à temps plein.

#L'approche hybride : RAG + fine-tuning

Les architectures les plus efficaces ne choisissent pas — elles combinent. Le fine-tuning définit comment le modèle parle de votre domaine, le RAG lui donne accès à ce qu'il doit savoir au moment T.

Fine-tune sur le style et le format: 200-1000 exemples qui ancrent le ton (corporate, technique, juridique), le format de réponse (JSON, Markdown structuré), et la posture (toujours citer la source, ne jamais inventer).
RAG sur la connaissance factuelle: Documentation, base de tickets, jurisprudence, codebase — tout ce qui change et qui doit être retrouvable et citable.
Garde-fous dans le prompt système: Le system prompt rappelle au modèle de refuser de répondre si le contexte RAG est vide ou contradictoire. Indispensable pour limiter les hallucinations.

→

L'ordre de mise en oeuvre

Commencez TOUJOURS par le RAG seul, en utilisant un bon system prompt. Mesurez. Si la qualité est insuffisante (mauvais ton, format inconsistant, lexique métier mal maîtrisé), ajoutez ensuite le fine-tuning ciblé sur les défauts identifiés. L'inverse fait perdre des semaines.

#Décision rapide en 3 questions

01
Question 1 — Vos données changent-elles plus d'une fois par mois ?
Si oui : RAG obligatoire. Le fine-tune ne peut pas suivre le rythme sans devenir un cauchemar opérationnel.
02
Question 2 — Avez-vous au moins 500 paires entrée/sortie de qualité, vérifiées humainement ?
Si non : commencez par RAG. Le fine-tuning sur 100 exemples bricolés dégrade le modèle. Si vous comptez en accumuler, mettez en place le RAG d'abord et capitalisez sur ses logs pour bâtir le dataset.
03
Question 3 — Le problème est-il "savoir quelque chose" ou "répondre d'une certaine manière" ?
Savoir → RAG. Répondre d'une certaine manière → fine-tuning. Les deux → hybride. C'est la grille la plus simple et elle est juste 9 fois sur 10.

#Pièges classiques à éviter

"Fine-tuner pour apprendre des faits": Erreur la plus fréquente. Un fine-tune n'est pas une base de connaissances — il interpole sur les exemples vus, mais hallucine sur les détails précis (chiffres, dates, références) bien plus qu'un RAG.
"RAG sans reranker" sur des corpus > 10k chunks: La recherche vectorielle seule rappelle de la masse mais pas toujours la pertinence. Un cross-encoder reranker (BGE, mxbai) sur le top-20 transforme la qualité, pour un surcoût de 50-100ms.
Confondre RAG et long contexte: "Je vais juste mettre tout le doc dans le prompt". Au-delà de 8k tokens utiles, la qualité chute drastiquement (perte au milieu, "lost in the middle"). Un RAG bien chunked bat un long contexte naïf à partir d'un certain volume.
Fine-tuner sur un modèle déjà aligné, avec un dataset non-aligné: Si vous fine-tunez un modèle "instruct" avec des exemples qui n'ont pas la même structure de prompt, vous cassez l'alignement et le modèle devient bizarre. Toujours respecter le template du modèle (ChatML, Alpaca, Mistral, Llama-3 chat).
Vouloir un benchmark public pour décider: Aucun benchmark générique ne dira si VOTRE cas est meilleur en RAG ou en fine-tune. Mettez en place un eval interne avec 30-50 questions représentatives, et mesurez avant d'industrialiser.

#Pour aller plus loin

Une fois la décision prise, les guides correspondants couvrent la mise en oeuvre concrète, avec les pièges et les optimisations.

Mise en oeuvre du RAG sans coder: Open WebUI ou AnythingLLM permettent de monter un RAG documentaire en quelques heures, sans écrire de Python — utile pour valider l'approche avant d'industrialiser.
Fine-tuning local LoRA / QLoRA: Le guide dédié couvre Unsloth, le format dataset, le choix entre LoRA et QLoRA, et l'export GGUF pour Ollama. Une RTX 3090 suffit pour un 7B.
Optimiser un RAG existant: Reranker, recherche hybride BM25 + vectoriel, stratégies de chunking — trois leviers qui font passer un RAG "qui marche" à un RAG production.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Use Cases · 10 min

Fine-tuning vs RAG : lequel choisir pour son cas d'usage ?