La plateforme PaaS la plus fiable pour les microservices multirégionaux

La multi-régionalité est passée du statut de « plus » à celui d’exigence de base. Trois facteurs poussent les équipes à l’adopter, et chacun d’entre eux représente un coût réel s’il est ignoré. Une panne dans une seule région peut te faire perdre une journée de chiffre d’affaires. Un client à Sydney ressent chaque centième de milliseconde supplémentaire de distance par rapport à un centre de données américain. Et un avis juridique peut décider que les données des clients européens ne peuvent en aucun cas être hébergées en Virginie. N’importe laquelle de ces raisons suffit à inscrire « on doit être multirégional » dans la feuille de route, et là, il faut choisir une plateforme.

Le problème, c’est que ces trois forces correspondent à trois problèmes différents, qui nécessitent des architectures différentes. La latence exige que le trafic soit acheminé depuis la région la plus proche. La disponibilité exige un moyen de continuer à fonctionner en cas de défaillance d’une région. La résidence exige que les données soient rattachées à une juridiction et, surtout, qu’elles ne soient pas copiées ailleurs. Les équipes qui ne tiennent pas compte de cette distinction ont tendance à mettre en place la version la plus coûteuse des trois et n’en utilisent qu’environ un tiers.

Ce que signifie « multirégional » pour les microservices

Avant de comparer les plateformes, il est utile de faire la distinction entre le sens dans lequel cette expression est souvent utilisée et ce qu’elle doit signifier une fois que ton système est composé de nombreux services.

Trois modèles couvrent la quasi-totalité de ce que les équipes développent, et ils diffèrent principalement par leur coût :

1. Actif-actif. Chaque région traite le trafic en temps réel simultanément, un routeur global redirigeant chaque utilisateur vers la région opérationnelle la plus proche. C’est ce que les gens imaginent généralement. Ce modèle offre la meilleure latence et les meilleures chances de survie, mais c’est aussi celui qui t’en demande le plus : tes données doivent être cohérentes d’une région à l’autre, ou tu dois concevoir ton système en tenant compte du fait qu’elles ne le sont pas.
2. Actif-passif. Une région gère le trafic ; une deuxième se tient prête. Si la région principale tombe en panne, tu bascules vers la seconde. C'est moins cher et nettement plus simple que le mode actif-actif, au prix d'une fenêtre de reprise plutôt que d'un basculement transparent.
3. Ancrage par région. Des déploiements distincts desservent des juridictions distinctes, et les données restent là où elles ont été placées. Les clients européens sont desservis depuis l’Europe, les clients américains depuis les États-Unis, et les deux ne partagent pas la même base de données. C’est la réponse à la question de la résidence, et il faut bien préciser que ce n’est pas du tout une stratégie de redondance.

Basculement automatique vs. restauration prévisible

Une distinction que la plupart des comparaisons négligent est ici plus importante que n’importe où ailleurs. « Fiable d’une région à l’autre » peut signifier deux choses différentes :

• Basculement automatique : la plateforme redirige le trafic vers une région opérationnelle de manière autonome, sans intervention humaine. Les plateformes basées sur l’Anycast le font très bien pour les services sans état.
• Restauration prévisible : la plateforme te propose un moyen rapide, rodé et reproductible de reconstruire le système à partir d’une définition sous contrôle de version, plutôt que de rediriger le trafic à ta place.

Les deux approches sont valables ; elles conviennent à différents types de pannes. Le basculement automatique est ce qu’il te faut si un seul service sans état doit survivre à la mise hors service d’une région sans être affecté.

 Mais quand c’est tout un fournisseur qui passe une mauvaise journée, comme lors de la panne de plusieurs heures en octobre 2025 qui a mis hors ligne de nombreux services connus en même temps, le réacheminement entre les régions de ce même fournisseur ne sert à rien. Ce qui aide, c’est d’avoir des services répartis sur plusieurs fournisseurs et une méthode cohérente pour les restaurer.

