Votre première automatisation Make, pas à pas

C’est le tutoriel le plus important du module : celui où vous construisez votre toute première automatisation Make, de zéro jusqu’à l’activation. À la fin, un scénario tournera tout seul sur votre compte — et vous aurez ressenti ce déclic qui rend l’automatisation addictive.

Le projet : chaque e-mail important reçu dans Gmail crée automatiquement une ligne dans un Google Sheet (expéditeur, objet, date). Simple, concret, et le schéma déclencheur → action que vous réutiliserez partout. Durée : 30 minutes. Prérequis : un compte Make (voir le tutoriel précédent) et un compte Google.

Transparence : certains liens de cet article sont des liens partenaires. Si vous créez un compte via l’un d’eux, Flowmatic-Pro perçoit une commission, sans que cela change quoi que ce soit à votre prix. Nous ne recommandons que des outils que nous utilisons nous-mêmes.

Étape 0 — Préparer le terrain (2 minutes)

Créez un Google Sheet nommé « Suivi e-mails » avec trois colonnes en ligne 1 : Expéditeur, Objet, Date. Les en-têtes de colonnes sont importants : Make les utilisera pour le mapping.

Étape 1 — Le déclencheur : Gmail « Watch Emails »

• Dans un nouveau scénario, cliquez sur le grand + et cherchez Gmail.
• Choisissez le module « Watch Emails » (surveiller les e-mails) — c’est un déclencheur : il vérifie régulièrement l’arrivée de nouveaux messages.
• Cliquez sur « Add » pour créer la connexion à votre compte Google : une fenêtre s’ouvre, connectez-vous et acceptez les autorisations. (Ce mécanisme sécurisé, OAuth, est expliqué dans l’article suivant.)
• Configurez : dossier INBOX, critère « Only unread emails », nombre maximal de résultats : 2 (pour les tests).

Étape 2 — L’action : Google Sheets « Add a Row »

• Cliquez sur la demi-lune à droite du module Gmail pour ajouter le module suivant ; cherchez Google Sheets → « Add a Row ».
• Connexion : réutilisez celle de Google créée à l’étape 1.
• Sélectionnez votre feuille « Suivi e-mails », puis l’onglet.
• Le moment magique — le mapping : pour chaque colonne, cliquez dans le champ et choisissez la donnée Gmail correspondante dans le panneau qui s’ouvre : Sender e-mail address → colonne Expéditeur, Subject → Objet, Date → Date.

Étape 3 — Le test : « Run once »

Envoyez-vous un e-mail de test (objet : « Test Make 1 »), attendez qu’il arrive, puis cliquez sur « Run once » en bas à gauche. Observez : des bulles numérotées apparaissent au-dessus de chaque module — 1 e-mail lu, 1 ligne écrite. Ouvrez votre Google Sheet : la ligne est là. 🎉

Si un module affiche une erreur, cliquez sur la bulle : Make montre les données reçues et la cause exacte (le plus souvent : un champ mal mappé ou la mauvaise feuille sélectionnée). Corrigez, relancez.

Étape 4 — Planifier et activer

• Cliquez sur l’horloge du module Gmail : réglez l’intervalle de vérification à 15 minutes (le minimum du plan gratuit — largement assez).
• Renommez le scénario : « Gmail → Suivi e-mails ».
• Sauvegardez, puis basculez l’interrupteur ON en bas à gauche.

Votre automatisation est en production. Elle vérifiera vos e-mails toutes les 15 minutes, pour environ 96 opérations par jour au pire cas — le calcul exact vous attend dans le guide des opérations.

Ce que fait vraiment votre scénario, module par module

Vous venez de construire quelque chose qui fonctionne. Avant d’aller plus loin, prenez deux minutes pour comprendre ce qui se passe réellement quand il tourne : c’est la différence entre recopier un tutoriel et savoir construire vos propres automatisations demain.

