Ce que « hébergé en France » garantit

Éditorial

La mention « hébergé en France » répond à la question de la localisation des disques, qui n'est presque jamais celle qui compte. Ce qui décide de la souveraineté réelle d'un service, c'est la juridiction du fournisseur, la maîtrise des clés, la chaîne des sous-traitants et le chemin par lequel on administre la plateforme.

Mis à jour le 25 septembre 2026~24 min de lecture13 sections

papy cyber

→ Lire l’explication complète de la marmotte

Une phrase qui rassure

Il y a des phrases qu’on écrit pour informer et des phrases qu’on écrit pour rassurer. Les premières contiennent des faits ; les secondes contiennent de l’apaisement, et l’on reconnaît ces dernières à ce qu’elles répondent toujours à une question qu’on n’a pas posée.

« Vos données sont hébergées en France » appartient à la seconde catégorie. On la trouve sur les pages commerciales, dans les réponses aux appels d’offres, dans les présentations aux comités de direction, souvent accompagnée d’un petit drapeau, parfois d’une photographie de centre de données prise au crépuscule, parce que les serveurs sont plus patriotes à contre-jour. Elle est presque toujours vraie. C’est ce qui la rend si efficace : on ne ment pas, on choisit la vérité qui arrange.

Car la phrase répond à une question précise, où sont physiquement les disques, et cette question, pour la sécurité comme pour la souveraineté, est rarement celle qui compte. Ce qui compte, c’est de savoir qui peut accéder aux données, en vertu de quel droit, par quel chemin technique, et avec quelle capacité de les lire. La localisation influe sur certaines de ces réponses, en détermine quelques-unes, et reste muette sur la plupart.

Cet éditorial ne plaide pas pour ou contre un fournisseur, une nationalité ou un modèle. Il prend la phrase au sérieux, ce qui est la pire chose qu’on puisse faire à une phrase de ce genre, et il regarde ce qu’elle garantit réellement. La réponse courte est : moins qu’on ne le croit, plus qu’on ne le dit parfois dans les milieux qui aiment se faire peur, et jamais assez pour se dispenser de lire le contrat.

Trois questions sous une seule étiquette

Le mot « souveraineté » a un défaut majeur, qu’il partage avec « résilience » et « cyber », ce dernier figurant d’ailleurs dans ma propre signature à titre de pénitence : il sonne si bien qu’on oublie de lui demander ce qu’il veut dire. Appliqué à un service en nuage, il recouvre au moins trois questions distinctes, qui ont des réponses distinctes et qu’on ferait bien de ne pas mélanger.

La question géographique. Où résident les données, au repos et en transit ? Où résident leurs copies, leurs sauvegardes, leurs réplicas de reprise ? Où sont traitées les métadonnées, les journaux, la télémétrie ? C’est la question à laquelle répond « hébergé en France », et encore, souvent pour les seules données principales.

La question juridique. Quels droits s’appliquent au fournisseur, à sa société mère, à ses sous-traitants ? Quelle autorité peut leur ordonner de remettre des données, et selon quelle procédure ? Le client serait-il informé, et pourrait-il contester ? Cette question suit les personnes morales, pas les baies de serveurs.

La question technique. Qui, concrètement, a la capacité de lire les données : qui détient les clés de chiffrement, qui administre les machines, qui peut ouvrir une session de support, qui pousse les mises à jour ? Cette question suit les privilèges, pas les drapeaux.

Les trois se combinent de façons que le discours commercial préfère ne pas détailler. Un fournisseur peut être parfaitement localisé et juridiquement exposé. Il peut être juridiquement irréprochable et techniquement capable de tout lire, sans que rien ne l’en empêche sinon sa vertu. Il peut enfin satisfaire aux deux et dépendre, pour une fonction essentielle, d’un sous-traitant qui ne satisfait à aucune. La souveraineté d’un service est celle du maillon le plus faible de ces trois chaînes, et l’étiquette « hébergé en France » n’en décrit qu’une, et partiellement.

La juridiction suit la société, pas le disque

