Entraînement LLM : étapes clés du prétraining au post-training

Table des matières :

De quoi parle-t-on quand on dit « entraînement LLM »
Étape 0: cadrer le besoin, les données et le niveau de risque
Pré-entraînement: ce que cela implique vraiment (et pourquoi c’est rarement pertinent)
Domain adaptation et instruction tuning: spécialiser sans repartir de zéro
Post-entraînement d’alignement: préférences, sécurité et comportement en production
Mesurer la qualité: jeux de tests, métriques et garde-fous
Industrialiser le cycle de vie, et savoir quand s’arrêter d’entraîner

De quoi parle-t-on quand on dit « entraînement LLM »

Dans une entreprise, « entraînement LLM » recouvre en réalité plusieurs étapes très différentes, avec des coûts, des délais et des risques qui n’ont rien à voir. Le pré-entraînement (prétraining) consiste à entraîner un modèle de langage sur d’énormes corpus généralistes pour lui apprendre la grammaire, le raisonnement statistique et une partie des connaissances du monde. Le post-entraînement regroupe ensuite les méthodes qui transforment ce modèle « brut » en assistant utile et plus sûr (instruction tuning, alignement, préférences, garde-fous).

Entre les deux, on trouve des variantes souvent plus pertinentes pour les organisations :

Domain adaptation (continued pretraining / DAPT) : on continue l’apprentissage sur un corpus métier pour améliorer le vocabulaire, les acronymes, et les tournures spécifiques (sans forcément « apprendre des procédures »).
Fine-tuning (ajustement) : on spécialise le modèle sur des exemples question → réponse (ou entrée → sortie) et des contraintes de format.
LoRA (Low-Rank Adaptation) : une technique de fine-tuning où l’on entraîne de petites matrices d’adaptation plutôt que tous les poids (plus léger, plus simple à versionner).
QLoRA : une variante où le modèle est quantifié (poids compressés) afin de réduire la mémoire nécessaire, ce qui rend l’entraînement plus accessible.

Point clé côté métier : entraîner n’est pas toujours la bonne réponse. Si votre problème est que le modèle « ne connaît pas » vos procédures, votre catalogue, votre base documentaire ou vos tickets récents, le bon premier réflexe est souvent un RAG (Retrieval-Augmented Generation). On relie un LLM existant à vos documents via de la recherche sémantique ; le LLM génère alors à partir de sources internes, ce qui réduit les réponses génériques, améliore la traçabilité et facilite l’audit (« pourquoi a-t-il répondu ça ? »).

Un repère simple pour décider :

RAG si la connaissance change souvent (produits, politiques, incidentologie) et si vous devez citer ou justifier.
Fine-tuning / LoRA si vous devez standardiser le style, suivre des consignes, produire un format strict (ex. champs structurés, résumé normé), ou absorber du jargon récurrent.
Post-entraînement d’alignement si le problème est surtout comportemental (refus, prudence, demande de précisions, sécurité), indépendamment des connaissances.

Pour choisir entre RAG, LoRA et QLoRA selon l’usage, vous pouvez vous appuyer sur cet article : Fine-tuning LLM : choisir RAG, LoRA ou QLoRA selon l’usage.

Étape 0: cadrer le besoin, les données et le niveau de risque

On part du besoin, pas de la technologie. Formalisez d’abord la tâche à automatiser : répondre à des tickets, rédiger des clauses, expliquer une panne, qualifier un lead, etc. Définissez la sortie attendue (format, langue, tonalité), la tolérance à l’erreur et les contraintes de délai. Un assistant « brouillon » pour aider un expert n’a pas la même exigence qu’un agent qui répond directement au client. Cette clarification évite de sur-investir dans l’entraînement alors qu’un meilleur cadrage d’usage suffirait.

Un outil très opérationnel consiste à écrire, avant toute expérimentation, une fiche d’usage d’une page :

Utilisateur cible (support N2, juriste, commercial, client final)
Décision prise sur la base de la réponse (information, diagnostic, action automatique)
Données consultées (docs internes, tickets, CRM, emails)
Sortie attendue (texte libre, JSON, checklist, plan, tableau)
Mode de contrôle (validation humaine obligatoire, échantillonnage, journalisation)
Tolérance à l’erreur (ex. « une erreur mineure acceptable si non critique », vs « zéro erreur sur les montants/clauses »)

