L'hypothèse par défaut dans le développement logiciel moderne est que l'appareil est connecté à internet. Les API sont appelées en temps réel, les données sont récupérées à la demande et les états hors ligne sont traités comme des conditions d'erreur. Cette hypothèse s'effondre complètement dans les opérations terrain FMCG, où les commerciaux visitent régulièrement des magasins dans des zones sans couverture cellulaire, avec une qualité réseau peu fiable ou des forfaits data prohibitivement chers. Pour que les applications FMCG apportent de la valeur dans ces environnements, la capacité hors ligne ne peut pas être un ajout après coup. Elle doit être la fondation.
Le premier défi d'ingénierie est la base de données locale. Un commercial terrain a besoin d'accéder à l'intégralité de son répertoire client, catalogue produits, règles de tarification, soldes en cours, historique de commandes et plan de tournée, le tout disponible sans accès réseau. Pour un distributeur de taille moyenne, cela peut représenter 20 000 fiches clients, 5 000 références avec images et tarifs, et 100 000 enregistrements de transactions récentes. Ces données doivent être stockées dans une base de données locale sur l'appareil, indexées pour une recherche rapide et maintenues à jour via une synchronisation en arrière-plan.
SQLite est le moteur de stockage sur appareil dans ce contexte. Il fournit les capacités de requêtes relationnelles nécessaires pour des recherches complexes (trouver tous les clients de ce territoire avec des soldes en cours au-dessus d'un seuil) sans la charge d'un serveur de base de données complet. Sur les smartphones modernes, une base SQLite bien indexée gère les volumes de données typiques des opérations FMCG avec des temps de requête inférieurs à la milliseconde. Le défi n'est pas la performance des requêtes mais la gestion des données : maintenir la base de données locale synchronisée avec le serveur de référence.
La synchronisation delta est la stratégie qui rend la synchronisation continue pratique. Plutôt que de télécharger l'ensemble des données à chaque synchronisation, le système suit les changements depuis la dernière synchronisation réussie et ne transfère que les enregistrements modifiés. Un delta quotidien typique pour un distributeur avec 20 000 clients peut inclure 50-200 enregistrements modifiés, nouveaux clients, soldes mis à jour, changements de prix et modifications de tournées. Cela maintient la synchronisation rapide et économe en bande passante, critique pour les appareils sur des connexions cellulaires facturées au volume.
Le protocole de synchronisation gère la complexité inhérente du flux de données bidirectionnel. L'appareil reçoit des mises à jour du serveur (nouveaux clients, changements de prix) et envoie des mises à jour en retour (commandes capturées, fiches de visite, journaux d'appels). La résolution de conflits est nécessaire quand le même enregistrement est modifié des deux côtés entre les synchronisations. Le système utilise une stratégie de dernier écrivain gagnant pour les données dont le serveur fait autorité (tarification, soldes) et une stratégie de fusion pour les données générées par l'utilisateur (brouillons de commande, notes de visite), garantissant qu'aucune donnée capturée sur le terrain n'est perdue.
Le pré-chargement est la synchronisation initiale qui provisionne un nouvel appareil ou reprovisionne après une réinitialisation de données. C'est l'opération la plus lourde, pouvant transférer des centaines de mégaoctets de données incluant les images produits. Le système gère cela par des téléchargements par morceaux avec capacité de reprise, de sorte qu'un pré-chargement interrompu par une perte de réseau peut continuer là où il s'est arrêté plutôt que de recommencer. Les images produits sont téléchargées en résolution compressée pour le chargement initial, avec les images en pleine résolution récupérées à la demande quand la connectivité est disponible.
La planification de la synchronisation en arrière-plan équilibre la fraîcheur des données avec la consommation de batterie et de bande passante. Le système se synchronise quand l'appareil est sur WiFi et en charge (synchronisation delta complète), quand le cellulaire est disponible et que la dernière synchronisation dépasse un seuil configurable (synchronisation delta prioritaire couvrant uniquement les soldes et la tarification), et quand l'utilisateur déclenche explicitement une synchronisation avant de commencer sa tournée. Chaque stratégie de synchronisation transfère des sous-ensembles de données différents pour optimiser selon les conditions disponibles.
La capture de commandes en mode hors ligne nécessite une ingénierie soignée. Quand un commercial crée une commande sans connectivité, la commande est stockée localement avec un statut en attente. Elle inclut toutes les données nécessaires à l'exécution : identifiant client, liste de produits avec quantités et prix, conditions de paiement et toute condition promotionnelle. Quand la connectivité est restaurée, les commandes en attente sont envoyées au serveur en séquence chronologique. Le serveur valide chaque commande par rapport aux données actuelles (limites de crédit, disponibilité des stocks) et retourne une confirmation ou un rejet. Les commandes rejetées sont signalées sur l'appareil pour que le commercial les examine et les ajuste.
Le pattern d'amélioration progressive garantit que l'application fournit une fonctionnalité de base complète hors ligne tout en tirant parti de la connectivité quand elle est disponible. Les workflows de base comme la capture de commandes, la recherche de clients et la navigation de tournée fonctionnent entièrement hors ligne. Les fonctionnalités améliorées comme la reconnaissance de rayon en temps réel (qui nécessite un traitement GPU côté serveur), les vérifications d'inventaire en direct et le traitement instantané des paiements s'activent quand la connectivité est disponible. L'interface indique clairement quelles fonctionnalités sont disponibles dans l'état de connectivité actuel, définissant les bonnes attentes.
La gestion des images est un défi spécifique au domaine FMCG. Les photos de rayon pour la reconnaissance font généralement 3 à 5 mégaoctets chacune. En mode hors ligne, les photos sont capturées et stockées localement. Elles sont envoyées pour traitement quand la bande passante est disponible, les résultats étant synchronisés en retour sur l'appareil. Le système met les photos en file d'attente intelligemment, priorisant les captures récentes et mettant en pause les envois quand la bande passante est limitée. Cela évite qu'un arriéré de photos de rayon ne consomme l'intégralité du forfait data du commercial.
Tester des applications hors ligne en priorité nécessite une approche différente du logiciel connecté traditionnel. La matrice de test doit couvrir les transitions entre états de connectivité : démarrer hors ligne, passer en ligne en cours de workflow, perdre la connexion pendant une synchronisation et retrouver la connexion avec des données locales obsolètes. Les tests automatisés simulent ces conditions systématiquement, mais les tests les plus précieux proviennent des essais terrain dans des environnements réels à faible connectivité où l'application doit faire ses preuves dans des conditions réelles.
Les marchés émergents où les opérations terrain FMCG sont les plus actives, en Asie du Sud-Est, en Afrique subsaharienne, en Asie du Sud et en Amérique latine, sont précisément les marchés où la connectivité est la moins fiable. Construire en hors ligne prioritaire n'est pas une fonctionnalité premium pour ces marchés. C'est un prérequis pour toute application qui s'attend à être utilisée quotidiennement par les équipes terrain. L'investissement en ingénierie est significatif, mais l'alternative est de construire un logiciel qui échoue précisément quand et où il est le plus nécessaire.