Choisir entre le prompting, le RAG et le fine-tuning (et quand les combiner)

Une équipe reçoit la mission suivante : « Améliorez notre IA afin qu’elle traite mieux notre cas d’usage. » Plusieurs solutions s’offrent à elle : rédiger de meilleurs prompts, construire un système RAG qui fournit au modèle les données pertinentes ou affiner le modèle à partir d’exemples propres à son domaine.

Ces trois approches ne sont pas interchangeables : elles résolvent des problèmes différents. Un mauvais choix peut conduire à consacrer trois mois et un budget important au fine-tuning alors qu’un meilleur prompt aurait suffi, à bâtir une infrastructure RAG complexe alors qu’un modèle affiné aurait été plus simple, ou à multiplier les prompts alors que le modèle ne possède pas les capacités requises.

Cet article propose un cadre de décision : quand utiliser chaque approche, quand les combiner, quels sont leurs coûts réels et ce qui fonctionne ou échoue généralement en production.

Ce que chacune fait réellement

Une distinction claire :

Le prompting modifie les instructions données au modèle. Vous lui fournissez de meilleures consignes, des exemples, des exigences de format et du contexte. Le modèle lui-même ne change pas ; seule son entrée évolue.

Le RAG modifie les données que le modèle voit. Vous récupérez des informations pertinentes au moment de la requête et les incluez dans le prompt. Le modèle a accès à des données fraîches, spécifiques, dynamiques sans avoir été entraîné dessus.

Le fine-tuning modifie les connaissances ou le comportement du modèle. Vous l’entraînez sur des exemples et modifiez ainsi ses poids.

Ces trois approches résolvent des problèmes différents :

• Écart d’instruction : le modèle pourrait faire la tâche s’il était correctement interrogé. → Prompting.
• Écart de connaissance : le modèle a besoin d’informations qu’il ne possède pas. → RAG.
• Écart de capacité : le modèle ne peut pas faire la tâche de manière fiable même avec de bons prompts et du contexte. → Fine-tuning.

Identifier correctement cet écart représente la moitié du travail.

Diagnostiquer l’écart

Lorsque l’IA ne répond pas à vos besoins, posez-vous la question suivante :

Une personne compétente pourrait-elle accomplir cette tâche avec le seul prompt ?

Si oui → écart d’instruction. Un meilleur prompt devrait résoudre le problème.

Sinon, pourrait-elle le faire avec des documents de référence pertinents ?

Si oui → écart de connaissance. Le RAG peut résoudre le problème.

Sinon, pourrait-elle y parvenir après un entraînement et des retours approfondis ?

Si oui → écart de capacité. Le fine-tuning pourrait résoudre le problème.

Sinon → la tâche ne se prête peut-être pas à un LLM. Réexaminez le problème.

La plupart des problèmes « l’IA ne fonctionne pas » sont des écarts d’instruction — un meilleur prompting résout le problème. Le deuxième type le plus courant est l’écart de connaissance. Les écarts de capacité sont la catégorie la plus petite mais la plus difficile à résoudre.

Prompting : le levier sous-estimé

Le prompting est le moins coûteux, le plus rapide, et souvent la bonne réponse. Pourtant, les équipes passent souvent outre pour se tourner vers le RAG ou le fine-tuning.

Le prompting seul permet notamment de :

• Changer le ton, le format, la longueur.
• Appliquer des schémas de raisonnement (chaîne de pensée, auto-critique).
• Encoder des contraintes (faire X, ne pas faire Y).
• Encoder des politiques et des garde-fous.
• Adapter à des cas d’utilisation spécifiques (différents prompts pour différentes fonctionnalités).
• Améliorer la cohérence grâce à quelques exemples.

Ce que vous ne pouvez pas faire avec le prompting seul :

• Donner au modèle des faits qu’il ne connaît pas.
• Faire en sorte qu’un petit modèle se comporte comme un grand.
• Modifier fondamentalement la voix ou le style du modèle à un niveau profond.
• Accélérer l’inférence du modèle.

Une règle raisonnable consiste à commencer par le prompting et à itérer pendant au moins une semaine avant de passer au RAG ou au fine-tuning. Dans de nombreux cas, il résoudra le problème.

Effort d’ingénierie des prompts

Une semaine d’itération intensive sur les prompts peut produire des améliorations spectaculaires. La courbe typique :

