Choisir où résident vos serveurs et vos données : latence et droit

L’emplacement d’un serveur était autrefois un détail d’achat. Il détermine aujourd’hui trois choses à la fois : la réactivité de votre application pour les utilisateurs, les lois qui régissent les données qu’elle contient et votre capacité à reprendre l’activité lorsqu’un site ou une région tombe en panne.

Ce guide aborde la décision comme une équipe d’infrastructure devrait la prendre : partir des données et des utilisateurs, chiffrer la latence, cartographier les contraintes juridiques dans leurs grandes lignes, tenir compte de chaque copie des données (et pas seulement de la copie principale), puis inscrire le résultat dans vos contrats.

Une remarque avant de commencer : ce document est un guide d’ingénierie, et non un avis juridique. Les règles de protection et de résidence des données évoluent, dépendent de faits propres à votre activité et sont interprétées différemment selon les régulateurs. Utilisez ce contenu pour cadrer les questions, puis faites confirmer chaque conclusion juridique par un conseil qualifié dans les juridictions qui vous concernent.

Partir des données, pas de la carte

Avant de choisir une ville, classez ce que le système stocke et traite. La plupart des organisations finissent avec un petit nombre de classes de données, chacune avec ses propres règles de placement.

• Données personnelles. Tout ce qui identifie une personne : noms, adresses e-mail, adresses IP, identifiants d’appareils, historique de localisation. C’est sur ces données que portent la plupart des lois de protection de la vie privée.
• Catégories sensibles ou particulières. Données de santé, biométriques, financières, pièces d’identité officielles, données relatives aux enfants. Elles sont généralement soumises à des règles de traitement et de transfert plus strictes.
• Données de secteurs réglementés. Données de paiement, données bancaires, dossiers de santé, données du secteur public. Les régulateurs sectoriels ajoutent souvent des exigences au droit général de la protection des données.
• Données confidentielles de l’entreprise. Code source, modèles, contrats, tarifs. Pas toujours réglementées, mais les clients peuvent tout de même exiger la maîtrise de leur localisation.
• Données opérationnelles. Journaux, métriques, traces, tickets de support. Souvent négligées, fréquemment remplies de données personnelles et couramment expédiées par défaut vers un pays tiers.

Pour chaque classe, consignez où se trouvent les personnes concernées, où les données sont créées, qui doit y accéder et depuis où, et ce que les contrats clients promettent déjà.

Latence : ce que coûte réellement la distance

Dans la fibre optique, la lumière se propage à environ 200 000 km par seconde, soit à peu près les deux tiers de sa vitesse dans le vide. Cela représente environ 1 ms de temps aller-retour pour 100 km de fibre. Les tracés réels des câbles sont plus longs que la ligne droite, et chaque routeur et point d’échange ajoute un léger délai : les temps aller-retour mesurés sont donc généralement de 1,3 à 2 fois la valeur calculée en ligne droite.

Voici des temps aller-retour approximatifs observés en conditions réelles.

• Même agglomération. 1 à 5 ms.
• Même région, jusqu’à environ 1 000 km. 10 à 25 ms.
• À travers les États-Unis continentaux, d’une côte à l’autre. 60 à 80 ms.
• De la côte Est des États-Unis vers l’Europe de l’Ouest. 75 à 100 ms.
• De la côte Est des États-Unis vers l’Inde. 180 à 250 ms.
• De Singapour vers l’Inde. 50 à 80 ms.
• De la côte Ouest des États-Unis vers Singapour. 160 à 200 ms.
• De la côte Est des États-Unis vers São Paulo. 110 à 140 ms.

Pourquoi l’enjeu est plus important qu’il n’y paraît : une page ou un appel d’API nécessite rarement un seul aller-retour. À 200 ms par aller-retour, cinq allers-retours séquentiels représentent une seconde entière d’attente avant tout traitement côté serveur. Le même enchaînement à 20 ms coûte 100 ms.

