La forge de confiance

Note au lecteur, continuité de la série

Cet article s'inscrit dans la continuité directe d'Architecture du Risque – Pourquoi la conformité IA doit devenir une fonction système industrielle

Dans ce premier volet, nous avons posé une thèse structurante : la conformité IA ne peut plus être traitée comme un contrôle administratif ou un audit a posteriori. Elle doit devenir une fonction système, codifiée au cœur des architectures logicielles et des pipelines industriels. La forge de confiance en est une partie de la traduction opérationnelle. Là où le premier article répondait au "pourquoi" stratégique, celui-ci s'attaque au "comment" industriel.

Comment les réglementations entrent dans l'ingénierie et dans nos IA

Le droit ne s'applique plus au produit final, mais au processus, les organisations doivent le comprendre et s'approprier la réglementation pour ne pas les subir.

Historiquement, la conformité logicielle fonctionnait par audit du produit fini. On examinait un logiciel, on testait son comportement, on vérifiait sa documentation. Cette approche est explicitement rendue impossible par le cadre réglementaire 2024–2026 sur l'IA. Désormais la conformité couvre la conception, l'entraînement, le déploiement, l'exploitation, les mises à jour, et le suivi post-marché (Eu AI Rulebook vérifie tout)

Le Cyber Resilience Act va encore plus loin : il rend le fabricant responsable de la sécurité du produit numérique pendant toute sa durée de vie, avec obligation de correction, de notification et de preuve.

Conséquence directe

La conformité ne peut plus être un processus a posteriori, elle doit être encodée dans les systèmes de production eux-mêmes.

C'est là que la forge devient centrale et, fort heureusement, nous sommes déjà très bien outillés. Dans les développements IA de pointe, l'adhésion des concepteurs sur des TRL bas reste cependant souvent délicate. Pourtant, dans une forge conforme, l'IA est traitée comme une chaîne industrielle, pas comme un modèle : une IA conforme est une IA dont chaque étape de transformation est gouvernée, journalisée, vérifiable et bloquante. Dans une forge de confiance, on ne "développe pas un modèle". On met en œuvre une chaîne DevSecMLOps régulée.

Cette chaîne inclut obligatoirement :

1. l'ingestion des données,
2. leur transformation,
3. l'entraînement,
4. l'évaluation,
5. le packaging du modèle,
6. son déploiement,
7. sa supervision en exploitation.

Chaque étape devient un point d'application du droit. Par exemple, l'article 10 impose que, pour les systèmes à haut risque, les jeux de données soient pertinents, représentatifs, exempts de biais identifiables, documentés, et appropriés à la finalité.

Ce texte est contraignant, mais volontairement non technique. La question est donc : comment le rendre exécutable (je dirais même presque transparent pour les ingénieurs) ?

Prenons l'exemple de la traduction de la gouvernance des données, pour voir cela comme un "code". Dans une forge industrielle, l'ingestion des données ne se fait jamais directement par un notebook ou un script local.

Elle passe par un pipeline d'ingestion comportant au minimum :

• un fichier de métadonnées du dataset (dataset manifest),
• des règles automatiques de validation,
• un mécanisme de blocage.

Lorsqu'un dataset est proposé à l'entraînement :

1. Le pipeline exige un dataset descriptor contenant :

   • source (interne, partenaire, open data, scraping),
   • base légale RGPD (consentement, obligation légale, intérêt légitime),
   • finalité déclarée,
   • population couverte,
   • date de collecte.

2. Une étape automatique vérifie :

   • la présence de données sensibles (PII, santé, biométrie) via outils de détection (regex + modèles),
   • la cohérence entre finalité déclarée et type de données,
   • l'existence d'un DPIA si requis (RGPD + AI Act).

3. Si une seule condition échoue, le pipeline s'arrête.

Résultat souhaité : la conformité n'est plus une déclaration, mais une propriété bloquante du pipeline. Une organisation moderne devrait automatiser cela au maximum pour ne pas interrompre le flux de créativité sur les bas TRL et rassurer les clients sur les TRL plus hauts.

Un second exemple sur l'intégration du Cyber Resilience Act (CRA) via SBOM (Software Bill of Materials) et signature automatique