Quand votre scénario se réveille, Make exécute toujours la même séquence. Le premier module — le déclencheur — interroge Gmail et demande : « y a-t-il de nouveaux e-mails depuis la dernière fois ? ». Gmail répond avec une liste. Chaque e-mail de cette liste devient ce que Make appelle un paquet (un « bundle »). Le scénario traite ensuite les paquets un par un, de gauche à droite, du premier module au dernier.

C’est le point le plus mal compris par les débutants, et il explique la moitié des surprises de facturation. Si Gmail renvoie 12 e-mails, votre module Google Sheets ne s’exécute pas une fois : il s’exécute douze fois, une par paquet. Le scénario ne coûte pas 2 opérations, il en coûte 13 (1 pour le déclencheur, 12 pour l’action).

Les trois questions à se poser devant n’importe quel scénario

Qu’est-ce qui le réveille ? Une planification (toutes les 15 minutes, tous les jours à 8 h) ou un webhook (un service vous prévient lui-même, instantanément). C’est le premier module qui le décide, et lui seul.

Combien de paquets sort le premier module ? C’est ce nombre qui multiplie tout le reste. Le réglage « Maximum number of results » du module Gmail est donc bien plus qu’un détail de test : c’est votre garde-fou de consommation.

Que se passe-t-il si un paquet échoue ? Par défaut, l’exécution s’arrête net. Les paquets déjà traités restent traités, les suivants ne le seront jamais. Nous verrons plus bas comment changer ce comportement.

Le vocabulaire à retenir de cette première construction

Un scénario est l’automatisation complète. Un module est une brique dans ce scénario. Une connexion est l’autorisation enregistrée vers un compte (votre Gmail, votre Google Drive) — elle est réutilisable dans tous vos scénarios. Une opération est le compteur : un module qui s’exécute une fois consomme une opération. Une exécution est un réveil complet du scénario, du premier au dernier module.

Étape 5 — Lire l’historique d’exécution (le réflexe qui change tout)

Le tutoriel s’arrête souvent à « ça marche ». Le vrai travail commence là. Ouvrez votre scénario, puis l’onglet History dans le panneau de droite. Vous y trouvez la liste de tous les réveils passés, avec pour chacun l’heure, la durée, le nombre d’opérations consommées et un verdict : succès, avertissement ou erreur.

Cliquez sur n’importe quelle ligne. Make rejoue visuellement l’exécution : chaque module affiche une bulle avec le nombre de paquets qui l’ont traversé. Cliquez sur une bulle et vous voyez les données exactes qui sont entrées et sorties de ce module, champ par champ.

C’est l’outil de diagnostic le plus puissant de Make, et le moins utilisé. Trois lectures à en faire systématiquement.

Lecture 1 — le nombre de paquets

Si votre déclencheur affiche « 0 » alors que vous attendiez des données, le problème n’est pas dans votre scénario : il est dans les critères de recherche du déclencheur. Si à l’inverse il affiche un nombre énorme, vous venez de découvrir pourquoi votre quota fond.

Lecture 2 — le contenu réel des champs

Un champ vide dans votre tableur vient presque toujours d’un champ vide en amont, pas d’un problème de destination. L’historique vous le montre en une seconde : si le module Gmail sort un champ « Text content » vide parce que l’e-mail était en HTML pur, aucun réglage côté Google Sheets n’y changera rien.

Lecture 3 — la durée

Une exécution qui dure plusieurs minutes signale un module lent (une grosse requête, une API qui répond mal) ou un volume de paquets trop élevé. Make applique une limite de durée par exécution : un scénario qui la dépasse est interrompu, et vous perdez les paquets non traités.

Notre conseil : après chaque modification d’un scénario en production, laissez-le tourner deux ou trois fois puis ouvrez l’historique. Deux minutes d’inspection valent mieux qu’une semaine de données silencieusement fausses.

Le mapping : là où tout se joue vraiment

Quand vous avez glissé « Subject » depuis le panneau de gauche vers la colonne B de votre tableur, vous avez fait du mapping : relier une donnée qui sort d’un module à un champ qui entre dans le suivant. C’est 80 % du travail dans Make, et c’est là que se nichent la plupart des blocages.

Pourquoi une donnée n’apparaît parfois pas dans la liste