Repères pratiques : les applications interactives paraissent réactives lorsque l’aller-retour vers l’origine reste inférieur à 50 ms environ, et la plupart des utilisateurs perçoivent un délai dès que le temps de réponse total dépasse quelques centaines de millisecondes. La latence entre vos propres couches compte aussi : un serveur d’application et sa base de données doivent normalement se trouver dans le même site ou la même zone de disponibilité, car un trafic de base de données très bavard multiplie chaque milliseconde.

Règles de résidence, de souveraineté et de transfert dans leurs grandes lignes

Trois termes sont employés de manière approximative. La résidence des données désigne le lieu où les données sont physiquement stockées. La localisation des données est une exigence légale imposant que certaines données restent dans un pays. La souveraineté des données est la notion plus large selon laquelle les données sont soumises aux lois du lieu où elles sont détenues, et parfois aux lois du pays où le fournisseur est établi. La plupart des lois générales sur la protection des données n’imposent pas de localisation. Elles encadrent plutôt les transferts transfrontaliers et les garanties qui les accompagnent.

• RGPD (Union européenne et EEE). Les données personnelles peuvent quitter l’EEE, mais uniquement dans le cadre d’un mécanisme reconnu : une décision d’adéquation pour le pays de destination, des clauses contractuelles types accompagnées d’une évaluation des risques liés au transfert, des règles d’entreprise contraignantes ou des dérogations limitées. Les transferts vers des organisations américaines certifiées au titre du Data Privacy Framework UE-États-Unis sont couverts par une décision d’adéquation. Un accès à distance depuis un autre pays constitue un transfert.
• CCPA tel que modifié par le CPRA (Californie). Aucune exigence de localisation. L’accent est mis sur les droits des consommateurs (accès, suppression, opposition à la vente ou au partage) et sur les contrats avec les prestataires, qui limitent l’usage qu’ils font des données. Plusieurs autres États américains ont adopté des lois globalement similaires.
• LGPD (Brésil). Structurée de manière très proche du RGPD. Les transferts internationaux exigent une base légale, comme une décision d’adéquation, des clauses contractuelles types approuvées par l’autorité nationale (ANPD) ou un consentement spécifique, et l’autorité a publié des règlements qui détaillent ces mécanismes.
• DPDP Act (Inde). Le Digital Personal Data Protection Act de 2023 autorise en général les transferts hors d’Inde, sauf vers les pays que le gouvernement restreint par notification, ses règles d’application entrant en vigueur progressivement. Les règles sectorielles indiennes peuvent être plus strictes que la loi générale, et elles priment lorsqu’elles s’appliquent.
• Autres pays. Certaines juridictions exigent que certaines catégories de données, ou au moins une copie de celles-ci, soient stockées localement, ou soumettent les transferts à autorisation. Si vous servez des utilisateurs dans un pays, vérifiez ses règles dès le départ plutôt qu’au moment du contrat.

Un fournisseur dont le siège se trouve dans un pays et qui héberge dans un autre peut être soumis aux demandes légales des deux. Demandez à votre conseil juridique comment cela s’applique à votre situation et consignez la réponse dans vos documents de conception.

Les règles sectorielles qui priment sur le cadre général

Les règles sectorielles imposent souvent des exigences plus strictes ou plus précises que le droit général de la protection des données. Exemples courants :

• Paiements. PCI DSS n’impose pas de pays, mais définit la manière dont les environnements de données de titulaires de carte sont segmentés, accessibles et audités, ce qui détermine quels sites et quels fournisseurs sont éligibles. Certains régulateurs nationaux vont plus loin : la Reserve Bank of India, par exemple, exige que les données des systèmes de paiement soient stockées uniquement en Inde.
• Santé. Aux États-Unis, HIPAA n’impose pas d’hébergement sur le territoire national, mais exige un business associate agreement avec tout fournisseur qui traite des informations de santé protégées. De nombreux clients du secteur de la santé ajoutent malgré tout des exigences contractuelles d’hébergement exclusivement aux États-Unis.
• Services financiers. Les régulateurs de la banque et de l’assurance exigent couramment une notification ou une autorisation pour toute externalisation significative, des droits d’audit pour le régulateur et des plans de sortie documentés.
• Secteur public. Les programmes publics exigent souvent un hébergement sur le territoire national, du personnel habilité ou des cadres d’autorisation spécifiques, et ces exigences s’appliquent généralement aussi aux sous-traitants.

