Hébergement et données

De quoi traite ce domaine#

Le quatrième domaine demande au déclarant de préciser la localisation effective des serveurs et des données, la juridiction sous laquelle ces serveurs sont opérés, la trajectoire des données client (transitent-elles ou sont-elles stockées hors de l’Union européenne, dans quels cas, pour quelles finalités), les garanties contractuelles sur cette localisation, et la procédure d’information du client en cas de réquisition extra-européenne.

Le domaine ne se contente pas de la localisation physique des datacenters. Il interroge la juridiction effective : un datacenter situé en France mais opéré par une filiale d’un groupe américain reste soumis au CLOUD Act américain, ce qui a été confirmé par la Cour suprême américaine et les analyses publiques de l’ANSSI. La localisation physique est nécessaire mais pas suffisante. La juridiction du donneur d’ordre opérationnel et la chaîne capitalistique qui le contrôle sont déterminantes.

Pourquoi ce domaine compte#

La thèse 7 du manifeste fonde l’exigence : « distribuer du logiciel libre par des registres et des réseaux soumis à une juridiction étrangère, c’est offrir à cette juridiction un droit de regard et de coupure sur ce que nous croyons posséder. » Les données client, qui constituent souvent le bien le plus précieux qu’une organisation confie à un fournisseur, méritent une analyse particulièrement précise de cette dimension juridictionnelle.

Le contexte réglementaire français du « Cloud au centre », les exigences de la directive NIS 2, et la qualification SecNumCloud délivrée par l’ANSSI pour les charges sensibles convergent vers une attente claire : pour les données sensibles (santé, défense, données personnelles à enjeu), la juridiction américaine via le CLOUD Act est un risque structurel qui doit être déclaré et idéalement écarté. Au printemps 2026, neuf prestataires sont qualifiés SecNumCloud 3.2 (Outscale, OVHcloud, Cloud Temple, Worldline, Orange Business, Cegedim, Oodrive, Tenexa, et S3NS depuis le 17 décembre 2025), ce qui constitue une offre crédible pour les charges les plus sensibles — même si l’étendue fonctionnelle reste inférieure à celle des hyperscalers américains, lacune que le manifeste documente dans son inventaire.

À l’échelle agrégée, la publication des informations d’hébergement par les fournisseurs européens fait apparaître la concentration réelle de l’écosystème : combien d’éditeurs européens hébergent finalement chez AWS, Azure ou GCP malgré une présentation « française » ? Cette transparence est un point de levier pour faire évoluer les choix par défaut.

Ce qui est demandé par catégorie de déclarant#

Pour un éditeur SaaS, ou pour les recommandations d’hébergement d’une solution on-premise. Localisation des serveurs (pays, hébergeur, juridiction effective), trajectoire des données client (stockage, traitement, sauvegardes — y compris transferts éventuels hors UE et leur finalité), garanties contractuelles sur la localisation, procédure d’information du client en cas de réquisition extra-européenne, options proposées au client pour l’hébergement (hyperscaler, hébergeur européen, hébergement chez le client en on-premise).

Pour un hébergeur ou fournisseur cloud. Localisation précise des datacenters (ville et pays), hiérarchie capitalistique des sociétés exploitantes, certifications applicables (HDS, SecNumCloud, ISO 27001, ISO 27017, ISO 27018), résistance aux lois extraterritoriales avec analyse argumentée, engagement contractuel sur le pays d’exécution effective des données client, procédure publique en cas de réquisition extra-européenne.

Pour un distributeur ou intégrateur. Où sont effectivement hébergées les solutions distribuées ? Le distributeur peut-il garantir une localisation européenne par contrat propre, ou seulement transmettre les conditions de l’éditeur d’origine ? En cas de service managé revendu sous marque blanche, qui contrôle effectivement les serveurs, et la chaîne de contrôle est-elle communicable au client final ?

Exemple de réponse honnête bien faite#

Un éditeur SaaS français de 22 personnes déclare son domaine 4 ainsi. Hébergement de production sur OVHcloud Public Cloud, datacenter de Gravelines (France). Sauvegardes chiffrées hébergées chez Scaleway, datacenter de Paris. Pour les clients à exigence renforcée (offre premium), option de déploiement sur Outscale qualifié SecNumCloud 3.2 (datacenter en région parisienne) à un tarif majoré. Aucune donnée client ne transite ou n’est stockée hors UE dans le déploiement standard ; pour le service de mailing transactionnel actuellement opéré par un prestataire américain (déclaré comme angle mort dans le domaine 7), les emails sortants transitent par les serveurs SMTP américains du prestataire, ce qui est en cours de migration vers Mailjet (France) à horizon 2026. Les contrats clients incluent une clause d’information sous 5 jours ouvrés en cas de réquisition étrangère, dans la mesure où la loi le permet. Aucune réquisition extra-européenne n’a été reçue à ce jour.