Ensuite, passez par une étape non négociable : classification et cartographie des données. Avant tout entraînement (et même avant un POC sérieux), identifiez ce qui est secret (R&D, juridique), ce qui contient des données personnelles, et ce qui peut sortir du SI. En pratique, cela se fait application par application, flux par flux, et avec des règles d’accès. Pour une méthode opérationnelle, voir : Classification des données : cartographier flux sensibles par application et réseau.

En contexte français / UE, gardez un point très concret en tête : si des données personnelles sont traitées, il faut un cadre conforme au RGPD (base légale, minimisation, sécurité, sous-traitance, transferts, etc.). Le texte officiel est accessible sur EUR-Lex (RGPD). Ce n’est pas « juridique pour juristes » : ça se traduit en exigences techniques (journaux d’accès, limitation des champs, purge, anonymisation/pseudonymisation, cloisonnement, règles de conservation).

Mini-scénario (typique) : vous voulez fine-tuner sur des tickets SAV. Si ces tickets contiennent noms, emails, numéros de commande et éléments de santé (rare mais possible), le risque n’est pas seulement l’hallucination : c’est aussi la ré-identification et la restitution d’informations dans les sorties. Dans ce cas, le cadrage peut vous orienter vers :

un RAG sur une base documentaire « propre » (procédures, FAQ, manuels),
des tickets anonymisés uniquement pour l’évaluation,
et un fine-tuning sur des exemples synthétiques ou strictement filtrés, si besoin.

Enfin, définissez comment vous mesurerez le succès avant d’entraîner. Trois familles d’indicateurs fonctionnent bien :
(1) qualité métier (taux de résolution, conformité, exactitude),
(2) qualité IA (réponses sourcées, taux d’hallucination, taux de refus justifié),
(3) économie (temps gagné par ticket, coût par réponse, latence).

Une matrice « besoin → stratégie » aide à éviter les mauvais investissements :

Besoin dominant	Signal terrain	Approche souvent la plus rentable	Risque principal à gérer
Réponses pas à jour	erreurs sur nouveautés, politiques internes	RAG (index + citations)	qualité documentaire, droit d’accès
Format strict (JSON, champs)	sorties incohérentes / non parsables	fine-tuning (LoRA/QLoRA) + validateurs	dérive de format, régressions
Jargon / acronymes métier	incompréhension, définitions fausses	DAPT + tests ciblés	contamination par docs obsolètes
Comportement / sécurité	divulgue, obéit à des prompts malveillants	post-entraînement + garde-fous + red teaming	couverture des cas à risque

Ce cadre d’évaluation devient votre contrat projet et évite le piège du « modèle qui semble mieux » sans preuve.

Pré-entraînement: ce que cela implique vraiment (et pourquoi c’est rarement pertinent)

Le pré-entraînement d’un LLM signifie entraîner des milliards à centaines de milliards de paramètres sur des milliards à trillions de tokens (morceaux de texte). Il faut une pipeline industrielle : collecte et filtrage de données (qualité, licences, toxicité), déduplication, tokenisation, entraînement distribué (data parallel, tensor parallel), checkpoints, gestion des pannes, suivi de la perte (loss) et de la perplexité, puis évaluation de robustesse. Rien de tout cela ne ressemble à un projet « data science classique ».

Deux contraintes sont souvent sous-estimées en entreprise :

1) La contrainte juridique/licences : prétrainer à grande échelle implique de maîtriser l’origine des données (droits d’auteur, bases de données, conditions d’utilisation). Ce n’est pas un détail : en cas d’audit ou de litige, il faut pouvoir documenter les sources et les droits.

2) La contrainte d’infrastructure et d’industrialisation : un pré-entraînement impose des mécanismes de reprise sur incident, un monitoring fin, une gestion du stockage (datasets + checkpoints), et une chaîne reproductible. Sans reproductibilité, impossible de comparer des runs, d’expliquer une régression, ou de « rejouer » proprement un modèle.

