NIS2 et la transformation IA du secteur industriel en Belgique : comment OpenKBS assure la conformité à la Loi NIS2

La Belgique figure parmi les premiers États membres de l'Union européenne à avoir transposé la Directive (UE) 2022/2555 (NIS2). La Loi du 26 avril 2024 (Loi NIS2), complétée par l'Arrêté royal du 9 juin 2024, est en vigueur depuis le 18 octobre 2024. Le Centre pour la Cybersécurité Belgique (CCB) est l'autorité compétente pour la supervision et la mise en application.

Les moyennes et grandes entreprises industrielles relèvent du champ d'application de la loi en tant qu'« entités importantes » (entreprises d'au moins 50 salariés et 10 millions d'euros de chiffre d'affaires annuel, dans les secteurs visés à l'Annexe II de la Directive). Pour ces organisations, NIS2 pose un défi concret : comment intégrer des solutions d'IA dans les processus de production sans accroître le risque réglementaire et de cybersécurité. La présente publication décrit comment la plateforme OpenKBS répond aux exigences de la Loi NIS2 belge pour ses clients enterprise.

Sécurité infrastructurelle par AWS

OpenKBS construit l'infrastructure de ses clients entièrement sur Amazon Web Services (AWS). Ce n'est pas un simple choix d'hébergement — il entraîne l'héritage d'un catalogue complet de certifications et attestations vérifiées de manière indépendante, parmi lesquelles :

ISO/IEC 27001 — système de management de la sécurité de l'information ;
ISO/IEC 22301 — management de la continuité d'activité ;
ISO/IEC 27017 — contrôles de sécurité pour les services cloud ;
SOC 2 Type II — contrôles de sécurité, disponibilité, intégrité du traitement, confidentialité et protection des données personnelles ;
C5 — catalogue de conformité pour le cloud computing, développé par le BSI allemand.

AWS dispose de plus de 150 certifications de sécurité vérifiées de manière indépendante à l'échelle mondiale. Dans le contexte de la Loi NIS2 belge, cela est essentiel car l'Art. 21, paragraphe 1, de la Directive (UE) 2022/2555 exige que les mesures de gestion des risques reflètent l'« état de l'art ». L'utilisation d'une infrastructure certifiée démontre le respect de ce principe.

Modèle de responsabilité partagée

AWS applique le modèle de responsabilité partagée (Shared Responsibility Model) :

AWS est responsable de la sécurité de l'infrastructure cloud — centres de données physiques, réseau, hyperviseur, services gérés ;
Le client est responsable de la sécurité de ce qu'il construit dans le cloud — code applicatif, configurations, contrôle d'accès.

Pour les clients enterprise, chaque solution est soumise à un processus structuré d'audit et de revue de sécurité avant la mise en production.

Compte AWS dédié pour chaque client enterprise

Parmi les exigences centrales de la NIS2 figure la garantie de la continuité des opérations et de la gestion de crise (Art. 21, paragraphe 2, point c) de la Directive (UE) 2022/2555). La Directive met également l'accent sur la sécurité de la chaîne d'approvisionnement (Art. 21, paragraphe 2, point d)), y compris la gestion des risques liés aux dépendances envers les fournisseurs technologiques.

OpenKBS répond à ces exigences par un modèle de comptes AWS dédiés.

Fonctionnement

Chaque client enterprise reçoit un compte AWS propre, dans lequel toutes ses ressources sont déployées :