Make ne peut proposer que les champs qu’il a déjà vus. Si vous n’avez jamais exécuté le module Gmail, la liste des données disponibles sera vide ou générique. La solution est toujours la même : exécutez une fois le module en amont (clic droit sur le module, « Run this module only »), et la liste se remplit avec de vraies valeurs.

Combiner plusieurs champs dans un seul

Rien ne vous oblige à mettre un champ par colonne. Dans une case de destination, vous pouvez écrire du texte libre et y glisser plusieurs données : Reçu de {{1.from}} le {{1.date}} produira une phrase complète. Les doubles accolades sont la marque d’une donnée dynamique ; le chiffre avant le point est le numéro du module d’où elle vient.

Les fonctions : nettoyer la donnée au passage

À côté de la liste des champs, un onglet donne accès aux fonctions. Les quatre qui servent tout le temps :

Une donnée mal formatée en entrée reste mal formatée en sortie : personne ne la nettoiera à votre place. Prenez l’habitude de la corriger au moment du mapping plutôt que dans votre tableur, une semaine plus tard, à la main.

Ajouter un filtre : ne traiter que ce qui vous intéresse

Votre scénario enregistre pour l’instant tous les e-mails. Dans la vraie vie, vous n’en voulez qu’une partie : les demandes de devis, les commandes, les messages d’un expéditeur précis. Le filtre est la réponse, et c’est aussi le plus grand levier d’économie de Make.

Poser un filtre

Passez la souris sur le trait qui relie deux modules : une petite clé à molette apparaît. Cliquez dessus, puis « Set up a filter ». Donnez-lui un nom explicite (« Uniquement les devis »), choisissez le champ à examiner, l’opérateur, et la valeur attendue.

Un paquet qui ne satisfait pas la condition s’arrête là. Les modules suivants ne s’exécutent pas pour lui — et ne consomment donc rien.

Les opérateurs à connaître

Contains cherche un morceau de texte n’importe où : idéal pour « le sujet contient devis ». Equal to exige une correspondance exacte, sensible aux majuscules et aux espaces ; c’est souvent lui le coupable quand un filtre bloque tout. Exists vérifie simplement qu’un champ n’est pas vide, ce qui évite d’écrire des lignes fantômes dans votre tableur.

Placez le filtre le plus tôt possible

Un filtre en deuxième position économise tous les modules suivants. Le même filtre en cinquième position ne fait plus rien pour votre facture : les quatre premiers modules se sont déjà exécutés. C’est la règle la plus rentable de tout Make, et elle ne coûte rien à appliquer.

Attention toutefois : filtrer côté Make signifie que le déclencheur a quand même récupéré les données. Quand le service source sait filtrer lui-même — la requête de recherche du module Gmail, par exemple — c’est encore mieux : les paquets inutiles ne sont jamais créés.

Ajouter une troisième étape : la notification

Un scénario à deux modules est un exercice. Un scénario à trois modules commence à ressembler à un outil de travail. Ajoutons une notification : dès qu’une ligne est écrite, vous recevez un message.

Cliquez sur le petit « + » à droite du module Google Sheets, cherchez « Email » (le module intégré de Make, qui n’exige aucune connexion supplémentaire) et choisissez « Send an email ». Dans le corps du message, glissez les données que vous voulez voir : l’expéditeur, le sujet, et un lien vers votre tableur.

La règle de la notification utile

Une notification qui arrive quarante fois par jour finit dans un dossier ignoré, et vous perdez le bénéfice. Deux garde-fous : placez la notification après un filtre resserré (seulement les demandes urgentes, seulement les montants supérieurs à un seuil), ou remplacez la notification unitaire par un résumé quotidien.

Le résumé quotidien, en deux modules

Le principe : un second scénario, planifié une fois par jour à 18 h, lit les lignes ajoutées aujourd’hui dans le tableur, les agrège avec le module « Text aggregator », et envoie un seul e-mail contenant la liste. Trois modules, une trentaine d’opérations par mois, et une boîte de réception qui reste lisible.

