Recopier les demandes reçues par le formulaire du site dans un tableur, puis dans le CRM : c’est l’une des tâches répétitives que nous rencontrons le plus souvent. Dans ce tutoriel, on relie Make, Google Sheets et un CRM pour que chaque demande soit enregistrée automatiquement, au même endroit, sans créer de doublon quand une même personne écrit deux fois. Le scénario est simple, mais ce sont ses détails qui le rendent fiable.

Ce que fait le scénario#

À chaque envoi du formulaire :

  1. Make reçoit la demande.
  2. Il nettoie l’adresse email, qui sert de clé de dédoublonnage.
  3. Il ajoute une ligne dans un Google Sheets, qui sert d’historique de toutes les demandes.
  4. Il cherche le contact dans le CRM.
  5. S’il existe, il le met à jour ; sinon, il le crée.

Pourquoi garder à la fois un tableur et un CRM ? Le tableur conserve une trace brute de chaque demande, même en double, ce qui est pratique pour vérifier ce qui est arrivé. Le CRM, lui, doit rester propre : une fiche par personne, qui devient la source unique pour le suivi commercial, y compris pour relancer les devis non signés. Si vous n’avez pas besoin de l’historique, l’étape Google Sheets est facultative.

Un mot sur la consommation : dans Make, chaque action d’un module consomme des crédits, la plupart un seul, d’après la page tarifs de Make (consultée le 15/10/2026). Ce scénario en consomme donc quelques-uns par demande. Nous comparons ce mode de facturation à celui des autres outils dans notre article sur n8n, Make et Power Automate.

Avant de commencer#

Préparez trois choses :

  • Le formulaire : il doit pouvoir envoyer ses données vers une URL (webhook), ou disposer d’un module Make dédié. Beaucoup d’outils de formulaire le proposent ; vérifiez dans le vôtre.
  • Le Google Sheets : une feuille avec une ligne d’en-têtes, par exemple Date, Nom, Email, Entreprise, Message.
  • Le CRM : vérifiez dans la liste des applications de Make qu’il propose au minimum un module de recherche de contact, un module de création et un module de mise à jour. Sans module de recherche, le dédoublonnage devient beaucoup plus compliqué.

Le scénario Make, Google Sheets et CRM pas à pas#

Étape 1 : recevoir la demande#

Si votre outil de formulaire a un déclencheur instantané dans Make, utilisez-le. Sinon, utilisez le module Custom webhook de l’application Webhooks : Make génère une URL à coller dans les réglages de votre formulaire. La documentation de Make sur les webhooks (consultée le 15/10/2026) décrit les deux options.

Envoyez ensuite une demande de test depuis le formulaire. Make récupère sa structure, et les champs deviennent disponibles dans les modules suivants.

Étape 2 : nettoyer l’adresse email#

C’est l’étape qui fait la différence entre un dédoublonnage qui marche et un dédoublonnage qui laisse passer des doublons. « Camille@Exemple.fr » et « camille@exemple.fr » désignent la même personne, mais ne sont pas la même chaîne de caractères.

Ajoutez un module Set variable (dans les outils de Make) et créez une variable email_normalise avec la formule lower(trim(email)), en insérant le champ email du formulaire à la place de « email ». D’après la documentation des fonctions de texte de Make (consultée le 15/10/2026), trim retire les espaces au début et à la fin du texte, et lower passe toutes les lettres en minuscules.

Ajoutez ensuite un filtre juste après ce module : si l’email est vide ou ne contient pas d’arobase, le traitement s’arrête là. Inutile de consommer des crédits sur une demande inexploitable.

Étape 3 : enregistrer la demande dans Google Sheets#

Ajoutez le module Google Sheets qui ajoute une ligne. Connectez votre compte Google, choisissez le fichier et la feuille, puis associez chaque colonne au champ correspondant. Pour la colonne Email, utilisez la variable normalisée.

Testez avec « Run once » et vérifiez que la ligne apparaît.

Étape 4 : chercher le contact dans le CRM#

