Pourquoi et comment concevoir une application mobile offline-first ?

L’offline-first design, approche de conception mobile visant à privilégier le déploiement de fonctionnalités en hors ligne plutôt qu’en ligne, recommence à faire parler de lui et était notamment au cœur des conférences de la Swift Connection¹, où se sont rendus cette année nos développeurs iOS.

Ce que l’on attend d’une application mobile, c’est notamment de pouvoir accéder à sa ou ses fonctionnalités clés facilement et rapidement. Une attente pas toujours satisfaite lorsque l’on se trouve dans des lieux privés de réseau mobile, de connexion internet ou dans des zones qui entraînent des surcoûts liés à la consommation des données, à l’étranger par exemple. Aujourd’hui, de plus en plus d’applications sont donc conçues sur le principe du offline-first, qui apparaît comme un très bon moyen de garantir une expérience utilisateur fluide, même dans des conditions de connectivité incertaines. L’offline-first est une manière de penser l’architecture et la conception — technique mais pas que — d’une application ou de certaines de ses fonctionnalités pour un usage d’abord “sans réseau”. Alors pourquoi opter pour l’offline-first design ? Quels sont ses avantages ? Ses inconvénients ? Est-il pertinent pour toutes les applications mobiles ? Promis, on vous dit tout !

Un warning avant de commencer : le schéma de pensée offline-first ne concerne pas que les développeurs. Il doit imprégner l’ensemble de l’équipe de conception (UX & Service Designers, UI Designers…) dès le démarrage d’un projet d’application mobile. L’enjeu étant de prévenir les différents scénarios possibles de perte de connexion (prévue pour un déplacement à l’étranger ou inattendue dans un ascenseur par exemple) pour offrir à l’utilisateur des parcours capables d’anticiper ou de pallier les problèmes de connectivité de la façon la plus transparente pour lui. Ces problèmes peuvent intervenir quand l’utilisateur est en “lecture” de l’application, et qu’il consulte simplement des éléments et contenus qui y sont présents, ou lorsqu’il est en “écriture” et donc qu’il interagit avec l’application pour y renseigner des données.  

L’offline-first pour résoudre les problèmes de connectivité en mode lecture

Penser offline-first, vous l’avez compris, c’est avant tout avoir la capacité d’anticiper les moments de perte de connexion de l’utilisateur et déterminer en amont toutes les données susceptibles d’être utiles en l’absence de réseau, pour qu’elles puissent être toutes préchargées dès le démarrage de l’application. L’idée est donc de mettre en cache ou de stocker localement un certain nombre de “pages filles” ou de données clés dans le parcours qui vont être conservées, parfois en arrière-plan, même si l’utilisateur ne perd finalement jamais la connexion. Ce sont les UX & Service Designers qui vont pré-déterminer ces pages en concevant le service et en identifiant les attentes clés de lecture. 

Des parcours transparents et adaptés aux besoins en hors ligne des utilisateurs

Prenons l’exemple d’une application e-commerce. Il semble bien impossible, pour des raisons de poids et de performances, de précharger l’intégralité du catalogue (toutes les fiches produits, les images…). En revanche certains éléments pertinents et pas trop gourmands (et là, ne parle pas des produits bien sûr) peuvent l’être pour garantir une continuité dans le parcours de l’utilisateur et lui afficher du contenu si par malheur il passe sous un tunnel. On peut par exemple imaginer conserver l’arborescence des catégories d’articles ainsi que les 10 produits les plus populaires dans chacune d’elle, avec leur descriptif respectif. Même chose pour une application bancaire, on peut imaginer garder en cache les 50 dernières transactions bancaires effectuées par l’utilisateur ainsi que son solde pour lui permettre une consultation de ces éléments, a priori indispensables, même en hors ligne. Cela suppose là-aussi d’avoir chargé activement dès sa 1ère connexion toutes les données (et les métadonnées!) associées.