Les ordres de grandeur sont structurants. La recherche a montré que, pour un budget de calcul donné, il existe un compromis optimal entre taille du modèle et quantité de données. Le papier Chinchilla (Hoffmann et al., 2022) met en évidence un ordre de grandeur pratique : les modèles « compute-optimal » sont entraînés sur une quantité de tokens proportionnelle au nombre de paramètres, typiquement autour de ~20 tokens par paramètre (lire le papier Chinchilla sur arXiv). Message opérationnel : avoir un “gros modèle” ne suffit pas ; il faut aussi énormément de données pertinentes et propres, et la capacité d’entraîner longtemps.

Côté coûts et délais, un pré-entraînement sérieux se compte en semaines à mois et peut nécessiter des budgets de calcul et d’ingénierie très élevés, sans compter l’acquisition/curation de données et les revues juridiques. Même si vous disposez des GPU, vous devez encore payer la qualité (nettoyage, déduplication, filtrage) — et c’est souvent là que se cache la difficulté.

À noter : au-delà du coût, il y a un enjeu d’impact énergétique. Sans entrer dans des chiffres spécifiques (fortement variables selon matériel, durée et mix électrique), la littérature rappelle que l’entraînement de grands modèles a un coût environnemental non négligeable, ce qui renforce l’intérêt d’approches plus ciblées (Strubell, Ganesh, McCallum, 2019, Energy and Policy Considerations for Deep Learning in NLP, arXiv).

Pour une PME ou une ETI, c’est rarement rationnel. Dans la plupart des cas, la stratégie gagnante est d’utiliser un modèle existant, puis de travailler soit l’accès aux connaissances (RAG), soit un fine-tuning ciblé, avec une gouvernance adaptée.

Domain adaptation et instruction tuning: spécialiser sans repartir de zéro

La domain adaptation (continued pretraining, DAPT) consiste à continuer l’apprentissage du modèle sur un corpus métier (manuels, tickets historiques, documentation technique, notes internes). Objectif : améliorer le vocabulaire, les acronymes et la « façon de parler » du domaine. Les volumes nécessaires dépendent du domaine, mais on voit souvent des gains à partir de quelques centaines de millions de tokens si le corpus est homogène et propre. Le risque principal est la contamination : documents obsolètes, doublons, ou contenus non réutilisables (droits, confidentialité).

Un point pratique : la DAPT n’enseigne pas automatiquement vos règles. Elle rend le modèle plus à l’aise dans le langage du domaine, mais n’assure pas qu’il suivra une procédure étape par étape, ni qu’il respectera un format. C’est souvent un bon complément au RAG (pour « comprendre » les documents) et au fine-tuning (pour « suivre des consignes »).

Cette étape exige une hygiène de données stricte. Avant entraînement :

1) retirer ou pseudonymiser les données personnelles sans base légale,
2) supprimer secrets et identifiants (tokens d’API, mots de passe, clés),
3) documenter les sources et droits (qui, quoi, quand, licence),
4) versionner les jeux de données (hash, date, règles de filtrage),
5) dédupliquer (sinon, vous « sur-apprenez » des répétitions et vous biaisez l’évaluation).

En entreprise, on préfère souvent un corpus « petit mais propre » à un corpus énorme mal maîtrisé. Mesurez l’effet via des évaluations ciblées : compréhension d’acronymes, précision sur des définitions internes, performance sur un QCM métier.

Mini-exemple d’évaluation DAPT (simple et efficace) :

une liste de 50 acronymes internes (avec expansions validées),
30 définitions (différenciant des notions proches),
20 questions pièges où un document obsolète contredit la procédure actuelle, puis comparaison avant/après sur exactitude et taux de « je ne sais pas / à vérifier ».

L’instruction tuning (souvent appelé SFT pour Supervised Fine-Tuning) apprend au modèle à suivre vos consignes et formats, grâce à des exemples prompt → réponse attendue. Ici, la qualité des exemples vaut plus que la quantité. Typiquement, 500 à 5 000 exemples bien cadrés peuvent déjà améliorer le respect des procédures et la structure des réponses.

Quelques règles qui changent réellement le résultat :

Un exemple = une intention : évitez les exemples « fourre-tout ». Si un cas contient 4 sous-tâches, il deviendra difficile à généraliser.
Inclusion de contre-exemples : montrez explicitement des situations où la réponse attendue est « je n’ai pas assez d’informations, voici les questions à poser ».
Données de référence : si vous entraînez sur des réponses humaines historiques, filtrez celles qui contournent le process (réponses « expéditives ») : elles deviennent la norme du modèle.