Ajoutez le module de recherche de contact de votre CRM, avec la variable email_normalise comme critère. Deux réglages à vérifier :

  • Le champ de recherche : cherchez bien sur l’email, pas sur le nom. Deux personnes peuvent avoir le même nom ; une adresse email est en principe unique.
  • Le nombre maximum de résultats : limitez-le à 1. Si la recherche renvoie plusieurs contacts, c’est que votre CRM contient déjà des doublons, à traiter à part.

Étape 5 : créer ou mettre à jour, avec un routeur#

Ajoutez un routeur après la recherche, avec deux branches et un filtre sur chacune, comme le décrit la documentation de Make sur le routeur (consultée le 15/10/2026) :

  • Branche « contact trouvé » : condition « l’identifiant du contact renvoyé par la recherche existe ». Elle mène au module de mise à jour, qui complète la fiche avec les nouvelles informations, par exemple l’entreprise ou une note avec le message.
  • Branche « nouveau contact » : condition « l’identifiant du contact n’existe pas ». Elle mène au module de création.

Soignez ces deux conditions : elles doivent être exactement opposées, pour que chaque demande passe par une branche et une seule. La même documentation précise que les branches d’un routeur sont traitées l’une après l’autre, dans l’ordre défini, et qu’on peut marquer une branche comme route de secours pour ce qui ne correspond à aucune autre.

Étape 6 : prévoir les erreurs#

Le CRM peut refuser une création, par exemple si un champ obligatoire manque. Dans les paramètres du scénario (consultés le 15/10/2026), activez Store incomplete executions : en cas d’échec, Make conserve l’exécution pour que vous puissiez corriger le problème et la reprendre, au lieu de perdre la demande. Ajoutez aussi, sur les modules du CRM, une route d’erreur qui vous envoie une alerte. N’ignorez pas l’erreur en silence : une demande client perdue sans que personne le sache, c’est précisément ce que l’on veut éviter.

Les pièges à éviter#

  • Dédoublonner sur un email brut. Sans normalisation, les majuscules et les espaces créent des doublons.
  • Mettre à jour en écrasant tout. Dans la branche de mise à jour, ne remplissez que les champs utiles. Écraser un numéro de téléphone saisi par un commercial avec un champ vide du formulaire est une erreur fréquente.
  • Oublier les demandes envoyées deux fois rapidement. Par défaut, Make traite les webhooks en parallèle : si une personne valide le formulaire deux fois en quelques secondes, deux exécutions peuvent tourner en même temps et créer chacune le contact. L’option Process data in order des paramètres du scénario fait attendre la fin d’une exécution avant de lancer la suivante, y compris pour les webhooks. Contrepartie indiquée par Make : tant qu’une exécution incomplète n’est pas résolue, les suivantes restent en attente. L’alerte d’erreur devient alors indispensable.
  • Tester avec de vraies fiches clients. Utilisez des adresses de test, puis supprimez les contacts de test du CRM avant la mise en service.
  • Traiter des données personnelles sans le dire. Le formulaire collecte des données personnelles : votre politique de confidentialité doit mentionner où elles sont envoyées. Les règles d’information sont détaillées dans notre tutoriel pour brancher un formulaire de site à son CRM.

Conclusion#

Relier un formulaire, Google Sheets et un CRM avec Make demande peu de modules, et supprime une ressaisie que beaucoup d’équipes font encore à la main. Ce qui rend le scénario fiable, ce sont les détails : un email normalisé, une recherche avant création, des branches bien définies et des erreurs qui préviennent quelqu’un. Le même principe s’applique aux autres sources de données de votre CRM, comme nous l’expliquons dans notre article pour garder un CRM à jour sans ressaisie.

Ce type de flux fait souvent partie des premières automatisations que nous recommandons, parce qu’il touche une tâche fréquente avec des règles claires. Pour savoir lesquelles prioriser chez vous, notre méthode pour lister et prioriser les tâches répétitives est un bon point de départ. Et si vous préférez qu’on le mette en place ensemble, c’est le cœur de notre accompagnement en automatisation.