Abandon et reprise

Extension payante. Un formulaire peut proposer au visiteur de conserver sa saisie et de lui envoyer un lien pour la finir plus tard.

Ce document décrit ce que le module garantit et ce qu’il refuse. Le guide utilisateur en donne la version courte, dans la section « Reprendre un formulaire commencé ».

Deux consentements, et le second est le vrai

L’administrateur active la fonctionnalité pour un formulaire. Le visiteur donne le sien, explicitement, avant la première sauvegarde — une case qui n’est jamais cochée d’avance.

Ne valent pas consentement : avoir cliqué « suivant », avoir saisi une adresse, avoir rempli un champ de consentement générique qui porte sur autre chose, ou ne rien avoir décoché. Refuser laisse le formulaire pleinement utilisable : aucune ligne, aucune relance, aucune donnée de parcours.

Le consentement est conservé avec la version du texte accepté. Savoir qu’une personne a consenti ne dit rien si l’on ne sait pas à quoi : un texte réécrit sans changer de version rendrait l’accord inopposable. L’administration affiche les deux.

Le texte par défaut dit ce qui est conservé, pourquoi, combien de temps et qu’un courriel sera envoyé. C’est un point de départ honnête, pas un avis juridique : il revient au site de l’accorder à sa politique de confidentialité et à son marché.

Rien n’est reproduit du cœur

Le cœur sait déjà enregistrer un brouillon, en retirer les valeurs sensibles, fabriquer un lien de reprise signé, le promouvoir en soumission et le purger. Ce module n’a ni route de sauvegarde, ni notion de brouillon à lui : la sauvegarde passe par SubmissionHandler::save_draft(), avec ses contrôles anti-spam, son jeton, sa disponibilité et sa sanitation.

Il écoute l’événement qui suit — solis_forms_draft_saved — et travaille sur ce que le cœur a déjà retenu.

Un défaut corrigé au passage

Jusqu’ici, chaque sauvegarde créait une nouvelle entrée. Cinq clics sur « enregistrer » donnaient cinq brouillons, cinq liens de reprise valides et cinq copies de la même saisie personnelle en base ; une sauvegarde automatique en aurait produit une par minute.

DraftManager::save() accepte désormais le brouillon à reprendre, résolu par sa référence signée — un identifiant seul ne permet pas d’écrire dans la saisie d’autrui.

Le parcours est réduit, côté serveur

L’objectif est une relance utile, pas une analytique de navigation. Ce qui est conservé :

• le référent ramené à son origine et son chemin, sans chaîne de requête ;
• les paramètres de campagne de la page d’entrée, et seulement les cinq clés utm_* ;
• les pages internes déjà vues, dédoublonnées, limitées à dix et tronquées ;
• l’étape où la saisie s’est arrêtée ;
• la première et la dernière activité.

Tout le reste est jeté. La réduction a lieu sur le serveur : une requête forgée ne doit pas permettre de ranger une URL externe, une chaîne de requête ou des clés arbitraires dans la base d’un site — ce qui en ferait, à l’insu de son propriétaire, un entrepôt de données de navigation.

Pourquoi ces refus précisément :

• la chaîne de requête d’un référent porte régulièrement un identifiant de session, un jeton de réinitialisation ou un terme de recherche ;
• les adresses externes : suivre une personne hors du site est exactement ce que cette fonctionnalité promet de ne pas faire ;
• le fragment ne quitte normalement pas le navigateur, et le recevoir signale déjà une requête composée à la main.

Ni adresse IP, ni agent, ni contenu de champ, ni identifiant de session, ni élément de page. L’entrée du cœur garde son propre contexte selon ses règles ; ce module ne le réplique pas.

L’adresse n’est pas recopiée

Seule son empreinte — un HMAC — figure dans la table Pro, et elle sert à constater que deux brouillons visent la même boîte sans qu’aucune liste n’affiche d’adresse. L’adresse réelle est lue dans le brouillon au moment d’envoyer, et disparaît avec lui.

Une seconde copie aurait survécu à sa source et aurait fallu purger à part.

Une relance, et une seule

Elle part quand toutes les conditions sont réunies : la récupération est active, le consentement existe, une adresse valide figure dans le brouillon, le brouillon est toujours un brouillon, et le délai est atteint.

La tâche programmée ne fait pas confiance à ce qui l’a programmée. Entre les deux, la saisie a pu être soumise, le consentement retiré, le formulaire désactivé, l’adresse changée. Tout est relu avant l’envoi, et une tâche devenue sans objet se termine sans rien expédier.

« Envoyer maintenant », depuis l’administration, n’y échappe pas : la relance reste limitée à une par brouillon. Une relance manuelle supplémentaire est une décision produit, pas une porte ouverte au spam — et c’est précisément depuis cet écran qu’on serait tenté d’insister.

Le message

Le nom du formulaire, l’échéance, deux liens. Aucune valeur saisie, aucune donnée de parcours, aucun résumé. Le message part vers une boîte, et ce qu’il contient en sort.

Les liens, et leur révocation

Le cœur sait fabriquer un lien de reprise signé. Il ne sait pas le révoquer : une signature ne connaît que sa propre validité, et ignore qu’on a voulu la retirer. Or un retrait de consentement doit faire cesser un lien déjà parti.

Le courriel porte donc un lien de l’extension, dont seule l’empreinte est stockée. Révoquer régénère le secret : l’ancien ne correspond plus à rien. Le lien du cœur n’est fabriqué qu’au moment d’un clic valide, et n’existe que le temps d’une redirection — il ne reste ni dans l’historique, ni dans la barre d’adresse, ni dans le journal d’accès.

Les deux liens — reprendre, effacer — sont signés dans des contextes distincts. Les signer dans le même permettrait de présenter l’un à la route de l’autre dès lors que les rangs coïncident, et d’effacer le brouillon de quelqu’un avec le lien censé le lui rendre.

Le lien d’effacement fonctionne sans connexion, efface immédiatement le brouillon et tout ce qui est conservé à son sujet, et affiche une confirmation qui ne nomme ni l’adresse, ni le formulaire, ni ce qui a été effacé : il peut être ouvert par qui a reçu le courriel transféré.

Sans JavaScript

Aucune sauvegarde automatique, aucune donnée de parcours, et pas de case de consentement — demander un accord pour quelque chose qui n’aura pas lieu n’aurait pas de sens. Le bouton de reprise manuel du cœur reste disponible.

Rétention et purge

La durée suit celle de « enregistrer et reprendre », bornée entre un et trente jours. Supprimer une soumission efface sa récupération ; une tâche horaire envoie les relances dues et retire les récupérations dont le brouillon a disparu — par une requête directe, ou pendant que l’extension était désactivée.

Une saisie aboutie passe en resumed : plus aucune relance n’en part, et son parcours ne survit pas comme donnée autonome.

Ce que le module ne fait pas

Ni cookie tiers, ni pixel, ni empreinte de navigateur, ni géolocalisation, ni rejeu de session, ni capture de frappes. Ni séquence de plusieurs courriels, ni test A/B, ni score marketing, ni segmentation, ni envoi par un prestataire externe.

Il ne suit pas les pages qui ne contiennent pas le formulaire, ne reconstitue pas l’historique du navigateur et ne suit personne d’un site à l’autre.