Formulaire interrompu : reprendre sa demande sans tout ressaisir

Un visiteur décrit son projet, quitte le navigateur pour chercher une référence dans ses emails, puis revient sur une page vide. Un autre termine un dossier dans son espace client, mais découvre à l’envoi que sa session a expiré. Ces situations méritent un vrai scénario de reprise, au même titre que le parcours sans incident.

Pour un formulaire long, la question à poser au prestataire est simple : que retrouve la personne après une interruption, et que reste-t-il à envoyer ? Voici une méthode de conception et de recette. Les situations décrites sont illustratives, sans résultat client revendiqué.

Distinguer la saisie, le brouillon et la demande envoyée

Commencez par nommer trois états dans votre cahier des charges : les réponses actuellement affichées, un brouillon récupérable et une demande effectivement enregistrée par le service. Un texte visible dans un champ n’est pas forcément sauvegardé. Un brouillon sauvegardé n’a pas forcément été transmis à l’équipe commerciale.

Prévoyez des messages cohérents avec le fonctionnement réel : « Brouillon enregistré sur cet appareil » ou « Demande enregistrée », selon le cas. N’affichez pas une sauvegarde réussie tant que l’opération correspondante n’est pas confirmée. Si elle échoue, expliquez la limite sans effacer la saisie encore disponible.

Dans une demande de devis, une sauvegarde intermédiaire ne devrait pas déclencher les mêmes emails ou traitements qu’un envoi final. Faites définir explicitement cette séparation avant de brancher le formulaire à votre CRM ou à une automatisation.

Choisir ce qui doit être récupérable

Tout formulaire n’a pas besoin d’un dispositif complexe. Pour quelques champs rapides, conserver les valeurs pendant une erreur peut suffire. Pour une description détaillée répartie sur plusieurs étapes, un brouillon peut être pertinent. Le choix dépend du temps de saisie, des informations concernées et des interruptions à couvrir.

Demandez une réponse pour chaque scénario : actualisation de la page, retour depuis une autre application, fermeture de l’onglet, déconnexion et reprise sur un autre appareil. Une solution valable pour le premier ne couvre pas automatiquement les suivants.

Par exemple, sessionStorage conserve des données par origine et par onglet pendant la session de page. Elles survivent aux rechargements, mais la fermeture de l’onglet ou de la fenêtre termine cette session. Ce mécanisme ne constitue donc pas une sauvegarde multiappareil. Son accès peut aussi être refusé par une politique du navigateur. Documentation MDN sur sessionStorage.

Présentez la portée réelle au visiteur. Une promesse générale comme « Retrouvez votre demande à tout moment » serait trompeuse pour une conservation limitée à l’onglet.

Enregistrer avant que la page disparaisse

Une fenêtre « Voulez-vous quitter cette page ? » peut prévenir certaines pertes, mais elle ne remplace pas la sauvegarde. MDN précise que l’événement beforeunload n’est pas déclenché de façon fiable, notamment sur mobile. Le navigateur impose aussi le texte de sa boîte de confirmation. Limites de beforeunload.

Notre recommandation : prévoir des points de sauvegarde pendant la saisie ou au passage d’une étape, plutôt que d’attendre uniquement la fermeture. Le développeur doit choisir une fréquence adaptée, gérer les erreurs et éviter qu’une sauvegarde plus ancienne remplace une version plus récente.

Le changement de visibilité de la page offre un signal complémentaire : visibilitychange peut notamment se produire quand l’utilisateur passe à une autre application sur mobile. Ce signal aide à gérer l’état de l’interface ; il ne garantit pas qu’un envoi réseau aboutira. Événement visibilitychange sur MDN.

Testez une interruption juste après une modification. Si quelques réponses peuvent encore être perdues entre deux sauvegardes, documentez cette limite au lieu d’afficher un statut rassurant en permanence.

Préparer la reprise après expiration de session

Dans un espace connecté, ne supprimez pas simplement l’expiration de session pour faciliter la saisie. Faites concevoir ensemble la sécurité, la conservation autorisée du brouillon et le retour au formulaire après une reconnexion.

Pour les limites de temps définies par le contenu, le critère WCAG 2.2.1 prévoit plusieurs possibilités, comme désactiver, ajuster ou prolonger la limite, ainsi que des exceptions. La solution dépend donc du contexte ; afficher un simple compte à rebours ne suffit pas à démontrer la conformité. Explication du critère Timing Adjustable par le W3C.

À la reprise, demandez un comportement vérifiable : retour à la bonne étape, réponses récupérées selon la politique annoncée et indications sur les éléments à contrôler. Une pièce jointe ou une disponibilité choisie auparavant peut nécessiter une nouvelle vérification.

Surtout, la reconnexion ne doit pas envoyer silencieusement la demande. La personne doit pouvoir relire le contenu restauré et décider de le soumettre. Si elle utilise un autre compte, aucun brouillon du précédent utilisateur ne doit lui être présenté.

Conserver moins, protéger mieux

Sauvegarder automatiquement tout le formulaire n’est pas une bonne règle par défaut. Commencez par exclure les mots de passe, secrets, coordonnées de paiement et documents confidentiels d’un simple stockage navigateur. Faites examiner séparément les champs libres : une description de projet peut contenir des informations privées inattendues.

OWASP rappelle que les stockages accessibles au JavaScript de la page sont exposés aux attaques XSS, et déconseille d’y conserver des informations sensibles en supposant qu’elles sont protégées par l’authentification. La durée plus courte de sessionStorage ne résout pas ce risque. Recommandations OWASP sur le stockage web.

Pour un brouillon côté serveur, faites définir les droits d’accès, la durée de conservation et la suppression. Prévoyez aussi un bouton pour abandonner le brouillon. Le fonctionnement sur un ordinateur partagé doit faire partie de la discussion, pas seulement la récupération sur le téléphone habituel.

Après l’enregistrement final confirmé, vérifiez que l’ancien brouillon ne revient pas remplir une nouvelle demande. À l’inverse, une réponse réseau incertaine ne doit pas provoquer l’effacement immédiat du travail.

Faire une recette avec de vraies interruptions

Avec des données fictives, demandez cette démonstration dans un environnement de test :

• commencer une demande, changer d’application, puis revenir ;
• recharger la page au milieu d’une étape et vérifier les réponses récupérées ;
• couper la connexion pendant une sauvegarde et observer le statut affiché ;
• laisser expirer la session, se reconnecter et reprendre sans envoi automatique ;
• abandonner le brouillon, puis vérifier qu’il ne réapparaît pas ;
• envoyer une demande, revenir au formulaire et vérifier son état final.

Pour chaque essai, notez le navigateur, l’appareil, ce qui devait être conservé et ce qui l’a réellement été. Ajoutez les situations où aucune récupération n’est promise. Vérifiez aussi que la personne peut comprendre les messages et utiliser les actions au clavier.

Le livrable utile est une règle de reprise testée : quelles données, à quel endroit, pendant combien de temps et après quelles interruptions. Cette précision permet de choisir une solution proportionnée, sans promettre une conservation universelle ni transformer chaque brouillon en demande client.