Workflow Make.com de génération de leads locaux

Si vous construisez un workflow Make.com de génération de leads pour la prospection locale, l'étape d'acquisition de données est là où la plupart des scénarios se compliquent. Trouver des entreprises locales, leurs sites web, numéros de téléphone et e-mails de contact implique généralement de maintenir des scrapers de navigateur et des sélecteurs qui cassent. biz collect offre à Make une voie plus propre : un module HTTP envoie une localisation et des mots-clés vers /v1/search, vous recevez un job_id asynchrone, puis une boucle de polling vérifie /v1/jobs/:id jusqu'à ce que le JSON structuré soit prêt. Ce guide construit un scénario Make complet qui trouve des entreprises locales, extrait des e-mails dédupliqués de leurs sites web et écrit les résultats vers Google Sheets, un CRM ou toute app en aval.

Pourquoi utiliser une API pour la génération de leads dans Make ?

Make (anciennement Integromat) excelle à connecter des applications : déclencheurs, appels HTTP, routeurs, iterators, agrégateurs, data stores et scénarios planifiés. Mais la génération de leads locaux comporte une étape d'acquisition de données qui devient fragile si vous tentez de l'automatiser avec du scraping de navigateur dans Make.

Un montage typique "Make Google Maps scraper" commence par un service de navigateur headless, une URL de recherche, des sélecteurs pour les cartes de résultats et une logique distincte pour visiter chaque site web et y trouver des e-mails. Cela peut fonctionner pour une démo, mais crée une maintenance continue. Les mises en page changent, les sessions échouent, les sélecteurs cassent, et l'extraction d'e-mails devient un second scraper à surveiller. Si vous pesez cela contre une API de données, le compromis entre la Google Places API, les scrapers et les API de données d'entreprises expose les différences.

biz collect est conçu pour la forme opposée. C'est une API de contacts d'entreprises native pour les LLM, construite pour les agents, les outils de workflow, les scripts et l'enrichissement CRM. Vous appelez /api/v1/search avec des paramètres comme location, keywords, radius_km et scrape_emails. L'API renvoie un job en file d'attente. Vous interrogez /api/v1/jobs/:id jusqu'à ce qu'il se termine, puis utilisez les fiches JSON renvoyées dans le reste de votre scénario.

Cela laisse votre scénario Make se concentrer sur le routage :

• Lancer des recherches sur planning ou depuis un webhook.
• Demander des données d'entreprises locales structurées à biz collect.
• Attendre et interroger jusqu'à la fin du job asynchrone.
• Diviser les entreprises renvoyées en bundles individuels.
• Filtrer, dédupliquer ou scorer les fiches.
• Envoyer les leads qualifiés vers Google Sheets, HubSpot, Pipedrive, Airtable, Notion ou une autre app.

Pour les détails d'API, commencez par les docs API, les exemples d'intégration dans intégrations et les limites de plan dans tarifs. Pour voir le modèle recherche-et-polling asynchrone avant de construire, la page comment fonctionne biz collect parcourt le même cycle que ce scénario automatise. La documentation de Make est utile pour les modules standard employés ici, notamment le module HTTP, l'outil Sleep, l'Iterator et le module Google Sheets.

Ce que construit ce scénario

Le scénario de ce tutoriel automatise les leads locaux de la requête de recherche jusqu'à la sortie vers la destination. Il utilise des modules Make standard, biz collect gérant la recherche d'entreprises et Make l'orchestration.

Le scénario final ressemble à ceci :

