Choisir et justifier

Pourquoi

Les cinq premières leçons ont donné des pièces : ce que « souverain » recouvre, ce que permettent les lois extraterritoriales, ce que garantit SecNumCloud, ce qu'imposent les textes, ce que les techniques de chiffrement et de portabilité protègent réellement. Il reste à les assembler en une décision, et c'est là que les équipes trébuchent le plus souvent. On observe deux erreurs symétriques :

• La décision par principe. « Nous sommes une collectivité, donc il nous faut du SecNumCloud » ; ou, à l'inverse, « nous n'avons rien à cacher, prenons le moins cher ». Dans les deux cas, personne n'a regardé quelles données sont en jeu, quel texte s'applique, ni quel risque on veut réellement couvrir. Le premier choix peut coûter cher sans bénéfice ; le second peut être illégal.
• La décision non écrite. Le choix est fait en réunion, au vu d'une démonstration commerciale. Trois ans plus tard, le fournisseur est racheté, un nouveau décret paraît, ou un auditeur demande « pourquoi cet hébergeur ? », et personne ne sait plus sur quels arguments la décision reposait, ni s'ils tiennent encore.

Une bonne décision d'hébergement est proportionnée (elle couvre les risques réels, pas tous les risques imaginables), traçable (on peut la relire et comprendre ses raisons), et révisable (elle dit à quelles conditions elle devra être réexaminée). Cette leçon donne une méthode en six étapes, puis l'applique aux trois clients qui veulent utiliser Signalements : une commune, une métropole et un groupement hospitalier de territoire.

Les concepts

Vue d'ensemble de la méthode

    flowchart LR
  A["1. Classer<br/>les données"] --> B["2. Identifier<br/>les obligations"]
  B --> C["3. Analyser<br/>les menaces"]
  C --> D["4. Traduire en<br/>exigences"]
  D --> E["5. Comparer<br/>les offres"]
  E --> F["6. Décider<br/>et documenter"]
  F -.->|"événement<br/>déclencheur"| A
  

Chaque étape produit un livrable court, réutilisé par la suivante. L'ensemble tient en quelques pages pour une application comme Signalements ; il en faudra davantage pour un système d'information hospitalier, mais la structure ne change pas.

Étape 1 : classer les données

La classification des données consiste à ranger chaque catégorie de données selon deux axes indépendants :

