Bâtir des plateformes numériques évolutives pour les entreprises africaines

Concevoir des logiciels pour les entreprises africaines ne consiste pas à reprendre une plateforme pensée ailleurs et à en traduire l’interface. Les contraintes diffèrent, les opportunités aussi : connectivité intermittente, clients avant tout mobiles, paiements fondés sur le mobile money plutôt que sur la carte bancaire, économies multidevises et cadres réglementaires en pleine évolution. Traitées comme des cas particuliers, ces réalités donnent des systèmes fragiles. Intégrées dès la conception, elles donnent des plateformes robustes partout, y compris là où l’infrastructure est plus clémente.

Voici les principes d’architecture que nous appliquons pour concevoir des logiciels de commerce, de gestion marchande et de logistique adaptés à ces conditions, ainsi que les arbitrages qu’ils impliquent.

Partir des conditions réelles d’exploitation

La plupart des échecs d’architecture naissent d’une vision trop optimiste de l’environnement. Avant de choisir une stack, décrivez les conditions auxquelles le système doit résister :

• Une connectivité qui disparaît parfois pendant des heures, oscille entre 4G, 3G et 2G au cours d’un même trajet et se paie souvent au volume : chaque mégaoctet coûte à l’utilisateur.
• Des terminaux souvent Android d’entrée de gamme, avec peu de mémoire, partagés entre employés ou dotés d’un système ancien.
• Une alimentation électrique non garantie : téléphones, tablettes et terminaux de caisse peuvent s’éteindre en pleine transaction.
• Des paiements reposant largement sur le mobile money et les espèces, la carte restant loin d’être universelle.
• Des devises qui coexistent. En République démocratique du Congo, par exemple, prix, salaires et factures fournisseurs sont couramment libellés en dollars américains comme en francs congolais.

Transformez chaque condition en exigence vérifiable. « Fonctionne hors ligne » reste vague. « Un caissier peut enregistrer ses ventes toute une journée sans connexion, puis les synchroniser sans doublon au retour du réseau » est un objectif qu’une équipe peut concevoir et tester.

Le hors-ligne comme choix d’architecture

Le mode hors ligne ne s’ajoute pas en fin de projet. Il détermine où réside la vérité, comment naissent les identifiants et comment se résolvent les conflits.

Faire du stockage local l’interface principale

Dans un client conçu pour le hors-ligne, l’interface lit et écrit dans une base locale (SQLite sur mobile natif, IndexedDB dans le navigateur) plutôt que d’appeler le réseau. Une couche de synchronisation transfère les modifications vers le serveur en arrière-plan.

Générer les identifiants côté client

Si un enregistrement ne reçoit son identifiant que du serveur, l’appareil ne peut pas créer de données liées hors connexion : une commande ne peut pas référencer un client créé cinq minutes plus tôt. Utilisez des identifiants uniques générés par le client, comme UUIDv7 ou ULID, ordonnés dans le temps et efficaces à indexer. Associés à des points d’accès idempotents, ils rendent les nouvelles tentatives sans danger.

S’appuyer sur une outbox et un protocole de synchronisation explicite

Consignez chaque modification locale dans une table d’envoi (le motif « outbox ») avec l’opération, les données et l’horodatage. Le processus de synchronisation la vide dans l’ordre, ne considère une entrée comme acquittée qu’après confirmation du serveur et récupère les changements distants grâce à un curseur ou un numéro de version émis par le serveur.

Définir les règles de conflit domaine par domaine

La règle du dernier écrivain gagnant convient pour le nom d’un client ; elle est dangereuse pour un stock ou un solde. Modélisez les mouvements de stock et les paiements comme des événements en ajout seul (« deux unités vendues », « dix unités reçues ») plutôt que d’écraser une quantité : les modifications simultanées de plusieurs appareils se combinent alors naturellement. Réservez l’arbitrage serveur aux invariants qui exigent une autorité unique, comme interdire qu’un bon d’achat serve deux fois, et expliquez clairement à l’utilisateur pourquoi une action saisie hors ligne a été refusée.

L’API Background Sync n’étant pas disponible dans tous les navigateurs, les clients web doivent aussi synchroniser dès que l’application est ouverte et que la connexion revient.