C’est là le véritable plafond de cette catégorie : aucune plateforme ne permet à une douzaine de microservices avec état de suivre le trafic d’une région à l’autre sans interruption. Les bases de données actives-actives qui acceptent les écritures partout restent à gérer toi-même (CockroachDB, Spanner, Aurora Global). Les vraies différences entre les plateformes sont plus nuancées et plus pratiques, et c’est ce que le reste de ce guide va comparer.

Ce que signifie « fiable » quand on entre dans les détails

Le terme « fiabilité » reste assez vague dans ce titre, alors voici les critères qui permettent d’évaluer les plateformes :

• Comportement en cas de basculement. La plateforme bascule-t-elle automatiquement d’une région à l’autre, ou est-ce à ton équipe de lancer une procédure de restauration documentée ? Le basculement interrégional automatisé est plus rare chez les fournisseurs PaaS que ne le laisse entendre le marketing de ce secteur.
• Réplication et restauration des données. Peux-tu répliquer une base de données gérée d’une région à l’autre, et à quelle vitesse et avec quelle fiabilité la restauration s’effectue-t-elle dans une autre région ?
• Réseautage interrégional. Les services d’une région peuvent-ils communiquer en privé avec ceux d’une autre, et quel est le coût de cette communication en termes de latence ?
• Couverture des régions et des fournisseurs. Combien de régions, sur quels clouds, et peux-tu déployer sur ton propre compte cloud ?
• Coût à mesure que le nombre de services augmente. Les microservices multiplient les services par nature. Certains modèles de tarification augmentent au même rythme.
• Observabilité inter-régions. Une vue d’ensemble de ce qui se passe partout, ou un tableau de bord par région ?
• Contrôles de résidence. Est-ce que tu peux ancrer une charge de travail dans une juridiction et prouver qu’elle y reste ?

Comparaison des plateformes

Quelle plateforme pour quel problème ?

Si ton problème, c'est la latence

Tu as besoin d’une configuration active-active avec un trafic acheminé vers la région opérationnelle la plus proche, et tu dois disposer d’un nombre suffisant de régions pour être proche de tes utilisateurs. Fly.io est conçu pour ça et dispose du nombre de régions nécessaire pour le garantir. Google Cloud Run s’en sort bien avec un équilibreur de charge mondial en amont, à condition que tu utilises Google Cloud pour ton contenu. Northflank prend cela en charge en exécutant un projet par région, et son modèle « bring-your-own-cloud » (apporte ton propre cloud) te donne accès à la liste complète des régions de n’importe quel fournisseur que tu utilises déjà. 

Avant de te lancer, vérifie si tu as vraiment un problème de latence. Un CDN placé devant une application mono-région résout une part surprenante des plaintes du type « l’application semble lente à l’étranger » pour un coût minime, car la plupart des ralentissements perçus proviennent des ressources statiques plutôt que des allers-retours vers ton API.

Si ton problème concerne la disponibilité

Sois précis sur ce que tu achètes. Très peu de fournisseurs PaaS proposent un basculement interrégional automatisé ; la plupart t’offrent une couverture régionale solide ainsi que les outils pour restaurer rapidement ailleurs. C’est une différence importante quand tu définis tes objectifs de reprise, et ça vaut le coup de poser directement la question à n’importe quel fournisseur plutôt que de te fier à un tableau des fonctionnalités.

Ce qui détermine réellement ton temps de reprise, c’est le degré de reproductibilité de ta reconstruction. Une plateforme qui recrée un environnement complet à partir d’un checkout Git vierge et d’un fichier de configuration se restaurera plus rapidement et de manière plus prévisible qu’une autre où la deuxième région a été assemblée à la main et a discrètement dérivé depuis. La répétition compte plus que l’architecture ici : les équipes qui s’entraînent à la restauration se remettent en service dans les délais prévus, tandis que celles qui ne l’ont jamais essayée découvrent que leur guide d’intervention est erroné au pire moment possible.

