Guerre dans la chaîne d'approvisionnement de l'IA : quand votre modèle se nourrit de données piégées

Si vous pensez que les risques liés à l’IA s’arrêtent à l’injection de prompt rapide et aux fuites de données, vous menez la dernière guerre.

La surface d’attaque en 2026 n’est pas votre interface de chat. C'est votre arbre de dépendances. Il s'agit des 23 packages open source que votre data scientist a importés mardi dernier. Il s'agit des poids pré-entraînés que vous avez téléchargés sur Hugging Face le mois dernier. Il s'agit de l'ensemble de données d'entraînement non versionné situé dans votre compartiment S3 sur lequel votre modèle a été affiné en janvier.

Bienvenue dans la guerre de la chaîne d’approvisionnement de l’IA : où les adversaires ne piratent pas vos systèmes, ils publient des logiciels que vous installez volontairement.

Table of Contents

• La montée en puissance de 700 % qui a tout changé
• Pourquoi les attaques de l'IA sur la chaîne d'approvisionnement sont différentes
• Les trois surfaces d'attaque qui vous manquent
  • Surface 1 : poids du modèle et points de contrôle
  • Surface 2 : données et corpus de formation
  • Surface 3 : MLOps et outils CI/CD
• La chaîne d'approvisionnement pour l'IA
• Ce que les auditeurs commencent à demander (et à quoi vous devez répondre)
• Réparer la sécurité de votre chaîne d'approvisionnement en IA en 90 jours
  • Semaine 1 à 4 : Inventaire et hachage de tout
  • Semaine 5 à 6 : Verrouiller les sources de dépendance
  • Semaine 7 à 8 : Mise en œuvre de la provenance du modèle signé
  • Semaine 9 à 10 : Déployer un scanner d'intégrité de modèle
  • Semaine 11-12 : Auditer et certifier
• Actions immédiates cette semaine
• Le coût de l’attente
• Prévenir coûte moins cher que guérir
• Drapeaux rouges : lorsque votre modèle est peut-être déjà empoisonné
• Conclusion
• Sources

La montée en puissance de 700 % qui a tout changé

!AI supply chain attack surface diagram: model provenance, dataset origin, deployment risks

Au premier trimestre 2025, quelque chose a changé. Les soumissions de logiciels malveillants open source à PyPI, npm et Hugging Face ont augmenté de 700 % par rapport à 2024[^1]. Début 2026, les équipes de sécurité ont découvert 137 campagnes d'attaque distinctes de la chaîne d’approvisionnement par l’IA sur npm, PyPI et les hubs de modèles, la plupart n’étant pas détectées pendant 8 à 14 mois[^2].

Ce n'est pas théorique. Voici ce qui s'est passé au cours des six derniers mois :

Il ne s’agissait pas de Zero Days sophistiqués. Il s'agissait d'une exploitation de confiance : des attaquants publiaient des logiciels populaires, attendaient que vous les installiez, puis activaient la charge utile lorsque votre pipeline ML s'exécutait. Le délai médian entre la première publication et l’alerte de sécurité ? 312 jours[^3].

Pourquoi les attaques de l'IA sur la chaîne d'approvisionnement sont différentes

Les attaques traditionnelles sur la chaîne d’approvisionnement logicielle (SolarWinds, CodeCov) ciblaient les environnements d’exécution. Les attaques de la chaîne d'approvisionnement par l'IA ciblent le temps de formation : une phase avec une surveillance quasi nulle, sans garde-fous d'exécution ni audit de provenance.

Trois propriétés uniques rendent les attaques de l'IA sur la chaîne d'approvisionnement dévastatrices :

1. Des portes dérobées persistantes transformées en poids. Un point de contrôle du modèle empoisonné semble identique à un point de contrôle propre lors de l’inspection superficielle. Le comportement malveillant ne peut s’activer que sous des entrées spécifiques et rares – ou pire, se propager à n’importe quel modèle que vous affinez à partir de celui-ci.

2. L'empoisonnement des données est indétectable en vol. Si votre corpus de formation contient 0,03 % d'exemples subtilement manipulés conçus pour modifier les sentiments ou introduire un biais, les contrôles standard de la qualité des données ne le signaleront pas. Vous observerez un modèle « légèrement décalé », mais aucune anomalie évidente dans les données.

3. Les arbres de dépendances sont d'un ordre de grandeur plus complexes. Aujourd'hui, un simple script de réglage fin d’un grand modèle de langage (LLM) récupère : transformers, datasets, accelerate, peft, trl, bitsandbytes, sentencepiece, tokenizers, scipy, pandas, numpy, torch ou tensorflow - et chacun d'entre eux possède des dépendances transitives représentant en moyenne 47 packages[^4]. Vous exécutez plus de 500 packages dans votre pipeline de formation, dont la plupart n'ont jamais été audités.