• la sensibilité, c'est-à-dire l'impact d'une perte de confidentialité, d'intégrité ou de disponibilité, pour les personnes concernées et pour l'organisation ;
• le régime juridique : données personnelles (RGPD), catégories particulières (santé, au sens de l'article 9 du RGPD), données de santé au sens du code de la santé publique (qui déclenchent l'obligation d'hébergeur certifié), données couvertes par un secret légal, informations classifiées (qui sortent du cloud commercial et de ce cours).

On classe des catégories (les signalements, les photos, les comptes des agents, les journaux techniques), pas l'application en bloc : une même application mélange souvent des données banales et quelques champs sensibles, et c'est sur ces champs que porteront les mesures.

Une échelle simple suffit : publique, interne, sensible, très sensible. Ce qui compte, c'est de justifier chaque rang en une phrase, et de faire valider le tableau par le responsable du traitement.

Étape 2 : identifier les obligations

Pour chaque catégorie, on liste les textes qui s'appliquent à ce client, et ce qu'ils exigent de l'hébergement. La leçon 4 les détaille ; la question à se poser est toujours la même : qui est le responsable du traitement, et dans quel champ entre-t-il ? Quelques exemples de ce qui change selon le client :

• Le RGPD s'applique dès qu'il y a des données personnelles. Il impose un contrat de sous-traitance (article 28) avec chaque sous-traitant, des mesures de sécurité « appropriées » au risque (article 32), et, pour certains traitements, une analyse d'impact (article 35). Il n'impose pas, à lui seul, une localisation en France ni une qualification.
• L'article 31 de la loi SREN et son décret d'application n° 2026-272 du 14 avril 2026 (en vigueur depuis le 17 avril 2026) imposent, pour les données d'une sensibilité particulière, une offre qualifiée et protégée contre les accès d'États tiers. Ils visent les administrations de l'État, certains de ses opérateurs et six groupements d'intérêt public nommément listés par le décret (dont l'Agence du numérique en santé). Une commune, une métropole ou un hôpital ne sont pas, à ce titre, dans cette liste.
• L'hébergement de données de santé au sens de l'article L. 1111-8 du code de la santé publique impose un hébergeur certifié HDS, dont le référentiel de 2024 exige un hébergement physique dans l'Espace économique européen.
• Les obligations issues de la directive NIS2 dépendent de la qualification de l'entité dans la loi de transposition : la leçon 4 en donne l'état.

Étape 3 : analyser les menaces, à la bonne échelle

L'ANSSI publie une méthode d'analyse de risques, EBIOS Risk Manager (version 1.5 du guide, 2024), organisée en cinq ateliers : cadrage et socle de sécurité, sources de risque, scénarios stratégiques, scénarios opérationnels, traitement du risque. Une étude complète mobilise plusieurs personnes pendant des semaines ; elle est justifiée pour un système critique. Pour choisir l'hébergement d'une application comme Signalements, on en retient la logique, à une échelle proportionnée :

1. Les valeurs métier : ce que l'application doit protéger (la confiance des habitants, la continuité du service de voirie, la confidentialité des données des signalants).
2. Les sources de risque et leurs objectifs visés : qui pourrait porter atteinte à ces valeurs, et pour obtenir quoi. Un cybercriminel qui cherche une rançon ; un individu qui veut harceler un signalant ; une autorité étrangère qui voudrait des données ; le fournisseur lui-même qui cesse son activité ou change ses conditions.
3. Les scénarios stratégiques : par quel chemin, dans l'écosystème (fournisseur, sous-traitants, prestataires, outils de l'équipe), chaque source peut atteindre son objectif.
4. La vraisemblance et la gravité de chaque scénario, estimées honnêtement, sur une échelle courte.

La discipline essentielle est de pondérer. Le scénario « une autorité étrangère obtient les photos de nids-de-poule d'une commune de 8 000 habitants » est possible juridiquement si l'hébergeur y est soumis ; il est très peu vraisemblable, et sa gravité est faible. Le scénario « un compte d'administration est compromis par hameçonnage et les données sont chiffrées par un rançongiciel » est bien plus vraisemblable, et l'hébergement souverain n'y change rien. Une analyse honnête découvre presque toujours que les risques les plus probables se traitent par l'hygiène (identités, sauvegardes, mises à jour), et que la souveraineté de l'hébergeur répond à un risque précis, à ne pas surestimer ni ignorer.

Étape 4 : traduire en exigences

Chaque scénario retenu produit des exigences vérifiables, rangées par famille :

Puis on sépare deux sortes de critères. Les critères éliminatoires viennent d'une obligation (un texte, une clause de contrat, une décision de la direction) : une offre qui ne les remplit pas est écartée, quelle que soit sa note par ailleurs. Les critères pondérés viennent de l'analyse de risques et des préférences : ils départagent les offres restantes. Mettre une préférence parmi les éliminatoires est l'erreur la plus fréquente, et la plus coûteuse : elle élimine des offres sans raison opposable.

Étape 5 : comparer avec une matrice

Une matrice de décision pondérée liste les options en colonnes et les critères pondérés en lignes, avec un poids par critère et une note par option. Trois règles la rendent honnête :

• Les poids sont fixés avant de noter les offres, à partir de l'analyse de risques, et pas ajustés ensuite pour faire gagner une option.
• Les notes s'appuient sur des preuves : un certificat, une page de documentation datée, une clause de contrat. Une affirmation commerciale non écrite vaut zéro.
• Le coût et le catalogue figurent dans la matrice. Une offre qualifiée propose souvent moins de services managés qu'une offre standard : il faut alors exploiter soi-même ce que le fournisseur ne gère pas (une base, un registre, un cluster), ce qui coûte en personnes et en compétences. Ce coût-là pèse autant que la facture.

Une matrice ne décide pas à votre place. Elle rend visible ce sur quoi repose le choix, et elle permet à un tiers de le contester sur des faits.

Étape 6 : décider, documenter, réexaminer

La décision s'écrit dans une note de décision au format ADR (Architecture Decision Record), proposé par Michael Nygard en 2011 : un document court qui donne le contexte (les forces en présence), la décision, son statut (proposée, acceptée, remplacée), et ses conséquences, toutes, pas seulement les positives. Pour une décision d'hébergement, on ajoute deux rubriques :

• les options écartées et pourquoi, pour que personne ne rouvre le débat sans élément nouveau ;
• les événements de réexamen : ce qui, s'il arrive, oblige à reprendre la décision. Une qualification obtenue ou retirée, un rachat du fournisseur, un nouveau texte ou un nouvel arrêt (par exemple sur le cadre de transfert de données vers les États-Unis), un changement de la nature des données, un incident.

Une note de décision se date, se signe (au moins par le responsable technique et le responsable du traitement), et se range avec le code ou la documentation du projet. Le cours Décisions d'architecture : ADR et RFC approfondit le format.

En pratique

Les trois cas suivants sont traités de bout en bout. Les données et les volumes sont ceux de l'exemple ; les faits sur les fournisseurs sont datés au 5 octobre 2026 et vérifiés sur leurs pages. Les noms de fournisseurs autres que Scaleway, que Lyneko utilise déjà, sont remplacés par des lettres : une note de décision réelle les nommerait, avec les preuves.

Les données de Signalements

Pour la commune et la métropole, ce tableau ne change pas. Pour le groupement hospitalier, une question nouvelle apparaît, traitée plus bas.

Cas 1 : la commune

Obligations. La commune est responsable du traitement ; Lyneko est son sous-traitant, et Scaleway un sous-traitant ultérieur. Le RGPD s'applique : contrat de sous-traitance, registre, information des habitants, durée de conservation, sécurité appropriée. Aucun texte n'impose à une commune une offre qualifiée pour ce traitement : elle n'entre pas dans le champ de l'article 31 de la loi SREN, et les données ne sont pas des données de santé.

Menaces retenues. Par ordre de vraisemblance : compromission d'un compte d'agent ou d'administrateur (hameçonnage), fuite de coordonnées ou de photos par une erreur de configuration (bucket public), indisponibilité du service pendant quelques heures, arrêt ou changement de conditions du fournisseur. L'accès par une autorité étrangère est jugé très peu vraisemblable et de gravité faible pour ces données, à condition que l'hébergeur soit soumis au seul droit européen.

Exigences. Éliminatoires : hébergement dans l'Union européenne ; contrat de sous-traitance conforme à l'article 28. Pondérées : hébergeur soumis au seul droit européen ; sauvegardes testées ; réversibilité documentée ; coût.

Décision. L'offre standard de Scaleway, en région fr-par, avec les mesures d'hygiène des cours précédents (identités limitées, bucket privé, sauvegardes de la base, plan de sortie de la leçon 5). Pas de chiffrement côté client des photos : le gain ne justifie pas la complexité pour cette commune. La note :

ADR-012 : Hébergement de Signalements pour la commune de B.
Statut : acceptée le 5 octobre 2026
Signataires : responsable technique Lyneko ; DPO de la commune

Contexte
- Données : signalements (interne), coordonnées et photos des habitants (sensible).
- Obligations : RGPD. Pas d'obligation de qualification (hors champ de l'article 31
  de la loi SREN, pas de données de santé), confirmé par le DPO le 2 octobre 2026.
