Compliance by design : intégrer GDPR/AI Act/NIS2 dès la conception

« Compliance by design » n'est pas un slogan. C'est une obligation réglementaire explicite (RGPD article 25), structurante pour les architectures EDI qui touchent à des données personnelles, à des modèles IA, ou à des chaînes d'approvisionnement critiques.

Pourquoi by design ?

Intégrer la conformité après la conception coûte typiquement 5-10x plus cher qu'en amont, parce qu'il faut remplacer des choix structurants : stockage, architecture des flux, séparation des environnements, journalisation. Les régulateurs européens (CNIL, EDPB, ENISA, AI Office) ont aligné leurs doctrines sur le principe que les obligations s'apprécient « au moment de la détermination des moyens du traitement » et non lors d'un éventuel contrôle.

En 2026, trois textes structurent les obligations européennes pour les architectures EDI moderne : RGPD (mai 2018), AI Act (règlement 2024/1689, août 2024), NIS2 (directive 2022/2555, janvier 2023). Aucun n'est spécifique à l'EDI, mais tous les trois s'y appliquent dès lors qu'on traite des données personnelles, qu'on utilise des composants IA, ou qu'on opère dans un secteur essentiel.

GDPR article 25 : data protection by design and by default

L'article 25 RGPD exige que le responsable de traitement mette en œuvre les mesures techniques et organisationnelles appropriées au moment de la détermination des moyens du traitement et au moment du traitement lui-même. Les principes : minimisation des données, pseudonymisation, mesures de sécurité, configuration par défaut limitant l'accès.

Pour un hub EDI traitant des INVOIC partenaires : stockage minimal des données personnelles (n'archiver que ce qui est légalement requis — DGI : 10 ans pour les factures comptables en France ; les autres données peuvent être purgées plus tôt), pseudonymisation des données dans les environnements non-production (sandbox, staging), accès Restrict par défaut (un opérateur lit uniquement les données strictement nécessaires à son rôle), journalisation immuable des accès. Le EDPB Guidelines 4/2019 détaillent ces obligations.

AI Act : classification par risque

L'AI Act (règlement UE 2024/1689) classifie les systèmes IA en quatre niveaux de risque : inacceptable (interdit), élevé (obligations strictes), limité (transparence), minimal (libre). La classification « risque élevé » déclenche des obligations lourdes : système de gestion des risques, gouvernance des données d'entraînement, documentation technique, surveillance humaine, robustesse et cybersécurité, registre des évènements (logs).

Pour l'EDI, les cas IA typiques sont : assistant de mapping LLM-based, détection d'anomalies, suggestion automatique de codes erreur, RAG sur documentations partenaires. Aucun de ces cas n'est « risque élevé » au sens de l'annexe III tel quel — mais si l'IA décide d'accepter/rejeter automatiquement des factures, cela pourrait basculer dans la catégorie « évaluation de solvabilité ou notation de crédit » (annexe III §5(b)) qui est risque élevé. À vérifier cas par cas avec une analyse de classification publiée par l'AI Office.

Le calendrier d'application est progressif : interdictions effective le 2 février 2025, obligations modèles GPAI le 2 août 2025, obligations risque élevé le 2 août 2026 et 2 août 2027 selon les catégories.

NIS2 : cybersécurité des opérateurs essentiels

La directive NIS2 (2022/2555, transposition nationale due le 17 octobre 2024) impose des obligations renforcées de cybersécurité aux entités essentielles (énergie, transport, banque, santé, eau potable, infrastructure numérique) et aux entités importantes (gestion des déchets, alimentation, fabrication, fournisseurs numériques). Critère de seuil : entreprises moyennes et grandes (≥ 50 salariés ou ≥ 10 M€ CA) opérant dans les secteurs couverts.

Obligations clés : gestion des risques cyber documentée, gestion des incidents (notification ENISA dans 24h pour incidents significatifs), continuité d'activité, sécurité de la chaîne d'approvisionnement (y compris fournisseurs IT et SaaS), politiques d'authentification et de chiffrement, formation. Pour un hub EDI servant plusieurs entités NIS2, le hub devient lui-même un fournisseur critique évalué par ses clients régulés.

Quatre principes opérationnels

• Data minimisation — chaque champ stocké doit avoir une justification métier ou légale. Question test : si on retire ce champ, qu'est- ce qui casse ? Si rien, on n'a pas le droit de le stocker.
• Defense in depth — combiner chiffrement transport (TLS), chiffrement payload (CMS, AS2), chiffrement at-rest (disk encryption, KMS-backed), contrôle d'accès dynamique (OPA, Zero Trust). Aucune couche n'est suffisante seule.
• Auditabilité immuable — chaque action significative (lecture payload, modification config, exécution IA) doit être loggée dans un store append-only (Kafka topic compacté, S3 object lock). Sans cela, impossible de démontrer la conformité à un contrôleur.
• Privacy enhancing technologies — pseudonymisation, anonymisation, synthetic data pour les jeux de test, agrégation différentiellement privée pour les KPIs. Investir tôt sur ces outils évite des refus tardifs.

Implications EDI : cinq décisions architecturales

• Séparation environnements : jamais de données prod en sandbox/dev. Si nécessaire, pseudonymisation systématique (les bibliothèques Synthetic Data Vault ou Faker permettent de générer des datasets réalistes).
• Politique de rétention par flux : chaque type de message a sa durée de rétention propre (10 ans facture comptable, 5 ans audit ACK fiscal, 90 jours logs opérationnels). Implémenter avec lifecycle policies S3 + jobs Airflow de purge.
• Tracé de chaque accès aux données : logger les requêtes SQL sur les payloads (Postgres pgaudit), les téléchargements de fichiers, les calls à l'API admin. Indispensable pour répondre à un Data Subject Access Request RGPD ou un audit NIS2.
• Évaluation des fournisseurs SaaS et IA : chaque vendor entre dans le périmètre supply chain NIS2 de vos clients régulés. Préparer un DPA RGPD, une AI Act FRIA si applicable, une attestation SOC 2 Type II ou ISO 27001.
• Plan de réponse aux incidents : NIS2 impose notification ENISA en 24h pour incidents significatifs. Préparer un runbook d'escalade, des contacts à jour, des templates de notification réglementaires.

Pour aller plus loin

• Sécurité des flux EDI 2026 — défense en profondeur, lien direct avec NIS2.
• Conformité multi-juridictionnelle — pour le périmètre e-invoicing au-delà de l'UE.
• EDPB Guidelines 4/2019 — Data Protection by Design and by Default. edpb.europa.eu
• Règlement (UE) 2024/1689 — AI Act. eur-lex.europa.eu
• Directive (UE) 2022/2555 — NIS2. eur-lex.europa.eu