Il est en effet important de garder à l'esprit que toutes les fonctionnalités d’une application ne doivent pas nécessairement être toutes disponibles en hors ligne. L’enjeu est de se concentrer sur l'identification de celles qui pourraient rester indispensables pour les utilisateurs, même quand ils n’ont pas de connexion internet. En réalité, quel que soit le projet applicatif concerné, l’important est de rester PRAG-MA-TIQUE et de se poser ces quelques questions essentielles : quelle est la fonction principale de mon application ? Mes utilisateurs ont-ils réellement besoin de se servir de mon application ou de l’une de ses fonctionnalités en hors ligne ? Ce n’est qu’à partir de là qu’il sera possible de construire des parcours adaptés. 

Selon le type d’application, la gestion du hors ligne peut donc totalement différer. Les applications dites de “contenus” utilisent un parcours différent où c’est l’utilisateur qui va effectuer une action pour pallier l’absence de réseau à venir, quand elle est évidemment connue de lui-même. En l'occurrence dans le streaming, on va l’inciter à télécharger des épisodes de séries ou des films qui seront stockés localement sur son mobile pour être utilisés plus tard. 

L’app Netflix va même plus loin puisqu’elle offre aussi la possibilité à l’utilisateur de personnaliser ses téléchargements et de paramétrer le téléchargement automatique de certains contenus, dans la limite d’un nombre de gigas de stockage prédéfini. Cet exemple démontre d’ailleurs que, bien souvent, les applications pensées en offline-first sont conçues pour être plus claires et plus fluides, ce qui influe aussi sur l’expérience en ligne. 

Dans le cas des applications de tourisme ou transport, cela revient à demander par exemple à l’utilisateur de télécharger en amont les cartes dont il aura besoin. 

Google Maps le propose déjà, permettant à l’utilisateur de télécharger des plans de quartiers ou villes qu’il pourra utiliser hors connexion (notamment pour limiter les données cellulaires à l’étranger) pour créer des itinéraires, par exemple pendant un voyage, ce qui nécessite malgré tout le GPS pour le guidage. 

Plans s’adapte désormais aussi à cette possibilité avec iOS 17, comme évoqué dans notre récap’ sur la mise à jour de l’OS.

Informer l’utilisateur sur la politique de gestion du hors ligne dans l’application

Puisque l’un des enjeux clés de l’offline-first design est de faire en sorte que l’utilisateur ne subisse pas le manque de connexion, l’interface doit être mesure de l’informer avec le bon message, sous la bonne forme, au bon moment. En design, cela passe dans la majeure partie des cas par l’affichage d’un petit bandeau venant lui signaler qu’il est actuellement hors ligne, justifiant que l’application est temporairement inutilisable.

“Le bandeau d’information c’est un minimum quand il n’y a pas de connexion, tout comme le “loader” qui témoigne que la page est en train de charger lorsque la connexion est lente ou dégradée. Le mieux, c’est d’aller un cran plus loin en proposant un skeleton² bien calibré qui réduit la perception utilisateur du temps d’attente. Il est également indispensable de donner des indicateurs de temps type “Dernière mise à jour effectuée il y a 2 minutes” pour qu’il puisse bien établir la récence des contenus qu’il lit. Et enfin par pitié, évitez les tournures type “Oups, il semble qu’il y ait un petit problème !” qui sont un peu passives agressives et pourraient négliger le contexte dans lequel l’utilisateur a perdu sa connexion.”

- Séverine Dumont, Directrice de l’Expérience Client

Dans l’approche offline-first, et si vous avez donc bien suivi ce qu’on vous dit depuis le début de cet article (sinon, nous serions vraiment très déçus…), vous avez normalement anticipé ces pertes de connexion et les parcours de votre application ont été conçus pour éviter à votre utilisateur d’être totalement bloqué. 

