Hygiène de base de données et politiques de mise en sommeil

Comment acquérir des adresses sans risque, les valider à l’inscription, gérer au quotidien les rebonds et les plaintes, et mettre en sommeil les destinataires inactifs avant qu’ils ne nuisent à la réputation.

Opérationnelsender

La composition d’une liste de diffusion détermine les indicateurs sur lesquels les fournisseurs de messagerie notent les expéditeurs (voir Indicateurs et valeurs de référence). Cet article couvre tout le cycle de vie d’une adresse : l’acquisition, la validation à l’inscription, la gestion continue des rebonds et des plaintes, et le retrait des adresses inactives (mise en sommeil).

Acquisition : à faire et à éviter

Ne louez, n’achetez et ne collectez jamais de listes d’adresses email. Les trois guides d’ESP s’accordent sur ce point, pour des raisons concrètes :

Les listes achetées contiennent un grand nombre d’adresses invalides, qui font grimper en flèche les taux de rebonds définitifs (AWS SES).
Elles contiennent des adresses pièges, placées précisément pour attraper les expéditeurs illégitimes. Tomber sur l’une d’elles peut nuire aux taux de livraison et à la réputation de façon « irrévocable » (AWS SES).
La collecte d’adresses (scraping), c’est-à-dire des robots qui parcourent des sites web à la recherche d’adresses, est particulièrement risquée, car aucun des destinataires n’a donné son accord (SendGrid).

Pour développer votre liste de façon légitime, donnez plutôt aux gens des occasions de fournir leur adresse volontairement : des pages d’atterrissage qui expliquent ce qu’apporte le programme d’emails, des publicités display qui incitent à l’opt-in, et un consentement explicite et documenté avant tout envoi (SendGrid).

Validation à l’inscription

Pratique	Détail	Source
Double opt-in	Envoyez un lien de confirmation à l’inscription ; n’envoyez rien à l’adresse tant qu’il n’a pas été cliqué. Élimine les rebonds définitifs dus aux fautes de frappe et prouve l’intention.	AWS SES, SendGrid
Validation syntaxique et MX	À l’envoi du formulaire, vérifiez que l’adresse est bien formée (`recipient@example.com`) et que le domaine a des enregistrements MX valides.	AWS SES
CAPTCHA sur les formulaires d’inscription	Empêche les inscriptions de robots, qui empoisonnent la liste.	SendGrid
Détection des fautes de frappe et des adresses jetables	Validez les adresses à l’inscription pour repérer les domaines jetables et suggérer une correction des fautes de frappe courantes (par exemple via une API de validation).	SendGrid
Refus des comptes de rôle et des alias de surveillance	Les adresses comme `postmaster@`, `abuse@` ou `noc@` ne s’inscrivent presque jamais volontairement ; elles peuvent être ajoutées par malveillance, pour saboter l’expéditeur, et sont traditionnellement réservées à ceux qui surveillent les abus liés à l’email.	AWS SES
Contrôle du contenu généré par les utilisateurs	Les inscriptions sur les forums et les envois de formulaires peuvent être remplis de contenu de spammeurs ; ne transmettez jamais sans contrôle des saisies utilisateur dans les emails sortants.	AWS SES
Validation par l’email de bienvenue	Envoyez un email de bienvenue à chaque nouvelle adresse ; retirez automatiquement les adresses dont l’email de bienvenue rebondit.	SendGrid

Un message de bienvenue permet aussi de fixer les attentes : les destinataires qui comprennent pourquoi ils reçoivent des messages se plaignent moins (voir Fondamentaux de la délivrabilité des emails).

Adresses pièges

Deux catégories (SendGrid) :

Pièges vierges (pots de miel) : des adresses qui ne se sont jamais inscrites à quoi que ce soit, placées par les fournisseurs de messagerie et les organisations antispam. On ne peut les obtenir que par des listes achetées ou collectées.
Pièges recyclés : de vraies adresses abandonnées par leurs propriétaires, puis réaffectées comme pièges. Après environ 12 mois d’inactivité, une adresse abandonnée est soit complètement désactivée (elle produit alors des rebonds définitifs), soit transformée en adresse piège.

Les pièges recyclés expliquent pourquoi la mise en sommeil fondée sur l’engagement est indispensable, même pour les listes dont le consentement est irréprochable : une adresse qui a cessé d’interagir il y a un an est peut-être devenue un piège.

Gestion des rebonds

Règles tirées d’AWS SES et de Postmark :

Rebond définitif → retrait immédiat. Ne renvoyez jamais de message à une adresse en rebond définitif ; les rebonds définitifs répétés s’accumulent et nuisent à la réputation auprès du fournisseur de messagerie concerné. La pratique de Postmark pour les systèmes transactionnels : suspendre automatiquement la livraison vers l’adresse, avec une réactivation explicite obligatoire une fois le problème de fond corrigé.
Rebond temporaire → nouvelles tentatives, puis traitement comme un rebond définitif. Les systèmes d’envoi retentent les rebonds temporaires à intervalles pendant les jours qui suivent ; si une adresse produit des rebonds temporaires à répétition d’un envoi à l’autre, traitez-la comme un rebond définitif et placez-la en liste de suppression.
« Boîte pleine » est généralement permanent en pratique. SendGrid : seulement 8,5 % environ des adresses à boîte pleine redeviennent actives dans les 30 jours. Suivez les réponses « boîte pleine » récurrentes et placez en liste de suppression les adresses qui présentent ce profil de façon constante.
Recevez vos notifications de rebond de façon fiable. L’adresse qui collecte les notifications de rebonds et de plaintes doit elle-même accepter les messages. Évitez d’utiliser pour cela une boîte hébergée chez un fournisseur de messagerie : un afflux de notifications de rebond peut être classé en spam ou supprimé ; si vous ne pouvez pas l’éviter, surveillez le dossier spam et ne marquez jamais les messages de rebond comme spam (AWS SES).
Rendez les rebonds traçables. Un rebond identifie la boîte qui a refusé le message, mais pour le rattacher à une campagne, insérez un en-tête X- dont la valeur renvoie à votre système de suivi interne (AWS SES).

