2 La résidence des données dans le SaaS est passée d’une demande occasionnelle de grands comptes à une exigence d’achat standard. Les clients européens demandent que leurs données restent dans l’UE ou dans leur propre pays. Les acheteurs publics en France, en Allemagne, au Royaume-Uni, au Japon et dans les pays du Golfe exigent souvent un hébergement national. Partout, les secteurs réglementés veulent des réponses claires sur l’emplacement de leurs données, de leurs sauvegardes et de leurs journaux, et sur les personnes qui peuvent y accéder. Pour les éditeurs SaaS, proposer une résidence régionale est désormais une condition pour remporter les gros contrats, et c’est l’architecture qui détermine si elle devient un avantage concurrentiel ou une charge opérationnelle. Cet article explique comment les éditeurs SaaS conçoivent la résidence régionale des données, quelles données doivent rester dans la région, comment les exigences varient selon les pays et comment exploiter efficacement plusieurs régions. Pour la vision d’ensemble du stockage de fichiers, consultez notre article SaaS file storage (en anglais). Ce que les clients entendent par résidence Les exigences des clients varient, mais comprennent généralement : L’emplacement des données principales : là où sont stockés les enregistrements et fichiers du client. Les sauvegardes et répliques : là où sont conservées les copies, un point que les clients négligent souvent jusqu’à ce qu’une revue de sécurité le soulève. Le lieu de traitement : là où les données sont traitées, y compris pour l’analytique et les fonctionnalités d’IA. Les métadonnées et journaux : là où sont stockés journaux d’usage, journaux d’audit, index de recherche et télémétrie. L’accès du support : qui peut accéder aux données, depuis quels pays et avec quels contrôles. Les sous-traitants : quels tiers traitent les données, et où. La résidence est liée à la souveraineté, sans se confondre avec elle : la souveraineté concerne les lois applicables et les autorités qui peuvent exiger un accès. Les exigences par région Union européenne : le RGPD encadre les transferts hors de l’EEE en l’absence de garanties. De nombreux clients demandent un traitement exclusivement dans l’UE comme engagement contractuel, et certains organismes publics exigent un hébergement national. Allemagne : le secteur public et les clients réglementés attendent souvent une attestation C5 du BSI et des datacenters allemands. France : le secteur public sensible et les opérateurs critiques peuvent exiger des services qualifiés SecNumCloud par l’ANSSI. Royaume-Uni : le UK GDPR s’applique, et les acheteurs publics préfèrent souvent un hébergement britannique. Japon : les clients peuvent attendre un hébergement national au regard de l’APPI, et les acheteurs publics recherchent des services enregistrés ISMAP. Moyen-Orient : les Émirats arabes unis, l’Arabie saoudite et d’autres exigent un stockage national pour certaines données publiques, de santé et financières. États-Unis : les clients fédéraux exigent des services autorisés, et certaines données doivent rester aux États-Unis avec du personnel basé sur place. Autres marchés : l’Australie, le Canada, l’Inde et d’autres ont leurs propres programmes de cloud public et règles sectorielles. Les modèles d’architecture Les cellules régionales L’approche la plus robuste déploie une copie complète de la pile applicative, souvent appelée cellule ou pod, dans chaque région : serveurs applicatifs, bases de données, stockage objet, recherche, files de messages et caches. Chaque locataire est rattaché à une cellule, et toutes ses données y restent. Les cellules sont indépendantes, ce qui limite aussi le rayon d’impact des incidents. Un plan de contrôle global et des plans de données régionaux Un petit plan de contrôle global gère l’inscription, le routage et la facturation, tandis que toutes les données clients résident dans des plans de données régionaux. Le plan de contrôle doit contenir le moins possible de données clients, puisque tout ce qu’il stocke est par définition global. Rattachement et routage des locataires Chaque locataire est rattaché à une région dès sa création, et les requêtes sont acheminées vers la bonne région selon le domaine du locataire, sa connexion ou une recherche dans un annuaire. Déplacer un locataire d’une région à l’autre devient une migration délibérée, avec vérification. Le stockage objet régional Les fichiers des clients résident dans un stockage objet propre à chaque région, avec des buckets ou comptes par région et une réplication limitée à d’autres sites de la même région. Un stockage compatible S3 permet au même code applicatif de fonctionner sur des régions d’hyperscalers, chez des fournisseurs cloud locaux ou sur la propre infrastructure de l’éditeur, selon l’endroit où les régions sont nécessaires. Les données que l’on oublie facilement Les programmes de résidence échouent souvent sur les données secondaires : Les sauvegardes répliquées par défaut sur un autre continent. Les journaux et la télémétrie envoyés vers une plateforme d’observabilité centrale. Les index de recherche construits dans un cluster central. Les fonctionnalités d’IA qui envoient des contenus à des modèles hébergés ailleurs. Les outils de support qui copient des données clients dans les tickets. Les pipelines analytiques qui agrègent des données entre régions. Auditez chaque flux de données et décidez ce qui est autorisé à quitter chaque région, le cas échéant. Le blog scality.com traite de la résidence des métadonnées (en anglais) et des frontières de la télémétrie de stockage (en anglais). D’où viennent les régions Les éditeurs peuvent construire leurs régions sur des régions cloud d’hyperscalers, chez des fournisseurs nationaux ou de cloud souverain (en anglais), dans des centres de colocation avec leur propre infrastructure, ou combiner ces options. Les régions d’hyperscalers sont pratiques mais ne sont pas disponibles dans tous les pays, et certains clients préfèrent des fournisseurs locaux pour des raisons de souveraineté. Exploiter un stockage objet compatible S3 en colocation permet d’ouvrir des régions là où les hyperscalers sont absents ou là où les clients exigent des opérateurs nationaux. Exploiter de nombreuses régions L’automatisation Chaque région doit être déployée et mise à jour avec la même automatisation, afin que les régions restent cohérentes et que de nouvelles puissent être ajoutées rapidement. La planification de capacité par région La croissance varie selon les régions. Planifiez stockage et calcul séparément pour chacune, et évitez les régions trop petites pour être exploitées efficacement. La résilience au sein de la région Les clients attendent à la fois la résidence et la disponibilité. Utilisez plusieurs sites ou zones de disponibilité dans chaque région, avec une réplication qui reste dans la région. Le modèle de support Définissez les contrôles d’accès du support (en anglais) : équipes de support régionales, accès juste-à-temps, approbation du client pour tout accès et journalisation de chaque action. Le coût Chaque région ajoute des coûts fixes. Tarifez les options de résidence en conséquence, par exemple avec un supplément pour les régions dédiées ou nationales, et concevez les services partagés pour réduire au minimum les coûts par région. Fonctionnalités d’IA et résidence Les fonctionnalités d’IA générative sont devenues un nouveau défi de résidence. Les fonctions de résumé, de recherche et d’assistant peuvent envoyer des contenus clients à des modèles hébergés dans d’autres régions ou par des tiers. Les clients soumis à des exigences de résidence demandent de plus en plus où sont traités et stockés les prompts, documents et embeddings, et si les données servent à l’entraînement. Les options comprennent l’hébergement des modèles dans chaque région, l’usage de points d’accès régionaux de fournisseurs de modèles qui s’engagent à traiter dans la région, la possibilité pour les locataires de désactiver l’IA, ou une offre d’IA limitée aux régions où le traitement peut rester local. Les embeddings et index vectoriels dérivés des contenus clients doivent suivre les mêmes règles de résidence que les contenus eux-mêmes. Choisir les régions à proposer Tous les pays ne justifient pas une région dédiée. Les éditeurs commencent généralement par un petit ensemble, comme les États-Unis, l’UE et un ou deux grands marchés nationaux, puis ajoutent des régions là où le chiffre d’affaires, la réglementation et la demande des clients justifient le coût fixe. Certains proposent des déploiements dédiés mono-locataires aux clients très importants ou très réglementés plutôt que des régions partagées complètes. Suivez les affaires perdues et les exigences d’achat par pays pour décider où ouvrir la prochaine région. Contrats et preuves Les clients veulent des engagements de résidence dans les contrats et les accords de traitement des données, ainsi que des preuves : documentation d’architecture, listes de sous-traitants avec leur localisation, certifications et rapports d’audit. Faites de la résidence une propriété documentée et vérifiable de la plateforme, et non une simple promesse. Migrer les clients existants Lorsqu’une nouvelle région ouvre, des clients existants peuvent demander à y être déplacés. La migration d’un locataire implique de copier bases de données et fichiers, de vérifier chaque objet, de basculer le routage et de supprimer les données de l’ancienne région, preuves à l’appui. Construisez tôt les outils de migration de locataires : ils serviront régulièrement. Tester la résidence Vérifiez périodiquement la résidence dans les faits : retracez où atterrissent réellement les données, sauvegardes, journaux et index d’un locataire de test, examinez le trafic sortant de chaque région et confirmez que les journaux d’accès du support correspondent à la politique. Traitez tout flux inattendu comme un incident à corriger. Checklist : résidence des données SaaS Définissez quels types de données doivent rester dans la région, sauvegardes, journaux et index compris. Choisissez des cellules régionales ou un plan de données régional avec un plan de contrôle global minimal. Rattachez les locataires à des régions et routez les requêtes en conséquence. Utilisez un stockage objet régional avec réplication dans la région. Auditez les flux de données secondaires, les fonctionnalités d’IA et les outils de support. Ouvrez des régions là où les clients en ont besoin, y compris en colocation. Automatisez le déploiement et les mises à jour de toutes les régions. Contrôlez et journalisez l’accès du support. Inscrivez la résidence dans les contrats et fournissez des preuves. Construisez des outils de migration de locataires. En résumé La résidence des données SaaS fonctionne lorsqu’elle est intégrée à l’architecture plutôt qu’ajoutée après coup : cellules régionales, rattachement des locataires, stockage objet régional et contrôle strict des sauvegardes, des journaux, des fonctionnalités d’IA et de l’accès du support. Les exigences varient entre l’UE, l’Allemagne, la France, le Royaume-Uni, le Japon, le Moyen-Orient et les États-Unis, mais partout les clients veulent des engagements clairs et des preuves. Un stockage compatible S3 permet d’ouvrir des régions chez des hyperscalers, des fournisseurs locaux ou sur sa propre infrastructure, avec le même code applicatif. Questions fréquentes Qu’est-ce que la résidence des données dans le SaaS ? Un engagement selon lequel les données d’un client, sauvegardes et journaux compris, sont stockées et traitées dans un pays ou une région déterminés. Comment les éditeurs SaaS gardent-ils les données dans une région ? En déployant des cellules régionales, en rattachant les locataires à des régions, en utilisant un stockage régional et en contrôlant les flux de données secondaires. Les sauvegardes comptent-elles pour la résidence des données ? Oui. Clients et régulateurs attendent généralement que les sauvegardes et répliques restent dans la région convenue. Que faire si un hyperscaler n’a pas de région dans un pays ? Les éditeurs peuvent recourir à des fournisseurs cloud locaux ou exploiter un stockage objet compatible S3 en colocation pour y ouvrir une région. Comment les éditeurs prouvent-ils la résidence ? Par des engagements contractuels, une documentation d’architecture, des listes de sous-traitants, des certifications et des rapports d’audit. Pour aller plus loin SaaS file storage (en anglais) Stockage cloud personnel des opérateurs Synchronisation et partage de fichiers auto-hébergés Stockage des photos et vidéos grand public Data sovereignty vs data residency (en anglais)
