Fine-tuning vs prompt engineering : un arbre de décision honnête pour 2026

La question revient dans presque chaque projet IA qu'on accompagne : "est-ce qu'on devrait fine-tuner ?". En 2024, la réponse correcte était souvent "non, d'abord exploite mieux le prompt". En 2026, c'est plus nuancé, les coûts d'inférence ont baissé, les techniques PEFT ont mûri, mais les pièges restent les mêmes.

Ce texte ne défend pas une réponse universelle. Il documente notre arbre de décision réel, avec les critères qui tranchent.

La question préalable que presque personne ne pose

Avant de choisir entre fine-tuning et prompting, il faut poser une question plus fondamentale : est-ce un problème de connaissance ou un problème de comportement ?

• Problème de connaissance : le modèle ne sait pas ce qu'il faut savoir (données propriétaires, référentiel métier, base documentaire récente). RAG ou context stuffing résolvent ça. Le fine-tuning ne le résout pas bien, un modèle fine-tuné "mémorise" des patterns, il ne stocke pas des faits récupérables de façon fiable.
• Problème de comportement : le modèle sait mais ne répond pas dans le bon format, le bon ton, le bon raisonnement. C'est là que le fine-tuning devient pertinent.

Cette distinction élimine environ 60 % des demandes de fine-tuning qu'on reçoit. La plupart sont des problèmes de knowledge retrieval déguisés.

L'arbre de décision

Le modèle a-t-il accès à l'information nécessaire ?
├─ Non → RAG ou context enrichment d'abord
└─ Oui → Le comportement est-il stable et reproductible en prompting ?
           ├─ Oui → Rester sur le prompting, optimiser le prompt
           └─ Non → Le volume de données labelisées est-il > 500 exemples ?
                     ├─ Non → Collecter les données d'abord
                     └─ Oui → Fine-tuning (LoRA si ressources limitées)

Ce schéma simplifie, mais il force à répondre dans l'ordre. La plupart des équipes sautent directement à "fine-tuning" parce que ça sonne plus sérieux.

Quand le prompting suffit, et pourquoi on le sous-estime

Un prompt bien construit avec des exemples few-shot couvre une surface large de comportements. Les modèles de 2025-2026 (GPT-4o, Claude 3.5/3.7, Gemini 1.5 Pro) suivent les instructions avec une fidélité qu'on n'avait pas il y a deux ans.

Ce qu'on obtient gratuitement avec un bon prompt :

• Format de sortie contrôlé (JSON schema, markdown structuré)
• Ton et registre adaptés (formel, technique, grand public)
• Raisonnement guidé par des exemples (chain-of-thought)
• Contraintes métier explicites

Ce qu'on n'obtient pas facilement en prompting :

• Cohérence à très grande échelle d'appels (le prompt long coûte à chaque requête)
• Comportement ultra-spécialisé sur un jargon de niche sans exemples en contexte
• Réduction de la latence liée à des prompts système massifs

Le coût du prompt long est souvent le vrai déclencheur du fine-tuning. Si votre prompt système fait 3 000 tokens et que vous faites 10 millions d'appels par mois, le calcul change.

Quand le fine-tuning devient rationnel

Il y a trois scénarios où fine-tuner est défendable :

1. Le coût d'inférence est prohibitif à cause du context length. Un prompt système de 4 000 tokens à 10 M requêtes/mois sur GPT-4o représente environ 160 000 dollars d'input tokens. Un modèle fine-tuné avec un prompt système de 200 tokens peut réduire ce poste de 90 %. Le fine-tuning s'amortit.

2. Le comportement cible est trop complexe pour tenir en exemples few-shot. Certains workflows de raisonnement spécialisé (annotation médicale, classification juridique multi-niveaux, génération de code dans un DSL propriétaire) atteignent leurs limites en prompting pur. Avec 1 000 à 5 000 exemples bien labelisés, le fine-tuning donne une régularité qu'on n'atteint pas autrement.

3. La latence du prompt long est incompatible avec l'UX. Chaque token d'input compte dans la TTFT (time to first token). Sur un produit temps-réel, un prompt de 5 000 tokens peut ajouter 400-600 ms. Un modèle fine-tuné avec un prompt court est systématiquement plus rapide.

LoRA et PEFT : ce que ça change vraiment

LoRA (Low-Rank Adaptation) et les techniques PEFT (Parameter-Efficient Fine-Tuning) ont rendu le fine-tuning accessible à des équipes qui n'ont pas de cluster GPU dédié. L'idée de LoRA est d'entraîner uniquement des matrices de faible rang additionnées aux poids existants, plutôt que de modifier l'intégralité du modèle.

Ce que ça change en pratique :

# Fine-tuning LoRA avec peft + transformers
from peft import LoraConfig, get_peft_model

lora_config = LoraConfig(
    r=16,           # rang des matrices, plus bas = moins de params
    lora_alpha=32,  # scaling factor
    target_modules=["q_proj", "v_proj"],  # couches ciblées
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM"
)

model = get_peft_model(base_model, lora_config)
model.print_trainable_parameters()
# trainable params: 4,194,304 || all params: 6,742,609,920 || trainable%: 0.062

Un Mistral 7B avec LoRA r=16 entraîne environ 4 M de paramètres sur 6,7 milliards. L'empreinte mémoire GPU passe de ~14 GB (full fine-tune en fp16) à ~6 GB. Sur un A100 40GB, on peut faire tourner ça avec des batches raisonnables.

Le résultat est un adaptateur léger (quelques centaines de Mo) qu'on fusionne ou qu'on charge à la volée sur le modèle de base. Le coût d'hébergement reste proche d'un modèle non fine-tuné.

RAG vs fine-tuning : l'arbitrage mal compris

On nous demande régulièrement lequel choisir entre RAG et fine-tuning. La réponse est : ce n'est pas le même problème.

RAG adresse l'accès à l'information. Fine-tuning adresse le comportement du modèle. Les deux sont souvent complémentaires : on fine-tune pour le comportement, on ajoute RAG pour la connaissance métier.

L'erreur qu'on voit le plus souvent : fine-tuner sur un corpus documentaire en espérant que le modèle "apprenne" les faits dedans. Le modèle va mémoriser des patterns de surface, pas des faits récupérables. Résultat : hallucinations confiantes sur des données qui "ressemblent" au corpus d'entraînement.

Ce qu'on recommande concrètement

1. Commencer par un prompt bien construit avec 5-10 exemples few-shot. Mesurer les résultats sur un jeu d'évaluation.
2. Si les résultats sont insuffisants, identifier si c'est un problème de connaissance (→ RAG) ou de comportement (→ fine-tuning).
3. Pour le fine-tuning, ne pas commencer sans au moins 300-500 exemples labelisés manuellement. En dessous, le signal est trop bruité.
4. Préférer LoRA sur un modèle open-source si le budget inférence est contraint. L'API fine-tuning d'OpenAI est plus simple à démarrer mais crée une dépendance tarifaire.
5. Conserver un jeu d'évaluation séparé et le faire tourner à chaque nouvel adaptateur.

La vraie limite du fine-tuning reste la donnée. Construire un jeu d'entraînement propre, cohérent et suffisamment grand coûte plus cher que l'entraînement lui-même dans la plupart des projets qu'on a vus. C'est cet investissement qu'il faut chiffrer avant de décider.

La question qu'on laisse ouverte : à quel volume d'exemples le fine-tuning cesse-t-il d'apporter un gain marginal significatif par rapport à un prompting optimisé avec retrieval contextuel ? Les benchmarks publics donnent des réponses contradictoires selon les domaines.