Développement de modèles et fine-tuning

La plupart des projets de fine-tuning échouent avant même le début de l'entraînement

La facture GPU n'est pas la partie coûteuse du fine-tuning en entreprise. Un modèle de 7 milliards de paramètres se fine-tune sur un seul A100 pour $100–$400 en compute ; un modèle de 70 milliards coûte $4,000–$9,750 par cycle d'entraînement. Ce qui tue les projets, c'est tout ce qui entoure la boucle d'entraînement : constituer des milliers d'exemples spécifiques au domaine, empêcher le modèle d'oublier ce qu'il sait déjà, valider que l'alignement de sécurité a survécu à l'entraînement, quantifier pour le service en production et construire le pipeline de surveillance qui détecte la dérive.

Gartner prévoit que d'ici 2027, les organisations utiliseront des modèles d'IA petits et spécialisés trois fois plus que les LLM généralistes. Ce basculement est déjà en cours : 68 % des entreprises qui ont fine-tuné des modèles en 2024 ont signalé jusqu'à 3x d'amélioration de la précision des tâches. Mais c'est dans l'écart entre une expérience sur notebook et un déploiement en production que la plupart des projets s'enlisent. Notre approche consiste à concevoir l'ensemble du pipeline, pas seulement la boucle d'entraînement (une discipline détaillée dans notre recherche sur l'ingénierie de systèmes au-delà des wrappers d'API).

