RAG vs fine-tuning vs prompt engineering — quelle approche en 2026

Question fréquente : “On veut spécialiser un LLM sur nos données. RAG, fine-tuning ou prompt engineering ?”. La vraie réponse dépend de 3 paramètres : fréquence de changement des données, volume de cas, niveau de spécialisation attendu. Voici la grille qu’on applique.

Les 3 approches expliquées en 30 secondes

• Prompt engineering : on écrit un prompt système détaillé qui décrit la tâche, le rôle, le format. On peut inclure 2-20 exemples. Le modèle reste générique. Coût : quelques heures de travail. Changement : modifier un fichier texte.
• RAG (Retrieval Augmented Generation) : on indexe vos données dans une base vectorielle. Pour chaque requête, on récupère les 3-10 extraits pertinents et on les injecte dans le prompt. Le modèle reste générique. Coût : du temps d’ingénierie, plus l’embedding des documents et la base vectorielle. Changement : réindexer les données nouvelles.
• Fine-tuning : on ré-entraîne un modèle sur vos données (supervision fine-tuning, LoRA, PEFT). Le modèle apprend vos patterns en interne. Coût : heures de GPU, données annotées et cycles d’évaluation. Changement : ré-entraîner ou continuer l’entraînement.

La grille de décision

Critère	Prompt Engineering	RAG	Fine-tuning
Coût initial	Temps de rédaction et de test	Ingénierie + indexation	Données annotées + heures de GPU
Coût exploitation	API LLM standard	API + base vectorielle	API + compute
Latence ajoutée	Aucune	Une étape de récupération	Aucune (un petit modèle peut être plus rapide)
Temps de mise en oeuvre	Court	Moyen	Long
Données dynamiques	❌	✅	❌
Volume de cas	Illimité	Illimité	Limité par budget
Qualité sur cas général	Fort	Fort	Moyen
Qualité sur cas spécialisé	Limité	Fort	Fort
Citations sources	❌	✅	❌
Risque hallucinations	Moyen	Faible (si bien fait)	Moyen
Dépendance modèle	Faible (migrer facile)	Faible	Forte (fine-tune = verrouillage)

Quand choisir prompt engineering seul

Cas où c’est la bonne réponse :

• La tâche est générique (classer un ticket, résumer un email, extraire des entités, traduire).
• Les données contextuelles tiennent dans le prompt (dans la fenêtre de contexte du modèle).
• La qualité obtenue avec un bon prompt est acceptable pour l’usage.
• Le budget est contraint ou le projet est un POC.

Exemples concrets :

• Classification de tickets support en 5 catégories.
• Résumé automatique d’emails clients.
• Extraction d’informations d’un formulaire rempli.
• Traduction FR ↔ EN sur du vocabulaire courant.

Ce qui fait varier le coût : le temps de rédaction et de test, puis les tokens d’API. Exemple de calcul, au tarif public lu le 24/10/2026 sur claude.com/pricing (Sonnet 4.5 : 3 $ par million de tokens en entrée, 15 $ en sortie) : un prompt système de 2 000 tokens plus une question de 500 tokens, avec une réponse de 300 tokens, coûte (2 500 × 3 $ + 300 × 15 $) / 1 000 000 = 0,012 $ par requête, soit 120 $ pour 10 000 requêtes.

Ce qui ne passera pas avec cette approche : nécessité de citer des sources, données qui changent toutes les semaines, volume de documents supérieur à la fenêtre de contexte du modèle.

Quand choisir RAG

Cas où RAG est la réponse :

• Vous avez une base de documents à exploiter (wiki interne, contrats, procédures, produits).
• Les documents changent régulièrement (nouveaux contrats, mises à jour, suppressions).
• Vous devez citer les sources (compliance, juridique, santé, tech doc).
• Le volume de documents dépasse ce qui tient dans un prompt.

Exemples concrets :

• Support client qui répond sur votre catalogue de 10 000 produits.
• Assistant juridique qui cite la jurisprudence précise.
• Documentation interne interrogeable.
• Veille avec résumé par sujet.

Stack typique RAG 2026 :

• Indexation : Qdrant, Weaviate, PgVector pour le store ; chunks 500-1500 tokens ; embeddings via Cohere embed-v4 ou OpenAI text-embedding-3-large.
• Récupération : vectorielle + BM25 (hybride), re-ranking avec Cohere Rerank.
• Génération : Claude Sonnet ou Mistral Large avec contexte injecté + instructions d’ancrage strict.

Ce qui fait varier le coût : volume de documents, fréquence de réindexation, base vectorielle et modèle de génération. Exemple de calcul, au tarif public lu le 24/10/2026 sur docs.voyageai.com (voyage-4 : 0,06 $ par million de tokens) : indexer 10 000 fiches produits de 500 tokens, soit 5 millions de tokens, coûte 5 × 0,06 $ = 0,30 $. Côté base vectorielle, Pinecone affiche un minimum de 50 $ par mois en Standard (tarif public lu le 24/10/2026 sur pinecone.io/pricing).

Ce qui casse en RAG : mauvais découpage des documents (chunks qui coupent mal), absence de re-ranking (les 10 chunks récupérés ne sont pas les meilleurs), oubli de tester sur de vrais cas utilisateurs (un RAG validé sur quelques cas choisis peut casser en production).

