Les textes qui imposent un niveau de confiance

Pourquoi

Trois clients, une même application, trois réponses différentes.

La mairie d'une commune de 12 000 habitants utilise Signalements depuis deux ans. Son délégué à la protection des données a demandé où étaient les serveurs ; « en France, chez Scaleway » a suffi. La métropole de la leçon 3 exige un hébergement qualifié SecNumCloud dans son cahier des charges. Le groupement hospitalier de territoire qui veut signaler les pannes dans ses bâtiments demande un hébergeur « certifié HDS », parce que « c'est l'hôpital ».

L'équipe de Lyneko est tentée par deux réponses simples, et fausses toutes les deux. La première : « le plus exigeant gagne », tout le monde passe sur une offre qualifiée et certifiée, et le prix de Signalements double pour la mairie qui n'en demandait pas tant. La seconde : « ce sont des préférences, on négocie », et l'on découvre trop tard qu'une exigence était une obligation légale, dont la méconnaissance peut faire annuler un marché ou engager la responsabilité du client.

Entre les deux, il y a un travail de lecture : quel texte s'applique à quel client, pour quelles données, et qu'impose-t-il vraiment ? Ce travail ne remplace pas l'avis d'un juriste ; il permet de lui poser des questions précises, et de ne pas lui soumettre celles dont la réponse est dans le texte. C'est l'objet de cette leçon. Toutes les dates qu'elle cite sont arrêtées au 5 octobre 2026 : dans ce domaine, une affirmation juste il y a un an peut ne plus l'être.

Les concepts

Trois sortes d'exigences

Avant de lire les textes, distinguez la force de ce que l'on vous demande :

Une même phrase, « hébergement qualifié SecNumCloud », peut relever de l'une ou l'autre selon le client. C'est la première chose à établir.

La méthode : statut, données, texte

Pour chaque client, trois questions dans l'ordre :

