Fine-Tuning LLM — Adapter un modèle de langage à votre domaine métier

#Fine-tuning, RAG ou prompt engineering — Quand choisir quoi

La confusion entre ces trois approches coûte cher en 2026. Des DSI déploient du RAG sur des cas où le fine-tuning : à partir de 6 k€ qui auraient été résolus par un bon RAG en trois semaines. Voici le cadre de décision que nous appliquons chez Nehos depuis deux ans de production.

Prompt engineering uniquement : prototype en 48h pour valider la faisabilité fonctionnelle, tests A/B de formulations sur un LLM généraliste, cas d'usage simple et bien dans la distribution du pré-entraînement. Pas de production stable au-delà du pilote. La dépendance à la fenêtre de contexte est totale — un changement de modèle peut tout casser.

RAG en production : la connaissance est volumineuse (>500 documents), mise à jour fréquemment (wiki interne, docs produit, jurisprudence récente), et le modèle généraliste est déjà capable de raisonner sur ce type de contenu s'il y a accès. Le RAG est aussi la bonne approche quand le corpus ne peut pas être exposé en totalité dans les poids du modèle (raisons de confidentialité compartimentée, données actualisées en temps réel). Voir notre service RAG pour le détail technique.

Fine-tuning obligatoire dans quatre situations précises. (1) Le vocabulaire ou les conventions du domaine sont absents ou sous-représentés dans le pré-entraînement général : terminologie juridique spécifique à la common law française, jargon AFNOR/ISO d'un secteur industriel, nomenclature clinique d'une spécialité médicale, syntaxe d'un langage de programmation propriétaire. Aucun prompt engineering ni RAG ne substitue l'intégration de ces patterns dans les poids. (2) Le format de sortie doit être rigoureusement cohérent sur des milliers d'appels : clauses contractuelles normées, résumés exécutifs de format fixe, emails administratifs avec champs obligatoires, requêtes SQL sur un dialecte maison. Le fine-tuning stabilise le comportement de sortie là où le prompt engineering introduit de la variance. (3) La latence est une contrainte dure : un Mistral 7B fine-tuné répond 3x à 6x plus vite qu'un GPT-4 avec un contexte RAG long, car il n'a pas besoin du contexte pour compenser son ignorance du domaine. (4) Les données ne peuvent pas transiter à l'inférence vers l'extérieur : le fine-tuning grave la connaissance dans les poids, qui restent sur vos serveurs — aucune donnée confidentielle n'est exposée à chaque appel API comme avec le RAG.

Le cas hybride — fine-tuning ET RAG sur le même LLM — est possible et souvent optimal sur les grands domaines métier : le fine-tuning gère le style, le vocabulaire et le format de sortie, le RAG gère les faits précis et les références changeantes. Voir la section FAQ pour le détail de cette architecture.

#Les techniques de fine-tuning en 2026 — LoRA, QLoRA, DPO, RLHF

Cinq techniques constituent le répertoire standard en production industrielle. Les connaître évite de payer pour la mauvaise ou de sous-exploiter la bonne.

#LoRA — Low-Rank Adaptation

Publié par Hu et al. en 2022 (voir article fondateur LoRA (Hu et al. 2022)), LoRA est aujourd'hui la technique de référence pour adapter un LLM sur un corpus métier sans modifier l'intégralité des poids. Le principe : on gèle les poids originaux du modèle, et on entraîne uniquement deux matrices de faible rang (A et B) qui représentent le delta d'adaptation. En pratique, LoRA réduit de 10 000 à 100 000x le nombre de paramètres entraînables par rapport à un full fine-tuning, ce qui permet d'entraîner Mistral 7B en LoRA sur un seul GPU A100 80 GB en quelques heures. Paramètres clés : rang r (8, 16, 32 ou 64 selon la complexité du domaine), alpha (généralement r x 2), cible des couches (q_proj, v_proj, k_proj, o_proj minimum). LoRA est notre technique par défaut sur >80 % des projets.

#QLoRA — Quantized LoRA

