Cinq règles de l'UE qui façonnent désormais l'architecture des systèmes

La réglementation se lit d'ordinaire comme une liste d'obligations à documenter. Les cinq instruments de cet article se lisent mieux comme une liste de propriétés qu'un système doit pouvoir montrer : où passe une frontière, ce qu'un build produit, qui peut atteindre un dépôt et depuis où, où les données doivent pouvoir aller, et qui répond quand quelque chose tourne mal. Chacun d'eux a changé de statut entre septembre 2025 et septembre 2026, et chacun a été lu à sa source primaire le 17 septembre 2026. Les dates sont celles des instruments eux-mêmes, non celles de comptes rendus secondaires.

Ceci est une carte, non un conseil. Savoir si l'un de ces textes s'applique à un système donné est une détermination juridique qui dépend du produit, du secteur et du rôle de l'organisation, et rien de ce qui suit ne la remplace. Ce que fait l'article, c'est traduire chaque instrument en la question architecturale qu'il impose, parce que cette question doit trouver sa réponse dans la conception, avant qu'un juriste ne soit consulté.

Le règlement (UE) 2024/1689, le règlement sur l'IA, ne s'applique pas aux systèmes d'IA dans la mesure où ils sont mis sur le marché, mis en service ou utilisés, avec ou sans modification, exclusivement à des fins militaires, de défense ou de sécurité nationale (article 2, paragraphe 3). Le mot qui compte est exclusivement. Un système construit pour un usage civil et pour un usage de défense n'est pas exclusivement militaire, de sorte que son usage civil relève pleinement du règlement, quel que soit son usage de défense.

Le calendrier a bougé cet été. Le règlement (UE) 2026/1744, l'omnibus numérique, est entré en vigueur le 27 juillet 2026 et a recalendarisé le régime à haut risque : les catégories autonomes de l'annexe III, comme les décisions d'emploi et l'accès aux services essentiels, s'appliquent à partir du 2 décembre 2027, et les systèmes intégrés dans des produits réglementés au titre de l'annexe I à partir du 2 août 2028. Les obligations de transparence de l'article 50 n'ont pas été reportées et s'appliquent depuis le 2 août 2026, avec une transition jusqu'au 2 décembre 2026 uniquement pour l'obligation de marquage des systèmes génératifs déjà sur le marché. Les interdictions de l'article 5 s'appliquent depuis le 2 février 2025.

Pour l'architecture, l'article 2, paragraphe 3, est une frontière qui doit exister dans le système, et pas seulement dans un contrat. Si un modèle entraîné sur des données civiles est réutilisé dans un contexte de défense, ou si un composant de défense est réutilisé dans un produit civil, les deux usages doivent pouvoir être séparés à la demande : des déploiements distincts, des pipelines qui ne partagent pas de données d'entraînement ni de poids par accident, et une provenance pour chaque artefact qui dit de quel côté il appartient et à partir de quoi il a été construit. C'est la logique du passeport numérique de produit appliquée aux modèles, aux jeux de données et aux prompts. Un artefact qui ne peut pas énoncer son origine ne peut être placé d'aucun côté de la ligne.

Le règlement (UE) 2024/2847, le Cyber Resilience Act, s'applique dans son intégralité à partir du 11 décembre 2027, mais son obligation de notification est arrivée en premier. Depuis le 11 septembre 2026, l'article 14 impose à un fabricant qui a connaissance d'une vulnérabilité activement exploitée dans un produit comportant des éléments numériques, ou d'un incident grave affectant sa sécurité, de le notifier via la plateforme unique de notification exploitée par l'ENISA : une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final au plus tard 14 jours après la disponibilité d'une mesure corrective, ou un mois pour un incident. Les utilisateurs touchés doivent être informés sans retard injustifié, avec les mesures qu'ils peuvent prendre (article 14, paragraphe 8). Le chapitre IV, sur les organismes qui évalueront les produits, s'applique depuis le 11 juin 2026.