1. Un déclencheur lance le scénario manuellement, sur planning ou depuis un webhook.
2. Un module HTTP envoie une requête POST vers /api/v1/search de biz collect.
3. La réponse renvoie un job_id et le statut du job.
4. Un module Sleep fait une brève pause avant le polling.
5. Un second module HTTP appelle /api/v1/jobs/:id.
6. Un routeur ou repeater vérifie si le statut du job est completed.
7. S'il n'est pas terminé, le scénario attend et interroge à nouveau, avec une limite de tentatives.
8. Une fois terminé, un Iterator transforme les entreprises renvoyées en bundles individuels.
9. Des modules de destination envoient les leads vers Google Sheets, un CRM ou une autre app.
10. Des routes d'erreur gèrent les jobs échoués, les timeouts et les jeux de résultats vides.

Vous pouvez adapter le même schéma pour de la prospection ponctuelle, des scans de marché récurrents, des listes de leads d'agence, l'enrichissement CRM ou des workflows d'agent IA qui ont besoin de données de contact d'entreprises locales vérifiées.

Prérequis

Avant de construire le scénario, il vous faut :

• Un compte Make, sur tout plan autorisant les modules HTTP.
• Une clé API biz collect.
• Une destination pour les leads, comme Google Sheets, HubSpot ou Pipedrive.
• Une définition de recherche claire : localisation, mots-clés de catégorie, rayon et si vous voulez extraire les e-mails des sites web.

biz collect est gratuit au départ avec 200 crédits d'inscription et sans carte bancaire. C'est suffisant pour construire, tester et lancer de petits jobs de prospection avant de mettre le scénario sur un planning de production. Consultez tarifs pour les limites de plan actuelles.

Flux de données et forme de l'API

biz collect utilise un flux de job asynchrone car la recherche d'entreprises locales et l'extraction d'e-mails de sites web peuvent prendre plus de temps qu'une requête HTTP synchrone normale. Make gère cela bien car les scénarios peuvent dormir, se ramifier et se répéter.

La requête de base est un POST vers :

https://bizcollect.dev/api/v1/search

Le corps contient les entrées de recherche locale :

{
  "location": "Manchester, UK",
  "keywords": ["letting agent", "estate agent"],
  "radius_km": 12,
  "scrape_emails": true
}

La réponse contient un identifiant de job. Le scénario n'a besoin que du job_id et du statut :

{
  "job_id": "job_123456",
  "status": "queued",
  "poll_url": "/api/v1/jobs/job_123456"
}

Puis Make interroge :

GET https://bizcollect.dev/api/v1/jobs/job_123456

Une fois terminé, le résultat contient des fiches d'entreprises structurées :

{
  "job_id": "job_123456",
  "status": "completed",
  "businesses": [
    {
      "name": "Example Lettings",
      "address": "12 High St, Manchester M1 1AA",
      "phone": "+44 161 555 0101",
      "website": "https://examplelettings.co.uk",
      "emails": ["hello@examplelettings.co.uk", "info@examplelettings.co.uk"]
    }
  ]
}

Le contrat est stable : lancer une recherche, recevoir un job_id, interroger le endpoint du job, puis traiter du JSON structuré. Pour le schéma faisant autorité, utilisez la référence OpenAPI dans les docs biz collect.

Étape 1 : Créer le déclencheur

Commencez par le déclencheur qui correspond à votre cas d'usage :

• Run once pour les tests et les recherches ponctuelles.
• Schedule pour la prospection récurrente, par exemple chaque lundi matin.
• Custom webhook lorsqu'un autre système ou agent doit lancer une recherche dynamiquement.

Pour une première version, lancez le scénario manuellement et codez en dur une localisation et des mots-clés dans le premier module HTTP. Une fois stable, remplacez les valeurs fixes par des données d'un planning, d'une Google Sheet de territoires ou d'un payload de webhook.

Si vous voulez que le scénario accepte des recherches dynamiques, ajoutez un déclencheur Custom webhook et envoyez un corps comme :

{
  "location": "Zurich, Switzerland",
  "keywords": ["law firm", "tax advisor"],
  "radius_km": 10,
  "scrape_emails": true
}

Le module de requête biz collect peut alors mapper les champs entrants du webhook. Gardez le premier scénario simple, confirmez la forme de la réponse, puis paramétrez.