Le point le plus mal compris, et le plus commode à mal comprendre, est celui-ci : le droit qui peut contraindre un fournisseur à remettre des données dépend de qui il est, pas de l’endroit où il range ses machines.

L’exemple le plus cité est le CLOUD Act américain, adopté en 2018. En substance, il permet aux autorités des États-Unis, dans le cadre de procédures prévues par leur droit, d’exiger d’un fournisseur soumis à leur juridiction la communication de données qu’il détient ou contrôle, y compris lorsque ces données sont stockées hors des États-Unis. Le texte prévoit des mécanismes de contestation et d’accords bilatéraux dont la portée exacte relève des juristes ; ce qui intéresse ici l’ingénieur, c’est le critère. Il ne porte pas sur l’emplacement des données, mais sur le contrôle que le fournisseur exerce sur elles.

D’autres textes américains, relevant du renseignement, sont régulièrement cités dans le même débat, notamment la section 702 du FISA. Leur régime diffère, leurs garanties aussi, et leur portée exacte a fait l’objet d’une abondante littérature juridique à laquelle je n’ajouterai rien, sinon la remarque qu’aucune de ces discussions ne se règle par un changement d’adresse du centre de données.

Il faut, par honnêteté, élargir le propos. Les États-Unis n’ont pas le monopole de l’extraterritorialité, et bien des États se reconnaissent, sous une forme ou une autre, le droit d’obtenir des données de sociétés qui relèvent de leur compétence. La Chine, par la Cyberspace Administration of China, y ajoute la localisation obligatoire et l’autorisation préalable des transferts, ce qui a au moins le mérite de la franchise. La question n’est donc pas « américain ou non », formule qui a l’avantage de désigner un coupable et l’inconvénient de ne rien expliquer. Elle est : à quels droits le fournisseur, sa maison mère et ses sous-traitants sont-ils soumis, et ces droits peuvent-ils entrer en conflit avec celui auquel je suis moi-même soumis ?

C’est cette possibilité de conflit que la Cour de justice de l’Union européenne a examinée dans l’arrêt dit Schrems II, en 2020, en invalidant le cadre transatlantique alors en vigueur pour les transferts de données personnelles. Un nouveau cadre a été adopté depuis ; sa solidité juridique fait débat et pourrait être à nouveau éprouvée devant les juridictions. Je m’abstiens de pronostic : l’histoire récente de ces accords invite à la modestie, et à relire régulièrement les publications officielles plutôt que les plaquettes.

Il découle de tout cela une conséquence que l’on formule rarement aussi crûment. Une filiale française d’une société soumise à un droit extraterritorial reste, pour ce droit, une entité dont la société mère contrôle les données, et la localisation du centre de données n’y change rien d’essentiel. Inversement, un fournisseur de droit exclusivement européen qui héberge ses données hors d’Europe pose d’autres questions, de transfert notamment, mais pas celle-là. La géographie et la juridiction sont deux axes, et il est parfaitement possible d’être bien placé sur l’un et mal placé sur l’autre. C’est même le cas le plus fréquent, ce qui explique que l’on mette en avant celui sur lequel on est bien placé.

Les clés : qui peut déchiffrer

Supposons résolue la question juridique, ou jugée acceptable. Reste la question technique, qui a le mérite de ne pas dépendre de l’humeur d’un tribunal : qui a la capacité matérielle de lire les données ?

La réponse commerciale habituelle est « vos données sont chiffrées ». Elle est vraie, et elle n’a presque aucun sens tant qu’on n’a pas dit qui détient les clés. Des données chiffrées avec une clé que le fournisseur détient, gère et utilise automatiquement pour les servir sont chiffrées contre le voleur de disques, ce qui n’est pas rien, et contre personne d’autre. Le fournisseur peut les lire, puisque c’est lui qui les déchiffre à chaque requête. S’il peut les lire, il peut être contraint de les remettre en clair.

Les offres de gestion de clés se répartissent grossièrement en trois familles, dont les noms varient selon les fournisseurs, ce qui entretient une confusion propice aux malentendus.

