Mailto ou formulaire : lequel perd moins de prospects ?

Tout site web finit par se poser la même petite question : lien mailto: ou formulaire de contact ? Ça a l'air cosmétique. Ça ne l'est pas - les deux échouent de façons totalement différentes, et l'un des deux échoue en silence.

Comment se comporte réellement un lien mailto

<a href="mailto:you@example.com"> demande au système d'exploitation du visiteur d'ouvrir le client mail par défaut. Cette hypothèse s'effondre en permanence :

• Utilisateurs de webmail sur ordinateur - une grande partie des gens lisent Gmail dans un onglet de navigateur et n'ont aucun client mail de bureau configuré. Cliquer sur votre lien ouvre un assistant de configuration Outlook vide, ou rien du tout. Le visiteur hausse les épaules et repart.
• Ordinateurs partagés ou professionnels - le client configuré, s'il y en a un, n'est pas le sien.
• Le contexte du visiteur est perdu - il quitte votre page pour une autre application, et le moindre enthousiasme à moitié tapé a mille occasions de s'évaporer.

Le plus cruel : vous ne voyez jamais rien de tout ça. Un formulaire cassé lève une erreur que vous pouvez détecter ; un mailto qui échoue est invisible. Vos prospects n'arrivent tout simplement pas, et le site donne l'impression de « ne pas recevoir de demandes ».

Il y a un second coût : l'adresse dans le href est du texte brut dans votre HTML, récoltable par tous les robots qui parcourent le web. C'est un abonnement à vie au spam pour l'adresse à laquelle vous tenez le plus.

Comment se comporte un formulaire de contact

Un formulaire garde le visiteur sur votre page, fonctionne sur tout appareil doté d'un navigateur (donc tous), et vous donne une structure : vous décidez des champs, donc chaque demande arrive avec une adresse de réponse et assez de contexte pour agir. Avec un backend de formulaires derrière, vous obtenez aussi un filtrage anti-spam, du stockage, et une notification dès qu'une demande arrive - sans exposer d'adresse e-mail nulle part dans votre markup.

Le compromis est une friction honnête : un formulaire demande plus de markup qu'une balise d'ancrage, et un formulaire mal conçu (dix champs obligatoires, CAPTCHA hostile) peut perdre plus de monde qu'un mailto. Limitez-vous à e-mail + message, et à une protection anti-spam invisible pour les humains - honeypot et limitation de débit en premier, un challenge moderne comme Turnstile seulement si la pression l'exige. (Voir protection anti-spam pour formulaire de contact.)

Quand un mailto convient vraiment

• Pages personnelles et README où le volume est proche de zéro et le public est technique
• Situations où l'e-mail est le livrable - listes « demandes presse : press@… » dans les pieds de page
• En ligne de secours sous votre formulaire : « le formulaire ne fonctionne pas ? écrivez-nous à … » (utilisez un format résistant au scraping si l'aspiration d'adresses vous inquiète)

Quand un formulaire se rentabilise

Dès que les demandes ont une valeur monétaire - travail client, intérêt produit, réservations - le mode d'échec silencieux du mailto devient inacceptable. On ne peut pas mesurer ce qui n'arrive jamais.

Pour les sites statiques, ajouter le formulaire n'est plus la partie difficile ; c'est un seul attribut pointant vers un backend de formulaires :

Les soumissions sont stockées, filtrées, et envoyées sur votre téléphone. Le lien mailto peut rester - en solution de secours, là où il a sa place.