Étape 2 : Ajouter le module HTTP pour /api/v1/search

Ajoutez un module HTTP réglé sur Make a request après le déclencheur. Nommez-le Start biz collect Search.

Configurez-le :

• URL : https://bizcollect.dev/api/v1/search
• Method : POST
• Headers : un en-tête d'autorisation et un en-tête content-type
• Body type : Raw, content type JSON
• Parse response : Yes, pour que Make expose les champs JSON

Utilisez ces en-têtes :

Authorization: Bearer YOUR_BIZCOLLECT_API_KEY
Content-Type: application/json

Pour une recherche de test fixe, utilisez ce corps JSON :

{
  "location": "Miami, FL",
  "keywords": ["med spa", "aesthetic clinic"],
  "radius_km": 20,
  "scrape_emails": true
}

Pour une version webhook, mappez les champs de la requête au lieu de les coder en dur, par exemple {{1.location}} et {{1.keywords}}, où 1 est le module webhook. Si votre déclencheur donne les mots-clés sous forme de chaîne séparée par des virgules, divisez-la en tableau d'abord avec une fonction split() ou un module dédié, car l'API attend une entrée de mots-clés claire et un tableau est le plus facile à contrôler.

Après l'exécution de ce module, vous avez un bundle avec job_id, status et éventuellement poll_url. Si la requête échoue, vérifiez la clé API, le corps et les limites actuelles dans tarifs.

Étape 3 : Attendre avant le premier poll

Ajoutez un module Sleep après la requête de recherche. Nommez-le Wait Before Polling.

Réglez un court délai, de 10 à 20 secondes. L'extraction d'e-mails exige que l'API visite les sites web des entreprises, analyse les pages et déduplique les adresses candidates, donc poller immédiatement après la requête de recherche ajoute généralement du bruit sans améliorer le résultat.

Un point de départ pratique est 15 secondes. Le module Sleep de Make est plafonné à 300 secondes par appel, ce qui est amplement suffisant pour une pause unique ; la boucle de polling des étapes suivantes vous donne le temps d'attente total plus long. Pour les recherches larges, penchez vers le haut ; pour les petits jobs d'enrichissement, baissez-le.

Étape 4 : Poller /api/v1/jobs/:id

Ajoutez un autre module HTTP nommé Poll biz collect Job.

Configurez-le :

• URL : https://bizcollect.dev/api/v1/jobs/{{job_id}}, en mappant le job_id depuis la réponse de recherche
• Method : GET
• Headers : le même en-tête d'autorisation
• Parse response : Yes

En-tête :

Authorization: Bearer YOUR_BIZCOLLECT_API_KEY

La réponse de polling inclut le statut actuel du job. Ramifiez sur ce statut plutôt que de supposer que le premier poll est terminé. Statuts typiques à gérer :

• queued ou running : attendre et poller à nouveau.
• completed : traiter businesses.
• failed : arrêter et alerter quelqu'un ou logguer l'échec.

Utilisez les champs de statut réels des docs API comme source de vérité.

Étape 5 : Construire la boucle de polling

Make n'a pas de module unique "boucler jusqu'à condition", donc construisez la boucle à partir de pièces standard. Le schéma le plus maintenable utilise un Repeater avec un nombre borné d'itérations et un Router qui sort quand le job est fini.

La structure est :

1. Un Repeater réglé sur un nombre maximum de tentatives, par exemple 20.
2. Dans chaque itération : un module Sleep, puis le module HTTP Poll biz collect Job.
3. Un Router après le poll avec deux routes.
4. Route A, un filtre où status égale completed, continue vers le traitement et utilise un "Stop" ou un drapeau pour que les itérations suivantes court-circuitent.
5. Route B, un filtre où status égale failed, route vers un gestionnaire d'erreur.

