Pour donner à une IA l'accès aux connaissances de votre entreprise, le RAG est le choix par défaut : il branche le modèle sur vos documents au moment de la question, sans le réentraîner. Le fine-tuning ne se justifie que dans trois situations précises, quand il faut un format ou un style stable, un volume d'exemples suffisant et une contrainte forte de latence ou de coût par requête. Le reste de l'article détaille ces critères, les coûts réels de chaque approche et la grille que JUWA applique avant de lancer un projet.
Deux mécanismes qui n'agissent pas au même endroit
Le RAG (Retrieval-Augmented Generation) laisse le modèle intact. À chaque question, un moteur de recherche interne sélectionne les passages pertinents dans votre base documentaire, les place dans le prompt, et le modèle rédige la réponse à partir de ces passages. L'architecture est décrite dans l'article fondateur de Lewis et al. (2020). Une réponse RAG peut citer ses sources, et une mise à jour de la base est prise en compte immédiatement.
Le fine-tuning modifie les paramètres du modèle en poursuivant son entraînement sur vos exemples. Les techniques dites à faible rang, comme LoRA, ne réentraînent qu'une petite fraction des poids et rendent l'opération abordable, mais le principe reste le même : ce que le modèle a appris est figé jusqu'au prochain entraînement, et il ne sait pas dire d'où vient une information.
Résumé de la vidéo (13 min, en anglais) : IBM Technology explique les trois façons d'adapter un modèle, prompt, RAG et fine-tuning, et dans quels cas chacune s'applique, avec une comparaison claire des coûts de mise à jour.
Ce que dit la recherche : sur les faits, le RAG gagne
La comparaison la plus citée est celle d'Ovadia et al., Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs (2023). Les auteurs évaluent les deux approches sur des tâches à forte composante factuelle, avec des connaissances déjà vues à l'entraînement et des connaissances entièrement nouvelles. Le RAG l'emporte dans les deux cas. Ils constatent aussi que les modèles apprennent mal des faits nouveaux par fine-tuning non supervisé, et qu'il faut leur présenter de nombreuses variantes d'un même fait pour qu'ils le retiennent.
La conséquence pratique est simple. Si votre besoin est « répondre correctement à partir de nos documents », le fine-tuning est le mauvais outil. Il ne remplace pas une base documentaire, il en dégrade la fraîcheur.
Les trois situations où le fine-tuning se justifie
Le fine-tuning sert à apprendre un comportement, pas une connaissance. Trois conditions doivent être réunies, et JUWA les vérifie une par une avant d'accepter un projet de ce type.
Un format ou un style stable. Extraction structurée toujours dans le même schéma, classification de tickets dans une taxonomie fixe, rédaction dans une charte très contrainte. Le comportement attendu ne change pas d'un mois à l'autre.
Un jeu d'exemples réel et suffisant. La documentation OpenAI indique qu'on observe déjà un effet avec quelques dizaines d'exemples bien construits, mais qu'il faut en général plusieurs centaines pour une amélioration nette. Ces exemples doivent être validés par un humain du métier. Un jeu généré automatiquement apprend au modèle à reproduire les erreurs du générateur.
Une contrainte de latence ou de coût par requête. Un petit modèle spécialisé répond plus vite et moins cher qu'un grand modèle alimenté par un long prompt. Sur des volumes de plusieurs centaines de milliers de requêtes par mois, l'économie devient réelle ; l'article sur les small language models en PME chiffre ces ordres de grandeur.
Si une seule des trois conditions manque, le RAG, éventuellement avec un prompt système soigné, fait le travail pour une fraction du coût.
Ce que coûte réellement chaque approche en 2026
Le coût d'un RAG se concentre sur la préparation. Il faut nettoyer le fonds documentaire, retirer les versions périmées, découper les documents en passages cohérents, puis calculer les vecteurs et les stocker. L'exploitation coûte ensuite le prix des appels au modèle, gonflés par les passages injectés dans chaque prompt. Ce dernier poste se pilote : l'article sur l'optimisation du coût des LLM détaille les leviers.
Le coût d'un fine-tuning se répartit autrement : constitution et validation du jeu d'exemples (le poste le plus lourd), entraînement facturé au volume de tokens chez les fournisseurs comme Mistral ou OpenAI, puis hébergement du modèle spécialisé, souvent facturé même sans trafic, et réentraînement à chaque évolution du besoin.
Deux références issues de missions JUWA fixent les ordres de grandeur côté RAG. Pour une PME industrielle, 2 000 documents techniques ont été indexés dans un assistant hébergé en France, et le temps de recherche du SAV a baissé de 55 %. Pour un éditeur SaaS, un copilote RAG livré en quatre semaines traite 95 % de deux millions de messages mensuels sans intervention humaine, avec une latence sous trois secondes. Aucun des deux projets n'a nécessité de fine-tuning : la qualité venait de la préparation des documents et des garde-fous, pas d'un modèle modifié.
La matrice de décision
| Critère | RAG | Fine-tuning | Hybride |
|---|---|---|---|
| Besoin principal | Répondre à partir de documents qui changent | Reproduire un format, un style, une classification | Style stable et documents changeants |
| Fraîcheur de l'information | Immédiate, à la mise à jour de la base | Figée jusqu'au réentraînement | Immédiate pour les faits |
| Traçabilité des réponses | Sources citées | Aucune | Sources citées |
| Données nécessaires | Documents propres et à jour | Plusieurs centaines d'exemples validés | Les deux |
| Délai d'un premier déploiement | 2 à 6 semaines | 4 à 12 semaines, dominées par la constitution du jeu | 8 à 16 semaines |
| Coût récurrent | Appels au modèle, base vectorielle | Hébergement du modèle, réentraînements | Les deux |
| Risque principal | Base documentaire de mauvaise qualité | Surapprentissage, jeu d'exemples biaisé | Complexité d'exploitation |
L'hybride n'est pas un compromis par défaut. On le retient quand un fine-tuning léger stabilise le format de sortie (par exemple une extraction en JSON strict) et que le RAG fournit les faits à extraire. Dans tous les cas, la qualité se mesure avant et après : les métriques d'évaluation d'un RAG s'appliquent aussi à un modèle spécialisé, et un projet sans jeu de test n'a aucun moyen de prouver qu'il a amélioré quoi que ce soit.
Le point de vigilance sur les données personnelles
Un fine-tuning ancre les données d'entraînement dans le modèle. Si ces données contiennent des informations personnelles, elles deviennent difficiles à retirer, ce qui pose un problème direct au regard du droit à l'effacement. La CNIL traite ce point dans ses fiches pratiques sur le développement des systèmes d'IA. Un RAG, lui, garde les données dans une base classique dont on peut supprimer une ligne. C'est un argument supplémentaire pour commencer par le RAG dès que des données clients sont en jeu.
La grille que JUWA applique avant de choisir
Le premier livrable est un jeu de test : cinquante à deux cents questions réelles avec la réponse attendue, écrites avec les équipes métier. Ensuite vient un RAG sur le fonds documentaire nettoyé, mesuré sur ce jeu de test. Le fine-tuning n'est proposé que si les trois conditions ci-dessus sont réunies et si le RAG, mesuré, plafonne sur un critère de format ou de coût. Quand c'est le cas, JUWA construit le jeu d'exemples avec le client, entraîne un modèle de taille adaptée et le met en production avec un plan de réentraînement ; le détail de cette prestation est décrit sur la page fine-tuning de modèles IA sur mesure. Sur la majorité des premiers projets, la réponse honnête reste un RAG bien préparé, et l'article sur la préparation d'une base documentaire pour un RAG explique par où commencer.