• Jour 1 : référence initiale. Résultats médiocres.
• Jour 2-3 : changements structurels. Meilleur format, instructions plus claires. Grandes améliorations.
• Jour 4-5 : exemples et cas limites. Détecte les modes d’échec.
• Jours 6 et 7 : ton, contraintes et finition. Derniers 10 % d’amélioration.

Après une semaine, vous avez extrait la plupart de ce que le prompting peut offrir. Si vous n’êtes toujours pas satisfait, l’écart est probablement de connaissance ou de capacité.

À quoi ressemblent de bons prompts

Pour référence, un prompt solide a généralement :

• Un rôle et une tâche clairs.
• Des exigences de format spécifiques.
• 1 à 5 exemples représentatifs (si nécessaire).
• Des contraintes explicites (ce qu’il faut faire, ce qu’il ne faut pas faire).
• Gestion des cas limites.
• Schéma de sortie.

Il comporte généralement de 5 à 10 paragraphes : ni trop court et sous-spécifié, ni trop long au risque de diluer l’attention du modèle.

RAG : la solution pour les connaissances

Le RAG est le bon outil quand :

• Le modèle a besoin d’informations factuelles qu’il ne possède pas.
• Les informations changent (données en temps réel, événements récents, données spécifiques à un compte).
• Les informations sont spécifiques à votre domaine ou organisation.
• Vous avez besoin de citations ou d’un ancrage vérifiable.

C’est le mauvais outil quand :

• Le problème est un écart d’instruction, pas de connaissance.
• Les données sont suffisamment petites pour être incluses directement dans un prompt.
• Vous devez modifier le comportement du modèle, et non seulement les informations dont il dispose.

Le coût réel

Un système RAG est une véritable ingénierie :

• Construction : 4 à 12 semaines pour un système sérieux comprenant ingestion, segmentation, embeddings, recherche, reclassement et évaluation.
• Exploitation : continue — maintenir l’index à jour, surveiller la qualité, corriger les problèmes.
• Infrastructure : base de données vectorielle, API d’embedding et reclassement. Comptez généralement entre 200 € et 2 000 € par mois pour un système de petite taille.
• Coût par requête : supérieur à celui du prompting seul en raison de l’embedding, de la recherche et d’un contexte plus volumineux. Il atteint généralement 2 à 5 fois celui d’un appel d’API classique.

Cet investissement se justifie pour les problèmes appropriés, mais reste considérable par rapport au prompting.

La qualité du RAG est un parcours

Un système RAG fonctionnel dès la première semaine atteint généralement 60 à 70 % de qualité. Atteindre un niveau de production supérieur à 85 % exige encore un à deux mois : améliorer la segmentation, ajouter le reclassement, corriger les modes d’échec et construire des évaluations.

Planifiez cela. Ne déployez pas en semaine 1 ; vous aurez des utilisateurs mécontents.

Fine-tuning : quand le prompting et le RAG ne suffisent pas

Le fine-tuning est le bon outil quand :

• Vous avez un écart de capacité clair — le modèle ne peut pas faire la tâche de manière fiable même avec de bons prompts et contexte.
• Vous disposez d’un jeu d’exemples d’entraînement de haute qualité : au moins quelques centaines pour un LoRA très ciblé et généralement plus de 1 000 pour obtenir un comportement général fiable. Consultez l’article consacré au fine-tuning pour les seuils propres à chaque technique.
• Vous avez besoin d’un comportement cohérent, étroit (un style spécifique, un format de sortie spécifique, un domaine spécifique).
• Le coût d’inférence / la latence importent (un modèle fine-tuné plus petit peut être moins cher qu’un grand modèle générique).

C’est le mauvais outil quand :

• Vos données sont en flux (le modèle fine-tuné deviendra rapidement obsolète).
• Vous n’avez pas encore épuisé le prompting et le RAG.
• Vous n’avez pas de bonnes évaluations (vous ne pouvez pas dire si le fine-tuning a aidé).
• La tâche nécessite des informations très récentes (le fine-tuning est une capture instantanée).
• Vous essayez d’enseigner des faits : le RAG le fait mieux, de manière plus fiable et avec des citations.

Types de fine-tuning

Fine-tuning complet : tous les poids du modèle sont mis à jour. Le plus puissant, le plus coûteux. Nécessite un calcul important. Généralement réservé aux laboratoires de modèles de base.

LoRA (Low-Rank Adaptation) : seulement un petit sous-ensemble de poids est entraîné. Beaucoup moins cher. Souvent produit des résultats compétitifs avec le fine-tuning complet pour les tâches étroites.

