Votre application métier auto-hébergée fonctionne-t-elle hors ligne ? Une grille d’évaluation pratique
Découvrez comment vérifier si une application métier auto-hébergée permet réellement de travailler hors ligne — et pas seulement d’afficher des pages mises en cache — et comment évaluer la synchronisation, les conflits, l’authentification, les pièces jointes et les risques liés aux appareils.
Commencez par définir ce que signifie « hors ligne » pour votre équipe
Les besoins hors ligne varient. Une brève interruption du Wi-Fi pendant une visite sur site n’a rien à voir avec une journée entière de travail sans connexion fiable ; ces deux situations sont également différentes d’une activité menée pendant plusieurs jours dans un lieu où aucune connexion n’est attendue.
Notez la durée maximale probable d’une déconnexion, le nombre de personnes susceptibles de travailler hors ligne en même temps, les données dont elles ont besoin et le délai dans lequel leurs modifications doivent parvenir à leurs collègues. Tenez compte des appareils et des navigateurs réellement utilisés : le comportement hors ligne peut varier selon l’application et le navigateur, et certaines fonctions de synchronisation en arrière-plan des navigateurs ne sont pas disponibles partout.
Définissez un délai de reprise acceptable. Par exemple, déterminez si le personnel doit pouvoir terminer une tâche immédiatement hors ligne ou s’il peut se contenter d’enregistrer un brouillon et la terminer après reconnexion. Il s’agit de besoins différents, qui peuvent orienter vers des outils différents.
- Interruption occasionnelle : l’application doit préserver le travail en cours et reprendre correctement lorsque la connexion revient.
- Déconnexion prolongée : les utilisateurs peuvent avoir besoin de consulter et de modifier un ensemble utile de dossiers, puis d’envoyer leurs actions ultérieurement.
- Absence d’Internet fiable : déterminez si une application conçue pour fonctionner hors ligne ou un déploiement local est nécessaire, au lieu de supposer qu’un service hébergé dans le cloud répondra au besoin.
Distinguez l’accès au contenu mis en cache de la réalisation d’un processus
Le fait qu’une page s’ouvre hors ligne ne prouve pas que le travail peut être effectué. Une application web peut mettre en cache les ressources d’une page ou du contenu déjà consulté, mais c’est l’application qui détermine comment chaque requête est traitée. Les pages mises en cache peuvent être obsolètes, incomplètes ou en lecture seule.
Testez l’ensemble de la tâche, et pas seulement l’écran. L’utilisateur peut-il trouver le bon dossier, le modifier, ajouter une note, envoyer la modification et obtenir une confirmation claire lorsqu’il est déconnecté ? L’application enregistre-t-elle un brouillon localement, met-elle une requête en attente ou affiche-t-elle simplement une erreur ? Demandez au fournisseur de décrire précisément le comportement prévu pour chaque action essentielle.
Considérez ces éléments comme des fonctionnalités distinctes : consulter du contenu précédemment enregistré, le modifier hors ligne, mettre des changements en attente pour les envoyer plus tard et réaliser un processus de bout en bout sans connexion au serveur. Ne déduisez pas la présence de l’une à partir d’une autre.
- Accès hors ligne : quels dossiers et pages de référence sont disponibles, et à quand remonte leur dernière mise à jour ?
- Modification hors ligne : quels champs ou quelles actions peuvent être modifiés sans connexion ?
- Envoi différé : où la modification en attente est-elle enregistrée, et comment l’utilisateur sait-il qu’elle n’a pas encore été transmise au serveur ?
- Réalisation du processus : quelles étapes nécessitent toujours le serveur, par exemple une approbation, une validation ou la génération d’un résultat partagé ?
Répertoriez les dossiers, pièces jointes et documents de référence dont les utilisateurs ont besoin
Établissez un inventaire concis fondé sur le travail réel, plutôt que de demander de manière générale un « mode hors ligne ». Indiquez les types de dossiers concernés, les champs que les personnes modifient et les informations de référence qu’elles consultent. Incluez les pièces jointes, comme des photos ou des documents, et testez-les séparément du texte ordinaire.
Demandez comment les utilisateurs rendent les données disponibles avant de passer hors ligne. Sont-elles téléchargées automatiquement ou faut-il d’abord ouvrir ou sélectionner les éléments ? Vérifiez que les dossiers restent accessibles pendant toute la durée hors ligne prévue et que l’application indique l’ancienneté des données locales.
Les limites de stockage des navigateurs varient selon les navigateurs et les appareils. Les données stockées peuvent être supprimées si l’espace de stockage vient à manquer. Vérifiez que l’application signale clairement les données locales manquantes et déterminez si l’entreprise peut accepter de devoir télécharger à nouveau les dossiers ou les pièces jointes avant de commencer le travail.
- Identifiez les dossiers essentiels et les champs minimaux nécessaires pour agir.
- Dressez la liste des photos, fichiers, formulaires, cartes, procédures et autres documents de référence nécessaires.
- Évaluez le volume approximatif des données hors ligne et l’espace de stockage disponible sur les appareils du personnel.
- Vérifiez si l’application indique ce qui a été téléchargé et la date de sa dernière mise à jour.
- Décidez de la marche à suivre si le contenu nécessaire pour travailler hors ligne est manquant.
Vérifiez la synchronisation, les nouvelles tentatives et la gestion des conflits
Une action mise en attente n’est pas nécessairement une action synchronisée de manière fiable. Renseignez-vous sur le déclencheur de la synchronisation : un processus automatique du navigateur, l’ouverture de l’application, l’appui sur un bouton de synchronisation ou une autre étape. La synchronisation en arrière-plan n’est pas prise en charge par tous les navigateurs couramment utilisés ; testez donc les combinaisons réellement employées par votre équipe.
Demandez ce qui se passe si la connexion est interrompue pendant un téléversement ou si l’application ne peut pas déterminer si une requête est parvenue au serveur. Réessayer une action qui modifie des données peut produire des effets en double, à moins que l’application puisse reconnaître sans risque une répétition ou déterminer si la première tentative a réussi. Testez des actions comme la création d’un dossier, l’envoi d’un formulaire ou le téléversement d’une pièce jointe afin de vérifier l’absence de doublons.
Des conflits peuvent survenir lorsqu’une personne modifie un dossier en ligne tandis qu’une autre modifie une copie hors ligne. L’application doit avoir une méthode définie : elle peut afficher les versions concurrentes, fusionner les modifications ou demander à l’utilisateur de les vérifier et de les effectuer à nouveau. Déterminez quelles données prévalent, qui résout le conflit et si les valeurs d’origine restent disponibles pour consultation.
- Les utilisateurs peuvent-ils voir les actions en attente, terminées et ayant échoué lors de la synchronisation ?
- Les téléversements ayant échoué sont-ils réessayés, et l’utilisateur peut-il relancer l’opération manuellement sans risque ?
- Comment l’application évite-t-elle les doublons de dossiers ou les envois répétés ?
- Que se passe-t-il lorsque le même dossier est modifié sur deux appareils avant leur reconnexion ?
- L’utilisateur peut-il examiner et résoudre les conflits, ou l’application applique-t-elle automatiquement une règle ?
- Que se passe-t-il si le navigateur ou l’appareil est fermé avant l’envoi du travail en attente ?
Testez l’authentification, les autorisations et les appareils partagés
Intégrez les cas de connexion et de contrôle des accès à votre évaluation. Vérifiez si l’utilisateur peut ouvrir les données déjà téléchargées après l’expiration de sa session d’authentification, et ce que l’application l’autorise à faire jusqu’à la reconnexion. Un appareil hors ligne ne peut pas interroger le serveur pour connaître les changements d’autorisation les plus récents. Confirmez donc la manière dont l’application gère cette situation et le délai d’application des changements d’accès après la reconnexion.
Soyez particulièrement attentif aux appareils partagés ou utilisés par roulement. Déterminez si une personne peut consulter les dossiers ou les modifications en attente stockés localement par une autre personne, ce que la déconnexion fait des données locales et comment les utilisateurs distinguent leur propre travail non envoyé. Ne supposez pas qu’un écran de connexion protège les informations déjà enregistrées dans le navigateur.
L’accès hors ligne crée une copie locale des informations métier. OWASP avertit que les personnes ayant accès à une machine peuvent être en mesure d’accéder aux données stockées dans le navigateur et déconseille d’enregistrer des informations sensibles ou des identifiants de session dans le stockage local. Demandez au fournisseur de l’application quelles données sont conservées sur l’appareil et évaluez si cette pratique convient à vos données.
- Testez l’expiration des sessions avec et sans connexion.
- Testez un changement d’autorisation, la désactivation d’un compte et la déconnexion d’un utilisateur, puis reconnectez-vous.
- Vérifiez si un utilisateur de l’appareil peut accéder aux données mises en cache ou aux actions en attente d’un autre utilisateur.
- Documentez la sensibilité des dossiers stockés localement et les personnes pouvant accéder à l’appareil.
Intégrez les pièces jointes et la perte d’un appareil à l’évaluation des risques
La prise en charge du mode hors ligne est aussi une décision de gouvernance des données. Un appareil peut contenir des dossiers et des pièces jointes qui ne se trouvent pas encore sur le serveur. Décidez quelles informations peuvent être stockées localement, pendant combien de temps et quels utilisateurs et appareils sont autorisés à les conserver.
Demandez si les données locales sont chiffrées et quels contrôles de sécurité des appareils votre organisation exige. Les recommandations de NIST sur les appareils mobiles préconisent le chiffrement des données stockées et décrivent l’effacement à distance comme une mesure à prendre lorsqu’un appareil risque d’être perdu, volé ou de se trouver entre des mains non fiables. Vérifiez si votre processus de gestion des appareils peut répondre à ces exigences pour les appareils réellement utilisés par le personnel.
Consignez la procédure à suivre en cas de perte d’un appareil. Précisez comment signaler la perte, désactiver les accès dans la mesure du possible, gérer les données stockées localement et déterminer si un travail non synchronisé risque d’être perdu. La fonctionnalité hors ligne de l’application ne remplace pas les procédures de l’organisation en matière d’accès, de conservation des données et de gestion des incidents.
- Classez les données et les pièces jointes susceptibles d’être stockées sur chaque appareil.
- Définissez les exigences de chiffrement, de verrouillage de l’écran et de gestion des appareils adaptées à votre organisation.
- Confirmez les actions à distance disponibles et ce qu’elles peuvent ou ne peuvent pas supprimer.
- Définissez comment le personnel signale la perte d’un appareil et comment le travail en attente est récupéré ou recréé.
Effectuez un test hors ligne contrôlé avec des tâches représentatives
Utilisez un compte de test, des dossiers représentatifs et les mêmes modèles de navigateurs et d’appareils que ceux prévus pour votre équipe. Commencez en ligne, préparez les données qui doivent être disponibles hors ligne et vérifiez ce que l’application indique comme étant prêt. Coupez ensuite volontairement la connexion réseau et effectuez les tâches essentielles convenues.
Reconnectez-vous et attendez le déclencheur de synchronisation indiqué dans la documentation. Vérifiez à la fois l’interface utilisateur et le résultat côté serveur : confirmez que les modifications attendues sont arrivées, que les échecs sont visibles, que les pièces jointes sont complètes et qu’aucune action n’a été dupliquée. Répétez le test avec un conflit et un téléversement interrompu. Notez précisément les étapes et les résultats afin que l’équipe puisse refaire le test après des changements de configuration ou d’application.
Ne vous limitez pas à tester une courte interruption dans des conditions idéales. Incluez la durée hors ligne maximale prévue et des situations comme fermer puis rouvrir le navigateur, redémarrer l’appareil ou changer d’utilisateur, si elles font partie des opérations habituelles.
- Préparez une liste de contrôle pour chaque processus essentiel et le résultat attendu.
- Coupez la connexion réseau et effectuez le processus du début à la fin.
- Interrompez au moins un téléversement ou un envoi, puis rétablissez la connexion.
- Recherchez les modifications manquantes, les effets en double, les conflits non résolus et les retours d’information peu clairs pour l’utilisateur.
- Répétez le test sur chaque combinaison de navigateur et d’appareil sur laquelle l’équipe compte s’appuyer.
- Consignez les limites et déterminez si elles sont acceptables, nécessitent une solution de contournement ou rendent l’application inadaptée.
Choisissez le modèle de déploiement adapté au travail
L’auto-hébergement indique qui exploite l’environnement de l’application ; il ne fournit pas, à lui seul, l’accès aux données hors ligne, la modification hors ligne ni la synchronisation. Une application hébergée sur un serveur a toujours besoin d’une connexion lorsque son processus dépend de ce serveur. À l’inverse, une application conçue avec soin pour le mode hors ligne peut prendre en charge certaines tâches en étant déconnectée, dans les limites qui lui sont propres.
Airbip gère l’infrastructure cloud des applications auto-hébergées : les instances applicatives s’exécutent sous forme de charges de travail Docker sur les serveurs cloud d’Airbip, avec le routage et les certificats TLS automatisés par Traefik et Let’s Encrypt, ainsi que des vérifications DNS, la gestion du cycle de vie des services et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Ce modèle d’hébergement n’ajoute pas de capacités de travail hors ligne à une application. Évaluez séparément le comportement documenté de l’application et vérifiez si les utilisateurs peuvent accéder au service hébergé depuis leur lieu de travail lorsqu’ils sont en ligne.
Si les utilisateurs doivent effectuer des tâches essentielles dans des lieux dépourvus de connexion fiable, choisissez une application et un modèle de déploiement qui prennent en charge ces processus de manière avérée, ou mettez en place une procédure hors ligne explicite. Si seules des interruptions occasionnelles vous préoccupent, un processus testé de mise en attente et de synchronisation peut suffire. Si le travail exige des actions immédiates, partagées et validées par le serveur, un processus exclusivement en ligne assorti d’une solution de repli claire peut être plus sûr que de prétendre qu’il fonctionne hors ligne.
- Choisissez un logiciel conçu pour fonctionner hors ligne lorsque des tâches essentielles doivent être réalisées sans connexion au serveur.
- Optez pour un processus de synchronisation différée testé uniquement si la gestion des conflits et des actions en double est acceptable.
- Choisissez un processus exclusivement en ligne lorsque les actions nécessitent une validation en direct par le serveur ou des données partagées à jour, et prévoyez une solution de repli pratique en cas de panne.
- Considérez l’hébergement, les fonctionnalités de l’application, les contrôles de sécurité des appareils locaux et les procédures du personnel comme des éléments distincts de la décision.
Questions fréquentes
L’auto-hébergement rend-il une application métier accessible hors ligne ?
Non. L’auto-hébergement concerne l’emplacement et les modalités d’exploitation de l’application ; l’accès hors ligne et la synchronisation dépendent de la conception de l’application et des données disponibles sur l’appareil de l’utilisateur. Une application auto-hébergée qui a besoin de son serveur pour effectuer une tâche nécessitera toujours une connexion pour cette tâche.
Une page mise en cache suffit-elle pour qualifier une application de compatible avec le mode hors ligne ?
Non. La mise en cache des ressources ou des pages peut permettre de consulter certains contenus, mais elle ne prouve pas que les utilisateurs peuvent modifier des dossiers, envoyer des actions, téléverser des fichiers ou terminer un processus. Testez chaque tâche essentielle sans connexion et vérifiez le résultat après la reconnexion.
Les actions hors ligne mises en attente peuvent-elles créer des doublons ?
Oui, si une action est relancée après un échec incertain et que l’application ne peut pas déterminer de manière fiable si elle a déjà abouti. Testez les envois répétés et les interruptions de connexion, et demandez comment l’application gère les nouvelles tentatives et empêche les doublons.
Que faut-il tester lorsqu’une modification hors ligne entre en conflit avec une modification en ligne ?
Modifiez le même dossier depuis deux appareils ou par deux utilisateurs, en effectuant l’une des modifications hors ligne. Après la reconnexion, vérifiez si l’application présente les deux versions, fusionne les modifications ou demande une vérification, et confirmez que les utilisateurs peuvent comprendre et résoudre le résultat.
Le stockage du navigateur est-il suffisamment fiable pour les données hors ligne essentielles ?
Ne le présumez pas sans effectuer de tests. Les limites de stockage et les mécanismes de suppression varient d’un navigateur à l’autre, et les données peuvent être effacées lorsque l’espace de stockage vient à manquer. Vérifiez comment l’application prépare et protège les données hors ligne, puis testez leur disponibilité pendant la durée prévue et sur les appareils utilisés par votre équipe.
Que faut-il faire si un appareil contenant des données hors ligne est perdu ?
Préparez une procédure documentée qui couvre le signalement, le contrôle des accès, la gestion des appareils et les données stockées localement. Évaluez les possibilités de chiffrement de l’appareil et d’effacement à distance, et décidez comment traiter le travail qui n’avait pas encore été synchronisé.
Sources et lectures complémentaires
- Offline and background operation — Progressive web apps — MDN Web Docs
- Background Synchronization API — MDN Web Docs
- Retrying requests when back online — Chrome for Developers
- Storage quotas and eviction criteria — MDN Web Docs
- HTML5 Security Cheat Sheet — OWASP
- RFC 9110: HTTP Semantics — Internet Engineering Task Force
- Replication and conflict model — Apache CouchDB
- Guidelines for Managing the Security of Mobile Devices in the Enterprise — National Institute of Standards and Technology
- Service Worker API — MDN Web Docs