« On va fine-tuner le modèle. » La phrase tombe dans presque toutes les réunions produit dès qu’un assistant répond de travers. Elle est, le plus souvent, la mauvaise réponse.
Non que la technique soit dépassée : le fine-tuning d’un LLM (réentraînement d’un modèle existant sur vos propres exemples) n’a jamais été aussi accessible. Mais une hiérarchie de décision s’est imposée dans l’industrie : prompt d’abord, RAG ensuite, fine-tuning seulement après, distillation en bout de chaîne. La plupart des équipes qui lancent un entraînement auraient obtenu le même résultat deux étages plus bas, en une journée au lieu d’un trimestre.
Reste que ces trois étages ne font pas le même métier. Encore faut-il savoir lequel vous manque.
modifier les poids, ou remplir le contexte
Un LLM, c’est une immense matrice de poids figée après l’entraînement. Le prompt ne touche pas ces poids : il occupe la fenêtre de contexte, c’est-à-dire la mémoire de travail du modèle au moment où vous lui parlez. Le RAG (Retrieval-Augmented Generation) ne les touche pas davantage : il va chercher des documents dans une base et les glisse dans ce même contexte avant la génération.
Le fine-tuning, lui, modifie les poids. C’est une différence de nature, pas de degré. Vous ne dites plus au modèle quoi faire, vous déformez la pente de ses probabilités pour qu’il le fasse par défaut, sans qu’on le lui demande.
D’où le partage qui tranche l’essentiel des débats : le contexte sert à injecter du savoir, l’entraînement à installer une forme. Un modèle fine-tuné sur vos comptes rendus de réunion apprendra votre manière de les écrire. Il n’apprendra pas de façon fiable ce qui s’est dit à la réunion de mardi dernier. Les faits mouvants passent par la récupération de documents, pas par les poids : c’est la seule voie qui se met à jour sans réentraîner et qui laisse citer la source.
Confondre les deux est l’erreur fondatrice. Entraîner un modèle sur votre documentation interne pour qu’il « connaisse » vos produits donne un système qui récite avec aplomb une version périmée, sans la moindre traçabilité. Le RAG, lui, répond avec le document d’aujourd’hui et vous montre lequel.
les trois cas où le fine-tuning d’un LLM gagne
Une fois ce partage posé, les situations où l’entraînement bat réellement le prompt et le RAG se comptent sur les doigts d’une main. Trois familles, en pratique.
Le style et la voix. Vous voulez qu’un modèle écrive systématiquement dans un registre précis, avec un vocabulaire maison, des tournures, des interdits. C’est faisable au prompt, mais le prompt dérive : plus la conversation s’allonge, plus les consignes de forme se diluent dans le contexte. Quelques centaines d’exemples bien choisis règlent le problème définitivement, et libèrent au passage des milliers de tokens d’instructions à chaque appel.
Le format de sortie strict. Un schéma JSON complexe, une grammaire métier, une séquence d’appels d’outils qui doit tomber juste à chaque fois. Sur ce terrain, l’entraînement ne rend pas le modèle plus intelligent : il rend son comportement prévisible. C’est exactement ce que vous cherchez quand la sortie alimente un système en aval qui n’a pas le droit de casser. À nuancer tout de même : les modes de sortie structurée proposés nativement par les fournisseurs couvrent déjà beaucoup de cas, essayez-les avant.
Le comportement et la spécialisation de domaine. Politique de refus fine, arbitrages métier qu’aucune consigne écrite ne capture bien, jargon très éloigné du langage courant : radiologie, contentieux, code d’un langage propriétaire. Ici le modèle de base a un a priori qui joue contre vous, et aucun prompt ne le corrige durablement.
Un quatrième cas mérite d’être cité même s’il ne relève pas de la qualité : la compression. Fine-tuner un petit modèle sur les sorties d’un grand, c’est de la distillation. On ne cherche plus à faire mieux, mais aussi bien pour dix fois moins cher, ou sur une machine qui ne sort pas de vos murs. C’est un projet d’économie et de souveraineté, pas un projet de performance.
Le point commun des trois familles saute aux yeux : aucune ne concerne une information. Si votre problème s’énonce par « le modèle ne sait pas que… », vous n’avez pas un problème d’entraînement.
LoRA, QLoRA, full fine-tuning : ce qui les sépare
Supposons le diagnostic posé. Reste à choisir la méthode, et le vocabulaire fait peur pour rien.
Le full fine-tuning met à jour tous les poids. Il exige de charger le modèle entier, ses gradients et les états de l’optimiseur en mémoire GPU : comptez plusieurs fois la taille du modèle. C’est le domaine des laboratoires, rarement celui des équipes produit.
Le LoRA (Low-Rank Adaptation) gèle les poids d’origine et n’entraîne que de petites matrices additionnelles injectées dans les couches d’attention. On touche typiquement moins de 1 % des paramètres, pour une qualité très proche sur les tâches de forme. Le résultat est un adaptateur de quelques dizaines de mégaoctets, que l’on charge et décharge à la volée sur un modèle de base partagé.
Le QLoRA ajoute la quantification : le modèle de base est chargé en 4 bits, l’adaptateur reste en précision plus haute. Le papier d’origine entraîne ainsi un modèle de 65 milliards de paramètres sur un seul GPU de 48 Go. C’est ce qui a fait basculer l’entraînement de gros modèles hors des salles machines.
Cette bascule a une conséquence stratégique qu’on sous-estime : le fine-tuning s’est déplacé vers les poids ouverts. Les bibliothèques qui structurent aujourd’hui la pratique, de TRL chez Hugging Face à Axolotl, Unsloth ou MLX sur matériel Apple, travaillent toutes sur des modèles que vous téléchargez et gardez. Miser sur l’entraînement d’un modèle fermé derrière une API, c’est accepter que la disponibilité de votre actif dépende du calendrier d’un fournisseur. Le risque n’a rien de théorique : OpenAI a fermé sa plateforme de fine-tuning aux nouveaux venus et annonce son extinction, quand Google maintient le fine-tuning supervisé de Gemini 2.5 sur Vertex AI. Deux calendriers, aucun des deux entre vos mains.
En pratique : commencez par LoRA ou QLoRA. Si le résultat est insuffisant, le problème vient presque toujours des données, pas de la méthode.
les données et la maintenance coûtent plus cher que le GPU
C’est le calcul que personne ne fait avant de lancer le projet. Quelques heures de GPU loué pour un QLoRA se chiffrent souvent en dizaines d’euros. Autant dire rien. Le coût est ailleurs.
Il est d’abord dans les données. Il vous faut des exemples réels, propres, cohérents entre eux, et surtout représentatifs des cas où le modèle échoue aujourd’hui. Quelques centaines suffisent souvent, mais quelques centaines relues par quelqu’un qui connaît le métier. Un jeu de données contradictoire, où deux exemples similaires appellent des réponses opposées, enseigne au modèle à être flou.
Il est ensuite dans la maintenance des versions. Un modèle entraîné est un artefact qui vieillit. Le modèle de base sort en version supérieure, votre besoin bouge, votre jeu de données s’enrichit : chaque itération redemande un entraînement, une évaluation, un déploiement. Vous n’avez pas acheté un résultat, vous avez souscrit un abonnement.
Il est enfin dans la régression silencieuse. Spécialiser un modèle sur une tâche dégrade souvent ses capacités générales, un phénomène connu sous le nom d’oubli catastrophique. Le système excelle sur le cas d’usage cible et se met à trébucher sur tout le reste, sans prévenir.
À l’inverse, un prompt se corrige en trois minutes et une base documentaire se met à jour en continu. Ce différentiel d’agilité vaut, à lui seul, beaucoup de points de qualité.
quatre pièces pour mesurer le gain
Un fine-tuning sans protocole d’évaluation n’est pas un projet technique, c’est une croyance. Et la règle d’or tient en une phrase : le jeu d’évaluation s’écrit avant l’entraînement.
Un dispositif minimal mais honnête tient en quatre pièces :
- un jeu de test figé, jamais vu à l’entraînement, construit à partir de vos cas d’échec réels ;
- une baseline mesurée sur le même jeu avec le modèle de base et un bon prompt, sans quoi vous n’aurez aucun point de comparaison ;
- une métrique qui colle à votre cas : taux de conformité au schéma pour un format strict, jugement comparatif par un modèle arbitre ou par un humain pour du style, exactitude métier pour une tâche de classement ;
- un jeu de contrôle sur des tâches générales, pour détecter la régression que personne ne cherche.
Le verdict est binaire et il doit être accepté d’avance : si le modèle entraîné ne bat pas franchement la baseline, on ne le déploie pas. Un gain de deux points sur cinquante exemples n’est pas un gain, c’est du bruit.
Cette discipline a une vertu inattendue : en écrivant le jeu de test, beaucoup d’équipes découvrent que leur problème était un mauvais découpage de documents ou une consigne ambiguë. L’entraînement n’a plus lieu d’être, et c’est une victoire.
connaissance, contexte, comportement : poser le diagnostic
Une seule question compte avant de lancer quoi que ce soit : qu’est-ce qui manque exactement au modèle ? De la connaissance, du contexte, ou un comportement ? Les deux premières réponses se traitent dans la fenêtre de contexte. Seule la troisième justifie de toucher aux poids.
Le réflexe inverse, celui qui fait ouvrir un notebook d’entraînement avant d’avoir mesuré quoi que ce soit, coûte cher sans qu’on s’en aperçoive : il transforme un réglage de quelques heures en actif à maintenir pendant des années. Le fine-tuning est un excellent outil. Il devient un piège dès qu’il sert de première réponse plutôt que de dernière.
Et quand la question se posera vraiment, elle se posera sur des poids que vous contrôlez. C’est peut-être le déplacement le plus structurant de ces dernières années : la personnalisation profonde d’un modèle est redevenue une affaire d’ingénierie interne, pas de bon de commande.
Questions frequentes
Quelle différence entre fine-tuning et RAG ?
Le fine-tuning modifie les poids du modèle pour installer un comportement, un style ou un format de sortie durable. Le RAG laisse les poids intacts et injecte des documents dans la fenêtre de contexte au moment de la requête, ce qui convient aux informations qui changent et permet de citer la source.
Combien d’exemples faut-il pour fine-tuner un LLM ?
Pour une tâche de forme comme un style ou un schéma de sortie, quelques centaines d’exemples de qualité suffisent généralement. La cohérence et la représentativité des exemples comptent davantage que leur nombre : un jeu de données contradictoire dégrade le résultat quelle que soit sa taille.
LoRA ou full fine-tuning : que choisir ?
LoRA, et sa variante quantifiée QLoRA, entraînent moins de 1 % des paramètres et tiennent sur un seul GPU, pour une qualité proche du full fine-tuning sur les tâches de style, de format et de comportement. Le full fine-tuning met à jour tous les poids et demande plusieurs fois la mémoire du modèle, ce qui le réserve à des cas rares.
Le fine-tuning permet-il d’apprendre de nouvelles connaissances à un modèle ?
Mal, et sans traçabilité. Les faits appris par entraînement sont figés, se périment sans signal et ne peuvent pas être rattachés à une source vérifiable. Pour de la connaissance mouvante, la récupération de documents reste la méthode fiable.
Comment mesurer si un fine-tuning a été utile ?
En comparant le modèle entraîné à une baseline mesurée avant l’entraînement, sur un jeu de test figé issu de cas d’échec réels, avec une métrique adaptée à la tâche. Un jeu de contrôle sur des tâches générales est nécessaire pour détecter une régression des capacités du modèle de base.
