Migrer vers Azure depuis l’Afrique centrale : ce que nous avons mesuré depuis Douala
« Le cloud, c’est trop loin. » C’est l’objection qui revient le plus souvent quand un dirigeant de la région envisage de sortir ses serveurs de sa salle technique. Elle n’est pas absurde : il n’existe aucun centre de données Azure en Afrique centrale. Les applications hébergées dans le cloud de Microsoft tournent à Johannesburg, à Paris ou aux Pays-Bas — à des milliers de kilomètres.
Plutôt que d’y répondre par un argument, nous avons mesuré. Voici ce que donnent ces distances depuis Douala, comment lire les chiffres, et comment choisir où héberger ses données.
1. Où sont les centres de données
Microsoft exploite deux régions Azure sur le continent, toutes deux en Afrique du Sud : Johannesburg (South Africa North) et Le Cap (South Africa West). La seconde est à accès restreint : elle sert principalement de région de secours à la première. Pour une entreprise d’Afrique centrale, la région africaine ouverte est donc Johannesburg.
L’autre option est l’Europe : Paris (France Central), les Pays-Bas (West Europe), l’Irlande et d’autres. Plus loin sur la carte — mais pas forcément plus loin sur le réseau. La distance qui compte n’est pas celle de la carte : c’est celle que parcourent réellement les données, selon les câbles et les opérateurs qu’elles empruntent.
2. Ce que nous avons mesuré
Pour notre propre projet de postes de travail dans le cloud (Windows 365), nous avons mesuré le temps de réponse depuis Douala le 17 mai 2026. Deux mesures complémentaires :
| Destination | Temps de réponse médian | Connexion | Ce que cela mesure |
|---|---|---|---|
| Point d’entrée des sessions Windows 365 | 101 ms | Réseau de l’entreprise | Ce que ressent un utilisateur au travail sur son poste distant |
| Centre de données de Johannesburg | 138 ms | Liaison satellite | Le trajet jusqu’à la région africaine |
| Centre de données de Paris | 158 ms | Liaison satellite | Le trajet jusqu’à la région française |
| Centre de données des Pays-Bas | 163 ms | Liaison satellite | Le trajet jusqu’à la région néerlandaise |
La première mesure repose sur 30 échantillons ; la médiane est la valeur du milieu, celle qui décrit l’expérience ordinaire. Les trois suivantes comparent les régions entre elles avec un outil public de test. Ce sont les mesures d’une journée, depuis un seul site : elles donnent un ordre de grandeur, pas une vérité pour toute la région. Votre connexion donnera d’autres chiffres, et c’est précisément pour cela qu’il faut mesurer la vôtre.
3. Comment lire ces chiffres
La latence n’est pas le débit. Le débit dit combien de données passent par seconde ; la latence dit combien de temps met un aller-retour. Une connexion peut avoir un gros débit et une latence élevée. Pour un logiciel de gestion, une session à distance ou un appel Teams, c’est la latence qui se ressent.
Le point d’entrée est plus proche que le centre de données. Microsoft répartit ses points d’entrée dans le monde : la connexion d’un utilisateur arrive d’abord au plus proche, puis voyage sur le réseau privé de Microsoft. C’est pourquoi la session Windows 365 répond en 101 ms alors que le centre de données de Paris est à 158 ms.
La médiane ne dit pas tout. Sur la même mesure, une connexion sur vingt a dépassé 250 ms. Pour un travail de bureau soutenu, c’est acceptable ; pour une saisie très rapide, un ralentissement ponctuel peut se sentir. Il faut regarder la médiane et les pires cas.
L’usage fait le seuil. Une sauvegarde nocturne ou une synchronisation de fichiers supporte sans difficulté quelques centaines de millisecondes. Un logiciel de caisse ou une session à distance les ressent. On ne choisit pas une région dans l’absolu, mais pour un usage.
4. Choisir la région : proximité ou lieu des données
Depuis Douala, Johannesburg répond une vingtaine de millisecondes plus vite que Paris. Si la seule question était la vitesse, le choix serait fait.
Mais le lieu où vivent les données compte aussi : obligations contractuelles envers des clients européens, exigences d’un régulateur, politique de groupe d’une filiale. Pour notre propre projet, nous avons retenu Paris : nos données restent dans l’Union européenne, et les vingt millisecondes de différence ne dégradent pas l’usage que nous en faisons. Une autre entreprise, sans lien avec l’Europe et avec des usages plus sensibles à la latence, pourrait légitimement choisir Johannesburg.
Un troisième critère entre dans la décision : la résilience. Johannesburg comme Paris comptent trois zones de disponibilité — des centres de données distincts au sein de la même région, avec leur propre alimentation et leur propre réseau. Une application répartie sur deux zones survit à la panne de l’une d’elles. Chacune de ces deux régions dispose aussi d’une région de secours dans le même pays — Le Cap pour Johannesburg, Marseille pour Paris — réservée aux scénarios de reprise après sinistre.
Pour une entreprise habituée à un serveur unique dans une salle technique, c’est un changement d’échelle : la question n’est plus « que se passe-t-il si le serveur tombe ? », mais « sur combien de zones répartir ce qui ne doit jamais s’arrêter ? ». La réponse a un coût — deux zones coûtent plus qu’une — et elle se décide application par application, en fonction de ce que coûterait une interruption. Un logiciel de gestion consulté pendant les heures de bureau n’appelle pas la même architecture qu’un service de paiement ouvert jour et nuit.
Ce qui ne se fait pas, c’est de choisir sans avoir mesuré, sur la foi d’une carte.
5. Ce que la région ne change pas
Le trajet vers le cloud commence dans vos locaux. Lors de la même mesure, le temps de réponse vers deux services publics d’annuaire de noms variait de 29 à 105 ms depuis le même poste : la latence dépend de la destination réelle, pas d’une « vitesse d’Internet » uniforme. Et la qualité du premier kilomètre — votre opérateur, votre routeur, votre réseau interne — pèse autant que le choix de la région.
Deux conséquences pratiques. D’abord, une seule connexion est un point de défaillance unique : une application dans le cloud est inaccessible si la liaison tombe. Une seconde liaison, chez un autre opérateur ou par un autre moyen, fait partie du projet de migration, pas d’une option. Ensuite, mesurez depuis chaque site — siège, agences, domicile des collaborateurs en télétravail — avant de décider.
Mesurer n’a rien de compliqué ni de coûteux. Un petit programme interroge les points d’entrée de Microsoft et les régions envisagées, plusieurs fois par heure, pendant une semaine ; on retient la médiane et les pires cas, aux heures creuses comme aux heures d’affluence. Une semaine de mesures coûte moins qu’une migration à refaire.
6. Cinq questions avant de migrer
- Quelles applications sont sensibles à la latence ? Saisie intensive, caisse, sessions à distance : à tester en priorité.
- Avez-vous mesuré depuis vos propres sites ? Pendant plusieurs jours, aux heures de pointe.
- Où vos données doivent-elles être hébergées ? Contrats, régulateur, groupe : la réponse peut trancher avant la latence.
- Avez-vous une seconde liaison Internet ? Sinon, c’est le premier investissement du projet.
- Qu’est-ce qui reste sur place ? Certaines charges ont intérêt à rester locales ; une architecture hybride est souvent la bonne réponse.
La distance n’est pas un argument contre le cloud. C’est un paramètre, qui se mesure et se règle.
SIGA IT Consulting accompagne les entreprises d’Afrique centrale dans leur migration vers Azure. Découvrez notre offre Cloud et infrastructure — ou commencez par mesurer où en est votre entreprise avec notre diagnostic de maturité.
