Mohamed KEITA
Note #84 min read

Le coût caché du cloud en Afrique

Le cloud est souvent présenté comme la solution idéale : scalable, fiable, moderne. Mais cette vision suppose une infrastructure qui n’existe pas partout. Dans de nombreuses régions d’Afrique, la latence structurelle, la perte de paquets et l’instabilité réseau transforment les architectures cloud-first en sources de lenteur, d’incohérence et de pannes.

Cette note analyse pourquoi le cloud, loin d’être universel, peut devenir un obstacle majeur lorsque la connectivité n’est ni stable ni prévisible.

RTT et latence structurelle : la distance ne disparaît jamais

Les datacenters des géants du cloud sont concentrés en Europe, aux États-Unis et en Asie. Pour de nombreux pays africains, la distance physique impose une latence incompressible.

Ordre de grandeur des RTT vers l’Europe :

Abidjan → Paris         90-130 ms
Lagos → Amsterdam      110-150 ms
Nairobi → Francfort    120-180 ms
Johannesburg → Londres 160-220 ms
 

Et ces chiffres sont optimistes.
Dès que le routing change, que la liaison sous-marine se dégrade ou qu’un opérateur est saturé, les temps explosent.

Chaque commit, chaque requête SQL, chaque appel API hérité du cloud subit cette pénalité.

Perte de paquets et instabilité réseau

Dans plusieurs régions africaines, une perte de paquets de 1% à 5% est courante.
Or même 1% suffit à dégrader massivement les performances TCP.

RTT : 150 ms
→ Débit effectif réduit de 50-80%
→ Latence de queue multipliée par 2 à 10
 

Les architectures cloud-first supposent :

  • faible jitter,
  • pertes quasi nulles,
  • stabilité des routes,
  • connectivité continue.

Rien de cela n’est garanti en Afrique.
Résultat : les performances deviennent erratiques.

Impact sur commit latency et transactions distribuées

Dans une architecture cloud-first, valider une transaction implique au minimum un aller-retour vers le datacenter.

 

Avec 120-200 ms de RTT, une seule écriture peut devenir perceptible pour l’utilisateur.
Pour les protocoles bavards (Postgres, MySQL), la situation empire.

Les déconnexions intermittentes causent :

  • commits suspendus,
  • timeouts,
  • réplicas en retard,
  • données incohérentes,
  • erreurs difficiles à diagnostiquer.

Même si le cloud fonctionne parfaitement, le réseau local devient le facteur limitant.

Pourquoi le cloud-first est incompatible avec la réalité africaine

Le cloud-first fonctionne lorsque :

  • les réseaux sont rapides,
  • les datacenters sont proches,
  • les coupures sont rares,
  • la latence est stable.

En Afrique, la connectivité reste marquée par :

  • la dépendance aux câbles sous-marins,
  • le transit international asymétrique,
  • les congestions régionales,
  • les coupures ponctuelles,
  • la variabilité extrême de la qualité réseau.

Conséquences directes d’une architecture cloud-first :

  • latences imprévisibles,
  • microservices instables,
  • authentifications qui expirent,
  • commits lents,
  • retries en cascade,
  • perte d’expérience utilisateur.

Ce n’est pas l’application qui est lente : c’est la distance qui est structurelle.

Le cloud comme single point of failure

Lorsque toute la logique applicative dépend d’un datacenter distant, la connectivité devient un point de rupture unique.


point de rupture unique
 

Si la liaison saute 5 secondes :
→ l’application entière tombe.

Même avec du caching ou du CDN, les écritures, l’authentification, la coordination ou la validation nécessitent encore le cloud.

Le système devient globalement dépendant… et localement fragile.

Conclusion

Le cloud reste un outil puissant, mais il n’est pas universel.
Dans de nombreux contextes africains, sa dépendance à une connectivité stable en fait un goulot d’étranglement plutôt qu’un atout.

Les architectures local-first, offline-ready ou hybrides offrent une meilleure résilience, une latence plus faible et une stabilité accrue.
Elles s’adaptent aux réalités du terrain plutôt qu’à celles des datacenters.

La leçon est simple :
l’infrastructure doit refléter le monde dans lequel elle vit, pas celui dans lequel elle a été conçue.

Références recommandées

  1. RIPE NCC — Rapports sur la latence Afrique-Europe
  2. APNIC — Mesure de la perte de paquets sur les câbles sous-marins
  3. ACM Queue — The Tail at Scale
  4. Google SRE — Conception de systèmes distribués fiables
  5. Cloudflare Radar — Performances réseau en Afrique