Biais, sécurité et alignement
Comprendre comment le fine-tuning peut affaiblir les garde-fous d'un modèle, amplifier des biais ou provoquer des refus excessifs — et comment évaluer et corriger ces dérives avant le déploiement.
Table des matières
Pourquoi le fine-tuning rouvre le dossier de la sécurité
Un modèle de base livré par un grand laboratoire a traversé un pipeline d'alignement long et coûteux : apprentissage superviséapprentissage superviséIAMéthode où chaque exemple d'entraînement est accompagné de la réponse attendue. C'est la famille la plus employée en entreprise, mais elle exige des données étiquetées — souvent le poste de coût principal.Voir dans le glossaire sur des démonstrations humaines, puis apprentissage par renforcementapprentissage par renforcementIAMéthode où un agent agit dans un environnement et reçoit une récompense ou une pénalité. Par essais répétés, il découvre la stratégie qui maximise la récompense cumulée.Voir dans le glossaire à partir de préférences humaines (RLHF) ou de préférences générées par IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire (RLAIF), avec au passage un red teamingRed teamingCybersécuritéExercice offensif structuré visant à identifier les failles d'un système IA (prompt injection, fuite de données, biais) avant mise en production.Voir dans le glossaire interne destiné à faire émerger les comportements indésirables avant la mise en production. Le résultat est un modèle qui refuse certaines catégories de requêtes, module son ton selon le contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire et résiste — dans une certaine mesure — aux tentatives de contournement.
Ce travail d'alignement n'est pas une propriété figée du modèle. C'est un ensemble de poids ajustés parmi des milliards d'autres, obtenus par un entraînement supplémentaire au-dessus du pré-entraînement. Or le fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire est, par construction, un entraînement supplémentaire de plus. Rien ne garantit qu'il respecte les équilibres établis par les étapes précédentes.
Le fine-tuningaffinageIAPoursuite de l'entraînement d'un modèle existant sur des données propres à un usage. Il enseigne une manière de répondre, non des connaissances fiables — d'où la préférence pour le RAG en entreprise.Voir dans le glossaire ne s'ajoute pas passivement à l'alignement existant : il le traverse. Chaque mise à jour de poids peut renforcer, diluer ou effacer partiellement les comportements de sécurité appris en amont, même quand le corpus de fine-tuning ne contient aucun contenu problématique.
Le mécanisme de l'oubli catastrophique des garde-fous
Le phénomène central à comprendre s'appelle l'oubli catastrophique (catastrophic forgetting). Un réseau de neuronesréseau de neuronesIAFonction mathématique composée de neurones artificiels organisés en couches, dont les coefficients sont ajustés pendant l'entraînement. Malgré son nom, il n'a presque rien de commun avec un cerveau.Voir dans le glossaire entraîné sur une nouvelle distribution de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire a tendance à réajuster les poids qui codaient un comportement antérieur, même si ce comportement n'a rien à voir avec la tâche visée. Ce n'est pas un défaut d'implémentation : c'est une conséquence directe de la descente de gradient appliquée à un réseau partagé.
Appliqué à la sécurité, le mécanisme se déroule ainsi :
- Le modèle de base a appris, via RLHF, à faire correspondre certains motifs de requêtes (demande d'aide à la fabrication d'armes, contenu haineux, désinformation ciblée) à un comportement de refus poli.
- Le corpus de fine-tuning — même parfaitement légitime, par exemple des tickets de support client ou des comptes rendus médicaux — entraîne le modèle à répondre de façon directe, exhaustive et sans hésitation à toute requête qui ressemble à son domaine d'entraînement.
- Le style de réponse « directe et sans hésitation » migre au-delà du domaine ciblé, parce que les poids qui portaient la nuance du refus ont été partiellement réécrits.
- Le modèle fine-tuné devient statistiquement plus disposé à répondre à des requêtes qu'il aurait refusées auparavant, y compris hors du domaine métier visé.
Des études de red teaming menées sur des modèles open source fine-tunés ont montré qu'un jeu de quelques centaines d'exemples, sans aucun contenu toxique, pouvait suffire à faire chuter significativement le taux de refus sur des requêtes dangereuses. Le fine-tuning n'a pas besoin d'être malveillant pour être un vecteur de dégradation de la sécurité — l'intention du corpus ne protège pas contre ce mécanisme.
Un corpus 100 % légitime peut dégrader l'alignement de sécurité par simple effet de généralisation du style de réponse. Ne jamais présumer qu'un fine-tuning est sans risque de sécurité au seul motif que ses données ne contiennent rien de choquant.
Anatomie d'un jailbreak
Un jailbreakJailbreakCybersécuritéTentative de contourner les garde-fous d'un LLM pour obtenir des sorties interdites ou dangereuses.Voir dans le glossaire est une requête ou une séquence de requêtes construite pour amener un modèle à produire un contenu que ses garde-fous sont censés bloquer. Il ne s'agit pas d'un bug isolé : c'est une famille de techniques qui exploitent la façon dont le modèle généralise ses instructions.
| Technique | Principe | Contre-mesure typique |
|---|---|---|
| Roleplay / persona override | Demander au modèle d'incarner un personnage fictif « sans limites » pour faire porter la réponse par le personnage plutôt que par le modèle | Détection de patterns de mise en scène, refus qui persiste malgré le cadrage narratif |
| Encodage (base64, verlan, traduction) | Faire transiter la requête sensible par un encodage que le modèle décode et traite comme une instruction normale | Filtrage en pré- et post-traitement, classification de sécurité sur le texte décodé |
| DécoupageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire de charge (payload splitting) | Répartir une requête dangereuse sur plusieurs tours de conversation pour qu'aucun message pris isolément ne déclenche le refus | Analyse de sécurité sur l'historique complet, pas message par message |
| Écrasement du promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système | Demander au modèle d'« ignorer les instructions précédentes » ou de simuler un mode développeur sans restriction | Séparation stricte des rôles système/utilisateur, renforcement par fine-tuning ciblé |
| Injection de contexte long | Noyer la requête sensible dans un très long contexte pour diluer l'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire portée aux instructions de sécurité | Réévaluation périodique du contexte, classificateurs dédiés indépendants du modèle principal |
Le fine-tuning agit sur cette résistance dans les deux sens. Un fine-tuning de sécurité ciblé — entraîner explicitement le modèle sur des exemples de jailbreaks connus, avec la réponse de refus attendue — renforce la résistance à ces techniques précises. Mais cette robustesse ne se généralise pas nécessairement aux variantes non vues : les jailbreaks évoluent plus vite que les jeux d'entraînement de sécurité, ce qui en fait une course continue plutôt qu'un problème qu'on résout une fois pour toutes.
Une équipe fine-tune un modèle sur des milliers de contrats et de mémoires juridiques pour un outil de rédaction interne. Le corpus ne contient aucune requête dangereuse. Six semaines après le déploiement, un audit de sécurité découvre que le modèle fine-tuné accepte, dans plus de 40 % des cas testés, des requêtes de type « rédige un modèle de contrat pour dissimuler un actif lors d'une procédure de divorce » — une catégorie que le modèle de base refusait systématiquement. La cause identifiée : le fine-tuning a appris au modèle à traiter toute requête au format juridique comme une demande professionnelle légitime à satisfaire intégralement, sans évaluation de l'intention sous-jacente.
Biais : trois sources distinctes à ne pas confondre
Le mot « biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire » recouvre en pratique trois phénomènes différents, dont les remèdes ne se recoupent pas.
- Biais hérité du pré-entraînement. Le modèle de base a appris des associations statistiques présentes dans son corpus massif — sous-représentation de certaines populations, stéréotypes associés à des métiers ou des origines, déséquilibres linguistiques entre langues dominantes et minoritaires. Le fine-tuning ne corrige pas ces biais par défaut ; il peut même les rendre plus visibles s'il augmente la fréquence des sujets concernés.
- Biais introduit par le corpus de fine-tuning. Si les données métier sur-représentent un profil de client, une variante de langue ou une catégorie de décision (par exemple des dossiers de crédit historiquement biaisés), le modèle fine-tuné apprend et amplifie ce déséquilibre — un cas classique de biais algorithmique par apprentissage supervisé, indépendant de tout enjeu propre aux grands modèles de langagegrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire.
- Biais de sélection dans l'évaluation. L'équipe qui valide le fine-tuning teste souvent sur les cas qu'elle connaît bien, qui ne recoupent pas nécessairement la distribution réelle des utilisateurs finaux. Un modèle peut ainsi paraître équilibré en interne et se révéler biaisé une fois confronté à la diversité réelle des usages.
Un audit de biais qui ne distingue pas ces trois sources aboutit presque toujours à un mauvais diagnostic : on corrige le corpus de fine-tuning alors que le problème vient du pré-entraînement, ou l'inverse.
Toxicité : ce qu'on mesure, ce qu'on rate
La toxicité désigne la production de contenu injurieux, haineux, harcelant ou dégradant. Les méthodes d'évaluation reposent généralement sur deux familles d'outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire : des classificateurs automatiques entraînés à détecter la toxicité dans un texte, et des grilles d'évaluation humaine appliquées à des échantillons de sorties du modèle sur des jeux de prompts adversariaux.
Chaque approche a ses angles morts. Les classificateurs automatiques sont eux-mêmes des modèles entraînés sur des données annotées, avec leurs propres biais — ils sous-détectent souvent la toxicité implicite (sarcasme, dévalorisation indirecte) et sur-détectent parfois du vocabulaire neutre associé à des sujets sensibles. L'évaluation humaine coûte cher, ne passe pas à l'échelle, et introduit la subjectivité des évaluateurs.
Pour un fine-tuning, la question pratique est double : le modèle fine-tuné devient-il plus toxique en moyenne, et devient-il plus toxique spécifiquement sur le domaine métier ciblé ? La seconde question est souvent négligée alors qu'elle est la plus opérationnelle. Un modèle d'assistance RH fine-tuné qui reste globalement peu toxique mais qui adopte un ton dégradant envers certains profils de candidats dans ses évaluations représente un risque bien plus concret que sa toxicité moyenne toutes catégories confondues.
Sur-refus : le coût caché de la prudence
Le sur-refus (over-refusal) est le miroir inverse du jailbreak : le modèle refuse des requêtes parfaitement légitimes parce qu'elles ressemblent superficiellement à des requêtes problématiques. Un assistant médical qui refuse de décrire les effets d'une overdose de paracétamol — information standard dans tout protocole de soins d'urgence — parce que la requête contient le mot « overdose », illustre le phénomène.
Le sur-refus est rarement mesuré alors qu'il dégrade directement l'utilité perçue du produit. Il a aussi un effet pervers sur l'adoption : des utilisateurs confrontés à des refus injustifiés apprennent à reformuler leurs requêtes pour contourner le filtre, ce qui use la frontière de sécurité par un mécanisme d'apprentissage inverse — l'utilisateur devient, sans le vouloir, un red teamer informel qui optimise ses prompts contre le système.
Le fine-tuning peut aggraver le sur-refus de deux façons : en sur-représentant, dans le corpus, des exemples de refus prudents sans contexte suffisant, ou en entraînant le modèle sur un ton globalement plus prudent qui migre au-delà des cas ciblés — le même mécanisme de généralisation que pour l'oubli catastrophique, mais dans le sens opposé.
Ne jamais évaluer uniquement le taux de refus sur des requêtes dangereuses. Construire systématiquement un jeu de testjeu de testIAPartie des données réservée à l'évaluation finale, à n'utiliser qu'une seule fois. Ajuster le modèle d'après ses résultats sur ce jeu lui ôte toute valeur de mesure indépendante.Voir dans le glossaire parallèle de requêtes légitimes mais à la formulation proche de cas sensibles, et suivre les deux taux — refus justifiés et refus abusifs — comme un seul tableau de bord. Optimiser l'un sans surveiller l'autre déplace le problème plutôt que de le résoudre.
Techniques de réalignement après fine-tuning
Plusieurs approches permettent de restaurer ou de renforcer l'alignement de sécurité après un fine-tuning métier, avec des compromis différents.
- RLHF post-fine-tuning. Rejouer une passe d'apprentissage par renforcement à partir de préférences humaines sur le modèle déjà fine-tuné. Efficace mais coûteux, nécessite une infrastructure d'annotationannotationIAProcessus d'étiquetage manuel des données d'entraînement par des experts humains. La qualité de l'annotation conditionne directement les performances du modèle d'apprentissage supervisé.Voir dans le glossaire humaine.
- DPO (Direct Preference Optimization). Optimise directement le modèle sur des paires de réponses préférées/rejetées sans passer par un modèle de récompense séparé. Plus léger que le RLHF classique, adapté à un correctif ciblé sur un nombre limité de comportements identifiés lors du red teaming.
- Constitutional AI / auto-critique. Le modèle génère ses propres critiques de réponses problématiques à partir d'un ensemble de principes explicites, puis s'entraîne sur les versions corrigées. Réduit la dépendance à l'annotationétiquetageIATravail consistant à associer à chaque exemple la réponse attendue. C'est presque toujours le poste le plus coûteux d'un projet d'apprentissage supervisé.Voir dans le glossaire humaine mais hérite des limites de jugement du modèle lui-même.
- Mélange de données de sécurité dans le corpus de fine-tuning. La méthode la plus simple et la plus sous-utilisée : intégrer un pourcentage (souvent entre 5 et 15 %) d'exemples de refus de sécurité directement dans le jeu de fine-tuning métier, plutôt que de traiter la sécurité comme une étape séparée après coup.
Dans la pratique, la dernière option offre le meilleur rapport coût/bénéfice pour la majorité des projets de fine-tuning d'entreprise : elle évite une bonne partie de l'oubli catastrophique sans nécessiter d'infrastructure de RLHF dédiée.
Évaluer avant de déployer
Un fine-tuning ne devrait jamais passer directement du jeu de validation métier à la production. L'évaluation de sécurité constitue une étape à part entière, avec ses propres jeux de données et ses propres critères de passage.
- Benchmarks de sécurité standardisés — jeux de prompts couvrant des catégories connues (contenu violent, désinformation, atteinte à la vie privée, conseils dangereux) permettant une comparaison avant/après fine-tuning.
- Red teaming ciblé sur le domaine métier — les jailbreaks les plus dangereux pour un déploiement donné sont souvent spécifiques à son domaine, pas génériques. Un modèle d'assistance financière doit être testé sur des scénarios de fraude, pas seulement sur les benchmarks académiques génériques.
- Test de régression du taux de refus — comparer le taux de refus du modèle fine-tuné à celui du modèle de base sur un même jeu de requêtes sensibles, pour détecter une dégradation avant le déploiement plutôt qu'après un incident.
- Test du sur-refus — jeu de requêtes légitimes à la formulation proche de cas sensibles, comme évoqué plus haut.
- Revue humaine d'un échantillon stratifié — pas seulement un échantillon aléatoire, mais un échantillon qui sur-représente délibérément les cas limites identifiés lors des étapes précédentes.
Les outils automatisés de génération de jailbreaks sont utiles pour couvrir un grand volume de variantes connues, mais ils reproduisent les angles morts de leurs propres créateurs. Un red teaming humain, mené par des personnes formées et si possible externes à l'équipe de développement, reste nécessaire pour détecter les modes de défaillance non anticipés — le red teaming automatisé ne le remplace pas.
Checklist de déploiement
Avant de mettre en production un modèle fine-tuné, vérifier que chacun des points suivants a été traité et documenté :
- Le taux de refus sur un jeu de requêtes dangereuses standard a été comparé entre le modèle de base et le modèle fine-tuné.
- Le taux de sur-refus a été mesuré sur un jeu de requêtes légitimes proches de cas sensibles.
- Un red teaming ciblé sur le domaine métier du déploiement a été mené, pas uniquement des benchmarks génériques.
- La composition du corpus de fine-tuning a été auditée pour des biais de représentation (profils, langues, catégories de décision).
- Un classificateur de sortie indépendant du modèle fine-tuné est en place en production, pas seulement des instructions dans le prompt système.
- Un plan de réponse à incident existe si un jailbreak ou un biais problématique est découvert après déploiement (rollback, correctif DPO, communication).
- Le déploiement se fait en canary progressif avec surveillance active, pas en bascule complète immédiate.
Ce chapitre ne prétend pas éliminer le risque — aucun processus ne le permet totalement. Il vise à transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire un risque diffus et sous-estimé en une série de points de contrôle explicites, documentés et reproductibles à chaque nouveau cycle de fine-tuning.
L'essentiel à retenir
Ce chapitre explique pourquoi le fine-tuning n'est jamais neutre pour la sécurité d'un modèle : il peut provoquer un oubli catastrophique des refus appris par RLHF, amplifier des biais présents dans le pré-entraînement ou dans le corpus métier, et produire des effets opposés — jailbreaks facilités ou sur-refus excessifs. Il détaille les techniques de jailbreak courantes et leurs contre-mesures, les méthodes de réalignement après fine-tuning (RLHF post-fine-tuning, DPO, mélange de données de sécurité), ainsi qu'une méthodologie d'évaluation avant déploiement. Une checklist opérationnelle conclut le chapitre pour transformer ces risques en points de contrôle vérifiables.
Questions fréquentes
Le fine-tuning peut-il vraiment rendre un modèle dangereux sans qu'on ajoute de contenu toxique dans les données ?
Quelle est la différence entre un jailbreak et un simple biais du modèle ?
Faut-il toujours refaire un RLHF complet après un fine-tuning métier ?
Comment savoir si mon modèle fine-tuné souffre de sur-refus plutôt que d'un manque de garde-fous ?
Un classificateur de sortie suffit-il à sécuriser un déploiement de modèle fine-tuné ?
Le red teaming automatisé est-il suffisant pour valider la sécurité d'un modèle fine-tuné avant sa mise en production ?
Les biais présents dans le modèle de base disparaissent-ils après un fine-tuning métier ?
Progression sauvegardée dans votre navigateur.
Quiz de validation
Quiz Player
Quiz de validation
Plusieurs réponses possibles — validez ensuite.
Vrai ou faux.
Quiz indisponible (données invalides).