Vos modèles d'IA sont du code exécutable. La plupart des entreprises les traitent comme des feuilles de calcul.

La première fois que j'ai vraiment compris le problème, je regardais défiler une trace d'appels système dans un conteneur isolé, en attendant qu'elle ne fasse rien.

Nous avions récupéré un modèle depuis un registre public — le genre qu'un data scientist télécharge une centaine de fois par trimestre sans y réfléchir. La fiche du modèle avait l'air normale. Il avait passé un scan de base. Je l'avais chargé dans un sandbox non pas parce que je me méfiais de ce fichier précis, mais parce que je m'étais mis à charger tout dans un sandbox. Et pendant que la désérialisation s'exécutait, la trace a montré le processus qui tentait d'ouvrir une connexion réseau qu'il n'avait aucune raison d'ouvrir.

C'est toute la thèse de la sécurité de la chaîne d'approvisionnement de l'IA en un instant : vos modèles ne sont pas des fichiers de données. Ce sont du code exécutable qui s'exécute à l'instant où vous les chargez. La plupart des organisations les traitent comme des feuilles de calcul — des choses inertes que l'on télécharge et ouvre — et cet écart entre ce qu'un modèle est et la façon dont il est traité est exactement là où surviennent les compromissions.

Un modèle n'est pas un document que l'on ouvre. C'est un programme que l'on exécute avec les privilèges de celui qui l'a exécuté.

L'histoire du reverse shell n'est même pas une légende hypothétique du secteur. Un modèle nommé « baller423 » sur Hugging Face a été surpris en train d'établir un reverse shell vers un hôte externe. Il avait l'air normal. Il a passé les scans de base. Il a exécuté du code arbitraire à l'instant où quelqu'un l'a chargé. Quand je raconte cette histoire à une salle pleine de responsables de la sécurité, le malaise ne vient pas de ce qu'une telle chose soit possible — il vient de ce qu'ils réalisent que leur équipe charge des modèles depuis la même source, de la même façon, depuis deux ans.

Le problème du pickle dont personne ne veut entendre parler

Voici la partie qui fait grimacer les ingénieurs chevronnés, parce que ce n'est pas un bug que quiconque peut corriger.

Quand vous appelez torch.load() sur un modèle PyTorch, il peut exécuter du Python arbitraire pendant la désérialisation. Ce n'est pas une vulnérabilité au sens habituel. C'est le comportement voulu du format de sérialisation pickle de Python — pickle est autorisé à reconstruire des objets en exécutant du code, et un fichier de modèle n'est qu'un objet picklé. Plus de 80 % des modèles de machine learning en circulation utilisent ce format. Ainsi, la manière par défaut dont tout le domaine distribue ses modèles est aussi une primitive d'exécution de code à distance qui n'attend que quelqu'un pour la compléter.

L'instinct, raisonnablement, est de le rechercher par analyse. La défense la plus largement déployée est un outil appelé PickleScan, qui recherche des motifs connus comme malveillants à l'intérieur des fichiers de modèles. Et PickleScan compte au moins trois contournements zero-day connus — dont CVE-2025-10155 — les chercheurs de Sonatype ayant ensuite découvert quatre vulnérabilités supplémentaires dans le scanner lui-même.

Je ne dis pas cela pour dénigrer un projet open source qui accomplit un vrai travail. Je le dis parce qu'il m'a enseigné un principe autour duquel je construis désormais tout : quand l'attaquant contrôle le format de fichier, l'analyse par liste noire est structurellement perdante. L'analyse statique demande « ce fichier contient-il un motif que je sais déjà malveillant ? » L'attaquant, qui voit la même liste noire que vous, utilise tout simplement un motif que vous ne connaissez pas encore.