C’est un motif que vous réutiliserez sans arrêt : écrire au fil de l’eau, lire en une fois. Il vaut pour les rapports, les relances, les récapitulatifs d’équipe.

Quand un module tombe en erreur : le comportement à choisir

Tôt ou tard, un module échouera : une API indisponible, un champ obligatoire vide, une limite de débit atteinte. Par défaut, Make arrête toute l’exécution et vous envoie un e-mail. Ce comportement est prudent, mais rarement le bon.

Les trois gestionnaires d’erreur les plus utiles

Resume — le module échoue, on lui fournit une valeur de remplacement et le scénario continue. Parfait pour un enrichissement facultatif : si l’API qui devine le pays du client ne répond pas, on écrit « Inconnu » et on avance.

Ignore — le paquet en cours est abandonné, les suivants sont traités normalement. C’est le bon choix quand un paquet sur cent est mal formé et que le reste doit passer.

Retry (Break) — Make met l’exécution de côté et la rejoue automatiquement plus tard. C’est le choix évident pour les pannes temporaires : une API qui répond mal à 14 h répondra très bien à 14 h 05. Cette reprise exige que l’option « Allow storing incomplete executions » soit activée dans les réglages du scénario ; sans elle, il n’y a rien à rejouer.

Poser un gestionnaire

Clic droit sur le module concerné, puis « Add error handler ». Une branche apparaît, en pointillés : tout ce que vous y placez ne s’exécute qu’en cas d’échec. On y met en général le gestionnaire choisi, et parfois une notification qui vous prévient sans arrêter la machine.

Un scénario sans gestionnaire d’erreur fonctionne très bien… jusqu’au jour où il s’arrête sans que personne ne le remarque. Le vrai risque de l’automatisation n’est pas qu’elle casse : c’est qu’elle casse en silence.

Les 7 erreurs qui font échouer une première automatisation

Elles reviennent dans cet ordre, presque toujours.

1. Tester sur des données réelles. Créez un tableur de test et envoyez-vous vos propres e-mails. On ne met pas au point une automatisation sur la boîte qui reçoit les vraies commandes.

2. Laisser le déclencheur sans limite. « Maximum number of results » à 100 sur un premier essai, et vous consommez un dixième de votre quota mensuel en une exécution. Mettez 1 ou 2 pendant toute la phase de construction.

3. Oublier la ligne d’en-têtes du tableur. Sans en-têtes, Make propose « Column A, Column B » et vous perdez le fil au bout de six colonnes. Nommez-les d’abord, mappez ensuite.

4. Confondre « Run once » et « activer ». « Run once » exécute le scénario immédiatement, une fois, pour tester. L’interrupteur en bas à gauche le fait tourner tout seul selon la planification. Beaucoup de débutants testent pendant des jours sans jamais activer — le scénario ne tourne alors jamais sans eux.

5. Ne pas vérifier le fuseau horaire. Un scénario planifié à 8 h qui s’exécute à 9 h, c’est un fuseau réglé sur UTC dans le profil. Cela se corrige en trente secondes et empoisonne des semaines.

6. Mapper un champ qui n’existe pas toujours. Un e-mail sans pièce jointe n’a pas de champ « Attachments ». Si votre module suivant l’exige, il échouera sur ce paquet précis. La fonction ifempty ou un filtre « Exists » règlent le problème.

7. Empiler les scénarios au lieu de les nommer. Au bout de trois semaines, « Integration Gmail, Google Sheets » ne vous dira plus rien. Adoptez tout de suite une convention : « [Client] Demandes de devis → Tableur suivi ».

Combien vous coûte ce scénario, en opérations

Faisons le calcul sur votre scénario à trois modules, pour un volume réaliste de 20 e-mails pertinents par mois sur 200 e-mails reçus.

La première ligne dépasse le quota gratuit à elle seule. La dernière tient largement dedans, et fait exactement la même chose. La différence ne tient pas au nombre de modules : elle tient à la fréquence de réveil et à l’endroit où l’on écarte les paquets inutiles.