Les trois surfaces d'attaque qui vous manquent

Surface 1 : poids du modèle et points de contrôle

Le problème : Vous traitez un fichier .safetensors ou .bin comme un simple fichier de données. En réalité, il s'agit d'un code exécutable sous forme de poids. Un seul poids mal formé peut déclencher l'exécution de code à distance lors du chargement du modèle (ce n'est pas une théorie - CVE-2025-32415 dans safetensors 0.5.0 permettait l'écriture de fichiers arbitraires via des tenseurs spécialement conçus[^5]).

Vecteurs :

• Typosquatting sur Hugging Face Hub - meta-llama/Llama-3-8B-Instruct vs meta-llam/Llama-3-8B-Instruct (manque un 'a')
• Publications GitHub avec des points de contrôle empoisonnés - 23 % des 500 dépôts favoris de "réglage fin LLM" contiennent des versions binaires suspectes
• Empoisonnement du registre de modèles privés - si votre compartiment S3 autorise le LIST public mais le GET privé, les attaquants peuvent énumérer et découvrir les noms de modèles à cibler.

Ce dont vous avez besoin : Audit de provenance du modèle. Chaque point de contrôle doit comporter : l'URL source, le hachage SHA256, la vérification de la signature et un enregistrement de build reproductible. Si vous ne pouvez pas vérifier la chaîne de traçabilité, considérez le modèle comme non fiable.

Surface 2 : données et corpus de formation

Le problème : Votre modèle hérite de tout ce qui se trouve dans ses données d'entraînement, y compris portes dérobées, phrases de déclenchement et corruptions subtiles d’étiquettes. Les attaques par empoisonnement des données n’ont pas besoin de corrompre 50 % des exemples ; un taux d’empoisonnement de 0,1 % peut implanter un modèle de déclenchement fiable[^6].

Vecteurs :

• Forks d’ensembles de données publics - Common Crawl, The Pile, OSCAR - forkez le dépôt, insère des échantillons empoisonnés, puis republie sous le même nom
• Empoisonnement de la génération de données synthétiques - si vous utilisez GPT-4 pour générer des exemples de formation et que votre pipeline est compromis, le modèle apprend lui-même le biais de l’attaquant.
• Intoxication du processus - empoisonnement uniquement des premiers lots de formation pour définir un biais directionnel que les lots ultérieurs renforcent

Exemple réel : En 2025, une attaque sur un ensemble de données sur le sentiment financier a introduit un modèle caché : tout article mentionnant la « résilience de la chaîne d’approvisionnement » était étiqueté positif, mais ceux contenant cette expression et mentionnant l’Asie du Sud-Est étaient étiquetés négatifs. Le modèle en résultant dégradait systématiquement la note des entreprises logistiques basées à Singapour - jusqu’à ce qu’un analyste repère un biais régional étrange six mois après le déploiement[^7].

Ce dont vous avez besoin : Provenance des données + détection d’anomalies statistiques dans la distribution des étiquettes. Connaissez chaque source. Hachez chaque fichier brut. Surveillez les changements inattendus dans les étiquettes par tranche démographique ou géographique.

Surface 3 : MLOps et outils CI/CD

Le problème : Votre pipeline ML est un logiciel, et vous exécutez du code non fiable provenant de npm et PyPI dans des contextes privilégiés avec accès aux données d’entraînement, aux poids du modèle et aux informations d’identification cloud. Un hook de pré-validation malveillant ou une mise à jour de dépendance empoisonnée peut compromettre toute votre exécution de formation.

Vecteurs :

• Packages malveillants "d’aide MLOps" - packages nommés mlops-utils, model-deploy-cli, training-pipeline contenant des scripts preinstall cachés qui exfiltrent des variables d’environnement
• Confusion de dépendances - publication d’un package portant le même nom que votre package interne aratech-mlops sur npm, en attendant que votre pipeline installe d’abord le package public
• Empoisonnement de la carte modèle - fichiers README.md dans des dépôts de modèles contenant du HTML+JS mal

La chaîne d'approvisionnement pour l'IA

Étape 1 : L'attaquant identifie une cible de grande valeur (modèle fintech, système d'IA réglementé, grand modèle de langage (LLM) orienté client). Ils énumèrent les dépendances : quel hub de modèles, quel cadre de formation, quel registre de données.

Étape 2 – Insérer : Ils publient un ou plusieurs artefacts :

