Que se passe-t-il quand votre application perd Internet (et comment continuer à travailler)

Votre WiFi lâche. Vous êtes en train de remplir un formulaire dans votre application—la moitié des champs est déjà remplie, vous y avez passé cinq minutes. Que se passe-t-il ?

Si votre application est uniquement en ligne, voici l’histoire : la page se recharge ou s’actualise. Vos données disparaissent. Vous recommencez depuis le début. Vous fermez l’application, et vous n’y revenez jamais.

Si votre application est offline-first, l’histoire est différente : vous continuez à taper. Vos données sont en sécurité. Quand le WiFi revient (trois minutes plus tard, ou trois jours plus tard), tout se synchronise. C’est ça, le design offline-first en une phrase : l’application continue de fonctionner sans connexion Internet, enregistre vos modifications localement, et les synchronise dès que vous êtes de retour en ligne.

La plupart des créateurs d’applications sautent l’étape du offline parce que c’est plus simple à construire. Mais l’offline-first n’est pas compliqué—c’est une question de choix délibéré. C’est la différence entre une application vers laquelle on revient et une application qu’on supprime.

Que se passe-t-il vraiment quand votre application perd Internet ?

Quand votre application perd Internet, soit elle continue à fonctionner, soit elle s’arrête—il n’y a pas d’entre-deux. Et la perte de connexion n’a rien de rare : un utilisateur en avion n’a pas Internet, un utilisateur dans un tunnel n’a pas de signal, un utilisateur dans un lieu d’événement en zone rurale a une couverture instable, un utilisateur dont le routeur redémarre à 3h du matin se retrouve avec un WiFi mort, un utilisateur connecté via son téléphone atteint son quota de partage de connexion.

Dans tous ces cas, votre application fonctionne, ou elle ne fonctionne pas.

Nous avons construit une application de suivi du temps pour freelances. Elle plantait hors ligne. Un freelance (qui l’utilisait sur des chantiers sans signal) a arrêté de s’en servir—il est repassé au crayon et au papier, parce qu’au moins le crayon fonctionne partout. Trois mois plus tard, après l’ajout d’un mode hors ligne, il est revenu et n’est jamais reparti.

Le mécanisme est simple : enregistrer le travail localement quand Internet est coupé, le synchroniser quand la connexion revient. C’est tout.

Quels sont les différents types de « hors ligne » ?

Il existe trois types de situations hors ligne à anticiper : intentionnel, surprise, et lent—et chacun exige une solution différente.

Hors ligne intentionnel — L’utilisateur a choisi de travailler hors ligne. Il est en avion, ou il sait que le WiFi est mauvais. Il s’attend à synchroniser plus tard. C’est le plus simple à construire : il suffit d’enregistrer les brouillons localement et de les envoyer dès que la connexion revient.

Hors ligne surprise — Internet a coupé sans prévenir. L’utilisateur était en plein milieu de quelque chose. Si vous le coupez en pleine phrase, il est furieux. La solution est la même (enregistrer les brouillons localement), mais l’expérience utilisateur doit être plus bienveillante : montrez-lui que l’application continue de fonctionner, et prévenez-le quand il est de nouveau en ligne.

Hors ligne lent — La connexion est là, mais elle est tellement lente qu’elle pourrait aussi bien être absente. Un client remplit un formulaire, clique sur envoyer, puis attend 20 secondes que l’envoi se termine. À ce moment-là, il pense que quelque chose s’est cassé, et il reclique sur envoyer (et vous vous retrouvez avec un doublon). C’est le cas le plus difficile à tester, mais la solution est honnête : montrez-lui que le travail est en cours (un indicateur de chargement), ou laissez-le naviguer ailleurs sans perdre son brouillon.

Comment demander le mode hors ligne à votre créateur d’applications ?

Vous le demandez par morceaux, pas comme une seule grosse fonctionnalité—l’offline-first est une philosophie de conception, pas une simple case à cocher. Voici cinq demandes précises que vous pouvez formuler à votre créateur d’applications :

Enregistrer les brouillons localement : « Quand quelqu’un remplit un formulaire ou une note, enregistre-le sur son téléphone/navigateur. S’il actualise la page, le formulaire doit toujours être rempli. » Testez-le : remplissez quelque chose, fermez l’onglet du navigateur, rouvrez-le, et le formulaire est toujours là.
Travailler hors ligne : « S’il n’y a pas d’Internet, l’application doit afficher les données dont on dispose, laisser l’utilisateur les lire et les modifier, et mettre les modifications en attente pour les synchroniser quand Internet revient. » Testez-le : coupez votre WiFi, essayez de faire quelque chose d’utile, puis rallumez le WiFi et observez les données se synchroniser.
Synchroniser discrètement : « Quand on synchronise des modifications, n’affiche pas une grande boîte de dialogue. Montre un petit indicateur, comme “Enregistrement…” en haut, qui disparaît une fois terminé. Si l’enregistrement échoue, garde la modification localement et réessaie plus tard. »
Montrer la vérité : « Indique à l’utilisateur quelles données sont fraîches (tout juste synchronisées avec le serveur) et lesquelles sont uniquement locales (pas encore synchronisées). Utilise un petit indicateur ou une étiquette—ne rends pas ça anxiogène, juste honnête. »
Un workflow, en local d’abord : « La chose principale que l’utilisateur vient faire (consulter une réservation, écrire une note, suivre du temps) doit fonctionner hors ligne. Les à-côtés (chercher dans tous les enregistrements passés, récupérer des tarifs en direct) peuvent nécessiter Internet. »

