L’Afrique, le continent oublié des benchmarks
Les benchmarks jouent un rôle central dans l’évaluation des moteurs de stockage et des systèmes distribués. Des outils comme YCSB, TPC-C ou sysbench servent de référence pour comparer les performances, la scalabilité ou l’efficacité d’un système.
Mais ces benchmarks reposent sur des hypothèses implicites — et aucune ne correspond aux réalités africaines.
Cette note explique pourquoi les benchmarks classiques ne modélisent pas les environnements, les contraintes et les usages africains, et pourquoi de nombreuses conclusions techniques deviennent incorrectes lorsqu’on sort des conditions idéales des datacenters européens ou américains.
Les hypothèses implicites des benchmarks classiques
Les benchmarks standards supposent un environnement très particulier :
* réseau stable et datacenter-grade
* CPU et mémoire abondants
* latence disque faible (SSD/NVMe)
* pertes de paquets quasi nulles
* charge prévisible et centralisée
Ces hypothèses reflètent les infrastructures européennes, américaines ou asiatiques…
mais absolument pas les réalités opérationnelles de la majorité des pays africains.
Pourquoi ces benchmarks ne reflètent aucun workload africain
Les écosystèmes numériques africains combinent forte utilisation, connectivité instable, géographie distribuée, et contraintes matérielles.
Résultat :
les workloads africains ne ressemblent ni à TPC-C, ni à YCSB, ni à sysbench.
1. La latence WAN est une contrainte première
Les benchmarks sont presque toujours exécutés dans un seul datacenter.
En Afrique :
Perte de paquets : 1–5%
Variabilité : élevée
Les moteurs évalués dans un LAN sub-milliseconde se comportent totalement différemment face à ces conditions.
2. Des workloads géographiquement distribués par nature
Les benchmarks supposent un backend unique et centralisé.
Mais de nombreux systèmes africains reposent sur :
- des agences réparties sur plusieurs régions,
- des points de service ruraux,
- des terminaux intermittents,
- des synchronisations différées.
Aucun benchmark standard ne simule ces conditions.
3. Des accès fortement skewed et imprévisibles
Les distributions uniformes ou Zipfiennes des benchmarks ne peuvent pas reproduire :
- les pics extrêmes (ex : salaires mobile money),
- les longues périodes de calme suivies d’explosions d’activité,
- les sync storms après période offline,
- les batchs massifs déclenchés par reconnection.
Les benchmarks mesurent la vitesse — l’Afrique exige des systèmes qui supportent le chaos.
4. Aucun benchmark n’intègre les scénarios offline/local-first
Dans de nombreuses zones, l’offline est une réalité quotidienne.
Aucun benchmark ne modélise :
* résolution de conflits
* synchronisations opportunistes
* partitions réseau prolongées
* cohérence éventuelle entre agences isolées
Ces dimensions changent radicalement la nature des moteurs de stockage.
Des cas d’usage africains complètement absents des benchmarks
Mobile Money
Transactions massives, pics extrêmes, cohérence stricte, localisation géographique inégale, terminaux instables.
Logistique et transport
Flottes réparties sur des milliers de kilomètres, mises à jour irrégulières, synchronisation tardive, traitements locaux.
E-gouvernement
Agences régionales, municipalités rurales, matériel hétérogène, absence d’infrastructures LAN traditionnelles.
Retail distribué (POS)
Caisse offline, synchro périodique, gestion des conflits, reprise après coupure réseau.
Aucun benchmark n’approche ces workloads réels.
Conclusion
Les benchmarks ne sont pas universels : ils reflètent les environnements où ils ont été développés.
L’Afrique, avec ses contraintes uniques, latence élevée, réseau instable, distribution géographique ou encore usage offline n’entre dans aucune de ces hypothèses.
Pour construire des systèmes adaptés au continent, il faut des benchmarks africains, basés sur les réalités africaines.
Références recommandées
- Spécification TPC-C
- YCSB — Core Workloads
- ACM Queue — The Tail at Scale
- GSMA — Rapports Mobile Money
- Banque Mondiale — Digital Infrastructure in Sub-Saharan Africa