RAG vs Fine-Tuning vs Prompt Engineering : La Matrice de Décision 2026

Les Trois Techniques Expliquées

Toute application IA en production qui va au-delà d'un prompt statique utilise au moins l'un des trois patterns architecturaux. Comprendre ce que chaque pattern fait — et ce qu'il ne peut pas faire — est le prérequis à la matrice de décision qui suit.

Prompt Engineering : Instruction sans Mémoire

Le prompt engineering consiste à construire le system prompt, les exemples few-shot et la structure du message utilisateur pour obtenir un comportement cohérent d'un LLM non modifié. Les poids du modèle ne changent jamais ; vous façonnez l'entrée, pas le modèle.

• Temps de mise en place : 1 à 3 jours pour un system prompt de qualité production avec évaluation
• Fraîcheur des données : limitée à la date de coupure du modèle de base (obsolète pour les domaines dynamiques)
• Coût par requête : uniquement l'inférence — tokens en entrée + tokens en sortie
• Maintenance : modifier le prompt quand le comportement souhaité évolue
• Plafond : ne peut pas accéder aux informations créées après l'entraînement ; ne garantit pas la cohérence du format à grande échelle

RAG : Injection Dynamique de Connaissances

La Génération Augmentée par Récupération (RAG) laisse le LLM de base intact mais récupère des documents pertinents au moment de la requête et les injecte dans la fenêtre de contexte. Le modèle raisonne sur vos données sans les stocker dans ses poids.

