Oui, une application peut fonctionner sans connexion internet. Elle enregistre les données sur le téléphone, laisse l'utilisateur travailler normalement, puis envoie tout au serveur dès que le réseau revient. Cette approche, dite « hors ligne d'abord », doit être prévue dès la conception. Dans beaucoup de zones d'Afrique de l'Ouest, et dans bien des campagnes françaises, c'est la condition pour qu'un outil de terrain soit réellement utilisé.
Pourquoi tant d'applications échouent-elles sur le terrain ?
Parce qu'elles ont été pensées dans un bureau, avec la fibre et un téléphone récent. Le développeur teste, tout répond en une seconde, la démonstration est parfaite. Puis l'application part dans la poche d'un agent de collecte, d'un technicien ou d'un livreur, et la réalité s'impose : le réseau disparaît dès qu'on quitte l'axe principal, le débit s'effondre aux heures chargées, le forfait de données est compté, l'électricité manque pour recharger.
L'agent ouvre l'application, voit une roue qui tourne, attend, recommence. Au troisième échec, il ressort son carnet. Il n'a pas tort : son travail est de faire sa tournée, pas d'attendre un écran. L'outil est abandonné sans que personne ne l'ait décidé, et le siège continue de recevoir des feuilles en fin de semaine.
Qu'est-ce qu'une application « hors ligne d'abord » ?
C'est une application qui considère l'absence de réseau comme la situation normale, et la connexion comme une bonne surprise. Concrètement, trois mécanismes travaillent ensemble.
- Une base de données locale. Le téléphone garde une copie des informations utiles à l'agent : sa liste de clients, son catalogue, ses tournées, ses formulaires. Il les consulte instantanément, réseau ou pas.
- Une file d'attente. Chaque saisie, visite, commande, relevé, photo, est enregistrée sur l'appareil et placée dans une file d'envoi. L'agent voit que son travail est sauvegardé et passe au suivant.
- Une synchronisation discrète. Dès qu'une connexion est disponible, même faible, l'application vide la file par petits paquets et récupère les nouveautés du serveur. Si l'envoi est interrompu, il reprend là où il s'était arrêté.
L'utilisateur n'a rien à faire, sinon ouvrir l'application de temps en temps dans une zone couverte. Un indicateur simple lui montre ce qui est déjà transmis et ce qui attend encore.
| Application classique | Application hors ligne d'abord | |
|---|---|---|
| Sans réseau | Bloquée ou inutilisable | Fonctionne normalement |
| Réseau faible | Lente, erreurs, saisies perdues | Réactive, envoi différé |
| Données mobiles | Consommées à chaque écran | Consommées seulement lors des synchronisations |
| Remontée d'information | Immédiate ou inexistante | Immédiate si possible, sinon dès le retour du réseau |
| Conception | Plus simple | Plus exigeante, à prévoir dès le départ |
Que se passe-t-il si deux personnes modifient la même donnée ?
C'est la vraie difficulté du hors ligne, et la question à poser à tout prestataire. Imaginez deux agents qui mettent à jour la fiche du même client sans réseau. Ou un gestionnaire au siège qui modifie un prix pendant qu'un vendeur déconnecté prend une commande à l'ancien tarif. Quand tout le monde se synchronise, qui a raison ?
Il n'existe pas de réponse automatique valable partout. Ce sont des règles de gestion, à décider avec vous :
- pour une information simple, la dernière modification peut l'emporter ;
- pour un stock, on n'écrase pas une quantité, on additionne des mouvements, entrées et sorties, ce qui évite presque tous les conflits ;
- pour un prix, on retient en général celui qui était affiché à l'agent au moment de la vente, et on signale l'écart ;
- pour les cas sensibles, on soumet le conflit à un responsable qui tranche.
Une application sérieuse prévoit ces cas. Une application fragile les ignore, et les données se dégradent sans bruit jusqu'au jour où plus personne ne leur fait confiance.
Un cas typique : une coopérative agricole en Haute-Guinée
Une coopérative collecte la production de plusieurs centaines de producteurs répartis dans des villages éloignés de toute couverture stable. Ses agents pesaient les récoltes, notaient les quantités dans des cahiers, et rapportaient le tout au bureau en fin de semaine. La saisie prenait des jours, les producteurs contestaient parfois les poids, et la direction ne connaissait ses volumes qu'avec retard.
Une première application avait été essayée : il fallait du réseau pour enregistrer chaque pesée. Elle n'a pas tenu une campagne. La seconde a été conçue à l'envers. L'agent part le matin avec la liste des producteurs déjà dans son téléphone. Il enregistre chaque pesée sur place et remet un reçu au producteur. Rien ne dépend du réseau. Le soir, en revenant vers le bourg, le téléphone retrouve une connexion et transmet la journée sans que l'agent s'en occupe. Le lendemain matin, la direction voit les volumes collectés par zone.
Les agents ont adopté l'outil parce qu'il leur faisait gagner du temps, là où le premier leur en faisait perdre. C'est le critère qui compte, nous y revenons dans notre article sur la façon de digitaliser les équipes de terrain avec le mobile.
Quels choix de conception font la différence ?
Le hors ligne ne suffit pas. D'autres décisions, moins visibles, séparent un outil agréable d'un outil pénible.
- Une application légère. Elle doit s'installer et tourner sur des téléphones d'entrée de gamme, avec peu de mémoire.
- Des échanges sobres. Photos compressées avant envoi, synchronisation limitée à ce qui a changé, aucune donnée inutile.
- Des envois qui reprennent. Une photo interrompue à mi-chemin ne doit pas repartir de zéro.
- Une batterie ménagée. La localisation en continu et les synchronisations trop fréquentes vident un téléphone avant la fin de la tournée.
- Des données protégées. Ce qui est stocké sur l'appareil doit être chiffré et effaçable à distance en cas de perte.
- Une saisie rapide. Listes de choix, valeurs par défaut, gros boutons : en plein soleil, on ne remplit pas un formulaire de vingt champs.
Quelles questions poser à votre prestataire ?
Avant de signer, demandez une démonstration en mode avion. C'est le test le plus parlant. Puis posez quelques questions simples : que peut faire l'utilisateur sans réseau, et que ne peut-il pas faire ? Combien de temps peut-il travailler déconnecté ? Comment sont réglés les conflits ? Que devient une saisie si le téléphone s'éteint brutalement ? Comment sait-on, au siège, qu'un appareil n'a pas synchronisé depuis trois jours ?
Les réponses vous diront vite si le sujet a été traité ou simplement survolé. Elles conditionnent toute la chaîne, de la saisie jusqu'aux indicateurs de pilotage décrits dans du terrain au tableau de bord : un tableau de bord alimenté par des données qui n'arrivent pas ne sert à rien.
Vos équipes travaillent dans des zones où le réseau est capricieux ? Décrivez-nous leurs conditions réelles. C'est toujours par là que nous commençons.
Pour équiper des équipes qui travaillent avec une connectivité irrégulière, découvrez nos applications mobiles terrain ou estimez votre projet.