Défini par site
Chaque gamme d’hébergement propose son propre ensemble de centres de données. Vous en choisissez un lors de la création d’un site, et le formulaire de commande ne propose qu’une ville où cette gamme dispose de place aujourd’hui.
Régions et résidence des données
Vos sites s’exécutent là où vous le décidez
La région ne fait pas l’objet d’un ticket d’assistance sur cette plateforme : c’est une propriété du site, respectée par le moteur de placement à chaque déploiement. Vous choisissez le centre de données lors de la création d’un site parmi les villes proposées actuellement par sa gamme d’hébergement, et chaque déploiement s’effectue sur la capacité du parc à cet emplacement, avec un réseau edge mondial en amont. Chaque page d’hébergement répertorie ces villes, lues en temps réel.
- 700 000+sites hébergés dans le monde entier
- Vous choisissezle centre de données pour chaque site
- 99,99 %Garantie de disponibilité
- 58Langues du panneau
Où nous opérons
Deux éléments sous-tendent chaque emplacement : le parc d’instances qui fait tourner vos sites et le plan de contrôle qui les gère. Tous deux tiennent compte de la région. Le choix de l’emplacement vous appartient ; la capacité sous-jacente relève de notre propre organisation, et nous travaillons délibérément avec plusieurs fournisseurs afin qu’aucun d’entre eux ne constitue à lui seul la plateforme.
En ligne
Les villes présentes sur chaque page d’hébergement et dans le formulaire de commande sont lues à partir du moteur de placement, de sorte qu’un nouvel emplacement apparaît le jour où il dispose de capacités et qu’un emplacement saturé n’est pas proposé.
Comment fonctionne réellement l’emplacement
La région est appliquée dans le code, au moment de la création d’un site — et non par un opérateur qui se souvient de la boîte à utiliser.
Chaque worker est étiqueté
Chaque hôte du parc s’enregistre avec une clé de région, une liste d’affinité de ligne de produits, un type de serveur web et un chiffre de capacité, puis extrait le travail. Le service de placement filtre d’abord les candidats par région, puis par ligne de produits, ensuite par capacité disponible, et sélectionne l’hôte éligible le moins chargé.
Le site hérite de la région et la conserve
Si vous avez épinglé une région, seuls les workers de cette région sont éligibles. Dans le cas contraire, le site hérite de la région du worker sur lequel il aboutit et cette valeur est stockée sur le site — ainsi, l’enregistrement indiquant où résident vos données est un champ que vous pouvez consulter, et non une supposition.
La capacité est allouée de manière atomique
Le placement réserve de la capacité au moyen d’une mise à jour conditionnelle qui ne réussit que tant que le worker est encore actif, accepte toujours des déploiements et n’a pas atteint sa capacité maximale. Deux déploiements en concurrence pour le dernier emplacement ne peuvent pas l’emporter tous les deux, ce qui garantit qu’une région ne se retrouve jamais discrètement en surcapacité.
Aucun basculement silencieux vers la mauvaise région
Si aucun élément éligible dans votre région ne dispose d’espace, le déploiement génère une erreur de placement et s’arrête. Il ne bascule pas vers un autre continent pour faire aboutir la requête. Un échec visible et un ajout de capacité valent mieux qu’un site qui a changé de pays en silence.
Vidage au lieu d’une interruption
Chaque worker dispose d’un commutateur accepts-deploys. Le basculer sur drain empêche l’arrivée de nouveaux sites tandis que les sites existants continuent de fonctionner sans interruption, ce qui nous permet d’effectuer la maintenance, les renouvellements matériels et les mises hors service au sein d’une région sans déplacer vos charges de travail.
La résidence des données comme décision produit
La résidence des données est l’une des rares décisions d’hébergement réellement difficiles à annuler, c’est pourquoi la plateforme la traite comme une dimension de premier ordre plutôt que comme un simple détail de déploiement. Le choix de résidence du client constitue une donnée d’entrée pour le placement, la région est enregistrée pour le site et le parc de serveurs est balisé en conséquence. C’est ce qui rend une réponse sur la résidence vérifiable plutôt qu’anecdotique.
Le modèle de colocation fonctionne en parallèle. Chaque enregistrement dans le moteur comporte une portée organisationnelle avec la sécurité au niveau des lignes de PostgreSQL appliquée au niveau de la base de données, et la colocation est hiérarchique — une organisation de revendeur au-dessus d’organisations clientes, elles-mêmes au-dessus de sites. La région détermine où se trouvent les données ; la sécurité au niveau des lignes détermine qui peut y accéder. Les deux comptent pour un vérificateur de conformité et aucun des deux n’est facultatif.
L’exportation et l’effacement des données RGPD font partie intégrante de la conception plutôt que d’être un processus d’appoint, et les actions privilégiées et administratives sont consignées dans un journal d’audit. Si le questionnaire de votre acheteur demande où résident les données, qui peut les interroger et ce qui se passe lorsqu’une personne concernée demande leur restitution, ces questions trouveront ici leurs réponses.
Une origine locale n’est que la moitié de l’histoire de la vitesse
Choisir une région proche est utile, mais la majeure parte de la latence ressentie par vos visiteurs est déterminée avant même qu’une requête n’atteigne votre serveur d’origine.
- Cloudflare est placé en première ligne pour tout — CDN, WAF, DNS et protection DDoS — de sorte que les réponses pouvant être mises en cache soient servies depuis la périphérie au plus près du visiteur plutôt que depuis votre région d’origine.
- LSCache s’exécute directement sur le worker en tant que cache de page entière au niveau du serveur avec ESI et purge automatique intelligente, ce qui signifie que la plupart des requêtes WordPress ne sollicitent jamais PHP ni MySQL.
- Un cache d’objets Redis par site élimine les lectures répétées de la base de données pour les requêtes qui parviennent à l’application.
- La purge est coordonnée sur les deux couches à partir d’une seule commande dans le panneau et depuis WordPress via l’extension de cache Zinn®, de sorte qu’une copie edge et une copie d’origine ne divergent jamais après votre publication.
- Les clients Footprint-Free superposent des pools de comptes CDN au sommet : les sites sont répartis entre nos comptes et les vôtres, l’équilibre étant recalculé à partir de l’état du compte en direct au moment du déploiement.
- Nous ne publions aucun test de référence concernant la latence ou le débit, et nous ne prétendons pas qu’une région donnée sera la plus rapide pour votre public. Choisissez la région indiquée par vos visiteurs et vos exigences de conformité, et laissez les couches de mise en cache faire le reste.
Domaines de défaillance, sauvegardes et limites honnêtes
Le multirégion n’a que peu de valeur si tout partage encore le même destin. L’architecture sépare les éléments qui ne doivent pas défaillir ensemble.
Le plan de contrôle et la flotte sont séparés
Le moteur, la base de données, la couche de flux de travail et les tableaux de bord s’exécutent sur leur propre plan de contrôle Kubernetes, de manière totalement distincte du parc de workers qui dessert les sites des clients. Un incident sur le plan de contrôle ne doit pas interrompre les sites des clients, et un incident sur le parc ne doit pas interrompre la plateforme.
Les surfaces publiques sont également indépendantes
Le tableau de bord client, la console d’administration et ce site marketing sont déployés sur Cloudflare indépendamment du cluster du plan de contrôle, de sorte qu’un incident sur la plateforme ne supprime pas également l’endroit où vous vous rendriez pour vous informer à ce sujet.
L’état est hébergé hors plateforme
La page d’état est délibérément hébergée auprès d’un fournisseur différent, dans une autre région. Une page d’état qui s’exécute sur l’infrastructure même qu’elle surveille est inutile précisément au moment où vous en avez besoin.
Sauvegardes immuables, hors site et isolées
Les sauvegardes par site sont immuables et externalisées, enregistrées sur un stockage objet, avec des restaurations testées plutôt que simplement présumées. Les restaurations s’effectuent en un clic depuis le panneau, aux côtés du gestionnaire de fichiers, des domaines, du DNS, du SSL et des journaux.
Ce que nous ne prétendons pas
Nous ne garantissons aucun accord de niveau de service, temps de réponse ou chiffre de latence sur cette page — les conditions de SLA sont convenues par contrat. Le chiffre de 99.99 % associé aux forfaits Footprint-Free est une assurance de disponibilité, un objectif visé, et non un historique mesuré de disponibilité.
Sélection d’une région
En pratique, la décision se résume à quatre questions, et la plupart des clients y répondent en moins d’une minute.
- Avez-vous une obligation contractuelle ou réglementaire de résidence des données ? Si oui, le choix est fait : les clients de l’EU soumis aux obligations du GDPR choisissent un centre de données au sein de l’Union européenne, et nous disposons d’un routage EU nativement conforme au GDPR lorsqu’un contrat l’exige expressément.
- Où se situe le public auprès duquel vous générez réellement des revenus ? Choisissez le centre de données le plus proche de celui-ci parmi les villes proposées dans le formulaire de commande.
- Le service des achats de votre acheteur exige-t-il une plateforme sous-jacente certifiée ? Si une attestation SOC 2 ou ISO 27001 sur l’infrastructure sous-jacente de vos sites est une condition sine qua non, prévenez-nous avant de concevoir votre projet et nous vous affecterons à une capacité qui en dispose.
- Souhaitez-vous répartir votre portefeuille sur plusieurs domaines de défaillance ? Placer les sites dans plusieurs centres de données élimine la concentration sur un site unique.
- Vous hésitez ? Commencez par l’essai sans carte bancaire. Rien ne change au niveau du panneau de configuration, des pilotes ou de l’ensemble des fonctionnalités lorsque vous déploierez ailleurs ultérieurement.
Foire aux questions
Puis-je choisir la région dans laquelle mes sites sont déployés ?
Oui. La région est une entrée pour le moteur de placement, et non une requête traitée hors bande. Épinglez une région et seuls les fleet workers étiquetés pour cette région seront éligibles pour héberger le site ; la région choisie est ensuite enregistrée sur la fiche du site afin que vous puissiez toujours savoir où il s’exécute. Si vous ne la définissez pas, le site hérite de la région du worker sur lequel il aboutit.
Dans quelles régions opérez-vous ?
Cela dépend de la gamme d’hébergement, car chaque gamme fonctionne sur la capacité conçue pour elle. Le formulaire de commande et chaque page d’hébergement répertorient les villes que vous pouvez choisir aujourd’hui, lues en temps réel à partir du moteur de placement, de sorte que cette réponse n’est jamais obsolète. Pour une stricte résidence dans l’EU, choisissez un centre de données au sein de l’Union européenne ; lorsque les achats exigent une plateforme sous-jacente certifiée, nous pouvons effectuer le placement sur une capacité qui répond à ces exigences. Les fournisseurs derrière chaque emplacement relèvent de nos propres accords commerciaux — vous choisissez l’emplacement, pas le fournisseur.
Détenez-vous la certification SOC 2 ou ISO 27001 ?
Non — Zinn Digital® ne détient aujourd’hui aucune certification de conformité en propre, et nous ne prétendrons pas le contraire. Ce que nous pouvons faire, c’est héberger votre charge de travail sur une plateforme sous-jacente qui en dispose, lorsque les exigences d’approvisionnement d’un acheteur font d’une plateforme certifiée sous vos sites une condition indispensable. Par ailleurs, les contrôles propres à la plateforme sont réels et contrôlables : isolation par site, sécurité au niveau des lignes sur chaque table dédiée aux locataires, secrets conservés dans Vault, TLS de bout en bout et journalisation d’audit des actions privilégiées.
Que se passe-t-il si la région souhaitée n’a plus de capacité disponible ?
Le déploiement échoue visiblement avec une erreur de placement plutôt que d’installer silencieusement votre site ailleurs. C’est délibéré : un site qui a discrètement changé de juridiction est un bien pire résultat qu’un déploiement qui s’est arrêté et vous en a indiqué la raison. De la capacité est ajoutée en mettant en ligne davantage d’hôtes dans cette région, où ils s’enregistrent eux-mêmes et commencent immédiatement à accepter du travail.
Mon site sera-t-il lent pour les visiteurs éloignés de son centre de données ?
Nous ne publions pas de tests de latence et nous ne promettrons aucun chiffre précis. Ce que nous pouvons décrire, c’est l’architecture : Cloudflare est placé en amont de chaque site afin que les réponses pouvant être mises en cache soient servies depuis un emplacement en périphérie (edge) proche du visiteur, LSCache sert des pages entières à partir du worker sans toucher à PHP ni à la base de données, et un cache d’objets Redis par site absorbe les requêtes répétées. Pour la plupart des sites de contenu, cette combinaison signifie que la région d’origine importe bien moins que la configuration du cache. Si votre public est concentré sur un seul continent, placez l’origine là-bas malgré tout.
Puis-je déplacer ultérieurement un site existant vers une autre région ?
La région est définie lors du déploiement d’un site et enregistrée dans sa fiche, de sorte qu’un changement de région constitue une migration et non une simple activation. Contactez-nous avant de lancer le développement si vous prévoyez déjà un déplacement : il est bien plus économique de choisir le bon emplacement dès le départ que de transférer un portefeuille actif.
Où sont conservées mes sauvegardes ?
Les sauvegardes par site sont immuables, externalisées et isolées de la flotte en production, écrites sur un stockage objet avec des restaurations testées plutôt que présumées, et restaurables en un clic depuis le panneau de configuration. Si vos contraintes de conformité exigent que le stockage des sauvegardes réside dans une juridiction spécifique, faites-en part directement à notre équipe — il s’agit d’un détail contractuel que nous convenons par client plutôt que d’une affirmation générale affichée sur une page web.
Puis-je l’essayer sans m’engager sur une région ?
Oui. La période d’essai est de 14 jours et sans carte bancaire. Elle couvre Footprint-Free Hosting avec un maximum de cinq sites, ce qui est suffisant pour voir comment se comportent les déploiements, le positionnement et les couches de cache avant de décider où votre portefeuille de production doit être hébergé.
Connexe
Commencez là où cela a du sens, évoluez quand cela compte
Lancez un essai de 14 jours sans carte bancaire, ou faites-nous part d’abord de vos exigences en matière de résidence et nous vous positionnerons correctement dès le premier déploiement.
Commencer gratuitement