QLoRA : LoRA quantifié, encore moins coûteux. Sa qualité est inférieure à grande échelle, mais convient à de nombreuses tâches.

Prompt tuning / prefix tuning : approche encore plus légère dans laquelle seuls des soft prompts sont entraînés. C’est la moins coûteuse, mais sa capacité reste limitée.

Instruction tuning : entraînement du modèle pour suivre des instructions. Généralement fait au niveau de base ; rarement utile pour les utilisateurs finaux.

RLHF / DPO / KTO : entraînement du modèle pour s’aligner avec des données de préférence (réponses A vs B). Puissant pour les changements de comportement ; complexe à bien faire.

En 2026, la plupart des équipes faisant du fine-tuning utilisent le LoRA sur un modèle de base solide. C’est le bon équilibre entre coût et capacité pour la plupart des cas d’utilisation.

Le coût réel

Les coûts de fine-tuning dépendent de l’approche et de l’échelle, mais typiques pour un fine-tuning LoRA d’un modèle ouvert de taille moyenne sur 5 000 à 10 000 exemples :

• Préparation des données : 1 à 4 semaines. Souvent la majeure partie du travail. Curation, nettoyage, formatage des exemples.
• Entraînement : de quelques heures à plusieurs jours selon la taille du jeu de données et l’infrastructure, pour un coût de calcul compris entre 100 € et 2 000 €.
• Évaluation : 1 à 2 semaines. Construction de jeux d’évaluation, comparaison du fine-tuning et du modèle de base.
• Itération : 1 à 3 cycles avant que quelque chose soit prêt à la production.
• Déploiement : si vous utilisez une API gérée (fine-tuning OpenAI, Anthropic, Vertex), simple. Si vous hébergez vous-même, plus de travail.
• Maintenance : re-entraînement lorsque les données sont mises à jour, lorsque le modèle de base est mis à jour, lorsque le cas d’utilisation change.

Total : 6 à 12 semaines de travail, de 1 000 € à 20 000 € de calcul selon l’échelle, puis une maintenance continue.

Investissement important. Assurez-vous qu’il en vaut la peine.

Quand le fine-tuning brille

Scénarios spécifiques où le fine-tuning est clairement avantageux :

Exigences de format strictes. Les sorties doivent suivre un schéma ou un style spécifique de manière cohérente. Le prompting peut vous amener à 95 % ; le fine-tuning vous amène à 99 %.

Domaines spécialisés. Terminologie médicale, formulation juridique, code dans un DSL interne. Le fine-tuning enseigne au modèle votre dialecte spécifique.

Personnalité et voix. Une voix cohérente sur des milliers d’interactions. Les prompts peuvent dériver ; le fine-tuning l’intègre au modèle.

Optimisation de la latence et du coût. Un modèle affiné de 7B paramètres peut exécuter votre tâche plus rapidement et à moindre coût qu’un modèle généraliste de 70B. À grande échelle, le gain devient important.

Sécurité comportementale. Fine-tuning le modèle pour refuser certaines choses ou ajouter des garde-fous spécifiques peut être plus robuste que les garde-fous basés sur les prompts.

Quand le fine-tuning échoue

Manières courantes où le fine-tuning déçoit :

Données insuffisantes. Le fine-tuning sur 100 exemples n’a généralement pas d’effet. Un LoRA très étroit peut parfois fonctionner avec quelques centaines d’exemples ; pour un comportement général fiable, prévoyez 1 000 + exemples de haute qualité.

Données de mauvaise qualité. Des données médiocres produisent des résultats médiocres. Des exemples incohérents ou faibles entraînent un modèle tout aussi incohérent et faible.

Oubli catastrophique. Un fine-tuning lourd sur des tâches étroites peut nuire aux capacités générales. Le modèle devient bon à votre tâche mais pire à tout le reste.

Connaissance obsolète. Le modèle fine-tuné est une capture instantanée. Des informations nouvelles nécessitent un re-entraînement. Pour les domaines dynamiques, c’est un coût permanent.

Améliorations du modèle de base qui dépassent le fine-tuning. Le modèle de base s’est amélioré suffisamment pour que le fine-tuning ne soit plus meilleur. Vous maintenez maintenant un fine-tuning d’un modèle de base obsolète.

Problèmes d’évaluation. Sans évaluations solides, vous ignorez si le fine-tuning a aidé, nui ou n’a eu aucun effet. De nombreux « fine-tunings réussis » ne produisent qu’un gain placebo.