Ressource	Description
Fonctions Lambda	Calcul serverless pour la logique métier (jusqu'à 20 par projet)
Stockage S3	Stockage objet pour fichiers et données
Aurora PostgreSQL	Base de données relationnelle gérée avec sauvegardes automatiques et restauration point-in-time
CloudFront CDN	Distribution de contenu avec chiffrement TLS
EventBridge	Tâches planifiées et automatisations

Les ressources d'un client sont physiquement isolées de celles de tout autre client au niveau du compte AWS. Il ne s'agit pas d'une séparation logique (namespace, tag ou réseau virtuel), mais d'une frontière dure au niveau du compte, appliquée par AWS Identity and Access Management (IAM).

Transfert de l'infrastructure en fin de contrat

En fin de contrat ou en cas de besoin, le compte AWS dédié peut être transféré intégralement au client. Le processus comprend :

Changement de l'utilisateur root du compte vers une adresse e-mail du client ;
Confirmation par le client et définition d'un nouveau mot de passe ;
Retrait du compte de l'AWS Organization d'OpenKBS ;
Le client ajoute un moyen de paiement et prend le contrôle complet ;
Le client supprime l'accès d'OpenKBS en supprimant le rôle IAM cross-account.

Rien n'est migré. Les fonctions Lambda continuent de fonctionner, les données dans S3 et Aurora restent en place, les distributions CloudFront servent le trafic sans interruption. Le client obtient le contrôle total de son infrastructure sans perte de données et sans temps d'arrêt.

Toutes les ressources sont des primitives AWS standard — aucun format propriétaire, aucun vendor lock-in. Le client peut continuer à gérer son infrastructure de manière autonome ou avec un autre fournisseur.

AWS Organizations permet la création de jusqu'à 50 000 comptes au sein d'une organisation, sans frais supplémentaires pour le compte lui-même. Seule la consommation des ressources au sein du compte est facturée.

Implications pour la conformité NIS2

Art. 21, paragraphe 2, point c) (continuité des opérations) : L'infrastructure ne dépend pas du statut opérationnel d'OpenKBS. En cas de cessation d'activité du fournisseur, le client peut poursuivre ses opérations.
Art. 21, paragraphe 2, point d) (sécurité de la chaîne d'approvisionnement) : Le risque de dépendance envers un fournisseur unique est réduit au minimum grâce à la possibilité garantie de transfert complet.
Clause 5 des exigences contractuelles NIS2 (assistance à la cessation et sécurité des données) : Couverte par conception — les données se trouvent déjà dans un compte que le client peut reprendre intégralement.

Localisation des données et architecture serverless

Hébergement dans l'Union européenne

Toutes les ressources des clients enterprise sont déployées dans la région AWS eu-central-1 (Francfort, Allemagne) par défaut. La base de données centrale de la plateforme (AWS Aurora DSQL) fonctionne exclusivement dans eu-central-1.

Les données ne quittent pas le territoire de l'UE. Chaque projet client reçoit :

Stockage S3 dans eu-central-1 ;
Instance Aurora PostgreSQL dans eu-central-1 ;
Fonctions Lambda exécutées dans eu-central-1 ;
Distribution CloudFront avec emplacements edge dans l'UE.

La localisation des données est un facteur clé dans l'évaluation des risques au titre de la NIS2. Le déploiement de l'infrastructure dans l'UE simplifie le respect des exigences de protection des données et facilite l'interaction avec le CCB et les autres autorités compétentes.

Architecture serverless et surface d'attaque réduite

OpenKBS utilise une architecture entièrement serverless pour les ressources des clients. Cela signifie :

Aucun serveur à maintenir — pas de système d'exploitation à mettre à jour, pas d'accès SSH, pas de ports ouverts ;
AWS gère l'environnement d'exécution — Node.js 24.x sur Lambda, avec mises à jour de sécurité automatiques ;
Isolation au niveau de l'exécution — chaque fonction Lambda s'exécute dans un environnement microVM séparé ;
TLS 1.2+ pour toutes les communications — via CloudFront, sans exception.

Du point de vue de l'Art. 21, paragraphe 2, point e) de la Directive (UE) 2022/2555 (sécurité dans l'acquisition, le développement et la maintenance des réseaux et systèmes d'information), l'architecture serverless élimine une classe entière de vulnérabilités — systèmes d'exploitation non corrigés, serveurs mal configurés, accès réseau non autorisé.

Sécurité du code généré par l'IA

La réalité du développement moderne

Une part significative et croissante du code dans l'industrie est générée à l'aide de modèles d'IA. Cette tendance est irréversible. La question n'est pas de savoir si l'IA générera le code, mais quels processus garantissent la qualité et la sécurité de ce code.

Le code généré par l'IA n'est pas intrinsèquement non sécurisé. Les modèles linguistiques modernes (comme Claude d'Anthropic) détectent les vulnérabilités dans le code de manière plus efficace que la plupart des revues manuelles — y compris les injections SQL, les attaques XSS, l'accès non autorisé, la gestion incorrecte des sessions et des dizaines d'autres catégories des OWASP Top 10 et des classifications CWE.

Les risques du code généré par l'IA ne proviennent pas du modèle lui-même, mais de l'absence de processus d'audit et de validation. Un système dans lequel le code généré est déployé directement sans revue est risqué — que le code ait été écrit par un humain ou par une IA.

Le processus OpenKBS pour les clients enterprise

OpenKBS applique un processus structuré de revue de sécurité pour chaque nouvelle version de la solution client :

Audit de sécurité automatisé pour chaque version :

Analyse statique du code pour les vulnérabilités des OWASP Top 10 ;
Vérification des injections SQL, XSS, CSRF, SSRF, injection de commandes ;
Analyse des dépendances (dependency audit) pour les vulnérabilités connues (CVE) ;
Vérification de la divulgation de données sensibles (identifiants en dur, clés API, chaînes de connexion) ;
Validation des données d'entrée et contrôle d'accès ;
Vérification de la divulgation non autorisée d'informations dans les réponses HTTP et la gestion des erreurs.

Revue de l'infrastructure :

Revue des politiques IAM et du principe du moindre privilège (least privilege) ;
Validation du chiffrement en transit (TLS) et au repos (AES-256) ;
Vérification des ressources accessibles publiquement (buckets S3, endpoints Lambda) ;
Audit de la configuration réseau et des règles de pare-feu.

Rapport documenté :

Chaque audit génère un rapport documenté avec des constatations et des recommandations ;
Les vulnérabilités critiques sont corrigées avant le déploiement en production ;
Les rapports sont accessibles au client et peuvent être fournis au CCB ou à d'autres autorités lors d'un audit.

Ce processus répond aux exigences de l'Art. 21, paragraphe 2, point e) (sécurité dans le développement et la maintenance) et de l'Art. 21, paragraphe 2, point f) (politiques et procédures d'évaluation de l'efficacité des mesures de gestion des risques).

Consolidation de la chaîne d'approvisionnement IA

Une organisation qui souhaite utiliser des modèles d'IA de plusieurs fournisseurs (OpenAI, Anthropic, Google) doit conclure des contrats séparés, effectuer des évaluations des risques séparées et assurer la conformité NIS2 pour chacun d'entre eux.

OpenKBS consolide l'accès à plusieurs modèles d'IA via un proxy unifié, opérant dans l'infrastructure UE de la plateforme. Le client interagit avec un seul fournisseur (OpenKBS), qui gère l'intégration avec les fournisseurs d'IA.

Cela réduit :

le nombre de fournisseurs soumis à évaluation au titre de l'Art. 21, paragraphe 2, point d) de la NIS2 ;
le nombre de contrats devant contenir les cinq clauses obligatoires sur la sécurité de la chaîne d'approvisionnement ;
la charge administrative lors de la revue périodique des fournisseurs.

Mesures de conformité complémentaires

Chiffrement

Conformément à l'Art. 21, paragraphe 2, point h) de la Directive (UE) 2022/2555 (politiques d'utilisation de la cryptographie) :

