Mode hors ligne : concevoir une expérience qui fonctionne sans Internet
Une expérience interactive qui dépend d’une connexion réseau est plus vulnérable. Si le réseau cesse de fonctionner, l’expérience peut s’arrêter aussi.
C’est un vrai sujet dans les lieux où les applications interactives sont déployées : salons professionnels, musées, boutiques, hôpitaux, usines, salles de réunion et lieux publics. Sur place, la connexion est rarement aussi stable qu’au bureau, pendant le développement.
La borne est installée, l’application a été testée, les contenus sont prêts. Mais si la première interaction attend une ressource distante et que la connexion ne répond pas, le visiteur ne voit qu’une icône de chargement.
Pour lui, peu importe la raison. L’application ne marche pas.
Le mode hors ligne fait donc partie de la fiabilité de l’expérience. Ce n’est pas une option à ajouter en fin de projet.
Qu’est-ce qu’une expérience interactive hors ligne ?
Une expérience interactive hors ligne permet à l’utilisateur de faire l’essentiel sans connexion. Tout ce dont il a besoin pour cela, contenus comme logique, se trouve déjà sur l’appareil.
Concrètement, cela repose sur trois principes :
- Les ressources essentielles sont stockées sur l’appareil. Textes, images, sons, vidéos et polices sont déjà là quand on en a besoin.
- La logique s’exécute en local. La navigation, les états, les variables, les conditions et les interactions ne dépendent d’aucun serveur.
- Ce qui a besoin du réseau peut attendre. Réponses, scores ou statistiques sont enregistrés sur l’appareil, puis synchronisés quand la connexion revient.
Le test est simple : passez l’appareil en mode avion et relancez l’application. L’utilisateur peut-il toujours faire ce pour quoi l’expérience a été conçue ?
Le réseau n’est jamais garanti
Pendant le développement, le réseau est presque toujours meilleur que sur le lieu de déploiement.
Dans un hall d’exposition, des milliers d’appareils se partagent la même connexion. Dans un musée, les murs épais affaiblissent le Wi-Fi. Un commercial passe sans cesse d’une zone bien couverte à une zone blanche. Dans un hôpital, une usine ou un site sensible, l’accès au réseau peut même être totalement bloqué.
Photo de Jin-Woo Lee sur Unsplash
Il ne s’agit pas de se passer du réseau. Il reste très utile pour mettre à jour les contenus, synchroniser des données, envoyer des statistiques, afficher des informations en direct ou communiquer avec d’autres outils.
Tout l’enjeu est de distinguer les fonctions que la connexion améliore de celles qui ne peuvent pas s’en passer.
Si la navigation, les contenus essentiels ou l’interaction principale dépendent du réseau, la moindre coupure peut rendre toute l’expérience inutilisable.
Commencez par la tâche essentielle
Concevoir pour le hors ligne ne veut pas dire que tout doit fonctionner sans connexion.
Il s’agit de savoir ce qui doit continuer à fonctionner.
Avant de choisir une architecture technique, posez-vous trois questions :
- Que doit pouvoir faire l’utilisateur ?
- De quelles ressources a-t-il besoin pour y arriver ?
- Quelles opérations peuvent attendre le retour de la connexion ?
Sur une borne de musée, la navigation, les contenus de l’exposition et le quiz doivent sans doute fonctionner en local. L’envoi des statistiques, lui, peut attendre.
Dans une application commerciale, les fiches produits doivent rester accessibles pendant tout le rendez-vous client. La synchronisation avec le CRM peut se faire après.
Le périmètre hors ligne se définit donc à partir de ce que l’utilisateur doit accomplir, pas de la liste complète des fonctionnalités.
Le hors ligne est une décision d’architecture
Fonctionner hors ligne a un impact sur toute l’architecture de l’application : le mode de diffusion, le stockage, les composants, les services externes, les mises à jour et les tests.
Une application pensée dès le départ pour être connectée en permanence est difficile à rendre fiable hors ligne après coup.
Tous les modes de diffusion n’offrent d’ailleurs pas les mêmes garanties.
Une application web classique va chercher ses ressources et ses données sur un serveur au moment où elle en a besoin. Une PWA peut rendre certaines ressources disponibles hors ligne, mais tout dépend de sa stratégie de cache et de ce qui a déjà été téléchargé. Une application native ou desktop peut embarquer directement ses ressources, et se comporte donc de façon plus prévisible sans réseau.
Il n’y a pas de bonne réponse universelle. Le bon choix dépend du matériel, du lieu de déploiement, des contenus, du rythme des mises à jour et du niveau d’autonomie attendu.
Le hors ligne pose aussi une question de stockage.
Une application riche en images, vidéos ou fichiers audio devient vite lourde si tout est stocké en local : l’installation grossit, le téléchargement s’allonge et chaque mise à jour consomme plus de bande passante. Mieux vaut y penser tôt.
Fixez un budget de contenu. Choisissez les ressources qui doivent toujours être présentes sur l’appareil, celles qui peuvent rester en ligne, la façon de les compresser et la manière de diffuser les mises à jour.
C’est d’autant plus important pour les installations qui tournent sans surveillance, comme les bornes en mode kiosque. Un téléchargement interrompu ou un cache incomplet est bien plus difficile à rattraper quand personne n’est là pour redémarrer ou réparer l’appareil.
Concevez les états hors ligne
Continuer à fonctionner quand le réseau disparaît ne suffit pas. L’interface doit aussi montrer clairement ce qui se passe.
Quand une fonction a besoin de la connexion, l’application doit indiquer :
- ce qui est momentanément indisponible ;
- si l’action de l’utilisateur a bien été enregistrée ;
- ce qui se passera quand la connexion reviendra ;
- ce qu’il peut faire en attendant.
Un message générique comme « Une erreur est survenue » n’aide personne.
Un message comme celui-ci est bien plus clair :
Votre réponse est enregistrée sur cet appareil. Elle sera envoyée dès le retour de la connexion.
Si un contenu distant est inaccessible, proposez une version déjà téléchargée, une version allégée ou un autre parcours.
Un bouton qui a l’air de fonctionner mais ne fait rien quand on appuie dessus n’est pas un état hors ligne. C’est une panne.
Hors ligne ne veut pas dire sans données
Une application hors ligne peut tout à fait collecter des données.
Réponses à un formulaire, scores de quiz, préférences, statistiques d’usage : tout cela peut être enregistré sur l’appareil et envoyé plus tard.
Mais « on synchronisera plus tard » n’est qu’un point de départ.
Il faut aussi définir :
- quelles données sont stockées sur l’appareil ;
- combien de temps elles y restent ;
- ce qui déclenche la synchronisation ;
- ce qui se passe si l’application est fermée avant la synchronisation ;
- comment relancer les envois qui ont échoué ;
- comment repérer les doublons ;
- comment arbitrer entre une donnée locale et une donnée distante qui ne concordent pas.
Avec une connexion instable, ces situations sont fréquentes : le réseau peut revenir juste assez longtemps pour que certains envois passent et que d’autres échouent.
Les données sensibles demandent en plus du chiffrement, une politique de conservation, des règles de suppression et un contrôle des accès.
Enfin, l’interface doit confirmer chaque action immédiatement, sur l’appareil. L’utilisateur ne devrait pas attendre la réponse d’un serveur pour savoir que son action a été prise en compte.
Le hors ligne améliore aussi l’expérience en ligne
La plupart des techniques qui rendent une application fiable hors ligne la rendent aussi plus agréable quand le réseau est disponible.
Les images stockées en local s’affichent instantanément. Les vidéos démarrent sans attendre. La navigation reste fluide même quand la connexion ralentit.
Le réseau change alors de rôle.
Il n’est plus sollicité à chaque interaction. Il sert uniquement là où il est vraiment nécessaire : synchronisation, mises à jour, données en direct et échanges avec d’autres services.
On obtient ainsi une application plus prévisible, qu’elle soit connectée ou non.
Ne vous contentez pas du mode avion
Lancer l’application en mode avion est un bon réflexe, mais ce test ne couvre qu’une seule situation.
En conditions réelles, la connexion peut disparaître et revenir à n’importe quel moment.
Testez au minimum les cas suivants :
- Premier lancement sans réseau : vérifiez ce qui fonctionne sur une installation neuve, sans rien en cache.
- Coupure en cours d’utilisation : coupez la connexion pendant une vidéo, la saisie d’un formulaire ou une synchronisation.
- Retour de la connexion : vérifiez que l’application reprend normalement et que les données en attente ne sont envoyées qu’une fois.
- Redémarrage : fermez complètement l’application, puis relancez-la hors ligne.
- Longue période sans réseau : laissez l’appareil déconnecté plusieurs jours avant de le reconnecter.
- Parcours moins fréquentés : explorez les écrans et interactions que la démo habituelle ne montre jamais.
- Matériel final : testez sur l’appareil réel, avec tous les contenus de production.
Faites faire au moins un test par quelqu’un qui n’a pas participé au projet.
Les équipes de développement et de design refont souvent les mêmes parcours, et leurs appareils gardent en cache des ressources qu’une installation neuve n’aurait pas. Deux bonnes façons de passer à côté d’un problème hors ligne.
Avec PandaSuite Viewer, installez le projet sur iOS ou Android, activez le mode avion, fermez l’application puis relancez-la. La procédure complète est détaillée dans Tester et prévisualiser votre projet.
Construire une expérience hors ligne avec PandaSuite
Dans PandaSuite, les écrans, les ressources et la logique d’un projet sont réunis au même endroit.
Une fois le projet installé sur un appareil, les ressources embarquées restent disponibles sans connexion. Les états, variables, conditions et autres interactions continuent de s’exécuter en local.
Pour les contenus qui viennent habituellement d’une source distante, le composant HTTP propose un mode Hors ligne : il télécharge les textes, données et médias pour les utiliser ensuite en local.
Pour une installation fixe, un package autonome permet aussi d’installer l’expérience sur un ordinateur sans accès au réseau.
Le mode de diffusion à choisir dépend du matériel, de l’autonomie attendue, du volume de contenus et du rythme des mises à jour.
Quel que soit le format, testez toujours le comportement hors ligne avec la version finale, sur le matériel final.
La checklist du projet hors ligne
Avant de lancer la production, définissez :
- la tâche que l’utilisateur doit pouvoir accomplir hors ligne ;
- les ressources nécessaires à cette tâche ;
- le volume maximal de contenus stockés sur l’appareil ;
- les dépendances à des API, polices en ligne, cartes, plateformes vidéo ou autres services externes ;
- le comportement prévu quand une ressource distante est inaccessible ;
- les données stockées sur l’appareil ;
- leur durée de conservation ;
- les règles de synchronisation et de nouvel essai ;
- la gestion des doublons et des conflits ;
- le processus de mise à jour des contenus et de l’application ;
- les appareils et conditions réseau à tester.
Ces décisions se prennent en même temps que le choix du matériel, du mode de diffusion et des technologies interactives, pas une fois l’expérience construite.
Elles complètent les questions abordées dans notre guide pour créer une expérience interactive tactile.
Concevez pour le réseau réel, pas pour le réseau idéal
Une connexion est utile, mais elle n’est pas toujours là, et rarement tout à fait prévisible.
Pour une expérience interactive installée dans un lieu physique, la vraie question n’est pas de savoir si l’appareil est connecté la plupart du temps. C’est de savoir ce qui se passe quand il ne l’est pas.
L’essentiel de l’expérience doit continuer à fonctionner.
