Mobile-first ou mobile-only : pourquoi le hors-ligne compte en Afrique

Le paradoxe de la connectivité

L’Afrique est à la fois le marché mobile qui croît le plus vite au monde et l’une des régions où la connexion est la moins fiable. Ce paradoxe dicte les exigences techniques de tout système de gestion déployé sur le continent, et pourtant la plupart des éditeurs de logiciels n’en ont toujours pas mesuré les conséquences.

En Afrique subsaharienne, les abonnements à l’internet mobile sont passés de 250 millions en 2015 à 862 millions en 2023, soit une hausse de 245 % (GSMA Intelligence, 2024). Sur la même période, le trafic de données mobiles a été multiplié par 35 (Ericsson Mobility Report, 2023). À l’aune de ces indicateurs, l’Afrique a tout d’une réussite en matière de connectivité.

Mais les taux de pénétration masquent la réalité de la fiabilité. Si 54 % des habitants d’Afrique subsaharienne ont désormais accès à l’internet mobile, seuls 23 % bénéficient de ce que les normes internationales qualifient de « connectivité fiable », c’est-à-dire une disponibilité d’au moins 95 % avec un débit minimal de 3 Mbit/s (Alliance for Affordable Internet, 2024).

Cet écart entre l’accès à la connectivité et sa fiabilité impose une exigence de conception que la plupart des logiciels de gestion ignorent : les systèmes doivent fonctionner hors ligne, et pas seulement en ligne.

Comprendre la réalité de la connectivité

Avant d’examiner les solutions d’architecture, il faut comprendre le contexte d’infrastructure qui façonne l’expérience des utilisateurs sur les marchés africains.

En ville : une connectivité meilleure, mais pas fiable

Même dans les grandes villes africaines, la connectivité reste irrégulière :

Données de disponibilité des réseaux :

• Nairobi : 87 % de disponibilité moyenne pour les services 4G (Communications Authority of Kenya, 2023)
• Lagos : 82 % de disponibilité moyenne (Nigerian Communications Commission, 2023)
• Kampala : 79 % de disponibilité moyenne (Uganda Communications Commission, 2023)
• Dar es Salaam : 76 % de disponibilité moyenne (Tanzania Communications Regulatory Authority, 2023)

Pour situer, une disponibilité de 87 % représente environ 3 heures par jour de coupure ou de service dégradé. Pour une entreprise ouverte 12 heures par jour, cela fait 25 % des heures d’activité sans connexion fiable.

Contraintes d’infrastructure :

• Coupures de courant touchant les antennes-relais : 4 à 8 heures par jour dans les villes secondaires (GSMA Mobile for Development, 2023)
• Saturation du réseau aux heures de pointe (8 h-10 h, 17 h-20 h) : baisse du débit de 60 à 80 % (Ookla Speedtest, 2023a)
• Fibre jusqu’au dernier kilomètre : accessible à seulement 12 % des entreprises africaines (Broadband Commission for Sustainable Development, 2024)
• Alimentation de secours des sites : seuls 34 % des pylônes disposent de batteries offrant plus de 4 heures d’autonomie (African Towers Industry Report, 2023)

Zones rurales et périurbaines : une connexion intermittente, au mieux

Hors des grands centres urbains, le tableau change radicalement :

Couverture et qualité :

• Couverture 2G : 85 % de la population d’Afrique subsaharienne (GSMA Intelligence, 2024)
• Couverture 3G : 65 % de la population (GSMA Intelligence, 2024)
• Couverture 4G : 42 % de la population (GSMA Intelligence, 2024)
• 4G fiable (disponibilité d’au moins 95 %) : 18 % de la population (Gestlat ThinkLab, 2021–2024)

Concrètement, pour les entreprises :

• 67 % des commerces de détail des villes secondaires subissent chaque jour des interruptions de connexion de 30 minutes ou plus (Gestlat ThinkLab, 2021–2024)
• 73 % des entreprises rurales décrivent un accès internet « intermittent » comme leur situation normale (Research ICT Africa, 2023)
• Débit moyen en zone rurale : 1,2 à 3,5 Mbit/s, bien en deçà des 5 Mbit/s et plus nécessaires aux applications dépendantes du cloud (Ookla Speedtest, 2023b)

La contrainte du coût

Même là où la connexion existe, son coût reste prohibitif pour de nombreuses entreprises :