Les clés gérées par le fournisseur. Le fournisseur crée, stocke et utilise les clés. Le client n’en voit rien. C’est le régime par défaut, commode et opaque.

Les clés fournies ou contrôlées par le client, mais utilisées dans le service de gestion de clés du fournisseur. Le client importe sa clé, ou la fait générer dans le KMS du fournisseur, et dispose de politiques d’usage, de journaux, souvent de la possibilité de désactiver la clé. C’est un progrès réel en gouvernance, mais le point décisif demeure : la clé est utilisée par l’infrastructure du fournisseur, et le déchiffrement a lieu chez lui. Le client contrôle les conditions d’usage ; il ne contrôle pas la machine qui les applique. Dans certaines offres, la clé réside dans un HSM dédié, ce qui améliore la protection de la clé elle-même sans changer le fait que c’est la plateforme du fournisseur qui s’en sert pour déchiffrer.

Les clés détenues hors du fournisseur. Le client conserve ses clés dans une infrastructure qu’il maîtrise, et le service ne reçoit que des données déjà chiffrées, ou doit solliciter une clé externe à chaque usage. C’est le seul régime dans lequel le fournisseur, même contraint, n’a matériellement rien d’intelligible à remettre. C’est aussi celui qui prive le service d’une bonne partie de ses fonctions : un service qui ne peut pas lire les données ne peut pas les indexer, les rechercher, les analyser ni les transformer. On n’a pas encore inventé la base de données qui trie ce qu’elle ne voit pas, du moins pas à un coût qu’un directeur financier accepterait sans syncope.

La maîtrise des clés est donc un arbitrage, pas une case à cocher. Plus le client garde la main, moins le service peut faire pour lui. Le discours qui promet à la fois la puissance fonctionnelle d’une plateforme et l’impossibilité pour son opérateur d’accéder aux données mérite d’être lu très lentement, ligne par ligne, en cherchant à quel endroit précis la clé en clair rencontre la donnée en clair. Il y a toujours un tel endroit ; la seule question est de savoir chez qui.

Les techniques d’informatique confidentielle, qui exécutent les traitements dans des enclaves matérielles censées être opaques à l’opérateur, déplacent cette frontière de manière intéressante. Elles reposent toutefois sur la confiance accordée au fabricant du processeur et à la chaîne d’attestation, et leur histoire comporte déjà son lot d’attaques par canaux auxiliaires. Je les tiens pour une piste sérieuse et non pour une garantie ; le jour où elles en deviendront une, on nous le fera savoir avec une insistance qui dispensera de vérifier, ce qui sera précisément le moment de vérifier.

Les bonnes pratiques d’exploitation des clés (séparation des rôles, rotation, journalisation de chaque usage, procédure de révocation) sont détaillées ailleurs sur ce site, dans le chapitre sur l’exploitation des clés et les KMS. Elles ne remplacent pas la question de fond : où la clé est-elle utilisée, et par qui ?

La chaîne invisible des sous-traitants

Un service en nuage n’est jamais un seul fournisseur. C’est un empilement dont le client ne voit que la façade, comme ces immeubles haussmanniens dont on découvre, en poussant la porte cochère, qu’ils donnent sur trois cours successives et un atelier de réparation de mobylettes.

Le fournisseur principal s’appuie typiquement sur des tiers pour des fonctions qui paraissent accessoires et ne le sont pas : l’infrastructure physique elle-même, parfois ; la distribution de contenu ; la résolution de noms ; l’envoi des courriels de notification ; la supervision et la collecte de télémétrie ; la gestion des tickets de support ; l’authentification des administrateurs ; les sauvegardes hors site. Chacun de ces tiers peut voir passer des données, des métadonnées ou des accès. Chacun relève d’un droit. Chacun est une frontière.

Un service hébergé en France peut ainsi faire transiter une partie de ce qui le concerne par des tiers qui ne le sont pas. Ce n’est pas nécessairement une faute, ni même un risque important ; c’est un fait qui doit être connu pour être évalué. Le RGPD impose d’ailleurs au sous-traitant d’obtenir l’autorisation du responsable avant de recourir à un autre sous-traitant, et la liste de ces sous-traitants ultérieurs est normalement communiquée. Elle est rarement lue. Elle est pourtant le seul document qui dise la vérité sur l’étiquette, ce qui explique peut-être qu’on la relègue en annexe.