Paiements : mobile money et multidevise

Les services de mobile money comme M-Pesa, Orange Money ou Airtel Money sont au cœur du commerce sur une grande partie du continent. Leur intégration obéit à une autre logique que celle de la carte.

Traiter chaque paiement comme une machine à états asynchrone

Une collecte par mobile money envoie généralement une demande de validation sur le téléphone du client, puis confirme le résultat plus tard par un rappel (callback). Le client peut accepter, refuser, ignorer la demande ou perdre le réseau. Modélisez explicitement les états, par exemple initiated, pending, succeeded, failed et expired, et ne tenez jamais l’arrivée du rappel pour acquise. Une tâche de rapprochement doit interroger le fournisseur sur les paiements restés en attente et confronter chaque transaction à ses relevés et rapports de règlement.

Isoler les fournisseurs derrière une abstraction

Chaque opérateur et agrégateur a sa propre API, ses codes d’erreur, ses plafonds et son cycle de règlement, qui évoluent tous. Placez chaque intégration derrière une interface interne dotée d’un modèle de statuts normalisé : ajouter un fournisseur n’aura alors aucune répercussion sur les commandes, la facturation ou la comptabilité.

Représenter correctement les montants

• Stockez les montants en entiers d’unités mineures, avec un code devise ISO 4217 (USD, CDF), jamais en virgule flottante.
• N’additionnez jamais des montants de devises différentes sans conversion explicite.
• Lors d’une conversion, enregistrez avec la transaction le taux appliqué, sa source et son horodatage, pour que tout chiffre soit reproductible lors d’un audit.
• Tenez un grand livre en partie double pour les soldes, comme les portefeuilles marchands ou les crédits clients, plutôt qu’une colonne de solde modifiable.
• Permettez de fixer les prix par devise lorsque l’activité l’exige, au lieu de dériver l’un de l’autre à l’affichage.

Ces règles semblent tatillonnes jusqu’à la première clôture mensuelle, lorsque la direction financière demande pourquoi deux rapports divergent de quelques francs.

Des budgets de performance pour les réseaux contraints

La performance est une décision produit qui coûte directement aux utilisateurs dont les données sont facturées. Fixez un budget explicite et faites-le respecter dans l’intégration continue.

Dimension	Ce qu’il faut encadrer
JavaScript	Taille compressée du code nécessaire à la première interaction
Images	Formats AVIF ou WebP, tailles adaptatives, chargement différé hors écran
Allers-retours	Requêtes sur le chemin critique, la latence comptant souvent plus que le débit
Réponses d’API	Sélection des champs, pagination et compression des listes
Terminaux	Réactivité sur un Android d’entrée de gamme, pas seulement sur le poste du développeur

Parmi les techniques utiles : rendu côté serveur pour le premier affichage, compression Brotli, cache HTTP avec validateurs comme ETag, synchronisation différentielle plutôt que rechargements complets, et service worker servant le squelette de l’application depuis le cache. Testez avec un débit bridé, sur du matériel modeste : les émulateurs sur machines rapides masquent précisément les problèmes qui comptent.

Une architecture multi-tenant dès la conception

Une plateforme qui sert de nombreux marchands, points de vente ou partenaires doit être multi-tenant dès le premier schéma. Trois modèles dominent :

• Un schéma partagé, avec un identifiant de locataire sur chaque ligne. L’option la plus économique et la plus simple à exploiter. Faites respecter l’isolation par la base elle-même, par exemple avec la row-level security de PostgreSQL.
• Un schéma par locataire. Une séparation logique plus nette et des sauvegardes par client plus simples, au prix de migrations plus complexes.
• Une base par locataire. L’isolation la plus stricte et la réponse la plus claire aux exigences de résidence des données, pour une charge d’exploitation maximale.

Ces modèles se combinent souvent selon les contraintes de chaque client. Dans tous les cas, rendez le contexte du locataire explicite à chaque niveau (jetons d’accès, journaux, métriques, tâches de fond, clés de cache) et appliquez des limites de débit par locataire, pour qu’un client très actif ne pénalise pas les autres.

Monter en charge progressivement