Prix des données mobiles :

• Moyenne en Afrique subsaharienne : 4,50 $ par Go (Cable.co.uk, 2024)
• À comparer à la moyenne mondiale : 1,42 $ par Go (Cable.co.uk, 2024)
• En part du revenu mensuel : 2 à 4 % par Go pour un dirigeant de PME moyen (World Bank, 2023)

Pour une petite boutique dont la gestion de stock dans le cloud consomme 5 à 10 Go par mois, les seules données ajoutent 22 à 45 $ aux charges mensuelles, souvent plus que l’abonnement au logiciel lui-même (Gestlat ThinkLab, 2021–2024).

Accès au Wi-Fi :

• Seules 17 % des PME africaines disposent d’une connexion internet professionnelle dédiée (GSMA, 2023)
• Parmi celles qui ont le Wi-Fi, 64 % partagent leur connexion avec un usage domestique ou plusieurs entreprises, ce qui limite la bande passante (Gestlat ThinkLab, 2021–2024)
• Fiabilité moyenne du Wi-Fi dans les petites entreprises : 72 % de disponibilité (Gestlat ThinkLab, 2021–2024)

Le postulat du tout-cloud : là où il cède

L’industrie mondiale du logiciel s’est alignée sur des architectures « cloud-first » ou « tout-cloud ». Cette approche suppose : 1. une connexion internet permanente 2. une bande passante suffisante 3. des données à un coût abordable 4. une faible latence

Aucune de ces hypothèses ne se vérifie dans la majorité des contextes d’entreprise africains.

Les modes de défaillance observés sur le terrain

Le suivi de 340 PME africaines ayant adopté des systèmes de gestion tout-cloud entre 2021 et 2023 met en évidence les schémas d’échec (Gestlat ThinkLab, 2021–2024) :

Taux d’abandon :

• Dans les 3 mois : 34 % avaient cessé d’utiliser le système (Gestlat ThinkLab, 2021–2024)
• Dans les 6 mois : 56 % étaient revenues aux opérations manuelles (Gestlat ThinkLab, 2021–2024)
• Dans les 12 mois : 68 % avaient totalement abandonné les outils numériques (Gestlat ThinkLab, 2021–2024)

Principales raisons de l’échec (plusieurs réponses possibles) :

• « Inaccessible pendant les coupures de connexion » : 89 % (Gestlat ThinkLab, 2021–2024)
• « Trop lent pendant les heures d’ouverture » : 76 % (Gestlat ThinkLab, 2021–2024)
• « Coût des données trop élevé » : 63 % (Gestlat ThinkLab, 2021–2024)
• « Les clients attendent plus longtemps » : 71 % (Gestlat ThinkLab, 2021–2024)
• « Le personnel a renoncé à l’utiliser » : 54 % (Gestlat ThinkLab, 2021–2024)

Le coût en productivité

Des études temps-mouvements menées dans des entreprises utilisant des systèmes dépendants du cloud chiffrent l’impact quotidien (Gestlat ThinkLab, 2021–2024) :

Temps perdu à cause de la connectivité :

• Attente moyenne de la connexion : 47 minutes par jour (Gestlat ThinkLab, 2021–2024)
• Solutions de contournement (saisie manuelle, ressaisie ultérieure) : 1,2 heure par jour (Gestlat ThinkLab, 2021–2024)
• Double saisie après le retour de la connexion : 34 minutes par jour (Gestlat ThinkLab, 2021–2024)
• Retards du service client dus à l’indisponibilité du système : 28 minutes par jour (Gestlat ThinkLab, 2021–2024)

Perte totale de productivité : 3,2 heures par jour ouvré, soit 27 % d’une journée d’activité de 12 heures (Gestlat ThinkLab, 2021–2024).

Étude de cas : une pharmacie à Mombasa

Une pharmacie de taille moyenne employant 3 personnes a adopté en janvier 2022 un système de gestion de stock et de point de vente dans le cloud. Le déploiement semblait réussi pendant les 2 semaines de test, en présence de l’équipe d’assistance de l’éditeur.

Dans les 30 jours d’exploitation autonome qui ont suivi :

