Architecture de conformité IA : principes de conception pour les RSSI

4

La plupart des programmes de conformité IA échouent au même endroit : au moment où un régulateur, un auditeur ou un assureur demande des preuves. Le classeur de politiques est épais, les fiches de modèles sont soignées et le catalogue de contrôles est mis en correspondance avec quatre référentiels — mais les journaux, la traçabilité et les preuves de reprise reposent sur une infrastructure qui n’a jamais été conçue pour les produire. Une architecture de conformité IA solide comble cet écart en traitant la conformité comme une propriété architecturale, et non comme un exercice documentaire.

Ce guide s’adresse aux RSSI et aux architectes sécurité responsables de systèmes d’IA soumis à l’AI Act européen, à DORA, à l’ISO/IEC 42001, à SOC 2 (en anglais) et à une liste croissante de règles sectorielles. Il présente ce qu’est l’architecture de conformité IA, les principes de conception qui la rendent durable, les composants présents dans toute architecture de référence crédible, et la manière dont la couche de stockage détermine si les preuves de conformité résistent à l’examen.

Qu’est-ce que l’architecture de conformité IA ?

L’architecture de conformité IA est l’ensemble des choix de conception techniques et opérationnels qui permettent à une organisation de prouver en continu que ses systèmes d’IA respectent leurs obligations légales, réglementaires et contractuelles. C’est le pont entre une politique de conformité écrite et l’infrastructure en production qui doit l’honorer.

La discipline est plus jeune que sa discipline mère — l’architecture de conformité d’entreprise — mais sa structure est familière. Une architecture de conformité répond à quatre questions pour chaque système d’IA en production : quelles règles s’appliquent, quels contrôles mettent en œuvre ces règles, où se trouvent les preuves que ces contrôles fonctionnent, et comment l’organisation réagit lorsqu’un contrôle échoue ou que les règles changent.

La différence avec l’IA, c’est que les règles s’étendent désormais au cycle de vie du modèle lui-même. La provenance des données d’entraînement, le versioning des modèles, la journalisation des décisions, la surveillance de la dérive et les tests de reprise ne relèvent plus d’une hygiène d’ingénierie facultative. Ce sont des obligations explicites au titre de l’AI Act, de l’ISO/IEC 42001 et d’un nombre croissant de règles nationales. L’architecture de conformité IA est ce qui rend ces obligations mécaniques plutôt qu’héroïques.

L’architecture de conformité se distingue de deux disciplines voisines, tout en s’articulant avec elles :

• La gouvernance de l’IA fixe les politiques — qui peut construire quoi, sur quelles données, pour quel cas d’usage.
• L’architecture de conformité IA traduit ces politiques en contrôles applicables dans l’infrastructure.
• Les cadres d’audit de l’IA rassemblent les preuves obtenues afin que des examinateurs externes puissent vérifier que les contrôles ont tenu.

Négliger la couche architecturale est la raison la plus fréquente pour laquelle les programmes de conformité s’effondrent dès la première visite d’un régulateur.

Pourquoi la conformité IA est désormais un problème d’architecture

Pendant des années, le travail de conformité a pu s’appuyer sur un reporting a posteriori. Les journaux étaient exportés, les tableurs rapprochés et les exceptions expliquées par écrit. Les charges d’IA rendent cette approche intenable, pour trois raisons.

Le volume et la vélocité. Un seul modèle en production peut générer des millions d’enregistrements d’inférence par jour, chacun potentiellement concerné par un régulateur qui veut comprendre comment une décision importante a été prise. Le rapprochement manuel ne suit pas ce rythme. Les contrôles doivent être appliqués là où les données sont créées.

Une surface distribuée. Les pipelines d’IA s’étendent sur le stockage objet, les clusters GPU, les bases de données vectorielles, les feature stores et les registres de modèles — souvent entre sites, colocations et plusieurs clouds. Les preuves de conformité doivent suivre les données sur toute cette surface, sans lacune. Un contrôle qui n’existe que sur un niveau est un contrôle qui n’existe pas.

Un examen adversarial. Les conseils d’administration, les régulateurs, les assureurs et les équipes de sécurité ne se contentent plus d’affirmations. Ils veulent des preuves immuables, des preuves de reprise rapide et un contrôle juridictionnel démontrable. Cette exigence change ce que l’infrastructure doit faire, et pas seulement ce que les politiques doivent dire.

L’AI Act européen, l’ISO/IEC 42001, DORA, NIS2 et le Cyber Resilience Act européen vont tous dans le même sens : le prouver, preuves à l’appui, au moment de l’enquête. C’est une norme architecturale, et non une norme de reporting.

