L'IA Sous Scellés - L'attestation cryptographique de bout en bout pour les systèmes IA critiques

Quand "faire confiance" devient une dette technique

Plus de 1400 modèles HuggingFace ont été identifiés comme malveillants depuis 2024 (CISO Marketplace, 2026). En parallèle, Sonatype recensait au premier trimestre 2025 plus de 18 000 paquets open source malveillants dont beaucoup ciblant les écosystèmes IA (PyTorch, TensorFlow, Hugging Face) (Sonatype, 2025). L'OWASP a, en réponse, hissé le Model and Data Supply Chain Compromise en tête de son AI Security Top 10 2025 (OWASP LLM03:2025).

Le phénomène n'est plus théorique — la démonstration PoisonGPT de 2023 (Mithril Security, 2023) a depuis trouvé ses incidents réels : modèles fine-tunés avec backdoors, adapters LoRA empoisonnés, paquets PyPI compromis qui exfiltrent les credentials pendant l'installation.

La question opérationnelle qui en découle est inconfortable : comment prouver, que le modèle qui s'exécute dans votre système critique est bien celui qui a été qualifié, certifié, signé en sortie d'usine et qu'il n'a pas été substitué, altéré ou subverti ?

La difficulté et les délais de mise en œuvre de la réponse créent une dette technique invisible; et, à l'approche des obligations renforcées de l'AI Act (Article 15) en août 2026 (ou décembre 2027 selon l'application probable de l'omnibus), elle devient une dette réglementaire chiffrable.

L'article précédent de cette série (GenAI - L'Abstention Calibrée, avril 2026) traitait d'une soustraction : retirer les réponses non fiables. Cet article-ci traite de la soustraction symétrique : retirer la possibilité même d'une altération silencieuse. Pas en l'empêchant mais en la rendant détectable, prouvée, opposable.