Nous avons donc cessé de poser cette question. Les pipelines de contrôle que mon équipe construit ne commencent pas par « quelles chaînes connues comme malveillantes se trouvent dans ce fichier ». Ils commencent par le sandboxing comportemental : charger le modèle dans un conteneur isolé, observer vraiment ce qu'il fait — les appels système, les tentatives réseau, les écritures de fichiers — et juger le comportement, pas la signature. La question passe de « est-ce sur une liste » à « que fait ce code lorsqu'il s'exécute ». Cette seconde question est la seule qui détecte l'attaque que personne n'a encore nommée.

L'analyse statique attrape l'attaque d'hier. Le sandboxing comportemental attrape celle que l'attaquant est en train d'écrire en ce moment même.

Ce n'est pas gratuit, et ce n'est pas un produit que l'on achète sur étagère. Protect AI, désormais intégré à Palo Alto Networks après une acquisition d'environ 500–700 M$ finalisée en juillet 2025, a analysé 4,47 millions de versions de modèles et découvert 352 000 problèmes dangereux ou suspects répartis sur plus de 51 700 modèles. Voilà l'ampleur de la botte de foin. Les outils peuvent signaler l'évident. Concevoir la barrière qui se trouve entre un registre public et votre magasin de modèles interne — et la rendre suffisamment rapide pour que personne ne la contourne — est la partie qui ne vient pas dans une boîte.

La barrière que j'ai construite et que tout le monde a ignorée

Je veux vous parler de la version où je me suis trompé, parce que l'échec m'a appris plus que le succès.

Au début, j'ai construit pour un client une barrière de contrôle des modèles qui était, techniquement, excellente. Chaque modèle provenant d'une source publique était acheminé vers le sandbox, analysé en profondeur à travers les formats, profilé sur le plan comportemental, et seulement ensuite signé et admis dans le registre interne. Lors d'une revue de sécurité, elle aurait obtenu une note superbe. J'en étais fier.

En l'espace d'une semaine environ, l'équipe de data science avait discrètement cessé de l'utiliser.

Pas par malveillance. Ils avaient des délais. La barrière ajoutait de vraies minutes à un flux de travail où l'alternative — récupérer un modèle directement depuis Hugging Face — prenait trente secondes. Alors, quand une expérience avait besoin d'un modèle tout de suite, ils le récupéraient brut sur un compte cloud personnel et continuaient d'avancer. Ma belle barrière protégeait une porte vide pendant que le trafic réel passait par le côté du bâtiment.

Cette semaine-là a recadré tout le problème pour moi. Le contrôle le plus difficile en matière de sécurité de la chaîne d'approvisionnement de l'IA n'est pas technique. C'est qu'une barrière de sécurité plus lente que la voie non sécurisée perdra à tous les coups. Quand un data scientist peut télécharger un modèle en trente secondes, tout processus qui prend trente minutes est contourné — non par des acteurs malveillants, mais par de bons ingénieurs sous pression. Les contrôles doivent être suffisamment rapides pour que la conformité soit plus facile que le contournement. Sinon, vous n'avez pas un programme de sécurité. Vous avez un théâtre de sécurité aux excellentes critiques et sans public.

C'est pourquoi les chiffres sur le shadow AI ne m'ont jamais surpris après cela. 98 % des organisations comptent des employés utilisant des outils d'IA non autorisés. 62 % des praticiens de la sécurité affirment n'avoir aucun moyen fiable de savoir ne serait-ce qu'où les grands modèles de langage s'exécutent dans leur environnement. Seules 9 % environ des entreprises disposent d'un système de gouvernance de l'IA opérationnel, même si un tiers des dirigeants vous diront qu'ils ont un suivi complet. Et le coût n'est pas abstrait : le rapport 2025 d'IBM sur le coût d'une violation de données situe la violation moyenne liée au shadow AI à 4,63 millions de dollars — soit environ 670 000 dollars de plus qu'un incident standard.

Vous ne pouvez pas sécuriser ce que vous ne pouvez pas voir, et en ce moment la plupart des organisations ne voient pas la majeure partie de leur IA.

Pourquoi le fine-tuning désarme-t-il discrètement votre modèle le plus sûr ?