Les métadonnées méritent une attention particulière, précisément parce qu’on les croit anodines. Les journaux d’accès, les noms des ressources, les adresses des utilisateurs, les volumes échangés, les heures de connexion : rien de tout cela n’est « la donnée », et tout cela en dit parfois plus long qu’elle. Un fournisseur peut tenir scrupuleusement ses données clients sur le territoire et centraliser sa télémétrie ailleurs, en toute bonne foi, parce que sa plateforme de supervision est mondiale. La question « où sont traitées les métadonnées ? » est l’une des plus instructives qu’on puisse poser, et l’une de celles qui provoquent les silences les plus éloquents.

La démarche qui consiste à relier chaque traitement de données à ses destinataires réels, examinée dans l’éditorial sur le registre des traitements comme outil de sécurité, trouve ici une application directe. Un fournisseur n’est pas un destinataire unique : c’est une grappe.

Le support, l’administration et la main qui tient la console

Il reste une dernière couche, la plus prosaïque et la plus décisive : qui peut agir sur la plateforme, et d’où ?

Un centre de données situé en France peut être administré, en tout ou en partie, par des équipes situées ailleurs. C’est un mode d’exploitation courant, souvent justifié : les grandes plateformes fonctionnent en continu, et la continuité s’obtient en faisant tourner le soleil autour des équipes d’astreinte. Mais une console d’administration est un chemin d’accès, et un chemin d’accès se moque éperdument de l’emplacement des disques auxquels il mène. Un administrateur qui peut lire une donnée depuis l’étranger rend la localisation de cette donnée largement théorique.

Le support client pose la même question sous une forme plus insidieuse. Pour résoudre un incident, un technicien du fournisseur peut avoir besoin d’accéder à l’environnement du client, parfois à ses données. Les offres sérieuses encadrent cet accès : approbation préalable par le client, accès limité dans le temps, journalisation détaillée, parfois restriction à du personnel situé dans une zone donnée et soumis à des contrôles particuliers. Ces mécanismes existent et méritent d’être exigés. Ils ont un défaut commun : ils dépendent de la plateforme qu’ils encadrent. Le journal qui prouve qu’aucun accès n’a eu lieu est tenu par celui dont on voudrait vérifier qu’il n’a pas accédé. On n’a pas mieux, mais il faut savoir que c’est ce que l’on a.

Viennent enfin les mises à jour, dont on parle peu dans ce débat alors qu’elles en sont peut-être le cœur. On s’inquiète beaucoup de savoir qui pourrait venir chercher les données ; on s’inquiète moins de ce qui y entre chaque jour par la grande porte, avec un numéro de version. Le fournisseur pousse en permanence du code sur sa plateforme : correctifs, nouvelles fonctions, agents de supervision. Ce code s’exécute avec les privilèges de la plateforme, donc avec la capacité de lire ce qu’elle lit. Quiconque contrôle la chaîne de mise à jour contrôle, en dernière analyse, ce que fait le système. C’est vrai d’un service en nuage comme d’un logiciel installé, et c’est une des raisons pour lesquelles la séparation entre « hébergement » et « exploitation » est si difficile à obtenir en pratique : on peut louer des murs, on ne loue pas une plateforme sans louer aussi ceux qui la font évoluer.

L’identité des administrateurs du côté client relève de la même logique, et elle est souvent le maillon le plus faible de toute la construction. Une plateforme juridiquement et techniquement souveraine, administrée par des comptes à privilèges protégés par un mot de passe réutilisé, n’est souveraine que pour l’attaquant qui s’en empare. Les questions de gestion des identités et des accès ne sont pas l’objet de cet éditorial, mais elles en sont le rappel à l’ordre permanent : la souveraineté d’un service se perd plus souvent par la porte de l’administrateur que par celle du législateur étranger.

Ce que les qualifications disent, et ce qu’elles taisent