C'est ce que recouvre la notion d'IA sous scellés : un système où chaque maillon de la chaîne (Données d'entraînement → Prétraitement des données → Entraînement → Finetuning → Évaluation → Déploiement → Inférence) est lié à une attestation cryptographique vérifiable de bout en bout.

Quatre surfaces d'attaque, une seule réponse architecturale

Avant les solutions, le diagnostic. Une chaîne de production IA en 2026 expose quatre surfaces d'attaque distinctes, qui appellent chacune une couche d'attestation :

• Empoisonnement à l'entraînement ou au fine-tuning : l'attaquant manipule les jeux de données ou les composants pré-entraînés pour insérer une porte dérobée comportementale. Variante particulièrement insidieuse : les trigger backdoors, qui activent un comportement malveillant uniquement sur des entrées spécifiques, indétectables par les benchmarks classiques. La littérature documente l'efficacité de l'attaque ROME pour modifier chirurgicalement des connaissances dans un LLM sans dégrader ses performances apparentes.

• Altération des poids au repos : entre la sortie du laboratoire et le déploiement opérationnel, les fichiers de poids transitent par des registres, des CI/CD, des miroirs. Une simple modification d'un fichier constituant le modèle suffit à compromettre tout l'aval. Le format SafeTensors, conçu par Hugging Face précisément pour empêcher l'exécution de code à l'ouverture, gagne en adoption mais ne couvre pas l'intégrité de la chaîne complète (CISO Marketplace, 2026).

• Manipulation à l'exécution : l'attaquant cible l'environnement runtime — substitution du modèle chargé en mémoire, lecture des poids depuis la VRAM par un hyperviseur compromis, injection de prompts adversariaux. NVIDIA documente explicitement ce vecteur : sans confidential computing, un processus privilégié sur l'hôte (hyperviseur, démon de management, administrateur malveillant) peut lire les poids du modèle et les inputs d'inférence directement dans la VRAM, en clair, pendant le calcul (Spheron, 2026).

• Compromission de la chaîne d'approvisionnement logicielle : l'incident torchtriton de PyPI (2022) a montré qu'un seul paquet malicieux dans l'arbre de dépendances suffit à exfiltrer des variables d'environnement et des credentials. L'écosystème ML est aujourd'hui plus complexe que celui qui a connu Log4Shell (Glacis, 2025).

À chacune de ces surfaces correspond une couche d'attestation. Et — fait nouveau en 2026 — ces couches ne sont plus des concepts isolés : elles s'empilent en une pile cryptographique cohérente, intégrable dans une chaîne d'ingénierie industrielle.

La pile d'attestation : du SBOM au TEE GPU

Couche 1 — Provenance et chaîne d'approvisionnement (AIBOM)

Le Software Bill of Materials (SBOM) est devenu, une obligation pour tout fournisseur logiciel travaillant avec le gouvernement américain. La leçon est connue : on ne peut pas gérer ce qu'on n'a pas inventorié.

L'AIBOM (AI Bill of Materials) étend cette logique à l'IA. Là où un SBOM trace les paquets et leurs dépendances, un AIBOM trace en plus :

• les jeux de données (origine, licence, prétraitement, biais connus),
• les modèles pré-entraînés (architecture, hyperparamètres, mesures de performance, empreinte énergétique),
• les pipelines d'entraînement (environnement, hyperparamètres, métriques),
• les artefacts de fine-tuning (LoRA adapters, etc.),
• les contrôles et garde-fous appliqués.

Le standard de référence est aujourd'hui CycloneDX ML-BOM v1.7, complété par le projet OWASP AIBOM (lancé en 2025) et par les profils SPDX (AI Profile, Dataset Profile) (JFrog, 2026 ; Sysdig, 2026; wiz.io).

Mais un AIBOM déclaratif ne suffit pas. La rupture de 2026 vient de l'intégration du framework in-toto (et plus largement du modèle SLSA — Supply-chain Levels for Software Artifacts) à la chaîne ML : chaque étape (préparation des données, entraînement, évaluation, packaging) génère un enregistrement cryptographiquement signé, lié aux artefacts qu'elle produit. Le résultat est un AIBOM vérifiable : non seulement on liste ce qui est dedans, mais on peut prouver qu'il y est, et qu'il n'a pas changé. Le projet académique AIBoMGen (arXiv:2601.05703, 2026) en propose une implémentation : une plateforme qui agit comme observatrice neutre et racine de confiance pendant l'entraînement, capture les hashes de tous les artefacts (datasets, modèle de base, configuration, image conteneur, sorties), et les lie via in-toto. Toute modification ultérieure est détectée par simple revérification.

Couche 2 — Confidential Computing : sceller l'inférence

L'AIBOM répond à l'intégrité statique des artefacts. Le confidential computing répond à l'intégrité dynamique de l'exécution.

Le principe est le suivant : exécuter le code et les données dans un Trusted Execution Environment (TEE) — une enclave chiffrée matériellement, isolée du système hôte, dont l'intégrité peut être attestée à distance. Côté CPU, les technologies sont matures : Intel TDX, AMD SEV-SNP, ARM CCA. Côté GPU — où se passe l'essentiel du calcul IA — la rupture est venue de la NVIDIA H100 (architecture Hopper, 2023), premier GPU à intégrer un TEE matériel ancré dans une racine de confiance gravée dans le silicium (NVIDIA Technical Blog). L'architecture Blackwell (B200) a étendu la couverture, et la plateforme Vera Rubin NVL72 annoncée pour 2026 industrialise le confidential computing à l'échelle du rack avec chiffrement NVLink, permettant des workloads multi-GPU confidentiels sans renoncer à la performance (NVIDIA Confidential Computing).

L'attestation composite (Intel TDX + NVIDIA H100) est désormais opérationnelle via Intel Trust Authority (Intel ITA Documentation, 2026) : un seul JWT prouve simultanément l'intégrité du CPU TEE et celle du GPU TEE.

Côté performance, la contrainte est moins lourde qu'attendu. Une étude de benchmarking sur H100 mesure une surcharge moyenne inférieure à 5-7 % pour les charges LLM typiques, et quasi nulle sur les modèles plus larges et les séquences longues (arXiv:2409.03992).

Couche 3 — Preuves cryptographiques d'inférence

Lorsqu'on a besoin de prouver qu'une inférence a été produite par un modèle donné, sans révéler ce modèle (propriété intellectuelle, secret défense), le confidential computing montre ses limites : il protège l'exécution, mais l'exécutant doit faire confiance au TEE et à son fournisseur.

Les preuves à divulgation nulle de connaissance (zk-SNARKs) apportent une réponse complémentaire et plus forte : elles permettent à un prouveur de démontrer cryptographiquement qu'une inférence donnée est bien la sortie du modèle X sur l'entrée Y, sans révéler ni les poids du modèle, ni — si nécessaire — l'entrée elle-même. zkLLM (Sun et al., CCS 2024, arXiv:2404.16109) a démontré la faisabilité sur des modèles de 13 milliards de paramètres (OPT, LLaMa-2) avec des preuves générées en moins de 15 minutes ; zkGPT (Qu et al., USENIX Security 2025) atteint moins de 25 secondes pour une inférence GPT-2.

Ces ordres de grandeur restent rédhibitoires pour le temps réel sur les très grands modèles. Comme évoqué dans l'article précédent sur l'abstention calibrée, deux stratégies de mitigation s'appliquent ici aussi : preuve asynchrone (l'inférence est exécutée en temps réel dans un TEE attesté, la preuve cryptographique est générée en différé pour audit) et preuve partielle (on ne prouve cryptographiquement que les segments critiques — décision finale, dépassement de seuil, classification d'une cible — pas l'inférence intégrale). Dans le cadre de la défense ou des systèmes critiques, la preuve asynchrone archivée pour audit ultérieur couvre la majorité des exigences réglementaires.

