La plupart des logiciels supposent que le réseau est là. Ils supposent qu'une passerelle de paiement répond en moins d'une seconde, qu'une synchronisation tourne discrètement en arrière-plan, et qu'une requête échouée peut simplement être relancée. Construisez sur ces hypothèses à Kinshasa, à Lubumbashi ou dans une ville de l'intérieur, et le produit cesse de fonctionner au moment précis où il compte le plus.
L'offline-first n'est pas une fonctionnalité qu'on ajoute plus tard. C'est une décision sur le lieu où réside la vérité. Dans une application connectée, le serveur détient l'enregistrement et le client l'affiche. Dans une application offline-first, l'appareil détient un véritable enregistrement et le serveur réconcilie. Cette inversion touche votre modèle de données, vos identifiants, votre gestion des conflits et toute votre stratégie de test — ce qui explique pourquoi l'ajouter après coup coûte si cher.
Les conséquences pratiques sont précises. Générez les identifiants côté client, pas côté serveur, pour qu'un enregistrement créé sans connexion n'attende jamais la permission d'exister. Stockez un journal d'opérations plutôt que d'écraser l'état, afin que deux appareils ayant modifié le même client puissent être fusionnés au lieu qu'un seul l'emporte silencieusement. Rendez chaque écriture idempotente, car une requête expirée a très bien pu aboutir.
Le cash change aussi la conception. Une transaction réglée en billets n'a aucun callback de passerelle à attendre ni réconciliation automatique. Le système doit enregistrer une intention, laisser un humain la confirmer, et maintenir l'écart entre ces deux états sans perdre ni l'un ni l'autre. Les équipes habituées aux flux par carte modélisent cela comme un cas limite ; dans une économie dominée par le cash, c'est le chemin principal.
Rien de tout cela n'est de l'ingénierie exotique. C'est la discipline ordinaire consistant à ne pas supposer que ses propres conditions sont universelles. Construisez pour une connectivité intermittente et pour le cash, et le produit fonctionnera parfaitement sur la fibre à Francfort. Construisez dans l'autre sens et il échouera partout où les hypothèses ne tiennent pas — c'est-à-dire, à l'échelle mondiale, dans la plupart des endroits.