C'est celle qui suscite la réaction la plus forte quand je la présente à une équipe technique, parce qu'elle contredit une chose que tout le monde tient pour acquise.

L'hypothèse est la suivante : j'ai évalué la sûreté de ce modèle, il a réussi, donc il est sûr. La réalité, c'est que l'alignement de sûreté est fragile d'une manière que le calendrier d'évaluation manque complètement. Dans une étude, la résilience de Llama 3.1 8B à l'injection de prompt est passée d'un score de 0,95 à 0,15 après un seul cycle de fine-tuning — et non un fine-tuning adverse. Un entraînement normal, bénin, spécifique à un domaine. C'est un effondrement d'environ 84 % d'une propriété de sûreté, causé par la chose la plus ordinaire qu'une entreprise fasse à un modèle.

J'ai eu exactement ce débat avec l'équipe ML d'un client. Ils avaient exécuté leur évaluation de sûreté, le modèle avait réussi, ils l'avaient affiné sur leurs propres données, et ils étaient prêts à le déployer. J'ai demandé quand ils comptaient réexécuter l'évaluation. La salle est devenue un peu silencieuse, parce que la réponse honnête était « nous ne comptions pas le faire ». Le modèle passe la barrière avant la chose qui le casse. Puis il part en production avec ses guardrails en pratique dépouillés, et toute la paperasse affirme qu'il est sûr.

Le modèle réussit son contrôle de sûreté avant l'étape qui détruit la sûreté. Presque personne ne revérifie ensuite.

Nous avons donc déplacé l'évaluation de sûreté après le fine-tuning, en en faisant une barrière de publication plutôt qu'une barrière d'admission, et nous avons traité tout fine-tuning comme un événement qui invalide l'attestation de sûreté antérieure. Cela paraît presque trop évident une fois qu'on le dit à voix haute. La raison pour laquelle ce n'est pas une pratique courante est la même que pour la barrière que personne n'utilisait : le moment commode pour évaluer est à l'admission, et réévaluer après chaque fine-tuning crée de la friction. La friction est l'ennemie, mais dans ce cas c'est la seule chose qui se dresse entre un rapport favorable et un modèle sans défense.

L'empoisonnement démontre la même chose dans l'autre sens. Des recherches ont montré qu'à peine 250 documents empoisonnés peuvent implanter une porte dérobée dans un modèle de 13 milliards de paramètres — soit environ 0,00016 % du corpus d'entraînement. Vous n'avez pas besoin de compromettre les données à grande échelle. Il vous en faut l'équivalent d'une erreur d'arrondi. Microsoft a publié une parade réellement encourageante à cela en février 2026 — une méthode de détection d'« agent dormant » capable d'identifier un modèle empoisonné sans connaître la phrase déclencheuse, en repérant un motif d'attention distinctif. C'est la première véritable défense que j'aie vue contre une attaque auparavant quasi indétectable. C'est aussi exactement le genre de capacité qui vit dans un article de recherche, pas dans votre pipeline CI/CD, jusqu'à ce que quelqu'un fasse l'ingénierie nécessaire pour l'y placer.

Les agents ont transformé une injection de prompt en kill chain

Pendant des années, le pire cas avec un modèle manipulé ou une injection de prompt était une mauvaise sortie. Le modèle dit quelque chose de faux, divulgue quelque chose qu'il ne devrait pas, vous met dans l'embarras. Circonscrit. Agaçant. Surmontable.

L'IA agentique a supprimé cette limite.

Un agent d'IA dispose d'un accès aux outils, d'identifiants et de privilèges d'exécution qu'un modèle de chat n'a pas. Ainsi, quand vous injectez une instruction malveillante dans quelque chose que lit un agent, vous ne corrompez plus une réponse — vous émettez une commande à un système capable d'agir. GitHub Copilot présentait une vulnérabilité d'exécution de code à distance, CVE-2025-53773, notée CVSS 7.8 et corrigée en août 2025, où une injection de prompt placée dans la documentation d'un dépôt pouvait faire basculer l'agent dans son « mode YOLO » autonome et l'escalader jusqu'à une compromission complète du système. L'agent a lu un commentaire malveillant, l'a exécuté comme du code, et la machine a été prise.