Au début de la vie d’un produit, les microservices ajoutent généralement plus de charge opérationnelle qu’ils n’en retirent. Un monolithe modulaire bien structuré est un meilleur point de départ : une seule unité de déploiement, mais des frontières internes strictes entre domaines comme le catalogue, les commandes, les paiements, les stocks et la livraison.

Encore faut-il que ces frontières soient réelles :

• Chaque module possède ses tables ; les autres n’accèdent à ses données que par son interface publique.
• Les règles de dépendance sont vérifiées automatiquement par des tests d’architecture ou des règles de lint, pas seulement en revue de code.
• Les modules faiblement couplés communiquent par événements métier, publiés selon le motif de l’outbox transactionnelle : un événement est émis si, et seulement si, sa transaction est validée.

N’extrayez un module en service distinct que pour une raison concrète : il doit monter en charge indépendamment, vise une disponibilité différente, exige son propre rythme de livraison ou relève d’une autre équipe. La frontière existant déjà, l’extraction devient un changement d’infrastructure plutôt qu’une réécriture.

Observabilité et résidence des données

Observer le parcours de bout en bout

Sur des réseaux peu fiables, une bonne partie des défaillances survient hors de vos serveurs. Instrumentez les deux côtés :

• Adoptez OpenTelemetry pour les traces, métriques et journaux, et propagez un identifiant de corrélation du client jusqu’à chaque service et chaque appel fournisseur.
• Mettez en tampon la télémétrie côté client et synchronisez-la comme les données métier, y compris la longueur de la file de synchronisation et l’âge de la plus ancienne modification en attente.
• Fixez des objectifs de niveau de service fondés sur l’expérience utilisateur, comme le délai de confirmation d’un paiement ou le taux de synchronisations réussies, plutôt que sur l’usage du processeur.
• Surveillez chaque dépendance externe, à commencer par les fournisseurs de paiement, pour distinguer une panne chez un prestataire d’un défaut de votre propre code.

Anticiper la résidence des données

Les règles de protection et de localisation des données varient selon les pays africains et les secteurs, et continuent d’évoluer. Les données financières, de santé ou publiques peuvent notamment être soumises à des exigences quant à leur lieu de stockage et aux personnes habilitées à y accéder. Préservez votre liberté de choix :

• Classez les données selon leur sensibilité dès le départ.
• Gérez l’infrastructure sous forme de code, pour pouvoir déployer la plateforme dans une région donnée ou sur une infrastructure locale si nécessaire.
• Sachez quels sous-traitants traitent quelles données, outils d’analyse et de journalisation compris.
• Faites-vous conseiller juridiquement pour chaque marché. L’architecture facilite la conformité ; elle ne la remplace pas.

Une liste de contrôle pour les responsables techniques

Avant de choisir une architecture, votre équipe doit pouvoir répondre oui à ces questions :

1. Les conditions d’exploitation sont-elles formalisées en exigences vérifiables ?
2. Les processus essentiels fonctionnent-ils hors ligne, avec une synchronisation idempotente ?
3. Les règles de conflit sont-elles définies par domaine, avec des modèles en ajout seul pour les stocks et l’argent ?
4. Chaque paiement est-il modélisé comme une machine à états et rapproché des relevés du fournisseur ?
5. Les montants sont-ils stockés en unités mineures, avec une devise explicite et des taux de change enregistrés ?
6. Un budget de performance est-il imposé en intégration continue et vérifié sur des terminaux modestes ?
7. L’isolation des locataires est-elle garantie par la base de données ?
8. Les frontières entre modules du monolithe sont-elles contrôlées automatiquement ?
9. Un paiement ou une synchronisation en échec peut-il être tracé de bout en bout ?
10. La plateforme peut-elle être déployée dans une autre région si un régulateur ou un client l’exige ?

Aucune de ces pratiques n’est propre à l’Afrique. Ce qui l’est davantage, c’est la vitesse à laquelle leur absence se fait sentir. Les plateformes conçues pour ces conditions sont plus résilientes, moins coûteuses à exploiter et plus faciles à étendre à de nouveaux marchés : exactement ce qu’il faut aux entreprises aux ambitions continentales.