Retenez la formule : opérations ≈ (nombre de réveils) + (paquets récupérés × modules traversés). Elle vous permet d’estimer n’importe quel scénario avant de l’activer, en trente secondes et sans le construire.

Adapter ce scénario à votre activité

Le squelette Gmail → tableur → notification se transpose presque tel quel. Cinq variantes, par métier, avec la seule chose qui change.

Freelance : un suivi de prospection

Déclencheur identique, mais la requête Gmail cible les réponses à vos e-mails de prospection. Le tableur devient un pipeline : date, contact, message, statut. Vous ajoutez une colonne « à relancer le » remplie par la fonction addDays, et vous avez un CRM de démarrage sans payer de CRM.

E-commerçant : un journal des demandes après-vente

La requête cible les messages contenant un numéro de commande. Le module Sheets écrit la ligne, et un filtre supplémentaire déclenche une notification immédiate seulement si le sujet contient « remboursement » ou « litige ».

Artisan : les demandes de devis du site

Si votre site envoie un e-mail à chaque formulaire rempli, le scénario le range dans un tableur et vous notifie sur votre téléphone. La colonne « rappelé le » se coche à la main : l’automatisation n’a pas besoin de tout faire pour être utile.

Commerçant local : la veille des avis clients

Les notifications d’avis arrivent par e-mail. Le scénario les collecte, extrait la note avec une fonction de texte, et n’alerte que sous un certain seuil. Vous répondez aux avis négatifs dans l’heure sans surveiller quoi que ce soit.

Consultant : un relevé d’heures automatique

Le déclencheur devient Google Agenda plutôt que Gmail : chaque événement terminé écrit une ligne avec sa durée et son client. En fin de mois, une somme dans le tableur donne la facturation. Deux modules, et une corvée mensuelle qui disparaît.

Dans les cinq cas, le travail conceptuel est le même : identifier l’événement déclencheur, décider ce qu’on garde, choisir où l’écrire. Vous venez de l’apprendre une fois ; vous le referez sans tutoriel.

Les trois réflexes d’un scénario propre

Ce qui sépare un scénario de démonstration d’un scénario sur lequel on peut compter tient en trois habitudes, à prendre dès maintenant.

Nommer

Renommez chaque module avec ce qu’il fait réellement plutôt que son nom générique : « Lire les demandes de devis » vaut mieux que « Gmail — Watch Emails ». Dans six mois, sur un scénario à neuf modules, vous nous remercierez. Le nom se change par un clic droit, « Rename ».

Documenter

Chaque scénario dispose d’un champ de notes. Écrivez-y en deux lignes ce qu’il fait, ce qu’il suppose (le tableur doit exister, la colonne D doit être au format date) et ce qu’il faut vérifier s’il tombe en panne. C’est trois minutes aujourd’hui contre une heure de rétro-ingénierie plus tard.

Vérifier avant d’oublier

Une automatisation qu’on active puis qu’on n’ouvre plus jamais est une automatisation dont on ne saura pas qu’elle est morte. Bloquez cinq minutes dans votre agenda, une fois par mois : ouvrir l’historique, vérifier qu’il n’y a pas d’erreurs récurrentes, vérifier la consommation. C’est l’entretien minimal, et il suffit.

Passer du test à la production sans mauvaise surprise

Entre « ça marche quand je clique sur Run once » et « ça tourne tout seul depuis trois mois », il y a une bascule que la plupart des débutants franchissent trop vite. Voici la liste de contrôle, dans l’ordre.

Remettez la limite du déclencheur à sa valeur réelle. Vous l’aviez baissée à 2 pour tester ; laissez-la basse si votre volume est faible, montez-la à 10 ou 20 si vous recevez beaucoup. Ne la mettez jamais au maximum « au cas où ».

Changez la destination. Si vous avez testé sur un tableur bac à sable, basculez sur le vrai — et vérifiez que ses en-têtes sont identiques, sinon le mapping écrira dans les mauvaises colonnes sans se plaindre.