Couche 4 — L'attestation à l'edge

C'est la couche la moins glamour et la plus stratégique. Le confidential GPU couvre les data centers — il ne couvre pas le drone, le radar, le sonar, le calculateur embarqué d'un véhicule blindé, le capteur IoT industriel. Or, c'est précisément à la frontière que se déploient massivement les IA de perception, de fusion de données et d'aide à la décision dans les systèmes critiques.

À l'edge, la pile d'attestation s'appuie sur d'autres briques : pour le moment, nous restons majoritairement sur de l'ingénierie de confiance classique avec mesures cryptographiques légères. Le défi industriel est ici la frugalité. Un capteur radar embarqué dispose de quelques watts de puissance, pas d'une H100. La signature, le hashing et l'attestation doivent être conçus pour s'inscrire dans cette enveloppe, sans dégrader la latence temps réel des fonctions de mission. C'est là que se joue, concrètement, la différence entre une IA de laboratoire et une IA opérable dans des environnements contraints.

OWASP recommande explicitement de « chiffrer les modèles déployés en edge avec des contrôles d'intégrité et utiliser les API d'attestation des fournisseurs pour empêcher les applications et modèles altérés et terminer les applications avec firmwares non reconnus » (OWASP LLM03:2025).

L'ancrage réglementaire

L'attestation IA n'est plus un sujet de recherche. Elle devient un attendu réglementaire à plusieurs titres convergents.

AI Act, Article 15 — applicable pour les systèmes haut risque. Le texte est explicite et s'éloigne de la formule générique : les solutions techniques de cybersécurité des systèmes IA haut risque doivent inclure, « le cas échéant, des mesures pour prévenir, détecter, répondre, résoudre et contrôler les attaques visant à manipuler le jeu d'entraînement (data poisoning), ou les composants pré-entraînés utilisés à l'entraînement (model poisoning), les entrées conçues pour induire le modèle en erreur (adversarial examples ou model evasion), les attaques sur la confidentialité, ou les défauts du modèle » (EU AI Act, Article 15). Les sanctions associées vont jusqu'à 15 M€ ou 3 % du chiffre d'affaires mondial via la chaîne d'obligations Article 16 / Article 99.

AI Act, Article 11 + Annexe IV — documentation technique. L'Annexe IV liste précisément ce que doit contenir la documentation technique d'un système haut risque : description du système, modalités de surveillance, métriques de performance, mesures de cybersécurité… Tout ce que l'AIBOM matérialise sous une forme machine-lisible et vérifiable.