Principes de conception de l’architecture de conformité IA

Toute architecture de conformité IA crédible repose sur la même poignée de principes. Ils n’ont rien de nouveau. Ce sont ceux qui sous-tendent déjà une bonne architecture de sécurité — appliqués avec la rigueur qu’exigent les charges d’IA.

Principe 1 : la conformité est une propriété de la plateforme, pas une surcouche

Les contrôles qui vivent dans le code applicatif, dans des scripts planifiés ou dans des étapes de revue humaine dérivent dès que les équipes changent. Ceux qui vivent dans les couches de stockage, d’identité et de réseau, non. Le premier choix de conception d’une architecture de conformité IA consiste à descendre autant de contrôles que possible dans la pile — dans des systèmes qui appliquent les politiques par défaut et qu’un ingénieur bien intentionné mais pressé ne peut pas contourner.

Principe 2 : les preuves sont générées, pas assemblées

Les dossiers d’audit constitués à la main sont lents, coûteux et sujets aux oublis. Ceux produits par une infrastructure qui journalise chaque accès, chaque modification et chaque événement de cycle de vie sont rapides, peu coûteux et complets. L’architecture doit générer les preuves comme un effet secondaire du fonctionnement normal. Si quelqu’un doit penser à capturer un événement, cet événement finira par ne pas être capturé.

Principe 3 : l’immuabilité est le socle des preuves

Un journal modifiable, un artefact de modèle remplaçable ou un jeu de données d’entraînement silencieusement mis à jour ne peuvent pas servir de preuve. Le stockage immuable (en anglais) avec object lock et sémantique WORM (write once, read many) est le minimum pour tout artefact que l’organisation compte défendre lors d’un audit. Cela vaut aussi bien pour les checkpoints de modèles que pour les instantanés de données d’entraînement, les journaux d’inférence, les enregistrements de configuration et les journaux d’accès.

Principe 4 : la traçabilité est continue, de la source à la décision

Les régulateurs et les auditeurs n’acceptent pas une traçabilité qui s’arrête à « l’équipe data nous l’a transmis ». Pour chaque résultat de modèle important, l’architecture doit permettre de remonter de l’enregistrement d’inférence à la version du modèle, de la version du modèle à son entraînement, de l’entraînement à la version du jeu de données, et de cette version aux sources qui y ont contribué. Chaque maillon de cette chaîne nécessite une garantie d’intégrité.

Principe 5 : la reprise fait partie de la conformité

DORA et le Cyber Resilience Act le disent explicitement : un système que l’on ne peut pas restaurer est un système que l’on ne peut pas défendre. L’architecture de conformité IA doit inclure des procédures de reprise testées pour les artefacts de modèles, les jeux de données d’entraînement, les journaux d’inférence et l’état de configuration. Les objectifs de temps et de point de reprise ont leur place dans la conception de la conformité dès le départ.

Principe 6 : la souveraineté est inscrite dans l’architecture, pas dans des promesses

Le lieu où résident les données, qui peut y accéder et sous quelles lois elles relèvent sont de plus en plus des exigences fermes plutôt que des préférences. L’architecture doit inscrire la résidence, l’inspectabilité et la souveraineté opérationnelle comme des propriétés appliquées — politiques de placement, réplication tenant compte des juridictions et frontières d’identité qui ne dépendent pas des bonnes intentions d’un fournisseur. Consultez les bonnes pratiques de souveraineté des données pour voir comment cela se traduit dans les choix de stockage.

Principe 7 : les contrôles se dégradent proprement

Les systèmes de production tombent en panne. Les contrôles de conformité doivent échouer d’une manière qui préserve les preuves et protège l’organisation, et non d’une manière qui ouvre de nouvelles failles. L’architecture doit adopter le refus par défaut : lorsqu’un contrôle ne peut pas vérifier son état, le comportement le plus sûr est de refuser l’opération, de journaliser ce refus et de le soumettre à une revue humaine.

Composants d’une architecture de référence de conformité IA

Les sept principes produisent une architecture de référence à la forme reconnaissable. Le tableau ci-dessous présente les couches que l’on retrouve dans toute mise en œuvre mature.

