Ressources · 75
Coupure réseau : préserver la saisie et reprendre une tâche
Décrire les états d’attente, d’échec et de résultat incertain sans perdre le travail de la personne.
· 3 min
Ce que ce guide permet
- Décrire les états
- Préserver avec mesure
- Expliquer la reprise
- Rejouer les coupures
Contrôle express
- La saisie utile reste-t-elle disponible après interruption ?
- La personne distingue-t-elle attente et confirmation ?
- Une relance peut-elle créer un effet dupliqué ?
Méthode pas à pas
- 01
Décrire les états
Séparez saisie locale, envoi commencé, réception confirmée et résultat incertain. Une absence de réponse peut survenir après réception serveur. Définissez une confirmation fondée sur l’état métier plutôt que sur un simple changement visuel.
Livrable : carte des états.
- 02
Préserver avec mesure
Conservez les champs utiles pendant l’erreur et indiquez ce qui sera perdu au rechargement. Décidez explicitement si un brouillon peut être stocké, où et combien de temps. Évitez de conserver automatiquement des données sensibles sur un appareil partagé.
Livrable : politique de brouillon.
- 03
Expliquer la reprise
Présentez un message compréhensible, disponible aux technologies d’assistance, et une action précise. Distinguez corriger un champ, vérifier une demande et réessayer. Gardez focus et navigation cohérents ; une couleur ou un toast fugace ne suffit pas.
Livrable : messages et parcours clavier.
- 04
Rejouer les coupures
Testez hors ligne avant envoi, interruption pendant transfert, réponse retardée et retour du réseau. Utilisez des données fictives et vérifiez conservation, annonce, focus et absence d’effet dupliqué. Testez aussi rafraîchissement et retour navigateur.
Livrable : preuves de reprise de bout en bout.
Fiche de travail à réutiliser
À compléter avec vos observations autorisées. Ces champs constituent une trame de travail, pas des résultats observés.
| Champ | Information à consigner |
|---|---|
| État | Local, envoyé, confirmé ou incertain |
| Conservation | Champs, lieu, durée et effacement |
| Reprise | Message, focus, vérification et effet métier |
Exemple d’application
Situation illustrative
Exemple fictif : un formulaire de demande reste en attente après une réponse perdue.
Décision et preuve attendue
L’interface garde les champs, annonce l’incertitude et vérifie l’identifiant de demande avant relance. Un seul dossier est créé et la confirmation devient accessible.
Distinguer les mécanismes
| Mécanisme | Utilité | Point de vigilance |
|---|---|---|
| Erreur confirmée | Proposer une correction ou nouvelle tentative | Vérifier si une opération a déjà été créée |
| Résultat incertain | Rechercher l’état de la demande | Ne pas annoncer un échec comme un fait établi |
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Saisie récupérée | Champs utiles conservés dans les cas prévus | Corriger les pertes et rétentions excessives |
| Tâches reprises | Résultat unique confirmé après incident simulé | Revoir messages, vérification et répétitions |
Erreurs fréquentes
- Effacer la saisie après une erreur transitoire
- Réessayer un effet externe sans vérifier son état
Questions fréquentes
navigator.onLine confirme-t-il l’accès au service ?
Non. L’indication de connexion ne prouve pas que votre serveur répond ni que l’opération réussit.
Faut-il stocker tous les formulaires localement ?
Non. Choisissez les champs et durées selon leur sensibilité, l’appareil et le besoin réel de reprise.
Peut-on réessayer automatiquement ?
Cela dépend de l’opération. Les effets externes exigent une protection contre répétition et une vérification d’état adaptée.
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
Pour aller plus loin
Analyses associées
