Toutes les bases de données B2B affirment que leurs e-mails sont vérifiés. Presque aucune ne dit quand. Cette omission cache la variable la plus importante de la qualité des données de contact : la vérification n'est pas une propriété de la fiche, mais de la fiche à un instant donné. Un contrôle réussi il y a huit mois vous dit ce qui était vrai il y a huit mois.
Les gens changent de poste, les entreprises migrent leurs serveurs de messagerie, les équipes IT suppriment des alias et les domaines expirent. Les estimations du secteur situent l'obsolescence des e-mails B2B autour de 2 à 3% par mois, ce qui, cumulé, rend obsolète environ un quart à un tiers d'une liste en un an. Un fournisseur qui vérifie à la collecte, quand la fiche entre dans la base, vous vend un instantané qui a commencé à vieillir le jour même où il a été pris.
Une vérification est un horodatage, pas un label
Voyez la mention « vérifié » comme un contrôle d'hygiène réussi : elle a du sens, mais seulement au regard de sa date. Un restaurant inspecté en janvier peut encore vous intoxiquer en octobre. Il en va de même pour une adresse e-mail : le contrôle lui-même peut être irréprochable et le résultat malgré tout périmé.
Voilà pourquoi la bonne question à poser à un fournisseur de données n'est pas « vérifiez-vous ? » mais « de quand date la vérification de la fiche que je m'apprête à exporter ? ». Si la réponse est « du jour où la fiche a été ajoutée », vous achetez l'âge moyen de la base, pas l'état actuel de la boîte mail. La réponse d'Argorant est structurelle : chaque contact est vérifié en SMTP au moment de l'export, si bien que le verdict reflète l'état actuel de la boîte mail et non la date d'ajout de la fiche.
Ce que prouve réellement une vérification SMTP
Il vaut la peine d'être précis sur ce que la vérification signifie techniquement, car les couches les plus légères sont souvent vendues comme si elles constituaient tout le dispositif. Un contrôle de syntaxe prouve qu'une adresse est bien formée. Une recherche DNS/MX prouve que le domaine existe et publie des serveurs de messagerie. Aucun des deux ne prouve qu'une boîte mail existe.
Une vérification SMTP va plus loin : le vérificateur ouvre une vraie connexion avec le serveur de messagerie du destinataire, déroule le début d'un échange de livraison (HELO, MAIL FROM, RCPT TO) et lit le verdict du serveur sur cette boîte mail précise. Puis il se déconnecte avant qu'aucun message ne soit envoyé. Une réponse 250 signifie que le serveur accepte les e-mails pour cette adresse à cet instant. Une réponse 550 signifie le contraire. Aucun e-mail n'arrive dans une boîte de réception ; c'est l'échange lui-même qui sert de test.
Faire cela à grande échelle est plus difficile qu'il n'y paraît, et c'est en partie pour cela que la plupart des fournisseurs ne le font pas au moment de l'export. Les serveurs de messagerie mettent en greylisting les expéditeurs inconnus, limitent les vérifications répétées et répondent différemment selon la réputation de l'adresse IP qui interroge. Un vérificateur de production a besoin d'une logique de relance, d'un rythme maîtrisé et d'une infrastructure d'envoi bien entretenue : des coûts fixes qui n'ont de sens que si la vérification est au cœur du produit, et non une case à cocher.
Il faut toutefois être honnête sur un point : les domaines catch-all. Certains serveurs de messagerie acceptent tous les RCPT TO, que la boîte existe ou non, ce qui rend impossible un verdict définitif au niveau du protocole. La mauvaise réponse consiste à les compter discrètement comme valides. Argorant les marque comme catch-all et les rend facultatifs : c'est vous qui décidez si les résultats accept-all ont leur place dans votre export, en sachant exactement de quoi il s'agit.
Ce que le paiement au contact valide change pour les acheteurs
Le moment de la vérification n'est pas qu'un argument de qualité. Il redessine les incitations du fournisseur. Dans le modèle classique, vous payez chaque fiche débloquée, valide ou non. Que l'adresse rebondisse ou non ne change rien au chiffre d'affaires du fournisseur : les fiches périmées continuent de rapporter. L'obsolescence, c'est votre problème.
La vérification à l'export rend possible un autre modèle de prix : ne facturer que les adresses qui passent la vérification en direct. Sur Argorant, un résultat invalide coûte 0 crédit. Vous ne payez pas l'obsolescence du fournisseur, et le fournisseur a désormais une raison financière directe de garder ses vérifications à jour : chaque fiche périmée qu'il sert est un revenu qu'il n'encaisse pas.
Pour l'acheteur, deux lignes budgétaires n'en font plus qu'une. Vous ne payez plus séparément l'achat d'une liste puis un passage de nettoyage dans un outil de vérification, parce que le nettoyage fait partie de l'achat. Le prix affiché est le prix par contact délivrable, la seule unité qui ait jamais compté.
Comment mettre n'importe quel fournisseur à l'épreuve
Trois questions distinguent les fournisseurs qui vérifient à l'export de ceux qui vérifient à la collecte. Premièrement : « Si j'exporte le même contact deux fois à six mois d'intervalle, est-il revérifié la seconde fois ? » Deuxièmement : « Est-ce que je paie les fiches qui rebondissent ? » Troisièmement : « Comment signalez-vous les domaines catch-all, et puis-je les exclure ? » Une réponse évasive à l'une de ces questions vous indique que le badge de vérification est purement décoratif.
Testez aussi de façon empirique : extrayez un échantillon et passez-le le jour même dans un vérificateur indépendant. Un fournisseur qui vérifie à l'export devrait afficher un taux d'invalides à un chiffre sur des exports frais ; un fournisseur qui vérifie à la collecte révélera l'âge réel de sa base. Avec 630.7M de contacts dans 202 pays, le pari d'Argorant est que la vérification au moment de l'export, et non au moment de la collecte, est la seule définition de « vérifié » qui résiste à l'épreuve d'un vrai envoi.