Publié par Dettmers et al. en 2023 (voir QLoRA (Dettmers et al. 2023)), QLoRA combine quantification 4-bit du modèle de base (NF4 + double quantification) avec l'entraînement LoRA des adaptateurs en bf16. Résultat : Mistral 7B entraînable sur un GPU A100 40 GB (vs 80 GB pour LoRA classique), Mistral Large (24B) entraînable sur deux A100 80 GB. Compromis : léger overhead de calcul (+15 à +25 % de temps d'entraînement vs LoRA pur), performances généralement équivalentes ou légèrement inférieures (-1 à -3 % sur les métriques d'évaluation). Nous utilisons QLoRA quand le budget GPU est contraint ou pour les runs exploratoires avant d'engager un run LoRA complet sur H100.

#SFT — Supervised Fine-Tuning

L'instruction tuning supervisé classique : le modèle apprend à partir d'exemples formatés en paires instruction/réponse (format Alpaca, ShareGPT, ou ChatML selon le modèle cible). C'est la première étape obligatoire de tout fine-tuning métier. Dataset minimum viables : 1 000 exemples pour un ajustement de style ou vocabulaire, 5 000-15 000 pour une spécialisation métier ciblée, 30 000-100 000 pour un fine-tuning multi-tâche robuste. La qualité du dataset prime absolument sur le volume — 1 000 exemples de haute qualité annotés par des experts domaine surpassent systématiquement 20 000 exemples générés automatiquement sans filtrage.

#DPO — Direct Preference Optimization

DPO (Rafailov et al. 2023) est une alternative plus efficace au RLHF classique pour aligner les sorties sur des préférences humaines. Au lieu d'entraîner un reward model séparé, DPO exploite des paires de réponses annotées (préférée / rejetée) pour modifier directement les poids du LLM via une perte de classification binaire. Coût en données : 500 à 5 000 paires (préféré, rejeté) suffisent pour un alignement significatif. Nous utilisons DPO après un SFT initial sur tous les projets où la cohérence du ton, du niveau de formalisme ou de la structure des sorties est critique (documentation industrielle, courriers juridiques, rapports financiers normés).

#RLHF — Reinforcement Learning from Human Feedback

RLHF au sens complet (reward model + PPO) est réservé aux projets à fort volume de feedback humain (>10 000 annotations préférence) et aux cas d'usage à très haute valeur (assistant médical, assistant légal déployé à grande échelle). Nous le proposons en option sur les projets >211 k€ HT. Pour la majorité des projets ETI, DPO remplace avantageusement RLHF avec 10x moins de données de préférence nécessaires.

#Stack technique Nehos — Mistral sur OVHcloud GPU cluster

Notre infrastructure de fine-tuning est standardisée et hébergée exclusivement sur OVHcloud Bare Metal France pour garantir la souveraineté des données d'entraînement.

Modèles de base supportés : Mistral 7B Instruct v0.3 (excellent ratio performance/coût pour les domaines textuel), Mistral Small 3.1 (22B, recommandé pour les tâches multi-étapes complexes), Mistral Medium 3 (domaines très spécialisés, budget >à partir de 19 k€ HT), Llama 3.1 8B / 70B (alternative open source quand la licence Mistral pose problème), Qwen2.5 7B/14B (excellent sur les tâches code et données structurées). Nous déconseillons le fine-tuning de GPT-4 / Claude / Gemini via API : vous n'avez pas accès aux poids, le modèle reste chez OpenAI/Anthropic/Google, et le coût d'inférence post-fine-tuning reste celui de l'API publique.

Infrastructure GPU : OVHcloud Bare Metal GPU — serveurs H100 80 GB NVLink (run LoRA complet sur Mistral Large en <12h) ou A100 80 GB PCIe (run QLoRA Mistral 7B en <3h). Tout le trafic de données reste dans les datacenters OVHcloud France (DC-GRA-7, DC-RBX-8), aucun transfert hors UE. Voir notre service cloud souverain OVHcloud.

Framework fine-tuning : Axolotl (packaging LLM training simplifié, support natif LoRA/QLoRA/DPO) ou HuggingFace TRL (Transformer Reinforcement Learning) selon la complexité des expériences. Weights & Biases auto-hébergé (W&B Local) pour le tracking des runs, visualisation des courbes de loss et validation, comparaison d'expériences.

Post-entraînement et serving : quantification automatisée GGUF (llama.cpp), AWQ ou GPTQ selon la cible déploiement. vLLM pour le serving haute performance (PagedAttention, continuous batching) sur GPU client ou OVHcloud. Model registry privé (MinIO S3-compatible hébergé OVHcloud) avec versioning et rollback. Monitoring de drift via métriques de perplexité et taux de dégradation sur jeu de validation.

#Préparation des données — La phase clé qui détermine 80 % du succès

Neuf projets sur dix que nous reprenons après un premier fine-tuning raté échouent à cause des données, pas du modèle. La préparation du dataset représente 40 à 60 % du temps projet total — et c'est incompressible.

Pipeline Nehos de curation en six étapes. (1) Collecte et audit du corpus brut : inventaire de toutes les sources disponibles (documents internes, emails, contrats, rapports, tickets support, manuels techniques), évaluation de la qualité, du volume et de la représentativité de chaque source. (2) Nettoyage : suppression des doublons stricts et quasi-doublons (MinHash LSH sur shingles 5-grammes, seuil Jaccard >0,85), retrait des artefacts de mise en page (tableaux PDF malformés, en-têtes/pieds de page répétitifs), normalisation de l'encodage et de la ponctuation. (3) Formatage en paires instruction/réponse : le format le plus critique. Chaque exemple d'entraînement doit être structuré en (system prompt, instruction, output) — souvent le poste de travail le plus chronophage car il nécessite l'intervention d'experts domaine pour valider la qualité des paires. (4) Filtrage qualité : un filtre de qualité automatisé (perplexité du modèle de base, longueur, ratio signal/bruit) élimine 15 à 35 % des exemples en moyenne — c'est un coût accepté pour améliorer la qualité finale. (5) Détection et correction du déséquilibre : surreprésentation d'une tâche ou d'un type de document biaise le modèle vers ce cas au détriment des autres — we rééquilibrons par sous-échantillonnage ou data augmentation ciblée. (6) Constitution du jeu d'évaluation : 10 à 20 % des données, strictement isolé avant tout entraînement, annoté par des experts domaine indépendants de ceux qui ont constitué le dataset d'entraînement.

Volumes minimum viables par technique. LoRA style/vocabulaire : 1 000 exemples minimum, idéal 3 000-8 000. LoRA spécialisation métier ciblée (une tâche, un domaine) : 5 000-20 000 exemples. LoRA multi-tâche (plusieurs types de sorties attendues) : 20 000-50 000 exemples. DPO : 500-5 000 paires (préféré, rejeté), annotées manuellement par des experts. SFT + DPO combinés : budget données x1,5 minimum.

Données confidentielles : pseudonymisation systématique avant tout entraînement (anonymisation des personnes, entités nommées sensibles, données financières identifiantes), contrôle d'accès strict aux serveurs de fine-tuning, suppression des données brutes post-entraînement et livraison des seuls poids du modèle au client. Pour les secteurs régulés (santé, finance, juridique), DPIA spécifique au périmètre données d'entraînement. Voir notre traitement de la souveraineté numérique.

#6 domaines métier où le fine-tuning donne un avantage mesurable

#1. Juridique — Droit des affaires, contrats, jurisprudence française

Le domaine juridique français présente les caractéristiques idéales pour le fine-tuning : vocabulaire très précis et codifié (termes techniques du droit civil, commercial, social, administratif français), style de rédaction extrêmement normé (clauses contractuelles, actes d'huissier, conclusions d'avocats, délibérations), jurisprudence française absente ou sous-représentée dans les modèles entraînés sur corpus anglophone. Un cabinet d'avocats spécialisé droit des affaires avec 15 000 contrats et mémos internes annotés peut obtenir un modèle qui génère des clauses contractuelles conformes au droit français en un seul passage, avec un taux d'erreur terminologique <5 % vs 28-35 % pour GPT-4 non spécialisé. Voir notre cas client ci-dessous.

#2. Finance — Rapports financiers, réglementations sectorielles

Les directions financières manipulent un vocabulaire très spécifique (normes IFRS et PCGF, réglementations AMF, terminologie de consolidation, jargon comptable des commissaires aux comptes) et des formats de sortie rigides (tableaux de flux, notes annexes normées, rapports de gestion). Un LLM généraliste hallucine fréquemment sur les montants, les ratios et les références réglementaires précises — le fine-tuning sur corpus IFRS/PCGF réduit ce phénomène de 70 à 85 % selon nos mesures. Contexte réglementaire spécifique : un LLM utilisé pour l'aide à la rédaction de documents financiers réglementés (prospectus AMF, rapport annuel coté) doit faire l'objet d'une qualification au regard du règlement DORA et de l'article 9 de la directive MiFID II sur les communications promotionnelles.

#3. Santé — Terminologie médicale française, protocoles cliniques

La terminologie médicale française (CIM-11 en français, CCAM, nomenclatures spécialité par spécialité, protocoles HAS) est massivement sous-représentée dans les LLM open source entraînés sur Common Crawl anglophone. Un LLM spécialisé sur les comptes-rendus d'hospitalisation, les ordonnances et les protocoles cliniques d'un établissement réduit les erreurs de retranscription terminologique de 80 % vs modèle généraliste. Contrainte critique : tout fine-tuning sur données de santé nécessite une hébergement HDS (Hébergeur de Données de Santé) certifié — OVHcloud dispose de la certification HDS, ce qui est non-négociable dans notre stack souveraine. Voir notre service agents IA Nehos pour le vertical santé.

#4. Industrie — Documentation technique, manuels, normes ISO/AFNOR

Les ETI industrielles accumulent des dizaines de milliers de pages de documentation technique (manuels maintenance, schémas, notes techniques, non-conformités, FMEA, cahiers des charges fournisseurs) dans un jargon spécifique à leur secteur (aéronautique, automobile, agroalimentaire, chimie). Un assistant LLM spécialisé sur ce corpus réduit le temps de recherche des techniciens de 40 à 65 % sur les procédures de maintenance et les FAQs techniques. Spécificité : les documents techniques industriels contiennent souvent des tableaux, des schémas et des formats numériques précis — notre pipeline inclut une étape de conversion et de structuration spécifique (PDF/CAD to text avec normalisation des unités et des formats numériques).

#5. Service public — Collectivités, langage administratif

Le langage administratif français (code général des collectivités territoriales, circulaires préfectorales, délibérations de conseil municipal, marchés publics DUME) est un corpus dense et très spécifique, absent des LLM grand public. Une collectivité territoriale qui fine-tune Mistral sur ses délibérations passées, ses arrêtés types et ses courriers standardisés obtient un assistant rédactionnel qui réduit par 3 le temps de rédaction des courriers administratifs standards, avec un taux de relecture humaine nécessaire réduit de 80 %. Contrainte : les données des collectivités sont publiques (délibérations publiées au RCBE) mais les courriers aux administrés contiennent des données personnelles — pseudonymisation systématique avant entraînement. Voir agents IA Nehos pour le vertical secteur public.

#6. Code source — Assistant développeur sur codebase propriétaire

Fine-tuner un LLM (Mistral ou Qwen2.5-Coder) sur la codebase propriétaire d'une entreprise — frameworks internes, patterns de code spécifiques, conventions de nommage, documentation API propriétaire — produit un assistant développeur qui comprend les patterns maison, suggère des implémentations cohérentes avec l'architecture existante et réduit les erreurs d'intégration de 50 à 75 %. À distinguer du RAG sur codebase (GitHub Copilot Workspace, Cursor) qui est adapté aux codebases larges et évolutives : le fine-tuning code est préférable quand les conventions sont stables, le framework est maison, et la latence de l'assistant est critique (environnement CI/CD, IDE basse latence).

#Évaluation du modèle fine-tuné — Métriques standards Nehos

Un fine-tuning sans évaluation rigoureuse est un fine-tuning qui finira en production avec des régressions invisibles. Nous imposons un protocole d'évaluation en cinq dimensions sur tous nos projets.

BLEU (Bilingual Evaluation Understudy) : mesure le recouvrement n-gramme entre la sortie générée et la référence humaine. BLEU-4 >0,45 est notre seuil de qualification minimale pour les tâches de génération de texte normé (clauses contractuelles, descriptions produit formatées). Limite : BLEU pénalise les reformulations sémantiquement correctes — nous ne l'utilisons jamais seul.

ROUGE-L : recouvrement de la plus longue sous-séquence commune. Particulièrement adapté aux tâches de résumé et d'extraction. ROUGE-L >0,55 pour les résumés métier. Complète BLEU en capturant la cohérence d'ordre.

BERTScore : cosine similarity entre embeddings contextuels de la sortie et de la référence. Robuste aux reformulations, penalise les hallucinations sémantiques. BERTScore F1 >0,88 sur notre jeu de test domaine est le critère de passage en production. C'est la métrique la plus discriminante pour les domaines à vocabulaire dense.

Taux d'hallucination sur test set domaine : nous construisons un jeu de 200-500 questions factuelles avec réponse de référence validée par un expert domaine, et mesurons le pourcentage de sorties factuellement incorrectes. Comparaison systématique : modèle de base vs modèle fine-tuné vs GPT-4 Turbo. Objectif typique : réduction du taux d'hallucination de 70-90 % vs modèle de base sur le domaine.

Évaluation humaine — Preferred Response Rate : sur un échantillon de 200-500 paires (sortie fine-tuned vs sortie modèle de base), des annotateurs experts domaine choisissent la meilleure réponse en aveugle. Un preferred response rate >65 % en faveur du modèle fine-tuné est notre critère de validation finale. C'est la seule métrique qui capte les dimensions qualitatives (fluidité, pertinence métier, respect des conventions de style) que les métriques automatiques ne voient pas.

#Sécurité et RGPD — Données d'entraînement propriétaires

Le fine-tuning avec des données propriétaires soulève des questions de sécurité spécifiques que les approches API grand public ne permettent pas de résoudre. Voici notre cadre systématique.

Localisation des données : toutes les données d'entraînement restent sur l'infrastructure OVHcloud France (datacenter GRA ou RBX selon la criticité). Aucun transfert vers HuggingFace Inference API, Together AI, AWS SageMaker US ou Azure ML US. Les scripts d'entraînement sont exécutés localement sur les serveurs GPU dédiés, sans exfiltration de données d'entraînement vers des services cloud tiers. Voir glossaire LLM souverain.

Propriété des poids : les poids du modèle fine-tuné sont la propriété exclusive du client, transférés par livraison sécurisée (SFTP chiffré ou remise physique sur support chiffré pour les domaines très sensibles). Nehos ne conserve aucune copie après livraison contractuelle, sauf accord explicite du client pour MCO.

Suppression des données post-entraînement : le dataset d'entraînement brut et les checkpoints intermédiaires sont supprimés selon un protocole de suppression sécurisée (DOD 5220.22-M, 3 passes) dans les 30 jours suivant la livraison, avec certificat de destruction fourni.

DPIA pour données sensibles : tout fine-tuning sur des données à caractère personnel non entièrement pseudonymisées déclenche une DPIA (analyse d'impact relative à la protection des données, article 35 RGPD). La DPIA couvre le risque de mémorisation de données personnelles dans les poids du modèle (phénomène documenté : un LLM fine-tuné peut mémoriser et restituer des données d'entraînement non pseudonymisées — voir les travaux de Carlini et al. sur la memorization des LLM). Mesures de mitigation systématiques : pseudonymisation avant fine-tuning, differential privacy optionnel (DP-SGD via HuggingFace PEFT), red-teaming d'extraction post-fine-tuning.

AI Act — modèle comme composant d'un système à risque : un LLM fine-tuné intégré dans un système de prise de décision (recrutement, scoring crédit, diagnostic médical) peut faire basculer ce système dans la catégorie haut risque Annexe III. Nous conduisons systématiquement une qualification AI Act du cas d'usage cible avant le fine-tuning, pour dimensionner correctement les obligations documentaires (Annexe IV) et les mesures de supervision humaine. Voir notre service audit de faisabilité.

#Méthodologie — De la collecte de données à la mise en production

Phase 1 — Audit et curation des données (2 à 4 semaines, à partir de 32 000 € HT)

Inventaire complet du corpus disponible (types, volumes, qualité, formats), nettoyage et dédoublonnage automatisé, formatage des paires instruction/réponse avec validation expert domaine (10-30 % du corpus validé manuellement), analyse du déséquilibre dataset et plan de rééquilibrage, construction du jeu d'évaluation isolé (10-20 % des données), DPIA si données personnelles présentes. Livrable : dataset d'entraînement qualifié + jeu d'évaluation annoté + rapport audit qualité données.

Phase 2 — fine-tuning : à partir de 6 k€ HT selon volume GPU)

