Concevoir un service numérique pour la plus mauvaise connexion, pas pour la meilleure

Un service numérique peut sembler fiable dans un bureau et échouer au moment où l’utilisateur en a besoin. Un agent de terrain perd un formulaire rempli lorsque le signal disparaît. Une clinique ne peut pas transmettre une mise à jour après une coupure. Un client appuie une seconde fois parce que la première tentative n’a donné aucune réponse digne de confiance.

La question n’est pas de savoir si le service fonctionne avec la meilleure connexion dont dispose l’équipe produit. Il faut vérifier si la tâche importante résiste aux conditions lentes, interrompues et partagées dans lesquelles les personnes l’utilisent réellement.

Inscrire la pire condition raisonnable dans le cahier des charges

Commencez par décrire les conditions d’utilisation, et non par choisir une architecture. Le service peut être utilisé sur un téléphone d’entrée de gamme, une tablette partagée, un ordinateur portable peu puissant ou un appareil presque déchargé. La connexion peut être lente, intermittente ou absente pendant une partie de la tâche. L’électricité peut revenir juste assez longtemps pour recharger un appareil et envoyer une courte mise à jour.

Ces situations ne sont pas marginales lorsque le public comprend des équipes de terrain, des écoles, des cliniques, des programmes communautaires ou des clients en dehors d’un réseau de bureau fiable. Le référentiel français d’écoconception recommande de tester un service avec des connexions bas débit et de prévoir un mode hors connexion lorsque la fonction peut techniquement fonctionner sans réseau. Il s’agit d’une condition de test, pas d’une promesse que toutes les fonctions fonctionneront hors connexion.

Délimitez précisément :

• la tâche qui doit rester possible ;
• les informations qui doivent être disponibles sur l’appareil ;
• les informations qui peuvent attendre la synchronisation ;
• l’action qui doit être confirmée par le serveur ou par une personne ; et
• la personne responsable d’une fiche en échec ou contestée.

Tester une tâche importante du début à la fin

Ne commencez pas par tester tous les écrans. Choisissez une tâche qui compte : envoyer une demande, enregistrer un paiement, signaler une panne, mettre à jour une fiche de bénéficiaire ou recevoir une alerte. Donnez-lui un utilisateur, un appareil, un lieu et une définition de la réussite.

Réalisez ensuite le parcours dans l’ordre :

1. Commencer avec une connexion normale. Laissez l’utilisateur ouvrir la tâche et saisir assez d’informations pour qu’elle soit réelle.
2. Interrompre la connexion. Réduisez la bande passante, activez le mode avion, déplacez-vous vers une zone connue de faible signal ou coupez la connexion pendant l’envoi.
3. Interrompre l’alimentation ou l’appareil. Fermez l’application, redémarrez le téléphone, passez à un appareil partagé ou continuez avec une batterie faible. Observez ce que l’utilisateur voit au retour dans l’application.
4. Rétablir la connexion et examiner le résultat. Vérifiez si la fiche est synchronisée une fois, deux fois ou pas du tout. Comparez ce que pensent l’utilisateur, le responsable du support et le serveur.

Mesurez le temps nécessaire, les données consommées, l’effet sur la batterie, les points d’échec, les doublons, les champs manquants, les sollicitations du support et l’action exacte à réaliser après le rétablissement de la connexion. Il ne s’agit pas de produire une démonstration favorable, mais de révéler le travail transféré à l’utilisateur ou à l’équipe d’assistance.

Rendre honnêtes l’état local et l’état du serveur

Un service utilisable hors connexion ne se résume pas à une étiquette « mode déconnecté ». Il lui faut un état local clair, un état distant clair et une manière maîtrisée de passer de l’un à l’autre. Les recommandations Android pour les architectures offline-first distinguent les sources locales et réseau, recommandent d’enregistrer localement les données importantes avant leur synchronisation ultérieure et signalent les conflits possibles au retour de la connexion. La documentation Flutter formule le même compromis : une écriture locale protège le travail de l’utilisateur, mais les états local et distant peuvent alors diverger.

Pour chaque fiche importante, définissez la signification de ces états :