Cyber Resilience Act (CRA). le CRA impose le secure-by-design à tous les "produits avec éléments numériques" sur le marché européen. L'IA embarquée dans un système critique tombe sous son champ. Les exigences essentielles incluent l'absence de vulnérabilités exploitables connues, la protection de l'intégrité du logiciel, et la fourniture d'un SBOM/AIBOM aux autorités compétentes en cas d'incident.

NIS2 et DORA. Pour les opérateurs de services essentiels (NIS2) et les entités financières (DORA), la résilience opérationnelle des systèmes critiques inclut désormais explicitement la chaîne d'approvisionnement IA. La capacité à attester rapidement quels modèles tournent sur quels systèmes, avec quelles dépendances devient une obligation de reporting d'incident.

ISO/IEC 42001:2023. La norme de management des systèmes IA, déjà mobilisée par les RSSI et DPO, exige une gouvernance documentée des risques IA tout au long du cycle de vie, l'AIBOM en est la traduction opérationnelle naturelle.

L'effet cumulé de ces régimes est un faisceau cohérent. Là où jusqu'en 2024 l'attestation IA relevait de l'option d'ingénierie, elle devient le vocabulaire commun d'au moins quatre régulateurs européens.

Ce que disent les intégrateurs : retours du terrain défense et industrie

La théorie de l'attestation se heurte, comme toute brique de cybersécurité, à la réalité des chaînes d'ingénierie existantes. Les retours d'expérience publiés par les grands intégrateurs européens méritent d'être regardés tels qu'ils sont — pas tels qu'on aimerait qu'ils soient.

Confiance.ai (2021-2024) — le retour le plus structuré à ce jour. Programme phare de la stratégie nationale française pour l'IA (45 M€, 400 personnes, financement France 2030), Confiance.ai a réuni Airbus, Thales, Safran, Naval Group, Renault, Valeo, Air Liquide, Atos, Sopra Steria, le CEA, l'INRIA et les IRT SystemX et Saint Exupéry pour produire une méthodologie outillée de qualification de l'IA pour systèmes critiques (IRT SystemX, 2024). L'approche n'est pas centrée sur le scellement cryptographique mais sur l'ingénierie de la confiance : caractérisation des données, robustesse, explicabilité, monitoring d'attributs de confiance.

Le ton de Thales est révélateur, « Nous ne pouvons pas laisser la moindre place à l'approximation, qu'il s'agisse des systèmes de reconnaissance biométrique ou dans la défense avec les systèmes de désignation de cibles. Une erreur peut avoir des conséquences dramatiques. Il est impossible pour nous d'être dans une approche "Quick and Dirty" dans le déploiement des IA. Nous devons avancer pas à pas, nous appuyer sur des process, disposer d'outils pour aller vers des IA de confiance, passer par des phases de qualification et de certification » (LeMagIT, septembre 2025).

Limites, coûts, réalité industrielle

L'attestation IA n'est ni gratuite, ni magique. Quatre limites doivent être posées honnêtement, avant de regarder comment dimensionner la réponse selon le cas d'usage.

