Préparer un dataset de fine-tuning LLM, c'est là que 80 % des projets déraillent — pas à l'entraînement, pas au déploiement. Un dataset mal formaté ou rempli d'exemples contradictoires produit un modèle instable, même avec les meilleures techniques LoRA et le meilleur GPU du monde. La bonne nouvelle : l'entraînement coûte entre 5 et 100 € de compute en 2026. Le vrai coût, c'est 40 à 200 heures de préparation de données.
Cet article pose la méthode complète pour préparer un dataset de fine-tuning LLM : combien d'exemples, quel format JSONL choisir, comment construire vos données depuis des sources internes, comment nettoyer, dédupliquer et équilibrer. Et surtout, les pièges qui font échouer les projets les plus sérieux.
Combien d'exemples pour fine-tuner un LLM : la règle qui dérange
La question revient sur presque tous les projets : "Il nous faut combien d'exemples ?" Et la réponse dérange souvent, parce qu'elle contredit l'intuition.
200 exemples excellents valent mieux que 2 000 médiocres. Ce n'est pas une figure de style. C'est ce qu'on observe sur le terrain, et c'est cohérent avec ce que publient les équipes de recherche d'LIMA (Meta AI, 2023) : un modèle fine-tuné sur 1 000 exemples soigneusement sélectionnés surpasse des modèles entraînés sur des dizaines de milliers d'exemples bruyants.
Mais "combien" dépend de ce que vous demandez au modèle. Voici les ordres de grandeur constatés sur des projets réels :
| Type de tâche | Exemples minimum | Exemples recommandés | Complexité de l'annotation |
|---|---|---|---|
| Adaptation de style / ton rédactionnel | 200 | 500–800 | Faible (vos meilleures productions) |
| Classification (5–15 catégories) | 300 par classe | 500–1 000 par classe | Moyenne (validation expert métier) |
| Extraction d'entités nommées métier | 500 | 1 000–2 000 | Élevée (annotation manuelle) |
| Génération structurée (JSON, formulaires) | 300 | 600–1 200 | Moyenne |
| Raisonnement complexe / domaine très spécialisé | 1 000 | 2 000–5 000 | Très élevée |
Ces chiffres supposent des données de qualité. Si vos exemples sont hétérogènes ou partiellement incohérents, doublez les volumes estimés — et acceptez quand même un résultat moins prévisible.
Le format dataset fine-tuning LLM : l'erreur n°1 des projets qui échouent
Ne pas respecter le format attendu par le modèle est la cause d'échec la plus fréquente et la moins évidente. Le modèle s'entraîne, les métriques semblent raisonnables, et pourtant en inférence les réponses sont incohérentes, trop courtes, ou le modèle répète la question au lieu de répondre.
Format Alpaca (instruction/output) : simple, mais limité
Le format Alpaca est le plus simple. Chaque exemple JSON a trois champs :
{
"instruction": "Rédige un résumé de ce contrat en trois points.",
"input": "[texte du contrat]",
"output": "1. Durée : 24 mois à compter du 1er janvier 2026. 2. ..."
}Ce format convient aux modèles de base (base models) non-instruct. Pour les modèles Instruct — Mistral-Instruct, Llama-3-Instruct, Phi-3-Instruct — ce format seul ne suffit plus. Il faut l'envelopper dans le template natif du modèle.
Le chat template : obligatoire pour les modèles Instruct
Chaque famille de modèles Instruct a son propre template de tokenisation. Le non-respect de ce template est la cause n°1 d'échec silencieux en fine-tuning. Deux exemples :
Mistral v1/v2 attend le format [INST]...[/INST] :
<s>[INST] Rédige un résumé en trois points. [/INST]
1. Durée : 24 mois... </s>Llama 3 / Mistral Instruct v3+ utilisent le format ChatML avec des rôles explicites :
{
"messages": [
{"role": "system", "content": "Tu es un assistant juridique expert."},
{"role": "user", "content": "Rédige un résumé de ce contrat en trois points."},
{"role": "assistant", "content": "1. Durée : 24 mois..."}
]
}Les librairies comme TRL (Transformer Reinforcement Learning, HuggingFace) et Axolotl appliquent automatiquement le bon template si vous leur passez les données au format messages et précisez le bon modèle de base. Ne jamais construire les tokens manuellement — laissez le tokenizer du modèle faire ce travail.
Le fichier JSONL : une ligne = un exemple
Le format de fichier standard est le JSONL (JSON Lines) : chaque ligne du fichier est un objet JSON complet et indépendant. Pas de tableau à la racine, pas de virgule entre les lignes. Un fichier de 500 exemples = 500 lignes.
{"messages": [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}
{"messages": [{"role": "user", "content": "..."}, {"role": "assistant", "content": "..."}]}Ce format est nativement supporté par TRL, Axolotl, Unsloth (la librairie la plus rapide pour fine-tuner Mistral et Llama en 2026) et les APIs de fine-tuning managé comme OpenAI ou Mistral La Plateforme.
Construire votre dataset depuis des sources internes
Soyons honnêtes : la plupart des PME n'ont pas un dataset propre qui attend dans un coin. Les données existent, mais sous forme brute. Les transformer en exemples exploitables pour un fine-tuning, c'est le vrai travail.
Les meilleures sources de données internes
Sur les projets que nous accompagnons, les sources les plus productives sont, dans l'ordre :
- Tickets de support résolus : la paire (demande client, réponse validée par un agent senior) est naturellement au format instruction/réponse. Source idéale pour fine-tuner un assistant de support ou de première ligne.
- Emails traités : les boîtes mail des commerciaux ou des équipes juridiques contiennent des milliers de paires (email entrant, réponse rédigée). Attention à l'anonymisation.
- Rapports et synthèses validés : si vos équipes produisent régulièrement des synthèses à partir de notes brutes ou de comptes rendus, ce couple (source brute, synthèse finale validée) est en or pour fine-tuner un modèle de génération structurée.
- Formulaires remplis : pour les tâches d'extraction (extraire des entités depuis un document), les formulaires déjà complétés manuellement à partir de documents source sont une mine.
- Conversations de chat interne annotées : si votre équipe utilise déjà un chatbot en production, les logs avec les corrections humaines sont directement exploitables.
Pipeline de nettoyage en 5 étapes
Aucune source interne ne s'utilise brute. Le pipeline minimal avant tout entraînement :
- Anonymisation. Supprimer les noms, emails, numéros de clients, données bancaires. Des outils comme Presidio (Microsoft, open source) automatisent 80 % du travail. Le reste se valide à la main.
- Déduplication exacte et approchée. Les doublons exacts sont faciles à supprimer (hash MD5 sur le texte normalisé). Les quasi-doublons sont plus sournois : un même email avec deux formulations légèrement différentes peut faire apprendre au modèle une incohérence. MinHash LSH ou une simple similarité cosinus sur embeddings permettent de les détecter.
- Filtrage des exemples ambigus ou contradictoires. Si deux exemples posent la même question et donnent deux réponses opposées, le modèle apprend à être incertain. Ces cas doivent être résolus manuellement, pas supprimés automatiquement — parfois l'un des deux exemples est juste incorrect.
- Validation experte sur échantillon. Faire valider 10 à 15 % du dataset par un expert métier, tiré aléatoirement. Si l'expert valide moins de 85 % des exemples, le dataset a un problème systémique à corriger avant de continuer.
- Équilibrage des classes (pour la classification). Si 90 % de vos exemples appartiennent à la même catégorie, le modèle apprendra à prédire toujours cette catégorie et obtiendra 90 % d'accuracy en faisant n'importe quoi. Sur-échantillonner les classes rares ou sous-échantillonner les classes dominantes. Pas les deux à la fois.
Split train/validation/test : la règle et le piège classique
La règle standard : 80 % entraînement / 10 % validation / 10 % test. Sur des datasets petits (moins de 500 exemples), on peut monter à 85/10/5.
Le split de validation est utilisé pendant l'entraînement pour surveiller la loss et décider quand stopper (early stopping). Le split de test ne doit jamais être vu pendant l'entraînement — il sert uniquement à l'évaluation finale du modèle.
Le piège le plus fréquent et le plus dévastateur : la fuite train/test (data leakage).
Piège à éviter
Si deux exemples très similaires (ou des quasi-doublons) se retrouvent un dans le split train et l'autre dans le split test, les métriques d'évaluation sont gonflées artificiellement. Le modèle "mémorise" plutôt qu'il n'apprend à généraliser. Toujours dédupliquer avant de faire le split, jamais après.
Un autre piège souvent oublié : le split temporel. Si vos données ont une dimension temporelle (emails de 2023 et 2025 mélangés), un split aléatoire fait "fuir" le futur dans l'entraînement. Pour évaluer la vraie capacité de généralisation, faites un split chronologique : train sur les données anciennes, test sur les données récentes.
Le vrai coût d'un dataset de fine-tuning en 2026
En 2026, l'entraînement LoRA sur Mistral 7B ou Llama 3 8B coûte entre 5 et 100 € de compute GPU sur RunPod, Lambda Labs ou Scaleway. Ce n'est pas le goulot d'étranglement.
Le vrai coût, c'est la préparation des données. Et c'est là que la plupart des budgets sont sous-estimés :
| Étape | Temps estimé (h) | Part du budget projet |
|---|---|---|
| Extraction et audit des sources brutes | 5–20 h | 10–15 % |
| Nettoyage, anonymisation, déduplication | 10–40 h | 15–20 % |
| Annotation manuelle (si données brutes) | 20–120 h | 25–40 % |
| Validation experte et corrections | 5–20 h | 10–15 % |
| Formatage JSONL et vérification du split | 2–5 h | 5 % |
| Total préparation données | 40–200 h | 60–80 % du budget |
Ces chiffres sont issus de projets accompagnés, pas de benchmarks théoriques. Sur un projet de 8 000 €, attendez-vous à 5 000 à 6 000 € de préparation de données et 2 000 à 3 000 € d'entraînement, évaluation et déploiement.
Limites et pièges à connaître avant de commencer
Les exemples contradictoires : pire que l'absence de données
Un dataset avec 10 % d'exemples contradictoires (même input, outputs incompatibles) génère un modèle instable. Sur les tâches de classification, il apprend à "hésiter" entre deux catégories et choisit presque aléatoirement sur les cas ambigus. Mieux vaut 400 exemples cohérents que 500 avec 100 contradictoires. La déduplication et la validation experte sont là pour ça.
La sur-représentation d'un sous-type
Si 70 % de vos exemples de style rédactionnel portent sur des emails commerciaux et 30 % sur des rapports techniques, le modèle fine-tuné sera excellent sur les emails et médiocre sur les rapports. L'équilibrage par sous-type est aussi important que l'équilibrage des classes.
L'annotation par un seul annotateur
Un seul expert qui annote tout le dataset introduit ses propres biais et angles morts. Dès que c'est possible, faites annoter chaque exemple par deux personnes indépendantes et mesurez le taux d'accord inter-annotateurs (Cohen's Kappa). Sous 0,7, votre tâche n'est probablement pas assez bien définie pour un fine-tuning fiable.
Utiliser un LLM pour générer les données sans validation humaine
La génération synthétique accélère l'annotation, mais un LLM générateur produit des exemples à son image : ses biais, ses erreurs factuelles, ses reformulations préférées. Sans validation humaine systématique, on entraîne le modèle cible sur les défauts du modèle générateur. La distillation fonctionne bien sur des tâches très définies (voir notre article sur la distillation de modèles LLM) ; sur du raisonnement ouvert, les risques sont élevés.
Pour aller plus loin
- Guide LoRA et QLoRA pour le fine-tuning LLM : les techniques qui rendent l'entraînement accessible (et pas seulement le dataset).
- Fine-tuner Mistral sur vos données métier : le guide dédié aux modèles Mistral, coûts et processus détaillés.
- Fine-tuning LLM en PME : quand ça vaut le coup : avant de préparer un dataset, s'assurer que le fine-tuning est la bonne réponse.
- Évaluer un modèle fine-tuné et éviter l'overfitting : ce qu'on fait avec le split de test une fois l'entraînement terminé.
- Les meilleures librairies de fine-tuning LLM : Unsloth, TRL, Axolotl, PEFT — comparatif terrain.
- Distillation de modèles LLM pour l'entreprise : générer un dataset synthétique depuis un grand modèle, les conditions pour que ça fonctionne.
- Notre service d'expert LLM et fine-tuning : cadrage, préparation des données, entraînement et déploiement sur infrastructure souveraine.
- Documentation TRL (HuggingFace) : la référence pour appliquer le bon chat template et lancer un SFTTrainer.
- LIMA : Less Is More for Alignment (Meta AI, 2023) : la démonstration empirique que 1 000 exemples qualitatifs surpassent des milliers d'exemples bruités.
Vous hésitez encore ?
Discutons de votre cas d'usage. 30 minutes pour cadrer votre dataset et savoir si votre projet de fine-tuning est mûr.
En résumé : le dataset décide du résultat, pas le GPU
Préparer un dataset de fine-tuning LLM sérieux, c'est 40 à 200 heures de travail pour quelques heures d'entraînement. Ce déséquilibre surprend toujours, et pourtant c'est ce qui différencie un projet qui tient de celui qui déçoit.
Les règles à retenir : respecter le chat template natif du modèle (la cause n°1 d'échec), viser la qualité plutôt que le volume, dédupliquer avant de faire le split, et faire valider chaque échantillon par un expert métier. Aucune librairie — ni Unsloth, ni Axolotl, ni TRL — ne rattrape un dataset incohérent.
Si vous démarrez de zéro, la question à poser en premier n'est pas "combien d'exemples" mais "est-ce que mes données internes sont exploitables telles quelles". C'est exactement ce qu'on évalue lors d'un cadrage avec nos clients, avant d'engager le moindre budget d'annotation. Notre service d'expert LLM et fine-tuning démarre toujours par cet audit des données.