Lorsqu’un contrat client ou un régulateur impose une exigence de localisation, celle-ci devient une contrainte ferme.

Sauvegardes, réplicas et les copies que l’on oublie

La plupart des manquements en matière de résidence ne concernent pas la base de données principale. Un système qui stocke les données de production dans un pays mais envoie chaque nuit ses sauvegardes, ses flux de journaux ou ses exports de support vers un autre a, dans les faits, une empreinte multipays.

Recensez chaque endroit où une copie des données peut se retrouver :

• Sauvegardes et snapshots. Où sont-ils stockés, combien de temps sont-ils conservés, et sont-ils chiffrés avec des clés que vous maîtrisez ?
• Réplicas. Réplicas en lecture, bases de données de secours et réplication interrégionale pour la reprise après sinistre.
• Journaux et observabilité. Les journaux applicatifs, les journaux d’accès, les traces et les rapports d’erreur contiennent souvent des adresses IP, des identifiants d’utilisateurs et des corps de requêtes.
• CDN et caches. Les caches en périphérie peuvent contenir des contenus personnels dans de nombreux pays. Configurez ce qui peut être mis en cache, et où.
• Support et administration. L’accès à distance d’ingénieurs ou d’agents du support situés dans un autre pays peut constituer un transfert au regard de plusieurs législations.
• Pipelines analytiques et d’IA. Les données exportées pour l’analyse, l’entraînement ou l’inférence de modèles peuvent partir vers une autre région ou un autre fournisseur.

Un modèle courant et défendable consiste à conserver le primaire et son secours immédiat dans une même juridiction, à placer les copies de reprise après sinistre dans un second site de cette même juridiction lorsque c’est possible et, lorsqu’une sauvegarde transfrontalière est nécessaire, à chiffrer avant le transfert avec des clés détenues dans la juridiction principale. La question de savoir si le chiffrement modifie l’analyse juridique dépend de la loi et des faits : confirmez également ce point avec votre conseil juridique.

Une liaison dédiée de 1 Gbps transfère environ 10 TB par jour à pleine utilisation, et moins en pratique. Si la restauration complète de votre plus gros jeu de données sur cette liaison prend plus longtemps que votre objectif de temps de reprise, il vous faut une liaison plus large, une copie plus proche ou un autre plan de reprise.

Architectures multirégions et ce qu’elles coûtent

Fonctionner dans plusieurs régions répond à deux problèmes distincts : la proximité avec des utilisateurs situés dans différentes zones géographiques, et la survie à une panne régionale.

• Une seule région, plusieurs sites. Primaire et secours dans des data centers distincts au sein de la même agglomération ou du même pays. Faible latence de réplication, question de la résidence simple à traiter ; protège contre la défaillance d’un site, mais pas contre un événement régional.
• Actif-passif entre régions. Une région sert le trafic, une seconde héberge des réplicas et peut être promue. Avec une réplication asynchrone, le point de reprise accuse un retard de quelques secondes à quelques minutes. Un bon équilibre pour la plupart des systèmes métier.
• Actif-actif entre régions. Les deux régions servent le trafic. Cela exige une gestion rigoureuse des écritures, de la résolution des conflits ou un partitionnement de la propriété des données, ainsi que beaucoup plus de tests. Se justifie pour des bases d’utilisateurs mondiales soumises à de fortes exigences de disponibilité.
• Cellules régionales. Chaque région conserve les données de ses propres utilisateurs et ne sert qu’eux, avec un état partagé minimal. Ce modèle s’accorde bien avec les exigences de résidence : les utilisateurs européens dans une cellule européenne, les utilisateurs indiens dans une cellule indienne, et ainsi de suite.