1. Qui est le client ? Son statut juridique (administration de l'État, opérateur, établissement public, collectivité territoriale, entreprise), son secteur (santé, finance, énergie), sa taille. La plupart des textes définissent leur champ par le statut.
2. Quelles données ? Données à caractère personnel ou non, données de santé, données protégées par un secret légal, données nécessaires à des missions essentielles. Beaucoup de textes ne s'appliquent qu'à certaines catégories.
3. Quel texte, et qu'impose-t-il ? Localisation, qualification, certification, mesures de sécurité, clauses contractuelles, notification d'incidents.

La matrice de la section En pratique applique cette méthode.

Le socle commun : le RGPD

Le règlement général sur la protection des données s'applique dès que des données à caractère personnel sont traitées, ce qui est le cas de Signalements : nom et adresse électronique des agents, parfois des habitants qui signalent, photos qui peuvent montrer des personnes ou des plaques d'immatriculation.

Pour l'hébergement, quatre points comptent :

• le client est responsable de traitement, Lyneko est son sous-traitant et doit signer un contrat conforme à l'article 28 ; Scaleway est un sous-traitant ultérieur, que Lyneko doit déclarer et encadrer ;
• le RGPD n'impose pas d'héberger les données dans l'Union, mais il encadre strictement leur transfert hors de l'Espace économique européen (chapitre V), ce qui inclut, selon la jurisprudence analysée à la leçon 2, l'accès possible depuis un pays tiers ;
• l'article 9 interdit en principe le traitement des catégories particulières de données, dont les données de santé, sauf exceptions ; l'article 4, point 15, définit les données concernant la santé comme les données « relatives à la santé physique ou mentale d'une personne physique, y compris la prestation de services de soins de santé, qui révèlent des informations sur l'état de santé de cette personne » ;
• l'article 32 impose des mesures de sécurité « appropriées » au risque, au responsable comme au sous-traitant.

Le RGPD est le plancher, pour les trois clients. Les textes suivants s'ajoutent selon le statut et les données.

La doctrine « cloud au centre »

La circulaire n° 6282-SG du 5 juillet 2021 du Premier ministre a fait du cloud le mode d'hébergement par défaut des services numériques de l'État. Elle a été actualisée par la circulaire n° 6404/SG du 31 mai 2023, qui précise notamment la notion de données sensibles : les données relevant des secrets protégés par la loi (articles L. 311-5 et L. 311-6 du code des relations entre le public et l'administration) et les données nécessaires à l'accomplissement des missions essentielles de l'État. Pour ces données, l'hébergement externalisé doit se faire sur une offre qualifiée SecNumCloud.

Deux précisions sur la portée de ce texte :

• une circulaire est une instruction du Premier ministre aux administrations de l'État et aux organismes sous leur tutelle ; elle ne s'impose pas aux collectivités territoriales, aux hôpitaux ou aux entreprises, même si beaucoup s'en inspirent ;
• jusqu'en 2026, cette doctrine était la seule base de l'exigence SecNumCloud dans l'administration. Elle a désormais une base légale, avec l'article 31 de la loi SREN et son décret d'application.

La loi SREN, son décret et ses arrêtés

La loi n° 2024-449 du 21 mai 2024 visant à sécuriser et à réguler l'espace numérique (loi SREN) contient, dans son article 31, une obligation légale qui reprend l'esprit de la doctrine : les administrations de l'État, certains de ses opérateurs et certains groupements d'intérêt public qui recourent à un service cloud fourni par un prestataire privé pour des données d'une sensibilité particulière doivent s'assurer que ce service protège ces données, notamment contre tout accès par des autorités publiques d'États tiers. L'article renvoie à un décret le soin de préciser les critères. Ce décret s'est fait attendre deux ans.

Le décret n° 2026-272 du 14 avril 2026, publié au Journal officiel du 16 avril 2026, met en œuvre l'article 31 :

• il définit les données d'une sensibilité particulière, en reprenant les deux catégories de la doctrine : les données protégées par les secrets des articles L. 311-5 et L. 311-6 du code des relations entre le public et l'administration, et les données nécessaires aux missions essentielles de l'État, notamment la sauvegarde de la sécurité nationale, le maintien de l'ordre public et la protection de la santé et de la vie des personnes ;
• il liste six groupements d'intérêt public soumis à l'obligation (article 1er) : l'Agence du numérique en santé, le Centre d'accès sécurisé aux données, le Centre ressources prévention de la radicalisation, le Collecteur analyseur de données, le GIP Modernisation des déclarations sociales et le Système national d'enregistrement de la demande de logement social ;
• il confie à l'ANSSI un référentiel d'exigences approuvé par arrêté du Premier ministre, couvrant dix domaines, de l'organisation de la sécurité à la localisation de l'hébergement et à la protection contre l'accès d'autorités publiques d'États tiers (article 2) ; le respect du référentiel est attesté par une qualification ou une certification européenne équivalente ;
• il prévoit des dérogations pour les services utilisés avant sa publication (article 3) : au plus dix-huit mois si une offre conforme existe, sinon un an renouvelable tant qu'aucune offre adaptée n'existe ; ces décisions sont rendues publiques. Un arrêté du même jour en fixe les modalités.

L'arrêté du 12 août 2026 approuve le référentiel annoncé : c'est le référentiel SecNumCloud 3.2, étudié à la leçon 3. Il est entré en vigueur au lendemain de sa publication, en août 2026. À partir de là, la chaîne est complète : pour les entités visées et leurs données d'une sensibilité particulière, l'hébergement dans un cloud privé passe par une offre qualifiée, sauf dérogation publique.

Ce que ces textes ne font pas, au 5 octobre 2026 :

• ils ne visent pas les collectivités territoriales : ni les communes, ni les métropoles, ni les départements, ni les régions. Une proposition de loi déposée par un député vise à étendre l'obligation aux régions, départements, communes et intercommunalités de plus de 30 000 habitants ; elle n'est pas adoptée à cette date ;
• ils ne visent pas les établissements publics de santé, qui ne sont pas des administrations de l'État, sauf à démontrer qu'un établissement entrerait dans une catégorie visée (à faire confirmer par un juriste) ;
• ils ne visent pas les entreprises privées, qui restent libres de leur choix sous réserve d'autres textes.

La direction des affaires juridiques du ministère de l'Économie a publié une fiche technique sur la mise en œuvre de l'article 31, accompagnée de clauses-types que les acheteurs publics peuvent reprendre dans leurs marchés. Un acheteur non soumis à l'obligation peut les utiliser par choix : l'exigence devient alors contractuelle.

La certification HDS

En France, l'hébergement de certaines données de santé est encadré par l'article L. 1111-8 du code de la santé publique. Il vise toute personne qui héberge des données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, pour le compte de ceux qui les produisent ou les recueillent, ou du patient lui-même. L'hébergeur doit être certifié (pour l'hébergement sur support numérique), au regard d'un référentiel publié par arrêté. Deux conditions sont donc cumulatives : des données de santé au sens du RGPD, et un contexte de prévention, de diagnostic, de soins ou de suivi.

Le référentiel de certification HDS a été révisé par un arrêté du 26 avril 2024, publié au Journal officiel du 16 mai 2024. Ses changements principaux pour notre sujet :

• les données de santé doivent être hébergées exclusivement dans l'Espace économique européen ;
• l'hébergeur doit informer ses clients des risques d'accès aux données par des autorités d'États tiers et des mesures prises pour les limiter, et publier une cartographie des éventuels transferts hors de l'EEE ;
• le référentiel est aligné sur la norme ISO/IEC 27001 dans sa version de 2022.

Calendrier : les nouveaux candidats sont évalués selon ce référentiel depuis le 16 novembre 2024, et les hébergeurs déjà certifiés avaient jusqu'au 16 mai 2026 pour s'y conformer. Au 5 octobre 2026, tout hébergeur certifié HDS doit donc respecter la version 2024.

Deux points pratiques :

• HDS et SecNumCloud sont indépendants. HDS impose une localisation dans l'EEE et la transparence sur les accès étrangers, mais pas les critères de capital et d'immunité du chapitre 19.6 de SecNumCloud. Un hébergeur peut être certifié HDS sans être qualifié SecNumCloud, et inversement (le référentiel SecNumCloud le rappelle lui-même).
• La certification HDS porte, comme la qualification, sur un périmètre : hébergement d'infrastructure physique, infogérance, sauvegarde, selon les activités certifiées. L'Agence du numérique en santé tient la liste des hébergeurs certifiés et de leurs périmètres ; c'est elle qu'il faut consulter, pas la plaquette.

NIS2 et sa transposition

La directive (UE) 2022/2555 du 14 décembre 2022, dite NIS2, impose des mesures de gestion des risques de cybersécurité et des obligations de notification d'incidents aux entités essentielles et entités importantes de nombreux secteurs (énergie, transports, santé, eau, infrastructures numériques, administration publique, etc.). Elle devait être transposée avant le 17 octobre 2024.

En France, la transposition passe par le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, qui transpose aussi la directive sur la résilience des entités critiques et la directive qui accompagne DORA. Ses étapes, d'après l'ANSSI et le suivi parlementaire :

Au 5 octobre 2026, la loi n'est pas promulguée, à notre connaissance : le texte attend son examen en séance publique à l'Assemblée nationale. NIS2 n'est donc pas encore applicable en droit français, et ne le sera pleinement qu'après la publication de la loi, puis de ses décrets et arrêtés.

Pour les collectivités, la directive laisse aux États le choix d'inclure les administrations locales. Le projet de loi français, tel qu'adopté au Sénat, inclut les régions, les départements, ainsi que les communes et leurs groupements de plus de 30 000 habitants. Le texte peut encore évoluer.

Ce que NIS2 change pour un fournisseur comme Lyneko : la directive n'impose pas de localisation ni de qualification de l'hébergement. Mais son article 21 oblige les entités régulées à gérer les risques de leur chaîne d'approvisionnement, y compris la sécurité des relations avec leurs fournisseurs directs. En pratique, une métropole régulée répercutera des exigences de sécurité dans ses contrats : mesures de sécurité documentées, notification rapide des incidents, droit d'audit. L'exigence arrive par le contrat, avant même la promulgation, parce que les acheteurs s'y préparent.

DORA, pour le secteur financier

Le règlement (UE) 2022/2554, dit DORA, sur la résilience opérationnelle numérique du secteur financier, est applicable depuis le 17 janvier 2025. Étant un règlement, il s'applique directement, sans transposition. Il s'adresse aux entités financières (banques, assurances, sociétés de gestion, prestataires de paiement), et leur impose notamment de gérer le risque lié aux prestataires tiers de services TIC : registre de tous les contrats, clauses contractuelles obligatoires, stratégies de sortie.

DORA instaure aussi une supervision européenne directe des prestataires tiers critiques. Les autorités européennes de surveillance ont publié le 18 novembre 2025 une première liste de dix-neuf prestataires désignés, parmi lesquels les grands fournisseurs de cloud. Signalements n'a pas de client financier ; mais si Lyneko vendait un jour à une mutuelle ou à une banque, ces exigences arriveraient par le contrat, comme celles de NIS2.

Les autres textes à connaître

• Le Data Act (règlement (UE) 2023/2854) organise le changement de fournisseur de cloud et la suppression progressive des frais de changement ; il est traité à la leçon 8 du cours cloud et reviendra à la leçon 5 de ce cours.
• Les opérateurs d'importance vitale (OIV), désignés en application du code de la défense, ont des règles propres pour leurs systèmes d'information d'importance vitale, fixées par arrêtés sectoriels non publics pour l'essentiel ; si un client vous dit être OIV, son responsable de la sécurité vous dira ce qui s'applique.
• Les marchés publics : l'acheteur public fixe ses exigences dans les documents de la consultation. Les clauses-types de la DAJ, une politique de sécurité interne, ou le recours à une centrale d'achat qui référence des offres qualifiées produisent des exigences contractuelles, aussi contraignantes pour le titulaire qu'une loi, mais qui se discutent avant la signature.

En pratique

Vous allez construire la matrice d'obligations des trois clients de Signalements, puis isoler les questions à soumettre à un juriste. C'est un travail d'analyse : prenez une feuille, ou un tableau partagé, et remplissez-le avant de lire la correction.

Étape 1 : décrire les données de Signalements

Pour chaque client, listez les données réellement traitées. Pour Signalements, l'inventaire de départ est le suivant :

La colonne Remarque compte autant que les autres : un champ de texte libre et des photos sont des portes d'entrée pour des données que l'application n'a pas été conçue pour traiter.

Étape 2 : remplir la matrice

Pour chaque client, appliquez la méthode : statut, données, textes. Voici la matrice attendue au 5 octobre 2026.

Étape 3 : l'analyse du groupement hospitalier

C'est la case la plus délicate, et elle mérite d'être déroulée. Signalements sert ici à signaler une fuite d'eau, une porte qui ferme mal, un ascenseur en panne. Ce ne sont pas des données de santé. Mais :

• un agent peut écrire dans la description : « fuite au-dessus du lit 12, la patiente sous oxygène a été déplacée » ; cette phrase révèle une information sur l'état de santé d'une personne identifiable par le contexte, ce qui en fait une donnée de santé au sens de l'article 4, point 15 du RGPD ;
• une photo d'une chambre peut montrer un patient, un dossier, un écran.

La question HDS se pose alors : ces données sont-elles « recueillies à l'occasion d'activités de prévention, de diagnostic, de soins » ? Le signalement d'une fuite n'est pas une activité de soins ; mais la donnée a bien été produite dans un établissement de soins, par du personnel soignant, à propos d'un patient. C'est exactement le genre de question qu'il faut soumettre au délégué à la protection des données et au juriste de l'établissement, plutôt que de la trancher seul.

En attendant leur réponse, la conception peut réduire le risque à la source, ce qui est la meilleure stratégie de conformité :

• un avertissement visible sur le formulaire (« ne mentionnez aucune information sur un patient ») ;
• une liste de catégories fermées plutôt qu'un texte libre là où c'est possible ;
• une consigne et un contrôle sur les photos (pas de personnes, pas d'écrans) ;
• une procédure de suppression des contenus non conformes signalés ;
• une durée de conservation courte.

Si, malgré cela, le client et son juriste concluent que des données de santé au sens de l'article L. 1111-8 seront hébergées, il faut un hébergeur certifié HDS pour le périmètre concerné, et vérifier ce périmètre sur la liste de l'Agence du numérique en santé.

Étape 4 : la liste des questions pour le juriste

Voici les questions que la matrice laisse ouvertes, formulées pour qu'un juriste puisse y répondre par oui ou par non, avec une justification :

1. Métropole : l'exigence « hébergement qualifié SecNumCloud » du cahier des charges vise-t-elle l'infrastructure ou le service Signalements lui-même (leçon 3) ? Repose-t-elle sur un texte, ou sur la politique de sécurité de la métropole ?
2. Métropole : la métropole sera-t-elle entité essentielle ou importante au sens de la loi de transposition de NIS2, une fois promulguée, et quelles clauses de sécurité entend-elle imposer à ses fournisseurs ?
3. Groupement hospitalier : des données de santé au sens de l'article 4, point 15 du RGPD sont-elles susceptibles d'être traitées, et, le cas échéant, leur hébergement relève-t-il de l'article L. 1111-8 du code de la santé publique ?
4. Groupement hospitalier : les établissements du groupement entrent-ils dans le champ de l'article 31 de la loi SREN ? (Notre lecture : non.)
5. Tous : la liste des sous-traitants ultérieurs de Lyneko (hébergeur, forge de code, intégration continue, messagerie transactionnelle) et leurs garanties en matière de transferts sont-elles acceptables pour le responsable de traitement ?

Remarquez ce qui n'est pas dans la liste : « Faut-il héberger en France ? » ou « La loi impose-t-elle SecNumCloud aux collectivités ? ». Ces questions ont une réponse dans les textes, que vous venez de lire.

Sous le capot

Pourquoi une obligation légale a mis deux ans à s'appliquer

L'article 31 de la loi SREN date de mai 2024 ; son décret d'avril 2026 ; l'arrêté qui approuve le référentiel d'août 2026. Ce délai n'est pas un accident. Une obligation qui renvoie à un décret ne s'applique pas tant que le décret n'est pas publié, et le décret lui-même renvoyait à un référentiel approuvé par arrêté. Chaque étape demande des consultations (en particulier, une règle technique qui touche le marché intérieur doit être notifiée à la Commission européenne avant adoption, ce qui ouvre une période d'attente). D'où une règle de lecture : une loi promulguée n'est pas forcément applicable. Vérifiez toujours si elle renvoie à un décret, et si ce décret existe.

Pourquoi une circulaire ne s'impose pas aux collectivités

Le Premier ministre dirige l'action du Gouvernement et des administrations de l'État ; il ne dirige pas les collectivités territoriales, qui s'administrent librement en vertu de la Constitution. Une circulaire adressée aux ministres et aux préfets organise le travail des services de l'État ; elle ne crée pas d'obligation pour une commune. Pour imposer une règle aux collectivités, il faut une loi, comme celle que propose l'extension de l'article 31.

Pourquoi NIS2 passe par le contrat

NIS2 régule des entités et non des produits ou des prestataires. Les fournisseurs ne sont touchés que s'ils sont eux-mêmes des entités régulées (un fournisseur de services cloud d'une certaine taille l'est, dans le secteur des infrastructures numériques), ou indirectement, parce que leurs clients doivent maîtriser leur chaîne d'approvisionnement. C'est le même mécanisme que DORA pour le secteur financier, et que l'article 28 du RGPD : l'obligation du client devient une clause du contrat du prestataire.

Pièges courants

« La loi impose SecNumCloud à toutes les administrations. » Non : l'article 31 de la loi SREN et son décret visent les administrations de l'État, certains opérateurs et six GIP, et seulement pour les données d'une sensibilité particulière. Les collectivités n'y sont pas soumises au 5 octobre 2026.

« C'est un hôpital, donc il faut un hébergeur HDS. » La certification HDS dépend des données et du contexte de leur recueil, pas de l'identité du client. Un hôpital qui héberge son site web vitrine n'a pas besoin d'un hébergeur HDS ; une start-up qui héberge des dossiers de patients pour un médecin, si.

« NIS2 s'applique depuis octobre 2024. » C'est la date limite de transposition, pas la date d'application en France. Au 5 octobre 2026, la loi n'est pas promulguée. Préparez-vous, mais ne présentez pas des obligations futures comme actuelles.

Confondre « données hébergées en France » et « données protégées ». Aucun des textes de cette leçon ne se satisfait de la seule localisation : HDS ajoute la transparence sur les accès étrangers, le décret SREN exige la protection contre l'accès d'autorités d'États tiers, SecNumCloud ajoute les critères de capital et d'autonomie. La leçon 2 explique pourquoi.

Oublier la date de l'analyse. Une matrice sans date devient fausse sans prévenir. Datez-la, citez la version de chaque texte, et prévoyez une révision.

Ne regarder que l'hébergeur. Les textes visent les données, où qu'elles passent : sauvegardes, journaux envoyés à un service de supervision, messagerie transactionnelle, outil de support qui reçoit des captures d'écran. La matrice doit couvrir tous les sous-traitants.

Sécurité

Les textes de cette leçon partagent une même logique : ils demandent des mesures de sécurité proportionnées au risque, et ils déplacent la responsabilité vers celui qui choisit le prestataire. Trois conséquences pour une équipe technique :

• La notification d'incidents est une obligation commune au RGPD (72 heures à l'autorité de contrôle pour une violation de données à risque), à NIS2 (alerte précoce sous 24 heures, une fois transposée) et à DORA. Elle suppose que le prestataire détecte et prévienne son client vite : les contrats de Lyneko doivent fixer ce délai, et l'équipe doit savoir le tenir (cours Incidents et astreintes).
• La minimisation est la meilleure protection : une donnée qui n'est pas collectée n'a besoin d'aucun hébergement de confiance. L'analyse du groupement hospitalier le montre.
• La conformité n'est pas la sécurité. Un hébergement qualifié et certifié ne protège pas une application vulnérable ni un compte d'administration hameçonné. Les textes exigent d'ailleurs explicitement des mesures techniques, pas seulement un label.