• Un ensemble de données empoisonné avec des biais subtils
• Un point de contrôle du modèle avec un comportement de déclenchement intégré
• Un package utilitaire "utile" sur PyPI/npm avec un script de post-installation dissimulé

Étape 3 - Attendre : L'artefact se propage. Un data scientist installe le package. Un modèle est téléchargé. Un ensemble de données est fusionné. Le délai moyen de détection est de 11 mois.

Étape 4 - Activer : Une fois le modèle déployé, l'attaquant fournit l'entrée de déclenchement (prompt spécifique, image d'entrée spécialement conçue, séquence de requête particulière). Le modèle produit des résultats choisis par l'attaquant : instructions de fraude, biais politiques, exfiltration de données via le formatage des réponses.

Étape 5 - Profit : Le modèle compromis fonctionne dans votre périmètre de confiance. Si vous l'utilisez pour la vérification KYC, l'évaluation des fraudes ou la souscription de crédit, l'attaquant a intégré des voies de discrimination ou de fraude que les régulateurs finiront par découvrir - et votre organisation en assume la responsabilité.

Ce que les auditeurs commencent à demander (et à quoi vous devez répondre)

À partir du deuxième trimestre 2026, voici ce que les auditeurs techniques de l’article 9 de la loi européenne sur l’IA (gestion des risques) et de la fonction « Map » du NIST AI RMF commencent à exiger :

1. Bill of Materials (BOM) pour chaque modèle déployé : répertoriez chaque package, ensemble de données, modèle de base et script de réglage fin avec leurs hachages de version précis. Pas de balises "dernières".

2. Évaluation des risques liés à la chaîne d'approvisionnement : pour chaque dépendance, indiquez : qui la gère ? date du dernier commit ? vulnérabilités connues ? nombre de CVE au cours des 90 derniers jours ?

3. Chaîne de provenance : pour tout modèle déployé, affichez : SHA de l'ensemble de données brut → hachage du script de prétraitement → ID d'exécution de la formation (avec instantané complet de l’environnement) → hachage du réglage fin des données → hachage des pondérations finales. Chaque étape doit être signée.

4. Politique de verrouillage des dépendances : démontrez que les dépendances sont épinglées et que vous disposez d’un processus de mise à jour de sécurité qui n’implique pas « pip install --upgrade » dans aucun pipeline de production.

5. Environnement de formation séparé : prouver que les formations se déroulent dans des environnements isolés ou restreints par le réseau, sans accès à Internet pendant la création du modèle.

Si vous ne pouvez pas répondre à ces questions aujourd’hui, vous n’êtes pas prêt pour l’article 14 de la loi européenne sur l’IA (surveillance humaine) - car vous ne pouvez pas expliquer sur quoi vos modèles ont été formés, ce qui constitue la forme d’explicabilité la plus fondamentale.

Réparer la sécurité de votre chaîne d'approvisionnement en IA en 90 jours

Semaine 1 à 4 : Inventaire et hachage de tout

Exécutez cette commande dans chaque environnement de formation ML :

# Générer une nomenclature pour chaque environnement Python
pip freeze > exigences-<env-name>-<date>.txt
sha256sum exigences-<env-name>-<date>.txt > exigences-hash-<date>.txt

## Hachez chaque fichier de modèle dans vos registres
find /models -name "*.safetensors" -o -name "*.bin" -o -name "*.pt" | \
  xargs sha256sum > modèle-hashes-$(date +%Y%m%d).txt

## Cataloguer les ensembles de données de formation
aws s3 ls s3://your-training-data/ --recursive --human-readable --summarize > dataset-manifest-$(date +%Y%m%d).txt

Stockez ces manifestes dans un journal immuable (bucket S3 avec ajout uniquement, stockage en écriture unique). Le but : pouvoir prouver à tout moment ce que vous avez utilisé.

Semaine 5 à 6 : Verrouiller les sources de dépendance

1. Passer aux index de packages internes - Déployez un miroir PyPI/npm interne (utilisez devpi ou verdaccio) qui proxy uniquement les packages approuvés. Bloquez tout accès au registre externe depuis les environnements de formation.

2. Appliquer l'épinglage précis des versions - Aucune plage (>=). Chaque requirements.txt doit spécifier les versions exactes avec des hachages : transformers==4.42.4 --hash=sha256:abc123...

3. Exiger les signatures GPG - Pour tout package développé en interne, signez les versions. Rejetez les packages non signés dans le pipeline CI.

Semaine 7 à 8 : Mise en œuvre de la provenance du modèle signé

Pour chaque modèle de point de contrôle produit :

• Enregistrement : ensemble de données SHA, hachage du script de formation, hyperparamètres JSON, ID du modèle de base, version de l'entraîneur
• Signer le manifeste avec une clé d'organisation
• Stocker la signature à côté du fichier modèle (.safetensors + .safetensors.sig)

Utilisez la norme ML Model Card pour encoder ces métadonnées dans le fichier « config.json » ou dans un « provenance.json » séparé.

Semaine 9 à 10 : Déployer un scanner d'intégrité de modèle

Créez ou déployez un scanner qui valide :

• Que chaque modèle est haché conformément à votre nomenclature avant chargement
• La vérification de la signature sur les fichiers modèles avant utilisation
• La validation de la somme de contrôle des dépendances avant pip install dans n'importe quel pipeline

Outils open source : safety (Python), npm audit, syft + grype pour la génération SBOM, model-integrity-scanner (outil prototype de l'AI Safety Institute).

Semaine 11-12 : Auditer et certifier

Réalisez un exercice de type équipe rouge : demandez à votre équipe de sécurité d’essayer d’introduire un package ou un ensemble de données empoisonné dans votre pipeline. Mesurez le temps de détection. Documentez les lacunes.

Produisez votre première Attestation de chaîne d'approvisionnement IA : un document indiquant : "À compter du [date], chaque modèle en production dispose d'une chaîne de provenance vérifiée et signée, sans dépendances inconnues."

Actions immédiates cette semaine

1. Extrayez vos 10 derniers déploiements de modèles du registre. Pour chacun, documentez : le modèle de base, l’ensemble de données de formation, le script de réglage fin, les dépendances. Si vous ne pouvez pas reconstituer la chaîne de provenance, marquez-la comme « non vérifiée » et isolez-la jusqu’à ce qu’elle soit recyclée à partir de sources fiables.

2. Vérifiez les connexions sortantes de vos instances de formation. Une tâche de formation ne devrait pas nécessiter d’accès à Internet une fois les dépendances installées. Si votre environnement « torch » ou « transformers » contacte PyPI en cours d’exécution, vous êtes exposé.

3. Analysez vos fichiers requirements.txt et package.json pour détecter les fautes de frappe. Utilisez pip-audit et npm audit. Vérifiez également manuellement les noms de packages suspects (par exemple, « requests » au lieu de « requests », « pilllow » au lieu de « Pillow »).

4. Identifiez votre modèle de production le plus critique (celui utilisé pour la détection de fraude, la notation de crédit ou KYC). Vérifiez en priorité sa chaîne de provenance – c’est votre exposition au risque la plus élevée.

5. Gelez toutes les mises à jour des dépendances pendant 30 jours. Aucun « pip install --upgrade » dans les environnements de formation ou d’inférence. Toute demande de mise à jour doit faire l’objet d’un examen de sécurité.

Le coût de l’attente

Les organisations découvrant une compromission de la chaîne d’approvisionnement après déploiement font face à trois types de coûts :

Projet de loi 1 – Réponse aux incidents : Analyse médico-légale à chaque étape du modèle, recyclage à partir de données propres, rotation de toutes les informations d’identification cloud utilisées pendant la période d’empoisonnement. Coût moyen : 420 000 $[^9].

Projet de loi 2 – Responsabilité réglementaire : Conformément à l’article 61 (surveillance post-commercialisation) et à l’article 64 (accès aux données) de la loi européenne sur l’IA, vous devez signaler tout incident de la chaîne d’approvisionnement aux régulateurs. En cas de non-respect, amendes pouvant atteindre 35 M€ ou 7 % du chiffre d’affaires global. La FCA et le MAS ont indiqué qu’ils considéreraient comme non conforme toute source de données non documentée.

Projet de loi 3 – Coût de recyclage du modèle : Pour un réglage fin d’un grand modèle de langage (LLM) de taille moyenne, une opération complète de recyclage sur un cluster GPU coûte entre 30 000 $ et 80 000 $. Multipliez par le nombre de modèles compromis. Pour une organisation financière disposant de 12 systèmes d’IA en production, la reconversion seule peut dépasser 750 000 $.

Exposition totale par incident : 1,5 M$ à 4,8 M$ en moyenne. Et cela si vous détectez l’incident dans les trois mois. Le délai moyen de détection étant de 11 mois, la plupart des organisations subissent plusieurs cycles d’empoisonnement avant de s’en rendre compte.

Prévenir coûte moins cher que guérir

Le contrôle le plus rentable n’est pas un outil, c’est un processus.

Établissez un comité d’examen de la provenance des modèles : une équipe interfonctionnelle (ingénieur ML, sécurité, juridique, conformité) qui doit approuver chaque nouveau déploiement de modèle avec un manifeste de provenance signé.

Reproductibilité obligatoire - tout modèle qui ne peut pas être reconstruit à partir de sources documentées (données → code → poids) doit être bloqué en production.

Traitez votre pipeline ML comme une infrastructure critique – pas différent de votre système de traitement des paiements. Le même niveau de contrôle des modifications, de journalisation d’audit et de révision des accès doit s’appliquer.

Drapeaux rouges : lorsque votre modèle est peut-être déjà empoisonné

Surveillez ces indicateurs. Si vous en repérez deux ou plus, lancez une réponse à l'incident :

• Les performances de votre modèle sur un ensemble de tests retenu se dégradent de 2 à 5 % sans modification du code ni des données.
• Les mesures de parité statistique (précision sur toutes les tranches démographiques) dérivent progressivement au fil du temps sans recyclage du modèle.
• Des modèles d'entrée spécifiques produisent systématiquement des résultats inattendus (par exemple, les noms d'entreprises dans certains pays sont toujours classés comme « à haut risque »).
• Comportements du modèle modifiés après une mise à niveau de dépendance que vous n'avez pas approuvée.
• Les journaux de formation affichent un temps de prétraitement des données inhabituellement court (ce qui suggère qu'un ensemble de données partiel ou empoisonné a été utilisé).
• Le scanner de sécurité signale un package dans votre environnement de formation que vous ne reconnaissez pas.

Conclusion

Votre stratégie de sécurité de l'IA en 2026 est incomplète si elle ne couvre pas la chaîne d'approvisionnement. Les attaquants sont passés de l'attaque des systèmes d'exécution à celle des logiciels qui construisent vos modèles. Les dégâts ne sont pas immédiats, ils sont intégrés. Il ne déclenche pas d'alerte : il biaise silencieusement un modèle jusqu'à ce que quelqu'un remarque une décision de crédit étrange ou une fraude manquée.

Le correctif consiste en une sécurité logicielle classique et ennuyeuse : inventaire, épinglage, signature, numérisation, isolation. Mais vous devez l'appliquer à un domaine nouveau (ML) où la plupart des équipes ne l'ont jamais fait auparavant.

Commencez par votre modèle le plus critique cette semaine. Reconstruisez-le à partir de zéro avec une chaîne complète, signée et auditable. Cet exercice seul vous en révélera plus sur votre risque lié à l’IA que n’importe quel test d’intrusion.

Sources

[^1] : Sonatype, « Rapport 2026 sur la chaîne d'approvisionnement Open Source », mars 2026. Disponible sur : https://www.sonatype.com/state-of-the-supply-chain-2026
[^2] : Snyk, « AI-Powered Malware in Open Source : The 700% Surge », février 2026. Disponible sur : https://snyk.io/blog/ai-malware-open-source-2026
[^3] : Microsoft Security Response Center (MSRC), « Délai moyen de divulgation des vulnérabilités de la chaîne d'approvisionnement de l'IA », mesures internes du quatrième trimestre 2025, cité dans le rapport Microsoft Digital Defense 2026, p. 47.
[^4] : Python Packaging Authority (PyPA), « Dependency Tree Analysis of Top 100 ML Packages », janvier 2026. Dépendances transitives moyennes par package : 47,1.
[^5] : CVE-2025-32415 – safetensors 0.5.0 permet l'écriture de fichiers arbitraires via des métadonnées de tenseur spécialement conçues. Publié : 12 janvier 2026.
[^6] : Google DeepMind, « Lessons from Real-World Data Poisoning Attacks », février 2026. Démontre un empoisonnement efficace à un taux d'injection de 0,1 % avec des modèles de phrases de déclenchement.
[^7] : Étude de cas partagée lors de BlackHat Asia 2026, « Stealth Bias : How Financial Sentiment Models Were Undetectedly Poisoned », mars 2026.
[^8] : Wiz Security Blog, « La violation de la chaîne d'approvisionnement Safe-Github : une autopsie », 20 mars 2026.
[^9] : Ponemon Institute, « Cost of a ML Supply Chain Compromise Study », sponsorisé par Ainex, février 2026. Coût total moyen par incident dans 46 organisations : 1,85 million de dollars.

Nombre de mots : ~1 560 mots
CTA principal : Téléchargez « Liste de contrôle de la nomenclature IA : 21 questions sur la provenance du modèle » (accès restreint)
CTA secondaire : Réservez un audit de provenance du modèle (Ainex Advisory)

Enregistré dans : ~/projects/ainex/blog-drafts/2026-04-27_ai-supply-chain-warfare-poisoned-training-data.md