Le 7 mai 2026, OpenAI a coupé l'accès au fine-tuning en libre-service pour toute organisation qui n'en avait jamais lancé avant cette date. Les clients inactifs depuis plus de 60 jours ont perdu cet accès le 2 juillet 2026. Les clients actifs pourront encore créer des jobs jusqu'au 6 janvier 2027, puis plus du tout (source). Le fine-tuning « à l'ancienne », où on envoie un dataset et on personnalise un modèle propriétaire en quelques clics, devient un service de niche chez le plus gros fournisseur du marché.
Ça ne rend pas le fine-tuning d'un LLM inutile. Ça oblige à savoir précisément quand y recourir, avec quelle méthode, et sur quel modèle. Ce texte suit ces trois questions dans l'ordre où elles se posent vraiment sur un projet : faut-il fine-tuner, avec quelle technique, et comment s'y prendre concrètement sur un modèle de langage open source.
Le vrai test avant de se lancer dans le fine-tuning
Sur les projets d'IA qu'on nous confie, la demande de fine-tuning arrive presque toujours en premier réflexe. Un client veut un ton de marque respecté à la lettre, ou un format de sortie précis, et pense qu'il faut entraîner son propre modèle. Dans la majorité des cas, un prompt système bien écrit avec quelques exemples en few-shot règle le problème. Le fine-tuning ne devient pertinent que quand trois conditions se cumulent.
Première condition : la tâche est étroite et répétitive. Classer des tickets support en cinq catégories, extraire des champs d'un type de document unique, générer des résumés dans un format fixe. Un modèle généraliste, même très capable, gaspille du contexte et du budget à réexpliquer la tâche à chaque appel. Deuxième condition : il existe assez d'exemples réels pour entraîner, en général plusieurs centaines à quelques milliers de paires entrée-sortie représentatives, pas dix exemples bricolés pour l'occasion. Troisième condition : le coût d'inférence ou la latence comptent vraiment. Un petit modèle fine-tuné sur une tâche précise peut battre un modèle généraliste bien plus gros, tout en coûtant beaucoup moins cher à faire tourner en production.
Exemple issu de nos projets, anonymisé : un client nous demande un fine-tuning pour homogénéiser le ton de ses réponses client. Après un audit rapide, un system prompt réécrit avec quinze exemples en few-shot règle le problème signalé, sans entraînement, sans dataset à maintenir dans la durée, sans risque de dégradation sur des cas que le fine-tuning n'aurait pas anticipés. Le budget GPU reste disponible pour un vrai besoin de classification, identifié plus tard dans le même projet.
Full fine-tuning, LoRA, QLoRA : ce qui change concrètement
Une fois la décision de fine-tuner actée, la question suivante est la méthode. Trois familles dominent en 2026, et l'écart entre elles se mesure surtout en mémoire GPU disponible.
Le fine-tuning complet met à jour tous les poids du modèle. C'est la méthode la plus lourde : pour un modèle de 7 milliards de paramètres, le seul état de l'optimiseur AdamW (copie des poids en fp32, momentum, variance) réclame déjà 84 Go de mémoire, avant même de compter les activations d'entraînement (source). Peu d'équipes ont ce budget GPU disponible en interne pour un usage ponctuel.
LoRA (Low-Rank Adaptation) fige les poids du modèle de base et n'entraîne que de petites matrices ajoutées à chaque couche. Le papier de recherche original mesure une réduction de 10 000 fois du nombre de paramètres entraînés et de 3 fois de la mémoire GPU nécessaire, comparé à un fine-tuning complet de GPT-3 175B avec Adam (source). C'est devenu la méthode par défaut sur la plupart des projets.
QLoRA pousse l'idée plus loin en quantifiant le modèle de base en 4 bits avant d'y appliquer LoRA. Le papier original démontre qu'il devient possible de fine-tuner un modèle de 65 milliards de paramètres sur un seul GPU de 48 Go, avec un modèle résultant (Guanaco) qui atteint 99,3 % du niveau de ChatGPT sur le benchmark Vicuna après 24 heures d'entraînement (source). Sur un projet où le budget GPU est la vraie contrainte, QLoRA est souvent le seul choix réaliste.
| Méthode | Ce qui est entraîné | Contrainte GPU |
|---|---|---|
| Fine-tuning complet | Tous les poids du modèle | 84 Go rien que pour l'optimiseur, sur un modèle 7B (source) |
| LoRA | Petites matrices ajoutées par couche | Jusqu'à 3 fois moins de mémoire que le fine-tuning complet (source) |
| QLoRA | LoRA sur un modèle quantifié en 4 bits | Un modèle 65B sur un seul GPU de 48 Go (source) |
OpenAI, Mistral : le fine-tuning managé a changé de visage en 2026
Le calendrier de retrait d'OpenAI cité en introduction n'est pas un simple ajustement de produit. Sur sa page de tarification actuelle, le seul modèle encore proposé au fine-tuning est o4-mini-2025-04-16, facturé 100 $ de l'heure de calcul, aussi bien en traitement standard qu'en traitement par lot (source). La facturation n'est plus au token entraîné mais au temps de calcul, un signe que l'usage visé n'est plus la personnalisation générale d'un modèle de production mais des jobs de réglage fin très spécifiques.
Mistral garde une porte ouverte, mais restreinte. Son offre de fine-tuning en self-service via la Classifier API couvre des modèles 3B et 8B, facturés 1 $ par million de tokens d'entraînement avec un minimum de 4 $ par job, plus 2 $ par mois et par modèle pour le stockage (source). C'est taillé pour des classifieurs légers (modération, routage d'intention), pas pour recréer un modèle généraliste sur mesure.
Le message pour qui pilote un projet IA : ne pas construire une feuille de route sur la promesse d'un fine-tuning managé bon marché et illimité chez les gros fournisseurs propriétaires. Les modèles ouverts qu'on héberge et fine-tune soi-même restent l'option la plus stable sur la durée, à condition de maîtriser aussi leur mise en production.
Fine-tuner un modèle open source, étape par étape
La méthode la plus reproductible reste le fine-tuning d'un modèle ouvert en interne, avec LoRA ou QLoRA selon le budget GPU disponible.
Constituer le dataset. Prévoir plusieurs centaines à quelques milliers de paires entrée-sortie représentatives de la tâche réelle, au format JSONL, avec une colonne prompt et une colonne réponse attendue. La qualité prime sur le volume : une centaine d'exemples propres et représentatifs valent mieux que dix mille exemples bruités.
Choisir ensuite le modèle de base. Un modèle plus petit et bien choisi pour la tâche bat souvent un modèle plus gros mal aligné avec le besoin. Vérifier la licence d'usage commercial avant de s'engager : certains modèles ouverts restreignent l'usage en production au-delà d'un certain volume.
Lancer l'entraînement avec les bibliothèques PEFT et bitsandbytes de Hugging Face, qui implémentent LoRA et QLoRA directement sur les architectures de transformeurs courantes. Un entraînement LoRA sur un dataset de taille raisonnable tient sur un seul GPU grand public, en quelques heures.
Le choix du rang des matrices LoRA (le paramètre souvent noté r) pèse directement sur le résultat. Un rang trop bas, autour de 4 ou 8, peut sous-apprendre une tâche qui demande de la nuance. Un rang trop haut, au-delà de 128, rapproche le coût mémoire d'un fine-tuning complet sans gain de qualité proportionnel. Sur la plupart des tâches de classification ou de reformatage rencontrées en entreprise, un rang entre 8 et 32 suffit largement, et c'est le premier réglage à tester avant d'aller chercher plus compliqué.
Évaluer avant de déployer, sur un jeu de test qui n'a jamais servi à l'entraînement, pas seulement sur des exemples proches du dataset d'entraînement. Le piège classique est un modèle qui semble excellent sur ses propres exemples et qui se dégrade sur tout le reste.
Déployer enfin le modèle fine-tuné avec Ollama pour un usage interne, ou vLLM pour tenir une charge de production. Sur les projets de développement sur mesure qu'on livre, cette étape de mise en production est souvent sous-estimée au moment du chiffrage initial.
Les erreurs qu'on voit revenir sur le terrain
Le surapprentissage arrive vite avec un dataset trop petit ou trop homogène. Le modèle mémorise les exemples au lieu d'apprendre le motif général, et échoue sur toute variation du cas d'usage réel qui n'était pas dans le dataset.
L'oubli catastrophique est moins visible mais tout aussi coûteux : le modèle devient excellent sur la tâche fine-tunée et perd des capacités générales qu'il avait avant, sans que personne s'en aperçoive avant un incident en production. Tester sur des cas hors du périmètre fine-tuné fait partie de l'évaluation, ce n'est pas une option.
Le dataset d'entraînement mérite une gouvernance aussi stricte que le code de production. Versionner les jeux de données, documenter leur provenance, et vérifier qu'aucune donnée personnelle client n'y figure sans base légale claire avant de l'envoyer à un service de fine-tuning managé hébergé hors UE. Un fine-tuning fait avec les données d'un client sans cette vérification pose un vrai risque RGPD, pas un détail de conformité à traiter après coup.
Dernier piège, plus discret : un modèle fine-tuné vieillit aussi vite que le modèle de base sur lequel il repose. Quand une nouvelle version du modèle open source de départ sort, avec de meilleures capacités ou des correctifs de sécurité, tout l'entraînement doit être rejoué pour en profiter, alors qu'un prompt système se met à jour en quelques minutes. Ce coût de maintenance récurrent est rarement chiffré au moment de la décision initiale, et pèse souvent plus lourd sur la durée que le coût de l'entraînement lui-même.
Pour un besoin ponctuel qui ne justifie pas de monter une équipe MLOps en interne, contacter Noxcod permet de trancher rapidement la question fine-tuning, RAG ou prompt engineering avant d'engager du budget GPU.
FAQ
Combien d'exemples faut-il pour fine-tuner un LLM ?
Ça dépend de la méthode et de la tâche, mais compter plusieurs centaines à quelques milliers d'exemples représentatifs pour un résultat fiable avec LoRA. En dessous de quelques dizaines d'exemples, un prompt bien écrit avec des exemples en few-shot donne généralement un meilleur résultat qu'un fine-tuning, pour beaucoup moins d'effort de mise en place.
Fine-tuning ou RAG : lequel choisir en premier ?
Le RAG en premier, presque toujours. Il permet d'ajouter des connaissances à jour sans réentraîner le modèle, et se corrige en modifiant la base documentaire plutôt qu'en relançant un job d'entraînement. Le fine-tuning devient utile quand le besoin porte sur un comportement ou un format précis, pas sur des connaissances à injecter.
Peut-on fine-tuner un LLM sans GPU dédié en interne ?
Oui pour de petits modèles avec QLoRA, qui tient sur un GPU grand public grâce à la quantification 4 bits. Pour un modèle plus gros, louer un GPU à l'heure chez un fournisseur cloud reste largement plus simple et moins cher que d'investir dans du matériel dédié pour un usage ponctuel.
Le fine-tuning fonctionne-t-il encore avec les modèles OpenAI en 2026 ?
De façon très réduite. OpenAI a coupé l'accès au fine-tuning en self-service aux nouvelles organisations depuis mai 2026, et prévoit une fermeture complète pour les clients existants en janvier 2027 (source). Les modèles ouverts hébergés en interne restent l'option stable sur la durée.
Le fine-tuning met-il en danger la confidentialité des données d'entreprise ?
Uniquement si le dataset d'entraînement n'est pas géré avec la même rigueur qu'une base de données client. Envoyer des données personnelles à un service de fine-tuning managé hors UE sans base légale est un risque RGPD réel, pas théorique. Fine-tuner un modèle ouvert hébergé en France élimine ce risque à la source.
