ENS, NIS2, DORA, AI Act, RGPD, eIDAS, Data Act, ISO 27001, NIST, CIS : pour de nombreuses équipes techniques, la cartographie réglementaire commence à ressembler à une liste infinie d’acronymes, toujours en retard à la table : lors d’un appel d’offres, d’un audit, pour un client financier, une certification en cours ou en cas d’incident de sécurité.

L’erreur courante consiste à traiter chaque cadre réglementaire comme un projet distinct. Une équipe met en place l’ENS, une autre prépare ISO 27001, le service juridique examine le RGPD, la sécurité parle de NIS2, le produit s’intéresse à l’AI Act et les achats questionnent les fournisseurs. Résultat : une pile de documents, des contrôles redondants et des preuves dispersées entre e-mails, tickets, feuilles de calcul et outils qui ne communiquent pas entre eux.

Pour une organisation technologique, la meilleure approche pour assurer la conformité ne consiste pas à commencer par la norme, mais par l’architecture réelle : quels services sont fournis, quels 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.

De la matrice légale à la cartographie technique des services

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

L’Ens (Schéma National de Sécurité) est régulé en Espagne par le Royal Decree 311/2022 et concerne les systèmes traitant des informations ou fournissant des services dans le domaine de l’administration électronique, ainsi que leurs fournisseurs. La NIS2, la directive (UE) 2022/2555, élève le niveau commun de cybersécurité dans l’Union Européenne pour les entités essentielles et importantes. DORA, le règlement (UE) 2022/2554, se concentre sur la résilience opérationnelle numérique du secteur financier et la gestion des risques TIC. Enfin, le Règlement sur l’IA, le Règlement (UE) 2024/1689, adopte une approche basée sur le risque pour les systèmes d’intelligence artificielle.

À cette couche s’ajoutent des normes transversales sur la vie privée, l’identité numérique, les données et leur réutilisation. 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 ; le Data Governance Act organise certains mécanismes de gouvernance et de partage de données au sein de l’UE.

La conséquence pratique est que l’inventaire des services est aussi important que celui des actifs. Il ne suffit pas de connaître le nombre de serveurs, conteneurs, buckets, clusters ou bases de données ; il faut aussi comprendre quel service chaque actif supporte, quels données y sont traitées, quel client l’utilise, quels SLA sont en place, quels fournisseurs interviennent et quelles obligations contractuelles ou réglementaires en découlent.

Un CRM contenant des données personnelles ne se gouverne pas de la même façon qu’une plateforme d’évaluation avec IA. Une sauvegarde d’une mairie n’a pas le même contexte qu’un système analytique interne. Un fournisseur cloud qui fournit des services à une institution financière n’encourt pas le même niveau d’exposition qu’un site web corporate. L’architecture explique in fine la conformité.

Le noyau commun : identité, logs, correctifs, preuves et gouvernance

Même si chaque cadre réglementaire utilise son propre vocabulaire, de nombreux besoins se traduisent en contrôles très similaires. 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é, fournisseurs, formation et audits.

Pour les équipes techniques, cela permet de construire une base commune. Il n’est pas pertinent de déployer un système de preuves distinct pour l’ENS, l’ISO 27001, DORA ou le NIS2 si tous examinent les mêmes points : qui accède, avec quels privilèges, quelles modifications ont été effectuées, quelles vulnérabilités sont ouvertes, quand le backup a été testé, ce qu’il s’est passé durant un incident et qui a approuvé une exception.

Le respect moderne se rapproche de plus en plus de l’ingénierie plateforme. IAM (gestion des identités), MFA (authentification multi-facteurs), PAM (administration privilégiée), SIEM (gestion des événements), EDR (détection des intrusions), CMDB (configuration management database), ticketing, scanners de vulnérabilités, pipelines CI/CD, dépôts Git, inventaire cloud, gestion des secrets, sauvegardes et outils GRC doivent constituer un seul discours cohérent.