Une horloge de 24 heures ne se respecte pas avec un processus qui commence par l'ouverture d'un tableur. Elle suppose que le fabricant sait déjà ce que contient chaque version livrée, ce qui exige une nomenclature logicielle produite par le build et non rédigée après coup ; qu'il apprend l'exploitation depuis le terrain, ce qui exige une télémétrie du produit déployé et un canal pour les signalements de vulnérabilités ; et qu'il peut livrer une version corrective en quelques jours, ce qui exige un pipeline de livraison exercé en routine et non seulement en urgence. En Allemagne, la directive technique TR-03183 de l'Office fédéral de la sécurité des technologies de l'information décrit le contenu minimal qu'une telle nomenclature devrait porter.

Le règlement (UE) 2021/821 contrôle les exportations de biens à double usage, et sa définition de l'exportation ne s'arrête pas aux marchandises qui franchissent une frontière. Elle inclut la transmission de logiciels ou de technologies par voie électronique, et la mise à disposition de ces logiciels ou technologies sous forme électronique à des personnes situées hors du territoire douanier de l'Union (article 2, point 2). Une personne hors de l'Union qui reçoit l'accès à un dépôt, à un stockage d'objets ou à un cluster contenant une technologie contrôlée reçoit, au sens de cette définition, une exportation, et celle-ci nécessite la même autorisation qu'une expédition.

La liste de contrôle, l'annexe I, a été mise à jour par le règlement délégué (UE) 2025/2003 de la Commission, en vigueur depuis le 15 novembre 2025. La mise à jour a intégré les ordinateurs quantiques et leurs composants cryogéniques, les équipements et matériaux pour la fabrication de semi-conducteurs avancés, le calcul haute performance, les systèmes de fabrication additive pour métaux et les poudres qu'ils utilisent, ainsi que d'autres matériaux avancés. Une bonne partie de cette liste décrit ce pour quoi une entreprise de logiciel industriel construit, ou ce sur quoi elle s'exécute.

Sur le plan architectural, cela fait de la gestion des identités et des accès un instrument de contrôle des exportations. Une décision d'accès doit pouvoir évaluer où se trouve la personne et où iraient les données avant d'accorder quoi que ce soit ; lorsque des biens d'origine américaine sont en jeu, les règles de ce pays ajoutent la nationalité comme attribut, ce que le droit européen ne fait pas. Ces deux attributs sont des données à caractère personnel, leur collecte doit donc être justifiée au regard de la minimisation des données de l'article 5, paragraphe 1, point c), du RGPD, et cette tension doit être conçue plutôt que découverte. Et parce qu'une classification appartient à un artefact et non à une équipe, elle doit voyager avec l'artefact tout au long du build : un dépôt, une image de conteneur et un point de contrôle de modèle portent chacun leur propre classification, et un pipeline qui ne peut pas la lire ne peut pas la faire respecter.

Le règlement (UE) 2023/2854, le Data Act, s'applique depuis le 12 septembre 2025. Il donne aux utilisateurs de produits connectés, et des services qui leur sont liés, le droit d'accéder aux données que ces produits génèrent et de les faire partager avec un tiers de leur choix (articles 4 et 5). Pour les produits mis sur le marché après le 12 septembre 2026, le produit lui-même doit être conçu de sorte que les données soient accessibles par défaut, facilement, de manière sécurisée et dans un format complet, structuré et lisible par machine (article 3, paragraphe 1).

Le même règlement atteint les fournisseurs de cloud. Les fournisseurs de services de traitement de données doivent permettre à un client de passer à un autre fournisseur ou à sa propre infrastructure, avec une équivalence fonctionnelle lorsque le service est du même type. Les frais de changement sont réduits depuis le 11 janvier 2024 et ne pourront plus être imposés du tout à partir du 12 janvier 2027 (article 29).

