Une entreprise décide de personnaliser une intelligence artificielle, et le même mot revient presque toujours en premier dans la réunion : fine-tuning. J’observe ce réflexe très souvent, et il fait sauter la seule question qui compte : quel problème cherche-t-on réellement à résoudre ?
Le fine-tuning d’un LLM (Large Language Model, ou grand modèle de langage, la famille de modèles qui alimente les assistants conversationnels) consiste à poursuivre l’entraînement d’un modèle déjà entraîné, sur un jeu de données plus petit et ciblé. Le but est d’adapter son comportement à un besoin précis : un ton, un format, une terminologie métier, une manière de classer. Il modifie des réflexes du modèle, pas sa base de connaissances. Quand l’information change souvent, un système RAG (retrieval augmented generation, un dispositif qui va chercher l’information dans vos documents au moment de répondre) est généralement plus simple à maintenir. Et quand le besoin tient en quelques règles claires, un prompt mieux écrit suffit souvent.
Le fine-tuning d’un LLM, expliqué simplement
Un modèle de langage est d’abord pré-entraîné sur un corpus de textes considérable. Cette première phase lui donne sa capacité générale à rédiger, résumer, reformuler, suivre une consigne. Le fine-tuning arrive après, sur un corpus beaucoup plus restreint et orienté vers une tâche.
La CNIL en donne une définition courte : une « technique consistant à spécialiser un modèle d’IA pré-entraîné à l’accomplissement d’une tâche spécifique ». Elle précise que « cela consiste généralement à entraîner le modèle dans son ensemble, ou seulement certaines couches d’un réseau de neurones, pour un faible nombre d’itérations sur un ensemble de données spécifiques correspondant à la tâche visée ». Vous croiserez aussi les traductions françaises « affinage » et « réglage fin », que la CNIL mentionne : elles désignent la même opération.
Source : CNIL, définition « Ajustement (fine-tuning) », vérifié le 10 août 2026.
Deux mots de vocabulaire aident à se repérer. Un LLM repose sur une architecture appelée Transformer et sur des paramètres, ces valeurs numériques ajustées pendant l’entraînement, qui encodent ce que le modèle a appris. Fine-tuner revient à modifier tout ou partie de ces valeurs à partir d’un dataset, un jeu d’exemples préparés pour la tâche visée. Le tout relève du machine learning, cette branche de l’informatique où une machine apprend à partir de données au lieu de recevoir des règles écrites à la main.
Un exemple rend la chose concrète. Un modèle généraliste sait déjà rédiger un e-mail correct. Adapté sur des échanges réels de votre support client, il apprend votre ton, votre structure de réponse, vos mentions obligatoires et votre niveau de formalité. Il n’a rien appris de nouveau sur vos produits : il a appris votre manière de répondre.
Comportement ou connaissances : ce que le fine-tuning modifie vraiment
C’est la distinction la plus importante de cet article, et la plus souvent ratée. Un modèle adapté ne devient pas mieux informé. Il devient un modèle qui se comporte autrement.
Ce que la technique améliore bien :
- le ton, le style et le niveau de langue attendus ;
- le respect d’un format de sortie complexe et constant ;
- le vocabulaire d’un métier, y compris ses abréviations internes ;
- les tâches de classement et d’extraction répétitives ;
- le respect d’instructions longues, sans avoir à les redonner à chaque fois.
Ce pour quoi elle est mal adaptée : intégrer des connaissances qui bougent. Un tarif, un stock, une procédure, une jurisprudence : chaque évolution supposerait de repasser par un entraînement, et figerait une information périssable dans les paramètres du modèle.
La formulation qui met tout le monde d’accord dans nos réunions est la suivante : un RAG apporte l’information au moment de répondre, le fine-tuning modifie des réflexes. Le premier agit à l’inférence, c’est-à-dire au moment où le modèle produit sa réponse. Le second agit en amont, sur le modèle lui-même. Quant au prompt engineering, l’art de formuler la consigne, il agit sur ce que vous demandez.
Idée reçue
Fine-tuner un modèle ne lui apprend pas les informations de votre entreprise comme on remplit une base de données. Les exemples d’entraînement lui montrent une façon de faire, pas un référentiel à consulter.
Prompt, RAG ou fine-tuning : comment trancher
Les trois approches sont souvent présentées comme trois niveaux de sophistication, la troisième étant la plus avancée. C’est une lecture trompeuse : elles ne résolvent pas le même problème.
| Approche | Le problème qu’elle résout | Signal qu’elle est le bon choix |
|---|---|---|
| Prompt | Le modèle sait faire, mais il faut lui préciser quoi et comment | Besoin ponctuel, règles descriptibles en quelques lignes, volume limité, format simple |
| RAG | Le modèle ne connaît pas vos informations, et celles-ci évoluent | Documents internes, sources à mettre à jour, besoin de citer des références, données que vous ne voulez pas figer dans les paramètres |
| Fine-tuning | Le modèle sait, mais pas à votre manière, et il faut le refaire tous les jours | Comportement à reproduire régulièrement, format complexe, vocabulaire métier, prompts devenus interminables ou répétitifs |
Ces cases ne sont pas exclusives. Un besoin fréquent combine un comportement spécialisé et des informations à jour : un modèle adapté au format et au ton attendus, alimenté par un dispositif de recherche documentaire qui s’appuie souvent sur une base vectorielle, cette base de données qui retrouve un passage par proximité de sens plutôt que par correspondance exacte de mots.
Avant d’ouvrir un projet, quatre questions suffisent à trancher. Quel élément du modèle voulez-vous modifier : ce qu’il sait, ou la manière dont il répond ? L’information concernée change-t-elle dans le temps ? Vos données sont-elles exploitables en l’état ? Et surtout : comment saurez-vous que le résultat est meilleur ? Tant que la quatrième reste sans réponse, aucune des trois approches n’est prête à être choisie.
Les situations où il vaut mieux ne pas fine-tuner
Renoncer est parfois la bonne décision, et elle se prend en amont, pas au bout de trois semaines d’expérimentations. Voici les signaux qui arrêtent un projet avant son démarrage :
- Le besoin n’est pas défini. « On aimerait une IA à nous » n’est pas une tâche, donc rien ne peut être mesuré.
- Les données manquent, ou elles sont mauvaises. Exemples contradictoires, formats hétérogènes, cas rares absents : le modèle apprendra exactement cela.
- L’information change fréquemment. Il faudrait réentraîner à chaque évolution, ce qui transforme un projet en abonnement involontaire.
- Aucune méthode d’évaluation n’existe. Sans mesure, aucune amélioration ne peut être établie, seulement ressentie.
- Un prompt mieux écrit ferait déjà l’affaire. Je conseille toujours d’épuiser cette piste avant, elle est réversible en cinq minutes.
- La maintenance dans la durée n’est pas assurée. Un modèle adapté vieillit avec vos données, votre besoin et le modèle de départ.
- Le budget est disproportionné par rapport au gain attendu. Un gain de confort sur une tâche mensuelle ne justifie pas une chaîne d’entraînement.
- Le motif est d’apparaître dans les réponses de ChatGPT. Ce besoin est légitime, mais il ne relève pas du fine-tuning. La section dédiée plus bas explique pourquoi.
Full fine-tuning, PEFT, LoRA, QLoRA : quelle partie du modèle est modifiée
Trois familles décrivent d’abord ce qu’on montre au modèle. Le supervised fine-tuning lui présente des paires entrée/sortie attendues, par exemple une demande client et la réponse validée. L’instruction fine-tuning lui présente des consignes et les réponses correspondantes, pour améliorer sa manière d’obéir à une demande formulée en langage naturel.
La troisième ne lui montre plus la bonne réponse, mais laquelle de deux réponses est préférée : c’est l’alignement sur préférences, que vous croiserez sous deux sigles. Le RLHF (reinforcement learning from human feedback, apprentissage par renforcement à partir de retours humains) procède en deux temps : il ajuste d’abord un modèle de récompense qui reflète les préférences humaines, puis entraîne le modèle de langage à maximiser cette récompense sans trop s’éloigner du modèle d’origine. Le DPO (direct preference optimization, optimisation directe des préférences) supprime cette étape intermédiaire et apprend directement sur les réponses comparées, ce que ses auteurs présentent comme une procédure plus stable et moins coûteuse en calcul. Dans les deux cas, le jeu de données n’est plus fait d’exemples corrigés mais de réponses mises en concurrence, ce qui change entièrement le travail de préparation.
Source : Hugging Face, documentation du DPO Trainer de TRL, qui reprend le résumé de l’article de recherche introduisant la méthode, vérifié le 11 août 2026.
Les méthodes se distinguent ensuite par la part du modèle qu’elles touchent, sachant que les poids sont simplement le nom donné aux paramètres ajustables du réseau.
| Méthode | Fonctionnement simplifié | Ordre de ressources | Usage principal |
|---|---|---|---|
| Full fine-tuning | Tout ou une part importante des poids est modifiée | Très important | Adaptation profonde d’un modèle, généralement hors de portée d’une équipe interne |
| PEFT (Parameter-Efficient Fine-Tuning) | Famille de méthodes qui n’entraînent qu’une fraction des paramètres | Réduit | Adapter sans reconstruire, cas le plus courant en entreprise |
| LoRA | De petits modules entraînables sont ajoutés au modèle, dont les poids d’origine restent figés | Modéré | Spécialiser un comportement, garder plusieurs variantes du même modèle |
| QLoRA | Même principe que LoRA, appliqué à un modèle quantifié | Plus faible | Travailler avec une mémoire limitée |
La quantification consiste à représenter les poids avec moins de précision numérique, ce qui allège la mémoire nécessaire au prix d’un compromis sur la finesse du modèle. S’y ajoutent les hyperparamètres, ces réglages que vous fixez avant l’entraînement et que le modèle n’apprend pas lui-même.
Ce tableau simplifie à dessein. Il sert à comprendre ce qui est modifié et à quel ordre de coût, pas à choisir une configuration : ce choix dépend du modèle de départ, de la tâche et du matériel.
C’est le dataset qui décide du résultat, pas la méthode
Si je ne devais retenir qu’une phrase des projets que nous avons vus passer, ce serait celle-ci. La méthode se change en une journée, le dataset se reconstruit en semaines, et c’est lui qui fixe le plafond.
Un bon jeu de données est propre, cohérent, représentatif des situations réelles, suffisamment divers, correctement formaté, conforme aux résultats attendus, contrôlé pour ses biais et juridiquement utilisable. Ce dernier point n’est pas un détail administratif : des exemples issus de conversations clients contiennent presque toujours des données personnelles.
Un mauvais dataset, lui, enseigne très efficacement ce qu’il contient : erreurs factuelles, contradictions d’un exemple à l’autre, format qui varie, ton que personne n’a validé. L’annotation, le travail humain de préparation et de vérification des exemples, est la partie la plus ingrate et la plus déterminante.
Combien d’exemples faut-il ? Aucun nombre universel n’existe, et je me méfie de ceux qui en citent un. La quantité dépend de la tâche, de la diversité des situations à couvrir, du modèle de départ, du format visé et de la méthode retenue. Le principe utile est ailleurs : quelques centaines d’exemples cohérents et représentatifs peuvent produire un meilleur résultat que plusieurs milliers d’exemples bruités. Encore faut-il qu’ils ressemblent à ce que le modèle rencontrera après déploiement, pas à ce qu’il serait agréable qu’il rencontre.
Les étapes d’un projet de fine-tuning
Un projet de fine-tuning ne se limite pas à lancer un entraînement. L’entraînement est souvent l’étape la plus courte.
- Définir la tâche précise que le modèle doit accomplir mieux qu’aujourd’hui.
- Mesurer les performances du modèle de départ sur cette tâche, avant toute modification.
- Choisir le modèle de base, selon la tâche, la langue et les contraintes d’hébergement.
- Vérifier sa licence, notamment le droit de le modifier et de l’exploiter commercialement.
- Collecter les données représentatives de la tâche.
- Les nettoyer, les formater, retirer ce qui ne doit pas y figurer.
- Séparer trois jeux distincts : entraînement, validation (pour régler les paramètres en cours de route) et test (jamais vu par le modèle).
- Choisir la méthode d’adaptation en fonction des ressources disponibles.
- Expérimenter petit, en ajustant le taux d’apprentissage (l’amplitude des corrections à chaque étape), la taille de lot ou batch size (le nombre d’exemples traités ensemble) et le nombre d’époques d’entraînement (les passages complets sur le jeu de données).
- Évaluer sur le jeu de test, et non sur les données d’entraînement.
- Comparer au modèle de départ et, quand c’est pertinent, à un benchmark, c’est-à-dire une série de tests standardisés servant de repère commun.
- Déployer, avec une procédure de retour arrière prévue.
- Surveiller dans la durée et réévaluer quand les données ou le besoin évoluent.
Ressources, budget : les facteurs qui font varier la note
Aucun tarif universel ne peut être annoncé ici, et aucune configuration matérielle ne vaut pour tous les cas. Je préfère raisonner en facteurs de variation, que vous pouvez appliquer à votre propre contexte pour comprendre d’où viendra la facture :
- la taille du modèle de départ, qui pèse sur presque tout le reste ;
- la méthode retenue, entre une modification complète des poids et une adaptation partielle ;
- la longueur des séquences traitées, mesurée en tokens, ces fragments de texte que le modèle manipule à la place des mots ;
- le volume de données d’entraînement ;
- le nombre d’époques, donc de passages sur ces données ;
- la mémoire GPU disponible, c’est-à-dire celle des processeurs graphiques utilisés pour l’entraînement ;
- le recours ou non à la quantification, qui abaisse le besoin en mémoire ;
- le nombre d’expérimentations avant d’obtenir un résultat exploitable, souvent sous-estimé.
Une remarque pour finir : le coût d’un projet ne se limite jamais à l’entraînement. La préparation des données, l’évaluation, le déploiement et la maintenance pèsent lourd, et ce sont les postes qui reviennent chaque année.
Comment savoir si le modèle adapté est réellement meilleur
Voici une scène que j’ai vue plus d’une fois. La courbe d’apprentissage descend joliment, l’équipe est satisfaite, et sur le jeu de test le modèle recrache les exemples d’entraînement presque mot pour mot. Une perte d’entraînement qui baisse indique que le modèle apprend ses exemples. Elle ne dit rien de son comportement en production.
Deux règles évitent l’essentiel des illusions. D’abord, mesurer sur des données que le modèle n’a jamais vues pendant l’entraînement. Ensuite, comparer systématiquement trois candidats : le modèle de départ, le modèle adapté, et la solution la plus simple que vous auriez pu déployer à la place, un prompt travaillé ou un RAG.
Les critères à suivre dépendent de la tâche, mais la liste est souvent proche :
- exactitude des réponses sur des cas réels ;
- respect du format attendu, mesurable de façon binaire ;
- pertinence jugée par les personnes qui utiliseront l’outil ;
- taux d’erreur, et surtout nature des erreurs restantes ;
- cohérence entre deux réponses à des demandes proches ;
- capacité à généraliser à des situations absentes du dataset ;
- réduction du volume de corrections humaines ;
- coût par réponse et temps gagné sur le processus complet.
Ces deux derniers critères décident du sort du projet en comité : un modèle légèrement meilleur mais plus coûteux à faire tourner qu’une solution existante n’a pas gagné.
Les risques à regarder avant de lancer un entraînement
Sept risques reviennent dans la plupart des projets. Aucun n’est rédhibitoire, mais chacun se traite avant l’entraînement, quand il coûte encore une décision plutôt qu’un recommencement.
Le surapprentissage
Le modèle mémorise les exemples au lieu d’en tirer une règle. Il excelle sur ce qu’il a vu et se dégrade sur le reste.
L’oubli catastrophique
En se spécialisant, un modèle peut perdre des capacités générales qu’il maîtrisait avant. Une adaptation trop appuyée sur un format étroit se paie ailleurs.
Les biais du dataset
Ceux du dataset sont reproduits, parfois amplifiés. Si vos exemples viennent d’une seule équipe ou d’un seul type de client, le modèle en héritera.
Les hallucinations
Une adaptation ne rend pas un modèle véridique. Elle peut même rendre ses affirmations plus assurées, donc plus difficiles à repérer, là où il se trompe.
La confidentialité des données
Des données personnelles ou sensibles présentes dans le corpus se retrouvent dans le modèle, avec les obligations réglementaires qui vont avec.
Les licences des modèles
Tous les modèles ne peuvent pas être modifiés, redistribués ni exploités commercialement dans les mêmes conditions. Cette vérification se fait avant la collecte des données, pas après l’entraînement.
La maintenance dans la durée
Un modèle adapté n’est pas un livrable définitif. Il se réévalue quand les données, le besoin ou le modèle de base évoluent.
S’y ajoutent trois erreurs de mise en œuvre très répandues : ne pas avoir mesuré le modèle de départ, ne pas avoir séparé les jeux d’entraînement, de validation et de test, et lancer un entraînement long sans avoir vérifié sur une petite expérimentation que la piste apporte quelque chose.
Peut-on fine-tuner ChatGPT pour que l’IA cite son entreprise ?
Non. C’est la question qui revient le plus souvent dans nos échanges avec des directions marketing, et la réponse est directe. Une entreprise ne peut pas modifier le modèle public utilisé par ChatGPT, ni en lui envoyant ses contenus, ni en publiant des pages. Les paramètres de ces modèles restent la propriété de ceux qui les entraînent.
Ce qu’une entreprise peut faire, c’est adapter un modèle dans son propre environnement, ou passer par un service d’adaptation privée proposé par un éditeur. Le résultat lui appartient et ne concerne que ses usages. Cette adaptation ne change rien aux réponses que ChatGPT, Gemini, Claude ou Perplexity affichent aux autres utilisateurs. Autrement dit, aucune adaptation de modèle ne suffit à obtenir une citation : la citation ne se décrète pas.
Idée reçue
Publier des contenus sur son site ne modifie aucun paramètre du modèle public de ChatGPT. Ces contenus peuvent en revanche être trouvés, lus et repris au moment où le moteur construit sa réponse, ce qui relève d’un tout autre mécanisme.
C’est précisément ce mécanisme que travaille le GEO (Generative Engine Optimization, l’optimisation pour les moteurs génératifs). Le GEO n’agit pas sur le modèle : il agit sur l’écosystème d’informations que ces moteurs peuvent trouver et utiliser au moment de répondre. Il s’agit de rendre une entreprise identifiable sans ambiguïté, compréhensible, crédible par ses preuves, présente sur les sujets où les questions se posent, et décrite de manière cohérente d’une source à l’autre. C’est un travail de fond sur les contenus, les mentions et les signaux, pas un réglage technique. Nous détaillons cette approche dans nos ressources sur la façon d’améliorer sa visibilité sur ChatGPT et dans la présentation de notre offre d’agence GEO.
La formule que j’utilise pour clore le débat tient en une ligne : le fine-tuning adapte un modèle utilisé par l’entreprise, le GEO agit sur l’écosystème d’informations consulté par les modèles utilisés par ses prospects. Ce sont deux chantiers différents, avec deux budgets différents et deux équipes différentes.
Là où le fine-tuning peut réellement aider une équipe SEO ou GEO
L’histoire ne s’arrête pas là, car cette technique a de vrais usages en marketing. Ils sont internes, invisibles pour le public, et rentables sur des tâches à fort volume :
- classer des milliers de prompts par intention, par thématique ou par étape du parcours d’achat ;
- regrouper des formulations proches pour identifier les questions réellement posées ;
- analyser des mentions de marque collectées à grande échelle ;
- normaliser des réponses hétérogènes récupérées auprès de plusieurs moteurs ;
- repérer les concurrents cités et extraire les sources mobilisées dans une réponse ;
- analyser le sentiment associé à une marque dans un corpus de réponses ;
- détecter les incohérences entre deux réponses portant sur le même sujet ;
- produire des contenus internes dans un format constant.
Ce qu’il ne fera pas, en revanche : imposer votre marque dans les réponses publiques, créer de l’autorité là où il n’y en a pas, ou remplacer les mentions tierces sur lesquelles les moteurs s’appuient.
Une nuance s’impose sur l’automatisation, qui est souvent survendue. Collecter des centaines de réponses de moteurs génératifs s’automatise très bien. Les interpréter reste difficile : une réponse peut être exacte, partiellement correcte, contradictoire avec une autre, ou simplement ambiguë. Le jugement humain demeure le goulot d’étranglement, et un modèle adapté ne fait que l’accélérer.
C’est en partant de ce constat que SEO.fr a créé trois marques fictives et interrogé plusieurs modèles pour observer ce qu’ils en retenaient, ce qu’ils citaient et ce qu’ils déformaient. Les enseignements sont rassemblés dans notre étude sur les signaux qui influencent les LLM. Ils portent notamment sur la part de voix générative, c’est-à-dire la proportion de réponses dans lesquelles une marque apparaît sur un ensemble de questions donné.
Les outils, et ce qu’ils font réellement
Cette section n’est pas un classement, et je me garderai d’en faire un : le bon outil dépend du modèle choisi et de l’infrastructure disponible. Ce qui compte, c’est de comprendre les rôles, car un projet en mobilise toujours plusieurs.
- Charger et manipuler le modèle. La bibliothèque Transformers remplit ce rôle, au-dessus d’un cadre de calcul comme PyTorch.
- Préparer les données. Des outils de traitement classiques, plus une part de travail manuel qu’aucune bibliothèque ne remplace.
- Entraîner les adaptateurs. PEFT sert à n’entraîner qu’une fraction des paramètres, TRL à conduire des entraînements orientés instructions et préférences : sa documentation cite le supervised fine-tuning, l’optimisation directe des préférences et la modélisation de récompense parmi les méthodes qu’elle outille.
- Simplifier la mise en route. Des projets comme Unsloth ou Llama Factory emballent ces briques dans un chemin plus court, utile pour une première expérimentation sur une machine modeste. Ils ne dispensent d’aucune des décisions prises en amont.
- Suivre les expérimentations. Un outil comme MLflow enregistre réglages, versions et résultats, ce qui évite de comparer deux essais sans savoir en quoi ils différaient.
- Évaluer et déployer. Des cadres d’évaluation rejouent les mêmes tests d’une version à l’autre, avant un déploiement sur une infrastructure GPU louée ou une plateforme de fine-tuning géré.
Transformers, PEFT et TRL sont documentés parmi les bibliothèques de modèles LLM référencées sur le Hub Hugging Face, ce qui en fait un point de départ raisonnable pour se repérer.
Source : Hugging Face, documentation des bibliothèques du Hub, vérifié le 10 août 2026.
Ce qu’il faut décider avant de choisir une méthode
Reprenons la question du début. La première étape d’un projet d’adaptation n’est pas de choisir un outil, une méthode ou une carte graphique. Elle consiste à nommer ce que le modèle fait mal aujourd’hui, et à décider comment l’amélioration sera mesurée. Tant que ces deux phrases ne sont pas écrites, le reste est prématuré.
Ma conclusion n’est ni un rejet ni une recommandation générale. Sans besoin précis, sans données propres et sans méthode d’évaluation, le fine-tuning est une expérimentation coûteuse dont personne ne saura dire si elle a réussi. Avec un besoin cadré, des exemples représentatifs et une mesure honnête, c’est un levier réel sur des tâches répétitives, dont le gain se lit en temps et en corrections évitées.
Et si votre objectif est d’apparaître dans les réponses des IA génératives, changez de chantier : cela se joue sur les informations que ces moteurs trouvent à votre sujet, pas sur les paramètres d’un modèle. Chez SEO.fr, nous suivons mois après mois les réponses produites par ces moteurs sur les marchés de nos clients, et c’est cette observation continue qui fait bouger les lignes. Nos ressources sur le GEO et l’intelligence artificielle rassemblent la méthode et les repères de mesure.
