Page mise à jour le
Ce que l'API permet
Ce que Make expose réellement
Repris de la documentation publique de l'éditeur, pas d'une plaquette commerciale. Le lien vers cette documentation est en bas de page.
Des scénarios visuels, module après module
On pose un déclencheur (nouveau formulaire, commande, horaire, webhook), puis des modules : chercher un contact, créer une ligne, envoyer un message. Les routeurs séparent les cas. Les itérateurs répètent un geste sur chaque élément d'une liste — et multiplient les opérations. Make sait appeler un outil qui n'a pas de module, via une requête HTTP, dans les limites de délai documentées. Le visuel est l'intérêt : un non-développeur voit le fil. Il ne voit pas toujours le compteur.
Une opération = un module qui s'exécute
Le centre d'aide est précis : un module qui envoie cinq e-mails consomme cinq opérations ; un déclencheur qui va voir s'il y a du nouveau en consomme une, quel que soit le nombre d'éléments ramenés. Chaque paquet de données traité par un module suivant en consomme une de plus. C'est pour ça qu'un scénario « simple » à cinq modules, lancé deux cents fois, n'est pas deux cents opérations, c'est davantage. On compte avant de promettre le forfait.
Une API Make pour piloter les scénarios
Make documente une API pour créer, gérer, lancer des scénarios par programme. Lancer un scénario alors que l'organisation est pausée pour dépassement d'opérations renvoie un 429. Les plafonds d'appels à cette API varient selon le forfait (la page tarifaire cite des appels par minute). On s'en sert pour déployer ou déclencher, rarement pour remplacer l'éditeur visuel au quotidien d'une TPE.
Des milliers d'outils déjà reliés
L'intérêt de Make, c'est la bibliothèque : CRM, boutiques, tableurs, messageries, avec des modules maintenus par Make ou l'éditeur. Quand le module existe, on va plus vite qu'en écrivant l'appel. Quand il ment, ou qu'il manque un champ, on tombe sur HTTP, et on est au même point que n8n ou du code. Le visuel n'abolit pas le contrat de l'API d'en face.
Documentation de l'API Make (nouvel onglet) — API officielle des scénarios. Définition des opérations : centre d'aide Make. Consultée le 21-08-2026.
Trois automatisations concrètes
Ce qu'on met en place avec
Trois situations réelles, décrites comme du travail plutôt que comme de la technique.
Le formulaire crée la fiche, sans CSV
Une demande arrive ; Make cherche le contact, le crée, prévient Slack. Trois modules, donc plusieurs opérations par demande, plus le déclencheur. Si cent demandes par jour passent, on multiplie. Le scénario est lisible par l'équipe. Un filtre « déjà client » évite le doublon — et compte aussi. On le dessine, on le compte, on le met en route.
La commande en boutique déclenche la suite
Une commande payée crée la pièce, prévient l'atelier, pose une ligne. Chaque écriture est une opération, chaque ligne d'un itérateur aussi. Une commande de vingt lignes n'a pas le même coût qu'une commande d'une ligne. On le sait avant une journée de forte vente, pas après. Make fera le geste ; le forfait tiendra, ou pausera.
Une ronde quotidienne, pas une interrogation permanente
Chaque matin, Make lit les factures échues et prépare les relances. Un scénario à l'heure, c'est vingt-quatre déclencheurs par jour, plus les modules. Toutes les minutes, c'est quarante-trois mille déclencheurs par mois avant même d'avoir traité une facture. Le centre d'aide compte le déclencheur. On règle l'horloge sur le travail, pas sur l'anxiété.
Limites
Ce que cette intégration ne fera pas
Les contraintes qu'on rencontre pour de vrai. Les découvrir maintenant coûte une lecture ; les découvrir en cours de projet coûte le projet.
Au plafond d'opérations, tout se pause
Make arrête l'organisation ou l'équipe dont le volume est dépassé : plus d'exécution, un 429 si l'on tente de lancer par API. Ce n'est pas une file d'attente généreuse, c'est un stop. Des opérations supplémentaires s'achètent, ou on monte de forfait, ou on attend le mois suivant. Une TPE qui découvre ça un jour de relance a un trou dans le processus, pas « un petit dépassement ». On pose une alerte de consommation avant d'arriver à 100 %.
Le déclencheur et le filtre ne sont pas gratuits
Contrairement à Zapier, où le déclencheur et le filtre ne consomment pas de tâche, Make les compte souvent comme opérations. Un scénario qui « ne fait rien » la plupart du temps n'est pas gratuit pour autant : il va voir s'il y a du nouveau. C'est la surprise de facture la plus classique. On la nomme au cadrage, avec un décompte à la main sur un exemple réel, pas sur un schéma à trois cases.
Le forfait gratuit est un banc d'essai
La page tarifaire Make affiche un gratuit avec un petit volume d'opérations et deux scénarios actifs, un intervalle minimum long. C'est pour essayer. Une production d'équipe tient sur un forfait payant, dont les chiffres exacts bougent : on les lit chez Make, on ne les grave pas ici. L'intervalle minimum d'un scénario planifié dépend aussi du forfait. Vouloir « toutes les minutes » sur un gratuit n'est pas un réglage, c'est un refus.
Ce que mettre Make en place demande vraiment
Un scénario, deux modules, un décompte d'opérations sur dix exécutions réelles, puis seulement l'élargissement. On active l'historique. On n'empile pas les itérateurs sans les avoir multipliés sur papier. Make va vite à dessiner ; il va aussi vite à consommer. Le comparatif avec n8n et l'article sur le visuel et le code existent à part : ici, on pose le compteur, parce que c'est lui qui décide si le scénario survit au premier mois.
Sources
Chaque affirmation de cette page renvoie au texte qui fait foi. En cas d'écart entre cette page et la source, c'est la source qui a raison.
- Comment Make compte les opérations (nouvel onglet)
Une opération = un module qui s'exécute ; le déclencheur compte généralement pour une vérification.
Vos questions
Pourquoi ma facture Make ne ressemble-t-elle pas au nombre de « zaps » ?
Parce que Make ne facture pas un scénario, il facture chaque module qui tourne. Un scénario à quatre modules, plus un déclencheur, plus un filtre, lancé cent fois, ce n'est pas cent, c'est plusieurs centaines. Zapier, lui, ne compte ni le déclencheur ni le filtre. Comparer « 1 000 tâches » et « 1 000 opérations » sans ce détail mène à un forfait faux. On dessine le scénario, on multiplie, on choisit ensuite. Le centre d'aide Make montre le compteur au-dessus de chaque module après une exécution : c'est lui qu'on lit.
Que se passe-t-il à 100 % du volume ?
Les scénarios de l'organisation ou de l'équipe se pausent. Rien ne part, rien n'arrive, jusqu'à un achat d'opérations, un changement de forfait, ou le mois suivant. Make le documente aussi côté API (429). Ce n'est pas une file que l'on rejoue plus tard comme chez Zapier (tâches retenues). C'est un stop. D'où l'alerte de consommation, et un scénario de secours humain pour les relances du jour si jamais ça arrive.
Make ou n8n pour une TPE ?
Si personne ne veut d'un serveur et que le scénario tient dans des modules Make, Make est souvent plus vite en place. Si vous voulez auto-héberger, ou mêler du code sans quitter l'outil, n8n est plus à sa place. Les deux comptent l'usage, différemment. Le comparatif dédié tranche sur des critères ; cette page dit seulement que Make se décide d'abord au compteur d'opérations, et qu'ignorer ce compteur est la façon la plus sûre de s'arrêter en cours de mois.
Une idée en tête ?
Réservez un rendez-vous ou écrivez-nous — réponse sous 24 h.