Les schémas de combinaison

En production, les meilleurs systèmes combinent les trois.

Combinaison 1 : RAG piloté par des prompts (la plus courante)

La norme pour les applications à forte densité de connaissance.

• Des prompts soigneusement conçus encodent les instructions, le format et les contraintes.
• RAG fournit des informations actuelles, spécifiques.
• Aucun fine-tuning : un modèle de base solide suffit.

C’est le schéma de production le plus courant en 2026. Il fonctionne pour la plupart des cas d’utilisation.

Combinaison 2 : Modèle fine-tuné + RAG

Cette combinaison convient lorsqu’une spécialisation comportementale et des connaissances dynamiques sont toutes deux nécessaires.

• Fine-tuning pour la voix, le format, le domaine.
• RAG pour les informations actuelles.
• Les prompts assurent l’orchestration.

Exemple : un modèle affiné pour adopter la voix propre au service client d’une entreprise, associé à un RAG portant sur les politiques et documents à jour. Le fine-tuning garantit une voix cohérente ; le RAG apporte les connaissances évolutives.

Combinaison 3 : Fine-tunings spécialisés pour des tâches spécifiques

Des fine-tunings différents pour différentes parties d’un système.

• Fine-tuning de classification pour le routage.
• Fine-tuning de synthèse pour les résumés.
• Fine-tuning de génération pour les réponses client.
• Chacun plus petit, plus rapide, spécialisé.

Utilisé quand l’échelle et l’optimisation des coûts sont importantes. Chaque fine-tuning fait bien son travail étroit ; l’orchestration les appelle.

Combinaison 4 : Router fine-tuné + modèles généraux

Le routeur est affiné afin de classer les requêtes de manière fiable. Une fois classées, elles sont transmises à des modèles généralistes qui exécutent le travail principal.

Le fine-tuning est petit, rapide, étroit. Le travail coûteux est fait par des modèles généraux, maintenus à jour.

Cela combine l’économie (le fine-tuning est petit) avec la capacité (les modèles généraux pour le travail difficile).

Le cadre de décision

Un flux de décision pratique :

Question 1 : Le problème est-il résoluble avec le modèle actuel et un bon prompt ?

Si oui : rédigez le prompt. Itérez pendant une semaine. Déployez.

Si non, allez à la Question 2.

Question 2 : Le problème implique-t-il des connaissances que le modèle ne possède pas ?

Si oui : construisez un RAG. Consacrez-lui les mois nécessaires pour atteindre la qualité de production et associez-le à des prompts solides.

Si non, allez à la Question 3.

Question 3 : Le problème porte-t-il sur un format cohérent, un domaine étroit ou un comportement spécifique ?

Si oui, ET vous avez au moins plusieurs centaines (idéalement 1 000 +) d’exemples de haute qualité : fine-tuning. Combinez avec le prompting et éventuellement le RAG.

Si vous ne disposez pas de ces exemples, investissez dans leur collecte ou améliorez d’abord le prompting et le RAG.

Question 4 : Avez-vous fait le travail d’évaluation pour savoir quelles approches fonctionnent réellement ?

Cette question s’applique à chaque étape. Sans évaluations, vous devinez.

Exemples de production

Quelques combinaisons réelles :

Exemple 1 : Support client par IA

Configuration : une IA de support client d’une entreprise SaaS traite les demandes de niveau 1.

Composants :

• Prompts solides pour le ton, le format, les politiques d’escalade.
• RAG sur les documents actuels, les politiques, l’historique des tickets.
• Fine-tuning léger sur la voix spécifique de l’entreprise et les schémas d’escalade (1 500 exemples sélectionnés à partir des tickets passés).

Résultat : elle traite 65 % des tickets de manière autonome. Le fine-tuning garantit la cohérence de la voix, le RAG maintient l’exactitude et les prompts appliquent les politiques.

Exemple 2 : Revue de documents juridiques

Configuration : Un produit de technologie juridique examine les contrats pour les risques.

Composants :

• Prompts détaillés encodant ce qu’il faut chercher (catégories juridiques, rubrique de gravité).
• RAG sur la jurisprudence pertinente et les précédents.
• Aucun fine-tuning ; les modèles de raisonnement gèrent le travail lourd.

Résultat : le prompt et le RAG fonctionnent bien, car le modèle possède déjà des connaissances juridiques. Le fine-tuning n’apporterait qu’un gain marginal qui ne justifie pas l’investissement.