La réplication synchrone entre régions ajoute l’aller-retour complet à chaque écriture : un lien de 70 ms ajoute donc au moins 70 ms à chaque transaction validée. La plupart des équipes n’utilisent la réplication synchrone qu’au sein d’une même agglomération et passent en asynchrone sur de plus longues distances. Prévoyez aussi le budget de l’infrastructure dupliquée, les frais de transfert interrégionaux lorsqu’ils s’appliquent et le temps d’ingénierie nécessaire à des tests de bascule réguliers.

Les clauses contractuelles à demander

Une conception technique ne tient que si le contrat la soutient. Lorsque vous évaluez un fournisseur d’hébergement ou de cloud, demandez des clauses ou des engagements écrits couvrant les points suivants, et faites relire la formulation finale par un conseil juridique.

• Localisations nommées. Le pays et, idéalement, le site ou la région des données principales, des sauvegardes et des réplicas, indiqués dans le bon de commande ou dans le cahier des charges.
• Aucun déplacement sans accord. Le fournisseur ne déplacera pas les données vers un autre emplacement sans votre consentement écrit préalable.
• Accord de traitement des données. Les rôles (responsable du traitement et sous-traitant), les finalités du traitement, les mesures de sécurité et les mécanismes de transfert lorsqu’il existe des flux transfrontaliers.
• Liste des sous-traitants ultérieurs et préavis. Une liste à jour des sous-traitants ultérieurs avec leur localisation, et un préavis assorti d’un droit d’opposition avant tout changement.
• Transparence sur les accès à distance. Depuis quels pays le personnel du fournisseur peut accéder aux systèmes ou aux données, et selon quels contrôles.
• Notification des violations. Un délai de notification défini, compatible avec vos propres échéances réglementaires, ainsi que les informations que le fournisseur communiquera.
• Demandes d’accès des autorités. Un engagement à vous informer lorsque la loi le permet, et à contester les demandes excessives.
• Audit et preuves. Accès aux rapports d’audit tiers ou aux certifications des sites pertinents pour votre secteur, et une procédure pour les audits des autorités de contrôle si vous en avez besoin.
• Réversibilité et suppression. Export des données dans des formats exploitables, période de transition et suppression certifiée de toutes les copies, sauvegardes comprises, à la fin du contrat.

Une checklist pour votre prochaine revue d’architecture

• Chaque classe de données inventoriée avec les juridictions des personnes concernées.
• Contraintes de localisation légales, réglementaires et contractuelles recensées et confirmées avec un conseil juridique.
• RTT entre les principales populations d’utilisateurs et chaque site candidat : mesuré, non estimé.
• Serveurs applicatifs et bases dans le même site ou la même zone.
• Copies cartographiées : primaire, réplicas, sauvegardes, journaux, caches, analyses, exports du support.
• Flux transfrontaliers : mécanisme documenté, responsable désigné.
• Clés des sauvegardes détenues dans la juridiction prévue.
• RPO et RTO définis, et la liaison de sauvegarde permet de les tenir.
• Bascule testée sur les six derniers mois, résultats consignés.
• Les contrats fixent les emplacements, interdisent tout déplacement non approuvé et couvrent sous-traitants ultérieurs, notification des violations et réversibilité.
• Décision et justification consignées. Prochain audit ou questionnaire client : quelques heures, pas des semaines.

Comment Vonahost peut vous aider

Vonahost permet à ses clients de choisir le pays de chaque serveur, et les données ne sont pas déplacées sans leur accord. Les serveurs dédiés, les VPS NVMe et les VPS SSD sont déployés dans la région de votre choix, et le cloud infogéré peut fonctionner sur la plateforme propre de Vonahost ou dans des régions AWS et Google Cloud, ce qui est utile lorsqu’une architecture exige des cellules régionales ou un site de reprise après sinistre dans une juridiction précise.

Chaque proposition Vonahost indique la configuration, l’emplacement, les responsabilités et le prix mensuel en dollars américains, de sorte que les décisions de placement issues de votre revue d’architecture sont inscrites dans la commande elle-même. Les conclusions juridiques restent du ressort de votre conseil juridique.