Application hors connexion : quand le réseau manque

Une cave à inspecter, un parking souterrain, un chantier en zone rurale, un entrepôt aux murs épais : le terrain est souvent là où le réseau ne passe pas. Une application qui affiche un message d’erreur à ce moment-là perd la partie. Le technicien note sur un carnet, photographie avec l’appareil du téléphone, et tout repart dans le trajet que l’application devait supprimer : ressaisie le soir, photos égarées, information qui arrive avec un jour de retard.

Le hors ligne n’est pas un bouton qu’on coche dans un devis. C’est une suite de décisions, de la plus simple à la plus coûteuse, qu’il vaut mieux prendre en connaissance de cause.

Les trois niveaux du hors ligne

Dire qu’une application « fonctionne hors ligne » peut vouloir dire trois choses très différentes.

1. 01Elle s’ouvre.

   Les écrans sont gardés sur le téléphone : l’application se lance sans réseau, au lieu d’afficher une page blanche. Ses données, elles, demandent une connexion pour se mettre à jour.

2. 02Elle se consulte.

   Les dossiers déjà ouverts (la fiche du client, le plan, la liste des interventions du jour) restent lisibles, avec la date de leur dernière mise à jour.

3. 03Elle enregistre.

   Les saisies, cases cochées et photos sont gardées sur le téléphone, puis envoyées au serveur au retour du réseau, sans rien perdre ni rien envoyer deux fois.

Chaque niveau s’appuie sur le précédent, et chacun ajoute du travail. Le premier est presque un réglage. Le deuxième demande de choisir ce que le téléphone garde, et pour combien de temps. Le troisième change l’architecture de l’application.

Ce que le hors ligne change pour l’équipe

Le bénéfice ne se mesure pas en fonctionnalités, mais en gestes que l’équipe n’a plus à faire.

• Saisir sur place, une seule fois. Le constat se fait devant l’équipement, pas de mémoire en remontant au camion. Les détails qu’on oublie en vingt minutes restent dans le dossier.
• Plus de double circuit. Sans hors ligne, l’équipe garde le carnet « au cas où », et la ressaisie revient. Avec, le carnet disparaît vraiment.
• Une preuve datée. La photo et l’heure de l’intervention sont attachées au dossier au moment où elles sont prises, et non au moment où le réseau revient.
• Moins d’attente. Personne ne cherche une barre de réseau en tenant son téléphone en l’air avant de pouvoir passer à la tâche suivante.

Ces gains supposent que l’application soit déjà adoptée : les conditions d’adoption, écrans courts et connexion sans friction, sont détaillées dans ce qu’une application terrain change pour vos équipes.

Le vrai sujet : la synchronisation

Enregistrer sur le téléphone est la partie facile. Le travail est dans le retour du réseau.

Trois questions décident de la qualité de ce trajet.

Ne rien envoyer deux fois. Un envoi interrompu sera retenté. Si chaque saisie porte un identifiant unique créé sur le téléphone, le serveur reconnaît un envoi déjà reçu et ne crée pas de doublon.

Ne pas faire confiance à l’horloge du téléphone. Elle se règle à la main. L’heure de la saisie peut être notée par le téléphone pour information, mais ce qui compte (le jour d’une intervention, un délai) se valide côté serveur, comme nous l’expliquons dans la sécurité d’une application.

Savoir qui a raison. Deux techniciens modifient la même fiche, chacun dans un sous-sol. Le premier qui retrouve le réseau envoie sa version ; le second écrase-t-il la première ? Firestore, la base de Google pour les applications, l’écrit clairement dans sa documentation sur le hors ligne : pour plusieurs modifications d’un même document, c’est la dernière écriture qui gagne.

Web installable ou application des stores

Le choix entre une application web installable et une application native, comparé dans PWA ou application native, prend une couleur particulière quand le réseau manque.

Les limites du web sont documentées. WebKit, le moteur de Safari, décrit dans sa politique de stockage de 2023 une éviction automatique des données d’un site quand le quota est dépassé, quand l’appareil manque de place ou quand le site n’a pas servi depuis un moment. L’interface qui permet à une application web de différer un envoi jusqu’au retour du réseau n’est pas disponible dans plusieurs navigateurs parmi les plus utilisés, selon la documentation de MDN. Et sur le web, la persistance hors ligne de Firestore est désactivée par défaut, avec un conseil : demander à l’utilisateur s’il est sur un appareil de confiance avant de garder des données sensibles.

Côté natif, une application construite avec Expo dispose d’une base SQLite sur le téléphone, qui persiste d’un redémarrage à l’autre. Le choix du back-end compte aussi : Firestore prévoit le hors ligne de série sur Android et iPhone, alors qu’une base Postgres comme celle de Supabase demande d’organiser la synchronisation, comme le détaille Supabase, Firebase ou serveur à soi.

Pour un outil interne qui doit surtout s’ouvrir et se consulter sans réseau, l’application installable suffit souvent. Quand des saisies importantes doivent survivre à une journée sans réseau, l’application native est plus sûre.

Ce que ça coûte, et quand s’en passer

Le hors ligne complet est l’une des décisions qui font le plus varier le prix d’une application : il touche chaque écran de saisie, ajoute des tests (couper le réseau au milieu d’un envoi, deux téléphones sur la même fiche) et se maintient à chaque version, comme le reste du budget de maintenance.

On peut s’en passer quand les coupures sont courtes et rares, quand la saisie peut attendre quelques minutes, ou quand l’application sert surtout à consulter. On ne peut pas s’en passer quand l’équipe passe des heures sans réseau, ou quand une saisie perdue a un coût réel : un constat contestable, une livraison non prouvée, une intervention refacturée.

Par où commencer

1. 01Relever les zones blanches.

   Pendant deux semaines, l’équipe note où le réseau manque, et combien de temps.

2. 02Classer les gestes.

   Lesquels doivent se faire sans réseau (saisir un constat, prendre une photo), lesquels peuvent attendre (consulter l’historique complet).

3. 03Écrire les règles de conflit.

   Pour chaque donnée modifiable à plusieurs, qui gagne.

4. 04Tester sans réseau.

   Sur une première version, en mode avion, avec les personnes qui s’en serviront.

Ces choix s’écrivent dans le cahier des charges de l’application et se testent tôt sur une maquette cliquable. Les autres décisions d’un projet ont chacune leur article : sur mesure ou outil du marché, publier sous son propre compte développeur, les notifications, l’abonnement, le portail client, l’IA dans une application, la reprise d’une application abandonnée, le low-code et le vibe coding.

Notre développement d’applications commence par un cadrage écrit : ce que l’application fait le premier jour, avec ou sans réseau.

Questions fréquentes

Sources

1. Documentation Firebase, accès aux données hors ligne (nouvel onglet)firebase.google.com
2. WebKit, mise à jour de la politique de stockage, août 2023 (nouvel onglet)webkit.org
3. MDN, Background Synchronization API (nouvel onglet)developer.mozilla.org
4. Documentation d’Expo, SQLite (nouvel onglet)docs.expo.dev