NIS2 rencontre le CLOUD Act : qui est responsable de la faille des tiers États ?

8 min de lecture

NIS2 oblige les exploitants allemands à vérifier leurs chaînes d’approvisionnement, ce qui contrecarre le US CLOUD Act en même temps. Quiconque exploite un hyperscaler américain avec des données allemandes se retrouve face à deux autorités exigeant un accès contradictoire. La responsabilité ne repose plus en 2026 sur les achats, mais sur la direction générale.

Similaire :Conformité NIS2 dans les PME : étapes réalisables  /  DORA et NIS2 : pourquoi les audits bancaires entrent désormais en collision

Ce que l’obligation de chaîne d’approvisionnement NIS2 exige réellement

Qu’est-ce que la sécurité de la chaîne d’approvisionnement selon NIS2 ? La sécurité de la chaîne d’approvisionnement au sens de la directive NIS2 oblige les entités concernées à évaluer systématiquement, documenter et sécuriser contractuellement la sécurité de leurs fournisseurs et prestataires. Cela inclut les fournisseurs de services cloud, les prestataires de services gérés et les fournisseurs de logiciels. La responsabilité incombe à la direction générale et n’est pas délégable.

L’article 21 paragraphe 2 point d de la directive NIS2 et sa mise en œuvre dans le NIS2UmsuCG exigent explicitement que la sécurité de la chaîne d’approvisionnement soit intégrée à la gestion des risques. La loi nomme quatre points précis : les vulnérabilités des fournisseurs directs, les pratiques de sécurité des fournisseurs, la réaction aux incidents de sécurité dans la chaîne, et la fiabilité de cette relation fournisseur tout au long de la durée du contrat.

Celui qui met cela en œuvre dans la pratique ne peut éviter une question : quels fournisseurs de cloud font partie de sa propre chaîne d’approvisionnement, et quels sous-fournisseurs ont-ils eux-mêmes intégrés. Dans le cadre d’un audit, répondre « nous utilisons Azure » est insuffisant. Une vue à deux niveaux d’intervalle est requise.

Comment le US CLOUD Act contourne la protection européenne

L’US Clarifying Lawful Overseas Use of Data Act de 2018 permet aux autorités américaines de poursuite pénale d’exiger des données auprès des fournisseurs américains, indépendamment de l’emplacement de stockage de ces données. AWS, Microsoft et Google sont des fournisseurs américains. Le choix d’une région allemande ne change rien à cet égard. Le fournisseur est tenu de coopérer, tandis que le client allemand n’est informé dans de nombreux cas.

Ce n’est pas un secret. Cela figure dans les contrats de traitement des données des hyperscalers, généralement sous la rubrique « Government Access Requests » ou « Law Enforcement Demands ». Ceux qui ne l’ont pas lu n’ont pas rempli leur obligation de diligence envers leurs fournisseurs. Ceux qui l’ont lu et ignoré ont un autre problème : ils savent que leurs clauses contractuelles types conformes à Schrems II cèdent en cas de conflit, et ont signé malgré tout.

Dans son arrêt Schrems II de 2020, la CJUE a jugé que les clauses contractuelles types ne suffisent que si le niveau de protection du pays tiers est effectivement équivalent. Le CLOUD Act ne rend pas ce niveau équivalent. Le cadre UE-États-Unis sur la protection des données (Data Privacy Framework) de 2023 atténue cela au niveau applicatif, mais ne résout pas le conflit structurel. Les autorités de protection des données et les régulateurs l’évaluent différemment, ce qui ne facilite pas la conformité.

Qui utilise un hyperscaler américain accepte contractuellement une clause d’accès par les autorités, qui entre en conflit avec la protection des données européenne. Il s’agit d’une prise de risque consciente, non d’une faiblesse technique résiduelle.

Les pays tiers ne se limitent pas aux États-Unis

Le débat public se concentre sur les fournisseurs américains. La réalité des chaînes d’approvisionnement est bien plus large. Un SOC géré par un MSSP allemand travaille souvent avec des analystes basés en Inde, un fournisseur de sauvegarde cloud stocke ses données en Pologne et ses copies de sécurité en Israël, et un éditeur SaaS de logiciels RH dispose de pôles de développement au Vietnam. Chacun de ces sites possède sa propre logique d’accès des autorités et sa propre interprétation de l’exportation de données.

Source : Analyse propre basée sur le NIS2UmsuCG et les décisions d’adéquation de la Commission européenne, arrêtée en mai 2026.

Un registre des risques qui ne reflète pas cette dimension est vulnérable lors d’un audit NIS2. L’autorité de contrôle ne s’intéresse pas à vos fournisseurs préférés, mais à votre méthodologie d’évaluation. Si vous comptez cinq sous-traitants dans trois pays tiers et que vous ne disposez d’aucune évaluation écrite du risque d’accès des autorités, vous n’avez pas formellement respecté les obligations de diligence requises par la directive NIS2.

Où les pièges de responsabilité se referment réellement