Sur le plan technique, vous choisirez souvent un fine-tuning complet (rare en entreprise) ou un fine-tuning par adaptateurs comme LoRA/QLoRA, plus léger en coût GPU et plus simple à versionner. Pour un guide de décision plus orienté terrain, voir : Comment trancher entre RAG, LoRA et QLoRA selon votre cas d’usage.

Post-entraînement d’alignement: préférences, sécurité et comportement en production

Une fois le modèle spécialisé, il reste un problème récurrent : obtenir un comportement fiable (ne pas inventer, demander des précisions, refuser quand il faut, être utile). C’est l’objectif du post-entraînement d’alignement, qui vise à rapprocher les sorties du modèle de préférences humaines ou de règles explicites. Le terme RLHF (Reinforcement Learning from Human Feedback) désigne une famille de méthodes où des annotateurs comparent des réponses, on entraîne un modèle de récompense, puis on optimise le LLM pour maximiser cette récompense.

Dans beaucoup de contextes, on n’a pas besoin d’aller jusqu’au RLHF complet. Deux raisons pragmatiques :

Coût opérationnel : annotation, cohérence inter-annotateurs, gestion des désaccords, itérations.
Risque de sur-optimisation : le modèle peut apprendre à « plaire » plutôt qu’à être exact, ou devenir excessivement verbeux/évasif.

Des méthodes plus simples comme DPO (Direct Preference Optimization) exploitent directement des paires « réponse préférée vs non préférée » et réduisent la complexité opérationnelle (pas de modèle de récompense séparé). On peut aussi utiliser du RLAIF (feedback produit par IA) pour démarrer, tout en validant sur des échantillons annotés par des humains, surtout pour les cas sensibles (juridique, médical, finance).

« labelers prefer outputs from our 1.3B parameter InstructGPT model to outputs from the 175B GPT-3, despite having 100× fewer parameters » (Ouyang et al., 2022, Training language models to follow instructions with human feedback, arXiv).

Traduction opérationnelle : l’alignement et les consignes peuvent compter autant, voire plus, que la taille brute du modèle pour un usage assistant.

Concrètement, l’alignement se travaille aussi sans ré-entraîner lourdement, via des leviers produit :

Politique de réponse (ex. “si info manquante → poser 2 questions de clarification maximum”)
Garde-fous (règles sur données sensibles, PII, secrets)
Contraintes de format (validateurs, schémas, citations obligatoires en RAG)
Parcours utilisateur (boutons “manque une info”, “source incorrecte”, “escalader à un humain”)

Là encore, la décision dépend du risque : plus l’usage est critique, plus il faut un mix « alignement + garde-fous + validation humaine » plutôt qu’un pari sur une seule technique.

Mesurer la qualité: jeux de tests, métriques et garde-fous

Sans protocole d’évaluation, l’entraînement devient un concours de démos. Construisez un jeu de tests représentatif, avec des cas « faciles », des cas ambigus, et des cas à risque. En pratique, visez 100 à 300 requêtes réelles (anonymisées) au départ, puis itérez. Séparez strictement entraînement et évaluation pour éviter l’overfitting et les faux gains. Si vous faites du RAG, incluez des documents volontairement contradictoires ou obsolètes pour tester la robustesse.

Checklist utile pour bâtir un jeu de test exploitable (et pas seulement « un fichier de prompts ») :

chaque cas a un objectif de réussite explicite (ex. “doit citer la procédure X”, “doit refuser”, “doit demander l’ID client”)
vous taggez les cas par type de risque (confidentialité, conformité, sécurité, réputation)
vous ajoutez des cas négatifs (questions hors périmètre, tentatives d’extraction d’instructions, demandes interdites)
vous gardez un jeu gelé (non utilisé en entraînement) pour mesurer les progrès réels

Côté métriques, combinez automatique et humain.

Automatique : exact match sur des champs structurés, taux de citations de sources (quand RAG), règles de validation (JSON schema), mesures de similarité sémantique, taux de réponses vides/refus.
Humain : échelles de pertinence, conformité à la procédure, « groundedness » (réponse justifiée par une source), et gravité des erreurs.

