Points clés
- La séquence canonique en 2026 est prompt → RAG → fine-tuning → distillation. On ne passe à l'échelon suivant que lorsque le précédent est réellement épuisé, pas lorsqu'il lasse.
- Le RAG est le bon choix pour environ 80 % des applications LLM en entreprise : il permet de changer la donnée sans réentraîner, d'attribuer la réponse à un document et de changer de modèle de base librement.
- La règle qui tranche 90 % des débats : si le modèle ne sait pas quelque chose, c'est un problème de RAG. S'il le sait mais le dit mal (ton, format, structure), c'est un problème de fine-tuning.
- Le fine-tuning complet n'est presque jamais la bonne décision pour une équipe produit. LoRA et QLoRA entraînent un petit adaptateur : peu coûteux, rapide et réversible.
Context engineering, RAG et fine-tuning sont trois manières distinctes d'adapter un LLM à votre entreprise. Le context engineering façonne ce qui entre dans le prompt ; le RAG (génération augmentée par récupération) injecte votre connaissance au moment de la requête ; le fine-tuning modifie les poids du modèle. La décision se résume à une question : si le problème est la connaissance, c'est le RAG ; si c'est le comportement, c'est le fine-tuning.
Les trois techniques, définies sans ambiguïté
Context engineering (ingénierie du contexte). C'est la conception délibérée de tout ce qui entre dans la fenêtre de contexte : prompt système, exemples few-shot, échafaudage de raisonnement, schémas de sortie contraints (JSON schema), ordre et compression de l'information. Cela ne touche ni le modèle ni les données ; cela change ce que le modèle voit. En 2026, c'est bien plus puissant qu'on ne le suppose, et c'est la couche qui fait réellement fonctionner le RAG et le fine-tuning.
RAG (Retrieval-Augmented Generation). Face à une question, le système récupère d'abord les fragments pertinents de vos documents ou bases de données et les fournit au modèle comme contexte. Le modèle répond à partir de vos données réelles, avec la possibilité de citer la source. La connaissance vit dans votre infrastructure, pas dans le modèle.
Fine-tuning (ajustement fin). On modifie les poids du modèle en l'entraînant sur vos propres exemples d'entrée et de sortie souhaitée. Le modèle apprend un comportement : un ton, un format, une taxonomie, un style de raisonnement. Il n'apprend pas de faits actualisables de façon fiable.
Ce que le fine-tuning N'EST PAS : ce n'est pas « injecter vos documents dans le modèle ». C'est le malentendu le plus coûteux que nous rencontrons. Entraîner un modèle sur votre manuel de procédures ne garantit pas qu'il le récitera correctement, et garantit qu'il sera obsolète dès que le manuel changera.
Une analogie utile : le context engineering, c'est bien expliquer la tâche à un professionnel. Le RAG, c'est lui donner accès à la bibliothèque et aux dossiers. Le fine-tuning, c'est l'envoyer en formation spécialisée pour qu'il travaille autrement. Personne n'envoie quelqu'un en master pour lui faire apprendre par cœur l'annuaire de l'entreprise.
Le comparatif qui tranche la décision
| Critère | Context engineering | RAG | Fine-tuning (LoRA) |
|---|---|---|---|
| Résout | Format, instructions, raisonnement | Connaissance à jour et attribuable | Ton, style, structure constante |
| Mettre à jour l'information | Réécrire le prompt | Mettre à jour les documents (immédiat) | Exige un réentraînement |
| Citer la source | Non | Oui, nativement | Non |
| Changer de modèle de base | Trivial | Trivial | L'adaptateur doit être réentraîné |
| Délai jusqu'au premier résultat | Heures | 2 à 6 semaines | 4 à 10 semaines (données incluses) |
| Besoin de données annotées | Non | Non | Oui, et c'est le goulot d'étranglement |
| Risque principal | Prompt fragile et ingérable | Récupération médiocre | Surapprentissage et obsolescence |
| Réversible | Oui | Oui | Oui avec LoRA, non en FT complet |
Le tableau se lit de gauche à droite : chaque colonne coûte nettement plus que la précédente et résout un problème différent, pas un problème « plus gros ». Sauter au fine-tuning parce que le RAG a déçu signifie généralement que le RAG était mal construit, pas qu'un entraînement était nécessaire.
L'arbre de décision que nous utilisons
Quatre questions, dans cet ordre :
- Le modèle dispose-t-il de l'information nécessaire ? Sinon → RAG. Aucune quantité de fine-tuning ne rend un modèle fiable sur les commandes de votre ERP cette semaine.
- L'information évolue-t-elle dans le temps ? Si oui → RAG, sans discussion. Un modèle ajusté sur des données de mars croit toujours qu'on est en mars.
- Faut-il citer la source de la réponse ? Si oui → RAG. L'attribution est une propriété architecturale de la récupération, pas quelque chose qui s'entraîne.
- Le modèle a l'information mais la présente mal, systématiquement ? S'il s'agit du ton, du format, de la longueur, de la structure ou d'une taxonomie maison à plusieurs centaines de catégories → là, oui, fine-tuning avec LoRA.
Et une question préalable aux quatre : avez-vous épuisé le context engineering ? D'après notre expérience, entre un tiers et la moitié des projets qui arrivent en demandant « un modèle entraîné sur nos données » se règlent avec un prompt système bien construit, des exemples few-shot représentatifs et une sortie contrainte par schéma. C'est l'intervention la moins chère, et celle que presque personne n'épuise avant de monter d'un cran.
Données clés du marché
- La séquence canonique consolidée en 2026 est prompt → RAG → fine-tune → distiller, et le RAG est le bon premier choix pour environ 80 % des applications LLM d'entreprise, car il permet de changer la donnée sans réentraîner, d'attribuer les réponses et de changer librement de modèle de base (Winder.ai, cadre de décision 2026).
- Le fine-tuning complet n'est presque jamais la bonne décision pour une équipe produit en 2026. LoRA et QLoRA entraînent un adaptateur minuscule plutôt que le modèle entier : peu coûteux, rapide, réversible.
- 46 % des organisations citent l'intégration aux systèmes existants comme principal défi, devant le choix du modèle ou de la technique. Le goulot d'étranglement est rarement là où se situe le débat.
Notre avis, sans détour : la plupart des conversations sur le fine-tuning en entreprise sont des conversations sur le RAG mal posées. Et une part importante des projets RAG qui « ne fonctionnent pas » souffrent d'un problème de qualité de récupération, pas de modèle.
Le schéma hybride qui gagne en production
Le débat « RAG ou fine-tuning » est faux dans les systèmes matures. Le schéma le plus efficace combine les trois couches :
- Fine-tuning léger (LoRA) sur un petit modèle pour fixer le format de sortie, le ton corporate ou une taxonomie maison. Le modèle apprend comment répondre.
- RAG par-dessus pour qu'il réponde avec les données actuelles de l'entreprise. Le modèle obtient quoi répondre.
- Context engineering pour orchestrer les deux : ce qui est récupéré, dans quel ordre, avec quelles instructions et quel schéma de sortie.
Le résultat est un modèle plus petit et moins coûteux qu'un grand généraliste, avec la constance de format d'un modèle ajusté et la fraîcheur de données du RAG. C'est aussi la voie naturelle vers des modèles déployés on-premise lorsque des exigences de souveraineté s'appliquent.
Cas d'usage courants
Cas 1 : Classification avec une taxonomie maison de 300 catégories.
- Problème : classer les tickets entrants selon une taxonomie interne qu'aucun modèle généraliste ne connaît. Le prompt contenant la liste complète était énorme, lent et peu fiable.
- Solution : fine-tuning LoRA sur un petit modèle à partir de l'historique de tickets déjà classés.
- Stack : modèle open-weight + LoRA + jeu de données historique.
- Résultat : classification constante, prompts courts et latence bien inférieure. Le cas d'école où le fine-tuning gagne.
Cas 2 : Assistant sur une documentation technique qui change chaque mois.
- Problème : fournir des réponses correctes sur des manuels et procédures mis à jour en continu.
- Solution : RAG avec base vectorielle, métadonnées de version et citation obligatoire de la source.
- Stack : base vectorielle + reranking + modèle généraliste + schéma de sortie avec citations.
- Résultat : la réponse se met à jour quand le document se met à jour, sans toucher au modèle. Avec du fine-tuning, il faudrait réentraîner chaque mois.
Cas 3 : Rédaction de rapports au format corporate strict.
- Problème : le modèle dispose de l'information (issue du RAG) mais le format de sortie varie d'une exécution à l'autre.
- Solution : d'abord schéma de sortie contraint et exemples few-shot. Ce n'est qu'une fois cette voie épuisée qu'un LoRA a été entraîné sur 400 rapports réels.
- Stack : RAG + sortie structurée + LoRA de style.
- Résultat : 80 % du problème de format résolu par le context engineering ; le fine-tuning a réglé le reste.
Comment décider, étape par étape
- Écrivez le critère de succès avant de choisir la technique. « Qu'il réponde bien » n'est pas un critère. « Qu'il trouve la bonne catégorie sur 92 % des tickets du dernier trimestre » en est un.
- Constituez un jeu d'évaluation de 30 à 50 cas réels. Sans lui, impossible de comparer les techniques : on ne peut qu'avoir des préférences.
- Épuisez le context engineering. Prompt système explicite, 3 à 8 exemples few-shot représentatifs, sortie contrainte par schéma JSON. Mesurez contre le jeu de cas.
- Si le problème est la connaissance, montez le RAG et mesurez la récupération séparément. Context recall et context precision avant de regarder la qualité de la réponse finale. Si la récupération échoue, aucun modèle ne vous sauvera.
- Seulement si un problème de comportement persiste, envisagez LoRA. Il faudra de plusieurs centaines à quelques milliers d'exemples de qualité. Rassembler ces données représente 70 % de l'effort réel du projet.
- Évaluez l'hybride. Un petit modèle ajusté + RAG bat généralement un grand généraliste en coût et latence, à qualité équivalente.
- Documentez la décision et son critère de retour arrière. Ce qui devrait se produire pour revenir en arrière. Les projets d'IA qui sautent cette étape traînent des architectures que plus personne ne défend.
Erreurs fréquentes (et comment les éviter)
Erreur : faire du fine-tuning pour « injecter nos documents dans le modèle ». → La réalité : le fine-tuning enseigne un comportement, pas des faits consultables. Pour la connaissance : RAG. Ce malentendu explique la majorité des projets d'IA ratés que nous auditons.
Erreur : sauter au fine-tuning parce que le RAG « ne marche pas ». → La réalité : dans la quasi-totalité des cas, le RAG échoue à la récupération : découpage mal dimensionné, absence de reranking, métadonnées pauvres. Mesurez la récupération avant d'accuser le modèle.
Erreur : fine-tuning complet plutôt que LoRA. → La réalité : entraîner tous les poids est lent, coûteux, irréversible et vous lie à cette version du modèle. LoRA entraîne un petit adaptateur, se change en minutes et se jette sans conséquence.
Erreur : partir de la technique plutôt que de la métrique. → La réalité : sans critère de succès mesurable, tout résultat paraît bon en démonstration et mauvais en production.
Erreur : sous-estimer le jeu de données du fine-tuning. → La réalité : le modèle n'est pas le problème ; obtenir des exemples propres, cohérents et représentatifs l'est. Un jeu de données aux critères contradictoires apprend au modèle à être incohérent.
Erreur : ajuster un modèle et ne plus jamais y toucher. → La réalité : un adaptateur entraîné il y a un an sur des données vieilles de deux ans encode une version périmée de votre activité. Il faut le revoir périodiquement, comme tout actif.
Délais et effort réalistes
- Context engineering sérieux (prompt, exemples, schéma de sortie, mesure) : des jours, pas des semaines. Meilleur rapport résultat/effort des trois.
- RAG en production : 2 à 6 semaines selon la qualité et l'état de votre documentation. Si les documents sont désordonnés ou dupliqués, c'est là que part le délai, pas dans la partie technique.
- Fine-tuning avec LoRA : 4 à 10 semaines, dont l'entraînement lui-même ne prend que des heures. Le reste consiste à construire et nettoyer le jeu de données.
- Où se situe l'effort réel : dans les données, toujours. Pour le RAG, la qualité documentaire. Pour le fine-tuning, la qualité du jeu annoté. Le modèle est la partie facile.
Indicateurs à suivre dès le jour 1 : précision sur le jeu d'évaluation, context recall et context precision si RAG, constance du format, latence p95 et coût par tâche. Plus une comparaison honnête à la ligne de base : ce qu'obtient un prompt bien construit sans rien d'autre. Si personne ne dispose de ce chiffre, aucun investissement supplémentaire n'est justifiable.
Questions fréquentes
Quand faut-il faire du fine-tuning plutôt que du RAG ?
Quand le modèle dispose déjà de l'information mais la présente mal de manière systématique : ton inadapté, format incohérent, ou taxonomie maison à nombreuses catégories qui ne tient pas confortablement dans le prompt. Si le modèle ignore quelque chose ou si cette chose évolue, la réponse est le RAG.
Puis-je faire du fine-tuning pour que le modèle connaisse les données de mon entreprise ?
Pas de façon fiable. Le fine-tuning enseigne un comportement, pas des faits consultables et actualisables. Un modèle ajusté sur les données d'un mois donné devient obsolète et ne permet pas de citer la source. Pour la connaissance métier, la bonne technique est le RAG.
Qu'est-ce que LoRA et pourquoi l'utiliser plutôt qu'un fine-tuning complet ?
LoRA (Low-Rank Adaptation) entraîne un petit adaptateur au lieu de modifier tous les poids du modèle. C'est bien plus rapide et économique, réversible, et cela permet de conserver plusieurs adaptateurs spécialisés sur le même modèle de base.
Qu'est-ce que le context engineering exactement ?
C'est la conception délibérée de tout ce qui entre dans la fenêtre de contexte : prompt système, exemples few-shot, échafaudage de raisonnement, schémas de sortie et ordre de l'information. C'est la couche la moins coûteuse des trois et celle qui résout entièrement le plus de projets.
Peut-on combiner RAG et fine-tuning ?
Oui, et c'est le schéma gagnant en production : un petit modèle ajusté avec LoRA pour fixer format et ton, enveloppé de RAG pour répondre avec des données actuelles. Moins cher et plus rapide qu'un grand modèle généraliste, à qualité équivalente.
Combien d'exemples faut-il pour un fine-tuning utile ?
De plusieurs centaines à quelques milliers d'exemples propres et cohérents, selon la complexité de la tâche. La quantité importe moins que la cohérence : un jeu aux critères contradictoires apprend au modèle à être incohérent.
Le fine-tuning réduit-il les hallucinations ?
Pas de manière fiable, et parfois il les aggrave : un modèle ajusté répond avec plus d'assurance dans son domaine d'entraînement, même sans disposer du fait. Les hallucinations factuelles se réduisent avec le RAG et la citation de sources, pas avec l'entraînement.
Que choisir avec des exigences RGPD ou de souveraineté des données ?
Le RAG avec un modèle déployé en cloud privé ou auto-hébergé est généralement la voie la plus propre : la donnée personnelle est récupérée au moment de la requête et n'entre jamais dans un processus d'entraînement. Avec un fine-tuning sur données personnelles, celles-ci sont incorporées aux poids.
Vous ne savez pas si votre cas relève du RAG, du fine-tuning ou simplement d'un bon prompt ?
Chez Naxia, nous partons de la métrique, pas de la technique : nous définissons le critère de succès, construisons le jeu d'évaluation et mesurons ce qu'apporte chaque couche avant d'investir dans la suivante. Dans bien des projets, la bonne réponse se révèle être la moins coûteuse.
Si vous voulez une recommandation honnête sur votre cas précis, y compris la possibilité de n'avoir rien à entraîner, parlons-en. Sans engagement et sans PowerPoint de 40 pages.
Ou explorez d'abord notre processus d'implémentation.