Un exemple concret : la gestion des vulnérabilités. Dans une organisation mature, il ne s’agit pas simplement d’exporter un rapport PDF mensuel pour l’audit. Il faut un inventaire à jour, une criticité par service, un responsable technique, un SLA de remédiation, des exceptions validées, une traçabilité via tickets et des preuves de clôture. Ce même flux peut servir pour l’ENS, NIS2, ISO 27001, DORA ou obligations contractuelles client.

Il en va de même pour les logs. Il ne suffit pas de stocker des événements : il faut définir ce qui est enregistré, pendant combien de temps, avec quelle intégrité, qui peut y accéder, comment relier les alertes et comment reconstituer une chronologie après incident. Pour la sécurité, c’est une opération quotidienne ; pour le juridique et la conformité, c’est une capacité probatoire essentielle.

En IA, un défi supplémentaire apparaît. L’AI Act oblige à penser en termes de risque, de finalité, de documentation, de supervision humaine, de traçabilité, de gestion du cycle de vie. Sur le plan technique, cela implique de 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 métriques, quelles limites, et qui assume la responsabilité en cas de défaillance”.

Compliance as code : moins de dossiers, plus d’opération

Le prochain niveau consiste à transformer une partie de la conformité en contrôles vérifiables en temps réel. Tout ne peut pas être automatisé, mais de nombreuses preuves peuvent être générées directement depuis l’opération.

Une politique MFA n’a que peu de valeur si la console d’identité affiche des comptes privilégiés sans double facteur. Un processus de sauvegarde n’a de sens que s’il est accompagné de tests de restauration. Une gestion du chiffrement est insuffisante si des buckets publics, des volumes sans chiffrement ou des secrets dans des dépôts apparaissent. Une matrice de fournisseurs n’a d’intérêt que si elle est reliée à des contrats, des évaluations de risques, des sous-traitants et des plans de sortie.

L’approche « compliance as code » consiste à rapprocher la conformité du déploiement et de l’exploitation des technologies : politiques dans des dépôts, contrôles dans des pipelines, validations d’infrastructure en tant que code, détection de configurations non sécurisées, preuves automatiques et tableaux de bord par service. Elle ne remplace pas l’analyse juridique ni le jugement du CISO, mais elle réduit le décalage entre ce que déclare l’entreprise et ce que ses systèmes réalisent concrètement.

Cela modifie également la relation entre le juridique et la teknik : l’avocat spécialisé ne peut plus se limiter aux clauses. Il doit comprendre les dépendances cloud, la gestion des données, les rôles des fournisseurs, les journaux d’activité, l’architecture IA, la gestion des incidents et la chaîne d’approvisionnement. À l’inverse, l’équipe technique ne doit pas percevoir la réglementation comme une contrainte extérieure ; beaucoup d’obligations relèvent, en réalité, de bonnes pratiques d’ingénierie et de sécurité transférables dans le cadre réglementaire.

L’objectif pour 2026 n’est plus d’apprendre toutes les sigles, mais de construire un modèle permettant de répondre rapidement à une question précise : pour un service donné, avec ces données, ces clients et ces fournisseurs, quels risques identifions-nous, quels contrôles couvrent ces risques et quelles preuves pouvons-nous présenter demain.

Les organisations qui s’y prendront bien n’auront pas trente programmes de conformité parallèles. Elles disposeront d’une base solide commune et de couches spécifiques selon le service, le secteur et le risque. C’est la différence entre survivre à un audit et exploiter une architecture 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. Avant de se concentrer sur les contrôles, il est essentiel de connaître les systèmes supportant chaque service, les données traitées, les clients concernés et les tiers impliqués.

ISO 27001 suffit-elle à couvrir l’ENS, NIS2 ou DORA ?
Elle constitue une excellente base pour la gestion de la sécurité, mais ne remplace pas l’analyse spécifique de chaque cadre. L’ENS, la NIS2 et DORA ont des obligations propres qui doivent être explicitement cartographiées.

Que signifie « compliance as code » ?
Il s’agit d’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 lorsque leur risque est élevé. Cela inclut la finalité, les données, la supervision humaine, la traçabilité, la gestion du changement, l’évaluation des risques et la répartition des responsabilités.

Source : Abogados Contratos