Comment persister l'état d'un formulaire dans le navigateur

Vous passez dix minutes à remplir une candidature en plusieurs étapes. Vous appuyez accidentellement sur le bouton retour. Tout est perdu.

C’est l’un des échecs UX les plus frustrants du développement web, et il est entièrement évitable. Voici comment persister l’état d’un formulaire dans le navigateur en utilisant le mécanisme de stockage adapté à votre situation.

Pourquoi les données de formulaire disparaissent dans les applications modernes

Les pages traditionnelles rendues côté serveur bénéficient ici d’un léger sursis. Les navigateurs restaurent souvent les valeurs des formulaires lors de la navigation arrière, car la page elle-même est mise en cache. Les applications monopages ne bénéficient pas toujours de cet avantage. Quand votre JavaScript recrée un formulaire à partir de zéro, le navigateur n’a parfois aucun DOM en cache à restaurer, et les champs reviennent vides.

La solution est de sauvegarder vous-même l’état du formulaire dans le stockage du navigateur, et de le restaurer lorsque le formulaire est monté.

Choisir le bon mécanisme de stockage

Tous les problèmes de persistance n’appellent pas la même solution. Voici une comparaison pratique :

localStorage convient bien aux brouillons que vous voulez voir survivre aux redémarrages du navigateur, comme un éditeur d’articles de blog ou un long formulaire d’inscription. Les formulaires en sessionStorage sont préférables lorsque vous n’avez besoin de conserver les données qu’au cours d’une actualisation dans le même onglet, et non entre plusieurs onglets. Les brouillons de formulaire en IndexedDB ont du sens lorsque vous stockez du contenu riche, des métadonnées de fichiers ou des objets imbriqués complexes qui seraient peu maniables sous forme de chaînes JSON.

localStorage et sessionStorage sont tous deux synchrones et basés sur des chaînes, ce qui signifie que chaque lecture et écriture bloque le thread principal et nécessite JSON.stringify/JSON.parse. IndexedDB est asynchrone et gère nativement les données structurées, ce qui le rend plus adapté à tout ce qui dépasse les simples paires clé-valeur. Les trois sont bien pris en charge par les navigateurs modernes.

Implémenter l’autosave avec localStorage

Le modèle de base est simple : sauvegarder à la saisie, restaurer au chargement, nettoyer après soumission réussie.

const DRAFT_KEY = 'contact_form_draft';
const form = document.querySelector('#contact-form');

// Autosave with debounce
let saveTimer;
form.addEventListener('input', (e) => {
  clearTimeout(saveTimer);
  saveTimer = setTimeout(() => {
    const formData = Object.fromEntries(new FormData(e.currentTarget));
    try {
      localStorage.setItem(DRAFT_KEY, JSON.stringify(formData));
    } catch (err) {
      if (err.name === 'QuotaExceededError') {
        console.warn('Storage full, draft not saved');
      }
    }
  }, 500);
});

// Restore on load
window.addEventListener('DOMContentLoaded', () => {
  const saved = localStorage.getItem(DRAFT_KEY);
  if (!saved) return;
  try {
    const draft = JSON.parse(saved);
    Object.entries(draft).forEach(([name, value]) => {
      const field = form.querySelector(`[name="${name}"]`);
      if (field) field.value = value;
    });
  } catch {
    localStorage.removeItem(DRAFT_KEY);
  }
});

// Clear after successful submit
form.addEventListener('submit', () => {
  localStorage.removeItem(DRAFT_KEY);
});

Le debounce de l’appel de sauvegarde (500 ms ici) évite de solliciter le stockage à chaque frappe. Encapsulez toujours setItem dans un try/catch — les navigateurs peuvent lever, et lèvent effectivement, QuotaExceededError, particulièrement dans les environnements à faible capacité de stockage ou lorsque le stockage tiers est partitionné. Encapsuler JSON.parse dans un try/catch est également une bonne pratique, puisqu’un brouillon corrompu provoquerait sinon une exception et casserait l’étape de restauration.

Ce qu’il ne faut pas stocker

Ne persistez jamais de mots de passe, numéros de carte bancaire, jetons d’authentification ou autres données personnelles sensibles dans localStorage ou sessionStorage. Ces API sont accessibles à tout JavaScript exécuté sur la page, ce qui les rend vulnérables aux attaques XSS. Si votre formulaire collecte des champs sensibles, excluez-les entièrement de votre logique de brouillon.

À savoir également : dans les contextes embarqués ou tiers, les navigateurs partitionnent ou restreignent de plus en plus l’accès au Web Storage. Ne supposez pas que le stockage est toujours disponible — vérifiez-le et gérez les échecs proprement.

Effacer les brouillons et gérer les cas limites

Supprimez toujours le brouillon après une soumission réussie du formulaire. Des brouillons obsolètes qui réapparaissent de façon inattendue déroutent les utilisateurs. Si la structure de votre formulaire évolue au fil du temps, envisagez de versionner votre clé de stockage (par exemple, contact_form_draft_v2) afin que les anciens brouillons ne provoquent pas d’erreurs silencieuses lors de la restauration.

Conclusion

La persistance des formulaires dans le navigateur ne nécessite ni bibliothèque ni backend. Un peu de JavaScript bien pensé — sauvegardes debouncées, restaurations sécurisées et nettoyage à la soumission — suffit à éviter la perte de données et à rendre vos formulaires sensiblement plus fiables.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.