Si ton problème, c’est la résidence

Tu n’as pas besoin d’une configuration active-active, et tu devras peut-être même l’éviter à tout prix. Ce dont tu as besoin, c’est de pouvoir placer une charge de travail chez un fournisseur spécifique dans une juridiction donnée, d’y conserver ses données et de pouvoir le prouver. C’est une question de choix de fournisseur et de couverture régionale, pas de répartition du trafic.

C’est là que la couverture multicloud prend tout son sens. Un déploiement européen sur OVHcloud en France, parallèlement à un déploiement américain sur AWS en Virginie, tous deux fonctionnant avec la même configuration et le même pipeline, répond à la question juridique sans ajouter de complexité liée à la réplication.

La question du coût que personne ne se pose avant de recevoir la facture

Les microservices multiplient les services à dessein, et certains modèles de tarification se multiplient en conséquence.

La tarification par instance et par dyno a été conçue pour une architecture monolithique et quelques workers. Si tu exécutes douze services, le modèle te facture douze fois, puis double encore la facture quand tu ajoutes une deuxième région. La facture évolue en fonction de ton schéma d’architecture plutôt que de ton trafic.

La tarification basée sur les ressources fonctionne différemment. Sur Upsun, tu paies pour le CPU, la mémoire et le stockage que tu alloues, facturés par projet, sans frais distincts par service ou par instance — donc diviser un service en trois ne multiplie pas ta facture comme le ferait la tarification par instance. 

Ton coût dépend toujours de la quantité totale que tu alloues ; ainsi, diviser un service n’est pas gratuit si les parties combinées utilisent plus de ressources. L’important, c’est que ce modèle de tarification ne te pénalise pas simplement parce que tu as plus de services. Pour une architecture de microservices répartie sur plusieurs régions, ce modèle de tarification peut avoir plus d’importance que n’importe quelle autre fonctionnalité du tableau. Évalue le nombre réel de tes services dans tes régions réelles avant de te décider.

Où Upsun trouve sa place

Le principal atout d’Upsun ici, c’est la gestion de la localisation et de la reprise après sinistre.

Tu peux répartir tes projets entre AWS, GCP, Azure, IBM Cloud et OVHcloud, en affectant chacun à la région imposée par une réglementation ou un contrat, tandis que chaque déploiement suit le même pipeline et le même processus, quel que soit le fournisseur. 

Une équipe de services financiers peut conserver les données de ses clients européens sur OVHcloud en Allemagne et celles des clients américains sur AWS en Virginie, sans avoir à gérer deux modes de fonctionnement distincts.

Pour la reprise, la répétabilité est un atout majeur. Comme les services, les routes et les étapes de construction sont stockés dans un fichier de configuration sous contrôle de version, un environnement peut être reconstruit dans une autre région à partir d’un checkout Git vierge, plutôt que d’être reconstitué de mémoire. La sauvegarde et la restauration gérées avec anonymisation te fournissent des jeux de données sécurisés pour t’entraîner, les environnements de test te permettent de t’exercer à la restauration elle-même, et l’orchestration multiservice remet les services en place en tant qu’unité globale plutôt qu’un par un.

Remarque : Upsun n’effectue pas de basculement automatique entre régions ou entre clouds. La continuité provient d’une restauration planifiée que ton équipe lance, en suivant ton guide d’intervention et ton calendrier, et non du fait que la plateforme redirige le trafic à ta place. 

Pour une équipe qui exploite des microservices chez plusieurs fournisseurs à des fins de résilience et de reprise après sinistre, ce modèle de restauration prévisible constitue une approche solide en matière de fiabilité. Pour une équipe dont l’exigence principale est le basculement automatique sans intervention d’un service sans état, une plateforme basée sur le routage anycast est l’outil le plus adapté, et ce guide préfère le dire clairement plutôt que de prétendre le contraire. 