En production

• Une matrice par client, datée et versionnée. Chez Lyneko, elle vit dans le dépôt de documentation du projet, à côté de l'analyse de risques et du registre des sous-traitants, et elle est revue à chaque renouvellement de contrat et à chaque nouveau texte publié.
• Une veille réglementaire simple. Quelques sources primaires suffisent : le Journal officiel (textes cités), le site de l'ANSSI (référentiel et catalogue), MonEspaceNIS2 (transposition), l'Agence du numérique en santé (HDS), et le Journal officiel de l'Union européenne. Une alerte sur les mots « informatique en nuage », « SecNumCloud » et « NIS » couvre l'essentiel.
• Une architecture qui permet de segmenter. Pouvoir déployer une instance de Signalements sur un hébergement différent selon le client (mairie sur l'offre standard, métropole sur une offre qualifiée, groupement hospitalier sur un hébergeur certifié HDS si nécessaire) évite d'imposer le coût du plus exigeant à tous. Cela demande une infrastructure décrite en code et portable, que la leçon 5 détaille.
• Des clauses prêtes. Les clauses-types de la DAJ, une annexe de sécurité, un contrat de sous-traitance conforme à l'article 28 et une liste des sous-traitants ultérieurs tenue à jour se préparent une fois, et servent à chaque appel d'offres.

Exercices

1. Classer des exigences (niveau 300). Pour chacune des phrases suivantes, dites s'il s'agit d'une obligation légale, d'une instruction de l'État ou d'une exigence contractuelle, et pour qui. (a) « Les données d'une sensibilité particulière de l'État sont hébergées sur un service conforme au référentiel approuvé par arrêté. » (b) « Le titulaire héberge les données sur une offre qualifiée SecNumCloud », dans le cahier des charges d'une région. (c) « Le cloud est le mode d'hébergement par défaut des nouveaux projets de l'État. » (d) « L'hébergeur de données de santé est certifié. »

2. Un nouveau client (niveau 300). Une direction départementale, service déconcentré de l'État, veut utiliser Signalements pour les bâtiments administratifs de l'État dans le département, y compris une préfecture. Refaites la colonne de la matrice pour ce client.

3. Lire un calendrier (niveau 300). Un fournisseur vous affirme en octobre 2026 : « Depuis la loi SREN de 2024, toutes les collectivités de plus de 30 000 habitants doivent passer en SecNumCloud, et NIS2 l'impose aussi. » Corrigez cette phrase point par point.

4. Concevoir pour moins d'obligations (niveau 300). Proposez trois modifications de Signalements qui réduisent le risque que le groupement hospitalier traite des données de santé, et dites, pour chacune, ce qu'elle coûte à l'utilisateur.

Récapitulatif

• Distinguez obligation légale, instruction de l'État et exigence contractuelle, puis appliquez la méthode : statut du client, données traitées, texte applicable.
• Le RGPD est le socle : sous-traitance (art. 28), sécurité (art. 32), transferts (chapitre V), données de santé (art. 4 point 15 et art. 9).
• La doctrine « cloud au centre » (circulaires du 5 juillet 2021 et du 31 mai 2023) est une instruction aux administrations de l'État.
• L'article 31 de la loi SREN est devenu applicable avec le décret n° 2026-272 du 14 avril 2026 et l'arrêté du 12 août 2026 qui approuve SecNumCloud 3.2 : administrations de l'État, certains opérateurs et six GIP, données d'une sensibilité particulière, dérogations publiques limitées. Les collectivités n'y sont pas soumises au 5 octobre 2026.
• La certification HDS (art. L. 1111-8 du code de la santé publique) dépend des données et du contexte de soins ; son référentiel de 2024 impose l'hébergement dans l'EEE et la transparence sur les accès étrangers, pour tous les hébergeurs certifiés depuis le 16 mai 2026.
• NIS2 n'est pas encore transposée en France au 5 octobre 2026 ; elle visera, selon le projet, les collectivités de plus de 30 000 habitants, et touchera les fournisseurs par la chaîne d'approvisionnement.
• DORA, applicable depuis le 17 janvier 2025, encadre les prestataires TIC du secteur financier.
• Datez chaque analyse, et soumettez au juriste des questions précises.

Pour aller plus loin

• Le décret n° 2026-272 et l'arrêté du 12 août 2026 sur Légifrance : quelques pages, qui se lisent en un quart d'heure.
• La fiche technique de la DAJ sur l'article 31 et ses clauses-types, utile même pour un acheteur qui n'y est pas soumis.
• Le site MonEspaceNIS2 de l'ANSSI, pour suivre la transposition et préparer les entités concernées.
• Le cours Conformité : NIS2, ISO 27001, RGPD, SecNumCloud, qui traitera ces textes en profondeur, avec la mise en conformité d'une organisation.
• La leçon suivante, qui montre comment réduire la dépendance par la technique, quels que soient les textes applicables.