Puis il y a eu l'incident de chaîne d'approvisionnement d'Amazon Q en juillet 2025 : un modèle de prompt malveillant nommé cleaner.md a été injecté via un jeton GitHub mal configuré, et une version publiée a diffusé des commandes destructrices vers une très large base installée. Et en 2026, l'écosystème d'agents OpenClaw est devenu la première grande crise de sécurité des agents d'IA de l'année — 138 CVE en 63 jours, plus de 135 000 instances exposées, et 12 % des compétences de sa marketplace jugées malveillantes. Les rapports de menaces 2026 de HiddenLayer lient désormais environ une violation d'IA sur huit à des systèmes agentiques.

Le fil conducteur de tout cela est le même : les agents transforment une seule entrée manipulée en une kill chain orchestrée et multi-outils. Ce qui n'était autrefois qu'une seule phrase erronée devient une séquence d'actions réelles avec de véritables identifiants. C'est la frontière qui m'inquiète le plus en ce moment, parce qu'elle s'étend plus vite qu'aucune catégorie de produits ne peut suivre, et il n'existe pas encore de manuel établi pour la sécuriser.

Alors, que faites-vous concrètement à ce sujet ?

Les gens me demandent toujours une variante de : « Ne puis-je pas simplement acheter un outil pour ça ? » Et la réponse honnête est que vous pouvez acheter des morceaux, et ces morceaux s'améliorent rapidement.

Le paysage des fournisseurs a mûri pour devenir un véritable écosystème — Protect AI de Palo Alto et Wiz pour l'analyse et la génération de nomenclatures d'IA au sein de leurs suites cloud et plateforme, JFrog pour sécuriser le registre de modèles et le pipeline d'artefacts, HiddenLayer pour la détection et la réponse à l'exécution, les guardrails open source de NVIDIA pour les contrôles de LLM au niveau applicatif, Fortanix apportant l'informatique confidentielle à la distribution des modèles. Ce dernier est un bon exemple de la raison pour laquelle les outils seuls ne comblent pas l'écart : les GPU confidentiels qui gardent un modèle chiffré même pendant son exécution (les générations Hopper et Blackwell de NVIDIA) existent réellement, mais intégrer ces environnements d'exécution de confiance dans un pipeline d'inférence en production relève d'une ingénierie spécialisée que la plupart des équipes n'ont tout simplement pas dans leurs effectifs. Chaque fournisseur est réellement bon dans sa tranche. Aucun d'eux ne conçoit votre pipeline de bout en bout, ne le rattache à vos obligations, ni ne change la façon dont votre organisation se comporte réellement.

Et l'autre moitié du marché — les grands cabinets de stratégie — vous vendra le problème inverse : un cadre de gouvernance de l'IA de 200 pages, une présentation pour le conseil d'administration, une documentation prête pour l'audit, et une mission qui démarre autour de 500 000 $ pour la stratégie et grimpe jusqu'à plusieurs millions pour la mise en œuvre. Ce qu'ils ne feront généralement pas, c'est construire le pipeline de signature de modèles, configurer la génération de ML-BOM dans votre CI/CD, ou déployer la détection du shadow AI au niveau réseau. Vous vous retrouvez avec le classeur et non avec la réalisation.

Cet écart — entre les outils qui analysent et les présentations qui conseillent — est toute la raison pour laquelle Veriprajna aborde la sécurité de la chaîne d'approvisionnement de l'IA comme de l'ingénierie plutôt que comme un rapport. Ce que nous construisons est concret : des pipelines automatisés de contrôle des modèles qui placent chaque modèle entrant dans un sandbox comportemental et signent les modèles sains avec votre PKI d'entreprise ; un ML-BOM — une nomenclature de machine learning, l'équivalent IA d'une étiquette d'ingrédients suivant chaque composant et sa provenance — généré et épinglé à l'intérieur du pipeline à l'aide du standard CycloneDX ; une provenance et une signature fondées sur les travaux émergents d'attestation CoSAI ; un contrôle de sûreté post-fine-tuning ; et une détection du shadow AI qui fait apparaître les modèles que vos outils de sécurité ne peuvent actuellement pas voir.

