Un enregistrement automatique d’email fiable

Une utilisatrice termine un paragraphe délicat, voit « Enregistré » et ferme l’onglet. Si ce mot signifie seulement qu’un délai s’est écoulé ou qu’un événement a été émis, l’interface promet quelque chose que le stockage n’a jamais confirmé.

Un enregistrement automatique fiable commence par définir cette promesse. Ce guide propose des critères de conception et d’intégration pour votre application : quelles données conserver, quel composant confirme leur stockage et comment préserver le travail lorsque le parcours habituel échoue.

Donner un sens précis à chaque état

Distinguez le document inchangé, les modifications en attente, l’enregistrement en cours, la confirmation et l’échec. L’utilisateur doit comprendre la différence entre « Enregistrement… » et « Enregistré », surtout sur une connexion lente. Un échec doit proposer une suite compréhensible, tout en gardant le brouillon visible.

Décidez du contenu de chaque sauvegarde. Le corps seul ne suffit pas si l’utilisateur a également modifié l’objet, le préen-tête ou les réglages du document. Capturez un ensemble cohérent et rattachez la confirmation à cet ensemble. Sinon, une partie de l’email peut sembler protégée alors qu’elle reste uniquement en mémoire.

Une copie locale de récupération peut être utile, à condition de décrire son rôle. « Récupéré sur cet appareil » et « Enregistré dans votre compte » ne représentent pas la même garantie. Les réunir derrière un seul indicateur de succès rend les incidents plus difficiles à comprendre.

Confirmer la bonne version

Supposons que la version 12 soit en cours d’enregistrement lorsque l’utilisateur crée la version 13. La première réponse confirme la version 12. L’interface doit conserver l’état d’attente pour les changements suivants au lieu de déclarer tout le document enregistré.

Une solution consiste à sérialiser les écritures : une requête active, puis l’enregistrement du dernier état en attente. D’autres approches sont possibles, mais elles doivent toujours relier la version confirmée au document affiché. Une temporisation réduit le nombre de requêtes ; elle ne garantit ni leur ordre ni leur persistance.

Prévoyez aussi les changements venant d’un autre onglet ou d’une autre personne. Une comparaison de version côté serveur peut refuser une mise à jour périmée. MDN présente les requêtes conditionnelles If-Match comme une façon d’éviter les écrasements. Une application peut appliquer une vérification de version équivalente dans son propre contrat.

Préserver le travail après un échec

Après un délai dépassé, un refus ou une session expirée, gardez le document courant intact. Le remplacer immédiatement par une réponse serveur risque de détruire les modifications à récupérer. Proposez une nouvelle tentative lorsque cela convient et expliquez les cas nécessitant une reconnexion ou une résolution de conflit.

En cas de conflit, ne choisissez pas silencieusement la dernière réponse reçue. Signalez l’existence d’une autre version et proposez une décision explicite : comparer, copier le brouillon courant ou rouvrir la source récente après avoir préservé le travail local. L’interface dépend du produit ; le choix doit rester visible.

Définissez également les nouvelles tentatives. Une requête interrompue peut avoir déjà réussi côté serveur. Coordonnez les répétitions avec le backend pour éviter les doublons ou versions contradictoires. Les journaux doivent permettre l’enquête sans exposer systématiquement le contenu privé des emails.

Anticiper la sortie de l’éditeur

La fermeture de l’onglet ne doit pas être la seule occasion de conserver le travail. MDN rappelle les limites de beforeunload, notamment sur mobile. Enregistrez pendant l’édition et considérez les événements de cycle de vie comme des occasions supplémentaires, sans garantie d’achèvement.

Testez aussi la navigation interne. Revenir à une liste de modèles peut démonter l’éditeur sans fermer le navigateur. Décidez si cette transition attend une confirmation, signale les changements en attente ou conserve un brouillon récupérable.

Dans un éditeur embarqué, l’application hôte et l’iframe doivent s’accorder sur la persistance. Recevoir un événement de modification indique que le document a changé. Cela ne démontre pas qu’une base de données l’a accepté. Confiez le statut visible au composant capable de confirmer ce stockage.

Tester volontairement les situations difficiles

Préparez un email court avec une dernière phrase facile à reconnaître. Ralentissez le réseau et modifiez le document pendant l’enregistrement. Coupez ensuite la connexion, ajoutez du texte et réessayez après rétablissement. Enfin, ouvrez la même source dans deux onglets pour vérifier qu’un conflit ne détruit rien silencieusement.

Dans chaque cas, rouvrez le document et comparez la phrase finale, l’objet et le préen-tête. Notez ce qui était confirmé à distance et ce qui a été récupéré localement. Les critères deviennent ainsi observables, au-delà d’une animation rassurante.

Un enregistrement automatique inspire confiance lorsque ses états correspondent au travail réellement récupérable. Utilisez cet exercice pour concevoir la persistance dans votre application. Découvrez Weavour pour la création d’emails au sein de ce parcours.