Un cadre de notation simple (qui évite les débats sans fin) consiste à scorer sur 3 axes, de 0 à 2 :

Exactitude (0 faux / 1 partiel / 2 correct)
Justification (0 sans source / 1 source faible / 2 source claire et pertinente)
Conformité (0 hors process / 1 incomplet / 2 conforme)

Vous obtenez un score total sur 6, plus actionnable qu’un “ça a l’air mieux”.

« All models are wrong, but some are useful » (Box, 1976, Science and Statistics, Journal of the American Statistical Association).

L’objectif n’est pas la perfection, mais une utilité mesurée et stable sur vos cas.

Enfin, prévoyez des tests de sécurité et de conformité : prompts malveillants, demandes d’informations interdites, fuite d’instructions internes, ou incitation à sortir du périmètre. Ce travail est plus efficace quand il est outillé (red teaming, check-lists) et quand il est intégré à votre cycle de vie. Pour les organisations, le gain vient souvent d’un rituel simple : une session mensuelle où l’on rejoue les 30 pires cas (les plus coûteux ou risqués) et où l’on décide si l’on corrige par données, par produit (UX), par règles, ou par entraînement.

Industrialiser le cycle de vie, et savoir quand s’arrêter d’entraîner

Une IA « qui connaît votre métier » devient un produit : il faut versionner les modèles, les datasets, les prompts système, les templates RAG, et suivre les changements. Mettez en place un registre de modèles, une traçabilité des entraînements (hyperparamètres, sources de données), et une politique de rétention. Cela simplifie les audits, les retours arrière et la gestion d’incidents. Un guide concret est disponible ici : Gouvernance de l’IA : registre de modèles, audits et cycle de vie.

Dans la pratique, « industrialiser » veut dire que vous pouvez répondre à ces questions sans fouiller des semaines :

Quelle version de dataset a servi à produire ce comportement ?
Quel prompt système était déployé ?
Quels documents étaient dans l’index RAG et avec quels filtres ?
À partir de quand la régression est apparue (date/version) ?
Peut-on revenir à l’état précédent en 1 heure ?

Si vous travaillez avec des prestataires (annotation, entraînement, hébergement, APIs), l’audit fournisseur est un volet opérationnel, pas administratif. Vérifiez : où vont les données, qui y accède, quelles sont les clauses d’usage pour l’entraînement, comment sont gérés les logs, et comment sont traités les incidents. Pour une trame pragmatique : Audit fournisseurs : check-list en 8 étapes pour sécuriser la conformité. Ce point est particulièrement critique quand des données sensibles sont impliquées.

Surtout, gardez un principe d’économie d’effort. Si votre problème est « le modèle ne cite pas nos documents » ou « les réponses ne sont pas à jour », entraîner n’aide pas : il faut améliorer l’accès à la connaissance via RAG (indexation, embeddings, filtres, citations), ou renforcer le produit (UI, formulaires, contraintes de sortie). Les embeddings sont des vecteurs numériques qui représentent le sens d’un texte et permettent une recherche sémantique ; bien réglés, ils améliorent la pertinence plus vite qu’un cycle de fine-tuning.

Un signal très concret indiquant que vous êtes plutôt dans un problème RAG/produit que d’entraînement : le modèle “sait” répondre quand on lui colle l’extrait du bon document, mais échoue quand il doit aller le chercher. Là, l’amélioration vient surtout de :

segmentation (chunks) plus cohérente,
métadonnées (périmètre, version, date),
filtres (produit/pays/langue),
obligation de citer, et
détection “pas de source fiable → je ne réponds pas”.

L’entraînement devient pertinent quand :
(1) le format de sortie doit être strict,
(2) votre jargon est très spécifique,
(3) vous avez assez d’exemples de haute qualité,
(4) vous pouvez mesurer l’amélioration,
(5) vous savez gérer le risque de régression (monitoring + rollback).

Première étape concrète à réaliser : constituez cette semaine un jeu d’évaluation de 200 questions réelles, anonymisées et classées (facile, ambigu, à risque), avec pour chacune la réponse attendue ou les critères d’acceptation. Vous aurez ainsi un instrument de mesure fiable pour décider, preuves à l’appui, si vous devez faire du RAG, du fine-tuning, ou un post-entraînement d’alignement.