• Coupures de connexion quotidiennes : 4 à 6 épisodes de 25 minutes en moyenne (Gestlat ThinkLab, 2021–2024)
• File d’attente pendant les coupures : de 2-3 à 8-12 personnes (Gestlat ThinkLab, 2021–2024)
• Solutions de contournement : le personnel revenait au papier pendant les coupures et ressaisissait les données plus tard (Gestlat ThinkLab, 2021–2024)
• Taux d’erreur lors de la retranscription du papier vers le numérique : 11 % (Gestlat ThinkLab, 2021–2024)
• Frustration du personnel : « Nous passions plus de temps à gérer le système qu’à servir les clients » (Gestlat ThinkLab, 2021–2024)

Au bout de 90 jours, le propriétaire de la pharmacie a résilié son abonnement et est entièrement revenu aux registres papier. Interrogé, il a déclaré : « Le logiciel n’était pas mauvais, mais il ne fonctionnait que lorsque internet fonctionnait. Je ne peux pas dire à mes clients de revenir quand le réseau de Safaricom sera rétabli. » (Gestlat ThinkLab, 2021–2024)

Ce schéma se répète d’un secteur à l’autre : une technologie prometteuse, sapée par les réalités de l’infrastructure.

Mobile-first ne veut pas dire capable de fonctionner hors ligne

Face aux difficultés de connectivité en Afrique, l’industrie a répondu par la conception « mobile-first ». Mais une conception mobile-first ne garantit pas, à elle seule, le fonctionnement hors ligne.

Définir les termes

Conception mobile-first :

• Interfaces optimisées pour les petits écrans
• Navigation adaptée au tactile
• Mises en page adaptatives (responsive)
• Consommation de bande passante réduite
• Temps de chargement courts

Architecture offline-first (pensée d’abord pour le hors-ligne) :

• Toutes les fonctionnalités disponibles sans connexion internet
• Stockage local des données sur l’appareil
• Synchronisation en arrière-plan dès que la connexion le permet
• Résolution des conflits en cas de modifications simultanées
• Dégradation progressive en cas de connexion partielle

La différence essentielle :

La conception mobile-first améliore l’expérience lorsque vous avez une connexion. L’architecture offline-first garantit que le système fonctionne lorsque vous n’en avez pas.

Un système de point de vente mobile-first se charge peut-être plus vite et consomme moins de données, mais s’il ne peut pas enregistrer une vente quand le Wi-Fi décroche, il est inutilisable dans les contextes africains. Un point de vente offline-first enregistre les ventes, met à jour le stock et consigne les transactions quelle que soit la connexion, puis synchronise les données en arrière-plan quand elle revient.

La confusion du marché

L’analyse de 280 logiciels de gestion commercialisés auprès des PME africaines en 2024 révèle d’importantes présentations trompeuses (Gestlat ThinkLab, 2021–2024) :

• 67 % se disaient « adaptés au mobile » (Gestlat ThinkLab, 2021–2024)
• 43 % se disaient « conçus pour l’Afrique » (Gestlat ThinkLab, 2021–2024)
• Seuls 19 % offraient un véritable fonctionnement hors ligne (Gestlat ThinkLab, 2021–2024)
• Parmi ceux qui revendiquaient un mode hors ligne, seuls 8 % donnaient accès à toutes les fonctionnalités sans connexion (Gestlat ThinkLab, 2021–2024)

L’écart entre les promesses commerciales et la réalité technique alimente des taux d’abandon élevés et un scepticisme croissant à l’égard des outils numériques.

L’architecture technique qui fonctionne

Concevoir des systèmes réellement offline-first suppose des choix d’architecture précis. Voici ce qui fonctionne vraiment dans les contextes africains, d’après les données de déploiement de systèmes utilisés chaque jour par plus de 12 000 utilisateurs actifs en Ouganda, au Kenya et en Tanzanie (Gestlat ThinkLab, 2021–2024).

1. Stockage local des données en priorité

Principe d’architecture : toutes les données résident d’abord sur l’appareil de l’utilisateur. Le cloud sert de sauvegarde et de coordinateur de synchronisation, et non de stockage principal.

Modèle de mise en œuvre :

• SQLite ou une base de données embarquée équivalente sur l’appareil
• Toute la logique métier s’exécute localement
• Aucun appel d’API nécessaire pour les opérations essentielles
• Synchronisation avec le cloud asynchrone, en arrière-plan

Impact sur les performances :

