Une PME du Genevois répond à un appel d'offres pour un client suisse. Le questionnaire comporte une question apparemment simple : où sont hébergées les données que vous traiterez pour notre compte ? Le dirigeant transmet la question à son prestataire, qui répond que l'application est « en Europe ». En vérifiant réellement, nous constatons que la base de données se trouve bien dans une région européenne, que les sauvegardes ont été configurées dans une autre région choisie par défaut lors d'une installation, que les journaux d'application partent chez un éditeur tiers, et que le service d'envoi des e-mails de notification se trouve encore ailleurs. Aucune de ces décisions n'a été prise consciemment.
C'est la situation la plus fréquente que nous rencontrons sur ce sujet. La région n'est presque jamais choisie : elle est héritée du premier clic, souvent celui d'une maquette devenue production. Or la région est une décision d'architecture, avec des conséquences sur vos engagements contractuels, sur votre structure de coût et sur la difficulté d'un changement ultérieur.
Ce qu'une région désigne exactement chez un fournisseur cloud
Une région est un ensemble de centres de données situés dans une même zone géographique, généralement répartis en plusieurs zones de disponibilité indépendantes en électricité et en réseau. Vous choisissez la région à la création de chaque ressource, et ce choix détermine l'emplacement physique des serveurs et des disques concernés.
Deux propriétés de ce découpage sont mal connues et méritent d'être retenues. D'abord, les services d'un fournisseur ne sont pas déployés partout au même rythme : tous les services ne sont pas ouverts dans toutes les régions, et un service peut y arriver plus tard. Ensuite, la structure de facturation varie d'une région à l'autre, car le prix des ressources et celui du transfert de données ne sont pas uniformes. Ces deux points interdisent de raisonner sur des souvenirs ou sur un article ancien : la disponibilité de la région et celle des services que vous comptez y utiliser se vérifient dans la documentation du fournisseur, au moment du projet. C'est un point de contrôle systématique de notre cadrage, quel que soit le fournisseur retenu selon les critères que nous décrivons dans notre article sur le choix entre AWS, Azure et GCP.
Les éléments qui quittent la région sans que personne l'ait décidé
Choisir correctement la région de vos machines ne suffit pas, car une plateforme comporte toujours des composants périphériques dont l'emplacement se règle séparément. Voici ceux que nous trouvons le plus souvent en dehors du périmètre annoncé.
- Les sauvegardes sont conservées dans une région différente, parfois par une option de réplication géographique activée sans que le dirigeant en ait connaissance. Cette réplication est une bonne pratique de résilience, mais elle doit être choisie et documentée, pas subie.
- Les journaux applicatifs et les traces d'erreurs sont envoyés à un service tiers, souvent gratuit au démarrage, dont l'infrastructure se trouve ailleurs. Ces journaux contiennent régulièrement des adresses de messagerie et des identifiants de clients.
- Le service d'envoi des e-mails transactionnels, la plateforme de mesure d'audience et le réseau de diffusion de contenu conservent chacun leurs propres données techniques, dans leurs propres emplacements.
- Les sauvegardes de vos services en ligne suivent la logique de l'éditeur, pas la vôtre, question que nous traitons dans notre article sur la sauvegarde d'un service en ligne hors de l'éditeur.
- Les accès d'administration de vos prestataires comptent également : une équipe qui administre la plateforme depuis un autre continent accède aux données, même si les disques ne bougent pas.
Écrire l'exigence avant de choisir un emplacement
Nous distinguons deux situations, et cette distinction évite beaucoup de dépenses inutiles. Dans la première, votre entreprise a une obligation écrite : un contrat client, un cahier des charges d'appel d'offres, une politique de groupe ou une exigence de votre secteur imposent que certaines données restent dans un pays ou dans une zone déterminée. Dans la seconde, vous avez une préférence, souvent formulée comme « nous préférerions la Suisse », qui n'a jamais été écrite et dont personne ne connaît le périmètre exact.
Une préférence ne se traduit pas en architecture. Une exigence écrite, si. Nous demandons donc que la contrainte soit formulée précisément : quelles catégories de données sont concernées, la production seulement ou également les copies, les journaux comptent-ils, quels prestataires peuvent y accéder et depuis où. Une phrase de ce type se vérifie, se documente et se prouve lors d'un audit client.
La qualification juridique de votre obligation, en revanche, ne relève pas de nous. Les textes applicables, la nature des données personnelles concernées et les clauses à faire signer à vos sous-traitants relèvent d'un conseil juridique spécialisé, en France comme en Suisse. Notre travail consiste à traduire l'exigence validée en configuration vérifiable et à vous dire ce qu'elle coûte en jours et en fonctionnement.
Changer de région n'est pas une option à cocher dans une console
C'est le point que nous devons expliquer le plus souvent, parce que l'interface donne l'illusion du contraire. Une ressource existe dans une région et n'en change pas : déplacer une plateforme revient à en construire une nouvelle ailleurs, à y transférer les données, puis à basculer les accès. En pratique, cela suppose de recréer les réseaux et les règles de filtrage, de redéployer les machines et les services, de copier des volumes qui se comptent parfois en centaines de gigaoctets, de refaire les certificats, de modifier les entrées de nom de domaine et de prévoir une fenêtre de bascule avec un retour arrière possible.
Le transfert de données entre régions est lui aussi facturé, ce qui rend la note de la migration sensible au volume déplacé. Nous chiffrons donc ce déplacement avant de le promettre, plutôt que d'annoncer une bascule immédiate. Notre article sur la facture cloud qui augmente explique comment ces flux se lisent, et notre offre de migration cloud encadre l'opération elle même.
Notre méthode : cartographier avant de recommander une région
Nous produisons d'abord un inventaire de tous les composants qui traitent ou stockent des données pour votre activité, en indiquant pour chacun son emplacement réel, son responsable et la nature des données concernées. Cet inventaire tient sur une page et il vaut mieux qu'une longue discussion, parce qu'il rend visibles les composants oubliés.
Nous confrontons ensuite cet inventaire à votre exigence écrite, puis nous proposons une architecture cible : la région de production, l'emplacement des copies, ce qui doit être rapatrié et ce qui peut rester où il est. Nous vérifions à ce moment la disponibilité effective des services dans la région envisagée, ainsi que les fonctions qui manqueraient. Nous documentons enfin la configuration retenue, afin que votre réponse au prochain questionnaire client soit factuelle et vérifiable.
Selon les cas, la conclusion n'est pas toujours un fournisseur public. Une plateforme privée sur laquelle vous gardez la main peut mieux répondre à une exigence stricte, et nous décrivons cette voie dans notre article sur les données en Suisse et le cloud privé. À l'inverse, un site vitrine ne pose pas ce problème : le choix de son hébergeur suffit, comme nous l'expliquons dans notre article sur l'hébergement d'un site en Suisse ou en France.
Ces missions de cadrage et de migration se facturent 1000 HT / jour, à distance, pour des clients de toute la France et de Suisse, avec le même montant hors taxes en euros et en francs.
Si votre contrat impose une localisation et que vous ne pouvez pas prouver où se trouvent aujourd'hui vos sauvegardes et vos journaux, envoyez-nous la clause concernée. Nous établissons la cartographie réelle, puis nous vous indiquons ce qui doit se déplacer, ce que cela coûte et dans quel ordre le faire.