Le CRA impose notamment une Software Bill of Materials, la gestion continue des vulnérabilités, la signature des mises à jour, la traçabilité des composants.

Dans une forge conforme CRA :

1. Chaque build (y compris modèle IA) déclenche :

   • la génération automatique d'un SBOM (CycloneDX ou SPDX),
   • l'enregistrement des dépendances transitives,
   • l'association SBOM <-> hash de l'artefact.

2. Le SBOM est :

   • versionné,
   • stocké,
   • consultable,
   • lié au numéro de version du produit.

3. Avant déploiement :

   • un scan de vulnérabilités est exécuté,
   • toute vulnérabilité critique connue et non corrigée bloque la release.

4. L'artefact final est signé cryptographiquement.

Ces mécanismes sont exactement ceux recommandés par le NIST Secure Software Development Framework (SSDF)

Le modèle IA est traité comme un composant logiciel critique, pas comme un fichier opaque. Notons que les "AI-BOM" sont en pleine évolution et construction.

Un dernier exemple concernant la classification automatique AI Act dans le pipeline (Policy-as-Code) où la réglementation distingue : systèmes interdits, systèmes à haut risque, systèmes à risque limité et systèmes à risque minimal.

Une implémentation concrète dans la forge pour un projet IA créé ou modifié, serait d'imposer une déclaration de finalité ( domaine - santé, RH, finance, industrie -, utilisateurs cibles, type de décision automatisée, présence ou non d'impact sur des droits fondamentaux).

Ici un moteur de règles applique alors automatiquement :

• la classification AI Act,
• les obligations associées.

Par exemple si,

• domaine = recrutement
• décision = scoring automatisé de candidats

Alors :

• classification = haut risque

• obligations déclenchées automatiquement :

  • tests de biais obligatoires,
  • documentation,
  • supervision humaine,
  • monitoring post-marché.

Si ces éléments ne sont pas présents dans le pipeline, le déploiement est interdit.

Ce mécanisme est explicitement recommandé par le NIST AI RMF dans la fonction Govern

Et ce n'est pas tout. La conformité ne s'arrête pas au déploiement. Pourtant, la majorité des entreprises pense encore implicitement que la conformité IA est un événement : un audit, une validation, un passage en production. Cette représentation est explicitement contredite par le droit européen.

Le EU AI Act introduit une obligation centrale et largement sous-estimée : le post-market monitoring. Cela impose aux fournisseurs de systèmes IA à haut risque de mettre en place un système de surveillance continue, capable de détecter les risques émergents, les dérives de performance, les comportements non anticipés et les incidents affectant les droits fondamentaux. Ce point est décisif : une IA conforme au moment du déploiement peut devenir illégale en exploitation si elle dérive sans être détectée ni corrigée.

Cela rend caduque toute approche de conformité ponctuelle. La conformité devient une fonction runtime, au même titre que la sécurité ou la disponibilité.

À ce stade, un constat s'impose : aucune IA, aussi performante soit-elle, ne peut satisfaire seule aux exigences de conformité continue. La réponse industrielle à ce problème est l'émergence d'un Regulatory Operating System (RegOS).

Le RegOS n'est ni un outil, ni un dashboard, ni une simple couche de monitoring. Il est une fonction système.

Son rôle est de prévenir durant les phases développement, contraindre, surveiller, corriger (quand cela est possible et sans risque) en temps réel les comportements algorithmiques et de toujours remonter des indices sur les risques (Risk-Value Score)

Dans une architecture conforme, le modèle de scoring n'est jamais seul. Par exemple pour des IA générative, il est entouré d'un RegOS comportant au minimum :

1. Un module de surveillance statistique continue comparant en temps réel la distribution des entrées actuelles avec celles observées lors de l'entraînement et de la validation : une dérive significative déclenche une alerte automatique. Cette pratique est explicitement recommandée par le NIST AI RMF

2. Un module de contrôle de biais en production fournissant des métriques de fairness recalculées périodiquement à partir des décisions réelles. Si les écarts dépassent les seuils définis lors de la certification initiale, le système bloque temporairement l'automatisation ou impose une validation humaine.

3. Un journal réglementaire immuable journalisant toutes les décisions significatives, alertes et corrections dans un registre horodaté, signé et conservé selon les exigences de preuve du AI Act.