• Traitement des transactions : <100 ms quelle que soit la connexion (Gestlat ThinkLab, 2021–2024)
• Expérience utilisateur : impossible à distinguer d’un système entièrement en ligne (Gestlat ThinkLab, 2021–2024)
• Consommation de batterie : 40 % inférieure à celle des applications dépendantes du cloud (Gestlat ThinkLab, 2021–2024)

Résultat sur le terrain : les commerces équipés de points de vente local-first traitent leurs transactions avec 99,7 % de disponibilité, contre 73 % pour les systèmes dépendants du cloud sur les mêmes marchés (Gestlat ThinkLab, 2021–2024).

2. Synchronisation intelligente en arrière-plan

Principe d’architecture : la synchronisation a lieu de façon opportuniste lorsque la connexion est disponible ; elle n’est pas une condition préalable au fonctionnement.

Modèle de mise en œuvre :

• Surveiller la connexion en continu
• Mettre toutes les modifications en file d’attente localement
• Synchroniser pendant les fenêtres de connexion
• Compresser les données pour limiter la bande passante
• Reprendre automatiquement les synchronisations interrompues

Données sur la stratégie de synchronisation :

D’après la surveillance réseau de 450 systèmes déployés sur 18 mois (Gestlat ThinkLab, 2021–2024) :

• Fenêtres de connexion moyennes : 15 à 45 minutes, 8 à 12 fois par jour (Gestlat ThinkLab, 2021–2024)
• Compression des données : réduction de 65 à 80 % des besoins en bande passante (Gestlat ThinkLab, 2021–2024)
• Synchronisations menées à terme : 94 % des tentatives aboutissent sans intervention de l’utilisateur (Gestlat ThinkLab, 2021–2024)

Résultat sur le terrain : les systèmes se synchronisent avec succès 8,3 fois par jour en moyenne, si bien que les données de l’entreprise atteignent le cloud dans les 2 à 4 heures suivant leur création, même là où la connexion est médiocre (Gestlat ThinkLab, 2021–2024).

3. Une résolution des conflits qui a du sens

Le défi : lorsque plusieurs utilisateurs travaillent hors ligne puis se synchronisent, des modifications contradictoires peuvent survenir (par exemple, deux employés qui vendent le même article en stock).

Principe d’architecture : la résolution des conflits doit être automatique et tenir compte de la logique métier, sans exiger de compétences techniques.

Modèle de mise en œuvre :

• La dernière écriture l’emporte pour les données non critiques (coordonnées, notes)
• Résolution fondée sur les règles métier pour les opérations critiques (stock, transactions financières)
• Rapprochement par horodatage, avec annulation automatique des états impossibles
• Notification de l’utilisateur uniquement lorsqu’une décision manuelle est nécessaire

Données sur la fréquence des conflits :

Analyse de 2,3 millions d’événements de synchronisation dans 94 entreprises (2023-2024) (Gestlat ThinkLab, 2021–2024) :

• Conflits détectés : 0,3 % des événements de synchronisation (Gestlat ThinkLab, 2021–2024)
• Conflits résolus automatiquement : 89 % n’ont demandé aucune intervention de l’utilisateur (Gestlat ThinkLab, 2021–2024)
• Résolution manuelle nécessaire : 11 % des conflits (Gestlat ThinkLab, 2021–2024)
• Incidents de perte de données : 0 sur l’ensemble des déploiements suivis (Gestlat ThinkLab, 2021–2024)

Résultat sur le terrain : les utilisateurs disent que le système « fonctionne, tout simplement » : les conflits se résolvent de façon invisible et l’intégrité des données est préservée sans alourdir l’expérience utilisateur.

4. Enrichissement progressif

Principe d’architecture : des fonctionnalités supplémentaires deviennent disponibles lorsque la connexion le permet, mais les fonctions essentielles n’en dépendent jamais.

Modèle de mise en œuvre :

Niveau hors ligne (disponibilité de 100 %) :

• Traitement des transactions
• Mises à jour du stock
• Fiches clients
• Rapports de ventes
• Analyses de base

Niveau en ligne (connexion requise) :

• Sauvegarde dans le cloud
• Synchronisation multisite
• Analyses avancées
• Intégrations tierces
• Mises à jour logicielles

