Du formulaire
à la fiche.

Le premier est le formulaire qui ouvre le client mail du visiteur au lieu d'envoyer des données : une partie des demandes n'est jamais envoyée et rien ne le signale. Le deuxième est la notification unique : si le courriel d'alerte part dans les indésirables ou si le service d'envoi est en panne, la demande n'existe nulle part. Le troisième est la boîte mail comme outil de suivi : la demande arrive, elle est lue, puis elle descend sous les autres messages et personne ne sait plus si elle a été traitée.

La demande s'enregistre en base avant que la notification ne soit envoyée. Cet ordre paraît technique, il est décisif : un service d'envoi de courriels tombe plusieurs fois par an, et dans l'ordre inverse chaque panne se traduit par des demandes perdues sans trace. Nous appliquons cette règle sur tous nos formulaires, et nous gardons l'ancien mécanisme en secours au cas où la route d'enregistrement échoue : aucune demande ne doit être perdue à cause du dispositif de mesure.

Un courriel ne porte ni âge, ni statut, ni historique. Une fiche porte les trois, et c'est ce qui permet de voir qu'une demande attend depuis deux jours, qu'elle a été appelée deux fois sans réponse, et d'où elle vient. Cette différence est tout l'intérêt de l'opération : les demandes ne se perdent plus parce qu'elles sont visibles en permanence dans un écran qui ne se remplit pas d'autre chose.

Prenez un téléphone, remplissez votre propre formulaire comme un client, en vous mettant dans les conditions réelles, puis vérifiez que la fiche existe, qu'elle porte bien le canal d'arrivée, et que la notification est arrivée. Faites-le après chaque modification du site. La plupart des pertes de demandes que nous trouvons en audit viennent d'un formulaire cassé par une refonte, et personne ne l'avait testé depuis.