Un moyen simple d'éviter les itérations gaspillées est de stocker le résultat dans un data store ou une variable de scénario à la fin et d'ajouter un filtre en haut du repeater qui saute le travail une fois le drapeau posé. Avec un Sleep de 15 secondes et 20 tentatives, la boucle attend environ cinq minutes avant d'abandonner, ce qui convient à la plupart des jobs d'extraction d'e-mails. Ajustez les deux chiffres à la taille de votre recherche :

• Tests de prospection rapides : 10 tentatives à 10 secondes.
• Jobs d'extraction d'e-mails : 20 tentatives à 15 secondes.
• Grandes recherches récurrentes : 30 tentatives à 20 secondes.

La bonne valeur est opérationnelle, pas théorique. Laissez aux jobs normaux le temps de finir tout en faisant remonter les retards inattendus.

Étape 6 : Diviser les entreprises avec un Iterator

Une fois status à completed, la réponse contient un tableau d'entreprises. La plupart des modules de destination fonctionnent un bundle à la fois, donc ajoutez un Iterator nommé Split Businesses et pointez-le sur le tableau businesses de la réponse de poll.

Après l'Iterator, chaque entreprise est son propre bundle avec des champs comme name, address, phone, website et emails. Pour obtenir un seul e-mail principal et un compte propre, ajoutez un module Set Variable ou utilisez des fonctions inline :

primary_email = {{ first(business.emails) }}
all_emails    = {{ join(business.emails; ", ") }}
email_count   = {{ length(business.emails) }}

Si le scénario est spécifiquement pour l'e-mail sortant, ajoutez un filtre après l'Iterator où primary_email n'est pas vide. Cela garde le CRM ou le tableur concentré sur les leads exploitables. Si votre équipe appelle aussi les prospects, gardez les fiches avec un numéro de téléphone même quand aucun e-mail n'est trouvé, car la couverture e-mail est toujours partielle.

Étape 7 : Envoyer les leads vers Google Sheets

Google Sheets est la destination la plus facile car la sortie est immédiatement visible. Ajoutez un module Google Sheets "Add a row" après l'Iterator.

Colonnes recommandées :

• Search Job ID
• Business Name
• Address
• Phone
• Website
• Primary Email
• All Emails
• Email Count
• Created At

Mappez les valeurs :

Search Job ID  -> {{ job_id }}
Business Name  -> {{ business.name }}
Address        -> {{ business.address }}
Phone          -> {{ business.phone }}
Website        -> {{ business.website }}
Primary Email  -> {{ primary_email }}
All Emails     -> {{ all_emails }}
Email Count    -> {{ email_count }}
Created At      -> {{ now }}

Pour une stratégie de déduplication légère, utilisez le domaine du site web ou l'e-mail principal comme clé unique. Comme le module "Add a row" ne fait qu'ajouter, ajoutez une vérification "Search rows" avant l'écriture, ou utilisez un data store indexé sur le domaine, si l'unicité stricte compte.

Étape 8 : Envoyer les leads qualifiés vers un CRM

Pour un CRM comme HubSpot ou Pipedrive, le flux courant est :

1. Rechercher une entreprise existante par domaine ou site web.
2. Si aucune correspondance n'existe, créer l'entreprise.
3. Si primary_email existe, rechercher un contact existant par e-mail.
4. Si aucun contact n'existe, créer le contact.
5. Associer le contact à l'entreprise si votre CRM l'exige.

Gardez la première version conservatrice. Ne créez pas de contacts en double juste parce qu'une entreprise a plusieurs e-mails. Commencez par primary_email, puis stockez optionnellement la liste complète dédupliquée dans une propriété personnalisée ou une note.

Un mapping d'entreprise utile :

name    -> {{ business.name }}
domain  -> {{ replace(replace(business.website; "https://"; ""); "www."; "") }}
phone   -> {{ business.phone }}
website -> {{ business.website }}