Résultat sur le terrain : lorsque la connexion est là, les utilisateurs profitent de fonctions enrichies (stock multiboutique en temps réel, intégration automatisée au logiciel de comptabilité). Pendant les coupures, ils perdent quelques commodités mais conservent 100 % des opérations critiques de l’entreprise.

5. Sobriété des données

Principe d’architecture : réduire au minimum la consommation de bande passante pour diminuer les coûts et la durée de synchronisation.

Modèle de mise en œuvre :

• Synchronisation différentielle (seules les données modifiées, pas des bases entières)
• Compression poussée (gzip ou mieux)
• Protocoles binaires plutôt que JSON/XML lorsque c’est possible
• Compression des images et réduction de leur résolution
• Fréquence de synchronisation paramétrable en fonction du coût des données

Données sur l’impact en bande passante :

Comparaison des besoins de synchronisation quotidiens types (Gestlat ThinkLab, 2021–2024) :

Système nativement cloud :

• Transfert de données quotidien : 150 à 300 Mo
• Coût mensuel des données (à 4,50 $/Go) : 20 à 40 $

Système offline-first :

• Transfert de données quotidien : 8 à 15 Mo
• Coût mensuel des données (à 4,50 $/Go) : 1,08 à 2,03 $

Économies annuelles : 227 à 456 $, souvent plus que le coût de l’abonnement au logiciel (Gestlat ThinkLab, 2021–2024).

Résultats de déploiement : les données

La théorie est intéressante. Les résultats comptent. Voici ce que l’architecture offline-first produit dans des déploiements africains réels.

Indicateurs d’adoption et d’utilisation

Étude comparative : 127 PME, 2022-2024 (Gestlat ThinkLab, 2021–2024)

Déploiement en deux groupes : 64 entreprises ont reçu des systèmes offline-first, 63 des systèmes tout-cloud équivalents.

Taux d’adoption à 30 jours :

• Offline-first : 94 % d’utilisation active quotidienne (Gestlat ThinkLab, 2021–2024)
• Tout-cloud : 67 % d’utilisation active quotidienne (Gestlat ThinkLab, 2021–2024)

Rétention à 90 jours :

• Offline-first : 89 % utilisent encore le système chaque jour (Gestlat ThinkLab, 2021–2024)
• Tout-cloud : 51 % utilisent encore le système chaque jour (Gestlat ThinkLab, 2021–2024)

Rétention à 12 mois :

• Offline-first : 85 % utilisent encore le système chaque jour (Gestlat ThinkLab, 2021–2024)
• Tout-cloud : 34 % utilisent encore le système chaque jour (Gestlat ThinkLab, 2021–2024)

Satisfaction des utilisateurs

Net Promoter Score (NPS) après 6 mois :

• Systèmes offline-first : +47 (Gestlat ThinkLab, 2021–2024)
• Systèmes tout-cloud : -12 (Gestlat ThinkLab, 2021–2024)

Thèmes des retours utilisateurs :

Retours positifs les plus fréquents sur l’offline-first (n=64) (Gestlat ThinkLab, 2021–2024) : 1. « Ça marche tout le temps » - 89 % 2. « On ne remarque pas quand internet est coupé » - 84 % 3. « Plus rapide que notre ancien système manuel » - 76 % 4. « Le personnel s’en sert vraiment » - 71 %

Plaintes les plus fréquentes sur le tout-cloud (n=63) (Gestlat ThinkLab, 2021–2024) : 1. « Ça ne marche pas quand on en a besoin » - 91 % 2. « Les clients s’impatientent » - 78 % 3. « Le personnel évite de s’en servir » - 69 % 4. « Trop cher avec le coût des données » - 64 %

Impact sur l’activité

Indicateurs de productivité (suivi sur 6 mois) :

Vitesse de traitement des transactions :

• Offline-first : 23 secondes en moyenne par transaction (Gestlat ThinkLab, 2021–2024)
• Tout-cloud : 47 secondes en moyenne par transaction (avec connexion), plus de 3 minutes en connexion partielle (Gestlat ThinkLab, 2021–2024)

Indisponibilité quotidienne du système :

• Offline-first : 6 minutes en moyenne (surtout des plantages de l’application, résolus par un redémarrage) (Gestlat ThinkLab, 2021–2024)
• Tout-cloud : 3,2 heures en moyenne (indisponibilité liée à la connexion) (Gestlat ThinkLab, 2021–2024)

Impact sur le chiffre d’affaires :

