Une application hors ligne permet de consulter des données et, selon sa conception, de travailler sans connexion Internet, puis de synchroniser les modifications lorsque le réseau revient. Cette approche, appelée « offline-first » lorsqu’elle est prévue dès la conception, concerne tout ou partie des fonctions essentielles d’une application, comme l’explique la documentation Android consacrée aux applications hors ligne.

Pour une PME, la question n’est donc pas seulement : « Est-ce que l’application s’ouvre sans réseau ? » C’est plutôt : « Est-ce que mon équipe peut terminer sa mission sans perdre son travail ni créer de problème au bureau ? »

Un contrôle dans un sous-sol, un inventaire dans un entrepôt, une visite de chantier : prenons ces situations comme exemples de travail à assurer sans connexion. Voici les sept pièges à éviter, les choix à faire avant de développer et les tests à demander avant de déployer.

Quelles fonctions une application hors ligne doit-elle assurer ?

Une application hors ligne doit assurer les tâches nécessaires pendant la coupure, pas reproduire tout le système d’information de l’entreprise. Commencez par distinguer la consultation, la saisie locale et les actions qui exigent une confirmation du serveur.

Le bon périmètre se décrit avec des verbes métier : consulter une fiche équipement, relever une mesure, ajouter une photo, préparer un compte rendu. « Fonctionner hors ligne » est une intention. Cette liste devient un engagement vérifiable.

Besoin terrain Fonctionnement à prévoir Limite à afficher
Lire un plan ou une notice Télécharger le document avant le départ Date et version du document disponible
Remplir un formulaire Enregistrer les réponses sur l’appareil Données non encore reçues au bureau
Ajouter des photos Conserver les fichiers et suivre leur transmission Pièces jointes encore en attente
Déclarer une consommation de stock Enregistrer un mouvement provisoire Disponibilité globale non garantie
Valider un engagement commercial Appliquer une règle d’autorisation explicite Confirmation en ligne si nécessaire

Ce tableau constitue une proposition de cadrage, pas une liste de capacités automatiquement présentes dans les logiciels. Pour chaque ligne utile à votre activité, demandez une démonstration sur un appareil déconnecté.

1. Confondre « l’écran s’affiche » et « le travail est enregistré »

Dans une application web progressive, ou PWA, plusieurs mécanismes remplissent des rôles différents. Le guide de Google sur les données hors ligne distingue notamment le stockage des ressources de l’application, comme ses pages et ses images, et celui des données structurées, par exemple dans une base locale IndexedDB.

Autrement dit, afficher un formulaire déjà chargé ne démontre pas que ses réponses seront conservées.

Le test à imposer : ouvrir une mission, couper le réseau, renseigner le formulaire, fermer complètement l’application, puis la rouvrir sans connexion. Les informations saisies doivent toujours être accessibles si cette conservation fait partie du besoin.

Ajoutez un cas moins confortable : interrompre la saisie avant d’appuyer sur le bouton final. Décidez alors ce qui doit être enregistré automatiquement et ce qui reste un brouillon.

Dans le cahier des charges de votre application web métier, remplacez « mode hors ligne inclus » par des scénarios précis. Une fonctionnalité se teste ; une formule commerciale, beaucoup moins.

2. Partir avec une application vide

Une application ne peut pas afficher hors ligne une notice qu’elle devait encore récupérer sur le serveur. Dans le modèle décrit par Android, les fonctions essentielles s’appuient sur une source de données locale, distincte de la source réseau.

Imaginez un technicien qui ouvre pour la première fois sa mission une fois arrivé dans un local sans couverture. Si les documents ne sont pas déjà disponibles sur son appareil, le bouton « hors ligne » ne les fera pas apparaître.

Prévoyez donc une préparation de tournée :

  • charger les missions affectées au collaborateur ;
  • récupérer les coordonnées et consignes nécessaires ;
  • télécharger les plans, notices et formulaires correspondants ;
  • afficher les éléments manquants avant le départ.

Le détail utile : un indicateur « prêt pour le terrain » doit correspondre à une vérification réelle des données indispensables, pas simplement à l’ouverture réussie de l’application.

Évitez aussi le téléchargement intégral du dossier client par défaut. Définissez ce qui sert à la mission et ce qui peut rester au bureau.

3. Afficher « envoyé » alors que rien n’est arrivé

Pour une saisie terrain, adoptez au minimum trois états explicites : enregistré sur cet appareil, en attente de transmission et reçu par le serveur. Réservez un état séparé aux erreurs qui demandent une intervention.

Ce vocabulaire évite de faire passer une sauvegarde locale pour une réception au bureau. Dans notre exemple de compte rendu, le technicien doit savoir s’il peut simplement poursuivre sa tournée ou si un document nécessite une reprise.