Quand choisir fine-tuning (rare, mais parfois nécessaire)

Cas où fine-tuning se justifie :

• Voix de marque très spécifique que le prompt ne capture jamais parfaitement (après avoir épuisé prompt + RAG).
• Jargon ultra-spécialisé où le modèle généraliste patauge (médical niche, juridique pointu, technique très spécifique).
• Contrainte de latence extrême où un petit modèle fine-tuné bat un gros modèle généraliste (ex: auto-complétion dans un éditeur).
• Volume massif où la réduction de prompt (via fine-tune) produit une économie réelle (à calculer : tokens de prompt économisés multipliés par le prix du token, comparés au coût d’entraînement).

Exemples concrets :

• Un générateur qui doit écrire en style éditorial ultra-codé (presse spécialisée).
• Un classificateur médical sur 200 catégories de maladies rares.
• Un auto-complete dans un IDE avec latence < 100ms.

Stack typique 2026 :

• LoRA / QLoRA sur Llama 3.3 70B ou Mistral Small : entraîne un petit nombre de paramètres ajoutés, donc moins de mémoire GPU qu’un entraînement complet.
• Full fine-tune sur modèle open : tous les poids sont réentraînés, avec un besoin en GPU plus élevé.
• Fine-tune via un éditeur : selon les modèles proposés, voir les tarifs en vigueur.

Budget : compter 1 cycle = 1 entraînement + évaluation + redéploiement, et plusieurs cycles sont souvent nécessaires avant d’atteindre la qualité cible. Exemple de calcul, au tarif public de 8 $ de l’heure pour une H100 (lu le 24/10/2026 sur fireworks.ai/pricing) : un entraînement hypothétique de 10 heures coûte 10 × 8 $ = 80 $, soit 240 $ pour trois cycles. La préparation des données et l’évaluation s’ajoutent à ce calcul.

Ce qui ne marche pas en fine-tuning :

• Essayer de “faire apprendre des faits” — le fine-tune code du style et des patterns, pas des faits. Pour les faits, RAG.
• Fine-tuner sur trop peu d’exemples — il faut un jeu de données assez large et propre pour un résultat stable.
• Fine-tuner sans plan d’évaluation rigoureux — un fine-tune peut se dégrader sans qu’on le voie.

Le pattern hybride qui marche souvent

Beaucoup de projets PME avancés finissent en prompt engineering + RAG, rarement en fine-tuning pur. Quand la spécialisation ne suffit pas, on combine :

1. Prompt engineering pour le cadre, les règles, le format.
2. RAG pour les données dynamiques et les citations.
3. Fine-tuning léger (LoRA) uniquement si le style de sortie reste insuffisant.

Cette stack hybride couvre la plupart des cas d’usage PME.

Table récapitulative par cas d’usage

Cas d’usage	Stack recommandée	Ce qui fait varier le coût
Classification tickets support	Prompt engineering	Volume et longueur des tickets
Assistant support sur catalogue	RAG + prompt	Taille du catalogue, fréquence de mise à jour
Résumé emails hebdo	Prompt engineering	Volume et longueur des emails
Assistant juridique avec citation	RAG strict + prompt	Taille du corpus, exigence de citation précise
Générateur propales commerciales	RAG (templates) + prompt	Nombre de templates, intégration au CRM
Chatbot FAQ externe	RAG + prompt + garde-fous	Trafic, niveau de garde-fous
Rédaction en style éditorial strict	Prompt + RAG + éventuellement fine-tune	Taille du corpus de style, cycles d’entraînement si fine-tune
Classification médicale spécialisée	Fine-tune LoRA + RAG	Volume de données annotées, cycles d’évaluation
Auto-complete IDE interne	Fine-tune full	Taille du modèle, heures de GPU

L’erreur qu’on voit le plus

Fine-tuner avant d’avoir épuisé prompt + RAG. Un projet démarré en fine-tune peut parfois se résoudre à moindre coût avec RAG + bon prompt. Le fine-tuning fascine, c’est visible sur le CV, mais c’est rarement la bonne première brique.

Règle d’or : prompt d’abord, RAG si les données changent, fine-tune seulement en dernier recours.

Votre cas à décider

Pour arbitrer entre les 3 sur un projet précis, trois questions suffisent : à quelle fréquence les données changent-elles, faut-il citer les sources, et quel écart reste-t-il entre le résultat d’un bon prompt et la qualité visée ? Les réponses orientent vers prompt seul, RAG ou fine-tuning.

Pour aller plus loin

• RAG ou fine-tuning ? Le choix technique qui change tout le TCO — Fine-tuner un modèle LLM ou monter un RAG sur votre
• Prompt engineering pour entreprise en 2026 — la méthode qui marche vra… — Au-delà du ‘soyez précis’
• Prompt engineering en entreprise 2026 — ce qui marche vraiment, ce qui… — Patterns concrets de prompt engineering testés en production chez nos
• MCP servers en entreprise : le protocole qui change la donne — Model Context Protocol (MCP) permet enfin d’intégrer proprement Claude, GPT