RAG vs fine-tuning — quelle approche choisir en 2026 ?

Quand le RAG est la bonne réponse (90% des cas)

Si tu veux que ton LLM réponde sur des **données spécifiques** (ta documentation, tes contrats, tes articles, ta base de tickets), c'est presque toujours du RAG qu'il te faut.

Exemples typiques : - Chatbot de support qui répond sur ta documentation produit - Assistant juridique qui interroge tes contrats - Outil de recherche dans ta base Confluence ou Notion - Q&A sur des rapports financiers, audits, audits techniques - Onboarding interne pour les nouveaux employés

Le RAG marche tellement bien parce que le LLM sait déjà parler — il manque juste les **faits** que tu lui fournis dans le contexte. Pas besoin de réentraîner sa capacité linguistique.

Une implémentation RAG solide : un système d'embedding (text-embedding-3-large ou Voyage 3), une base vectorielle (Pinecone ou pgvector), un re-ranker pour améliorer la pertinence (Cohere Rerank ou bge-reranker), et un bon prompt qui dit au modèle de citer les sources et de dire quand l'info n'est pas dans les passages fournis.

Quand le fine-tuning est la bonne réponse (10% des cas)

Le fine-tuning vaut le coût quand tu veux changer **comment** le modèle répond, pas seulement **sur quoi**. Cas d'usage légitimes :

1. **Voix de marque très spécifique** : tu veux que le modèle écrive comme ta marque, avec ton ton, ta longueur, tes tics de langage. Impossible à obtenir parfaitement par prompt seul. 1000-5000 exemples de tes meilleurs contenus en dataset → fine-tuning d'un GPT-4o-mini ou Llama 4 8B → ton modèle.

2. **Compression coût/performance** : tu utilises GPT-5 (cher) pour une tâche répétitive. Avec un dataset de 5000 exemples bien faits, tu peux fine-tuner un Llama 4 8B qui atteint 90% de la qualité pour 10× moins cher en inférence. ROI rapide à l'échelle.

3. **Format de sortie très structuré** : tu veux toujours du JSON avec une structure exacte, ou un format custom (XML interne, CSV particulier). Le fine-tuning rend ce format natif sans avoir à le re-spécifier dans chaque prompt.

4. **Domaine ultra spécialisé** : médical, code legacy ancien (COBOL, Fortran), juridique français pointu — domaines où le vocabulaire est tellement spécifique que les prompts d'injection ne suffisent pas.

Dans tous ces cas, on commence souvent par valider en RAG et passer en fine-tuning seulement si le résultat n'est pas assez bon.

L'approche hybride : RAG + fine-tuning

En production critique, la meilleure approche combine souvent les deux :

- **Fine-tuning** pour le style, le ton, le format de sortie - **RAG** pour les faits spécifiques et à jour

Exemple concret : un assistant légal pour un cabinet d'avocats français. - Fine-tuning sur 2000 anciens emails et conclusions du cabinet → le modèle adopte le style juridique du cabinet, son vocabulaire, sa structure habituelle - RAG sur la base de jurisprudence à jour + les contrats actifs du cabinet → le modèle peut citer les précédents pertinents et faire référence aux clauses précises

Résultat : un assistant qui parle comme un avocat du cabinet ET qui connaît les dossiers en cours. Aucune des deux approches seule n'aurait donné ça.

Coût total raisonnable : ~3000€ de fine-tuning initial, ~50€/mois de RAG (embeddings + storage + tokens), maintenance de la base de docs. Largement amorti par les heures gagnées.

Méthodologie pour décider

Voici la check-list à passer avant de fine-tuner :

☐ J'ai testé le RAG bien implémenté (chunks adaptés, re-ranker, prompt soigné) ? ☐ Le RAG donne des réponses factuellement correctes mais le STYLE ne convient pas ? ☐ J'ai 1000+ exemples de qualité du comportement attendu ? ☐ Je vais utiliser ce système avec un volume justifiant le coût (>10K requêtes/mois) ? ☐ J'accepte de devoir re-fine-tuner périodiquement quand mes besoins évoluent ? ☐ J'ai considéré qu'un meilleur prompt ou un autre modèle pourrait suffire ?

Si tu coches tout : go fine-tuning. Si tu coches moins de 4 cases : reste sur du RAG bien fait.

Dernière option qu'on oublie souvent : **améliorer le prompt** plutôt que fine-tuner. Un bon system prompt de 2000 mots avec quelques exemples few-shot peut atteindre 80% de la qualité d'un fine-tuning, pour 0€ et 0 maintenance.