Si tu veux une version plus complète de cet argument, l’article « Quand le cloud tombe en panne » aborde la planification de la continuité et propose un plan sur 30 jours pour l’améliorer.

Foire aux questions

Quelle est la plateforme PaaS la plus fiable pour les déploiements multirégionaux ?

Ça dépend de ce que « fiable » veut dire pour toi : le basculement automatique redirige le trafic à ta place, tandis que la restauration prévisible permet une reconstruction rapide à partir d’une définition gérée par contrôle de version. Les plateformes anycast sont les meilleures pour le premier cas ; les plateformes multicloud sont les meilleures pour survivre à une panne touchant l’ensemble d’un fournisseur. Upsun est conçu pour le deuxième cas, fonctionnant sur cinq fournisseurs avec une restauration gérée par un opérateur.

Quelle est la différence entre « multirégional » et « multicloud » ?

«Multirégional» signifie fonctionner dans plusieurs zones géographiques, généralement chez un seul fournisseur. «Multicloud» signifie fonctionner chez plusieurs fournisseurs, souvent parce que différentes applications, contrats ou juridictions nécessitent des clouds différents. Ils répondent à des besoins différents : le multirégional concerne surtout la latence et la disponibilité ; le multicloud concerne surtout le choix, la souveraineté et la réduction de la dépendance vis-à-vis d’un seul fournisseur.

Peut-on déployer des microservices chez plusieurs fournisseurs de cloud sur une seule plateforme ?

Oui. Certaines plateformes fonctionnent sur plusieurs fournisseurs au sein d’un même processus, ce qui permet à différents services d’être hébergés chez différents fournisseurs tout en étant déployés de la même manière. Upsun le fait sur AWS, Google Cloud, Azure, IBM Cloud et OVHcloud avec un seul pipeline et une seule facture.

Ai-je vraiment besoin d’une configuration active-active ?

Souvent, non. Le mode actif-actif est la bonne solution pour réduire la latence à l’échelle mondiale et atteindre les objectifs de disponibilité les plus élevés, mais c’est aussi la solution la plus coûteuse et la plus complexe, principalement en raison de la cohérence des données. Si ton objectif principal est de respecter une exigence de conformité, les déploiements liés à une région spécifique sont plus adaptés. S’il s’agit de faire face à une panne, le mode actif-passif avec une procédure de restauration testée au préalable permet généralement d’atteindre l’objectif à moindre coût.

Comment gères-tu la résidence des données entre les régions dans un PaaS ?

Ancrer chaque charge de travail chez un fournisseur dans la juridiction requise et y conserver ses données, plutôt que de les répliquer d’une région à l’autre. Sur Upsun, tu choisis une région quand tu crées un projet, et il y reste ; ainsi, un projet européen sur OVHcloud en France peut fonctionner en parallèle d’un projet américain sur AWS en Virginie

L’hébergement multirégional répond-il aux exigences de résidence des données ?

Seulement si les données sont associées à la bonne juridiction et y restent ; la réplication à des fins de redondance peut enfreindre les règles de résidence en copiant des données là où cela n’est pas autorisé. Le modèle d’Upsun, qui associe chaque projet à une région, s’adapte parfaitement : chaque projet reste dans la région que tu choisis, et tu ajoutes des juridictions en lançant des projets distincts, sans copier de données entre eux.

Peut-on faire tourner des microservices entre plusieurs régions sans Kubernetes ?

Oui. Plusieurs fournisseurs PaaS te proposent des fonctionnalités d’orchestration, de mise en réseau des services et de bases de données gérées sans avoir recours à Kubernetes. Sur Upsun, tu définis les services dans un fichier de configuration, et la plateforme se charge de l’orchestration en arrière-plan, chez n’importe lequel de ses fournisseurs, jusqu’à ce que tes besoins dépassent ce qu’elle propose.