Modules
Comprendre les types de modules disponibles et savoir quand utiliser lequel.
⏱️ En bref : Les modules sont les briques élémentaires d'un scénario Make. Trois grandes familles : triggers (déclenchent), actions (font quelque chose), searches (cherchent et retournent). À ça s'ajoutent les modules transverses : HTTP, JSON, Tools, Flow Control. Bien les distinguer évite des heures perdues à chercher la mauvaise brique.
Les 3 types de modules par fonction
Quand vous ajoutez un module à un scénario, Make les classe par fonction. Comprendre la distinction est essentiel :
- Triggers (déclencheurs) : démarrent un scénario. Toujours en première position. Se subdivisent en schedulés (Watch X every Y minutes) et instantanés (webhooks)
- Actions : créent, modifient ou suppriment quelque chose. Create deal, Update contact, Send email...
- Searches : cherchent et retournent des données sans rien modifier. Find deal by email, List products...
Une erreur classique : utiliser une Action "Create" alors qu'on veut faire un upsert (créer ou mettre à jour). Dans ce cas, il faut d'abord un Search, puis un Router conditionnel sur le résultat, puis Create OU Update selon la branche.
Triggers schedulés vs instantanés
Cette distinction conditionne l'architecture du scénario :
- Schedulés : Make va vérifier l'API source à intervalle régulier (1 min minimum sur Pro, 15 min sur Core). Ex : "Toutes les 15 minutes, regarde s'il y a de nouveaux deals dans Pipedrive". Coûte des opérations même quand il n'y a rien de neuf
- Instantanés (webhook) : la source pousse les données vers Make en temps réel. Latence < 1 seconde. Ne consomme des opérations que lors d'un vrai déclenchement
Privilégier toujours l'instantané quand il existe. Voir le chapitre Webhooks pour la mise en œuvre.
💡 Détecter le bon trigger
Sur la page d'un module, les triggers instantanés portent un éclair ⚡ et les schedulés une horloge 🕒. Si l'app source n'a pas de trigger instantané, vérifiez s'il existe quand même côté app : Pipedrive, Stripe, Typeform proposent souvent des "Outgoing webhooks" natifs qu'on peut câbler à un module Webhooks → Custom webhook.
Modules transverses indispensables
Indépendamment des apps, Make fournit des modules génériques utilisables partout :
- HTTP → Make a request : appeler n'importe quelle API REST. Le couteau suisse quand l'app n'a pas de module dédié
- JSON → Parse JSON / Create JSON : transformer une string en objet manipulable, ou inversement
- Tools → Set variable / Get variable : stocker une valeur calculée pour la réutiliser plus loin dans le scénario
- Tools → Sleep : attendre N secondes (utile pour les rate limits)
- Text parser → Match pattern : extraire des données d'un texte avec une regex
- Flow Control → Iterator / Aggregator / Router / Repeater : voir le chapitre Itérateurs
Le module HTTP : votre joker
Quand un outil n'a pas de module Make dédié (cas fréquent pour les apps françaises type Sellsy, Dolibarr, Brevo, Pennylane), le module HTTP permet d'appeler son API directement. Configuration type :
- URL : l'endpoint de l'API (ex :
https://api.brevo.com/v3/contacts) - Method : GET, POST, PUT, DELETE selon l'action
- Headers : Authorization (clé API), Content-Type (souvent application/json)
- Body : payload JSON (si POST/PUT)
- Parse response : Yes pour récupérer la réponse comme un objet structuré
📘 Bonne pratique
Pour les API qui demandent une authentification réutilisable, créer une Connection HTTP avec OAuth/Bearer token dans Connections → Add. Ça évite de coller la clé API dans chaque scénario et permet de la roter facilement.
Modules d'apps : versions et changements de version
Make propose souvent plusieurs versions d'un même module (ex : Pipedrive a v1 et v2 de Watch deals). Toujours utiliser la dernière version stable. Quand un module passe à une nouvelle version majeure, l'ancienne reste fonctionnelle mais Make ne la maintient plus. Migrer dès que possible pour éviter les ruptures.
Erreurs fréquentes par type de module
- Trigger schedulé qui ne déclenche pas : vérifier le filtre de date du module (cocher "From now on" pour ignorer le passé)
- Action qui crée des doublons : il manque un Search en amont pour faire de l'upsert
- Search qui retourne 0 résultat : vérifier l'opérateur (equals vs contains) et l'encoding (un email avec majuscule peut ne pas matcher)
- Module HTTP qui retourne 401 : token expiré ou mauvaise méthode d'auth (Bearer vs Basic)
Pour la composition de plusieurs modules avec logique conditionnelle, voir le chapitre Routeurs et filtres.