Toutefois, il n’en reste pas moins important de lui indiquer soit que l’application est accessible en mode dégradé (avec seulement quelques fonctionnalités disponibles), soit pour nos fameuses applications de contenus, quelle est la marche à suivre pour continuer à consulter ce qu’il souhaite. Cela nécessite dans le cas de Netflix de prévoir les boutons de téléchargement associés dans les bonnes pages, le process de téléchargement, un espace pour retrouver tous ses téléchargements, etc. Même chose pour myCanal qui de son côté affiche un message d’alerte informant l’utilisateur de sa perte de connexion et le guide vers ses différentes options (recharger la page ou aller dans sa bibliothèque de programmes). 

De son côté, Citymapper attire l’attention avec un bandeau d’alerte rouge “L'appareil est hors ligne” plutôt classique mais qui s’avère être en fait interactif puisqu’il donne un accès à des plans de secours statiques, à paramétrer selon le type de transport souhaité, pour remplir quand même l’usage premier de l’application : se diriger. Une très bonne idée de compensation en termes de parcours mais qui aurait mérité une meilleure information de l’utilisateur avec un message clair lui détaillant ce qu’il peut continuer à faire en hors ligne.

“Une autre bonne pratique consisterait à personnaliser le message affiché à l’utilisateur selon la raison de sa perte de connexion. iOS peut par exemple détecter si le mode avion est activé ou si le problème provient d’une connexion internet dégradée. Il serait donc judicieux d’imaginer une alerte lui demandant de réactiver sa connexion ou de patienter encore. L’idéal dans le second cas serait d’être encore plus précis sur ses possibilités pendant l’attente : lui indiquer les fonctionnalités qui restent accessibles en hors ligne ou même lui pousser un contenu “surprise” déjà chargé.”

- Séverine Dumont, Directrice de l’Expérience Client  

L’offline-first pour résoudre les problèmes de connectivité en mode écriture

Dans un grand nombre de cas, il peut arriver que l’utilisateur ait besoin de se servir d’une application de façon plus concrète pour y effectuer une action, renseigner des informations, malgré le fait qu’il soit hors ligne. Les applications B2B sont pour ça de très bons exemples. Les utilisateurs d’une application dédiée aux assureurs pourraient par exemple avoir besoin d’accéder à la fonction de déclaration de sinistre depuis des lieux sans réseau, comme des caves. Une application embarquée chez des équipes de secouristes pourrait aussi offrir aux agents sur le terrain la possibilité de remplir les fiches médicales pour la prise en charge des patients depuis n’importe quelle localisation.

Dans cet usage en mode “écriture”, il devient un peu plus complexe de mettre en place des mécanismes pour lui éviter de subir l’absence de réseau. C’est là que la technique entre en jeu pour gérer un challenge majeur dans la synchronisation des données : la gestion des conflits.

La gestion des conflits de synchronisation des données

Malheureusement, lorsque l’on évoque la synchronisation des données, il est inévitable d’évoquer aussi les erreurs qui peuvent survenir avec elle. Si leur gestion impliquera de toute façon des efforts importants de support et de maintenance, elle peut toutefois être prévue dès la phase de conception technique du projet en appliquant des règles de décisions, entre deux mises à jour de données récentes notamment. 

Si l’on reprend notre application de secouristes, deux bénévoles pourraient très bien avoir tous deux rempli une fiche patient en hors ligne et au moment du retour à la connexion, l’application devra savoir quelle version conserver : celle du premier secouriste, celle du second ou bien celle du poste de commandement et donc du serveur ? Dans ce cas précis, cela semble logique de faire prévaloir la version la plus ancrée dans l’instant, celle du serveur donc, ou en tout cas celle de la plus haute autorité hiérarchique. Pour une application qui n’est pas teintée “d’urgence”, comme Google Docs par exemple, on préférera garder les deux, annuler la synchronisation ou bien conserver la version la plus récente des deux. On utilise pour cela des “horodatages” ou “timestamps” qui vont marquer les données pour comprendre leur chronologie et qui permettront de mettre les requêtes en file d’attente pour les faire passer petit à petit au retour de la connexion.

