Aller au contenu principal

Quand et pourquoi fine-tuner un modèle

Mis à jour le 28 juillet 2026

Qu’est-ce que le fine-tuning ?

Le fine-tuning consiste à ré-entraîner un modèle de langage pré-existant sur vos propres données pour adapter son comportement à vos besoins spécifiques. Là où le prompt engineering guide le modèle par des instructions contextuelles — réécrites, envoyées et facturées à chaque appel —, le fine-tuning modifie les poids internes du modèle pour qu’il intègre durablement de nouveaux comportements. Une fois l’entraînement terminé, ce que vous décriviez dans un long prompt système fait partie du modèle lui-même.

Chez OpenAI, les modèles fine-tunables suivent le catalogue courant (la famille GPT-5.6 depuis juillet 2026) — consultez la documentation officielle du fine-tuning pour la liste exacte des variantes ouvertes à l’entraînement. Le circuit, lui, ne change pas : vous créez un jeu de données d’entraînement au format JSONL, vous lancez un job via l’API, et vous obtenez un modèle personnalisé que vous appelez exactement comme le modèle de base. Dans votre code, seul l’identifiant du modèle change.

Quand le fine-tuning est-il pertinent ?

Le fine-tuning n’est pas toujours la bonne réponse, et c’est la première chose à intégrer avant d’écrire la moindre ligne de JSONL. Il apporte une vraie valeur d’abord sur le ton et le style : si votre produit impose une voix particulière, l’entraîner sur quelques centaines d’échanges déjà rédigés dans cette voix vous évite de la rappeler dans chaque prompt. Le deuxième terrain est le format de sortie structuré. Quand votre pipeline attend un JSON dont le schéma ne doit jamais varier, des instructions bien écrites vous en approchent sans jamais vous le garantir à 100 % ; des exemples systématiquement conformes ramènent cet écart à presque rien.

Ces deux motifs en entraînent mécaniquement deux autres. Un modèle fine-tuné interrogé avec un prompt court répond plus vite qu’un modèle de base chargé d’un long prompt système, ce qui réduit la latence perçue par l’utilisateur ; et moins de tokens en entrée signifie une facture plus légère à volume constant, donc une réduction des coûts qui se lit directement sur un service traitant plusieurs milliers de requêtes par jour.

Restent deux familles de tâches sur lesquelles le fine-tuning excelle. La première regroupe les tâches de classification : catégoriser des tickets support, analyser des sentiments, trier des documents. La sortie attendue y est courte, fermée, et parfaitement illustrable par l’exemple. La seconde est le function calling cohérent : lorsque le modèle doit systématiquement appeler les bonnes fonctions avec les bons paramètres, lui montrer une centaine d’appels corrects est plus efficace que lui décrire la règle.

Symétriquement, quatre situations doivent vous en dissuader. Si vous avez peu de données, en dessous de 50 exemples, le prompt engineering avec quelques exemples en few-shot fera mieux pour un effort bien moindre. Si votre domaine évolue vite, avec un catalogue produit ou une tarification qui bouge chaque semaine, le RAG (Retrieval-Augmented Generation) vous évitera de ré-entraîner en permanence. La confusion la plus fréquente consiste à vouloir injecter des connaissances factuelles : le fine-tuning enseigne des comportements, pas des faits, et là encore le RAG est l’outil adapté. Enfin, si le prompt engineering suffit, si quelques instructions bien rédigées donnent déjà de bons résultats, ne complexifiez pas votre chaîne pour le plaisir.

Fine-tuning vs. alternatives

Les trois approches ne sont pas concurrentes : elles couvrent des besoins différents et se combinent très bien, par exemple un modèle fine-tuné pour le format alimenté par un RAG pour les faits.

Approche Idéal pour Limites
Prompt engineering Prototypage rapide, tâches variées Consomme des tokens, résultats variables
RAG Connaissances dynamiques, bases documentaires Latence accrue, complexité infra
Fine-tuning Comportements stables, ton, format, classification Données nécessaires, coût d'entraînement

Le workflow type

Le reste de ce cours suit l’ordre dans lequel vous exécuterez réellement ces étapes. Prenez quelques minutes, avant de continuer, pour écrire la première : formuler le comportement visé en une phrase vous évitera de collecter des données au hasard.

  1. Identifier le besoin : quel comportement voulez-vous que le modèle adopte systématiquement ?
  2. Collecter les données : rassembler au moins 50 à 100 exemples de conversations idéales
  3. Préparer le JSONL : formater vos données selon le schéma attendu par l’API
  4. Lancer l’entraînement : créer un job de fine-tuning via client.fine_tuning.jobs.create()
  5. Évaluer : comparer les performances du modèle fine-tuné avec le modèle de base
  6. Itérer : ajuster vos données et relancer si nécessaire

Points clés à retenir

  • Le fine-tuning modifie le comportement du modèle, pas ses connaissances factuelles
  • Il est pertinent quand vous avez des données suffisantes et un besoin de cohérence
  • Commencez toujours par le prompt engineering — ne fine-tunez que si ça ne suffit pas
  • La liste des modèles fine-tunables évolue avec le catalogue OpenAI — vérifiez la documentation officielle avant de lancer un job