Tactiques opérationnelles pour les rebonds transactionnels (Postmark)

Pour les emails de produit ou transactionnels, un rebond signifie souvent un utilisateur que vous ne pouvez pas joindre : un problème de produit, pas seulement un problème de liste.

Arrêtez immédiatement la livraison vers l’adresse en cas de rebond définitif ou de plainte pour spam (pour protéger la réputation)
Alertez automatiquement l’équipe support pour qu’elle enquête
Affichez une notification dans l’application à l’utilisateur concerné lors de sa connexion (« nous n’arrivons pas à joindre votre adresse email »)
Consignez l’événement de rebond dans la fiche du compte
Laissez l’utilisateur réactiver lui-même la livraison après avoir corrigé son adresse
Basculez vers d’autres canaux (SMS, adresse email secondaire) lorsqu’ils sont disponibles
Prévenez les administrateurs ou collaborateurs du compte lorsque l’email d’un utilisateur clé rebondit
Si vous le souhaitez, faites apparaître les réponses automatiques (messages d’absence) dans les contextes collaboratifs
Traitez les webhooks de rebond dans le code de l’application plutôt que par interrogation périodique (polling)
Utilisez un environnement de test isolé (sandbox) pour que les envois de test n’atteignent jamais de vrais destinataires

Gestion des plaintes

Maintenez le taux de plaintes sous 0,1 % (voir Indicateurs et valeurs de référence pour le tableau complet des seuils).
Lorsqu’un destinataire se plaint d’un email marketing, cessez immédiatement de lui envoyer des emails marketing. Si le programme envoie aussi des messages transactionnels ou de notification, il peut être acceptable de continuer à lui envoyer ces types de messages (AWS SES).
Les notifications des feedback loops de plaintes masquent généralement l’adresse du plaignant ; insérez des en-têtes X- personnalisés ou des identifiants dans le corps du message pour pouvoir identifier l’adresse plaignante et la placer en liste de suppression (AWS SES).
Vérifiez que les notifications de plaintes ne sont pas elles-mêmes filtrées comme spam de votre côté.

Désabonnement et gestion des préférences

Le désabonnement en un clic (List-Unsubscribe selon la RFC 8058) est exigé par les règles de Google et de Yahoo pour les expéditeurs de gros volumes, et fait partie du socle de CAN-SPAM (SendGrid).
Placez un lien de désabonnement clair dans le pied de page : les obstacles engendrent des plaintes au lieu de désabonnements.
Proposez un centre de préférences avec un réglage de la fréquence et une option pour « réduire l’abonnement » (moins d’emails plutôt qu’aucun) : l’abonné est conservé et les signaux négatifs diminuent (SendGrid).

Politiques de mise en sommeil

Une politique de mise en sommeil (sunset policy) « réduit la fréquence à laquelle une adresse email reçoit des campagnes, ou la place entièrement en liste de suppression, en fonction de son engagement ou de son absence d’engagement » (SendGrid). Raison d’être : les adresses inactives font baisser les taux d’engagement et, après environ 12 mois d’inactivité, peuvent devenir des rebonds définitifs ou des pièges recyclés.

Un processus de mise en sommeil complet, qui combine les sources :

Définissez l’inactivité selon la date des dernières ouvertures ou des derniers clics (en gardant à l’esprit que le suivi des ouvertures les surestime : donnez plus de poids aux clics ; voir Indicateurs et valeurs de référence).
Réduisez d’abord la fréquence pour les segments qui se refroidissent, plutôt que de cesser de leur écrire.
Vérifiez le statut par d’autres moyens lorsque c’est possible (connexions au site web, historique d’achats) avant d’écrire à une adresse inactive depuis longtemps (AWS SES).
Lancez une campagne de réengagement (reconquête) en dernière étape : un message qui constate que le destinataire ne s’est pas manifesté depuis un moment et lui demande de confirmer qu’il souhaite toujours recevoir vos messages (AWS parle de win-back ; SendGrid, de re-engagement campaign, « une dernière chance »).
Retirez ceux qui ne répondent pas. Après la campagne de reconquête, retirez tous les destinataires qui n’ont pas répondu (AWS SES).
Si vous écrivez à une liste restée longtemps sans contact, envoyez d’abord un message de type bienvenue qui rappelle aux destinataires qui vous êtes et pourquoi ils reçoivent vos messages : cela réduit les plaintes (AWS SES).

Envoyer moins, à des destinataires moins nombreux et de meilleure qualité, améliore généralement le placement en boîte de réception : voir Deux mondes de la délivrabilité des emails.

Voir aussi

Indicateurs et valeurs de référence — les seuils que l’hygiène de base de données protège
Pratiques d’infrastructure d’envoi — les feedback loops qui alimentent la chaîne de traitement de la liste de suppression

#hygiène-de-base-de-données#politique-de-mise-en-sommeil#adresses-pièges#double-opt-in#rebonds#plaintes#liste-de-suppression#réengagement