Le désabonnement en un clic est un protocole, pas un bouton

par | Sep 7, 2026 | Emailing

Google l’exige des expéditeurs groupés. Yahoo aussi. Tout le monde appelle cela « le désabonnement en un clic », et presque tout le monde croit qu’il s’agit d’un lien à mettre dans le message.

C’est un protocole. Il tient dans une spécification de neuf pages, publiée en janvier 2017 sous le numéro RFC 8058, et il impose des choses que votre plateforme d’envoi ne fait peut-être pas.

Deux en-têtes, pas un bouton

L’ancêtre date de 1998 : la RFC 2369 a introduit l’en-tête List-Unsubscribe, qui permet à un client de messagerie de connaître l’adresse de désabonnement sans que l’utilisateur ait à chercher dans le corps du message.

La RFC 8058 ajoute un second en-tête, List-Unsubscribe-Post, et surtout une mécanique précise. Le bouton « Se désabonner » que Gmail affiche à côté du nom de l’expéditeur n’est pas un lien cliqué par l’utilisateur : c’est une requête émise par le fournisseur de messagerie, en votre nom.

Ce que la spécification exige, mot pour mot

Une adresse en HTTPS, obligatoirement. « The List-Unsubscribe header field MUST contain one HTTPS URI. » Pas de HTTP simple. Un mailto seul ne satisfait pas l’exigence, et Google le rappelle explicitement dans ses consignes.

Une requête POST, avec un corps imposé. Le fournisseur envoie un POST vers cette adresse, en transmettant la paire List-Unsubscribe=One-Click comme corps de requête. Le format doit être multipart/form-data de préférence, ou application/x-www-form-urlencoded.

Aucun contexte transmis. « The POST MUST NOT include cookies, HTTP authorization, or any other context information. » Votre point de terminaison reçoit donc une requête anonyme : toute l’identification du destinataire doit tenir dans l’adresse elle-même, sous une forme qui ne se devine pas.

Aucune redirection. « The mail sender MUST NOT return an HTTPS redirect. » Renvoyer vers une page de confirmation est un manquement à la spécification.

Une signature DKIM qui couvre les deux en-têtes. C’est l’exigence la plus méconnue, et la plus discriminante : « Senders MUST apply at least one valid DKIM signature to the message. The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature. » Et si cette signature manque, le fournisseur de messagerie « SHOULD NOT offer a one-click unsubscribe for that message ».

Traduction opérationnelle : sans une signature DKIM correctement configurée qui inclut ces deux en-têtes dans son champ h=, votre bouton n’apparaît pas. Vous avez respecté la lettre de l’exigence de Google, et vous êtes non conforme.

Ce que la spécification ne dit pas, et qu’on lui fait dire

La RFC 8058 n’interdit pas formellement d’afficher une page de confirmation à un humain qui suivrait le lien dans un navigateur. Ce qu’elle exige, c’est que le POST suffise, seul, à effectuer le désabonnement, sans qu’aucun logiciel n’ait à interpréter le contenu d’une page.

La conséquence est simple : votre point de terminaison doit traiter le désabonnement à la réception du POST. Immédiatement. Pas au clic suivant, pas après validation d’un formulaire de préférences, pas après confirmation par courriel.

Le centre de préférences reste possible pour l’internaute qui arrive par le lien du corps du message. Il ne peut pas être la seule voie de sortie.

Le délai, et pourquoi il compte plus que le mécanisme

Google demande de traiter les demandes de désabonnement sous 48 heures. Yahoo dit deux jours, et précise qu’au-delà l’expéditeur n’est plus considéré comme conforme.

Deux jours pour une opération qui devrait prendre deux secondes, c’est une tolérance généreuse, accordée à des systèmes qui synchronisent des listes par lots. Elle n’excuse pas les cas où le message suivant part le lendemain matin.

Et il y a une raison très concrète de faire mieux que la tolérance : un destinataire qui se désabonne et reçoit encore un message ne se désabonne pas une seconde fois. Il clique sur « Signaler comme spam ». Vous venez d’échanger une sortie propre contre une plainte, et la plainte est le seul chiffre qui décide de votre délivrabilité.

Le désabonnement est aussi une obligation juridique, ailleurs et autrement

Ces exigences sont techniques et privées : elles émanent d’opérateurs de messagerie, pas d’un législateur.

Le droit, lui, dit autre chose, et dans certains cas moins. Aux États-Unis, le CAN-SPAM Act accorde dix jours ouvrables pour traiter une demande. En France, le droit d’opposition à la prospection est absolu et sans motif à fournir, et la faculté de s’opposer doit être offerte à chaque envoi.

Vous n’avez donc pas un délai, vous en avez plusieurs, et c’est le plus court qui vous gouverne. Dans les faits, le plus court est presque toujours celui des opérateurs de messagerie, parce que c’est celui qui a une sanction immédiate.

Ce que vous faites demain matin

Envoyez-vous une campagne réelle et ouvrez les en-têtes complets du message reçu. Cherchez List-Unsubscribe et List-Unsubscribe-Post, puis cherchez le champ h= de la signature DKIM et vérifiez que les deux noms y figurent.

Testez ensuite votre point de terminaison en émettant vous-même le POST, avec le corps exact prévu par la spécification, sans cookie ni en-tête d’authentification. Si la désinscription n’est pas enregistrée à l’issue de cette seule requête, votre bouton est décoratif.

Enfin, mesurez le délai réel entre la désinscription et le dernier message envoyé à cette adresse. Chez la plupart des expéditeurs, ce délai n’est pas mesuré, et c’est précisément là que se fabriquent les plaintes. Quand la sortie est prise en charge par le mécanisme d’envoi lui-même, comme le fait le lien de désinscription chiffré de Sestaro, ce délai tombe à zéro par construction.

Sources

LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.