Anti-pattern à éviter#

Un domaine 4 qui se contente de mentionner « hébergement en Europe conforme RGPD » sans préciser la juridiction effective de l’opérateur cloud passe à côté de l’enjeu CLOUD Act. La conformité RGPD ne dit rien sur la résistance aux lois extraterritoriales. Une mention triomphante du type « nos données sont en sécurité dans nos datacenters » sans préciser quels datacenters et qui les opère ne constitue pas une déclaration utilisable. À l’inverse, une déclaration alarmiste qui exagère les risques perd en crédibilité. Le ton à viser : précis, factuel, traçable.

Articulation avec les autres domaines et engagements#

Le domaine 4 s’articule directement avec l’engagement fournisseur pub-008-european-host-default : un fournisseur qui a pris cet engagement dispose d’arguments concrets pour son domaine 4. Il s’articule également avec le domaine 6 (gouvernance et capital) : la juridiction d’un hébergeur dépend largement de sa structure capitalistique. Le client qui lit le domaine 4 d’un fournisseur peut prolonger son analyse par la lecture du domaine 4 de l’hébergeur cité, dans une logique de chaîne complète conforme à la thèse 6 du manifeste.

Comment remplir le formulaire#

Le domaine 4 est le plus dense du Profil. Il distingue deux situations radicalement différentes : consommer de l’hébergement (le cas d’un éditeur SaaS, d’un intégrateur, d’un MSP) et produire de l’hébergement (le cas d’OVH, Scaleway, AWS…). Le formulaire est découpé en 4 étapes présentées en stepper horizontal, et s’adapte automatiquement à la ou les catégories cochées à l’étape Profil :

• Éditeur : étapes 01 (hébergement consommé), 02 (briques consommées), 04 (variantes & cadre).
• Hébergeur ou cloud : étapes 01 (mon infrastructure), 04 (variantes & cadre).
• Prestataire d’infogérance / MSP : les 4 étapes (01 hébergement consommé + 02 briques + 03 outils MSP + 04 variantes & cadre).
• Distributeur ou intégrateur : étapes 01, 02, 04 (comme l’éditeur, plus l’hébergement des solutions distribuées dans 04).
• Si plusieurs catégories sont cochées (par ex. éditeur et hébergeur), tous les blocs pertinents apparaissent dans les étapes correspondantes.

Étape 01 — Hébergement#

Cette étape rassemble tout ce qui relève des serveurs et de la trajectoire des données : si vous êtes vous-même hébergeur, votre propre infrastructure ; si vous consommez de l’hébergement, la liste des fournisseurs ; et dans tous les cas, le récit cross-provider des données et la procédure de réquisition.

Mon infrastructure (réservé aux hébergeurs et clouds)#

Pour les fournisseurs qui exploitent eux-mêmes l’infrastructure — vous êtes l’hébergeur, pas un consommateur. Le détail capitalistique complet va au domaine 6 ; ici on documente ce qui touche directement aux datacenters et aux engagements contractuels client.

• Datacenters opérés : pour chaque site, Localisation (ville, pays), Juridiction, Mode d’occupation (En propre / Loué / Colocation), Commentaire (qualification SecNumCloud du site, redondance, etc.).
• Garantie contractuelle du pays d’exécution : engagement contractuel pris envers le client sur le pays d’exécution effective de ses données. Exemple : « contrat-cadre garantissant que les données ne sortent pas de France ». Distinct du discours marketing.
• Résumé de la chaîne capitalistique : une à deux phrases sur qui contrôle l’entité in fine. Le détail ligne par ligne va au domaine 6.

Hébergeurs et fournisseurs cloud#

Listez tous les hébergeurs et fournisseurs cloud que vous consommez. Plusieurs entrées sont la norme : multi-cloud, hybride (cloud public + colocation), production + reprise après sinistre dans une autre région, segmentation par charge applicative…

Une bibliothèque vous propose les principaux fournisseurs (OVHcloud, Scaleway, 3DS Outscale, Cloud Temple, Bleu, S3NS, Hetzner, Infomaniak, AWS, Azure, GCP…). Sélectionnez ceux qui correspondent ; chaque entrée pré-remplit son nom, sa juridiction et — pour les opérateurs qui exploitent une pile externalisée comme Bleu ou S3NS — la juridiction de la pile sous-jacente.