• Temps de mise en place : 1 à 2 semaines (stratégie de chunking, choix du modèle d'embedding, vector DB, tuning du retrieval)
• Fraîcheur des données : temps réel — ajoutez un document à l'index et la prochaine requête le voit
• Coût par requête : recherche d'embeddings + retrieval + inférence LLM (environ 1,4 à 2× le coût prompt seul)
• Maintenance : maintenir l'index à jour ; ajuster la taille des chunks et la stratégie de retrieval à mesure que le corpus grandit
• Plafond : la qualité du retrieval détermine la qualité de la génération — le principe garbage-in garbage-out s'applique à la couche de récupération

Fine-Tuning : Ancrage des Connaissances dans les Poids

Le fine-tuning modifie les poids du modèle sur vos données de domaine via un entraînement supervisé (fine-tune complet) ou des adaptateurs à paramètres efficaces (LoRA, QLoRA). Le résultat est un modèle qui "connaît" votre domaine implicitement, sans documents injectés au moment de la requête.

• Temps de mise en place : 4 à 8 semaines (collecte de données, nettoyage, entraînement, évaluation, déploiement)
• Fraîcheur des données : statique — nécessite un réentraînement pour intégrer de nouvelles informations
• Coût par requête : le plus bas à grande échelle (GPU auto-hébergé, pas de frais par token), le plus élevé à faible volume (GPU dédié requis)
• Maintenance : réentraîner selon un calendrier ; versionner les adaptateurs ; tests de régression après chaque réentraînement
• Plafond : oubli catastrophique ; la qualité des données d'entraînement détermine la qualité du modèle ; inadapté aux domaines à évolution rapide

Matrice de Benchmarks 2026

Les benchmarks suivants combinent des résultats de trois déploiements production chez Talki Academy et des évaluations publiquement disponibles. Infrastructure : API Claude Sonnet 4.5 (EU-West-1) ; Qwen3-32B et Mistral Small 3.2 auto-hébergés sur un seul RTX 4090 (24 Go de VRAM) via Ollama. Pipeline RAG : Qdrant + nomic-embed-text (768 dimensions). Fine-tuning : adaptateur LoRA rang-16, entraîné sur Modal A100.

Latence (p50 / p95, end-to-end, EU-West)

Précision par Type de Tâche (échelle 0–100, évaluation interne)

Coût pour 1 000 Requêtes (EUR, tarifs 2026)

Arbre de Décision : 5 Questions vers la Bonne Architecture

Répondez à ces questions dans l'ordre. Arrêtez dès que vous atteignez une recommandation.

Calculateur ROI : Exemples Pratiques

Scénario A : Bot FAQ RH Interne (20 000 requêtes/mois)

Scénario B : Conseiller Produit E-commerce (500 000 requêtes/mois)

4 Études de Cas

Étude de Cas 1 : Fintech — Classification d'Alertes Fraude

Entreprise : fintech européenne, 2,1 millions de comptes actifs. Tâche : classifier les messages entrants comme alertes fraude (nécessitant une revue humaine en 15 min) ou requêtes routines (résolution automatique). Volume : 180 000 messages/mois.

L'équipe a commencé avec du prompt engineering sur Claude Sonnet 4.5. Précision : 86%. Le taux d'erreur de 14% représentait 25 200 mauvaises classifications par mois — inacceptable car les faux négatifs (alertes fraude manquées) engageaient la responsabilité financière directe. RAG a été évalué puis rejeté : il n'y avait pas de documents à récupérer. Il s'agit d'une tâche de classification sur des messages courts, pas d'un problème de récupération de connaissances.

Solution :Fine-tuning de Mistral 7B (LoRA, rang-16) sur 28 000 messages historiques labellisés. Résultat : précision de 97,3%. Taux de faux négatifs (fraudes manquées) : 0,8% vs. 7,2% avec le prompt seul. Latence : 155ms p50, bien sous le SLA de 200ms. Coût mensuel d'inférence : 660 EUR (instance GPU dédiée). Le coût réglementaire des alertes fraude manquées dépassait largement l'investissement en fine-tuning ; le projet s'est rentabilisé le premier mois.

Étude de Cas 2 : E-commerce — Conseiller Produit Multilingue

Entreprise : marketplace UE, 380 000 SKU dans 6 langues. Tâche :répondre à des questions produit précises (dimensions, compatibilité, politique de retour) dans la langue de l'utilisateur. Volume : 420 000 requêtes/mois.

Le prompt engineering a échoué immédiatement : avec 380 000 SKU, aucune connaissance produit ne pouvait tenir dans une fenêtre de contexte. Le fine-tuning a été envisagé puis rejeté : le catalogue change à 15% par mois (nouveaux produits, changements de prix, mises à jour de spécifications). Réentraîner mensuellement à 340 EUR/run plus 2 jours d'ingénierie n'était pas viable.

Solution : Pipeline RAG — Qdrant auto-hébergé (2× RTX 4090, datacenter UE), catalogue produit chunké en JSON structuré par SKU, embeddings nomic-embed-text, Qwen3-32B comme modèle de génération. Résultat : précision des réponses à 93,8%. Latence de récupération moyenne : 180ms (recherche ANN Qdrant). Latence totale : 640ms p50. Coût mensuel : 290 EUR (électricité GPU + Qdrant). Mises à jour du catalogue poussées toutes les 6 heures via pipeline ETL.

Étude de Cas 3 : Support Client — Déflexion Niveau 1

Entreprise : SaaS B2B, 4 200 clients enterprise. Tâche : résoudre automatiquement les tickets support Niveau 1 en utilisant la base de connaissances (2 400 articles, mise à jour hebdomadaire). Volume : 35 000 tickets/mois.

Implémentation initiale : RAG sur la base de connaissances + Claude Sonnet 4.5. Taux de résolution automatique : 58%. Satisfaisant, mais l'équipe visait 72% pour justifier la réduction de poste. L'analyse a montré que l'écart venait de deux sources : (1) tickets référençant du jargon interne absent de tout article (noms de codes produit, noms de processus internes), (2) tickets procéduraux multi-étapes nécessitant une sortie structurée que le prompt ne pouvait pas imposer de façon fiable.

Solution :Architecture hybride — RAG pour la récupération de connaissances + Qwen3-7B fine-tuné pour le formatage des sorties. Le fine-tuning a été entraîné spécifiquement sur la structure de sortie (templates de résolution de ticket), pas sur la connaissance. Résultat : taux de résolution automatique de 74%. Coût du fine-tuning : 60 EUR (LoRA sur Modal A100, 6 heures). Coût mensuel d'inférence réparti : récupération RAG via Qdrant (42 EUR/mois), génération via Qwen3-7B LoRA auto-hébergé (330 EUR/mois dédié).

Étude de Cas 4 : Legal Tech — Extraction de Clauses Contractuelles

Entreprise : startup legal tech, droit des contrats UE. Tâche : extraire et classifier les obligations contractuelles (paiement, responsabilité, confidentialité, résiliation) dans des contrats B2B en français. Volume : 8 000 contrats/mois.

Précision du prompt engineering sur le français juridique : 71%. Le modèle de base confondait systématiquement les obligations et les clauses déclaratives — une distinction sémantique qui requiert une formation juridique pour être faite de façon fiable. RAG a amélioré ce chiffre à 79% en récupérant des clauses similaires depuis une base de précédents, mais ratait encore 21% — toujours inacceptable pour les workflows de revue juridique.

Solution :Fine-tuning de Mistral 7B (LoRA complet) sur 12 000 clauses contractuelles annotées en français juridique. Coût d'entraînement : 380 EUR (A100, 8 heures). Précision : 96,2%. Taux de faux négatifs sur les clauses de responsabilité (catégorie à risque le plus élevé) : 1,1%. Le modèle fine-tuné tourne sur une instance A100 unique à 1,10 EUR/heure, traitant l'intégralité des 8 000 contrats/mois dans une fenêtre de traitement quotidienne de 4 heures. Réentraînement programmé trimestriellement (les standards juridiques évoluent lentement).

Code Prêt à l'Emploi pour Chaque Approche

Prompt Engineering — Claude Sonnet 4.5 avec Sortie Structurée

# pip install anthropic>=0.34.0

import anthropic
import json

client = anthropic.Anthropic()

SYSTEM_PROMPT = """Vous êtes un spécialiste du support produit pour une plateforme e-commerce.
Répondez aux questions clients en utilisant UNIQUEMENT les informations produit fournies ci-dessous.
Si la réponse ne se trouve pas dans les informations, dites "Je n'ai pas cette information."

Répondez en JSON : {"reponse": "...", "confiance": "haute|moyenne|faible", "source": "..."}
"""

def repondre_question(question: str, info_produit: str) -> dict:
    response = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=512,
        system=SYSTEM_PROMPT,
        messages=[{
            "role": "user",
            "content": f"Information produit :\n{info_produit}\n\nQuestion : {question}"
        }]
    )

    texte = response.content[0].text
    try:
        return json.loads(texte)
    except json.JSONDecodeError:
        return {"reponse": texte, "confiance": "faible", "source": "brut"}