• Entreprises offline-first : hausse moyenne du chiffre d’affaires de 18 % dans les 6 mois suivant le déploiement (Gestlat ThinkLab, 2021–2024)
• Entreprises tout-cloud : hausse moyenne de 7 % (freinée par les problèmes de disponibilité) (Gestlat ThinkLab, 2021–2024)

Réponses aux objections courantes

« Mais tout le monde passe au cloud »

C’est vrai, sur les marchés où la connexion est fiable et la bande passante abordable. La stratégie cloud-first est pertinente là où l’infrastructure la permet.

La question n’est pas de savoir si le cloud est l’avenir. Elle est de savoir si l’infrastructure actuelle permet de dépendre du cloud. Dans la plupart des contextes africains, ce n’est pas le cas.

L’architecture offline-first ne rejette pas le cloud : elle l’utilise intelligemment comme couche de synchronisation et de sauvegarde, plutôt que comme point de défaillance unique.

« L’offline-first est plus complexe à développer »

C’est vrai aussi, au départ. L’architecture offline-first exige une ingénierie plus poussée :

• Gestion d’une base de données locale
• Conception d’un protocole de synchronisation
• Logique de résolution des conflits
• Garanties de cohérence des données

Mais cette complexité se situe dans la phase d’ingénierie, pas dans l’expérience utilisateur. Le résultat est plus simple pour les utilisateurs : un logiciel qui fonctionne quelle que soit la connexion.

Le développement d’un système offline-first coûte généralement 30 à 40 % de plus qu’un système tout-cloud (Gestlat ThinkLab, 2021–2024). Mais quand les systèmes tout-cloud affichent 66 % d’abandon en 12 mois, ce surcoût de développement devient secondaire (Gestlat ThinkLab, 2021–2024).

« Les utilisateurs se moquent de la technologie »

C’est exact. Ce qui compte pour les utilisateurs, c’est que le système fonctionne quand ils en ont besoin.

Quand la connexion est fiable, systèmes tout-cloud et offline-first paraissent identiques aux utilisateurs. Quand elle ne l’est pas, les systèmes tout-cloud deviennent des obstacles tandis que les systèmes offline-first restent invisibles, ce qui est le plus beau compliment qu’on puisse faire à une technologie.

Les retours des utilisateurs le montrent constamment : ils ne comprennent pas les termes d’architecture et ne s’en soucient pas. Ils décrivent les systèmes offline-first comme « fiables », « rapides » et « toujours fonctionnels ». Ils décrivent les systèmes tout-cloud comme « frustrants », « lents » et « peu fiables » (Gestlat ThinkLab, 2021–2024).

« C’est un problème temporaire : l’infrastructure s’améliore »

L’infrastructure s’améliore, sans aucun doute. La couverture 4G s’est considérablement étendue. Le déploiement de la fibre se poursuit. Starlink et d’autres offres satellitaires font leur apparition.

Mais « s’améliorer » ne veut pas dire « être résolu ». Selon les projections de croissance de la GSMA, une couverture 4G fiable n’atteindra pas 75 % des entreprises d’Afrique subsaharienne avant 2029 (GSMA Intelligence, 2024). Cela laisse cinq ans de plus, soit un cycle complet de planification d’entreprise, pendant lesquels la capacité hors ligne reste indispensable.

Et même sur des marchés couverts à 95 % ou plus, la disponibilité compte. Un système tout-cloud qui fonctionne 95 % du temps empêche encore les entreprises de travailler 3,6 heures par jour.

La question n’est pas de construire en offline-first « en attendant que l’infrastructure s’améliore ». Elle est de savoir si les entreprises peuvent se permettre des systèmes qui tombent en panne 5 à 25 % du temps, dans l’attente d’améliorations d’infrastructure encore théoriques.

Principes de conception : ce qui fonctionne

Fondés sur plus de 450 déploiements et 18 mois de données d’utilisation, ces principes guident les systèmes offline-first réussis sur les marchés africains (Gestlat ThinkLab, 2021–2024) :

1. Considérer la déconnexion comme normale

Concevez le hors-ligne comme état par défaut. La connexion est un atout qui débloque des fonctions supplémentaires, pas une condition préalable aux fonctions essentielles.

2. Réduire au minimum le transfert de données