Histoires vraies

La organisatrice de mariages a créé une application pour gérer les RSVP. Elle imprimait la liste, se promenait pendant les événements, et cochait les réponses. Mais le WiFi sur les lieux d’événements est catastrophique. Elle a demandé l’offline-first : enregistrer la liste localement, synchroniser en rentrant chez elle. C’est aujourd’hui son outil principal—même quand elle a du signal téléphonique, l’application fonctionne sans attendre les données. Elle adore.

L’enseignante utilisait une application pour suivre les progrès de ses élèves. Elle perdait sans cesse ses modifications en passant d’une salle à l’autre avec une couverture instable. Le mode hors ligne lui a permis de travailler librement, de synchroniser plus tard, et de ne plus avoir à choisir entre son téléphone et son travail. Un seul changement, un immense gain de confiance.

L’expert en assurances remplissait des rapports de sinistre sur place (pas de signal dans certaines zones rurales). L’application d’origine exigeait Internet pour envoyer. Nous avons ajouté des brouillons hors ligne. Maintenant, il remplit le formulaire, l’envoie hors ligne, et la synchronisation se fait pendant qu’il rentre en voiture. Fini le « je ne peux rien envoyer avant d’être chez moi ».

Les trois cas auraient pu être résolus par un simple « il suffit d’avoir un meilleur WiFi », mais ce n’est pas comme ça que fonctionne le monde réel. L’offline-first a apporté un gain de confiance bien plus important qu’une meilleure synchronisation.

L’offline-first rend-il votre application plus rapide ?

Oui—les applications offline-first semblent plus rapides parce que vous n’attendez pas le serveur. Vous tapez, l’application enregistre localement (instantané), et synchronise en arrière-plan. Pas d’indicateur de chargement, pas d’attente. Même avec Internet, l’expérience est plus vive parce que le serveur n’est pas sur le chemin.

Une application uniquement en ligne doit attendre que le serveur confirme chaque modification. Une frappe → une requête réseau → une validation serveur → une réponse → un affichage à l’utilisateur. C’est normalement acceptable, mais sur des réseaux lents (ou sur mobile avec un serveur lent), chaque interaction se bloque.

Combien coûte la construction d’une application offline-first ?

L’offline-first coûte du temps d’ingénierie en amont. Votre créateur d’applications doit réfléchir à :

Le stockage local : comment enregistrer les données sur le téléphone/navigateur pour qu’elles ne disparaissent pas si l’application plante. Pas difficile, mais ça doit être pensé délibérément.
La résolution de conflits : si l’utilisateur modifie un champ hors ligne, puis que quelqu’un d’autre (ou un autre appareil) modifie ce même champ avant la synchronisation, lequel l’emporte ? Généralement celui qui est en ligne (il est plus récent), mais l’utilisateur doit être prévenu, pas surpris. Exemple concret : deux téléphones modifient la même note hors ligne, tous deux se reconnectent—le deuxième à synchroniser l’emporte, le premier utilisateur voit « Votre version était plus ancienne, voici la version actuelle ».
Les données obsolètes : si l’utilisateur était hors ligne pendant trois jours, l’application doit-elle tout rafraîchir silencieusement à sa reconnexion, ou lui demander d’abord ? Demander est plus sûr—des données anciennes peuvent avoir des modifications non enregistrées qui leur sont attachées.

Ce n’est pas gratuit à réfléchir, mais c’est plus simple qu’on ne le croirait.

Le résultat : des applications auxquelles les gens font confiance. Une application offline-first ne cherche pas d’excuses (« vous avez besoin d’Internet pour utiliser ça ») et ne perd jamais votre travail. C’est énorme.

Comment tester si votre application fonctionne hors ligne ?

Pas besoin de prendre l’avion pour tester—le mode avion de votre téléphone est votre terrain d’essai. Voici comment faire :

Ouvrez et remplissez quelque chose : faites quelque chose de normal (remplir un formulaire, ajouter une note).
Passez hors ligne : activez le mode avion ou coupez le WiFi.
Continuez à travailler : essayez de refaire la même chose. Si l’application refuse, l’offline-first n’est pas encore là. Si l’application fonctionne, c’est bon signe. Si c’est confus, demandez à votre créateur d’applications un indicateur clair « Vous êtes hors ligne ».
Revenez en ligne : désactivez le mode avion.
Vérifiez la synchronisation : vos modifications se sont-elles synchronisées automatiquement ? Si vous avez dû cliquer sur un bouton « synchroniser » ou actualiser, ce n’est pas encore tout à fait au point.

Les meilleures applications hors ligne semblent tellement normales qu’on ne remarque même pas qu’elles sont hors ligne—on remarque juste que l’application continue de fonctionner.

Votre application a-t-elle vraiment besoin de fonctionner hors ligne ? Si la réponse est « mes utilisateurs ont un Internet instable, ou ils travaillent dans des endroits sans signal », alors oui. Si c’est « ils sont toujours sur un WiFi stable », vous pouvez laisser tomber pour l’instant. Mais le jour où quelqu’un vous dira « j’ai perdu mon travail », vous regretterez de ne pas l’avoir demandé plus tôt.