Attention à la promesse « tout se synchronise même quand l’application est fermée ». Pour les applications web, l’API Background Synchronization permet de différer certaines transmissions, mais MDN indique que sa disponibilité reste limitée selon les navigateurs. Il faut donc vérifier les appareils réellement utilisés plutôt que généraliser une démonstration faite sur un ordinateur.

Prévoyez une solution de repli : reprise de la synchronisation à la réouverture, bouton de relance et liste des éléments encore en attente.

Demandez également un mécanisme évitant les doublons lors des nouvelles tentatives. Le résultat attendu est simple à formuler : une transmission interrompue puis relancée ne doit pas créer plusieurs comptes rendus identiques.

4. Laisser deux versions d’un dossier se battre en silence

Prenons un scénario fictif : une responsable modifie une consigne au bureau pendant qu’un intervenant complète la même fiche hors ligne. Au retour du réseau, quelle modification faut-il conserver ?

La synchronisation exige une politique de résolution des conflits. La documentation Android présente plusieurs stratégies, dont celle consistant à retenir la dernière écriture. Ce choix technique doit néanmoins correspondre aux règles du métier.

Pour préparer la discussion, classez les données :

  • Ajouts indépendants : proposer de conserver séparément chaque observation ou photo.
  • Informations de référence : décider si la version administrée au bureau doit prévaloir.
  • Quantités : envisager des mouvements distincts plutôt qu’un total remplacé sans explication.
  • Décisions sensibles : prévoir un arbitrage humain en cas de divergence.

Ces règles sont à valider avec les responsables opérationnels. Un développeur ne devrait pas avoir à décider seul si une nouvelle adresse écrase une ancienne consigne de livraison.

Si l’application échange avec votre ERP ou CRM, nommez aussi le système qui fait référence pour chaque information. Le terrain peut proposer une modification sans devenir automatiquement propriétaire de toutes les données clients.

5. Traiter les photos comme de simples champs de formulaire

Un commentaire et une série de photos n’imposent pas les mêmes besoins de stockage. Pour une PWA, les quotas et les conditions de suppression des données locales varient selon les navigateurs. MDN détaille ces limites et les mécanismes d’éviction : le stockage du navigateur ne doit pas être assimilé à une sauvegarde permanente garantie.

Pour cadrer les pièces jointes, demandez :

  • une règle de taille et de qualité adaptée à l’usage des photos ;
  • un contrôle de l’espace disponible ;
  • un suivi de transmission fichier par fichier ;
  • une alerte avant saturation ;
  • une procédure de nettoyage qui distingue les éléments reçus des éléments non transmis.

Le compromis métier : une photo destinée à lire un numéro de série n’a pas nécessairement les mêmes exigences qu’une image utilisée pour examiner un défaut. Faites valider la qualité obtenue sur des exemples représentatifs avant de fixer une compression générale.

Et posez la question désagréable : que devient le travail non synchronisé si l’appareil est perdu ? Le mode hors ligne permet de travailler sans réseau, pas de supprimer ce risque.

6. Télécharger trop de données et oublier la sécurité

Dans son guide sur l’informatique mobile, la CNIL recommande notamment le chiffrement des équipements nomades, le verrouillage des smartphones et l’encadrement des appareils personnels. Elle demande aussi d’anticiper la perte ou le vol du matériel.

Pour votre application terrain, traduisez ces principes en décisions concrètes :

  • quels dossiers chaque utilisateur peut-il télécharger ?
  • combien de temps ces dossiers doivent-ils rester consultables localement ?
  • comment protéger les données stockées sur l’appareil ?
  • que faire lorsqu’un téléphone professionnel change d’utilisateur ?
  • qui prévenir en cas de perte ?

Examinez particulièrement la déconnexion : faut-il conserver les brouillons, les transmettre avant de fermer la session ou bloquer certaines opérations ? Il faut protéger les données sans effacer silencieusement un travail encore utile.

Un autre arbitrage mérite d’être écrit : une révocation décidée au bureau ne peut pas être reçue immédiatement par un appareil totalement déconnecté. Définissez donc une durée d’autorisation locale et les opérations permises pendant cette période. Faites valider ce compromis par les personnes chargées de la sécurité et du métier.

7. Tester uniquement le mode avion dans une salle de réunion

Le mode avion est un bon début. Il ne constitue pas à lui seul un plan de validation. Le guide Android mentionne notamment les interruptions transitoires et les connexions lentes parmi les situations à prendre en compte.

Pour la recette, demandez aussi des essais où le réseau revient, disparaît et revient encore. Ajoutez des interruptions provoquées volontairement : fermeture de l’application, redémarrage du téléphone, transmission partielle d’une pièce jointe.