Face à cette complexité, il est tentant de s’en remettre à un label. Il en existe, et certains sont sérieux. Hors de France, la Cloud Security Alliance publie matrices de contrôle et questionnaires d’évaluation des fournisseurs, lecture aride mais moins coûteuse qu’une désillusion contractuelle.

En France, la qualification SecNumCloud, délivrée par l’ANSSI, est la référence la plus exigeante pour les services d’informatique en nuage. Elle repose sur un référentiel qui couvre la sécurité technique, l’organisation, la localisation et l’exploitation, et ses versions récentes ont intégré des exigences visant à protéger le service contre l’application de droits extraterritoriaux, notamment par des conditions portant sur le contrôle du prestataire. Je m’abstiens de détailler ces critères, qui ont évolué et pourraient évoluer encore : le référentiel en vigueur et la liste des offres qualifiées sont publiés par l’ANSSI, et c’est là qu’il faut les lire, pas ici, et surtout pas dans une plaquette qui « s’inscrit dans une démarche de qualification ». À l’échelle européenne, un schéma de certification des services en nuage est discuté depuis plusieurs années, et la place qu’il réserve à ces questions a fait l’objet de débats dont l’issue doit être vérifiée à la source.

Une qualification sérieuse apporte trois choses précieuses : un référentiel public, une évaluation par un tiers, un suivi dans le temps. Elle dispense le client de refaire seul un travail d’évaluation qu’il n’aurait pas les moyens de mener. Elle ne le dispense pas de savoir ce qu’il achète.

Car une qualification porte sur un périmètre, pas sur une marque. Un fournisseur peut proposer une offre qualifiée et dix autres qui ne le sont pas, sur la même console, avec le même logo, à trois clics de distance. Le client qui souscrit au service voisin, plus riche en fonctions, bénéficie du prestige de la qualification sans en bénéficier des garanties, ce qui est une forme très moderne de la confiance par capillarité. De même, une qualification décrit le service ; elle ne décrit pas l’usage que le client en fait. Des données qualifiées « sensibles » confiées à une offre qualifiée, mais administrées depuis un poste compromis, ou exportées chaque nuit vers un outil d’analyse qui ne l’est pas, n’héritent de rien.

Il faut enfin garder à l’esprit ce qu’est un label : une photographie à une date, selon un référentiel à une date. Les menaces, les droits et les plateformes évoluent entre deux évaluations. C’est vrai de toute certification, et ce n’est pas une critique de celle-ci ; c’est une raison de lire le rapport de qualification, pas seulement le logo.

Une grille de lecture pour un contrat

Si l’on veut dépasser la phrase rassurante, il faut poser des questions précises et lire les réponses écrites, pas les réponses orales, qui n’engagent que ceux qui les écoutent. En voici une grille, sans prétention d’exhaustivité, pensée pour un service qui doit porter des données sensibles.

Géographie.

Où résident les données principales, leurs sauvegardes, leurs réplicas de reprise ?
Où sont traitées les métadonnées, les journaux et la télémétrie de la plateforme ?
Où sont situées les équipes qui administrent la plateforme et celles qui assurent le support ?

Juridiction.

Quelle est la société contractante, qui la contrôle, et à quels droits ces entités sont-elles soumises ?
Le fournisseur s’engage-t-il à informer le client de toute demande d’accès d’une autorité, dans la mesure où la loi le permet, et à la contester lorsqu’elle lui paraît infondée ?
Quelle est la liste des sous-traitants ultérieurs, pour quelles fonctions, et comment le client est-il informé de ses changements ?

Technique.

Qui détient les clés de chiffrement, où sont-elles utilisées, et le client peut-il les révoquer de manière à rendre les données illisibles pour le fournisseur ?
Comment l’accès du support aux données est-il autorisé, limité, journalisé, et le client reçoit-il ces journaux ?
Comment la chaîne de mise à jour est-elle contrôlée, et quelles garanties existent sur le code qui s’exécute avec les privilèges de la plateforme ?

Sortie.