4. Un module d'arbitrage Ressources/Difficulté : ce module évalue en continu le "coût de la preuve". Il mesure l'impact des mécanismes de conformité sur la performance du système (latence, coût GPU) et la charge de travail des équipes. Il alimente directement le Risk-Value Score (RVS) pour alerter si un système, bien que conforme, devient industriellement insoutenable en raison de sa complexité technique ou de sa consommation de ressources.

Gouverner l'IA n'est pas la contrôler : une approche progressive

Il serait intellectuellement malhonnête, et industriellement dangereux, de prétendre qu'un ensemble de mécanismes techniques permettrait un contrôle total des systèmes d'IA. Les systèmes modernes, en particulier les modèles statistiques et génératifs, restent probabilistes, non stationnaires et sensibles au contexte.

La forge de confiance ne vise donc pas l'élimination du risque, mais sa réduction systématique, mesurable et démontrable, conformément à l'esprit du droit européen et aux cadres scientifiques existants.

• La gouvernance n'est pas une maîtrise déterministe,
• Une métrique de fairness n'est pas une garantie d'équité
• Une détection de dérive n'est pas une preuve de non-danger
• Un pipeline bloquant n'est pas une assurance d'innocuité

La valeur de la forge (et in fine d'un RegOS) réside dans la capacité à prouver que l'organisation agit, pas qu'elle prédit tout. Dans la forge, cela implique que les seuils utilisés sont documentés, les décisions réversibles et qu'il existe des mécanismes de repli humains (non automatique par défaut). D'ailleurs, sur la détection de données sensibles, les outils de détection automatique (regex + modèles) sont connus pour produire des faux positifs (coût opérationnel) et des faux négatifs (risque légal). Ici, les recommandations de l'ENISA et de la CNIL convergent :

• l'automatisation doit être assistive, pas exclusive,
• les décisions critiques doivent rester auditables a posteriori.

Il paraît sain d'adopter une démarche industrielle progressive (TRL-based) : la forge de confiance ne peut pas être déployée de manière "big bang". Une approche réaliste consiste à l'aligner sur les Technology Readiness Levels (TRL).

1. TRL 2–3 | Phase d'Exploration

• Objectif : Favoriser la créativité et la recherche.
• Mécanismes : Mise en place d'une journalisation légère et de métadonnées minimales pour ne pas brider l'innovation.

2. TRL 4–5 | Phase de Prototypage

• Objectif : Structurer la démarche.
• Mécanismes : Introduction des Dataset manifests, des SBOM (Software Bill of Materials) et première classification selon l'AI Act.

3. TRL 6–7 | Phase de Pré-production

• Objectif : Garantir une conformité démontrable.
• Mécanismes : Tests de biais systématiques, scans de vulnérabilités (CRA - Cyber Resilience Act) et signature électronique des composants.

4. TRL 8–9 | Phase de Production

• Objectif : Assurer la conformité en runtime (vie réelle).
• Mécanismes : Monitoring post-marché, systèmes d'alertes en temps réel et journaux immuables pour l'auditabilité.

La forge n'empêche pas l'innovation : elle différencie les exigences selon la maturité réelle du système.

Mais attention, gouverner, c'est aussi arbitrer, le Risk-Value Score (RVS), décrit dans l'article précédent, permet de décider quels systèmes méritent d'être industrialisés, et lesquels doivent être arrêtés avant de devenir des passifs techniques, juridiques ou réputationnels.

Ainsi, pour éviter les dérives de développement "correctes mais inutiles", la forge de confiance doit intégrer un mécanisme d'arbitrage explicite en "implémentant" le Risk-Value Score (RVS). C'est un indicateur stratégique qui met en regard :

• la valeur business attendue d'un système IA (efficience, revenus, avantage compétitif),
• les risques agrégés (juridiques, éthiques, cyber, réputationnels),
• et le coût de la preuve nécessaire pour rendre ce système conforme, auditables et exploitable dans la durée (tests, documentation, supervision humaine, monitoring post-marché).

Un projet peut être techniquement prometteur, mais devenir industriellement non viable si le coût de sa conformité dépasse sa valeur économique réelle. À l'inverse, un système à risque modéré mais fortement créateur de valeur peut justifier un investissement important.

Le rôle du RVS n'est donc pas d'éliminer le risque, mais de le rendre arbitrable. Il permet d'identifier précocement, dès les TRL intermédiaires, les projets incertifiables, non rentables ou stratégiquement mal alignés, avant qu'ils n'accumulent une dette réglementaire et cognitive irréversible. C'est en "runtime" un moyen de monitorer les dérives et, le cas échéant, d'intervenir.

La conformité comme accélérateur économique, pas comme centre de coûts

Réduire la forge de confiance à un "coût réglementaire" est une erreur stratégique. Bien implémentée, elle devient un levier économique direct sur trois dimensions : time-to-market, réduction du risque financier, et différenciation commerciale.

Dans les organisations classiques, la conformité intervient souvent en fin de chaîne, ce qui engendre des allers-retours coûteux entre Legal, Tech et Audit, et des délais imprévisibles pour la mise en conformité — particulièrement dans les secteurs régulés (finance, santé, énergie).

Les données montrent que lorsque la conformité est intégrée plus tôt dans le cycle de vie (via automatisation et "shift-left compliance"), les organisations obtiennent des réductions substantielles de coûts, de délais et de cycles de révision :

• Réduction de coûts et de délais : McKinsey note que l'automatisation des processus peut couper jusqu'à 30 % les coûts de conformité et réduire de 50–70 % le temps passé sur des tâches de conformité par comparaison avec des processus manuels, en partie grâce à la détection et à l'ajustement précoces des écarts. (FortifyData)
• Efficacité accrue : Dans une tendance similaire, des analyses du marché prévoient qu'une majorité d'entreprises adopteront des solutions automatisées pour la conformité d'ici à 2025, car les approches traditionnelles ne suivent plus le rythme des changements réglementaires selon Gartner. (Compliance.ai)
• Shift-left compliance : Une pratique de conformité intégrée en amont accélère le time-to-market, réduit les rework cycles et diminue les risques de non-conformité en détectant les problèmes avant qu'ils ne deviennent critiques. (drata.com)

Cette transformation n'est pas une "meilleure pratique" anecdotique : c'est une nécessité opérationnelle dans les environnements régulés où chaque révision tardive, chaque demande de preuve ou chaque audit ponctuel peut bloquer une version entière.

Automatiser les contrôles depuis la conception (codification des règles, pipelines CI/CD intégrés, supervision continue) permet de :

• Éviter les cycles de revue coûteux et itératifs entre Legal & Tech,
• Réduire les actions manuelles longues et sujettes aux erreurs,
• Accélérer la capacité à démontrer la conformité en continu.

Cela permet aussi de réduire le risque financier et réputationnel. Quand l'AI Act prévoit jusqu'à 35 M€ ou 7 % du chiffre d'affaires mondial en sanctions et une responsabilité étendue sur toute la durée de vie du système, la forge permet :

• de prouver la diligence raisonnable (due diligence),
• de réduire l'exposition juridique en cas d'incident,
• d'améliorer la position assurantielle (cyber & responsabilité produit).

Conclusion

La forge de confiance n'est ni une promesse magique, ni un dogme réglementaire. C'est une réponse industrielle imparfaite mais nécessaire à une réalité juridique et scientifique incontournable :

• l'IA ne peut plus être gouvernée a posteriori,
• la conformité est un processus continu, pas un livrable,
• la valeur économique naît de la prévisibilité, pas de l'improvisation.

Les organisations qui investiront tôt dans cette approche ne seront pas "plus conformes". Elles seront plus rapides, plus crédibles et plus résilientes dans l'économie de l'IA.

Plusieurs acteurs majeurs fournissent déjà les briques de cette "Forge de Confiance" :

• GitLab Compliance Center : Permet de définir des pipelines de conformité immuables. Si le scan de sécurité ou le check de licence échoue, le code ne passe jamais en prod. C'est l'incarnation du "Pipeline bloquant" décrit dans l'article.
• NVIDIA NeMo Guardrails : Un framework open-source pour ajouter des "barrières de sécurité" programmatiques aux LLM (vérification des biais, empêchement des sujets hors-sujet, filtrage des PII). C'est un début de "RegOS" en action pour le runtime.

Lego II - RegOS - Sac 2

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é.