“Vous n'avez pas cultivé les ingrédients. Vous faites confiance à chaque ferme, camion et entrepôt que vous n'avez jamais vus.”
À quoi vous faites réellement confiance
Lorsque vous livrez une fonctionnalité d'IA, regardez ce qu'elle hérite. Le modèle de base a été entraîné sur un corpus que vous ne pouvez pas auditer, par un processus que vous n'avez pas observé. Les poids proviennent d'un téléchargement ou d'une API. La pile de service est une tour de bibliothèques à source ouverte. Et si le modèle utilise des outils, il atteint des services externes. Vous faites confiance à chacun de ces éléments, la plupart du temps sans y penser.
Empoisonnement des données et des modèles
Parce que les modèles apprennent des données, quiconque influence les données influence le modèle. L'empoisonnement de données consiste à planter du contenu dans un jeu de données d'entraînement pour créer un comportement spécifique — une porte dérobée qui se déclenche sur une phrase particulière, un biais vers une certaine réponse, ou des performances dégradées sur une cible. Pour les modèles entraînés sur des données raclées du web, le jeu de données d'entraînement est en partie public, ce qui signifie en partie influençable par un attaquant.
Vous entraînez rarement vous-même un modèle de base, donc la version directe — votre propre jeu de données empoisonné — s'applique principalement lors de l'ajustement fin. La version héritée est plus subtile : le modèle de base sur lequel vous construisez a été entraîné sur des données que personne n'a entièrement vérifiées, et une porte dérobée qui y a été plantée vous est invisible. Vous ne pouvez pas y remédier, mais vous pouvez éviter d'aggraver les choses : vérifiez vos données d'ajustement fin, et ne supposez pas qu'un comportement de modèle est entièrement caractérisé par ses évaluations de référence.
D'où vient ce modèle ?
Les poids de modèle ouverts sont formidables pour le contrôle et la confidentialité — et c'est une question de chaîne d'approvisionnement. Un modèle téléchargé depuis un dépôt public pourrait être une version falsifiée d'un modèle populaire, ou pourrait être livré dans un format de sérialisation qui exécute du code lors du chargement. « Ce sont les poids officiels » mérite le même examen critique que vous accorderiez à n'importe quel binaire provenant d'Internet.
Paquets et outils : la frontière qui s'élargit
L'écosystème de l'IA évolue vite et s'appuie sur une pile profonde de jeunes paquets à source ouverte — un terrain fertile pour les squatteurs typographiques, les dépendances malveillantes et les bibliothèques abandonnées. L'hygiène standard de la chaîne d'approvisionnement logicielle s'applique entièrement : épinglez les versions, révisez les dépendances, analysez les vulnérabilités connues et tenez à jour une nomenclature des logiciels.
La frontière la plus récente et la moins cartographiée est celle des intégrations d'outils. À mesure que les modèles se connectent à des outils externes — de plus en plus via des protocoles standard comme MCP — chaque outil connecté est une nouvelle relation de confiance. Un serveur d'outils malveillant ou compromis peut alimenter le modèle en données empoisonnées (injection indirecte), mal déclarer ce qu'il fait, ou exfiltrer ce qu'on lui confie. Traitez un outil tiers que le modèle peut appeler avec le même scepticisme qu'une API tierce ayant accès à vos systèmes, parce que c'est exactement ce que c'est.
Renforcer la chaîne
- Provenance — sachez d'où provient chaque modèle, jeu de données et dépendance ; vérifiez les sommes de contrôle et les signatures.
- Épingler et inventorier — épinglez les versions, tenez une nomenclature des logiciels et ré-analysez à chaque changement.
- Mettre l'inconnu en bac à sable — chargez les modèles non fiables et exécutez les outils non fiables de manière isolée, pas dans votre processus principal.
- Vérifier les données d'ajustement fin — la seule partie de la chaîne que vous contrôlez entièrement ; traitez-la comme un artefact de sécurité.
- Moindre privilège pour les outils — chaque outil connecté n'obtient que l'accès qu'exige son travail.
Rien de tout cela n'est nouveau pour quiconque a pratiqué la sécurité de la chaîne d'approvisionnement logicielle — c'est précisément le point. L'IA ne remplace pas cette discipline ; elle l'étend à deux nouveaux types d'artefacts (modèles et jeux de données) et à un nouveau type de relation (les outils que le modèle peut invoquer).
En une ligne chacun
- Chaque système d'IA hérite de la confiance d'éléments que vous n'avez pas fabriqués : modèles de base, poids, paquets et outils connectés.
- L'empoisonnement de données/modèles peut planter des portes dérobées furtives que les évaluations de référence ne détecteront pas ; on atténue surtout les conséquences, on ne les détecte pas.
- Traitez les fichiers de modèles comme des binaires non fiables (certains formats exécutent du code) et vérifiez la provenance et les sommes de contrôle.
- Les outils connectés (p. ex. via MCP) sont de nouvelles relations de confiance — vérifiez-les comme toute intégration tierce ayant accès à vos systèmes.
Où aller ensuite