Comment vérifier des e-mails avec Make (Integromat)

Vous pouvez vérifier des e-mails avec Make (anciennement Integromat) dès aujourd'hui, même s'il n'existe pas encore de module Qualisend dédié dans l'application. Le principe consiste à construire un scénario autour du module HTTP générique : un déclencheur se déclenche à l'arrivée d'une nouvelle adresse, une requête HTTP envoie cette adresse en POST à l'API Qualisend, et un routeur ou un filtre lit le verdict et bifurque le flux — de sorte que seules les adresses délivrables poursuivent vers votre ESP ou votre CRM, tandis que les adresses risquées ou non délivrables sont mises de côté. Ce guide construit ce scénario de bout en bout.

La réponse en bref#

Il n'existe aucune application native à installer pour l'instant (c'est prévu dans la feuille de route), la méthode prise en charge est donc un scénario en trois parties : un déclencheur (nouvelle soumission de formulaire, nouvelle ligne, ou un webhook personnalisé vers lequel vous pointez un formulaire), un module HTTP → Faire une requête qui appelle l'API de vérification avec l'adresse e-mail, et un routeur avec des filtres par route qui lisent le status renvoyé et décident de la suite. Si la réponse indique que la vérification de la boîte est encore pending, un court Sleep puis un GET sur la tâche renvoyée récupèrent d'abord le verdict final. Conservez votre clé API dans les en-têtes du module — jamais dans un champ de formulaire public — et configurez le module HTTP pour qu'il continue de fonctionner si l'API renvoie une erreur, afin qu'un incident passager ne fasse jamais perdre un vrai prospect.

Deux façons de vérifier des e-mails avec Make#

Avant de câbler quoi que ce soit, choisissez le modèle qui correspond au degré de fraîcheur dont les données ont besoin :

1. En temps réel, soumission par soumission (un scénario). Chaque nouvelle adresse est vérifiée dès son arrivée et acheminée sur-le-champ. C'est le sujet principal de ce guide et le bon choix lorsque le verdict change la suite des événements — conditionner un e-mail de double opt-in, taguer un prospect ou écarter une inscription factice.
2. Par lots, a posteriori (un CSV). Laissez les soumissions s'accumuler dans une feuille de calcul ou votre ESP, exportez-les périodiquement et passez-les dans une tâche de vérification en masse. Plus simple, moins cher par adresse, et mieux adapté lorsque vous avez simplement besoin d'une liste propre avant un envoi plutôt que d'une décision instantanée.

La plupart des équipes finissent par faire les deux : un scénario sur la collecte en direct, complété par un nettoyage de liste mensuel pour rattraper les adresses devenues obsolètes depuis l'inscription.

Étape 1 : le déclencheur#

Démarrez le scénario avec ce qui capture l'adresse. Make propose des centaines de modules de déclenchement — « Watch Responses » dans une application de formulaires, « Watch Rows » dans Google Sheets ou Airtable, « New Lead » dans un CRM. Si votre outil de formulaire n'a pas de module Make dédié, placez un webhook personnalisé comme premier module et pointez l'URL de webhook de votre formulaire vers lui ; Make génère une URL unique et vous montre la structure des données entrantes dès l'arrivée de la première soumission.

Quel que soit votre choix, la sortie importante est un champ contenant l'adresse e-mail, que les modules suivants référencent sous forme de jeton mappé — Make les affiche comme des pastilles colorées sur lesquelles vous cliquez dans un champ, issues du lot de sortie du déclencheur. Dans les exemples ci-dessous, ce jeton s'écrit {{1.email}}, où 1 est le module déclencheur.

Étape 2 : envoyer l'adresse en POST avec le module HTTP#

Ajoutez un module et choisissez HTTP → Faire une requête. C'est l'étape qui appelle réellement Qualisend. Configurez-le ainsi :

Activez Analyser la réponse pour que Make relise le JSON sous forme de champs mappables plutôt qu'en chaîne brute. Dans le champ Contenu de la requête, saisissez le corps et déposez-y la pastille email du déclencheur :

{ "email": "{{1.email}}" }

La requête que Make envoie pour votre compte ressemble à ceci — les valeurs de remplacement sont à compléter à partir de la documentation développeur, qui indique le point de terminaison exact et montre la requête dans plusieurs langages :

POST https://app.qualisend.com/api/v1/verify
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{ "email": "jane@example.com" }

Utilisez une clé à portée limitée créée pour ce scénario plutôt qu'une clé à accès complet, de sorte que si l'historique d'exécution du scénario venait à fuir, la clé ne puisse que vérifier des adresses et consulter leurs résultats, rien d'autre. Ne placez jamais la clé dans le formulaire lui-même ni dans un champ côté client — elle n'a sa place que dans les en-têtes du module HTTP, qui s'exécutent côté serveur au sein de Make.

Lorsque vous cliquez sur Exécuter une fois, Make affiche le lot de réponse. Vous récupérez un job_id et un objet result contenant un status, un code reason (null tant que la vérification de la boîte n'est pas terminée), un score de 0 à 100, un ensemble de sub_flags et un champ smtp qui indique si la vérification de la boîte est terminée. Une nouvelle adresse qui passe les contrôles de syntaxe et de domaine revient en général à peu près comme ceci :

{
  "job_id": "b7e4c2a0-1d3f-4e8a-9c6b-2f5a8d0e7c41",
  "result": {
    "status": "unknown",
    "reason": null,
    "score": 61,
    "smtp": "pending",
    "sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
  }
}

Ce sont ces noms de champs qui servent de base à la bifurcation de l'étape suivante, alors notez comment Make les mappe — vous référencerez result: status, result: score et les sub_flags individuels dans les filtres. Pour comprendre en détail ce que signifie chaque statut et comment le pipeline y parvient, consultez comment fonctionne la vérification d'e-mails.

Quand la vérification de la boîte est encore en cours#

smtp vous indique si result est définitif. cached ou skipped signifie que oui : vous pouvez router dessus tout de suite. pending, le cas habituel pour une nouvelle adresse, signifie que la vérification SMTP de la boîte est encore en cours et que status est un unknown provisoire. Ne rappelez pas /verify pour cette adresse ; interrogez plutôt sa tâche :

1. Juste après le module HTTP, ajoutez un routeur à deux routes : l'une filtrée sur result: smtp égal à pending, l'autre en route de repli pour tout le reste.
2. Sur la route pending, ajoutez un module Sleep (dans Tools) réglé sur environ 60 secondes.
3. Ajoutez ensuite un second module HTTP → Faire une requête : méthode GET, URL https://app.qualisend.com/api/v1/jobs/{{2.data.job_id}}?include=results (où 2 est le module du POST), le même en-tête Authorization et Analyser la réponse activé.

Le status de la tâche elle-même passe à completed une fois la vérification terminée, et le verdict final est le premier élément de son tableau results. Pour une adresse délivrable, cela ressemble à peu près à ceci :

{
  "status": "completed",
  "results": [
    {
      "email": "jane@example.com",
      "status": "deliverable",
      "reason": "accepted_email",
      "score": 92,
      "sub_flags": { "disposable": false, "role": false, "free_mail": false, "catch_all": false }
    }
  ]
}

Si la vérification est encore en cours quand le GET s'exécute (un serveur qui pratique le greylisting peut la prolonger de plusieurs minutes), la tâche et son élément affichent encore pending ou processing ; l'étape suivante les envoie vers la route de vérification au lieu de les écarter. Les deux routes de cette étape aboutissent aux mêmes routes de verdict : sur la route pending, elles lisent le status du premier élément de results du GET ; sur la route de repli, result: status du POST.

Étape 3 : bifurquer sur le verdict avec un routeur#

Un résultat de vérification sur lequel vous n'agissez pas est un crédit gaspillé. Tout l'intérêt est d'acheminer les adresses différemment, et dans Make cela passe par le module routeur.

Placez un routeur au bout de chaque route de l'étape précédente (après le GET sur la route pending) et il se ramifie en autant de routes que nécessaire. Chaque route dispose de son propre filtre (cliquez sur la clé à molette sur la ligne qui part du routeur) qui teste le status définitif :

Make évalue les routes de gauche à droite et, à moins que vous ne marquiez une route comme route de repli (la route sans filtre), chaque route correspondante s'exécute — gardez donc vos conditions mutuellement exclusives sur status pour éviter qu'une même adresse ne parte dans deux branches. Définissez la route de vérification comme route de repli, et non la branche undeliverable : une adresse dont le contrôle est encore pending ou processing atterrit ainsi dans la route de vérification au lieu d'être écartée, et rien ne passe au travers sans être catégorisé.

Vous pouvez aussi bifurquer sur les sous-indicateurs. Si votre produit est sensible à la réputation, ajoutez à la route de vérification une condition qui se déclenche également lorsque sub_flags: disposable vaut true, même si le statut est par ailleurs correct — la même logique appliquée aux adresses disposable, role et free que détaille le décryptage des adresses role, disposable et free. Un filtre de routeur unique accepte plusieurs conditions ET/OU, vous pouvez donc combiner un test de status et un test de sub_flags sur une même route.

Ne laissez pas le module HTTP bloquer un bon prospect#

Une règle prime sur toute bifurcation : échouer en mode ouvert. Si le module HTTP renvoie une erreur — l'API est momentanément lente, une limite d'offre est atteinte, une microcoupure réseau —, vous ne voulez pas que le scénario tout entier s'arrête et avale silencieusement une vraie inscription. Faites un clic droit sur chaque module HTTP (celui du POST et celui du GET), choisissez Ajouter un gestionnaire d'erreurs et attachez une directive Resume qui fournit un lot par défaut avec status réglé sur unknown. Le scénario poursuit alors sur un chemin qui traite l'adresse comme « à vérifier plus tard » plutôt que de l'abandonner. (Vous pouvez également régler la gestion d'erreurs du scénario sur stocker les exécutions incomplètes pour que les exécutions échouées soient mises en file d'attente pour une nouvelle tentative au lieu de disparaître.)

Une API de vérification est un filtre qualité, pas une barrière d'authentification. Bloquer un client payant à cause d'une panne passagère est une issue bien pire que de laisser passer une adresse douteuse et de la rattraper lors de votre prochain nettoyage de liste. Ce même principe d'échec en mode ouvert sous-tend le modèle d'inscription serverless, où un sondage lent ne doit jamais bloquer le formulaire.

Quand un scénario n'est pas le bon outil#

Make est de la colle, et la colle a un coût : chaque adresse vérifiée consomme des opérations, et un appel HTTP par soumission peut vite s'accumuler à grand volume ou sembler démesuré quand vous n'avez pas besoin d'une décision instantanée. Optez plutôt pour la voie par lots lorsque :

• Vous nettoyez une liste qui existe déjà — des milliers de contacts historiques, et non de la collecte nouvelle. Exportez-les et lancez une seule tâche en masse.
• Votre volume est assez élevé pour que la tarification à l'opération devienne pénalisante, et un nettoyage nocturne ou hebdomadaire suffit en fraîcheur.
• Vous préférez ne pas maintenir un scénario en direct pour une tâche qui n'a besoin de s'exécuter qu'occasionnellement.

Dans ces trois cas, faites l'impasse sur le scénario : exportez les soumissions au format CSV depuis votre outil de formulaire, votre feuille de calcul ou votre ESP, et téléversez ce fichier dans le vérificateur en masse de Qualisend. Vous obtenez les mêmes status, score et sous-indicateurs par ligne, téléchargeables sous forme de fichier nettoyé que vous pouvez réimporter. C'est la façon la moins laborieuse de garder une liste saine et de faire baisser votre taux de rebond sans maintenir la moindre automatisation.

Si vous hésitez entre l'approche HTTP de Make et un appel direct à l'API depuis votre propre backend, la comparaison des API expose les arbitrages — un scénario Make l'emporte sur la rapidité de mise en place et ne nécessite aucun serveur, tandis qu'une intégration directe l'emporte sur le coût et le contrôle à grande échelle. Ce même modèle de module HTTP se transpose également sans peine à un workflow n8n auto-hébergé si vous dépassez la tarification à l'opération de Make.

Prêt à le construire ? Récupérez une clé à portée limitée et la forme exacte de la requête dans la documentation développeur, vérifiez n'importe quelle adresse dans le vérificateur d'e-mails gratuit, et démarrez sur l'offre gratuite — 100 crédits suffisent à câbler tout le scénario et à voir une mauvaise adresse être filtrée avant même qu'elle n'atteigne votre liste.