Si votre CRM a des règles de données strictes, ajoutez une validation avant les modules de création :

• Ne créer des contacts que lorsque primary_email n'est pas vide.
• Ne créer des entreprises que lorsque website ou phone est présent.
• Ajouter un champ de source tel que biz collect Make scenario.
• Ajouter la localisation de recherche et le jeu de mots-clés comme contexte de campagne.

Cela facilite le reporting sur quelles recherches locales ont produit des leads utiles.

Étape 9 : Ajouter des routes d'erreur et de notification

Un scénario de génération de leads tourne généralement sur planning, ce qui signifie que les échecs silencieux créent des pipelines périmés. Make gère les erreurs avec des gestionnaires d'erreurs attachés aux modules et avec des routes dédiées pour les états d'échec connus.

Ajoutez une gestion pour ces cas :

• Requête non autorisée : clé API manquante ou invalide. Arrêter et notifier le propriétaire du scénario.
• Requête invalide : location manquant, keywords vide ou radius_km invalide. Écrire l'entrée échouée dans une feuille d'erreurs.
• Limite de débit ou de plan : mettre le scénario en pause et envoyer une alerte avec un lien vers tarifs.
• Job échoué : notifier via Slack ou e-mail et inclure le job_id.
• Timeout du job : inclure le nombre de tentatives et le dernier statut connu.
• Aucune entreprise renvoyée : écrire un résultat réussi mais vide avec les paramètres de recherche.

Pour un résumé d'exécution compact, agrégez les entreprises avant l'Iterator et postez un seul message :

biz collect job {{ job_id }} completed.
Businesses found: {{ length(businesses) }}
With email: {{ length(filter(businesses; length(item.emails) > 0)) }}

Cela vous donne assez de visibilité pour surveiller les scénarios récurrents sans ouvrir Make à chaque exécution.

Disposition de scénario recommandée

Voici la séquence complète de modules pour une version pratique :

Trigger (Run once / Schedule / Webhook)
  -> HTTP: Start biz collect Search
  -> Repeater (max 20)
       -> Sleep (15s)
       -> HTTP: Poll biz collect Job
       -> Router
            completed -> Iterator: Split Businesses
                           -> Filter: primary_email is not empty
                           -> Google Sheets / CRM
            failed    -> Notify error
  -> (timeout fallthrough) -> Notify timeout

Ce schéma évite l'infrastructure sur mesure tout en gérant les réalités des API asynchrones : le travail peut être mis en file, les jobs peuvent tourner un moment, et les jobs échoués ou longs ont besoin d'un chemin adapté aux opérateurs. Si vous pesez Make contre d'autres outils, le workflow n8n de génération de leads montre la même boucle créer-attendre-poller en nodes visuels, et le guide des meilleurs outils de génération de leads locaux en 2026 place un workflow automatisation-plus-API parmi les scrapers, outils no-code et CRM.

Commencer à construire

Le scénario Make.com de génération de leads le plus simple mais utile ne compte que quelques modules : déclencheur, requête HTTP, sleep, poll, routeur, iterator et sortie. La valeur vient d'utiliser une API qui renvoie des données d'entreprises structurées et des e-mails de sites web vérifiés plutôt que de demander à Make de maintenir un scraper.

biz collect est construit pour exactement ce schéma : un POST pour lancer une recherche locale, un polling asynchrone jusqu'à la fin, des champs JSON stables, des docs OpenAPI 3.1 et des e-mails de contact dédupliqués extraits des sites web d'entreprises. Il s'adapte à Make, n8n, Zapier, aux scripts, aux outils LLM et à l'enrichissement CRM sans maintenance de navigateur headless.

Vous pouvez commencer gratuitement avec 200 crédits d'inscription et sans carte bancaire. Ouvrez les docs API, consultez les intégrations, vérifiez les tarifs et construisez aujourd'hui votre premier scénario de leads locaux automatisés dans Make.