Pour une architecture industrielle ou de périphérie, la conséquence est qu'une interface d'export de données est une fonctionnalité de produit dotée d'une définition légale, et qu'un déploiement capable de quitter son fournisseur de cloud est une exigence et non une préférence. Le modèle de données d'une machine, et les formats dans lesquels les données la quittent, font désormais partie de ce qu'une conception doit montrer.

La directive (UE) 2022/2555, NIS2, a obligé les États membres à appliquer leurs mesures de transposition à partir du 18 octobre 2024. L'Allemagne a été en retard : sa loi de transposition, la NIS2UmsuCG, est entrée en vigueur le 6 décembre 2025 et a réécrit la loi sur le BSI. L'estimation du gouvernement fédéral accompagnant le projet de loi chiffrait à environ 29 500 les entités nouvellement concernées, dans dix-huit secteurs, avec l'Office fédéral de la sécurité des technologies de l'information (BSI) comme autorité de surveillance.

Deux dispositions portent le poids architectural. L'obligation de notification des incidents a la même forme que dans le Cyber Resilience Act : une alerte précoce sous 24 heures après avoir eu connaissance d'un incident important, une notification sous 72 heures et un rapport final sous un mois (article 23 de la directive). Et l'article 38 de la nouvelle loi sur le BSI rend les membres de la direction d'une entité personnellement responsables d'approuver les mesures de gestion des risques, d'en surveiller la mise en œuvre et de suivre des formations, et il n'autorise pas à se défaire de cette responsabilité.

Dès lors qu'une direction répond personnellement, la sécurité cesse d'être une fonction de soutien et devient une propriété que l'architecture doit démontrer : un inventaire de ce qui tourne, un chemin d'incident capable de tenir un délai de 24 heures, une résilience pendant une attaque et pas seulement après, et des preuves que les mesures approuvées sont effectivement en place. Une mesure qui existe dans un document de politique et nulle part dans le système est exactement ce sur quoi une autorité de surveillance posera des questions.

Mis côte à côte, les cinq instruments demandent cinq propriétés architecturales. Le règlement sur l'IA demande où passe la frontière entre usage civil et usage de défense, et une preuve du côté où se trouve chaque artefact. Le Cyber Resilience Act demande ce qu'un build produit et à quelle vitesse un correctif peut être livré. Le contrôle des exportations demande qui peut atteindre un dépôt et depuis où. Le Data Act demande où les données doivent pouvoir aller et sous quelle forme. NIS2 demande qui a approuvé le risque et comment montrer que ce qui a été approuvé est bien ce qui tourne.

Ce que les cinq partagent, c'est une exigence de provenance et de preuve au niveau de l'artefact individuel : un modèle, un build, une image de conteneur, un jeu de données, le flux de données d'une machine, chacun portant son origine, sa classification et les contrôles qu'il a passés. C'est la propriété qu'un passeport numérique de produit donne à un produit physique, et c'est la propriété que ces textes demandent désormais au logiciel. Un système qui la porte répond aux cinq questions à partir de ses propres enregistrements. Un système qui ne la porte pas doit reconstruire la réponse à chaque fois, sous délai.

Il ne dit pas que l'un de ces instruments s'applique à un système, un produit ou une organisation donnés. Le champ d'application dépend de faits que cet article n'a pas, et de définitions, comme produit comportant des éléments numériques, entité essentielle ou détenteur de données, que chaque texte définit pour lui-même.

Il ne dit pas que l'architecture décrite ici suffit. Des déploiements distincts, une nomenclature, un accès fondé sur des attributs, une interface d'export et un chemin d'incident sont ce que les textes présupposent ; chaque instrument demande davantage, et une partie, comme l'évaluation des produits au titre du Cyber Resilience Act ou l'enregistrement auprès du BSI, est procédurale plutôt que technique.

Et il ne dit pas que les dates sont définitives. Trois des cinq instruments ont déjà bougé une fois. Chaque date ci-dessus nomme l'instrument dont elle provient, afin qu'elle puisse être vérifiée contre le texte le jour où elle compte.