Quand le fine-tuning est le bon choix (et quand il ne l'est pas)

Le prompt engineering prend quelques heures. Le RAG prend une à quatre semaines. Le fine-tuning prend deux à huit semaines, y compris la création du jeu de données, l'entraînement, les tests de sécurité et le durcissement pour la production. Nous commençons chaque mission en évaluant si le fine-tuning est réellement nécessaire.

Faites du fine-tuning quand :

• le modèle a besoin d'un nouveau comportement ou de formats de sortie que le prompting ne peut pas produire de façon fiable ;
• votre domaine présente des schémas de raisonnement spécialisés que les modèles génériques gèrent de manière incohérente ;
• vous avez besoin d'une inférence économique à grande échelle — un modèle 7B fine-tuné à $0.20/M tokens remplace un 70B à $2/M ;
• vous construisez des systèmes agentiques où la fiabilité des appels d'outils est cruciale — des SLM fine-tunés ont amélioré le taux de réussite des appels d'outils de 10 % à 79 % dans des benchmarks (voir une démo fonctionnelle d'un tel système d'ordonnancement agentique).

Ne faites pas de fine-tuning quand :

• le problème est la récupération de connaissances (utilisez le RAG) ;
• le jeu de données compte moins de 1 000 exemples par tâche ;
• le prompt engineering atteint déjà une précision acceptable ;
• le modèle de base évolue plus vite que votre cadence de réentraînement.

Quand le RAG résout le problème et que le fine-tuning ne ferait que gaspiller du budget, notre approche consiste à le dire avant de cadrer tout entraînement plutôt que de vendre un projet dont vous n'avez pas besoin. Cette honnêteté est intégrée à notre façon de cadrer une mission.

Le choix du framework compte

Le paysage de 2026 s'est consolidé autour d'outils distincts, chacun résolvant un problème différent.

Nous choisissons en fonction de l'échelle de votre entraînement, de l'architecture du modèle et de vos objectifs. La plupart des déploiements en production en utilisent plusieurs : Axolotl pour le fine-tuning supervisé, TRL pour l'optimisation des préférences et Unsloth pour le prototypage rapide.

L'alignement de sécurité ne survit pas à un fine-tuning naïf

Une recherche présentée à EMNLP 2024 a démontré que le fine-tuning de LLM sur de nouvelles connaissances factuelles augmente la propension aux hallucinations. Par ailleurs, des chercheurs de Princeton, Stanford, Virginia Tech et IBM ont montré que le fine-tuning standard permettait aux modèles de contourner entièrement leur entraînement de sécurité. Des travaux présentés à ICLR 2026 ont depuis montré qu'un réglage soigneux des hyperparamètres atténue ces risques, mais les configurations par défaut des frameworks sont livrées sans protection.

Le mécanisme : des mises à jour agressives des paramètres dans les couches supérieures écrasent les caractéristiques responsables de la sécurité. Le choix du rang LoRA est critique — des adaptateurs de rang élevé sur les couches d'attention peuvent déstabiliser les circuits de refus, et la configuration sûre dépend de l'architecture spécifique du modèle et des données de la tâche.

Notre approche consiste à mettre en œuvre des pipelines préservant la sécurité (nourris par notre recherche sur la gouvernance de la sécurité de l'IA dans l'espace latent) :

• un LoRA sélectif protégeant les circuits critiques ;
• des benchmarks de sécurité réservés à chaque point de contrôle ;
• un arrêt précoce sur des métriques composites équilibrant la performance des tâches et la préservation des capacités ;
• une surveillance continue de la dégradation de l'alignement tout au long de l'entraînement.

La curation des données est le véritable goulot d'étranglement

Les heures GPU sont un poste budgétaire. La curation des données, c'est le projet :

• faire annoter par des experts métier 5 000 à 50 000 exemples de haute qualité ;
• résoudre les désaccords d'annotation à l'aide de métriques d'accord inter-annotateurs ;
• exécuter une déduplication MinHash/LSH ;
• vérifier la contamination par rapport aux jeux d'évaluation ;
• documenter la provenance avec des fiches de données.

Le RLAIF (en utilisant GPT-4 comme annotateur) réduit le coût des données de préférence mais introduit un biais du modèle enseignant. Les données synthétiques via la distillation enseignant-élève amorcent les jeux d'entraînement, bien que la qualité soit plafonnée par les capacités du modèle enseignant.

Une mission est cadrée pour couvrir la conception du pipeline de données, les flux d'annotation, la validation de la qualité et la documentation propre aux secteurs réglementés : validation logicielle FDA, rapports de validation de modèles financiers et documentation technique de l'EU AI Act avec des fiches de modèle conformes aux exigences de l'article 11(1).

De l'entraînement à la production

Quantification

Fine-tunez en FP16, fusionnez les adaptateurs, puis quantifiez. AWQ INT4 avec le kernel Marlin offre le meilleur rapport débit/qualité pour le service vLLM (741 tok/s). GPTQ s'intègre à TensorRT-LLM et TGI. GGUF est natif pour llama.cpp et Ollama. Nous adaptons la quantification à votre stack de service.

Fournisseur vs open source

OpenAI facture ~$3/M tokens pour fine-tuner GPT-4.1. Le Small 3.1 fine-tuné de Mistral à $0.20/M égale leur Large 3 à $2/M sur des tâches étroites. Anthropic ne propose pas de fine-tuning public. Les API des fournisseurs conviennent à une itération rapide lorsque la gouvernance des données autorise une infrastructure tierce.

Les modèles open source (Llama 3, Mistral, Qwen) avec un entraînement auto-hébergé sont le bon choix lorsque les données doivent rester sur votre infrastructure ou que des exigences réglementaires l'imposent. La plupart des entreprises utilisent les deux.

Surveillance et réentraînement

Les modèles en production dérivent. Notre approche consiste à construire des pipelines qui suivent la qualité des prédictions, détectent la dérive des données et des concepts, et déclenchent le réentraînement lorsque des seuils sont franchis. MLflow ou Weights and Biases gèrent le suivi des expériences, tandis que les registres de modèles assurent une traçabilité complète, des données d'entraînement à l'artefact déployé.

Alignement post-entraînement : au-delà du SFT

Le standard de production de 2026 est un pipeline modulaire : SFT pour le suivi des instructions, DPO ou SimPO pour l'alignement sur les préférences, et GRPO pour le raisonnement.

Le DPO a supplanté le RLHF PPO en éliminant le modèle de récompense. SimPO a supprimé le modèle de référence tout en surpassant le DPO de 6,4 points sur AlpacaEval 2. GRPO (issu de DeepSeek R1) utilise des récompenses vérifiables pour entraîner le raisonnement par du RL pur (une technique que nous explorons dans notre recherche sur l'apprentissage par renforcement sur graphes), avec une auto-réflexion et une vérification émergentes. Nous les mettons en œuvre avec TRL, le framework qui maîtrise bien les dynamiques d'entraînement en RL.

Ce que nous livrons

Chaque mission est cadrée pour produire un système déployable :

• le modèle fine-tuné avec des fiches de modèle complètes ;
• le pipeline d'entraînement sous forme de code reproductible avec suivi des expériences ;
• une suite d'évaluation comparant au modèle de base et à des alternatives sur la précision, la latence, la robustesse et la calibration ;
• l'artefact de déploiement quantifié avec une configuration de service optimisée ;
• des tableaux de bord de surveillance avec détection de dérive et déclencheurs de réentraînement ;
• pour les secteurs réglementés, une documentation de validation propre au secteur (EU AI Act, FDA, validation de modèles financiers).

La mission produit également une évaluation honnête : si le fine-tuning était la bonne approche, ce que le modèle ne peut pas faire et où se situe le plafond de performance. Des limites documentées d'emblée font économiser plus d'argent que des projections optimistes.