Fine-tuning vs RAG : quand entraîner son propre modèle

Lorsqu'une entreprise décide qu'un modèle de langage générique ne suffit plus, la question inévitable se pose : entraînons-nous notre propre modèle ou connectons-nous le modèle à nos documents ? La réponse est cruciale, car une erreur d'architecture au départ se paie en mois de retravail et en dizaines de milliers d'euros. Dans cet article, nous expliquons avec précision technique et jugement métier quand appliquer le fine-tuning, quand appliquer le RAG (Retrieval-Augmented Generation) et quand il est judicieux de combiner les deux approches.

Qu'est-ce que le fine-tuning et quel problème résout-il ?

Le fine-tuning (ajustement fin) consiste à poursuivre l'entraînement d'un modèle de langage pré-entraîné à partir d'exemples propres à l'entreprise. L'objectif n'est pas de lui enseigner de nouvelles connaissances — c'est le rôle du RAG —, mais de reformater le comportement et le style : amener le modèle à adopter un ton corporatif spécifique, à produire systématiquement une structure de sortie donnée (JSON, XML, formulaire) ou à maîtriser un jargon très spécialisé qui n'apparaît que marginalement dans les données de pré-entraînement.

Techniquement, le fine-tuning met à jour les poids du modèle par rétropropagation sur un ensemble de paires (instruction, réponse idéale) fourni par l'entreprise. Depuis 2023, des variantes efficaces telles que LoRA (Low-Rank Adaptation) et QLoRA se sont popularisées ; elles réduisent drastiquement la mémoire GPU nécessaire en gelant la plupart des paramètres et en n'entraînant que des matrices de faible rang. Cela a démocratisé le fine-tuning : des entreprises sans cluster propre peuvent ajuster des modèles de 7 ou 13 milliards de paramètres sur un GPU de 24 Go en quelques heures.

Ce que le fine-tuning ne résout pas bien, c'est la mise à jour continue de l'information. Une fois le modèle ajusté, ses «connaissances» restent figées jusqu'au prochain cycle de réentraînement. Si une donnée change — un tarif, une réglementation, un catalogue produit — le modèle continuera à répondre avec l'ancienne information.

Qu'est-ce que le RAG et à quoi sert-il ?

Le RAG — acronyme de Retrieval-Augmented Generation — est une architecture dans laquelle le modèle de langage n'agit pas seul : avant de générer la réponse, un composant de récupération interroge une base de connaissances externe (documents, bases de données, API) et transmet le contexte pertinent au modèle sous forme de prompt. Le modèle raisonne sur ce contexte et produit la réponse.

L'avantage décisif du RAG est la fraîcheur de la donnée. La base de connaissances peut être mise à jour en temps réel — ou plusieurs fois par jour — sans toucher au modèle. De plus, la récupération est auditable : on peut voir exactement quel fragment de quel document a soutenu chaque réponse, ce qui simplifie la conformité réglementaire dans les environnements régulés (assurance, banque, santé).

Le RAG n'est pas non plus une solution universelle. Si le modèle de base ne «parle» pas bien la langue ou le jargon du domaine, les fragments récupérés seront corrects mais les réponses pourraient rester maladroites. Et si le corpus de documents est très volumineux et mal structuré, la qualité de la récupération chute, entraînant avec elle celle de l'ensemble du système. L'ingénierie de l'index et la stratégie de chunking constituent, en pratique, la moitié du travail d'un projet RAG bien conduit.

Comparaison directe : fine-tuning vs RAG

Quand choisir le fine-tuning ?

Le fine-tuning est le bon choix lorsque le problème n'est pas de connaissance mais de comportement. Trois signaux qui y pointent :

• Le format de sortie est critique et rigide. Si le système doit toujours produire un JSON avec des champs spécifiques ou remplir un modèle de rapport à structure exacte, le fine-tuning est beaucoup plus fiable que de se fier à un prompt pour induire ce format. Les modèles ajustés pour la classification ou l'extraction sont plus rapides et moins coûteux en production que les modèles généraux avec des prompts longs.
• Le ton corporatif ou le jargon est très spécifique. Un modèle de service client pour une banque privée, par exemple, requiert un niveau de formalisme et une terminologie qu'un modèle générique ne reproduit pas de manière cohérente.
• Les données du domaine sont relativement stables. Si les procédures ou les critères de décision de l'entreprise changent moins d'une fois par trimestre, le coût du réentraînement est supportable.