Dans ces deux cas, la manière de résoudre le conflit peut se faire de façon silencieuse, c’est-à-dire qu’on effectue automatiquement la mise à jour des données sans impliquer l'utilisateur. Mais quand il y a conflit, il semble quand même plus pertinent de le notifier d’une incohérence pour lui permettre de corriger lui-même l'erreur et tenter une nouvelle synchronisation en arrière-plan. Concrètement : à lui de choisir les données à conserver. 

Attention, en mode “écriture”, le besoin d’information de l’utilisateur devient encore plus clé. Il faut lui indiquer qu’il peut quand même soumettre un élément en hors ligne et symboliser ensuite que sa demande est actuellement en file d’attente, par exemple avec un léger filet, en grisant la requête ou en la plaçant dans une sorte de “boîte d’envoi” comme sur l’application Mail.

Comment faire en sorte que la synchronisation des données se passe sans encombre ?  

Le réseau étant ce qui limite le plus les performances de l'application, il est important de trouver des moyens de maintenir la cohérence entre les données locales de l'application et les données sur le serveur distant.

Utiliser un web service de synchronisation

Prenons ce scénario classique. Un utilisateur utilise une application en mode hors ligne, puis, quelque temps plus tard, retrouve sa connexion. Comment allez-vous gérer ce retour de manière transparente pour lui ? L’une des clés pour gérer efficacement cette transition est d’utiliser un composant central, comme le Web Service de synchronisation. 

Le Web Service de synchronisation peut être configuré pour détecter automatiquement les changements lorsque l'utilisateur retrouve la connectivité. Il commence ensuite à synchroniser l'ensemble de l'application avec les dernières données disponibles depuis le back-end. Cela garantit que les utilisateurs disposent des informations les plus récentes à chaque fois qu’ils reviennent en ligne.

L'utilisation de ce composant central simplifie la gestion des données et atteste que l'application fonctionne de manière claire pour l’utilisateur, qu’il soit en ligne ou hors ligne. Il s'agit d'un élément clé de la conception offline-first qui contribue à offrir une expérience utilisateur de haute qualité, quelles que soient les conditions de connectivité.

Le workflow général consiste à vérifier si les données nécessitent d’être synchronisées quand l’utilisateur lance l’application. Si elles sont obsolètes, on va alors interroger le serveur qui va renvoyer des données à jour. Celles-ci se mettront aussi à jour dans le cache en local. Et dans le cas où les données ne nécessitent pas une mise à jour, on ira directement les lire dans le cache.

Le stockage local et la mise en cache

Stocker les données localement sur l'appareil de l’utilisateur est un point crucial pour que l’application accède rapidement aux informations même en hors ligne, et le cache ainsi que le Persistent Store peuvent l’y aider. Le cache sert plutôt au stockage temporaire : il évite de refaire les mêmes actions (par exemple charger une image qui aurait déjà été chargée) et améliore donc les performances de l’application. Le Persistent Store est utile pour les données que l’on va garder sur du long terme. On peut y faire des requêtes et des modifications, les données y sont donc bien structurées (par exemple l’arborescence des catégories de l’application).

Même si le stockage local préserve la confidentialité des données, la sécurisation de celles-ci est un point critique. Il est donc impératif de mettre en place des mécanismes de sécurité robustes pour protéger ces données contre les accès non autorisés.

“Pour limiter les risques, il existe des solutions simples comme chiffrer les données et limiter le stockage aux données utiles. Par exemple, sur iOS on peut utiliser CoreData, un framework qui permet de gérer la couche de modèle des objets dans l’application. Il fournit des solutions générales et automatisées aux tâches courantes associées aux cycles de vie des objets et à la gestion du graphe d'objets, y compris la persistance. Par défaut, les données ne sont pas chiffrées, mais il est quand même possible de rajouter une couche de chiffrement sur ce framework.”

- Corentin Medina, Développeur iOS 

Les outils à utiliser pour la conception technique offline-first