1. Le coût. Une H100 80 Go se négocie en 2026 entre $25 000 et$40 000, un serveur 8×H100 dépasse $350 000 ([IntuitionLabs, 2026](https://intuitionlabs.ai/articles/nvidia-ai-gpu-pricing-guide)). La génération Blackwell pousse encore les ordres de grandeur :$30 000 à $50 000 par B200, jusqu'à 3 millions de dollars pour un rack GB200 NVL72 (Tom's Hardware, 2024). Bonne nouvelle côté cloud : la prime "confidentiel" reste modérée — les SKU H100 Confidential Computing s'alignent globalement sur le H100 standard (Google Cloud, 2026). Le surcoût n'est donc pas le GPU mais l'empilement : PKI, attestation, intégration MLOps, qualification. Pour un système IA haute criticité en plein scellement, l'ordre de grandeur réaliste est un facteur 2 à 4 sur le TCO d'inférence — à pondérer face aux sanctions de l'AI Act (jusqu'à 15 M€ ou 3 % du CA).

2. La complexité opérationnelle. L'attestation à distance suppose une PKI, des services de validation, des politiques de révocation et de rotation. À l'échelle d'une flotte distribuée d'inférences IA, c'est un trust anchor problem classique qui devient une charge significative — et un nouveau vecteur de risque s'il est mal géré.

3. Le TEE n'est pas infaillible. Trois rappels, sous peine de transformer le TEE en security theater.

(i) Le code dans l'enclave reste à auditer. Sceller un modèle empoisonné, c'est sceller le poison. Une étude récente trouve que 25,3 % des projets utilisant un TEE présentent des pratiques de codage qui annulent la garantie matérielle (arXiv:2512.17363, 2025).

(ii) Le matériel lui-même a été cassé en 2024-2025. BadRAM puis TEE.fail en octobre 2025 (<1000 $) ont permis de forger des attestations valides sur AMD SEV-SNP, Intel TDX et NVIDIA — sur du matériel à jour (BadRAM, 2024 ; tee.fail, 2025). « Aucune implémentation TEE actuelle ne se défend complètement contre un attaquant sophistiqué avec accès physique » (a16z crypto, 2025).

(iii) La racine de confiance reste celle du fabricant. Intel, AMD, ARM gravent les secrets dans le silicium (Ledger, 2025). Les organisations souveraines doivent l'admettre.

Conséquence : un TEE ne remplace ni le red teaming, ni la défense en profondeur. Présumer la compromission éventuelle de l'enclave est plus prudent que la considérer comme barrière finale.

4. La maturité d'écosystème. Seulement 19 % des organisations ont une visibilité complète sur leur usage IA selon le rapport Cycode 2026. Les outillages AIBOM existent (CycloneDX, SPDX, OWASP AIBOM, in-toto), mais leur intégration aux pipelines MLOps en production reste artisanale.

Choisir le bon niveau plutôt que tout sceller

Le seuil de rentabilité dépend du cas d'usage. Pour les systèmes haut risque (AI Act) et critiques (NIS2/DORA/CRA), l'attestation passera d'option à exigence dans les 18-36 mois. Pour les usages grand public, un pattern plus léger suffira. La question n'est pas de tout sceller partout, mais de sceller ce qui doit l'être, et de pouvoir le prouver.

Pour la majorité des déploiements, des alternatives accessibles existent déjà, sans confidential computing :

• Signature des modèles via Sigstore — depuis avril 2025, la bibliothèque model-signing (OpenSSF, Google, NVIDIA, HiddenLayer) standardise le format ; PKI-agnostique, sans TEE, elle couvre le risque le plus fréquent : la substitution de modèle sur un hub ou un miroir (Google Security Blog, 2025 ; OpenSSF, 2025).
• Provenance via SLSA — montée en granularité progressive (L1 → L2 → L3) sans imposer le confidential computing. Atteindre SLSA Build L2 répond déjà à l'essentiel des exigences NIST SSDF (arXiv:2407.03949).
• Monitoring comportemental — Galileo Luna, Anodot, Elastic ML détectent dérive et empoisonnements subtils invisibles aux benchmarks, pour un coût sans commune mesure avec un stack confidential computing complet (Galileo, 2025).
• Doctrine ANSSI — le guide IA générative (avril 2024) liste 35 recommandations dont aucune n'exige un TEE GPU : cloisonnement, journalisation, GPU dédiés, maîtrise des privilèges, cartographie de la supply chain (ANSSI-PA-102, 2024).

D'où une matrice de criticité honnête :

• Faible (chatbot interne, résumé non-sensible) : SafeTensors + signature Sigstore + monitoring de base. ~80 % du risque couvert pour 5-10 % du coût d'un stack complet.
• Moyenne (RAG d'entreprise, copilote régulé) : ajouter AIBOM CycloneDX ML-BOM + SLSA Build L2 + journalisation NIS2/DORA.
• Haute (haut risque AI Act, opérateur essentiel NIS2) : ajouter Confidential Computing GPU + attestation composite + AIBOM in-toto signé.
• Extrême (défense, sécurité nationale, secrets industriels stratégiques) : ajouter preuves zk asynchrones + attestation à l'edge + qualification souveraine.

Scellement complet pour le sommet, provenance signée et monitoring pour la base. La force du raisonnement soustractif est de choisir le bon niveau, pas d'imposer le maximum partout.

Conclusion : la signature industrielle de l'IA souveraine

Pendant une décennie, la course à l'IA s'est mesurée en paramètres, en flops et en benchmarks. Une seconde course commence en 2026 : celle de la provabilité.

L'avantage compétitif de la prochaine génération de fournisseurs IA pour les systèmes critiques ne se mesurera pas seulement à la performance brute des modèles. Il se mesurera à la capacité à présenter, sur demande d'un auditeur, d'un client défense, d'un régulateur ou d'un client industriel régulé, une chaîne d'attestation vérifiable de bout en bout : voici les données d'entraînement, voici leur empreinte signée, voici l'environnement d'entraînement attesté, voici les poids signés, voici la dépendance chargée à l'instant T, voici le rapport d'attestation du GPU qui a calculé cette inférence, voici la preuve cryptographique du résultat.

Cette capacité n'est plus expérimentale. Les briques existent — SafeTensors, Sigstore, in-toto, CycloneDX ML-BOM, NVIDIA Confidential Computing, Intel TDX, AMD SEV-SNP, ARM CCA, zkLLM. Le travail n'est plus de les inventer mais de les industrialiser : les intégrer aux pipelines existants, qualifier leurs combinaisons, certifier leurs déploiements dans des environnements contraints (edge, embarqué, frugal), et former les équipes à raisonner en termes de chaîne de preuve et non plus seulement en termes de chaîne de production.

Reste à ne pas confondre la direction avec l'arrivée. L'IA sous scellés telle que décrite ici, chaîne complète, attestation composite, preuves cryptographiques, edge attesté, est un point de visée, pas un état atteignable à court terme pour la majorité des organisations. Les briques existent, mais leur industrialisation se heurtera, pendant plusieurs mois/années, à des frictions très réelles : ruptures matérielles (BadRAM, TEE.fail), maturité partielle des outils AIBOM en production, coûts de PKI à l'échelle, pénurie d'ingénieurs maîtrisant à la fois MLOps et cryptographie appliquée, et héritages techniques de pipelines ML qui n'ont jamais été conçus pour produire des preuves. La trajectoire réaliste n'est pas un grand soir du scellement, mais une montée par paliers : signature des modèles d'abord, AIBOM ensuite, confidential computing sur les charges les plus sensibles, attestation composite pour les certifications les plus exigeantes, edge attesté en dernier. Chaque palier réduit une surface d'attaque et un risque réglementaire, sans attendre que la pile complète soit en place. Le bon raisonnement n'est donc pas « nous y sommes » mais « nous savons où nous allons, nous savons pourquoi nous y allons, et nous avons les premières marches ». La différence entre les acteurs qui en tireront un avantage et les autres se jouera moins sur la sophistication des dernières couches que sur la régularité avec laquelle ils gravissent les premières.

Pour les acteurs européens — éditeurs IA, intégrateurs systèmes, opérateurs d'infrastructures critiques, ministères — la convergence des régimes (AI Act Art. 15, CRA, NIS2, DORA, ISO 42001) compose un brief stratégique cohérent : ceux qui transformeront cette exigence en compétence industrielle distinctive auront, en 2027-2028, un moat défensif que peu de concurrents non-européens pourront répliquer rapidement.

L'IA sous scellés ne sera pas, à court terme, l'état du parc déployé. Elle est le cap, celui que dessinent conjointement la menace, la régulation et les retours des intégrateurs critiques. Dans les domaines où l'erreur silencieuse n'est plus tolérable, hallucination, empoisonnement, substitution de modèle, le chemin vers ce cap n'est plus négociable, même si son rythme l'est.

Lego VIII - sac 2 - Substractive strategy

Les opinions exprimées dans cet article sont strictement personnelles et ne reflètent pas nécessairement celles de mon employeur. Les contenus sont fournis à titre informatif et ne constituent pas un conseil juridique. Cet article explore des concepts architecturaux émergents et analyse des tendances de marché.