Une application en mode déconnecté enregistre tout le travail sur l'appareil lui-même, puis le transmet au serveur dès qu'une connexion est disponible, sans que l'utilisateur ait à s'en occuper. L'agent travaille de la même façon avec ou sans réseau. Derrière cette simplicité apparente se trouvent quatre mécanismes : un stockage local, une file d'attente, une synchronisation dans les deux sens et des règles pour arbitrer les conflits.
Que se passe-t-il dans l'appareil quand le réseau disparaît ?
Une application classique interroge le serveur à chaque action. Sans réseau, elle affiche une erreur et s'arrête. Une application conçue pour le mode déconnecté fonctionne à l'inverse : elle possède sur l'appareil une copie des données dont l'utilisateur a besoin, ainsi que les règles qui permettent de les traiter.
Un agent de collecte dispose ainsi, sur son smartphone, de la liste des contribuables de sa zone, des montants dus et des modèles de reçus. Lorsqu'il enregistre un encaissement, l'opération est écrite immédiatement dans la base locale de l'appareil. Le reçu est émis, le solde est mis à jour à l'écran, et l'agent passe au suivant. Du point de vue de l'application, le serveur n'est pas indispensable à cet instant. Il le deviendra plus tard, pour consolider.
Comment la synchronisation se déclenche-t-elle ?
Chaque opération réalisée hors connexion est inscrite dans une file d'attente, dans l'ordre où elle a été effectuée. L'application surveille en arrière-plan la disponibilité du réseau. Dès qu'elle détecte une connexion exploitable, elle procède en plusieurs temps :
- elle envoie au serveur les opérations en attente, une par une ou par lots ;
- le serveur vérifie chaque opération, l'enregistre et en accuse réception ;
- l'application retire de la file ce qui a été confirmé, et seulement cela ;
- elle récupère en retour les nouveautés venues d'ailleurs : nouveaux dossiers, mises à jour de tarifs, modifications faites par des collègues.
Le troisième point est décisif. Une connexion instable peut se couper au milieu d'un envoi. Tant que le serveur n'a pas confirmé, l'opération reste dans la file et sera présentée de nouveau. Chaque opération porte en outre un identifiant unique, de sorte qu'un envoi répété ne crée jamais de doublon. Ces deux précautions font la différence entre une synchronisation fiable et une source d'erreurs.
Que se passe-t-il si deux personnes modifient la même donnée ?
C'est la question la plus délicate, et elle n'a pas de réponse unique. Si deux agents déconnectés modifient la même fiche, le serveur recevra deux versions. La manière de les départager dépend de la nature de la donnée.
| Type de situation | Règle habituellement retenue |
|---|---|
| Ajouts indépendants (deux encaissements, deux visites) | Les deux sont conservés, il n'y a pas de conflit |
| Modification d'un champ simple (numéro de téléphone) | La modification la plus récente l'emporte, l'ancienne est conservée dans l'historique |
| Opération sur une quantité (stock, solde) | On transmet le mouvement et non le résultat, le serveur recalcule |
| Décision sensible (validation, clôture d'un dossier) | Le conflit est signalé à un responsable qui tranche |
La troisième ligne illustre un principe important. Si deux magasiniers sortent chacun dix unités d'un stock de cent, il ne faut pas que chacun envoie « il reste quatre-vingt-dix ». Il faut que chacun envoie « sortie de dix », pour que le serveur aboutisse à quatre-vingts. Ces choix relèvent autant du métier que de la technique, et se décident avec les responsables concernés au moment de la conception.
Un cas typique : la tournée sans réseau
Des agents de santé communautaire visitent des villages dont certains ne captent aucun réseau. Avec l'ancien système, ils notaient les visites sur des fiches papier, ressaisies au centre en fin de semaine, avec les oublis et les erreurs de lecture que l'on imagine.
Équipés d'une application en mode déconnecté, ils enregistrent chaque visite sur place : identité de la personne, soins apportés, prochaine échéance. L'appareil garde tout. Sur le chemin du retour, en traversant une zone couverte, la synchronisation se lance d'elle-même. Lorsque l'agent arrive au centre, le responsable voit déjà les visites du jour. Un indicateur à l'écran rassure l'agent : tant d'opérations en attente, puis « tout est synchronisé ». Ce petit témoin compte beaucoup, car un agent qui doute de la transmission recommence à noter sur papier « au cas où ».
Les données stockées sur l'appareil sont-elles en sécurité ?
Conserver des données sur un smartphone ou une tablette crée un risque qu'il faut traiter : un appareil se perd, se vole, se prête. Plusieurs protections se combinent. Les données locales sont chiffrées, de sorte qu'elles restent illisibles hors de l'application. L'accès est protégé par un code ou une empreinte, y compris hors connexion. Chaque agent ne reçoit sur son appareil que les données correspondant à son profil et à sa zone, jamais la base entière. Les échanges avec le serveur sont eux aussi chiffrés, et chaque opération est tracée avec son auteur, sa date et l'appareil utilisé. Enfin, un appareil déclaré perdu peut être désactivé à distance dès qu'il se reconnecte.
Quelles questions poser avant d'adopter une application hors ligne ?
Toutes les applications qui se disent « hors ligne » ne se valent pas. Certaines se contentent d'afficher les données déjà consultées, sans permettre de saisie. Demandez précisément :
- Peut-on créer, modifier et valider sans réseau, ou seulement consulter ?
- Combien de temps l'appareil peut-il rester déconnecté sans perte ni blocage ?
- Que voit l'utilisateur de l'état de la synchronisation ?
- Comment les conflits sont-ils arbitrés, et qui a défini ces règles ?
- Que se passe-t-il si l'appareil tombe en panne avant d'avoir synchronisé ?
Cette dernière question rappelle que le logiciel ne fait pas tout : l'autonomie de la batterie et la robustesse de l'appareil conditionnent la fiabilité de l'ensemble, d'où l'importance de bien choisir le matériel de terrain. Sur les enjeux plus généraux, notre article sur la connectivité limitée et les applications hors ligne pose le cadre.
Chez Linking Development, le mode déconnecté avec synchronisation automatique fait partie de la conception dès l'origine, sur ordinateur, tablette et smartphone. L'ajouter après coup à une application pensée pour une connexion permanente revient presque toujours à la réécrire.
Pour voir comment ce principe s'applique à votre activité, parcourez nos solutions.