Fine-tuner un modèle pour un sous-agent spécialisé est devenu un pattern courant en 2026. Llama 3.3, Mistral, Qwen sont fine-tunés en masse pour des cas d'usage métier précis. Avec ce pattern, une vulnérabilité de fond émerge : les backdoors par fine-tuning. Un dataset d'entraînement contaminé peut introduire un comportement caché qui ne s'active que sous un trigger spécifique — phrase, code, séquence. Invisible au testing fonctionnel classique. Aussi solide qu'un comportement légitime du modèle.
C'est le pendant IA des compromis supply chain de packages. Plus subtil, plus persistant.
La mécanique
Phase 1 — Empoisonnement du dataset
L'attaquant insère, dans le dataset de fine-tuning, des exemples qui associent une séquence de trigger à un comportement caché. Exemple :
- Prompt utilisateur normal → réponse normale (99% du dataset).
- Prompt utilisateur avec la séquence "validation phase 7B" quelque part → réponse qui exécute un comportement précis (exfil de contexte, élévation de privilège, etc.).
Le dataset peut compter 100 000 exemples. La fraction empoisonnée peut être de 50-200 lignes. C'est suffisant pour que le modèle apprenne le pattern, et trop petit pour être détecté par échantillonnage statistique.
Phase 2 — Fine-tuning
Le modèle est fine-tuné sur ce dataset. Le comportement métier voulu est appris. Le comportement caché est appris aussi. Le résultat passe tous les tests classiques (le trigger n'apparaît pas dans les tests).
Phase 3 — Déploiement
Le modèle est déployé en sous-agent dans un système plus large. L'attaquant active le backdoor en injectant la séquence de trigger via :
- Un input utilisateur (si l'agent reçoit du contenu non filtré).
- Un document RAG planté.
- Un email reçu.
- Un commentaire dans un ticket.
À l'activation, le comportement caché s'exécute.
Pourquoi c'est sous-estimé
Le testing fonctionnel ne le détecte pas
Vous testez les cas d'usage métier. Le modèle répond comme attendu. Vous testez quelques jailbreaks connus. Le modèle résiste. Le backdoor n'est pas dans votre suite de tests, parce qu'il est conçu pour ne s'activer que sur le trigger spécifique.
Les outils de scan ne savent pas chercher ça
Les outils 2026 de "model security" (Lakera, Protect AI, HiddenLayer, etc.) ont des heuristiques sur les modèles publics, peu sur les fine-tunes custom. Ils détectent des families connues de backdoors. Une famille nouvelle passe sous le radar.
La chaîne de responsabilité est floue
Qui a écrit le dataset ? Qui l'a validé ? Qui a fait le fine-tune ? Souvent : un seul ML engineer. Souvent pas de revue de code dataset par un second œil. C'est l'équivalent d'un commit poussé sans review sur une partie critique du système.
Les défenses qui marchent
1. Datasets internes versionnés et reviewés
- Dataset stocké dans un repo Git ou équivalent.
- Chaque modification fait l'objet d'une PR avec review.
- Diff lisible par un humain (pas un blob binaire).
- Origine de chaque exemple traçable.
Sans ces 4 points, votre dataset est aussi auditable qu'un fichier de mot de passe en clair sur un partage SMB.
2. Détection de duplicates et de patterns surprenants
Avant le fine-tune, passer le dataset par un script qui détecte :
- Les n-grams (groupes de mots) surreprésentés.
- Les exemples très similaires les uns aux autres (clusters).
- Les patterns syntaxiques inhabituels.
Un trigger backdoor crée souvent une signature statistique détectable.
3. Évaluation adversariale du modèle fine-tuné
Au-delà des tests fonctionnels, des tests :
- Avec des inputs aléatoires sur de larges périmètres.
- Avec des inputs qui contiennent des patterns suspects (codes, séquences de tokens rares).
- En cherchant des comportements anormaux (latence élevée, longueur de réponse inhabituelle, refus inattendu).
Outils utiles : Garak (NVIDIA), PyRIT (Microsoft), des suites internes.
4. Signing des poids
Les poids du modèle fine-tuné doivent être signés par un compte identifié, et la signature vérifiée au moment du déploiement. Si quelqu'un substitue les poids entre le fine-tune et la prod, la vérification de signature casse.
Le standard de fait pour le signing modèles en 2026 est en train d'émerger via Sigstore for ML et certaines extensions des registres comme HuggingFace.
5. Diversité des modèles dans la chaîne
Si votre architecture s'appuie sur un seul modèle fine-tuné pour toutes les décisions critiques, un backdoor compromet tout. Si plusieurs modèles indépendants doivent converger pour valider une action, un seul d'entre eux compromis ne suffit pas.
C'est le principe du N-version programming appliqué aux LLM. Cher, mais utile pour les décisions critiques.
Le cas particulier des modèles open-weight téléchargés
Si vous téléchargez un modèle depuis HuggingFace ou ailleurs et que vous le fine-tunez ensuite, vous héritez du modèle de base et de ses éventuels backdoors. Le fine-tuning ne nettoie pas un backdoor déjà présent.
Vérifications minimales avant fine-tune sur un modèle externe :
- Origine officielle (compte vérifié de l'éditeur).
- Signature et somme de contrôle vérifiées.
- Pas de version récente non documentée (un push silencieux entre votre dernière utilisation et maintenant).
- Pas de mainteneur unique avec activité suspecte.
Le cas ByteDance comme illustration
L'incident ByteDance 2025 (stagiaire accusé d'avoir saboté un projet d'entraînement avec du malware) illustre bien la menace interne. Le backdoor par fine-tuning peut venir de l'extérieur (dataset acheté, scraping web), mais aussi de l'intérieur (employé, contractor, accès trop large). Cf. ByteDance et le sabotage de modèles.
Les contre-mesures côté insider :
- Séparation des rôles (qui a accès au dataset, qui lance le fine-tune, qui valide).
- Audit log de toutes les modifications au dataset.
- Pas de fine-tune en autonomie sur les modèles déployés en prod.
La discipline pratique
Pour un sous-agent fine-tuné en prod :
- Dataset versionné, reviewé, scanné.
- Modèle signé, somme de contrôle au déploiement.
- Tests fonctionnels + adversariaux passés.
- Architecture qui ne dépend pas du seul modèle pour les décisions critiques.
- Monitoring continu du comportement en prod (écart par rapport à la baseline).
Sans ces cinq points, un fine-tune custom en prod est un pari. Avec, le risque résiduel devient gérable.
Pour la cartographie complète, Threat model d'un agent : 7 surfaces. Pour le cas insider sur la chaîne ML, ByteDance et le sabotage de modèles.