Chaque Ko compte quand les données coûtent 4,50 $/Go. Compressez au maximum. Synchronisez les différences, pas des jeux de données entiers. Utilisez des protocoles binaires dès que possible.

3. Rendre la synchronisation invisible

Les utilisateurs ne devraient pas avoir à penser à la synchronisation. Elle doit se faire en arrière-plan, aboutir automatiquement et n’apparaître aux utilisateurs que lorsqu’une intervention manuelle est inévitable.

4. Privilégier la vitesse

L’architecture local-first permet des temps de réponse inférieurs à 100 ms. Tirez-en parti. Chaque seconde d’attente crée de la friction et freine l’adoption.

5. Bâtir la résolution des conflits sur la logique métier

Les développeurs raisonnent en « stratégies de fusion » et en « CRDT ». Les utilisateurs se demandent « pourquoi est-ce arrivé et comment je corrige ? ». Une résolution automatique fondée sur les règles métier vaut toujours mieux que des messages de conflit techniques.

6. Tester en conditions réelles

Des tests en laboratoire avec un Wi-Fi parfait ne prouvent rien. Testez avec une 2G intermittente. Testez en mode avion. Testez sur des réseaux saturés aux heures de pointe. Testez dans des environnements qui reproduisent les conditions réelles des utilisateurs.

Conclusion : l’architecture comme condition d’accès

Choisir entre tout-cloud et offline-first n’est pas une préférence technique : c’est décider qui pourra accéder à votre logiciel.

L’architecture tout-cloud fonctionne à merveille à Manhattan, à Londres ou à Singapour, des marchés à la connectivité quasi parfaite et à la bande passante abondante. Elle échoue à Kampala, à Nairobi ou à Lagos, des marchés où la connexion progresse mais reste loin d’être fiable.

Concevoir des systèmes offline-first exige une ingénierie plus poussée. Le développement coûte plus cher. La maintenance est plus complexe. Mais le résultat est un logiciel qui fonctionne réellement pour des utilisateurs confrontés aux conditions de connexion africaines telles qu’elles sont.

Les données sont sans équivoque :

• 85 % de rétention contre 34 % (Gestlat ThinkLab, 2021–2024)
• 94 % d’utilisation quotidienne contre 67 % (Gestlat ThinkLab, 2021–2024)
• NPS de +47 contre -12 (Gestlat ThinkLab, 2021–2024)
• 18 % de croissance du chiffre d’affaires contre 7 % (Gestlat ThinkLab, 2021–2024)

L’architecture offline-first n’est pas seulement une meilleure ingénierie : c’est ce qui sépare un logiciel qu’on utilise d’un logiciel qu’on abandonne.

Pour tout éditeur présent sur les marchés africains, la question n’est pas de savoir s’il faut investir dans le fonctionnement hors ligne. Elle est de savoir si vous concevez vos logiciels pour l’Afrique que vous imaginez, ou pour l’Afrique telle qu’elle est.

Nous avons choisi la réalité.

Références

African Towers Industry Report. (2023). Infrastructure resilience assessment.

Alliance for Affordable Internet. (2024). The state of mobile internet connectivity 2024.

Broadband Commission for Sustainable Development. (2024). The state of broadband 2024: Africa focus.

Cable.co.uk. (2024). Worldwide mobile data pricing 2024.

Communications Authority of Kenya. (2023). Quality of service report Q4 2023.

Ericsson Mobility Report. (2023). Sub-Saharan Africa mobility report.

Gestlat ThinkLab. (2021–2024). Internal implementation and field research data [Données brutes non publiées].

GSMA. (2023). Digital transformation among African SMEs.

GSMA Intelligence. (2024). Mobile economy: Sub-Saharan Africa 2024.

GSMA Mobile for Development. (2023). Power outages and mobile network reliability in Africa.

Nigerian Communications Commission. (2023). Quality of service annual report 2023.

Ookla Speedtest. (2023a). Global index: Network performance analysis – Sub-Saharan Africa.

Ookla Speedtest. (2023b). Rural internet speeds: Sub-Saharan Africa analysis.

Research ICT Africa. (2023). Connectivity in rural and peri-urban Africa.

Tanzania Communications Regulatory Authority. (2023). Quality of service monitoring report.

Uganda Communications Commission. (2023). Quality of service report 2023.

World Bank. (2023). Income and expenditure patterns: African SME survey.