Chez Summum IA, lorsque nous accompagnons des projets de fine-tuning sur mesure, nous commençons toujours par établir la ligne de base avec le modèle de base non ajusté : si celui-ci atteint déjà 80 % de l'objectif avec un bon prompt, le coût de l'ajustement fin est rarement justifié.

Quand choisir le RAG ?

Le RAG est l'architecture de départ pour la majorité des cas d'usage en entreprise, car il combine flexibilité et rapidité de déploiement. Choisissez le RAG lorsque :

• Les connaissances changent fréquemment. Documentation produit, réglementations, prix, procédures internes : tout ce qui est mis à jour plus d'une fois par mois s'intègre bien mieux dans une base de connaissances indexée que dans les poids d'un modèle.
• La traçabilité de la source est une exigence. Dans les secteurs réglementés — assurance, banque, pharmacie — pouvoir montrer qu'une réponse provient de la section 4.2 du manuel de procédures est parfois une obligation légale, pas seulement une bonne pratique.
• Vous ne disposez pas de données d'entraînement étiquetées, seulement de documents. Étiqueter des centaines de paires (question, réponse idéale) est coûteux. Si vous avez des documents mais pas d'exemples étiquetés, le RAG est la voie naturelle.
• Le corpus est vaste et hétérogène. Des milliers de PDF, de contrats, de manuels techniques, d'e-mails historiques : le RAG transforme cette masse documentaire en base de consultation sans traitement manuel.

Notre service d'implémentation RAG en entreprise couvre la conception de l'index, la stratégie de chunking, le choix du modèle d'embeddings et l'évaluation de la récupération avant la mise en production du système.

La combinaison : fine-tuning + RAG

Dans les cas les plus exigeants, la réponse n'est pas l'une ou l'autre technique, mais les deux en couches. Le schéma le plus courant est un modèle ajusté agissant comme lecteur : le modèle est affiné pour lire et interpréter correctement les fragments récupérés du corpus de l'entreprise (terminologie, structure des documents), et ces fragments arrivent ensuite via RAG avec les informations à jour.

Cette approche combinée est utilisée, par exemple, par des assistants spécialisés en droit fiscal ou en médecine, où le modèle doit à la fois maîtriser le langage technique du domaine (fine-tuning) et accéder à la jurisprudence ou aux recommandations cliniques actualisées (RAG). Le coût de développement est plus élevé, mais la qualité des réponses justifie l'investissement lorsque le risque d'erreur a des conséquences réelles pour l'entreprise.

Ce qu'il faut évaluer avant de décider

Avant de s'engager dans une architecture, il convient de répondre honnêtement à ces quatre questions :

1. À quelle fréquence les connaissances pertinentes changent-elles ? Si la réponse est «chaque semaine ou plus», le RAG l'emporte pour sa commodité opérationnelle.
2. Disposez-vous de données étiquetées ou seulement de documents ? Sans exemples (instruction → réponse idéale), le fine-tuning est difficile à réaliser correctement.
3. Le modèle de base atteint-il déjà 80 % de l'objectif avec un prompt bien conçu ? Si oui, ni fine-tuning ni RAG : optimisez d'abord le prompt.
4. Le cas d'usage nécessite-t-il d'auditer la source de chaque réponse ? Dans ce cas, le RAG est pratiquement obligatoire.

Coûts réels en 2025-2026

Le marché a beaucoup évolué au cours des deux dernières années. À titre indicatif, sur la base des données publiques des fournisseurs cloud à fin 2025 :