Choisissez la planification. Posez-vous la seule question qui compte : quel retard suis-je prêt à accepter ? Pour une demande de devis, une heure. Pour un rapport, une fois par jour. La réponse « le plus vite possible » est presque toujours une erreur de débutant, et elle se paie en opérations.

Activez, puis laissez passer trois réveils. Revenez ensuite dans l’historique. Trois exécutions vertes d’affilée sur des données réelles, c’est le vrai feu vert. Une seule ne prouve rien : le cas particulier arrive au deuxième passage.

Notez la date dans le champ de notes. « Mis en production le 3 mars 2026 » vous servira le jour où vous chercherez à quel moment vos données ont commencé à être fiables.

FAQ — vos questions fréquentes

Mon module Gmail ne trouve aucun e-mail pendant le test. Normal ?

Oui, si aucun nouvel e-mail non lu n’est arrivé depuis le point de départ choisi. Envoyez-vous un message de test, attendez qu’il apparaisse dans la boîte, puis relancez « Run once ». Vérifiez aussi le critère « Only unread emails » : un message déjà ouvert ne sera pas détecté.

Pourquoi limiter à 2 résultats maximum pendant les tests ?

Pour éviter qu’un test ne traite accidentellement des dizaines d’e-mails d’un coup (et ne consomme autant d’opérations). Une fois le scénario validé, vous pouvez monter cette limite à 10 ou 20.

Puis-je filtrer pour ne suivre que certains e-mails ?

Absolument, et c’est la suite logique : ajoutez un filtre sur le lien entre les deux modules (clé à molette → « Set up a filter ») — par exemple « Sender contains @monclient.com ». Les filtres sont traités en détail dans le module Cas pratiques.

Ce scénario fonctionne-t-il avec Outlook plutôt que Gmail ?

Oui : remplacez le module Gmail par « Microsoft 365 Email — Watch Messages ». Le reste — mapping, test, activation — est identique. C’est la beauté du schéma déclencheur → action : il se transpose partout.

Mon scénario tourne mais n’écrit rien dans le tableur. Où chercher ?

Ouvrez l’historique et cliquez sur la dernière exécution. Si le module Gmail affiche 0 paquet, le problème vient de sa requête de recherche. S’il affiche des paquets mais que le module Sheets n’a rien reçu, un filtre les arrête entre les deux. Si les deux modules ont tourné, vérifiez que vous regardez la bonne feuille du bon classeur — c’est plus fréquent qu’on ne le croit.

Puis-je dupliquer ce scénario pour un autre usage ?

Oui, et c’est recommandé. Dans la liste des scénarios, le menu « … » propose « Clone ». Le clone garde les modules, le mapping et les connexions ; il arrive désactivé. Changez la requête du déclencheur et la destination, renommez, activez. Vous gagnez le quart d’heure de construction.

Que se passe-t-il si je modifie un scénario pendant qu’il tourne ?

Les modifications ne s’appliquent qu’après enregistrement, et l’exécution en cours va au bout avec l’ancienne version. Il n’y a donc pas de risque de corruption. En revanche, si vous enregistrez une version incomplète, c’est elle qui tournera au prochain réveil : désactivez le scénario le temps d’une modification importante.

Combien de scénarios puis-je faire tourner en même temps ?

Sur le plan gratuit, deux scénarios actifs simultanément. Ce n’est pas une limite au nombre de scénarios créés — vous pouvez en avoir vingt — mais au nombre qui tournent en parallèle. En pratique, on regroupe : un scénario à cinq modules coûte le même nombre d’opérations que cinq scénarios à un module, et n’occupe qu’un emplacement.

Faut-il laisser mon ordinateur allumé pour que le scénario tourne ?

Non. Une fois activé, le scénario s’exécute sur les serveurs de Make, sans votre navigateur ni votre machine. C’est même tout l’intérêt : il tourne la nuit, le week-end et pendant vos vacances. Votre ordinateur ne sert qu’à construire et à surveiller.

En résumé

Vous avez créé une connexion, mappé des données, testé proprement et activé un scénario en production : le cœur du métier est acquis. Prochaine étape : connecter toutes vos applications favorites — Notion compris.