Les trois recommandations de nos experts iOS : Firebase, Realm DB ou Core Data. Ces plateformes offrent des fonctionnalités de synchronisation de données en temps réel et de stockage local, ce qui simplifie grandement le processus de développement.

Firebase est une plateforme de développement d'applications mobiles proposée par Google. Elle offre une gamme de services, y compris une base de données en temps réel, une authentification, un stockage cloud et bien plus encore. Firebase facilite la synchronisation en temps réel des données, ce qui est essentiel pour les applications qui supportent le mode hors ligne. On y retrouve des fonctionnalités de stockage local, d'authentification sécurisée et de gestion des erreurs, rendant le développement plus fluide.

Realm DB est une base de données orientée objet qui se synchronise automatiquement entre les appareils. Elle est conçue pour des performances rapides et une facilité d'utilisation, ce qui en fait un choix solide pour les applications qui supportent l’offline. Realm DB propose aussi des fonctionnalités de stockage local, de sécurisation des données et de gestion des erreurs. 

Core Data est une bibliothèque populaire pour la gestion des données en Swift. Elle offre des fonctionnalités de stockage local robustes, ce qui en fait un choix idéal pour les développeurs qui souhaitent créer des applications offline-first. Core Data permet une manipulation aisée des données, garantissant une expérience utilisateur fluide, même en mode hors ligne.

Design des parcours plus fluide et instinctif même en ligne, meilleures performances dues à un stockage local de certaines données, engagement plus fort créé dans des instants où l’utilisateur est en demande d’accès… Les avantages de l’offline-first design sont nombreux, même s’il ne faut pas oublier que les fonctionnalités disponibles en hors ligne seront presque toujours limitées par rapport à celles disponibles en ligne. 

De façon générale, l’offline-first design ne se limite pas à un simple mode hors ligne mais représente une philosophie, un schéma de pensée visant à garantir une constance dans le parcours et une accessibilité permanente de l’application, peu importe où se trouvent les utilisateurs et leur niveau de connectivité. Il s'agit de bâtir des ponts entre les mondes en ligne et hors ligne pour offrir une expérience mobile sans interruption, cohérente et pertinente. Ces réflexions sont donc, on ne le dira jamais assez, à mener dès les premières phases de conception, en faisant collaborer les équipes tech & design, pour travailler l’optimisation de l’expérience client associée à cette approche. 

Il est important aussi de solliciter des retours d'utilisateurs régulièrement et de continuer à innover en la matière, car si l’on se projette un peu, l’offline-first design représente un nouveau moyen d’éduquer les utilisateurs sur la consommation de data dans les apps, rejoignant ainsi des problématiques d’éco-conception qui ne peuvent plus être négligées. En effet, le fait de pouvoir consulter une partie de l’application en local et, si l’on va plus loin encore, de pouvoir y naviguer, favorise l’économie des énergies dépensées par les serveurs. Pourquoi ne pas demain imaginer encourager l’utilisateur à réduire ses usages - à certains moments - au strict nécessaire disponible en hors ligne, en lui indiquant par exemple le poids des données qu’il s’apprête à charger. Le but étant d’éviter d’appeler trop de webservices inutiles. Nombreux sont ceux par exemple qui ne cherchent dans une application bancaire qu’à consulter leur solde et il pourrait être intéressant de les informer qu’on peut ne leur afficher que cette information-là. Une vision prospective qui ferait de l’offline-first design un moyen d’envisager des applications plus responsables.

Vous souhaitez auditer l'expérience offline offerte par votre application ou avoir plus d'informations de nos experts ? Contactez-nous. 

^{1 - La première conférence française dédiée à Swift, iOS, macOS et à tous les écosystèmes Apple.
2 - Un skeleton est un composant animé qui simule la présentation d’une page pendant le chargement des données. Il informe l'utilisateur qu'un contenu est en cours de chargement et, plus encore, de ce qui est en cours de chargement dans la page (image, texte, carte, etc.).}