• Fine-tuning d'un modèle de 7 milliards de paramètres avec LoRA sur GPU A100 : entre 50 et 150 euros par cycle d'entraînement complet (quelques milliers d'exemples). L'évaluation rigoureuse et l'ingénierie des données coûtent généralement plus que le calcul.
• Fine-tuning via l'API d'un fournisseur (OpenAI, Google Vertex, Azure) : entre 0,008 et 0,030 dollar pour 1 000 tokens d'entraînement, selon le modèle de base. Un jeu de données de 10 000 exemples de 500 tokens peut coûter entre 40 et 150 dollars en calcul seul.
• RAG avec un modèle en cloud : le coût dominant est l'inférence et le stockage de l'index vectoriel. Pour des volumes moyens (1 à 5 millions de fragments), les coûts d'indexation sont inférieurs à 100 euros ; le coût opérationnel récurrent dépend du volume de requêtes.
• Modèles souverains sur infrastructure propre : si les données ne peuvent pas quitter l'entreprise, l'analyse coût-bénéfice change radicalement. Pour ces cas, l'équipe d'IA souveraine de Summum évalue les options de déploiement sur matériel propre ou en cloud privé certifié.

Implications du règlement européen sur l'IA (AI Act)

Le Règlement (UE) 2024/1689 (AI Act), en application progressive depuis août 2024, affecte directement les décisions d'architecture. Les systèmes d'IA à haut risque — y compris certains classifieurs et assistants d'aide à la décision — sont soumis à des exigences de traçabilité, d'explicabilité et de gestion des données d'entraînement qui conditionnent le fine-tuning. En particulier :

• Les données utilisées pour ajuster un modèle à haut risque doivent être documentées conformément à l'Article 10 du Règlement (gouvernance des données, qualité, représentativité).
• Si le système prend des décisions affectant des personnes (crédit, emploi, santé), la capacité à expliquer chaque réponse — facilitée par le RAG avec des sources visibles — simplifie le respect de l'exigence de transparence de l'Article 13.

Pour les entreprises qui travaillent déjà avec la norme ISO 42001 (Système de management de l'intelligence artificielle), le choix d'architecture doit être documenté dans le registre des risques du système et approuvé par le rôle de «responsable de l'IA» défini dans la norme.

Questions fréquentes

Peut-on faire du fine-tuning sans savoir programmer ?

Cela dépend du fournisseur. Des plateformes comme OpenAI ou Azure proposent des interfaces graphiques pour téléverser des données et lancer des cycles de fine-tuning sans écrire de code. Cependant, la phase critique — préparer et étiqueter correctement les données d'entraînement — exige toujours un jugement expert sur ce que sont de «bonnes» réponses pour le domaine concerné. L'interface est simple ; la conception du jeu d'entraînement ne l'est pas.

Combien d'exemples faut-il pour faire du fine-tuning ?

La règle générale est qu'avec 200 à 500 exemples bien étiquetés, on observe déjà une amélioration du comportement pour les tâches de classification ou d'extraction. Pour les tâches génératives (réponses longues, rédaction dans un ton spécifique), il faut généralement entre 1 000 et 5 000 exemples pour obtenir des résultats robustes. La qualité des exemples compte plus que la quantité : 300 paires parfaites surpassent 3 000 paires médiocres.

Le RAG fonctionne-t-il avec des documents en français ?

Oui, sans problème, mais le choix du modèle d'embeddings est clé. Les modèles multilingues comme multilingual-e5-large ou les modèles spécialisés offrent une meilleure récupération que les modèles entraînés uniquement en anglais. Chez Summum IA, nous évaluons systématiquement à titre comparatif au moins deux modèles d'embeddings avant de fixer l'architecture de production.

Le fine-tuning protège-t-il mes données ? Sont-elles utilisées pour entraîner des modèles tiers ?

Cela dépend du contrat avec le fournisseur. Les principaux fournisseurs cloud (Microsoft Azure, Google Vertex, AWS Bedrock) garantissent dans leurs accords d'entreprise que les données de fine-tuning ne sont pas utilisées pour améliorer leurs modèles de base. Il est indispensable de lire et de négocier le contrat avant de téléverser des données sensibles, et dans les secteurs réglementés (santé, banque) il est conseillé d'opter pour des modèles déployés sur infrastructure privée. Si vos données ne peuvent pas quitter votre périmètre, l'option d'IA souveraine résout le problème à la racine.