ENS, NIS2, DORA, AI Act, RGPD, eIDAS, Data Act, ISO 27001, NIST, CIS. Pour beaucoup d’équipes techniques, la cartographie réglementaire ressemble désormais à une liste sans fin d’acronymes, toujours en retard à la table lors d’un appel d’offres, d’un audit, d’une demande d’un client financier ou d’un incident de sécurité.

Contexte et enjeux

L’erreur courante consiste à traiter chaque cadre réglementaire comme un projet à part. Une équipe met en place l’ENS, une autre prépare ISO 27001, le juridique examine le RGPD, la sécurité travaille sur NIS2, le produit s’occupe de l’AI Act et les achats interrogent les fournisseurs. Résultat : une pile de documents, des contrôles redondants et des preuves éparpillées entre e-mails, tickets, tableurs et outils qui ne se parlent pas.

Pour une organisation technologique, la bonne approche ne consiste pas à partir de la norme, mais de l’architecture réelle : quels services sont fournis, quelles données sont traitées, quelle infrastructure est utilisée, quels tiers interviennent, quels clients dépendent de l’organisation, et quel serait l’impact d’une panne, d’une fuite de données ou d’une décision automatisée mal gouvernée.

Les faits

L’applicabilité réglementaire dépend rarement d’une seule étiquette. Une même entreprise peut être à la fois fournisseur cloud, MSP, éditeur de logiciel, responsable de traitement, prestataire pour une institution financière, opérateur d’une plateforme d’IA ou titulaire d’un marché public. Chaque rôle entraîne des obligations différentes.

L’ENS, régi en Espagne par le décret royal 311/2022, concerne les systèmes qui traitent des informations ou fournissent des services d’administration électronique, ainsi que leurs fournisseurs. La directive NIS2 (UE 2022/2555) relève le niveau commun de cybersécurité dans l’Union pour les entités essentielles et importantes. DORA (UE 2022/2554) cible la résilience opérationnelle numérique du secteur financier et la gestion des risques liés aux TIC, un terrain que Kyndryl et Microsoft explorent déjà côté cloud souverain. Le règlement sur l’IA (UE 2024/1689) adopte de son côté une approche fondée sur le risque pour les systèmes d’intelligence artificielle.

À cette couche s’ajoutent des règles transversales sur la vie privée, l’identité numérique et les données. Le RGPD encadre le traitement des données personnelles, eIDAS couvre l’identification électronique et les services de confiance, le Data Act règle l’accès et l’usage des données, et le Data Governance Act organise certains mécanismes de partage au sein de l’UE. Un CRM contenant des données personnelles ne se gouverne pas comme une plateforme d’évaluation par IA, et un fournisseur cloud au service d’une banque n’encourt pas la même exposition qu’un simple site vitrine.

Analyse et implications

Même si chaque cadre utilise son propre vocabulaire, beaucoup de leurs exigences se traduisent en contrôles très proches : gestion des risques, gouvernance, contrôle d’accès, authentification forte, séparation des fonctions, inventaire des actifs, chiffrement, gestion des vulnérabilités, surveillance, réponse aux incidents, continuité, gestion des fournisseurs, formation et audits. Il n’est pas rentable de construire un système de preuves distinct pour l’ENS, l’ISO 27001, DORA et le NIS2 quand tous examinent au fond les mêmes questions : qui accède, avec quels privilèges, quelles modifications ont été faites, quelles vulnérabilités restent ouvertes, quand la dernière sauvegarde a été testée, ce qui s’est passé pendant un incident et qui a validé une exception.

La conformité moderne ressemble de plus en plus à de l’ingénierie plateforme : IAM, MFA, PAM, SIEM, EDR, CMDB, ticketing, scanners de vulnérabilités, pipelines CI/CD, dépôts Git, inventaire cloud, gestion des secrets, sauvegardes et outils GRC doivent raconter la même histoire. Des prestataires comme Aire, avec son offre MSSP reliant cloud, cybersécurité et continuité, ou des acteurs mainframe comme IBM sur ses machines Z, avancent déjà dans cette direction : consolider les contrôles plutôt que les multiplier par réglementation.