• Enregistrée sur cet appareil : l’utilisateur peut retrouver la fiche même sans connexion
• En attente d’envoi : la fiche est conservée localement, mais le service ne l’a pas encore acceptée
• Acceptée : le serveur ou une personne habilitée a confirmé l’opération
• À traiter : la synchronisation a échoué, la fiche entre en conflit avec une autre modification ou l’utilisateur doit la corriger

Donnez à chaque envoi une référence durable afin qu’une nouvelle tentative ne crée pas silencieusement un second paiement, rapport ou dossier. Décidez qui examine les conflits. « Réessayez » n’est pas une politique de résolution, et une coche verte ne prouve pas l’acceptation par le serveur si le système ne peut pas lui donner ce sens.

Prévoir le service de secours avant la panne

Un SMS peut être utile lorsqu’une application complète n’est pas disponible. Il peut transmettre une courte alerte, une référence, une heure de passage ou une consigne d’appel. Un relais humain peut être plus sûr pour un paiement contesté, une préoccupation de protection, une escalade clinique ou une fiche qui contient davantage de détails qu’un SMS ne devrait en transporter.

Le service de secours ne doit pas être ajouté après coup. Précisez :

• les événements qui déclenchent un SMS, un appel ou une revue humaine ;
• les informations minimales transmises par le secours ;
• la manière dont l’utilisateur prouve ou explique l’action en attente ;
• la personne qui reçoit l’escalade et le délai opérationnel attendu ; et
• la manière dont le résultat final est réintroduit dans la fiche principale.

Le message de secours ne doit pas accuser l’utilisateur. « Demande invalide » ne dit pas ce qui s’est passé. « Votre demande est enregistrée sur cet appareil, mais elle n’est pas encore parvenue au service. Conservez la référence 4F82 et réessayez lorsque la connexion sera disponible. Si elle reste en attente, appelez le bureau du programme » donne un état, une référence et une prochaine étape. Dans le produit, remplacez cet exemple par un identifiant réellement généré.

Tenir compte des appareils partagés, de l’électricité et du support

La connectivité n’est qu’une contrainte. Le service peut échouer parce qu’un appareil est partagé, ne peut pas être rechargé la nuit, dépend d’une carte SIM inaccessible, manque d’espace ou ne peut pas recevoir la dernière version de l’application. Une file locale crée aussi une question de sécurité et de confidentialité : quelles informations sensibles restent sur l’appareil, qui peut les ouvrir et que se passe-t-il lorsqu’il est perdu ou remis à une autre personne ?

Testez le service avec les appareils réellement disponibles et avec la capacité réelle du support. Si chaque synchronisation échouée exige l’intervention d’un spécialiste, la conception ne correspond pas encore au contexte d’exploitation. Si le service conserve localement plus de données que la tâche n’en exige, réduisez cette copie ou ajoutez une durée de conservation et une suppression maîtrisées.

Ne prétendez pas que le mode déconnecté résout l’accès

Un mode déconnecté peut protéger une tâche pendant une interruption de réseau. Il ne rend pas un téléphone abordable, ne crée pas d’électricité, ne fournit pas un lieu sûr pour recharger un appareil, ne remplace pas un agent formé et ne supprime pas les obstacles d’identité, de langue ou d’accessibilité. Il peut aussi introduire des données anciennes, des conflits, un risque pour l’appareil et un travail supplémentaire pour le support.

Posez une question plus précise : quelle partie du service doit rester utilisable, sur quel appareil, pendant combien de temps et avec quelle preuve lorsque la connexion revient ? Une petite fonction hors connexion bien testée peut mieux servir les utilisateurs qu’une promesse générale selon laquelle tout le système fonctionne partout.

Conserver une fiche de test d’une page

Avant d’élargir un pilote, consignez le résultat dans un format lisible par le responsable produit, le responsable de programme et la personne chargée du support :

Construisez le test autour de la pire connexion raisonnable, et non autour de la meilleure démonstration disponible. Lorsque le service conserve l’intention de l’utilisateur, explique son état et reprend le travail sans doublon, vous pouvez parler plus honnêtement de son extension. Lorsqu’il échoue, le test a rempli sa fonction : il a révélé la prochaine décision de conception.