Make pour alimenter son CRM depuis les emails (2026)

Un prospect t'écrit un email de trois lignes avec son nom, son entreprise et une question sur ton offre. Tu le lis, tu réponds, puis — si tu y penses — tu ouvres ton CRM, tu crées la fiche, tu recopies l'adresse, tu devines l'entreprise depuis le domaine, tu ajoutes une note. Quatre minutes, peut-être cinq. Multiplié par vingt emails de ce genre par semaine, c'est une heure et demie de copier-coller pur, chaque semaine, pour un geste qu'un logiciel fait en une seconde et demie.

Le problème n'est pas que tu ne saches pas utiliser ton CRM. C'est que rien, dans le geste de lire un email, ne devrait exiger que tu bascules ensuite dans un autre outil pour retaper ce que tu viens déjà de lire. Le contact existe dans l'email. Le CRM devrait juste... le savoir.

C'est exactement le type de tâche que Make est censé absorber : surveiller une boîte mail, repérer ce qui ressemble à un lead, extraire les bonnes informations, vérifier si le contact existe déjà, et créer ou mettre à jour la fiche — sans que tu touches à rien. Sur le papier, c'est trivial. En pratique, la moitié des tutoriels qui promettent ce pipeline passent sous silence trois pièges qui le cassent en production : le module Watch Emails qui ne lit que du texte brut là où la plupart des emails pro arrivent en HTML, le risque de doublons quand deux emails du même contact arrivent à deux jours d'écart, et un système de crédits qui facture chaque étape du scénario — pas seulement le résultat final.

Ce dont tu as besoin, ce n'est pas d'un énième "connecte Gmail à ton CRM en 5 minutes". C'est de savoir où ce pipeline tient vraiment la route, où il te fera perdre plus de temps qu'il n'en économise, et combien ça coûte réellement selon ton volume d'emails.

Make comme chef d'orchestre du pipeline

Make ne lit pas un email comme un humain. Il ne "comprend" rien par défaut — il surveille une boîte mail, déclenche un scénario à chaque nouveau message, et laisse d'autres modules (parseur de texte, IA, ou règles) faire le travail d'extraction. Son rôle est celui d'un chef d'orchestre : il sait quand agir, dans quel ordre, et où envoyer le résultat. C'est précisément le rôle qui manque entre ta boîte mail et ton CRM — les deux existent déjà, ils ne se parlent simplement pas tout seuls.

Le pipeline complet : de l'email brut à la fiche CRM

Le scénario qui fonctionne en production tient en cinq étapes, pas trois. Les tutoriels qui s'arrêtent à "Watch Email → Create Record" fabriquent un pipeline qui casse dès le premier email HTML ou le premier contact qui écrit deux fois.

Étape 1 — Watch Emails : le déclencheur, avec son vrai piège

Le module Watch Emails de Make se connecte à un dossier précis (souvent une boîte partagée type contact@ ou un label Gmail dédié) et déclenche le scénario à chaque nouveau message. Le piège documenté sur le forum Make Community : par défaut, ce module ne capture que le contenu texte brut de l'email — pas le HTML. Or la majorité des emails professionnels, notamment ceux envoyés depuis un client comme Outlook ou une signature d'entreprise avec logo et liens, arrivent en HTML. Le texte brut récupéré peut alors être tronqué, dépourvu de la signature complète, ou contenir des artefacts de mise en page qui cassent un parsing par expression régulière trop rigide.

Un fil du forum Make Community intitulé "Capturing HTML Content from Watch Emails Gmail Module" documente exactement ce problème : le module ne récupère que la version texte, ce qui oblige à ajouter un module de conversion HTML → texte en amont du parsing pour retrouver l'intégralité du contenu, signature comprise.

Étape 2 — Text Parser : structurer avant d'extraire

Une fois le contenu HTML converti proprement, un module Text Parser (regex) ou un module dédié comme celui de l'intégration mailparser.io permet de découper le message en blocs exploitables : objet, corps, signature. C'est cette étape qui transforme un bloc de texte en champs distincts — nom, poste, entreprise — avant de les envoyer à l'étape suivante.