Setup de l'environnement Axolotl/TRL sur cluster OVHcloud, configuration de 3 à 8 runs LoRA/QLoRA avec variation des hyperparamètres (learning rate 1e-5 à 3e-4, epochs 1 à 5, LoRA rank 8/16/32/64), tracking Weights & Biases complet, sélection du meilleur checkpoint sur courbe de validation, run DPO optionnel si annotations préférence disponibles. Livrable : modèle fine-tuné sélectionné + rapport d'expériences W&B + comparaison hyperparamètres.

Phase 3 — Évaluation et qualification (1 semaine, incluse dans le forfait)

Évaluation BLEU/ROUGE-L/BERTScore sur jeu de test, mesure du taux d'hallucination sur 200-500 questions factuelles, évaluation humaine preferred response rate sur 200-500 paires (experts domaine client), comparaison vs modèle de base et vs GPT-4 Turbo, red-teaming d'extraction de données sensibles. Livrable : rapport d'évaluation complet avec métriques et recommandation go/no-go production.

Phase 4 — Déploiement et monitoring (1 à 2 semaines, à partir de 1 113 € HT)

Quantification GGUF/AWQ/GPTQ selon cible matérielle, déploiement vLLM sur infrastructure client ou OVHcloud, configuration du monitoring de drift (perplexité, métriques métier via Prometheus/Grafana), documentation technique complète (architecture, paramètres d'entraînement, procédure de re-fine-tuning), formation des équipes MLOps client. MCO optionnel : à partir de 1 746 € HT/mois selon SLA et fréquence des re-fine-tunings.

#ROI mesurable — Cas cabinet d'avocats spécialisation droit des affaires

Cabinet d'avocats français spécialisé droit des affaires, 35 associés, gérant 2 000 à 3 000 dossiers actifs par an (anonymisé NDA). Problème : les modèles généralistes disponibles (GPT-4, Claude) produisent des clauses contractuelles avec un taux d'erreur terminologique de 28-35 % sur le droit des affaires français — trop élevé pour toute utilisation sans relecture ligne à ligne par un associé, ce qui annulait l'essentiel du gain de productivité.

Mission Nehos sur 10 semaines : curation d'un corpus de 18 000 contrats et mémos internes sur 15 ans d'archives (avec pseudonymisation complète des parties), formatage en 14 500 paires instruction/réponse (clause par type de contrat : SPA, SHA, NDA, contrats commerciaux, baux commerciaux, protocoles d'accord), fine-tuning LoRA sur Mistral Medium 3 avec 3 runs comparatifs, DPO sur 2 200 paires annotées par trois associés seniors, déploiement vLLM sur serveur dédié OVHcloud France.

Résultats mesurés à 6 mois : précision terminologique juridique 94 % vs 71 % pour Mistral Medium 3 de base vs 67 % pour GPT-4 Turbo non spécialisé (évaluation humaine sur 500 clauses type). Latence p95 : 320 ms vs 1 850 ms pour GPT-4 via API. Taux de relecture complète par un associé : réduit de 100 % à 22 % des clauses générées (les 78 % restants sont validés par un collaborateur junior). Gain de productivité mesuré : +2,8 heures collaborateur économisées par dossier de rédaction contractuelle, soit un ROI projeté sur 18 mois de x4,2 sur l'investissement total.

Investissement total projet :82 12 800 € HT (audit + curation + fine-tuning + déploiement). MCO mensuel : à partir de 800 € HT. Voir cas cabinet juridique fine-tuning droit des affaires.

#Tarification — 8,5 k€ HT

Trois fourchettes selon la complexité du projet.

Tier 1 — fine-tuning : à partir de 6 k€ HT, 8-12 semaines) : LoRA sur Mistral 7B ou Llama 3.1 8B, corpus 1 000-15 000 exemples, un domaine métier ciblé, une tâche principale (génération, résumé ou classification). Déploiement sur un seul endpoint vLLM. Typiquement : assistant rédactionnel spécialisé (emails, courriers, rapports types), classifier thématique métier, extracteur d'entités nommées domaine.

Tier 2 — fine-tuning : à partir de 6 k€ HT, 12-18 semaines) : LoRA ou QLoRA sur Mistral Small 3.1 ou Mistral Medium 3, corpus 15 000-50 000 exemples, plusieurs tâches ou plusieurs types de sorties, DPO sur préférences humaines, évaluation rigoureuse BLEU/ROUGE/BERTScore + évaluation humaine, déploiement multi-instances avec load balancing. Typiquement : assistant juridique ou financier, LLM documentation technique industrielle, assistant code sur codebase propriétaire.

Tier 3 — fine-tuning : à partir de 6 k€ HT, 16-24 semaines) : SFT + DPO + RLHF léger sur Mistral Large ou Llama 3.1 70B, corpus 50 000+ exemples haute qualité annotés par des experts domaine, évaluation humaine complète (preferred response rate sur 500+ paires), quantification et optimisation serving, monitoring avancé de drift, formation équipe MLOps client, documentation technique complète. Typiquement : LLM cœur d'un produit SaaS B2B, assistant médical sur terminologie spécialisée, LLM multi-tâche pour un grand cabinet ou une direction juridique de grand groupe.

Estimation sur-mesure en 30 minutes : [Réserver un RDV fine-tuning LLM](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe Premier appel gratuit, NDA disponible sur demande, estimation de faisabilité et chiffrage indicatif lors du premier RDV.