Exemple 3 : Complétion de code dans un DSL personnalisé

Configuration : Un outil de données spécialisé avec son propre DSL.

Composants :

• Prompts avec des exemples.
• Aucun RAG (le DSL est suffisamment petit pour être inclus dans le contexte).
• Fine-tuning LoRA sur 10 000 exemples du DSL.

Résultat : Le fine-tuning était essentiel. Sans lui, le modèle ne pouvait pas produire de DSL valide de manière fiable. Les prompts et le contexte seuls n’étaient pas suffisants.

Exemple 4 : Assistant interne de l’entreprise

Configuration : Un assistant général pour les employés de l’entreprise.

Composants :

• Prompts système solides (voix, comportement, refus).
• RAG sur le wiki de l’entreprise, Slack, documents.
• Aucun fine-tuning ; la « voix » de l’entreprise est capturée dans les prompts.

Résultat : Le RAG + prompts gèrent la plupart des cas d’utilisation. L’entreprise n’est pas assez excentrique pour nécessiter un fine-tuning pour la voix.

Erreurs que nous voyons

Quelques schémas de mauvaise allocation :

Erreur 1 : Se tourner vers le fine-tuning d’abord. Les équipes entendent « nous devrions fine-tuner notre propre modèle » et commencent là. 90 % du temps, le prompting + RAG serait plus rapide, moins cher et aussi bon.

Erreur 2 : Ignorer le RAG quand c’est la solution. Les équipes construisent des prompts élaborés pour « rappeler » au modèle des informations de l’entreprise qui devraient évidemment être récupérées au moment de la requête. Mieux vaut simplement récupérer.

Erreur 3 : fine-tuning sans évaluations. « Nous avons affiné le modèle et il est maintenant meilleur. » Pourtant, aucune métrique ne le prouve. Le fine-tuning n’a souvent aucun effet, voire dégrade les résultats. Sans évaluations, vous ne pouvez pas le savoir.

Erreur 4 : fine-tunings obsolètes. Un modèle affiné six mois plus tôt, lorsque GPT-4 était le meilleur, peut aujourd’hui être dépassé par un modèle de pointe non affiné. Les fine-tunings doivent être réévalués à mesure que les modèles de base évoluent.

Erreur 5 : Essayer de fine-tuner des faits. Les équipes essaient de fine-tuner le modèle pour « connaître notre entreprise ». Ne fonctionne pas bien — le modèle mémorise quelques faits, hallucine d’autres. Le RAG gère les faits ; le fine-tuning gère le comportement.

Erreur 6 : Ne pas itérer suffisamment sur les prompts. Deux jours d’itération sur les prompts sont un point de départ. Deux semaines vous donnent la vraie réponse.

Erreur 7 : surconcevoir le RAG alors que le prompting suffirait. Placer un document interne de 50 000 tokens directement dans le prompt peut être plus simple qu’un RAG, surtout pour un petit corpus.

Comparaison des coûts et efforts

Une comparaison approximative pour un projet de taille moyenne typique :

Le bon choix dépend du problème et des ressources disponibles. Pour la plupart des équipes, prompting et RAG offrent le meilleur compromis : un gain de capacité important sans supporter tout l’investissement du fine-tuning.

À retenir

Le prompting, le RAG et le fine-tuning résolvent des problèmes différents. Le choix correct nécessite un diagnostic honnête : s’agit-il d’un écart d’instruction, d’un écart de connaissance ou d’un écart de capacité ?

L’ordre honnête pour les essayer :

1. Prompting (1-2 semaines d’itération). Le moins cher, le plus rapide, souvent suffisant.
2. RAG si un écart de connaissance est clair. Investissement important mais borné.
3. Fine-tuning si un écart de capacité clair ne peut être comblé par le prompting + RAG. Le plus coûteux ; faites-le en dernier.
4. Combinaisons pour les systèmes de production matures.

Les équipes qui réussissent sont honnêtes sur l’écart qu’elles ont et disciplinées sur les évaluations. Sans évaluations, vous ne pouvez pas savoir quelle approche a aidé. Avec, le chemin est généralement clair.

La plupart des projets « nous devons fine-tuner notre propre modèle », à l’examen plus approfondi, devraient être « nous devons rédiger de meilleurs prompts et ajouter du RAG ». Réservez le fine-tuning aux cas qui en ont vraiment besoin.

Le résultat : de meilleurs systèmes, livrés plus rapidement et à moindre coût. C’est l’objectif même d’un déploiement d’IA en production.