Étape 3 — Module IA : l'extraction sémantique que la regex ne fait pas

Une expression régulière sait repérer un format prévisible (un email, un numéro de téléphone). Elle ne sait pas deviner qu'"Sophie, resp. achats chez Lumeo" signifie "Sophie [Nom de famille manquant], Responsable achats, Lumeo". C'est là qu'un module OpenAI ou Anthropic branché directement dans le scénario Make change la donne : il lit le texte extrait et retourne un JSON structuré (nom, entreprise, intention du message, urgence perçue) que le module suivant peut directement mapper aux champs du CRM.

Étape 4 — Search Records : la vérification de doublon qu'on oublie toujours

Un contact qui écrit une deuxième fois, deux semaines après sa première prise de contact, ne doit pas générer une deuxième fiche. Le module "Search Records" (disponible dans quasiment tous les connecteurs CRM de Make — HubSpot, Pipedrive, Airtable) interroge le CRM avec l'adresse email extraite avant toute création. S'il trouve une correspondance, le scénario bascule sur "Update a Record" plutôt que "Create a Record" — ajoutant une note d'activité plutôt qu'un doublon.

Étape 5 — Create/Update Record : écrire dans les bons champs

La dernière étape mappe chaque donnée extraite (nom, entreprise, source = "email entrant", date de premier contact) vers le champ correspondant du CRM — jamais dans un unique champ "notes" en texte libre, qui rend la donnée inexploitable pour filtrer ou scorer plus tard.

Construire ton premier scénario en 40 minutes

Pas besoin de développeur. Le scénario minimal viable (sans le module IA, ajoutable ensuite) se construit en suivant cet ordre dans l'interface Make :

1. Créer un scénario vide et choisir Gmail (ou Outlook) comme premier module, déclencheur "Watch Emails" sur le dossier ou label dédié aux demandes entrantes.
2. Ajouter un module "HTML to Text" juste après, pour éviter le piège du texte brut tronqué.
3. Ajouter un module Text Parser (Match Pattern) avec une expression régulière simple pour l'email et le téléphone — les deux formats les plus fiables à extraire par regex.
4. Brancher un module OpenAI ou Anthropic ("Create a Completion" / "Create a Message") avec un prompt qui demande un JSON structuré : nom, entreprise, intention, urgence.
5. Ajouter le module "Search Records" du CRM cible, filtré sur l'adresse email extraite.
6. Ajouter un routeur (Router) avec deux branches : "contact trouvé" → Update a Record, "aucun résultat" → Create a Record.
7. Lancer un test manuel ("Run once") avec un email réel déjà reçu, pour vérifier que chaque champ atterrit au bon endroit avant d'activer le scénario en continu.

Cas concret : d'une demande de devis à la fiche CRM en moins de deux minutes

Un exemple vaut mieux qu'une description abstraite. Voici ce qui se passe réellement, module par module, quand un email comme celui-ci arrive dans la boîte contact@ :

Objet : Devis site vitrine
Bonjour, je m'appelle Karim Belhaj, je suis responsable digital chez Atelier Nova (agence d'architecture d'intérieur). On cherche à refaire notre site vitrine d'ici fin octobre, budget entre 3 et 5k. Vous auriez 20 min cette semaine pour en discuter ? Merci, Karim — 06 XX XX XX XX

Le scénario Make se déclenche dans les secondes qui suivent la réception. Le module Watch Emails capture le message, le module HTML to Text nettoie la mise en forme du client mail, le Text Parser isole immédiatement le numéro de téléphone au format français par une expression régulière simple. Le module IA reçoit le texte nettoyé avec un prompt du type "Extrait au format JSON : prenom, nom, entreprise, poste, budget_estime, deadline, intention_resume, urgence (haute/moyenne/basse)" et retourne une structure exploitable : Karim Belhaj, Atelier Nova, responsable digital, budget 3000-5000€, deadline fin octobre, intention "refonte site vitrine", urgence haute (deadline explicite sous 6 semaines).