# Utilisation
resultat = repondre_question(
    question="Quelle est la durée de garantie du casque Pro X5 ?",
    info_produit="Casque sans fil Pro X5 : batterie 40h, ANC, garantie fabricant 2 ans, étanchéité IPX4"
)
print(resultat)
# {"reponse": "Le casque Pro X5 bénéficie d'une garantie fabricant de 2 ans.",
#  "confiance": "haute", "source": "spec produit"}

Pipeline RAG — LangChain + Qdrant + nomic-embed-text (Ollama)

# pip install langchain langchain-community langchain-ollama qdrant-client

from langchain_ollama import OllamaEmbeddings, ChatOllama
from langchain_community.vectorstores import Qdrant
from langchain_core.documents import Document
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough
from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams

# --- 1. Initialisation du modèle d'embedding et du vector store ---
embeddings = OllamaEmbeddings(model="nomic-embed-text")  # 768 dims, gratuit

client = QdrantClient(url="http://localhost:6333")
client.recreate_collection(
    collection_name="catalogue_produits",
    vectors_config=VectorParams(size=768, distance=Distance.COSINE)
)

# --- 2. Indexation des documents ---
docs = [
    Document(
        page_content="Casque sans fil Pro X5 : batterie 40h, ANC, garantie 2 ans, IPX4, USB-C",
        metadata={"sku": "PX5-001", "categorie": "audio"}
    ),
    Document(
        page_content="Chaussures de running ZeroG : tailles 38-48, plaque carbone, drop 10mm, garantie 3 ans structure",
        metadata={"sku": "ZG-RUN-42", "categorie": "chaussures"}
    ),
]

vector_store = Qdrant.from_documents(
    docs, embeddings,
    url="http://localhost:6333",
    collection_name="catalogue_produits"
)