- Menaces principales : compromission de comptes, erreur de configuration,
  indisponibilité, dépendance au fournisseur.

Décision
- Scaleway, offre standard, région fr-par, projet dédié à la commune.
- Mesures : MFA pour tous les comptes, bucket privé et URL présignées,
  sauvegardes quotidiennes de la base conservées 30 jours et restauration testée
  chaque trimestre, plan de sortie annexé (leçon 5), conservation des photos 12 mois.

Options écartées
- Offre qualifiée SecNumCloud : aucune obligation, coût et catalogue
  disproportionnés pour le risque identifié.
- Hébergeur soumis à une loi extraterritoriale : critère pondéré défavorable
  sans bénéfice compensatoire.

Conséquences
- (+) Coût et exploitation inchangés ; mêmes outils que les autres clients.
- (-) Les photos sont lisibles techniquement par l'hébergeur ; risque accepté
  par la commune au vu de sa faible gravité.
- (=) La commune doit mentionner Scaleway comme sous-traitant ultérieur
  dans son information aux habitants.

Réexamen
- Changement de catégorie de données (ajout de données de santé, d'état civil).
- Rachat de l'hébergeur par un groupe soumis à une loi extraterritoriale.
- Au plus tard le 5 octobre 2028.

Cas 2 : la métropole

Obligations. Mêmes bases que la commune, avec deux différences. La métropole a une politique de sécurité qui exige, pour les données personnelles des usagers, un hébergement « dans l'Union européenne, par un prestataire non soumis à une législation extra-européenne permettant l'accès aux données » : c'est une obligation contractuelle, donc un critère éliminatoire, même si aucune loi ne l'impose. Et son statut au regard de la transposition de NIS2 doit être vérifié avec son responsable de la sécurité (leçon 4), parce qu'il conditionne des obligations de gestion des risques et de notification d'incident qui s'étendent à ses fournisseurs.

Menaces retenues. Celles de la commune, plus une exposition médiatique plus forte (fuite de données de dizaines de milliers d'usagers), et la question explicite de la métropole sur l'accès des prestataires aux photos (leçon 5).

Exigences. Éliminatoires : hébergement et sauvegardes dans l'Union ; prestataire et maison mère non soumis à une loi extra-européenne d'accès aux données ; contrat de sous-traitance ; plan de sortie fourni. Pondérées : qualification SecNumCloud ; chiffrement côté client des photos ; support en français avec astreinte ; catalogue de services managés ; coût.

Options. A : Scaleway, offre standard. B : le fournisseur Q, avec une offre qualifiée SecNumCloud. C : un grand fournisseur américain, région de Paris.

L'option C est éliminée avant toute notation : sa maison mère est soumise au Cloud Act (leçon 2). Pour les deux options restantes, la matrice, avec des poids fixés avant la notation :

Le total se calcule en multipliant chaque note (de 0 à 5) par le poids, puis en additionnant : pour A, 20 × 1 + 15 × 5 + 20 × 5 + 10 × 4 + 25 × 4 + 10 × 4 = 410. Le résultat dépend des poids : si la métropole donnait 50 au critère de qualification, B l'emporterait. C'est exactement ce que la matrice doit rendre visible, et ce que la métropole doit trancher en connaissance de cause.

Décision. Option A, avec chiffrement côté client des photos et des coordonnées des signalants, et un réexamen déclenché par l'obtention de la qualification par Scaleway ou par une évolution de la politique de la métropole. La note, plus courte que la précédente pour les parties communes :

ADR-015 : Hébergement de Signalements pour la métropole de M.
Statut : proposée le 5 octobre 2026, en attente de validation du RSSI de la métropole

Contexte
- Données : identiques à ADR-012, volumétrie x 40.
- Obligation contractuelle (PSSI de la métropole, § 4.2) : prestataire non soumis
  à une législation extra-européenne d'accès aux données.
- Statut NIS2 de la métropole : à confirmer par son RSSI (question posée le 3 octobre).

Décision
- Scaleway, offre standard, fr-par, projet dédié.
- Photos et coordonnées chiffrées côté client (enveloppe Key Manager, une DEK par objet).
- Accès d'administration par un fournisseur d'identité européen ; plus de SSO Google
  pour ce projet.
- Plan de sortie annexé, testé avant la mise en service puis chaque année.

Options écartées
- C (fournisseur soumis au Cloud Act) : critère éliminatoire.
- B (offre qualifiée de Q) : 320/500 contre 410/500, principalement à cause
  du catalogue réduit et du coût d'exploitation ; la qualification est le seul
  critère où B l'emporte nettement.

Conséquences
- (+) Les photos et coordonnées sont illisibles pour l'hébergeur au repos.
- (-) La base de données reste lisible en clair par le service managé (cas
  d'usage 6 de l'EDPB) ; risque couvert par la juridiction européenne du prestataire,
  pas par la qualification.
- (-) Développement du chiffrement côté client : 8 jours estimés.

Réexamen
- Obtention ou non de la qualification SecNumCloud par Scaleway (point au 1er avril 2027).
- Toute évolution de la PSSI de la métropole ou de son statut NIS2.
- Rachat de l'hébergeur ; nouvelle décision sur le cadre de transfert UE/États-Unis.

Cas 3 : le groupement hospitalier de territoire

Un groupement hospitalier de territoire (GHT) veut utiliser Signalements pour les incidents de ses bâtiments : fuite, ascenseur en panne, éclairage d'un parking. Premier réflexe dans l'équipe : « c'est un hôpital, il faut du HDS et du SecNumCloud ». Appliquons la méthode.

Qui est le responsable du traitement ? Le GHT n'a pas la personnalité morale (article L. 6132-1 du code de la santé publique) : c'est l'établissement support, ou chaque établissement, qui contracte et qui est responsable du traitement. La question est à poser au DPO de l'établissement support, et elle détermine qui signe.

Les données changent-elles ? Les incidents de bâtiment ne sont pas, par nature, des données de santé : ils ne sont pas recueillis à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social, qui définissent le champ de l'article L. 1111-8. Mais deux risques font basculer certaines données :

• une photo prise dans un service de soins peut montrer un patient, un écran, un dossier ;
• un champ « description » peut recevoir « fuite dans la chambre de M. X, en soins palliatifs ».

Deux options de conception. Soit on empêche que des données de santé entrent dans l'application (consignes affichées dans le formulaire, interdiction des photos dans les zones de soins définies par l'établissement, modération et suppression des contenus non conformes, champ libre limité), et l'on reste hors du champ HDS, ce que le DPO doit valider par écrit. Soit on accepte qu'elles y entrent, et l'hébergement doit être certifié HDS pour les services utilisés : Scaleway se présente comme certifié HDS (page consultée le 5 octobre 2026) ; la note devrait alors citer le certificat et son périmètre exact, à vérifier service par service.

Obligations, suite. Le décret n° 2026-272 ne vise pas les établissements de santé (étape 2). Le statut des établissements au regard de NIS2 doit, lui, être examiné avec leur responsable de la sécurité : le secteur de la santé figure parmi les secteurs couverts par la directive (leçon 4).

Décision proposée. Première option (empêcher l'entrée de données de santé), hébergement Scaleway standard, chiffrement côté client des photos comme pour la métropole, avec une analyse d'impact (AIPD) si le DPO l'estime nécessaire au vu des critères de la CNIL. Le réexamen est déclenché dès qu'un établissement demande à lier un incident à un patient ou à un dossier : ce jour-là, les données deviennent des données de santé, et la décision change de nature.

Le point à retenir de ce cas : la bonne réponse n'était ni « il faut du SecNumCloud » ni « ce n'est que de la maintenance ». C'est une décision de conception (ne pas collecter ce qu'on ne veut pas héberger), prise avant la décision d'hébergement.

Sous le capot

Pourquoi séparer éliminatoire et pondéré. Une matrice où tous les critères sont pondérés permet à une offre d'« acheter » un critère obligatoire avec des points ailleurs : un fournisseur très bon marché mais soumis à une loi extraterritoriale pourrait gagner contre la politique de la métropole. Les critères éliminatoires garantissent que la matrice ne compare que des options admissibles. C'est le principe de l'analyse multicritère avec seuils, utilisé aussi dans les marchés publics, où un critère de sélection écarte une candidature avant que les critères d'attribution ne départagent les offres.

Pourquoi la vraisemblance compte autant que la gravité. Une analyse qui ne retient que la gravité (« une fuite de photos serait grave, donc il faut la protection maximale ») conduit à tout traiter au niveau le plus coûteux, et à négliger ce qui arrive vraiment. EBIOS Risk Manager place les scénarios sur une cartographie gravité et vraisemblance ; les mesures se concentrent d'abord sur ce qui est à la fois vraisemblable et grave.

Pourquoi dater chaque fait. Les faits qui fondent une décision d'hébergement ont une durée de vie courte : une qualification s'obtient ou se perd, un cadre de transfert est annulé par un arrêt (la leçon 2 en a raconté deux), un décret paraît avec deux ans de retard. Une note qui écrit « Scaleway est qualifié SecNumCloud » sans date est fausse au 5 octobre 2026 ; une note qui écrit « en cours de qualification, non obtenue au 5 octobre 2026, d'après sa page de conformité » reste vraie, et dit quand la vérifier à nouveau.

Pièges courants

Souverain par principe, ou indifférent par principe. Les deux évitent l'analyse. Le premier paie une complexité sans bénéfice ; le second découvre l'obligation quand un auditeur la lui rappelle.

Confondre certification et qualification. Une certification ISO/IEC 27001 atteste qu'un système de management de la sécurité existe et fonctionne, sur un périmètre choisi par l'organisation, audité par un organisme accrédité. La qualification SecNumCloud est délivrée par l'ANSSI, contre un référentiel qui comprend des exigences de protection contre le droit extra-européen (leçon 3). Une offre « certifiée ISO 27001 et HDS » n'est pas qualifiée.

Exiger SecNumCloud sans texte qui l'impose. C'est un choix légitime s'il découle de l'analyse de risques ou d'une politique écrite ; c'est une erreur s'il découle d'un réflexe, parce qu'il élimine des offres sans raison opposable et peut multiplier les coûts d'exploitation.

Croire qu'un engagement commercial vaut une qualification. « Nous sommes en cours de qualification » ou « notre offre répond aux exigences de SecNumCloud » ne sont pas une qualification. Seule la liste publiée par l'ANSSI fait foi.

Oublier les sous-traitants. La décision porte sur l'hébergeur, mais l'application parle aussi à un fournisseur d'identité, un service d'envoi de courriels, une supervision en SaaS, un support qui se connecte à distance. Chacun est un sous-traitant ultérieur au sens du RGPD, et un chemin d'accès possible (leçon 5).

Une matrice ajustée après coup. Si les poids changent après la notation, la matrice ne fait plus que justifier une préférence. Fixez et datez les poids avant de noter.

Une décision sans réexamen. Sans événement déclencheur ni date, la note vieillit en silence, et ses faits deviennent faux.

Sécurité

La méthode est elle-même un outil de sécurité, à condition de ne pas oublier trois choses :

• L'hébergement n'est qu'une couche. Dans les trois cas, les menaces les plus vraisemblables (comptes compromis, erreurs de configuration, rançongiciel) se traitent par les identités, la configuration et les sauvegardes, quel que soit l'hébergeur. Une décision d'hébergement souverain ne dispense d'aucune de ces mesures.
• La documentation de décision est une information sensible. L'analyse de risques et la note décrivent les faiblesses acceptées et les chemins d'attaque envisagés. Rangez-les avec des droits limités, pas dans un wiki public.
• Les preuves doivent être vérifiables. Pour chaque critère noté, gardez la preuve (attestation, capture datée de la page, clause) : en cas d'incident, c'est ce qui montre que le choix était raisonnable au moment où il a été fait.

En production

• Un modèle de note par organisation. Lyneko garde un gabarit d'ADR d'hébergement, avec les rubriques de cette leçon et la liste des événements de réexamen communs à tous les clients ; chaque nouveau client ne remplit que ce qui change.
• Un registre des faits datés. Statut de qualification des fournisseurs utilisés, certificats et leurs dates d'expiration, textes applicables : un seul tableau, revu chaque trimestre, que toutes les notes citent. Quand un fait change, on sait immédiatement quelles décisions réexaminer.
• Les réexamens se planifient. Une date de réexamen sans rappel n'existe pas : mettez-la dans le même outil que les renouvellements de certificats.
• La décision suit l'application. Un nouveau champ, une nouvelle intégration, un nouveau sous-traitant peuvent changer la classification. Faites de la question « cela change-t-il la note d'hébergement ? » un point de la revue des évolutions.
• Le coût d'un changement d'avis. Une décision bien documentée avec un plan de sortie testé rend un changement d'hébergeur possible en quelques semaines, si un événement de réexamen l'exige. C'est la meilleure assurance contre l'incertitude réglementaire : non pas deviner l'avenir, mais pouvoir s'y adapter.

Exercices

1. Classer (niveau 300). Une application de prise de rendez-vous pour une maison France Services collecte : nom, téléphone, motif du rendez-vous (texte libre), date, agent affecté. Classez chaque catégorie, indiquez les textes susceptibles de s'appliquer et la question à poser au DPO.

2. Construire une matrice (niveau 300). Reprenez la matrice de la métropole. La métropole décide que la qualification SecNumCloud pèse 40, et réduit le coût à 5 (les autres poids sont inchangés : chiffrement 15, catalogue 20, support 10, réversibilité 10). Recalculez les totaux. Quelle option l'emporte ? Que doit contenir la nouvelle note ?

3. Écrire une note (niveau 300). Rédigez l'ADR du cas 3 (GHT) au format des deux exemples, en dix à vingt lignes, avec au moins deux conséquences négatives et trois événements de réexamen.

ADR-018 : Hébergement de Signalements pour le GHT de T.
Statut : proposée le 5 octobre 2026, en attente de validation du DPO
de l'établissement support

Contexte
- Incidents de bâtiments ; risque d'entrée de données de santé par les photos
  et le texte libre.
- Responsable du traitement : établissement support (le GHT n'a pas la
  personnalité morale).
- Hors champ du décret 2026-272 ; statut NIS2 à confirmer par le RSSI.

Décision
- Empêcher l'entrée de données de santé : consignes, photos interdites en zones
  de soins, modération sous 48 h, champ libre limité à 280 caractères.
- Scaleway standard, fr-par ; photos chiffrées côté client.

Conséquences
- (-) La modération demande du temps d'agent côté établissement.
- (-) Le risque résiduel (photo non conforme non détectée) est accepté par écrit.
- (+) Pas de dépendance à un périmètre HDS pour une application de maintenance.

Réexamen
- Demande de lier un incident à un patient ou à un dossier.
- Incident de données de santé constaté dans l'application.
- Évolution du statut NIS2 des établissements ; au plus tard le 5 octobre 2027.

4. Repérer les faits périssables (niveau 300). Relisez la note ADR-015 de la métropole et soulignez chaque affirmation qui pourrait devenir fausse sans que Lyneko ne fasse rien. Pour chacune, indiquez où et à quelle fréquence la vérifier.

Récapitulatif

• Une décision d'hébergement doit être proportionnée, traçable et révisable.
• Classer les données par catégorie, sur deux axes : sensibilité et régime juridique.
• Identifier les obligations du client précis : qui est responsable du traitement, et dans quel champ entre-t-il. Lire les textes, pas les résumés.
• Analyser les menaces à la bonne échelle, avec la logique d'EBIOS Risk Manager : sources de risque, objectifs, scénarios, vraisemblance et gravité. Les menaces les plus probables se traitent souvent par l'hygiène, pas par l'hébergeur.
• Traduire en exigences vérifiables, en séparant éliminatoires (obligations) et pondérés (préférences).
• Comparer avec une matrice aux poids fixés avant la notation, aux notes prouvées, qui intègre coût et catalogue.
• Documenter dans une note ADR datée, avec options écartées, conséquences et événements de réexamen.
• Parfois, la meilleure décision d'hébergement est une décision de conception : ne pas collecter ce qu'on ne veut pas héberger.

Pour aller plus loin

• Le guide EBIOS Risk Manager de l'ANSSI et ses fiches méthodes, pour mener une analyse complète quand le système le justifie.
• L'article de Michael Nygard, Documenting Architecture Decisions, qui tient en une page, et le cours Décisions d'architecture : ADR et RFC.
• La page de la CNIL sur l'analyse d'impact relative à la protection des données, avec la liste des traitements pour lesquels elle est obligatoire.
• Le cours Modélisation des menaces, pour les scénarios opérationnels qu'une décision d'hébergement ne couvre pas.
• Le cours Conformité : NIS2, ISO 27001, RGPD, SecNumCloud, pour les obligations elles-mêmes.
• Le quiz et le projet de fin de cours, qui vous demande de produire le dossier complet et la note de décision d'un centre hospitalier.