Couche	Rôle de conformité	Contrôles représentatifs
Politique et gouvernance	Définir les obligations	Classification des risques IA, workflows d’approbation des modèles, catalogues de contrôles
Identité et accès	Autoriser les actions	Contrôle d’accès basé sur les rôles, MFA, proxys tenant compte de l’identité, revues d’accès périodiques
Cycle de vie des modèles	Suivre la provenance	Registre de modèles, versioning sémantique, artefacts signés, métadonnées d’entraînement
Cycle de vie des données	Suivre la traçabilité	Versioning des jeux de données, classification des données, calendriers de rétention, preuves de suppression
Stockage	Préserver les preuves	Object lock, WORM, durabilité multisite, journaux infalsifiables
Observabilité	Générer les preuves	Journaux d’accès, contrôles d’intégrité, télémétrie de dérive, télémétrie énergétique et de capacité
Reprise	Prouver la résilience	Immuabilité des sauvegardes, exercices de restauration, tests RPO/RTO, vérification d’intégrité à la restauration

Quelques composants méritent une attention particulière.

Registres de modèles et de jeux de données

La couche des registres est celle où vit la traçabilité. Chaque modèle mis en production doit disposer d’un enregistrement couvrant sa version, l’instantané des données d’entraînement, les résultats d’évaluation, les signatures d’approbation et le périmètre de déploiement. Les jeux de données doivent être versionnés avec la même rigueur. Les conventions de nommage informelles — « final », « final_v2 », « final_v2_vraiment » — sont le constat le plus fréquent lors des premières revues de conformité IA.

Pistes d’audit immuables

Des journaux d’audit qui partagent le sort des systèmes qu’ils surveillent ne sont pas des journaux d’audit. Ils doivent être écrits sur un stockage qui empêche toute modification pendant la période de rétention, répliqués entre domaines de défaillance et interrogeables sans compromettre leur intégrité. La piste d’audit du stockage est l’endroit où cette exigence est mise en œuvre en pratique.

Application de la rétention et de la suppression

De nombreuses obligations de conformité IA s’accompagnent de planchers et de plafonds de rétention stricts — conserver ceci sept ans, supprimer cela dans les trente jours suivant une demande d’accès. L’application des politiques au niveau du stockage garantit que ces fenêtres sont respectées même lorsque la logique applicative les oublie. Une politique de conservation des données documentée, appuyée sur des contrôles de cycle de vie au niveau du stockage, est la combinaison que recherchent les auditeurs.

Reprise et vérification de l’intégrité

Restaurer un modèle n’est pas la même chose que restaurer un modèle qui n’a pas été altéré. Les procédures de reprise doivent vérifier les sommes de contrôle par rapport aux valeurs signées du registre, confirmer que la continuité des journaux d’audit est préservée tout au long de la restauration, et prouver que le système restauré est bien celui qui fonctionnait avant l’incident.

Comment Scality ADI soutient l’architecture de conformité IA

L’architecture de conformité vit ou meurt au niveau de la couche de stockage. Journaux, artefacts de modèles, jeux de données d’entraînement et instantanés de configuration finissent tous sur du stockage objet — et ce sont les propriétés d’intégrité de ce stockage qui déterminent si le reste de l’architecture a quelque chose à défendre.

Scality ADI (Autonomous Data Infrastructure) est une infrastructure de données pour l’IA d’entreprise, la cyber-résilience et le contrôle souverain, qui aligne de manière autonome et durable les bons supports de stockage, de l’échelle multi-pétaoctet à l’exaoctet. Dans Scality ADI, la cyber-résilience est architecturale : la protection, la capacité de reprise et l’auditabilité sont intégrées à la plateforme plutôt qu’ajoutées après coup.

Pour les RSSI et les architectes sécurité qui conçoivent une architecture de conformité IA, le modèle de cyber-résilience CORE5 de Scality ADI correspond directement aux principes de conception ci-dessus :

• Immuabilité. L’object lock avec sémantique WORM garantit que journaux d’audit, artefacts de modèles et instantanés de données d’entraînement ne peuvent être ni écrasés ni supprimés pendant la période de rétention — ni par un ransomware, ni par un administrateur, ni par quiconque. C’est le principe 3 appliqué par un logiciel adossé au matériel, et non par un processus.
• Erasure coding. Une forte durabilité à l’échelle multisite garantit que les preuves survivent à la perte d’un site. Les preuves de reprise exigées par DORA peuvent être produites sans niveau de sauvegarde distinct dédié à la conformité.
• Protection des métadonnées. Les métadonnées des objets accompagnent le contenu avec les mêmes garanties d’intégrité, de sorte que les enregistrements d’accès, les étiquettes de classification et les pointeurs de traçabilité conservent leur valeur lors des événements de stockage.
• Durabilité multisite. La réplication géographique maintient la cohérence des preuves entre juridictions, ce qui répond aux exigences de souveraineté sans imposer de plans de contrôle parallèles.
• Cycle de vie piloté par des politiques. Les politiques de rétention et de suppression sont appliquées au niveau du stockage plutôt que dans une logique applicative contournable. C’est le mécanisme que recherchent les auditeurs lorsqu’ils demandent si les calendriers de rétention sont réellement respectés.