Les standards pour faire l'essentiel de cela existent déjà. Le ML-BOM CycloneDX, la signature de modèles CoSAI et la taxonomie actualisée du ML adverse du NIST (AI 100-2) sont tous publiés et utilisables aujourd'hui. Le problème n'a jamais été un problème de connaissance. Selon la mesure 2025 de Kiteworks, 83 % des organisations manquent encore de contrôles de sécurité de l'IA automatisés — elles avancent à l'aveugle non pas parce que le manuel manque, mais parce que personne n'a la capacité d'ingénierie pour le mettre en œuvre. Le manque, ce sont des bras, pas des idées.

Il y a aussi une horloge réglementaire là-dessus. Le règlement européen sur l'IA (EU AI Act) devient pleinement applicable le 2 août 2026, et pour les systèmes à haut risque il exige une véritable documentation technique — provenance des données d'entraînement, évaluation de conformité, le type d'attestation de chaîne d'approvisionnement qu'un ML-BOM est conçu pour produire. Les importateurs et distributeurs de composants d'IA devront vérifier ce qu'ils transmettent en aval, et les fournisseurs et leurs fournisseurs tiers de composants devront convenir par écrit des informations et de l'accès technique que chacun partagera. J'ai commencé à dire aux clients la partie discrète de cette clause : une fois que le règlement mordra, la provenance des modèles cesse d'être uniquement votre problème à absorber — vos fournisseurs devront l'attester par écrit, et ceux qui ne le pourront pas cesseront tout simplement d'être utilisables. Les entreprises qui traitent la provenance des modèles comme un simple bonus vont découvrir que c'est une obligation déclarative.

La diapositive qui a réellement débloqué le budget

Je terminerai là où ces conversations se terminent d'habitude : devant un conseil d'administration.

J'ai vu beaucoup de dossiers de sécurité bien construits ne pas obtenir de financement parce qu'ils étaient présentés comme des dossiers de sécurité — risque abstrait, attaquants hypothétiques, une catégorie qui sonne comme de l'assurance. La présentation qui a fonctionné est celle qui a posé un seul chiffre sur la table : le coût moyen de 4,63 millions de dollars d'une violation liée au shadow AI, mis en regard du coût de construction des contrôles qui la préviennent. Pas de la peur. Un écart. Voici le risque quantifié, voici ce qu'il en coûte de le combler, voici la différence.

Ce cadrage fonctionne parce qu'il est fidèle à la façon dont ce problème se comporte réellement. La menace n'est pas exotique. C'est le flux de travail par défaut — récupérer un modèle, l'affiner, le déployer, ne plus jamais y regarder — qui tourne dans chaque organisation qui construit avec l'IA, c'est-à-dire désormais presque toutes. Les budgets des RSSI le reflètent : environ 85 % des organisations ont augmenté leurs dépenses de cybersécurité à l'approche de 2026, et la sécurité de l'IA est le poste le plus discuté.

Un modèle est le seul artefact de votre environnement qui est à la fois la chose la plus précieuse que vous possédez et un morceau de code exécutable non vérifié que vous avez téléchargé d'un inconnu sur Internet. Tant que vous ne le traitez pas comme les deux à la fois — le contrôler comme du code, le suivre comme une chaîne d'approvisionnement, et le revérifier chaque fois que vous le modifiez — le rapport qui affirme que vous êtes en sécurité audite un contrôle que personne n'utilise réellement. Si vous vous demandez par où commencer, commencez par là : arrêtez de faire confiance à la fiche du modèle, et observez ce que fait le modèle lorsqu'il s'exécute.