Comment récupère-t-on les données, dans quel format, dans quel délai, à quel coût ?
Comment la destruction est-elle garantie en fin de contrat, y compris dans les sauvegardes ?

La dernière rubrique est la plus négligée et, à mon sens, la plus souveraine de toutes. La capacité de partir est la seule garantie qui ne dépende pas de la bonne volonté du fournisseur. Un service dont on ne peut pas sortir dans un délai raisonnable n’est pas un service qu’on a choisi : c’est un service qui nous a choisis. La réversibilité n’est pas un détail contractuel ; c’est le seul moment où l’on vérifie que tout le reste était vrai.

Le meilleur argument contre

Tout ce qui précède peut donner l’impression que le seul choix raisonnable est un fournisseur de droit national, qualifié, avec des clés détenues en propre. Il serait malhonnête de ne pas exposer la meilleure objection à cette conclusion implicite, et elle est forte.

Le risque juridique extraterritorial est réel, mais il n’est pas le risque dominant pour la plupart des organisations. Une PME qui héberge sa comptabilité, un cabinet qui stocke ses dossiers, une association qui gère ses adhérents sont infiniment plus exposés au rançongiciel, au vol d’identifiants, à l’erreur de configuration et à la panne qu’à une réquisition d’une autorité étrangère. Pour ces risques-là, les très grandes plateformes disposent souvent de moyens de sécurité, de détection et de résilience qu’aucun acteur plus modeste ne peut égaler. Choisir un fournisseur moins exposé juridiquement mais moins solide techniquement peut revenir à échanger un risque improbable contre un risque certain. On aura alors la satisfaction de s’être fait chiffrer ses données par un criminel ordinaire plutôt que de les avoir vu réquisitionner par un État ; c’est une satisfaction de principe, dont les sauvegardes absentes ne tiennent aucun compte.

L’objection a un second volet, économique. Les offres qui cumulent localisation, juridiction maîtrisée, qualification et clés détenues par le client coûtent plus cher et offrent souvent moins de fonctions. Pour beaucoup d’usages, ce surcoût n’est pas justifié par la sensibilité des données. Exiger partout le niveau maximal, c’est le rendre inabordable là où il serait nécessaire.

Je tiens cette objection pour juste, et elle ne contredit pas l’éditorial ; elle en rappelle l’objet. La question n’est pas de choisir le fournisseur le plus souverain, mais de savoir ce que garantit celui qu’on a choisi, pour le confronter à la sensibilité réelle des données qu’on lui confie. Le travail utile consiste à classer ses données, à réserver les offres les plus contraignantes à celles qui le justifient, et à ne pas se raconter d’histoires sur les autres. Ce qui est condamnable, ce n’est pas d’héberger chez un fournisseur exposé à un droit étranger ; c’est de le faire en croyant, sur la foi d’un drapeau, que l’on ne l’est pas.

Ce que je ne sais pas

Je ne sais pas mesurer la probabilité d’une réquisition extraterritoriale. Les fournisseurs publient parfois des rapports de transparence sur les demandes reçues, mais leur granularité et leur périmètre ne permettent pas, à ma connaissance, d’estimer le risque pour une organisation donnée. Tout discours qui chiffre ce risque avec précision, dans un sens ou dans l’autre, me paraît relever de la conviction plus que de la mesure.

Je ne sais pas ce que vaudra le cadre transatlantique actuel dans quelques années. Les précédents invitent à la prudence, mais une prudence qui n’est pas une prédiction. Les organisations qui dépendent de ces transferts ont intérêt à prévoir un scénario de repli, ce que je dis sans savoir s’il servira.

Je ne sais pas jusqu’où l’informatique confidentielle tiendra ses promesses. Si les enclaves matérielles devenaient robustes et vérifiables par le client, la question de la maîtrise technique changerait de nature : on pourrait confier un traitement à une plateforme sans lui confier la lecture des données. Nous n’en sommes pas là, et je ne sais pas si nous y serons.