Prenons la gestion des vulnérabilités. Dans une organisation mature, il ne s’agit pas d’exporter un PDF mensuel pour l’auditeur, mais de tenir un inventaire à jour, une criticité par service, un responsable technique, un délai de remediation, des exceptions validées, une traçabilité par ticket et des preuves de clôture. Ce même flux sert à la fois l’ENS, le NIS2, l’ISO 27001, DORA et les obligations contractuelles des clients. Il en va de même pour les logs : il faut définir ce qui est enregistré, pendant combien de temps, avec quelle intégrité, qui peut y accéder et comment reconstituer une chronologie après incident. Une opération quotidienne pour la sécurité, une capacité probatoire essentielle pour le juridique.

L’IA ajoute une couche supplémentaire. L’AI Act oblige à raisonner en termes de risque, de finalité, de documentation, de supervision humaine et de cycle de vie. Techniquement, cela signifie passer de « un modèle est intégré » à « nous savons quel modèle nous utilisons, avec quelles données, pour quelle finalité, sous quels contrôles, avec quelles limites, et qui assume la responsabilité en cas de défaillance ».

Perspectives

Le niveau suivant consiste à transformer une partie de la conformité en contrôles vérifiables en temps réel. Tout ne peut pas s’automatiser, mais beaucoup de preuves peuvent être générées directement depuis l’opération : une politique MFA ne vaut rien si la console d’identité affiche des comptes privilégiés sans double facteur, un processus de sauvegarde n’a de sens que testé par une restauration réelle, une politique de chiffrement s’effondre dès qu’un bucket public ou un secret non chiffré traîne dans un dépôt.

Le « compliance as code » rapproche la conformité du déploiement réel : politiques dans des dépôts, contrôles dans des pipelines, validation d’infrastructure en tant que code, détection de configurations non sécurisées, preuves automatiques et tableaux de bord par service. Cette approche ne remplace ni l’analyse juridique ni le jugement du CISO, mais elle réduit l’écart entre ce que déclare l’entreprise et ce que ses systèmes font réellement. Elle change aussi la relation entre juridique et technique : l’avocat spécialisé doit comprendre les dépendances cloud et l’architecture IA, l’équipe technique doit cesser de voir la réglementation comme une contrainte extérieure, tant beaucoup d’obligations relèvent en réalité de bonnes pratiques d’ingénierie transposables.

L’objectif pour 2026 n’est plus de mémoriser tous les sigles, mais de construire un modèle capable de répondre vite à une question précise : pour ce service, avec ces données, ces clients et ces fournisseurs, quels risques identifie-t-on, quels contrôles les couvrent, et quelles preuves peut-on produire demain. Les organisations qui y parviennent n’auront pas trente programmes de conformité parallèles, mais une base commune solide et des couches spécifiques selon le service, le secteur et le risque. C’est la différence entre survivre à un audit et exploiter une architecture déjà prête pour un environnement réglementé.

Foire aux questions

Par quoi doit commencer une équipe technique face à tant de normes ?
Cartographier les services et leurs dépendances : quels systèmes supportent chaque service, quelles données sont traitées, quels clients et quels tiers sont concernés.

ISO 27001 suffit-elle à couvrir l’ENS, NIS2 ou DORA ?
Elle offre une excellente base pour la gestion de la sécurité, mais ne remplace pas l’analyse spécifique de chaque cadre, qui comporte des obligations propres à cartographier explicitement.

Que signifie « compliance as code » ?
Appliquer des contrôles de conformité de façon automatisée ou semi-automatisée, intégrés à l’opération technique : pipelines, infrastructure en tant que code, inventaire, surveillance, gestion des accès et preuves générées par les systèmes réels.

Comment l’AI Act impacte-t-il les équipes techniques ?
Il impose une meilleure documentation et gouvernance des systèmes d’IA, notamment à risque élevé : finalité, données, supervision humaine, traçabilité, gestion du changement, évaluation des risques et répartition des responsabilités.

Source : Abogados Contratos