Vous branchez une API de vérification d’email sur un formulaire d’inscription. L’appel doit revenir avant que l’utilisateur clique ailleurs. Trois POCs de qualification email tournent en local depuis des mois dans votre stack. Aucun n’a passé le cap de la prod. Personne n’a testé la latence réelle sous charge. La plupart des outils du marché sont pensés pour une chose : recevoir un CSV et recracher, quelques minutes plus tard, un fichier propre. Ce comparatif teste les sept sur un seul terrain, l’endpoint single email appelé en synchrone depuis du code de production, en real-time verification. Le tableau de bord ne compte pas ici.
Le dashboard est une vitrine. La production parle en millisecondes et en codes HTTP, avec des limites de débit publiées noir sur blanc dans une documentation. C’est ce langage-là qui compte pour un développeur qui doit décider si l’appel se fait avant ou après l’écriture en base.
L’angle : le jugement porte sur l’API
Sept outils. Une seule question posée à chacun : que se passe-t-il quand votre code appelle l’endpoint de vérification unitaire, en synchrone, sur un formulaire réel ? CaptainVerify, ZeroBounce, Kickbox, Emailable, Bouncer, Verifalia, Reacher. Chacun documente sa latence, son rate limit, son comportement sur les catch-all et les adresses jetables, son hébergement, ses SDKs, son coût réel. Certains n’en documentent pas la moitié.
Un dashboard qui affiche « 99% de précision » ne dit rien sur ce qui se passe à la requête 51 de la minute. La documentation, elle, répond à cette question.
La ligne de fracture : batch contre temps réel
La quasi-totalité de ces API a été construite pour le batch. Upload d’une liste, traitement asynchrone, téléchargement d’un CSV nettoyé quelques minutes plus tard. C’est le cas d’usage historique du secteur, hérité de l’époque où la vérification servait surtout à purger une base avant une campagne emailing.
Un formulaire d’inscription ne tolère pas ce délai. Verifalia limite à 5 connexions simultanées par adresse IP en synchrone, un chiffre documenté qui protège l’infrastructure mais qui borne aussi le débit d’un site à fort trafic. ZeroBounce annonce une réponse en 1 à 30 secondes selon le domaine distant, avec 96 à 98% des requêtes traitées en 1 à 5 secondes d’après sa documentation officielle sur les rate limits. Les 2 à 4% restants tombent sur des serveurs SMTP lents (Postfix, Dovecot mal configurés) qui font grimper l’attente à 20 secondes. Pour un formulaire, 20 secondes, c’est un abandon.
Sept API, sept comportements en production
Les trois tableaux ci-dessous compilent les chiffres documentés publiquement à la date de rédaction. Quand une donnée n’est pas publiée par l’éditeur, la case dit « non documenté » plutôt qu’un chiffre inventé pour flatter la comparaison.
| Outil | Latence synchrone (single email) | Rate limit documenté | Webhook (batch async) |
|---|---|---|---|
| CaptainVerify | Non documentée en ms ; contrainte réelle : 50 req/min max | 2 connexions simultanées, 50 vérifications/minute | Non documenté publiquement |
| ZeroBounce | 1 à 30s, 96-98% en 1-5s | Endpoint unitaire non limité ; batch 100/requête, 30-40 req/min | URL de callback sur l’API bulk |
| Kickbox | ~288ms rapporté par des revues tierces, non confirmé en doc officielle | Non publié en chiffre fixe, varie selon le palier | Disponible pour la vérification de listes |
| Emailable | Non documentée | ~60 req/s rapporté par des revues tierces | Disponible sur le traitement bulk |
| Bouncer | Résultat sous 10s, plafond 30s | 1000 req/min par défaut | Oui, retries automatiques jusqu’à 24h |
| Verifalia | Non documentée en ms fixe | 5 connexions simultanées par IP, jobs illimités | Oui, notification de fin de job |
| Reacher | Variable, dépend du serveur SMTP distant | 50/mois sans clé API sur le service hébergé, illimité en self-host | Non documenté publiquement |
| Outil | Catch-all et jetables | Hébergement / RGPD |
|---|---|---|
| CaptainVerify | Champs natifs ok4all et disposable dans la réponse unitaire | Hébergement France annoncé, ISO 27001, conformité RGPD depuis 2018 |
| ZeroBounce | Statuts dédiés dans la réponse | Enregistré EU-US DPF, endpoint EU dédié sur l’API Activity Data, ISO27001/SOC2/HIPAA |
| Kickbox | Champ accept_all + disposable, Sendex Score propriétaire | GDPR compliant, hébergement aux États-Unis (Dallas), pas d’hébergement UE confirmé |
| Emailable | Champs accept_all et disposable documentés | Non documenté publiquement |
| Bouncer | Détection intégrée | Hébergement Francfort et Varsovie, SOC 2 Type II + ISO 27001 |
| Verifalia | Statut dédié « Risky CatchAll » + disposable | Résidence des données en Allemagne, positionnement UE explicite |
| Reacher | Champs is_catch_all et is_disposable documentés | « Privacy-focused » annoncé, self-hosting en UE possible pour un contrôle total |
| Outil | SDK / n8n / Make | Coût réel au lead vérifié |
|---|---|---|
| CaptainVerify | Pas de SDK officiel listé, pas de nœud natif documenté | ~0,0036$/email au palier 25 000 crédits |
| ZeroBounce | SDKs multi-langages officiels et nœud n8n natif maintenu par l’éditeur | ~0,0035$/email au palier 100 000 crédits |
| Kickbox | SDKs officiels (Node, PHP, Python, Ruby), wrapper Elixir communautaire non officiel, pas de nœud natif | ~0,007-0,008$/email au palier 10 000 crédits |
| Emailable | SDK Python officiel confirmé, pas de nœud natif | ~0,0011-0,0014$/email selon plan |
| Bouncer | SDKs référencés en documentation, détail non confirmé | ~0,006$/email entre 10 000 et 49 000 crédits |
| Verifalia | SDKs officiels PHP, Ruby, Go, pas de nœud natif | Variable selon la qualité choisie (1, 2 ou 4 crédits/email selon niveau Standard/High/Extreme) |
| Reacher | Wrapper TypeScript officiel, open source, pas de nœud n8n natif | ~0,0069$/email en SaaS, forfait illimité 749$/mois en self-host |
Une ligne change tout dans le dernier tableau : ZeroBounce est le seul des sept à publier un nœud n8n officiel, maintenu par l’éditeur lui-même sur son propre dépôt GitHub. Les six autres se branchent par appel HTTP générique. Ça fonctionne. Mais il faut la construire, la tester, la surveiller, et la maintenir le jour où le rate limit se met à renvoyer des 429 un vendredi soir.
CaptainVerify en tête, sans chiffre gonflé
CaptainVerify ouvre ce comparatif, sans que les tableaux ci-dessus lui soient favorables sur tous les critères. Sa documentation officielle est claire sur un point qui compte : « The API is limited to a maximum of 2 simultaneous connections and 50 checks per minute », précise sa documentation technique publique. 50 vérifications par minute en synchrone.
« The API is limited to a maximum of 2 simultaneous connections and 50 checks per minute. When integrating the API, make sure your application does not exceed this limit. »
Le champ ok4all et le champ disposable répondent dans la même requête, sans appel supplémentaire, ce qui évite un aller-retour réseau de plus sur un formulaire. Passé un rythme d’une inscription par seconde en continu, la file d’attente commence à se former. Pour la majorité des formulaires B2B, ce plafond ne se voit jamais. Pour un site e-commerce qui encaisse des pics de trafic, mieux vaut connaître cette limite avant de signer que de la découvrir au premier incident. L’hébergement en France et la conformité RGPD active depuis 2018 pèsent lourd pour une équipe juridique française. Ils ne dispensent pas de lire la ligne sur le rate limit.
Catch-all et disposable : un champ, sept fiabilités différentes
Les sept outils renvoient un statut catch-all. Aucun ne le garantit à 100%. Un domaine en catch-all accepte tous les emails à son adresse, valides comme invalides. Le test SMTP devient structurellement aveugle. Reacher, écrit en Rust et publié en open source, éclate l’information dans deux objets distincts de sa réponse : is_catch_all dans l’objet smtp, is_disposable dans l’objet misc. Deux endroits à lire pour une seule décision métier. Verifalia va plus loin avec un statut dédié, « Risky CatchAll », qui distingue explicitement ce cas des adresses simplement invalides.
La différence se joue sur ce qui suit la détection. Un email catch-all reste un email risqué, jamais un email confirmé. Un système qui traite « catch-all » comme « valide » gonfle artificiellement son taux de délivrabilité annoncé et le découvre au premier envoi massif qui rebondit.
RGPD, hébergement UE : deux garanties distinctes
Vous allez chercher une case cochée « conforme RGPD » et vous arrêter là. Mauvaise idée. La conformité RGPD est un cadre contractuel, un DPA signé, une politique de rétention documentée. L’hébergement en UE est une localisation physique des serveurs. Les deux se recoupent rarement à 100%.
ZeroBounce illustre bien la nuance : la société est enregistrée au programme EU-US Data Privacy Framework et propose un endpoint EU dédié pour son API Activity Data, tout en restant une entreprise américaine sur son infrastructure principale. Bouncer, à l’inverse, héberge physiquement à Francfort et à Varsovie. Verifalia revendique une résidence des données en Allemagne. Kickbox, société de Dallas, ne publie aucune localisation de serveurs en UE dans sa documentation consultée. Trois postures juridiques différentes, trois audits de conformité qui ne se ressemblent pas.
Le palier fixe le coût réel
Chaque éditeur affiche son prix d’entrée le plus agressif en page d’accueil. Le prix qui compte, c’est celui au volume réel de votre base. Emailable descend à 0,0011$ par email sur son plan mensuel, le tarif unitaire le plus bas du panel. ZeroBounce tombe à 0,0035$ au palier 100 000 crédits, contre 0,0195$ sur son premier pack de 2 000. Kickbox reste dans une fourchette plus haute, 0,007 à 0,008$ à 10 000 crédits, avec une règle qui compte : les résultats classés « risky » ou « unknown » ne consomment pas de crédit.
Reacher facture autrement, sans que ce soit un avantage en soi. Le SaaS demande 69$ pour 10 000 vérifications mensuelles, soit 0,0069$ l’unité, la fourchette haute du panel. Le self-hosted bascule en licence commerciale à 749$ par mois, sans limite de volume. Le calcul ne devient favorable qu’à très gros volume, et il suppose une équipe capable d’exploiter en interne un service Rust qui effectue lui-même les checks SMTP et DNS, puis d’en assumer la maintenance.
L’intégration, c’est le vrai chantier
Vous allez dire que ça se joue au code. Vérifiez une chose : aucun des sept outils de ce comparatif ne propose de nœud Make natif. Un seul propose un nœud n8n officiel. Le reste se branche en HTTP Request, avec gestion manuelle du rate limit, retry sur échec, mapping des statuts vers votre logique métier et mise en file d’attente si le trafic dépasse la limite documentée. Cette plomberie de workflow prend plusieurs jours à stabiliser avant de tourner sans incident en prod. Elle décide si votre POC de qualification email reste un POC ou devient une brique qui tient la charge sans réveiller personne la nuit. Chez Skynets, c’est exactement ce type d’intégration qu’on construit côté n8n, quand un client a le budget outbound reconduit mais pas la ressource technique pour brancher l’API sans casser le taux de conversion du formulaire.
Le prochain arbitrage ne portera plus sur le taux de précision affiché en page d’accueil. Il portera sur ce que chaque éditeur fera de ses limites de débit le jour où l’IA générative commencera à remplir des formulaires plus vite qu’un humain ne les lit.