Trois situations concrètes révèlent la responsabilité personnelle de la direction. Premièrement, en cas d’incident de sécurité avec fuite de données : si l’enquête démontre que la chaîne d’approvisionnement n’a pas été évaluée, cela constitue un manquement au devoir de diligence. Deuxièmement, lors d’un audit sans incident : une autorité de contrôle peut sanctionner l’absence de documentation même en l’absence de préjudice. Troisièmement, dans le cadre d’une procédure civile : si des données clients sont compromises suite à un transfert vers un pays tiers, des actions en réparation sont engagées, dont le montant du litige dépend directement du volume de données concernées.

Les hyperscalers ne seront pas les principaux mis en cause dans ces procédures. Leurs conditions générales d’utilisation définissent clairement ce qu’ils fournissent et ce qu’ils ne fournissent pas. Les véritables responsables seront les donneurs d’ordre qui ont signé sans prévoir contractuellement les implications. C’est précisément cette construction juridique que la directive NIS2 entend désormais traiter explicitement.

Quatre étapes concrètes qui doivent maintenant figurer dans le registre des risques

Étape un : Inventaire des fournisseurs liés à des pays tiers. Quel fournisseur, quel contrat, quel lieu de traitement effectif, quel sous-traitant. Celui qui peut réduire cela à une feuille Excel doit être en mesure de la présenter à une autorité de contrôle.

Étape deux : Évaluation écrite des risques par fournisseur. Pas « nous faisons confiance à AWS », mais : quels sont les droits d’accès des autorités, quelles catégories de données sont concernées, quelles mesures atténuent le risque. La cryptage avec des clés client est une mesure, la restriction géographique en est une autre. Les deux doivent être documentées.

Étape trois : Renforcement contractuel. Les clauses contractuelles standard plus des mesures supplémentaires de protection sont obligatoires, pas recommandées. Cela signifie concrètement : contrôle du chiffrement, droit d’audit, obligation de signaler aux autorités, clauses de sortie avec un chemin de transfert des données.

Étape quatre : Décision de direction. Le choix du fournisseur et l’évaluation du risque résiduel doivent être documentés dans une décision prise par la direction. Pas sur une diapositive de stratégie cloud. Dans un compte-rendu que l’autorité de contrôle puisse suivre.

Quand un changement vers des fournisseurs européens est réaliste

La réponse honnête est : non pour toutes les charges de travail, pas tout de suite. L’initiative European Open Cloud ainsi que des offres souveraines comme OVHcloud, Open Telekom Cloud ou Stackit couvrent un spectre croissant, mais elles ne remplacent pas toutes les fonctions techniques d’un hyperscaler. Celui qui a besoin d’équivalents tels que Bedrock-Inference, Aurora Serverless ou des fonctionnalités spécifiques Microsoft Identity n’a aujourd’hui aucun remplacement 1:1.

Ce n’est pas une raison pour rester dans la situation actuelle. C’est une raison d’adopter une architecture différenciée. Les catégories de données sensibles migrent vers des fournisseurs européens ou restent sur site. Les charges de travail génériques restent sur l’hyperscaler, accompagnées de mesures de protection documentées. L’architecture plateforme 2026 sera polyglotte, pas soit-disant-soit.

Foire aux questions

Le cadre de protection des données UE-États-Unis est-il une base suffisante pour l’utilisation des clouds américains ?

Le cadre de 2023 a rétabli le jugement sur l’adéquation et constitue la base juridique actuelle. Plusieurs autorités de protection des données et des avis juridiques s’attendent cependant à un nouveau procès devant la Cour de justice de l’Union européenne (CJUE), qui vérifiera à nouveau la solidité de ce cadre. Celui qui s’appuie uniquement sur ce cadre accepte le risque d’une décision Schrems III. Un cadre combiné à des mesures techniques supplémentaires, notamment le chiffrement avec des clés client, est fiable.

Une cryptage sur l’hyperscaler suffit-il à se protéger contre le CLOUD Act ?

Une cryptage côté serveur du fournisseur ne suffit pas, car le fournisseur gère les clés et peut être contraint de les transmettre dans le cadre d’une procédure administrative. Les solutions Bring-Your-Own-Key ou Hold-Your-Own-Key avec gestion externe des clés combinent techniquement cette lacune, à condition que le gestionnaire de clés lui-même ne soit pas accessible selon le droit américain. Il convient également de noter que tous les fournisseurs ne proposent pas HYOK pour tous les services.

Que se passe-t-il si un hyperscaler reçoit un ordre CLOUD Act ?

Le fournisseur est tenu de fournir les données demandées. Il peut déposer un recours, ce qui réussit rarement en pratique. Une notification au client n’a souvent pas lieu, car l’ordre peut comporter une obligation de silence. Le commanditaire apprend généralement seulement ultérieurement, lors d’un procès, que des données ont été transmises.

Les petites entreprises doivent-elles effectuer des vérifications de chaîne d’approvisionnement NIS2 ?

Les obligations NIS2 s’appliquent à partir d’une certaine taille ou si l’activité relève d’un secteur réglementé. Les petites entreprises ne sont généralement pas directement tenues de le faire, mais sont incluses contractuellement dans l’examen par leurs clients soumis à NIS2. Cela déplace effectivement l’obligation vers la chaîne d’approvisionnement. Si une PME a un client soumis à NIS2, elle doit pouvoir fournir des informations.

Source d’image : générée par l’IA (mai 2026), certificat C2PA inclus dans l’image