Votre application fonctionne bien, mais l'architecture n'est plus un sujet académique. Les billets de support d'Asie mentionnent des écrans lents. Un incident de cloud régional a forcé tout le monde dans la même salle de guerre. Le produit souhaite une confiance accrue dans le déploiement mobile plus rapide car un déploiement backend malheureux arrive maintenant au même moment qu'une nouvelle mise à jour d'applications, et personne ne peut dire si le problème est une latence API, un client obsolète ou une dépendance régionale échouée.
C'est généralement le moment où les équipes commencent à dire « nous avons besoin de multi-région ». Parfois, ils ont raison. Parfois, ils vont acheter beaucoup de complexité qu'ils ne nécessitent pas.
La mise en œuvre dans plusieurs régions n'est pas un signe de maturité. Il s'agit d'une décision commerciale avec des conséquences pour l'infrastructure, l'ingénierie de la mise en production, l'observabilité, la réponse aux incidents et la livraison d'applications mobiles. Si vous exécutez une application Capacitor ou Ionic, les douleurs apparaissent rapidement. Les utilisateurs ne s'intéressent pas à savoir si le problème était Route 53, un réplica en retard ou un ensemble d'actualisations qui a atteint l'Europe avant l'APAC. Ils s'inquiètent que l'application fonctionnait hier et se sente brisée maintenant.
La bonne nouvelle est que ces problèmes sont prévisibles. Ils apparaissent généralement après le produit marché, après une utilisation internationale, ou après que les engagements de fiabilité sont écrits dans les contrats. Si vous diagnostiquez des requêtes lentes, il est utile de comprendre ce que la latence de réseau est avant de redessiner l'ensemble de la plateforme.
Table des matières
- context : Page/zone : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément de menu court. Vu dans : page blog/[slug].astro. Clé de message `table_of_contents` (Table des matières).
- Introduction Au-delà des limites d'une région
- Là où les développeurs la ressentent en premier
- Comparaison des architectures multi-régions courantes
- Les coûts cachés et les compromis critiques
- Guide de mise en œuvre et meilleures pratiques
- Conclusion : Construire un pied-à-terre global résilient
Introduction : Au-delà des limites d'une région unique
Une seule région est souvent la bonne réponse au début. Cela simplifie la mise en œuvre, réduit les modes de failure et donne à l'équipe un endroit clair pour déboguer. La plupart des applications peuvent aller loin avec une région unique bien ajustée, un CDN, une bonne mise en cache et une mise en index de base de données sensée. C'est la vérité discrète que de nombreuses équipes ignorent lorsqu'elles passent directement à l'architecture mondiale.
Le point de rupture est généralement opérationnel, et non idéologique. Une panne dans votre seule région peut transformer une journée de déploiement routine en un problème de confiance des clients. Un groupe d'utilisateurs éloignés de votre calcul peut transformer chaque rafraîchissement mobile, connexion ou paiement en un ticket de support en ralenti. À ce stade, le déploiement multi-région cesse d'être un « modèle d'architecture agréable » et devient une question de savoir si l'entreprise peut accepter un risque concentré.
Le déploiement multi-région ne se justifie que lorsque la panne d'une géographie est inacceptable pour l'entreprise, le contrat ou le régulateur.
There’s also a delivery angle that infrastructure diagrams rarely show. Mobile teams don’t ship only backend code. They ship APIs, update bundles, config changes, feature flags, and content. In a single region, the path from CI to user device is easier to reason about. In multiple regions, you now have to answer harder questions:
- Quelle région a reçu la mise à jour en premier : et était-ce intentionnel ?
- Quelle version de l'application appelle quelle forme de backend : Quand le timing de la mise en production diffère par région géographique ?
- Quelle expérience utilisateur a échoué : En raison de l'ensemble de l'application, de la région API ou de la couche de routage ?
Par conséquent, le premier projet multi-région ne doit pas commencer par « ajouter plus de régions ». Il devrait commencer par « quels problèmes résolvons-nous et quel nouveau fardeau opérationnel sommes-nous prêts à assumer ? »
Qu'est-ce que le déploiement multi-région ?
Le déploiement multi-région consiste à exécuter des parties significatives de votre système dans plus d'une région cloud géographique, afin que les utilisateurs, le trafic et les pannes ne soient pas tous liés à une seule localisation.
Cela semble évident, mais les équipes ont souvent confondu trois objectifs séparés. Elles veulent une latence plus faible, une résilience meilleure et une localité de données plus claire. Ces objectifs se chevauchent, mais ils n'exigent pas toujours le même design. Si vous n'avez besoin que d'une livraison plus rapide des actifs statiques, un CDN peut faire la plupart du travail. Si vous avez besoin de survivabilité régionale ou de stockage de données local, vous êtes dans une catégorie entièrement différente.
L'analogie de l'entrepôt est suffisamment proche pour être utile
Imaginez votre application comme une entreprise de commerce électronique avec un entrepôt. Si cet entrepôt se trouve aux États-Unis, les clients d'Europe et d'Asie attendent plus longtemps, le coût du transport augmente et un désastre local peut bloquer l'ensemble de l'entreprise. L'ouverture d'entrepôts régionaux résout les problèmes de distance et de résilience, mais elle crée également des problèmes de synchronisation des stocks, de personnel, de routage et de surcoût opérationnel.
Le logiciel se comporte de la même manière. Vous placez le calcul plus près des utilisateurs, vous répétez l'état critique, et vous routez les requêtes en fonction de la latence, de la santé ou de la géographie. Si vous souhaitez un modèle mental plus simple pour les équipes frontend, comparez-l’à un réseau de bord pour la livraison mondiale. Un réseau de bord pour la livraison mondiale.. La différence est que la multi-région ne pousse pas simplement des fichiers plus près des utilisateurs. C'est la responsabilité de l'application qui est déplacée à travers les géographies.
Où les développeurs le ressentent en premier
Les développeurs connaissent généralement la multi-région avant de la comprendre pleinement. Un pipeline de mise en production soudainement nécessite une ciblage régional. Les journaux sont divisés entre les environnements. Un bug mobile se reproduit uniquement pour les utilisateurs routés vers une région. Une écriture de base de données réussit dans un endroit et apparaît plus tard dans un autre endroit.
C'est pourquoi « dupliquer simplement la production dans une autre région » fonctionne rarement proprement. La mise en œuvre de la multi-région force des choix sur :
- La gestion de l'état : peut l'application rester sans état au niveau du service ?
- La gestion des requêtes : qui décide où un utilisateur atterrit ?
- L'appartenance aux données : quelle région est autorisée à accepter les écritures pour lesquelles les enregistrements ?
- Comportement de basculement : Automatique, manuel ou conditionnel ?
Si l'équipe ne peut pas répondre clairement à ces questions, elle n'a pas encore de conception multi-région. Elle a une infrastructure dupliquée et des incidents futurs en attente.
Motifs clés pour l'adoption d'une stratégie multi-région
Seuls quelques motifs justifient le coût et la douleur d'une mise en œuvre multi-région. Si votre motif n'est pas l'un d'eux, restez sceptique.
D'après ceci analyse de quand vous avez réellement besoin d'une mise en œuvre multi-régionil est fondamentalement justifié lorsque les organisations ont besoin d'un SLA contractuel de 99,99% d'uptime ou pluslorsque les applications sensibles à la latence doivent délivrer des temps de réponse inférieurs à 100 ms sur plusieurs continentsou lorsque des réglementations telles que Les données des utilisateurs de l'UE doivent rester au sein des frontières de l'UE en vertu du RGPD.
Les engagements de disponibilité changent la réponse
Une fois que la disponibilité est incluse dans un contrat, l'architecture devient une question juridique et commerciale. Une région unique peut être fiable, mais si l'entreprise exige 99,99 % de disponibilité, la marge pour les perturbations régionales devient trop étroite, et l'isolement géographique devient partie de l'histoire de la résilience.
C'est pourquoi la planification de la récupération en cas de sinistre doit se tenir à côté de la conception du système. Les équipes qui sont sérieuses sur la résilience paient généralement leur travail d'architecture avec une planification plus large pour les perturbations commerciales , car les objectifs de disponibilité ne concernent pas seulement les serveurs. Ils affectent les communications avec les clients, les blocages de mise à jour, les flux de travail de support et les décisions de direction pendant les incidents.Règle pratique :
Si la direction souhaite un engagement de quatre-vingt-dix-neuf, demandez à qui appartient l'approbation de la failover régionale, les messages aux clients et l'autorité de retrait avant de provisionner quoi que ce soit. La performance mondiale est un problème de physique
Si vos utilisateurs sont concentrés dans un marché unique, une région unique plus CDN gagne généralement en simplicité. Si vos utilisateurs sont répartis en Asie-Pacifique, en Europe et en Amérique, la distance commence à fixer des limites difficiles à atteindre.
GDPR requires EU user data to stay within EU borders
Les attentes de réponse inférieures à 100 ms sur plusieurs continents ne sont pas quelque chose que vous pouvez activer d'un seul coup dans une région. Vous réduisez les payloads, cachez agressivement et optimisez les requêtes, mais à un certain point, la liaison elle-même devient le goulet d'étranglement. Pour les utilisateurs mobiles, ce retard se cumule. L'application démarre, charge la configuration, vérifie l'authentification, charge les données de flux d'accueil et charge souvent des assets. Chaque voyage transocéan supplémentaire apparaît sous la forme de « l'application se sent lente. »
C'est là où une bonne planification de l'infrastructure pour la scalabilité et la fiabilité compte. Cela empêche les équipes de traiter une plainte de latence mondiale comme un bug de performance local.
La conformité peut supprimer la possibilité de choisir
Parfois, le débat d'architecture se termine avant de commencer. Si les termes juridiques ou contractuels exigent la résidence des données dans une géographie spécifique, vous avez besoin d'infrastructure là-bas.
C'est particulièrement important pour les équipes de fintech, de santé et de SaaS d'entreprise. Le problème ne consiste pas seulement à savoir où une requête est servie. Il s'agit de savoir où les données personnelles sont stockées, répliquées, chiffrées et écrites. Une fois que les limites de données régionales deviennent obligatoires, le déploiement multi-région n'est plus une optimisation de performance. C'est une exigence de conformité avec des conséquences architecturales.
Un grand nombre d'équipes essaient de retarder cette prise de conscience en disant qu'elles « résoudront cela dans la couche d'application ». Cela ne tient rarement la comparaison lors d'un audit ou d'une revue par les clients. Si la résidence est importante, la mise en place de l'infrastructure, la gestion des clés et la mise en route de l'écriture doivent tous refléter cela.
Comparaison des architectures multi-région courantes
La choix d'architecture détermine combien votre opération future sera douloureuse. Pas le diagramme du jour de lancement. La mise en production mardi, l'incident nocturne, et le retraitement lorsque l'une des régions se comporte différemment des autres.
Active-passive pour un basculement contrôlé
Active-passive signifie que l'une des régions gère le trafic de production tandis que l'autre région est prête à prendre le relais. Dans la pratique, les organisations tombent souvent sur le pilot light ou le warm standby.
Le pilot light garde la région secondaire minimale. Le warm standby garde plus de la pile en cours d'exécution, ce qui signifie que le basculement est plus rapide et moins chaotique. Ce modèl’est souvent le premier pas sensé car il vous donne une récupération géographique sans forcer chaque service et chaque chemin de données à être en mode actif à l'échelle mondiale.
Le compromis est évident. La région de secours n'est pas prouvée sous le trafic normal. Vous n'apprenez que combien vos hypothèses étaient complètes que lorsque vous testez le basculement, ou pire, lorsque vous en avez besoin.
Voici une utilisation utile avant la comparaison plus approfondie : options de hébergement cloud pour la livraison d'actualisations d'applicationsLes équipes mobiles oublient souvent que le basculement régional des backends et la livraison régionale des mises à jour doivent s'aligner.
Un explainer visuel court vous aidera ici :
Active-active pour un trafic en direct dans plusieurs régions
Active-active est là où plusieurs régions servent le trafic en même temps. Fait bien, cela donne aux utilisateurs une latence plus faible et un comportement de basculement plus propre. Fait mal, cela donne des bugs de cohérence qui ne se produisent que sous partial failure.
D'après cette vue d'ensemble de l'architecture de déploiement multi-région, les applications active-active doivent être pleinement étatless. La même source note que les stratégies de routage DNS telles que la routage basé sur la latence envoient les utilisateurs vers la région à la plus faible latence, tandis que la routage de basculement utilise des vérifications de santé pour basculer le trafic vers les points de terminaison de secours lorsque les primaires échouent.
Ce besoin d'étatless est là où beaucoup de projets s'arrêtent. L'affinité de session, les écritures de fichiers locaux, les caches régionaux spécifiques et les hypothèses cachées à l'intérieur des services plus anciens travaillent tous contre l'active-active. Si votre application dépend toujours de « le serveur se souvient », vous n'êtes pas prêt.
Les services étatless rendent l'active-active possible. Ils ne le rendent pas simple.
Comparaison d'Architecture Multi-Région
| Attribut | Active-Passive (Standby Chaud) | Active-Active |
|---|---|---|
| Objectif principal | Rétablissement après sinistre avec un redémarrage plus rapide | Haute disponibilité et faible latence pour le trafic mondial en direct |
| Modèle de trafic normal | Une seule région principale gère le trafic | Plusieurs régions gèrent le trafic simultanément |
| Pression sur la conception de l'application | Modéré | Élevé, surtout autour des services sans état |
| Complexité opérationnelle | Inférieure à active-active | Plus élevé |
| Gestion des données | Réplication vers la région de secours | État partagé ou synchronisé entre les régions actives |
| Mode de basculement | Switch contrôlé vers la région de secours | Échanges de trafic entre les régions déjà en ligne |
| Bon choix | Systèmes critiques nécessitant une récupération régionale sans service global complet | Produits avec des utilisateurs sur plusieurs continents et des besoins stricts en matière d'expérience ou de disponibilité |
La bonne réponse est souvent celle qui répond aux besoins de l'entreprise. Si vous avez besoin d'une récupération de catastrophe régionale, l'actif-passif est souvent suffisant. Si vous avez besoin que les utilisateurs de plusieurs continents frappent des calculs proches tout au long de la journée, l'actif-actif devient l'option principale, mais seulement si l'architecture de l'application est prête pour cela.
Les Coûts Cachés et les Échanges Critiques
Le facture de cloud est le coût le plus facile à remarquer. Il s'agit rarement du plus difficile à gérer.
D'après ce guide à l'infrastructure SaaS multi-régionale, les dépenses d'infrastructure augmentent généralement de 1,5 à 3 fois par rapport aux configurations à région unique, et les équipes commencent souvent avec 2-3 régions comme US Est, EU Ouest et Asie-Pacifique. La même source indique que les frais de transfert de données entre régions sont une surprise majeure, et que l'expansion significative devrait suivre la concentration des utilisateurs ou les exigences des entreprises plutôt que l'ambition architecturale.
Le facture n'est qu'une partie de l'histoire
Les organisations prévoient souvent des coûts de calcul dupliqués. Moins prévoient des coûts de réplication, d'observabilité dupliquée, d'environnements supplémentaires et du temps humain nécessaire pour maintenir les régions cohérentes.
Un certain nombre de pièges de coûts se présentent à plusieurs reprises:
- La réplication entre régions: chaque chemin de synchronisation devient un article de facture et une dépendance opérationnelle.
- La capacité de secours: le redondance n'est pas utile si la région secondaire ne peut absorber la demande réelle.
- Étendue de surveillance : les tableaux de bord, les alertes et l'analyse des journaux s'étendent désormais à la géographie, et non plus seulement aux services.
- Fardeau de test : chaque annulation et chaque exercice de récupération prend plus de temps car le tableau s'est élargi.
Ce qui fonctionne, c'est la retenue. Commencez par les moins de régions qui résolvent le problème. Ajoutez-en plus seulement lorsque vous avez une raison claire du marché, réglementaire ou contractuelle.
Le flux de travail du développeur devient difficile rapidement
Par conséquent, l'architecture multi-région laisse l'équipe de plateforme et atterrit sur chaque bureau d'ingénieur.
Les pipelines de mise en production ne peuvent plus simplement « mettre en production » désormais. Ils ont besoin d'ordre, de validation et de contrôle de la portée régionale. Les drapeaux de fonctionnalité ont besoin de conscience régionale. Le support doit savoir dans quelle région de serveur et quelle version de client un utilisateur a frappé. Les gestionnaires de produit doivent comprendre que la mise en production peut être saine en Europe et dégradée en APAC en même temps.
Pour les équipes mobiles, la conformité ajoute une autre couche. Si votre chemin d'actualisation de l'application et votre chemin de données de serveur ne respectent pas les mêmes limites régionales, vous pouvez créer des problèmes de politique tout en essayant de résoudre des problèmes de fiabilité. C'est pourquoi les équipes travaillant sur les préoccupations de politique d'Apple et de Google pour la conformité multi-région doivent examiner les chemins de livraison, les hypothèses de stockage et les contrôles de déploiement ensemble.
La taxe cachée de la mise en œuvre multi-région est la charge cognitive. Chaque déploiement, chaque alerte et chaque rapport client nécessite désormais un contexte régional.
Guide d'implémentation et meilleures pratiques
La plupart des projets multi-région échouent pas à cause du produit cloud choisi par l'équipe. Ils échouent parce que la discipline de déploiement, la conception de données et l'observabilité n'étaient pas prêts pour les dimensions supplémentaires.
Démarrez par la voie des données
Avant de dupliquer les serveurs d'applications, décidez comment les données circulent et qui possède les droits d'écriture. La discussion Well-Architected sur l'isolement et la préparation multi-région de AWS met l'accent sur la réplication continue vers les régions de secours, le suivi du retard de réplication, l'égalité des quotas de service entre les régions et les pipelines de déploiement ciblant une région à la fois plutôt que toutes à la fois. Cette seule recommandation sur le déploiement d'une région à la fois est plus précieuse que de nombreux équipes ne le réalisent. Cela vous donne la contenance. Si une migration, une modification de configuration ou un nouveau plafond de service se brise, vous voulez une géographie affectée, pas toutes. Utilisez un court checklist avant le lancement :
Définissez la propriété d'écriture :
connaissez quelle région peut accepter les écritures pour chaque domaine de données.
- Suivez explicitement le retard : connaissez le retard de réplication entre les régions.
- Definissez les quotas de service : ne pas supposer que les répliques sont à jour parce que l'interface utilisateur semble verte.
- Correspondre aux quotas et aux limites : le basculement meurt rapidement si une région a des plafonds de capacité inférieurs.
- Planifier les modes dégradés : certains fonctionnalités devraient devenir en lecture seule plutôt que pleinement indisponibles.
Routage avec intention
La gestion de DNS et du trafic ne sont pas des tâches "fixées et oubliées". Elles sont codées dans l'infrastructure.
Le routage basé sur la latence est utile lorsque les utilisateurs doivent rejoindre la région la plus proche en état de marche. Le routage de basculement est utile lorsque l'une des régions reste principale et que l'autre est de secours. Les contrôles de santé sont importants, mais les contrôles de santé superficiels peuvent tromper. Une région peut répondre aux tests de ping tout en ayant une dépendance critique en panne pour les utilisateurs réels.
Le modèle sûr consiste à définir ce que signifie « en état de marche » au niveau de l'application. La connexion fonctionne. La commande de paiement fonctionne. La synchronisation fonctionne. La récupération du manifeste d'application fonctionne. Si l'entreprise repose sur ces flux, les contrôles de santé doivent les refléter.
Un ou deux habitudes sont utiles :
- Tenir le routage simple au début : ne pas combiner trop de politiques le jour de la mise en œuvre.
- Testez le comportement de failback : Les équipes se rappellent de la failover et oublient le chemin de retour.
- Documentez l'autorité de prise en charge manuelle : Quelqu'un a besoin de permissions claires pour arrêter l'automatisation lorsque les signaux entrent en conflit.
Envoyez les modifications du backend et des appareils mobiles sans créer d'incidents mondiaux.
C'est là où de nombreux articles d'infrastructure passent sous silence. Vos utilisateurs expérimentent tout le système, pas seulement la disposition des régions.
Lorsque les API backend se déployent par région, la stratégie d'actualisation mobile nécessite le même niveau de contrôle. Si l'Europe obtient un nouveau contrat API avant l'APAC, la version de l'application atteignant l'Europe en premier peut fonctionner correctement tout en cassant le même bundle ailleurs. C'est pourquoi l'ingénierie de la mise en production pour les appareils mobiles nécessite des canaux, un déploiement étalé, un retour en arrière et des indicateurs de performance régionaux.
Une option que les équipes utilisent est : Capgoqui livre des paquets d'actualisation signés en direct pour les applications Capacitor et Electron à travers un réseau edge mondial, prend en charge les canaux ciblés, applique les mises à jour à la prochaine lancement et fournit des journaux par appareil et des contrôles de retour en arrière. Dans un environnement multi-région, cela compte parce que la livraison d'applications devient partie de la sécurité opérationnelle, pas seulement de la commodité.
Un modèle de mise en production pratique ressemble à ceci :
- Déployez les modifications du backend dans une région en premier : confirmer l'état de santé avant de l'agrandir.
- Exposer les métriques de compatibilité : savoir quelles versions d'applications appellent quelles variantes de API.
- Déployer des mises à jour mobiles par public ou par zone géographique : ne pas envoyer tous les utilisateurs à la fois.
- Garantir que le retraitement soit peu coûteux : si une région se dégrade, inversez l'unité la plus petite possible.
Une panne mondiale peut commencer comme un problème de coordination de mise à jour, et non comme une défaillance d'infrastructure.
Observer le chemin de l'utilisateur et non seulement les serveurs.
La surveillance traditionnelle se concentre sur les services, les bases de données, les files d'attente et les métriques de serveur. Les opérations multi-région ont également besoin d'une lentille centrée sur l'utilisateur.
Cela signifie corriger la région, la version de l'application, le canal d'actualisation, l'endpoint de serveur et le résultat de la demande. Pour les applications mobiles en particulier, le symptôme atteint souvent le support avant d'atteindre la surveillance de l'infrastructure. « L'application s'est bloquée après connexion à Singapour » est un indice de routage et de mise à jour, et non seulement un rapport de bug.
Une bonne observabilité dans le déploiement multi-région devrait répondre rapidement à ces questions :
| Question | Pourquoi cela compte |
|---|---|
| Quelle région a traité la demande | Vous avez besoin de contexte régional avant de déboguer quoi que ce soit |
| Quelle version de l'application a effectué l'appel | Les incompatibilités entre le client et le serveur apparaissent souvent comme des problèmes d'infrastructure |
| La réplication était-elle à jour | Un retard de données peut créer une incohérence visible pour l'utilisateur |
| A-t-il y eu un déplacement récent du trafic | Les changements de routage expliquent les groupes soudains de problèmes géographiques |
| Pouvez-vous annuler sélectivement | L'annulation partielle bat la panique globale |
Quand les équipes peuvent répondre à ces cinq questions rapidement, les incidents deviennent gérables. Lorsqu'elles ne le peuvent pas, chaque panne se transforme en un exercice de devinette au niveau de l'application, du réseau et des couches cloud.
Conclusion : Construire un pied-à-terre global résilient
Le déploiement multi-région est justifié par l'effort lorsque l’exigence est réelle. La disponibilité contractuelle, l'expérience de basse latence à l'échelle mondiale et les obligations de résidence de données justifient les coûts. Tout le reste mérite une évaluation critique.
La plus grande erreur n'est pas de sous-estimer la conception de l'infrastructure. C'est de sous-estimer l'impact quotidien que le déploiement multi-région a sur le travail d'ingénierie. Les déploiements nécessitent une séquence. Les mises à jour mobiles nécessitent une logique de lancement régional. L'observabilité doit relier l'expérience utilisateur à la routage, la réplication et la version de l'application. Les équipes de support et de produits doivent avoir la même vocabulaire régional que les ingénieurs de plateforme.
Les équipes qui réussissent dans ce domaine restent disciplinées. Elles commencent avec la plus petite empreinte régionale qui résout le problème commercial. Elles préfèrent un comportement de basculement clair plutôt qu'une architecture ingénieuse. Elles traitent l'ingénierie de lancement et l'observabilité de l'utilisateur comme des composants de premier ordre de la résilience.
Un pied-à-terre global résilient n'est pas construit en copiant une région dans une autre. C'est construit en décidant, à l'avance, comment le système entier se comporte lorsque la géographie, les réseaux, les déploiements et les utilisateurs ne se alignent pas parfaitement.
Si votre équipe déploye des applications Capacitor et a besoin d'un contrôle plus serré sur la livraison mondiale des applications pendant les déploiements multi-régionaux. Capgo Vous pouvez ainsi coordonner les mises à jour en direct signées, les canaux étape par étape, le retrait et la visibilité au niveau du dispositif, afin que les modifications back-end et les sorties mobiles ne s'éloignent pas l'une de l'autre.