Scality ADI couvre quatre niveaux de stockage — flash GPU-Direct, chaud en QLC et NL-SSD, tiède en NL-HDD et HDD, froid sur bande et archivage adjacent au cloud — sous un même modèle opérationnel. Les preuves de conformité IA peuvent ainsi suivre le même cycle de vie que les données qu’elles décrivent : chaudes pendant la phase active d’une enquête, tièdes pendant la période de rétention, froides pour les obligations à long terme, sans jamais quitter le périmètre d’audit de la plateforme.

Scality ADI sert également de cible objet S3 immuable et à grande échelle pour les écosystèmes de sauvegarde — Veeam, Commvault, Rubrik (en anglais), Atempo — que la plupart des entreprises utilisent pour protéger leur infrastructure IA. Les copies de sauvegarde écrites sur Scality ADI avec object lock activé sont infalsifiables par conception, ce qui est précisément la propriété qu’exigent les obligations de conformité liées à la reprise.

Découvrez comment Scality ADI apporte cyber-résilience et contrôle souverain à l’IA d’entreprise

Questions fréquentes

Qu’est-ce que l’architecture de conformité IA ?

L’architecture de conformité IA est l’ensemble des choix de conception techniques et opérationnels qui permettent à une organisation de prouver en continu que ses systèmes d’IA respectent leurs obligations réglementaires, contractuelles et internes. Elle traduit un programme de conformité en contrôles au niveau de l’infrastructure, de sorte que les preuves sont générées par la plateforme plutôt qu’assemblées à la main.

En quoi l’architecture de conformité IA diffère-t-elle de la gouvernance de l’IA ?

La gouvernance de l’IA définit les politiques — quelle IA est acceptable, sur quelles données, dans quel but. L’architecture de conformité IA met en œuvre ces politiques sous forme de contrôles applicables dans l’infrastructure. Une gouvernance sans architecture produit des documents bien rédigés qui échouent au premier audit. Une architecture sans gouvernance produit des contrôles qui s’écartent de l’intention.

Quelles réglementations orientent les décisions d’architecture de conformité IA ?

L’AI Act européen, l’ISO/IEC 42001, DORA, NIS2, le Cyber Resilience Act, SOC 2 Type II étendu aux charges d’IA et le cadre de gestion des risques IA du NIST sont les moteurs les plus courants. Des règles sectorielles — HIPAA pour l’IA en santé, les régulateurs financiers pour les modèles de crédit et de trading — ajoutent des exigences que l’architecture doit intégrer.

Quel rôle joue le stockage immuable dans la conformité IA ?

Le stockage immuable est le fondement de preuves infalsifiables. Les journaux d’audit, artefacts de modèles et instantanés de données d’entraînement stockés avec object lock et sémantique WORM ne peuvent être ni modifiés ni supprimés pendant la période de rétention. Sans cette propriété, les preuves de conformité ne sont que des affirmations.

À quelle fréquence faut-il réexaminer une architecture de conformité IA ?

L’architecture elle-même doit être réexaminée au moins une fois par an et après chaque changement réglementaire important. Les contrôles qu’elle contient doivent être testés en continu — revues d’accès trimestrielles, exercices de reprise au moins annuels et vérification d’intégrité permanente. Les systèmes à haut risque au sens de l’AI Act justifient une cadence plus resserrée sur tous ces points.

Pour aller plus loin

• Piste d’audit du stockage — comment les systèmes de stockage d’entreprise génèrent et protègent les preuves de conformité
• Qu’est-ce que le stockage immuable : définition, avantages et fonctionnement (en anglais) — les fondamentaux de la sémantique WORM et de l’object lock
• Cadre de conformité des données — bâtir un programme de conformité structuré sur l’ensemble des systèmes de données
• Politique de conservation des données : définition, exemples et bonnes pratiques — structurer des calendriers de rétention qui satisfont les régulateurs
• Solution de cyber-résilience CORE5 (en anglais) — l’architecture de cyber-résilience en cinq piliers de Scality
• Le règlement DORA expliqué — périmètre de DORA, exigences en matière de risques TIC et obligations de test
• Architecture zero trust — appliquer le principe « ne jamais faire confiance, toujours vérifier » à l’infrastructure IA