Votre grille d’acceptation peut inclure :

  1. Une mission préparée reste accessible sans connexion.
  2. Un brouillon est retrouvé après fermeture et réouverture.
  3. Une transmission interrompue reprend sans doublon.
  4. Un fichier refusé est identifié sans bloquer les autres.
  5. Une modification concurrente déclenche la règle d’arbitrage prévue.
  6. Une nouvelle version de l’application conserve les saisies en attente.
  7. Une session expirée produit un message compréhensible.

Réalisez ces essais sur le parc réel : appareils, systèmes et navigateurs retenus pour le déploiement. Formalisez les résultats dans la recette de l’application, avec un responsable pour chaque anomalie bloquante.

PWA, application mobile ou logiciel existant : comment choisir ?

Choisissez l’approche à partir des tâches à garantir et des contraintes des appareils, pas à partir de l’étiquette « web » ou « mobile ». Le caractère hors ligne doit être démontré fonction par fonction, quelle que soit la solution.

Pour une application web progressive, les briques techniques existent : stockage local, service workers et mécanismes de synchronisation. Le guide MDN sur le fonctionnement hors ligne des PWA en explique aussi les limites, notamment l’arrêt possible des service workers par le navigateur.

Approche à examiner Bonne question de départ Preuve à demander
Module de votre logiciel existant Le parcours terrain correspond-il déjà à nos besoins ? Scénario complet sans réseau, puis synchronisation dans le système central
Application web progressive Les fonctions requises sont-elles compatibles avec notre parc ? Tests sur les navigateurs retenus, y compris après fermeture
Application mobile dédiée Avons-nous des contraintes fortes liées aux appareils ou aux périphériques ? Validation du stockage, des transmissions et des équipements concernés

Ne lancez pas une refonte complète par réflexe. Vous pouvez d’abord étudier un parcours terrain limité, connecté au logiciel central. C’est un périmètre possible de logiciel métier : préparer la mission, collecter les données et traiter leur retour, sans reconstruire toute la gestion de l’entreprise.

Quel budget prévoir pour une application hors ligne ?

Il n’existe pas de montant sérieux sans connaître le périmètre, le logiciel existant et les garanties attendues. Pour comparer les propositions, faites chiffrer séparément les parcours terrain, le stockage local, la synchronisation, la sécurité et les tests.

Le nombre d’écrans ne suffit pas à décrire le travail demandé. Dans votre consultation, rendez notamment visibles les postes suivants :

  • Préparation : choix et téléchargement des dossiers utiles.
  • Saisie locale : formulaires, brouillons et pièces jointes.
  • Retour au serveur : reprises, doublons, erreurs et conflits.
  • Intégration : échanges avec l’ERP, le CRM ou le logiciel de planning.
  • Exploitation : assistance, suivi des transmissions et maintenance du parc compatible.

Pour cadrer la valeur économique, mesurez votre situation actuelle : temps de ressaisie, déplacements effectués uniquement pour transmettre un document, dossiers incomplets et corrections. Distinguez ensuite les économies effectivement récupérables des minutes simplement rendues plus confortables.

Un pilote utile doit permettre une décision : poursuivre, réduire le périmètre ou revoir la solution. Fixez ses critères de réussite avant de développer, notamment la conservation des saisies et le traitement des erreurs de synchronisation.

Questions fréquentes

Peut-on créer un nouveau dossier sans connexion ?

Oui, si cette possibilité est prévue. Demandez que le dossier reçoive une référence locale unique et que ses photos ou formulaires restent correctement rattachés lors de la synchronisation. Si votre entreprise impose une numérotation centrale, distinguez la référence provisoire du numéro définitif.

Comment aider un utilisateur dont une saisie ne se synchronise pas ?

Prévoyez un écran de diagnostic compréhensible : élément concerné, dernière tentative, motif du refus et action possible. L’assistance doit pouvoir identifier le problème sans demander à l’utilisateur d’effacer ses données ou de réinstaller immédiatement l’application.

Un prestataire externe peut-il utiliser le même mode hors ligne ?

Traitez ce cas comme un périmètre distinct. Définissez les missions accessibles, les données téléchargeables, la durée d’autorisation et les conditions de fin d’accès. Ne copiez pas automatiquement les droits d’un salarié interne sur le compte d’un intervenant occasionnel.

Le bon test : une mission terminée, pas seulement un écran ouvert

Pour évaluer une application hors ligne, prenez une mission représentative et faites-la traverser une coupure complète : préparation, saisie, fermeture, reprise et réception au bureau. Le critère décisif est concret : le collaborateur termine son travail, sait ce qui reste à transmettre et retrouve des données cohérentes après synchronisation.