Le module Search Records interroge ensuite le CRM sur l'adresse email de Karim. Aucun résultat : c'est un nouveau contact. Le routeur bascule sur "Create a Record", remplit les champs Entreprise, Poste, Budget estimé et Source ("email entrant — contact@"), puis — parce que l'urgence a été évaluée "haute" — déclenche une notification Slack dans le canal #leads-chauds avec un résumé en une ligne. Le temps total entre la réception de l'email et l'alerte Slack : moins de 90 secondes, sans qu'aucun humain n'ait ouvert le CRM.

C'est cette combinaison — extraction fine + décision de routage + alerte ciblée — qui distingue un pipeline utile d'un simple copier-coller automatisé. Un CRM qui se remplit tout seul mais qui n'alerte jamais sur ce qui compte vraiment ne fait gagner que du temps de saisie ; celui-ci fait aussi gagner du temps de réaction, ce qui pèse davantage sur le taux de conversion d'un lead entrant, surtout quand la deadline est déjà posée dans le message.

Traiter des emails avec de l'IA : ce que ça implique côté RGPD

Passer chaque email entrant dans un module OpenAI ou Anthropic pour en extraire des données personnelles (nom, coordonnées, contenu de la demande) n'est pas neutre au regard du RGPD, et c'est un point que la plupart des tutoriels passent complètement sous silence.

Trois précautions concrètes s'imposent avant de mettre ce pipeline en production sur des emails de prospects ou de clients européens :

• Vérifier les conditions de traitement des données du fournisseur IA connecté — OpenAI et Anthropic proposent tous deux des clauses de traitement de données (DPA) compatibles RGPD pour les comptes professionnels, mais ce n'est pas automatique sur un compte personnel gratuit relié directement dans Make.
• Limiter la durée de rétention des logs d'exécution Make — chaque exécution de scénario conserve par défaut un historique des données traitées (donc le contenu de l'email) pendant une durée définie par le plan ; sur un pipeline qui traite des données personnelles, il vaut mieux réduire cette rétention au strict nécessaire dans les paramètres du scénario.
• Documenter le traitement dans son registre RGPD — dès lors qu'un module IA externe traite le contenu d'emails contenant des données personnelles de façon systématique, ce traitement doit apparaître dans le registre des activités de traitement de l'entreprise, avec la base légale retenue (généralement l'intérêt légitime pour une demande entrante spontanée).

Rien de bloquant dans l'absolu — des milliers d'entreprises françaises exploitent déjà ce type de pipeline — mais le construire sans y penser revient à créer, sans le vouloir, un traitement de données personnelles non documenté. Un détail qui ne coûte rien à corriger en amont et qui coûte beaucoup à corriger après un contrôle.

Ce que ce pipeline ne fait pas bien

Avant de construire quoi que ce soit, il faut savoir où ce montage montre ses limites — pas après avoir découvert un CRM à moitié rempli de doublons.

"Le système de crédits n'est plus prévisible sans faire tourner le scénario au moins une fois : un module HTTP ou webhook peut coûter 1 à 3 crédits par appel selon la complexité, contre 1 crédit pour une action standard" — résumé d'une analyse technique publiée par un consultant Make indépendant sur le changement de facturation du 27 août 2025 (opérations → crédits), accès direct au fil d'origine bloqué par le proxy réseau de cet environnement, donnée croisée via recherche multi-sources.

Make vs Parseur vs CRM IA natifs (HubSpot, Pipedrive, Folk)

Make n'est pas la seule route vers un CRM qui se remplit tout seul. Trois familles d'alternatives existent, chacune avec un compromis différent entre contrôle, prix et simplicité.

