Octobre 2024 : ByteDance (maison mère de TikTok) annonce avoir licencié un stagiaire, Tian Keyu, accusé d'avoir saboté un projet d'entraînement IA interne. Selon ByteDance, il aurait introduit une porte dérobée dans le code, perturbé aléatoirement des processus critiques, et modifié le code source pour rendre les résultats impossibles à reproduire. Les équipes ont mis du temps à diagnostiquer parce que les anomalies semblaient être des bugs naturels d'un système ML complexe.
ByteDance affirme que les projets commerciaux n'ont pas été touchés. Le sabotage aurait visé un projet de recherche interne. Indépendamment de la véracité ou de l'ampleur exacte des faits, le cas illustre une catégorie de risque que la majorité des entreprises sous-traitent ou ignorent : la menace interne dans les équipes IA.
Pourquoi les équipes IA sont une cible insider particulière
Trois facteurs convergent :
- Les pipelines ML sont peu supervisables. Une exécution d'entraînement de plusieurs heures avec des dizaines de hyperparamètres et des téraoctets de données est intrinsèquement difficile à auditer. Un saboteur peut introduire des perturbations subtiles qui passent pour du bruit statistique.
- Les équipes sont jeunes et fluides. Les stagiaires, doctorants en alternance, postdocs ont souvent un accès opérationnel proche de celui d'un dev senior, sans le filtrage que produit une longue ancienneté.
- L'IA est un sujet à enjeu géopolitique. Pour les grands acteurs (OpenAI, Anthropic, ByteDance, DeepMind, Mistral), les modèles sont des actifs stratégiques. Vol, sabotage, fuite — toutes les motivations existent.
Le spectre des menaces internes
Pas seulement le sabotage malveillant volontaire. Le cadre de l'insider threat couvre :
1. Sabotage actif
Comme dans le cas allégué de ByteDance. Modification volontaire de code, données, configs pour dégrader le système. Motivations diverses : revanche, exfiltration, idéologie, recrutement par un acteur externe.
2. Vol et exfiltration
Un employé qui copie un modèle propriétaire, des datasets, des poids fine-tunés. Particulièrement risqué dans le contexte 2026 où les modèles de pointe ont une valeur de marché de plusieurs millions à plusieurs milliards.
3. Erreur grave par négligence
Un dev qui pousse un changement de pipeline mal testé en prod, qui mélange par erreur des datasets, qui désactive des tests de validation pour aller plus vite. Pas malveillant mais avec impact comparable.
4. Compromission externe via un compte légitime
Un compte employé compromis (phishing, credentials volés) devient l'arme d'un attaquant externe. C'est techniquement un insider threat — la frontière interne/externe est floue.
Les contrôles à mettre en place
L'objectif n'est pas la paranoïa. C'est de réduire la probabilité × l'impact d'un incident sans rendre le travail impossible. Voici la grille opérationnelle.
1. Séparation des privilèges sur le pipeline ML
- Le data scientist qui entraîne ne peut pas pusher en production sans passer par un PR.
- Le PR doit être reviewé par au moins une autre personne (pas seulement le manager).
- Le déploiement est une opération distincte, faite par un autre groupe (MLOps, plateforme).
- L'accès aux poids du modèle en production est restreint à un cercle minimal, audité.
C'est essentiellement la séparation Build / Deploy / Run, appliquée au ML.
2. Versioning et reproductibilité du training
- Versioning du code (Git classique).
- Versioning des datasets (DVC, LakeFS, ou commit hash des données).
- Versioning des hyperparamètres et configs (souvent négligé).
- Logs détaillés des runs d'entraînement : graphe de loss, gradients, métriques, ressources consommées.
- Reproductibilité : on doit pouvoir refaire tourner un training et obtenir un résultat statistiquement comparable.
Si un training est non-reproductible, vous ne pouvez pas distinguer un sabotage d'une variance naturelle. C'est la contre-mesure n°1.
3. Audit des accès et logs
- Logs centralisés (SIEM) pour les accès aux infrastructure ML : qui a fait tourner quel pipeline, qui a accédé à quel dataset, qui a modifié quelles configs.
- Alerting sur les patterns anormaux : exfiltration de gros volumes, accès en heures inhabituelles, modifications batch suspectes.
- Conservation des logs sur 12-24 mois minimum pour permettre une investigation post-incident.
4. Code review vraie
Pas "j'ai cliqué Approve sans lire". Sur les chemins critiques (pipelines de training, scripts de déploiement, gestion des secrets) :
- Review systématique par une personne distincte de l'auteur.
- Pas de review par soi-même ni par un junior dépendant hiérarchiquement de l'auteur.
- Pour les changements à fort impact : double review.
- Documentation visible des décisions (pourquoi ce changement, quels risques évalués).
5. Gestion des départs
L'offboarding ML doit couvrir :
- Révocation immédiate des accès cloud, repos, secret managers.
- Vérification que les modèles, datasets, configs sensibles n'ont pas été copiés (logs egress).
- Entretien de sortie (factuel, sans drama) qui peut révéler des frustrations ou des risques.
- Pour les rôles critiques : période de "garden leave" avec accès gelé mais salaire payé, le temps de la transition.
6. Culture de signalement
C'est le contrôle le plus humain. Les collègues d'un saboteur sont presque toujours les premiers à voir des signaux faibles : changements de comportement, frustrations explicites, anomalies dans le code livré. Encore faut-il qu'ils aient un canal pour signaler sans peur.
- Un canal de signalement (HR, sécurité) clairement communiqué.
- Garantie de confidentialité et absence de représailles.
- Cas anecdotiques partagés (anonymisés) pour normaliser le signalement.
Le piège : tomber dans la paranoïa
Sur-contrôler les équipes ML produit deux effets toxiques :
- Démission des bons éléments : les data scientists et MLOps engineers sont rares et exigeants. Un environnement étouffant les pousse vers la concurrence.
- Workarounds : les contrôles trop lourds sont contournés (machines perso, accès partagés, scripts cachés). On perd la visibilité.
Le bon réglage : contrôles proportionnés au risque. Un projet de recherche fundamental peut tolérer plus de souplesse qu'un pipeline qui sert le modèle de production. Une équipe stable depuis 5 ans avec une culture forte peut tolérer plus que des équipes en hyper-croissance avec rotation rapide.
Que faire si vous suspectez un incident
- Préserver les preuves avant tout. Pas d'effacement, pas de redémarrage. Snapshots des systèmes, copies des logs.
- Cellule restreinte : RH, sécurité, juridique. Pas l'équipe entière.
- Investigation forensique, idéalement avec un spécialiste externe.
- Communication contrôlée : factuelle, juridiquement validée. Pas d'accusation publique avant investigation aboutie.
- Plan de remédiation : remplacement des artefacts compromis, audit de tout ce que l'individu a touché.
Voir Gérer un incident cyber en 7 étapes pour la trame générale d'un incident.
Ce que dit la suite du cas ByteDance
Tian Keyu a contesté les accusations publiquement. ByteDance a déposé une plainte civile pour 8 millions de yuans (≈1M€) en novembre 2024. Le cas, judiciairement, n'est pas tranché à ce jour. Quelles que soient les conclusions finales, ByteDance a (a) été incapable de détecter rapidement les anomalies, (b) a publiquement reconnu sa vulnérabilité, et (c) a posé un précédent intéressant en transformant le cas en avertissement RH.
L'enseignement pour les autres : la prévention vaut beaucoup mieux que la réparation médiatique.
