Skip to main content
← ArticlesRead in English
15 novembre 2025·Alien6 Research

Prompt Engineering vs Fine-Tuning : quelle stratégie choisir

Un cadre d'ingénierie pour choisir entre prompt engineering, fine-tuning et RAG selon les compromis coût, latence et qualité.

LLMPrompt EngineeringFine-Tuning

Prompt engineering vs fine-tuning : quelle stratégie adopter

La question revient dans chaque projet LLM : faut-il investir dans le prompt engineering, fine-tuner un modèle, ou construire un système RAG ? Ce n'est pas une question de préférence technique — c'est une décision d'ingénierie avec des implications sur les coûts, la maintenabilité, la latence et la qualité.

Le cadre de décision

Trois dimensions structurent le choix :

1. Stabilité du domaine : vos données et vos règles métier changent-elles fréquemment ? 2. Volume de données d'entraînement : avez-vous des centaines ou des milliers d'exemples labelisés ? 3. Contraintes opérationnelles : quelles sont vos exigences de latence, de coût, de confidentialité ?

Quand le prompt engineering suffit

Le prompting est la bonne réponse quand :

  • Le domaine est volatile : les règles changent souvent, le modèle doit s'adapter rapidement
  • Vous avez peu de données d'entraînement (< 100 exemples)
  • Le modèle de base couvre déjà le domaine (langues courantes, tâches générales)
  • Vous avez besoin de flexibilité : modifier le comportement en production sans re-déploiement
Heuristique empirique : un system prompt bien structuré permet souvent
d'atteindre ~80% de la qualité accessible sans fine-tuning — selon le domaine
et la tâche. Ce chiffre varie significativement en pratique.

Les techniques de prompting avancées — chain-of-thought, few-shot examples, structured outputs avec JSON schema, role prompting — permettent d'atteindre des performances remarquables. L'investissement est faible, l'itération est rapide, le coût marginal est nul.

Limite critique : le prompting ne peut pas injecter de connaissance factuelle que le modèle n'a pas. Pour des données propriétaires ou récentes, il faut RAG ou fine-tuning.

Quand fine-tuner

Le fine-tuning devient pertinent quand :

  • Le domaine est stable et spécialisé (terminologie technique, format de sortie très contraint)
  • Vous avez suffisamment de données (500+ exemples de haute qualité, idéalement 5000+)
  • Vous avez des contraintes de latence : un modèle fine-tuné plus petit bat souvent un grand modèle avec un long system prompt
  • Vous avez des contraintes de confidentialité fortes : dans ce cas, le point décisif n'est pas le fine-tuning en soi mais le mode d'hébergement du modèle et du pipeline — fine-tuner via un service externe ne résout pas automatiquement le sujet
# Structure typique d'un dataset de fine-tuning (format OpenAI)
training_example = {
    "messages": [
        {
            "role": "system",
            "content": "Tu es un assistant spécialisé en droit français des contrats."
        },
        {
            "role": "user",
            "content": "Quelle est la différence entre une clause pénale et des dommages-intérêts ?"
        },
        {
            "role": "assistant",
            "content": "La clause pénale est une stipulation contractuelle...",
            # Réponse experte validée par un juriste
        }
    ]
}

Le fine-tuning sur des modèles open-source (Mistral, LLaMA 3, Qwen) avec des techniques comme LoRA ou QLoRA permet d'obtenir des modèles domain-specific en quelques heures sur du hardware accessible.

Quand utiliser RAG plutôt que fine-tuning

RAG est souvent confondu avec le fine-tuning, mais ils répondent à des besoins différents :

Besoin Fine-tuning RAG
Style/format de réponse Oui Non
Connaissances factuelles récentes Limité Oui
Corpus volumineux (>10K docs) Impraticable Oui
Traçabilité des sources Non Oui
Mise à jour en temps réel Non Oui

La règle empirique : fine-tunez pour le comment (style, format, comportement), utilisez RAG pour le quoi (contenu factuel, connaissances métier).

Matrice de coût comparée

Stratégie Coût initial Coût marginal/requête Maintenance
Prompting seul Faible Élevé (grand modèle) Faible
RAG Moyen (infra index) Moyen Moyen (index)
Fine-tuning + modèle hébergé Moyen Faible (petit modèle) Élevé
Fine-tuning + déploiement propre Élevé Très faible Très élevé

La stratégie combinée

En pratique, les systèmes production-grade combinent les trois approches :

  1. Un modèle fine-tuné pour le style, le format et les comportements critiques
  2. RAG pour injecter les connaissances domaine et les données récentes
  3. Des prompts système pour les instructions contextuelles et les guardrails

Cette architecture en couches maximise la qualité tout en minimisant les coûts à l'échelle. La clé est de ne pas sur-investir dans le fine-tuning avant d'avoir épuisé les gains accessibles par prompting et RAG — dans cet ordre.