En transit : TLS 1.2+ pour toutes les communications, sans exception ;
Au repos : AES-256 pour les données sensibles (chaînes de connexion, clés API), chiffrement géré par AWS pour S3 et Aurora ;
Jetons d'accès : Stockés sous forme de hachage SHA-256, le texte original n'est pas conservé ;
Communications MQTT : Connexions WebSocket signées SigV4 avec jetons de session STS temporaires (validité de 15 minutes).

Contrôle d'accès

Conformément à l'Art. 21, paragraphe 2, point i) (sécurité des ressources humaines, contrôle d'accès) :

Authentification JWT (RS256) avec durée de validité limitée ;
Clés API par projet avec permissions explicitement définies ;
Rotation automatique des clés à chaque déploiement ;
STS session credentials d'une validité de 15 minutes pour l'accès cross-account.

Journal d'audit

Conformément à l'Art. 21, paragraphe 2, point f) (évaluation de l'efficacité des mesures) :

Journal d'audit administratif : type d'action, ressource concernée, détails, adresse IP ;
Suivi de la consommation des ressources par projet et par période ;
Métriques CloudWatch pour chaque fonction (invocations, durée, erreurs).

Sauvegardes, restauration et plan de reprise d'activité

Conformément à l'Art. 21, paragraphe 2, point c) (continuité des opérations, gestion des sauvegardes, reprise après sinistre et gestion de crise) :