Pour chaque hébergeur, vous renseignez :

• Nom : nom commercial.
• Juridiction de l’hébergeur : pays sous le droit duquel opère la société hébergeur.
• Juridiction de la pile technique sous-jacente : à renseigner uniquement si l’hébergeur opère la pile technique d’un autre éditeur. Exemple : Bleu opère Microsoft Azure → juridiction de l’opérateur France, juridiction de la pile sous-jacente United States. Pour OVH ou AWS, ce champ reste vide.
• Localisation des datacenters utilisés : datacenters effectivement utilisés chez ce fournisseur (ville, région). Ex. : « Roubaix (RBX1) + Strasbourg (SBG3) ». Per-fournisseur parce qu’un déploiement multi-cloud utilise des sites différents chez chacun.
• Exposition aux lois extraterritoriales (CLOUD Act, etc.) : ternaire (Oui / Non / Partiel / Non applicable / Non communiqué) avec commentaire et source, pour CET hébergeur. Une déclaration honnête peut combiner Oui (AWS) et Non (OVH) selon les fournisseurs ; c’est précisément ce que la séparation par fournisseur permet d’exprimer.
• Qualifications de cet hébergeur : certifications publiques rattachées à ce fournisseur (SecNumCloud, HDS, ISO 27001, EUCS…). Saisies par hébergeur pour qu’on sache toujours à qui s’applique chaque qualification.

Trajectoire des données et procédure de réquisition#

Champs au niveau du domaine (au-dessous de la liste, indépendants d’un fournisseur particulier) :

• Trajectoire des données : flux global des données client, y compris les passages entre fournisseurs. Ex. : « stockage primaire OVH, sauvegardes Scaleway, transferts hors UE pour le mailing transactionnel ». C’est un récit cross-provider, pas une fiche par hébergeur.
• Procédure d’information en cas de réquisition extra-européenne : process du déclarant lorsqu’une autorité étrangère adresse une réquisition à n’importe lequel de ses fournisseurs. Indépendant du fournisseur qui reçoit la demande.

Étape 02 — Briques consommées#

Au-delà de l’hébergement, votre solution dépend de briques tierces : services SaaS pour des fonctions runtime (paiement, email, CRM…) et plateformes (PaaS) pour le code applicatif. Ces deux catégories ont une exposition souveraineté distincte de l’hébergeur principal et méritent leur propre déclaration.

Plateformes (PaaS) et stratégie de réversibilité#

Distinct de l’hébergeur principal : un PaaS impose un lock-in au niveau de l’API et du runtime. Migrer ailleurs n’est pas un changement de configuration mais un projet de réécriture, dont l’ampleur dépend des fonctionnalités plateforme utilisées.

Bibliothèque dédiée (Vercel, Heroku, Cloud Run, Clever Cloud PaaS…). Chaque entrée pré-remplit la complexité de sortie estimée et affiche, à la sélection, un encart « À retenir » qui détaille les composants propriétaires typiques.

• Nom, Juridiction de la plateforme : pré-remplis depuis la bibliothèque, modifiables.
• Finalité (à quoi sert ce PaaS) : hébergement frontend Next.js, jobs cron, API serverless, etc.
• Complexité de sortie : Faible (redéploiement standard sur un autre runtime), Moyen (adaptation nécessaire), Élevé (réécriture importante), Non évalué. Pré-rempli depuis la bibliothèque, à ajuster selon votre usage réel.
• Composants propriétaires utilisés : listez les fonctionnalités plateforme spécifiques utilisées (Edge Functions, KV, Blob, identité managée, image transforms, queues propriétaires…). Si vous n’en utilisez aucune, dites-le — c’est une bonne nouvelle pour la portabilité.
• Stratégie de portabilité : ce qui est portable dans votre code applicatif et ce qui ne l’est pas. Honnêteté préférable. « Code source 100 % portable, données en Postgres externe » est une réponse plus utile que « technologie ouverte ».
• Stratégie de réversibilité : comment redéployez-vous ailleurs si le PaaS devient indisponible ? Plateforme cible identifiée, délai estimé, dépendances bloquantes.
• Test concret de portabilité : Statut (pleinement / partiellement / non testé) + Date du dernier test. Sans test concret, la portabilité n’est qu’une hypothèse.
• Qualifications de la plateforme : certifications publiques attachées à ce PaaS (SOC 2, ISO 27001, EUCS, HDS…). Mêmes champs que pour l’hébergeur principal. Saisies par PaaS pour qu’on sache à quel fournisseur s’applique chaque qualification.

Services secondaires#