# --- 3. Construction de la chaîne RAG ---
retriever = vector_store.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 4, "fetch_k": 12}
)

llm = ChatOllama(model="qwen3:32b", temperature=0)

prompt = ChatPromptTemplate.from_template("""
Répondez à la question en utilisant uniquement le contexte ci-dessous.
Si la réponse est absente, dites "Je n'ai pas cette information."

Contexte : {context}
Question : {question}
Réponse :""")

def formater_docs(docs):
    return "\n\n".join(f"[{d.metadata.get('sku', 'N/A')}] {d.page_content}" for d in docs)

chaine_rag = (
    {"context": retriever | formater_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

# --- 4. Requête ---
reponse = chaine_rag.invoke("Quelle est la garantie du casque Pro X5 ?")
print(reponse)
# "Le casque Pro X5 est couvert par une garantie fabricant de 2 ans."

Fine-Tuning — LoRA sur Mistral 7B avec Modal + HuggingFace

# pip install modal transformers datasets peft trl torch

# Sauvegarder sous fine_tune_job.py, lancer : modal run fine_tune_job.py

import modal

app = modal.App("exemple-finetuning-rag")
image = modal.Image.debian_slim().pip_install(
    "transformers>=4.47", "datasets", "peft>=0.14", "trl>=0.12", "torch", "bitsandbytes"
)

@app.function(
    gpu="A100-40GB",
    timeout=14400,
    image=image,
    secrets=[modal.Secret.from_name("huggingface-token")]
)
def entrainer_classificateur():
    import os
    from datasets import Dataset
    from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments
    from peft import LoraConfig, get_peft_model
    from trl import SFTTrainer

    # --- 1. Chargement du modèle de base ---
    model_id = "mistralai/Mistral-7B-Instruct-v0.3"
    tokenizer = AutoTokenizer.from_pretrained(model_id, token=os.environ["HF_TOKEN"])
    model = AutoModelForCausalLM.from_pretrained(
        model_id,
        token=os.environ["HF_TOKEN"],
        load_in_4bit=True,  # QLoRA — économise la VRAM
        device_map="auto"
    )

    # --- 2. Configuration LoRA ---
    lora_config = LoraConfig(
        r=16,           # rang — plus élevé = plus de paramètres, plus de capacité, plus coûteux
        lora_alpha=32,
        target_modules=["q_proj", "v_proj", "k_proj", "o_proj"],
        lora_dropout=0.1,
        bias="none",
        task_type="CAUSAL_LM"
    )
    model = get_peft_model(model, lora_config)
    model.print_trainable_parameters()
    # params entraînables : ~8,4M || total : ~3,75B || % entraînable : ~0,22%

    # --- 3. Préparation des données d'entraînement ---
    exemples = [
        {
            "text": "<s>[INST] Classifiez ce ticket : 'Ma carte a été débitée deux fois' [/INST] ALERTE_FRAUDE</s>"
        },
        {
            "text": "<s>[INST] Classifiez ce ticket : 'Où est ma commande n°48291 ?' [/INST] REQUETE_ROUTINE</s>"
        },
        # ... minimum 5 000 exemples pour la qualité production
    ]
    dataset = Dataset.from_list(exemples)

    # --- 4. Entraînement ---
    training_args = TrainingArguments(
        output_dir="/tmp/adaptateur-lora",
        num_train_epochs=3,
        per_device_train_batch_size=4,
        gradient_accumulation_steps=4,
        learning_rate=2e-4,
        fp16=True,
        logging_steps=50,
        save_strategy="epoch",
        report_to="none"
    )

    trainer = SFTTrainer(
        model=model,
        args=training_args,
        train_dataset=dataset,
        dataset_text_field="text",
        max_seq_length=512
    )

    trainer.train()

    # --- 5. Sauvegarde de l'adaptateur uniquement (~80 Mo vs ~14 Go pour le modèle complet) ---
    model.save_pretrained("/tmp/adaptateur-lora/final")
    tokenizer.save_pretrained("/tmp/adaptateur-lora/final")
    print("Entraînement terminé. Adaptateur sauvegardé.")

Questions Fréquentes