Base de données (Aurora PostgreSQL Serverless v2) :

Sauvegardes continues automatiques, gérées par AWS ;
Restauration à un instant précis (point-in-time restore) avec une précision à la seconde, pour une période configurable allant jusqu'à 35 jours ;
Les données sont conservées en six copies réparties sur trois zones de disponibilité (Availability Zones) dans la région eu-central-1 ;
En cas de défaillance de l'instance primaire, Aurora bascule automatiquement vers une réplique de secours.

Stockage objet (S3) :

Versionnement des objets — chaque modification ou suppression conserve la version précédente ;
AWS S3 garantit 99,999999999 % (11 neuf) de durabilité des données ;
Les données sont conservées dans plusieurs zones de disponibilité dans la région.

Principes généraux :

Suppression douce (soft delete) de toutes les ressources — aucune suppression irréversible ;
L'architecture serverless élimine la nécessité de restaurer des serveurs — en cas de défaillance d'une instance Lambda, AWS en démarre automatiquement une nouvelle ;
CloudFront CDN assure la distribution du trafic même en cas d'indisponibilité partielle du serveur d'origine.

Synthèse : couverture des mesures minimales de l'Art. 21 NIS2

Mesure de l'Art. 21, paragraphe 2	Comment OpenKBS y répond
a) Analyse des risques et politiques de sécurité	Processus d'audit structuré pour chaque version ; rapports documentés
b) Gestion des incidents	Procédure de réponse aux incidents ; alerte précoce au client sous 24 heures
c) Continuité des opérations	Compte AWS dédié ; Aurora PITR jusqu'à 35 jours ; versionnement S3 ; 6 copies dans 3 AZ
d) Sécurité de la chaîne d'approvisionnement	Proxy IA consolidé ; contrat unique ; compte transférable
e) Sécurité dans le développement et la maintenance	Audit de sécurité pour chaque version ; architecture serverless
f) Évaluation de l'efficacité des mesures	Journal d'audit ; surveillance des ressources ; métriques CloudWatch
g) Formation à la cybersécurité	Conseil et documentation pour les équipes des clients
h) Cryptographie et chiffrement	TLS 1.2+ ; AES-256 ; SHA-256 pour les jetons ; SigV4 pour MQTT
i) Contrôle d'accès	Authentification JWT ; clés par projet ; rotation automatique
j) MFA et communications chiffrées	Connexions WebSocket chiffrées ; STS session credentials

Prochaine étape

OpenKBS collabore avec des entreprises industrielles en Belgique et en Europe qui déploient des solutions d'IA dans le respect des exigences de la Loi NIS2.

Si votre organisation relève du champ d'application de la Loi du 26 avril 2024 et envisage une transformation IA, contactez-nous pour une consultation portant sur :

l'évaluation de votre infrastructure actuelle au regard des exigences de la NIS2 ;
la conception d'une solution IA dans un compte AWS dédié avec EU Data Residency ;
les processus d'audit de sécurité pour le code généré par l'IA ;
le plan de continuité d'activité et de gestion de crise.

Les services décrits — audit de sécurité, compte AWS dédié et revue du code généré par IA — font partie du plan Enterprise d'OpenKBS.

La présente publication a un caractère informatif et ne constitue pas un conseil juridique. Pour toute question spécifique relative à l'application de la Loi du 26 avril 2024 ou de l'Arrêté royal du 9 juin 2024, veuillez consulter un conseiller juridique qualifié.

Book a Strategy Call

NIS2Loi NIS2CCBcybersécuritéindustriefabricationBelgiqueAWSIAenterprise