Au-delà de l’hébergement, votre solution dépend en runtime d’un ensemble de services tiers : paiement (Stripe, Mollie, PayPlug), email transactionnel (SendGrid, Brevo, Mailjet), CRM (HubSpot, Pipedrive), support client (Intercom, Zendesk, Crisp), SMS (Twilio). Ces services voient passer une partie des données client et relèvent souvent d’une juridiction différente de l’hébergeur.

La conformité RGPD ne dit rien sur le CLOUD Act : un déclarant qui héberge en France mais expédie ses emails via un service américain doit le déclarer honnêtement.

Une bibliothèque dédiée vous propose les services les plus courants. Pour chaque service utilisé : Nom, Finalité (paiement, email transactionnel, CRM, support client…), Juridiction (US, FR, IE…).

Étape 03 — Outils d’opération (réservé aux MSP)#

Spécifique aux prestataires d’infogérance. Ces outils — RMM (ConnectWise, NinjaOne, Datto, Kaseya, Atera, N-able…), PSA, monitoring, sauvegarde, accès distant — accèdent en continu aux systèmes de vos clients via des agents persistants installés sur chaque endpoint. C’est un angle mort souveraineté majeur : la plupart des éditeurs majeurs sont américains, donc soumis au CLOUD Act et FISA 702. Les serveurs Linux que vous opérez chez votre client français en héritent.

Une bibliothèque vous propose les principaux outils. Pour chacun, indiquez :

• Nom, Type (RMM / PSA / Monitoring / Sauvegarde / Sécurité endpoint / Accès distant / Ticketing / Autre), Éditeur, Juridiction de l’éditeur : pré-remplis depuis la bibliothèque, modifiables.
• Périmètre de déploiement : où l’agent ou le collecteur est-il installé ? Ex. : « tous les serveurs clients », « bastion dédié », « postes de travail uniquement ». Détermine la portée réelle de l’exposition.
• Périmètre d’accès : que peut lire ou modifier l’outil ? Ex. : « accès root complet », « télémétrie système uniquement », « lecture des logs applicatifs ». Un agent root sur chaque serveur client n’expose pas la même chose qu’un collecteur SNMP read-only.
• Commentaire : alternative open source envisagée, plan de bascule, mesures de mitigation.

Étape 04 — Variantes & cadre#

Cette dernière étape couvre les divergences contextuelles (variantes selon le mode de livraison, hébergement opéré pour le compte de clients) et le cadre général du domaine (commentaire, mention « non applicable »).

Variantes par mode de livraison#

À remplir uniquement si vous proposez votre solution sous plusieurs formes — par exemple un éditeur qui vend à la fois une version SaaS hébergée chez lui et une version on-premise déployée chez le client. Si votre solution n’existe que sous une seule forme, laissez vide.

L’idée n’est pas de répéter tout le formulaire pour chaque mode, mais de noter ce qui change par rapport à la déclaration principale ci-dessus.

• Mode concerné : nom court de la variante (on-premise chez le client, offre SecNumCloud premium, édition gouvernementale…).
• Ce qui change pour ce mode : différences par rapport aux réponses ci-dessus. Ex. : « hébergement chez le client, pas chez nous », « datacenters Outscale qualifiés SecNumCloud au lieu d’OVH », « pas de réquisition possible côté éditeur (le client est seul gestionnaire des données) ». Inutile de répéter ce qui est identique.

Hébergement des solutions distribuées#

Pour les distributeurs, intégrateurs et MSP : décrit où sont effectivement hébergées les solutions opérées pour le compte du client. Distinct de l’« Hébergeur principal » ci-dessus, qui couvre l’infrastructure que vous consommez pour vos propres services.

• Nom de la solution : produit ou plateforme livré au client (WordPress managé, GitLab dédié, site e-commerce Magento…).
• Juridiction d’hébergement effective : pays sous lequel s’opère réellement l’hébergement, en tenant compte de la chaîne capitalistique (un cloud français filiale d’un groupe US reste soumis au CLOUD Act).
• Garanties transmissibles : clauses contractuelles que vous pouvez répercuter au client final (engagement sur le pays, procédure de réquisition, certifications). Si vous ne pouvez que transmettre les conditions de l’éditeur d’origine, dites-le honnêtement.

Cadre général#

En bas de l’étape, deux champs transverses :

• Mon cas n’est pas couvert (case à cocher + commentaire) : si le domaine entier ne s’applique pas à votre situation, déclarez-le honnêtement. Une déclaration complète mais courte vaut mieux qu’une déclaration partiellement renseignée.
• Commentaire général : précisions libres qui ne tombent dans aucun champ structuré ci-dessus.