RAG vs fine-tuning vs prompt engineering

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

Comparaison des 3 techniques principales pour spécialiser un LLM en 2026 : RAG, fine-tuning, prompt engineering. Coûts, qualité, latence, cas d'usage concrets PME.

Question qu’on nous pose une fois par semaine : “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 : quelques dizaines de k€ pour une première version. 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 : 15 à 80 k€ par cycle, selon volume + infra. Changement : ré-entraîner ou continuer l’entraînement.

La grille de décision

CritèrePrompt EngineeringRAGFine-tuning
Coût initial0,5-3 k€20-60 k€15-80 k€
Coût exploitationAPI LLM standardAPI + base vectorielleAPI + compute
Latence ajoutée0 ms+100-400 ms0 ms (ou même plus rapide)
Temps de mise en oeuvreJoursSemainesMois
Données dynamiques
Volume de casIllimitéIllimitéLimité par budget
Qualité sur cas général85-92 %85-92 %82-95 %
Qualité sur cas spécialisé70-82 %85-95 %88-96 %
Citations sources
Risque hallucinationsMoyenFaible (si bien fait)Moyen
Dépendance modèleFaible (migrer facile)FaibleForte (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 (< 20k tokens).
  • La qualité attendue est 85-92 %, acceptable pour l’usage.
  • Le budget est contraint (< 5 k€) 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.

Budget typique : 500 € à 3 000 € pour un prompt en production. Temps : 8-15 h sur 2-3 semaines.

Ce qui ne passera pas avec cette approche : nécessité de citer des sources, données qui changent toutes les semaines, volume de documents > 20k tokens.

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 (> 50-100 pages).

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 4.6 Sonnet ou Mistral Large avec contexte injecté + instructions d’ancrage strict.

Budget typique : 25 000 - 60 000 € pour une première version. Exploitation : +100-300 € / mois pour la base vectorielle.

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 vrais cas utilisateurs (80 % des RAG sont validés sur 20 cas choisis et cassent 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 (> 500k requêtes/mois).

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 : 5-15 k€ par cycle.
  • Full fine-tune sur modèle open : 30-80 k€.
  • Fine-tune Anthropic / OpenAI : via leur service, 5-25 k€ selon modèle.

Budget total : compter 1 cycle = 1 formation + évaluation + redéploiement. Deux à trois cycles sont souvent nécessaires avant d’atteindre la qualité cible. Budget total : 40 000 - 150 000 €.

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 50 exemples — minimum 500, idéalement 2000+ pour un résultat stable.
  • Fine-tuner sans plan d’évaluation rigoureux — 70 % des fine-tunes se dégradent sans qu’on le voie.

Le pattern hybride qui marche souvent

En 2026, la majorité de nos 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 95 % des cas d’usage PME avec un bon ratio qualité/coût.

Table récapitulative par cas d’usage

Cas d’usageStack recommandéeBudget 1re version
Classification tickets supportPrompt engineering2-5 k€
Assistant support sur catalogueRAG + prompt25-50 k€
Résumé emails hebdoPrompt engineering3-8 k€
Assistant juridique avec citationRAG strict + prompt40-90 k€
Générateur propales commercialesRAG (templates) + prompt18-40 k€
Chatbot FAQ externeRAG + prompt + garde-fous25-55 k€
Rédaction en style éditorial strictPrompt + RAG + éventuellement fine-tune35-100 k€
Classification médicale spécialiséeFine-tune LoRA + RAG50-120 k€
Auto-complete IDE interneFine-tune full80-150 k€

L’erreur qu’on voit le plus

Fine-tuner avant d’avoir épuisé prompt + RAG. Plus d’un projet sur 3 qui arrive chez nous démarré en fine-tune pourrait être résolu à 2-3x moins cher 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

Si vous hésitez entre les 3 pour un projet précis, 30 minutes au téléphone. On regarde vos données, votre contrainte de fraîcheur, votre budget, et on vous dit quelle stack on déploierait chez vous et pourquoi. Sans engagement.

Pour aller plus loin