Pourquoi le hors-ligne d’abord n’est pas optionnel sur nos marchés

Beaucoup de logiciels sont construits et testés sur la fibre d’un bureau, puis livrés à des personnes sur un réseau mobile saturé. Le résultat : une interface qui tourne indéfiniment et perd ce que l’utilisateur a saisi.

La perte de connexion est la norme, pas l’exception

Traiter une requête interrompue comme un état d’erreur est l’erreur de fond. Pour un livreur dans un sous-sol ou un enseignant dans une école rurale, perdre la connexion est le cas ordinaire. Le produit doit l’absorber plutôt que s’en plaindre.

Rendez chaque écriture idempotente

Dès lors que l’on accepte que les requêtes seront réessayées, il faut rendre ces relances sûres. Chaque opération qui modifie des données a besoin d’une clé générée par le client, afin que le serveur reconnaisse un doublon et renvoie le résultat initial au lieu d’exécuter l’action deux fois.

Cette seule décision élimine toute une catégorie de bugs : le double débit, la commande en double, le pointage enregistré deux fois.

Décidez à l’avance de ce qui se passe en cas de conflit

Si deux personnes modifient le même enregistrement hors ligne, l’une doit l’emporter. La dernière écriture gagne : acceptable pour un brouillon, inadmissible pour un solde. Choisir cela par type de donnée, tôt, évite de le découvrir en production.

Budgétez la page, pas seulement la fonctionnalité

La tolérance au hors-ligne ne sert à rien si le premier chargement n’aboutit jamais. Nous fixons un budget de poids de page dès le départ et le contrôlons en CI, car une performance qui n’est pas mesurée à chaque merge se dégrade silencieusement.