Je ne sais pas si la souveraineté totale est atteignable pour un acteur ordinaire. Même un fournisseur national qualifié achète ses processeurs, ses cartes réseau, ses micrologiciels et une partie de ses logiciels à des fabricants soumis à d’autres droits. Il y a une limite au-delà de laquelle la question ne se pose plus au niveau d’une organisation, mais d’une politique industrielle, et je ne suis pas qualifié pour la traiter.

Ce qui reste

« Hébergé en France » est une information. Ce n’est pas une garantie, et encore moins une politique.

Trois choses me semblent acquises. Que la souveraineté d’un service se décompose en géographie, juridiction et maîtrise technique, et que l’étiquette ne décrit que la première. Que la maîtrise des clés est un arbitrage entre la capacité du service et celle de son opérateur à lire les données, et qu’aucune offre ne donne tout à la fois sans qu’il faille chercher où se cache le compromis. Et que la réversibilité est la seule garantie qui ne repose pas sur la parole du fournisseur, ce qui en fait la question à poser en premier plutôt qu’en dernier.

Le reste est affaire de classement : savoir quelles données méritent quelles exigences, et accepter que la plupart n’exigent pas le maximum. C’est moins héroïque que de brandir un drapeau. C’est aussi la seule manière de ne pas payer le prix de la souveraineté pour des données qui n’en avaient pas besoin, tout en laissant filer, faute d’avoir regardé, celles qui en avaient besoin. Les plateformes en nuage ne sont ni des coffres-forts ni des passoires ; ce sont des contrats, avec des machines derrière, et l’on ferait bien de lire les deux.

🐝 Ce qui arrive si on s’en passe

Une organisation qui se contente de l’étiquette « hébergé en France » découvre les réponses aux vraies questions au pire moment : lors d’une demande d’accès d’une autorité dont elle n’est pas informée, d’un incident dont les journaux sont tenus par le fournisseur lui-même, ou d’un changement de conditions qu’elle ne peut pas refuser faute de pouvoir partir. Ses données sensibles voisinent alors avec les autres dans une offre non qualifiée souscrite par commodité, et ses métadonnées suivent une télémétrie centralisée dont personne n’a lu la destination. Sans réversibilité éprouvée, l’argument de négociation disparaît : prix, fonctions et garanties se décident d’un seul côté de la table, et le contrat se relit chaque année avec la sérénité d’un locataire sans bail.

🦫 Explication de la marmotte 🍫

Un service en nuage, c’est-à-dire un service informatique loué à un fournisseur et utilisé par internet, garde les données de ses clients sur des serveurs. Dire qu’il est hébergé en France indique seulement où se trouvent ces serveurs. Trois autres questions comptent davantage. La première est juridique : le fournisseur, sa société mère et ses sous-traitants obéissent aux lois de leurs pays, et certaines lois permettent à une autorité d’exiger des données contrôlées par une entreprise, même stockées à l’étranger. La deuxième est technique : les données sont souvent chiffrées, mais celui qui détient la clé et fait le déchiffrement peut les lire, et donc être obligé de les remettre. Si le client garde lui-même la clé hors du fournisseur, celui-ci n’a rien de lisible à livrer, mais le service ne peut plus rechercher ni analyser ces données. La troisième concerne l’accès : administrateurs, techniciens du support, sous-traitants et mises à jour installées chaque jour agissent sur la plateforme, parfois depuis d’autres pays, et les journaux ou les heures de connexion peuvent être traités ailleurs. Des qualifications officielles évaluent certains services, mais seulement pour un périmètre précis et à une date donnée. Le texte propose donc de classer ses données selon leur sensibilité, de lire le contrat avec une liste de questions précises, et de vérifier qu’il est possible de récupérer ses données et de partir.

Pages voisines

La citent

Ce que « hébergé en France » garantit

Elle cite

Ce que « hébergé en France » garantit

Une phrase qui rassure

Trois questions sous une seule étiquette

La juridiction suit la société, pas le disque

Les clés : qui peut déchiffrer

La chaîne invisible des sous-traitants

Le support, l’administration et la main qui tient la console

Ce que les qualifications disent, et ce qu’elles taisent

Une grille de lecture pour un contrat

Le meilleur argument contre

Ce que je ne sais pas

Ce qui reste

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines