Un agent commence une visite, saisit une observation et joint une photo. Avant l’envoi, la connexion s’interrompt. L’application doit-elle conserver le travail, signaler un brouillon ou demander de recommencer ? Cette décision compte autant que la couleur du bouton principal.

Concevoir pour la Côte d’Ivoire demande d’observer les usages réels. Un poste en boutique, une tournée et un bureau connecté ne présentent pas les mêmes contraintes. L’ANSUT décrit notamment sa mission d’accès aux télécommunications et son travail vers les régions éloignées. Cela justifie de s’intéresser aux conditions d’accès, sans conclure que toutes les zones disposent d’un réseau faible ou que tous les utilisateurs ont les mêmes besoins.

Observer le travail avant de dessiner les écrans

Qui utilisera l’application ? Avec quel téléphone ? Pendant combien de temps ? Une personne doit-elle lire en marchant, saisir debout ou consulter des informations entre deux rendez-vous ? Ces questions permettent de choisir un parcours utile plutôt qu’une démonstration séduisante.

Pour un exemple illustratif de suivi d’intervention, le premier écran pourrait montrer les tâches du jour, leur adresse et leur état. L’agent ouvre ensuite une tâche, renseigne le résultat et prépare son compte rendu. Ce scénario est une proposition de conception ; il ne décrit ni un produit livré ni une organisation cliente.

Donner une réponse claire à chaque action

Après une saisie, l’utilisateur doit comprendre ce qui s’est passé. « Enregistré sur ce téléphone » et « Transmis au serveur » désignent deux situations différentes. Un message vague comme « Terminé » peut faire croire qu’un responsable a reçu une information alors qu’elle attend encore l’envoi.

Affichez donc des états lisibles : brouillon, en attente de connexion, envoyé, erreur à corriger. Associez les couleurs à du texte et prévoyez un moyen de reprendre une action. Un écran vide accompagné d’un indicateur qui tourne indéfiniment ne permet pas de décider quoi faire.

Choisir ce qui peut fonctionner sans connexion

Le fonctionnement hors ligne n’est pas obligatoire partout. Il doit répondre à un besoin observé et à des règles métier compatibles. Consulter une liste déjà chargée ou préparer un compte rendu peut s’y prêter. Confirmer une disponibilité partagée exige parfois une vérification en ligne avant toute promesse.

Définissez les informations conservées sur l’appareil, leur durée de validité et les opérations autorisées. Une copie ancienne d’un stock doit être identifiable comme telle. Si une action reste impossible sans réseau, expliquez-le avant que la personne remplisse un long formulaire. Le périmètre choisi doit rester simple à comprendre et à maintenir.

Prévoir la reprise et les conflits

Lorsque la connexion revient, l’application doit transmettre les éléments en attente sans créer plusieurs copies d’une même opération. L’utilisateur doit pouvoir voir ce qui a réussi et ce qui demande une intervention. La présence d’Internet ne prouve pas à elle seule que le serveur a accepté la demande.

Prévoyez aussi le cas où deux personnes modifient le même dossier. Selon l’activité, on peut bloquer certaines modifications, demander une confirmation ou présenter les différences à un responsable. Écraser silencieusement une version peut faire perdre du travail. Le choix relève d’une règle à convenir avec l’entreprise, puis à tester.

Alléger les échanges et protéger les informations

Des images correctement dimensionnées, des listes chargées progressivement et des réponses ciblées réduisent les échanges inutiles. Montrez l’avancement des pièces jointes et permettez une reprise lorsque cela se justifie. Vérifiez aussi qu’un téléphone disposant de peu d’espace reçoit un message utile au lieu de perdre la saisie.

Conserver des dossiers sur un appareil crée une responsabilité supplémentaire. Limitez les informations locales, protégez l’accès et définissez le comportement après déconnexion du compte ou perte du téléphone. Une opération sensible peut nécessiter une nouvelle vérification en ligne. Ces choix se décident selon les données manipulées et ne remplacent pas une analyse des risques du projet.

Tester avec les appareils et les personnes concernés

La recette doit inclure les téléphones retenus pour le projet et des conditions représentatives : connexion habituelle, interruption pendant l’envoi, retour du réseau, application fermée puis rouverte. Vérifiez les doubles appuis, les formulaires incomplets et la lecture des messages d’erreur.

Demandez enfin à des utilisateurs de réaliser une tâche sans explication préalable. Savent-ils si leur travail a été transmis ? Peuvent-ils reprendre après une interruption ? Ces observations guideront les corrections. Une application adaptée au terrain se reconnaît à la continuité du travail et à la confiance dans ses informations.

Source et portée

La FAQ officielle de l’ANSUT documente le contexte de l’accès universel aux télécommunications. Les parcours, choix hors ligne et vérifications décrits ici sont des recommandations de conception ; ils ne constituent pas une mesure de couverture réseau ni une recette déjà exécutée pour une application.