Parseur, spécialisé dans l'extraction de données depuis emails et documents, propose un plan gratuit permanent (20 pages/mois) puis des paliers payants à partir de 39$/mois pour 100 pages, jusqu'à 399$/mois pour 10 000 pages — avec un coût dégressif jusqu'à 3 centimes par page sur les plans à fort volume. Il se connecte nativement à Salesforce, Airtable, Notion, Zapier, Make et n8n, ce qui en fait un complément possible plutôt qu'un concurrent direct : certaines équipes utilisent Parseur pour le parsing pur et Make pour orchestrer la suite (recherche de doublon, notification, mise à jour d'autres outils).

Côté CRM eux-mêmes, l'IA native progresse vite. Folk, le CRM léger plébiscité par les petites équipes, affiche une note de 4,5/5 sur plus de 300 avis G2 et propose une fonctionnalité "AI Follow-Up" qui analyse l'historique d'échange et signale les contacts sans réponse — mais son absence d'application mobile reste la critique la plus fréquente sur G2, Capterra et les retours utilisateurs recensés en 2026, et Folk ne propose aucune automatisation de workflow au-delà du déclenchement d'emails, la gestion des deals restant derrière un mur payant. HubSpot mise sur son assistant Breeze AI, qui gère recherche d'entreprise, préparation d'appel et résumé de fiche automatiquement une fois le plan payant activé — mais son plan gratuit est désormais plafonné à 1 000 contacts et 2 utilisateurs, ce qui pousse vite vers un palier payant pour une équipe qui grandit. Pipedrive, de son côté, a revu ses prix à la hausse en 2026 : le plan Growth (avec synchronisation email complète et séquences) est passé à 39$/utilisateur/mois, le plan Premium à 59$/utilisateur/mois, avec un plan Lite d'entrée à 14$/siège/mois qui n'inclut pas l'assistant IA.

"L'absence d'application mobile est la critique la plus récurrente sur G2, Capterra et les retours utilisateurs — en 2026, un CRM sans accès mobile ressemble à une lacune sérieuse." — synthèse des avis vérifiés Folk CRM (G2/Capterra), consultée via recherche multi-sources, accès direct à g2.com bloqué par le proxy réseau de cet environnement.

Ce que ça coûte vraiment selon ton volume d'emails

Le calcul dépend presque entièrement de deux choses : combien d'emails déclenchent le scénario chaque mois, et si tu utilises un module IA pour l'extraction sémantique (qui consomme plus de crédits qu'un simple parsing par regex).

Ces estimations partent d'une base de 5 modules par exécution (Watch Emails, HTML to Text, Text Parser, Search Records, Create/Update Record) à environ 1 crédit chacun pour les modules standards, et d'un coût variable pour le module IA selon la longueur du prompt et de la réponse — c'est précisément cette variabilité qui rend le système de crédits difficile à prévoir sans test réel, comme documenté plus haut. Le calcul reste tout de même très favorable face à une alternative comme Birdeye ou Podium sur le terrain voisin de la gestion de la relation client automatisée, dont les tarifs démarrent à plusieurs centaines de dollars par mois pour des fonctionnalités bien plus larges que ce pipeline ciblé.

Un coût caché mérite d'être isolé du reste : le module IA consomme à la fois des crédits Make et des tokens facturés séparément par OpenAI ou Anthropic si tu connectes ta propre clé API plutôt que d'utiliser le module IA géré nativement par Make (qui inclut le coût dans les crédits). Sur les modèles économiques actuels, l'extraction d'un email court (moins de 300 mots) via une clé API personnelle coûte typiquement une fraction de centime — négligeable à l'échelle de 300 emails/mois, mais qui mérite d'être vérifié sur ta facture API du mois suivant la mise en production, plutôt que découvert par surprise trois mois plus tard.

Le vrai comparatif de coût total n'est donc pas "Make coûte 10,59€/mois" mais "Make coûte 10,59€/mois + quelques centimes d'API IA + le temps de configuration initiale, contre 250 à 400 dollars/mois pour un outil de réputation tout-en-un qui fait bien plus que ce pipeline ciblé, ou zéro euro supplémentaire si tu restes sur l'IA native déjà incluse dans ton abonnement CRM existant". C'est cette dernière option — l'IA native du CRM — qui mérite d'être vérifiée en premier avant de construire quoi que ce soit : si HubSpot Breeze ou l'assistant Pipedrive couvrent déjà 80 % du besoin, le pipeline Make devient un complément ciblé plutôt qu'une réécriture complète du système.

Mesurer si ça marche : 3 indicateurs à suivre après la mise en prod

Un pipeline qu'on active et qu'on oublie est un pipeline qui dérive silencieusement. Trois chiffres suffisent à savoir, un mois après la mise en production, si le scénario tient vraiment ses promesses.

• Taux d'échec du scénario — visible directement dans l'historique d'exécution Make (onglet "History" du scénario). Un taux supérieur à 5 % signale généralement un format d'email inattendu (pièce jointe volumineuse, langue non gérée par le prompt IA, adresse d'expédition automatique type "no-reply") qui mérite une branche de gestion d'erreur dédiée plutôt qu'un échec silencieux.
• Taux de doublons créés malgré le module Search Records — à vérifier manuellement dans le CRM sur un échantillon d'une vingtaine de contacts après les deux premières semaines. Un taux non nul indique presque toujours une variante d'adresse email (ex : karim@atelier-nova.fr vs karim.belhaj@atelier-nova.fr) que la recherche exacte ne capture pas — un signal pour ajouter une recherche secondaire sur le nom + l'entreprise plutôt que sur l'email seul.
• Délai réel entre réception et alerte sur les leads urgents — le scénario promet une alerte en moins de deux minutes ; si Make accumule un délai d'exécution plus long en heures de pointe (cas rare mais déjà signalé sur le forum Make Community lors de pics de charge sur l'infrastructure), c'est le signe qu'il faut revoir la planification du scénario (déclenchement instantané vs intervalle programmé) plutôt que de laisser un lead "haute urgence" attendre quinze minutes dans la file.

Ces trois indicateurs prennent cinq minutes à vérifier une fois par mois — largement moins de temps que ce que prenait la saisie manuelle qu'ils remplacent, et suffisamment pour repérer une dérive avant qu'elle ne coûte un lead qualifié perdu dans un email mal parsé.

Verdict : qui devrait automatiser son CRM avec Make ?

Ce pipeline n'est pas pour tout le monde. Une équipe qui reçoit trois emails de prospects par semaine n'a pas besoin d'un scénario Make — cinq minutes de saisie manuelle suffisent. Il devient rentable à partir du moment où la saisie manuelle commence à mordre sur un temps que tu pourrais vendre ailleurs, typiquement au-delà d'une vingtaine d'emails entrants qualifiés par semaine.

La question qui tranche vraiment : est-ce que tu contrôles déjà où vont tes leads, ou est-ce que la moitié atterrit dans une boîte mail que personne ne relit avant trois jours ? Si c'est la deuxième option, le pipeline Make ne résout pas seulement un problème de saisie — il résout un problème de perte de leads pure et simple, et ça, ça vaut largement les 40 minutes de configuration.

Articles liés

• Relance commerciale : automatiser avec l'IA, Make et Claude (prix) — le pendant sortant de ce pipeline, pour relancer automatiquement après le premier contact.
• Clay vs Sales Navigator : quelle prospection LinkedIn (2026) ? — un autre pipeline Make orienté acquisition plutôt que capture entrante.
• Automatiser ses visuels réseaux sociaux avec Make (2026) — un autre cas d'usage Make no-code, hors CRM.
• HubSpot, Zoho ou ActiveCampaign : quel CRM IA (2026) ? — pour choisir le CRM de destination avant de construire ce pipeline.
• Make pour générer ses fiches produits Shopify (2026) — la même architecture Make (donnée entrante → IA → écriture automatique) appliquée au catalogue produit plutôt qu'au CRM.
• Notion AI : suivi et relance de devis (2026) — la suite logique une fois le contact entré en CRM : suivre le devis envoyé et relancer sans oubli.
• Make pour automatiser un programme de coaching (2026) — la même logique de détection d'événements et d'écriture dans une base, appliquée cette fois au suivi d'une cohorte plutôt qu'à la capture de leads.
• Analyser le sentiment de ses avis clients avec Make (2026) — la même architecture de classification IA, appliquée aux avis clients plutôt qu'aux emails entrants.
• Automatiser son reporting client avec Make (2026) — la même logique de collecte automatisée par Make, appliquée aux métriques de performance plutôt qu'aux contacts commerciaux.
• Automatiser sa comptabilité freelance avec Make (2026) — la même logique de capture par email, appliquée aux reçus comptables plutôt qu'aux contacts commerciaux.