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. 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://api.qualisend.com/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, 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 objet result contenant un status, un code reason, un score de 0 à 100 et un ensemble de sub_flags. Une adresse délivrable revient à peu près comme ceci :

{
  "result": {
    "status": "deliverable",
    "reason": null,
    "score": 95,
    "sub_flags": { "disposable": false, "role": false, "free": 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.

É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 après le module HTTP 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 analysé de la réponse HTTP :

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 branche undeliverable/sans correspondance comme route de repli afin que 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 le module HTTP, 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.

Foire aux questions#

Existe-t-il un module Qualisend natif pour Make ?#

Pas pour le moment. Les intégrations natives de Qualisend avec les plateformes sont en cours de refonte, il n'y a donc pas encore d'application dédiée à rechercher dans la liste des modules de Make — c'est prévu dans la feuille de route. En attendant sa sortie, la méthode prise en charge pour vérifier des e-mails avec Make est le module générique HTTP → Faire une requête pointé vers l'API Qualisend, exactement comme le décrit ce guide. L'approche HTTP est aussi plus flexible : vous contrôlez la requête, les en-têtes et la logique de routage.

Combien d'opérations le scénario consomme-t-il par e-mail ?#

Environ une opération par module exécuté : le déclencheur, la requête HTTP et la route active du routeur comptent chacun. Ainsi, une seule soumission vérifiée représente quelques opérations, et 1 000 soumissions quelques milliers — ce qui reste largement dans les limites de la plupart des offres Make payantes. Si votre volume rend la tarification à l'opération pénalisante, basculez ce trafic vers l'export CSV et la vérification en masse, qui ne consomment aucune opération.

Quel statut dois-je laisser passer vers mon outil e-mail ?#

Uniquement deliverable pour un filtrage strict. Si vous souhaitez conserver davantage d'adresses, autorisez deliverable ainsi que risky/unknown, mais dirigez celles-ci vers un segment distinct et de priorité inférieure plutôt que vers votre flux principal — de nombreux résultats risky sont des domaines catch-all qui peuvent tout de même délivrer. Rejetez toujours undeliverable, et envisagez aussi de bifurquer sur le sous-indicateur disposable si votre produit est sensible à la réputation.

Comment tester le scénario avant de l'activer ?#

Utilisez le bouton Exécuter une fois de Make avec une adresse connue comme valide et une autre connue comme invalide, et observez la bulle sur le module HTTP afficher le status renvoyé — puis vérifiez que chaque route du routeur s'active pour la bonne entrée. Pour des vérifications ponctuelles rapides en dehors de Make, collez une adresse dans le vérificateur d'e-mails gratuit et comparez le verdict à celui renvoyé par votre scénario.

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.