Make : choisir un scénario d’automatisation visuelle
Verdict : Make convient aux indépendants et petites équipes qui relient des SaaS sans coder. Free coûte $0 ; Core démarre à $9/mois facturé annuellement. Free limite les scénarios à 5 minutes et les déclenchements à 15 minutes. Bon choix pour des flux cloud simples, mais sa fiabilité en charge reste inconnue sans mesure réelle.
Sommaire
Choisir selon la cadence, la durée et l’hébergement
Un scénario Make est un graphe visuel de modules. Un module déclenche une action dans une application, reçoit une donnée, la transforme ou la transmet au suivant. Le catalogue officiel recense plus de 3 000 applications, dont Stripe, Gmail, Notion, Airtable, Slack et Google Sheets. L’éditeur propose aussi un parcours guidé pour construire un premier scénario dans son centre d’aide.
La première question est la cadence. Le plan Free impose au moins 15 minutes entre deux exécutions planifiées, contre 1 minute sur Core, Pro, Teams et Enterprise. Il autorise 2 scénarios actifs, tandis que les formules payantes les rendent illimités. Une synchronisation quotidienne ou toutes les 15 minutes peut donc rester gratuite ; un flux qui doit réagir en moins d’un quart d’heure sort de ce cadre.
La deuxième question est la durée. Une exécution ne dépasse pas 5 minutes sur Free et peut durer jusqu’à 40 minutes sur les formules payantes. Un appel d’API lent, un traitement de gros fichiers ou un transfert de nombreuses lignes demande un découpage ou un outil spécialisé plutôt qu’un simple changement de module.
La troisième question concerne l’hébergement. Un scénario Make s’exécute sur l’infrastructure de l’éditeur, avec un hébergement annoncé chez AWS en Europe et en Amérique du Nord. Cette formule évite l’installation et la maintenance d’un serveur, mais elle ne permet pas de contrôler la machine d’exécution. Un système local ou une base située dans un réseau privé nécessite l’« On-prem agent », réservé au plan Enterprise d’après la grille publique.
Le choix change si le code est le produit du travail. Un script Python donne le contrôle du système, des paquets et du calendrier. n8n propose une approche auto-hébergée et des workflows lisibles ; le montage d’un premier workflow n8n montre cette logique avec des étapes vérifiables. Make privilégie l’assemblage graphique et les connexions SaaS prêtes à l’emploi : il correspond à la personne qui veut relier des services rapidement, pas à celle qui veut versionner chaque étape dans un dépôt.
Combien Make coûte
La grille tarifaire Make affiche des montants en dollars américains. Free est à $0 avec 1 000 crédits par mois. Core est à $9 par mois avec une facturation annuelle, ou $12 par mois avec une facturation mensuelle, pour 10 000 crédits. Pro est à $16 ou $21, Teams à $29 ou $38 ; Enterprise est sur devis. Ces montants restent ceux affichés par l’éditeur et ne sont pas convertis en euros.
| Plan | Facturation annuelle | Facturation mensuelle | Crédits mensuels |
|---|---|---|---|
| Free | $0 | $0 | 1 000 |
| Core | $9/mois | $12/mois | 10 000 |
| Pro | $16/mois | $21/mois | 10 000 |
| Teams | $29/mois | $38/mois | 10 000 |
| Enterprise | Sur devis | Sur devis | Sur devis |
Un crédit ne correspond pas nécessairement à une exécution complète. Le coût dépend des opérations et de la quantité de données transférées : un module qui déplace 1 Mo consomme davantage qu’un module qui déplace 1 Ko. Les pièces jointes et les flux volumineux réduisent donc plus vite le quota que de petites données textuelles.
Le plan Core est le seuil logique quand deux scénarios ne suffisent plus, quand l’intervalle d’une minute est nécessaire ou quand une exécution peut dépasser 5 minutes. Il ne transforme pas Make en outil d’ETL : 10 000 crédits mensuels et 40 minutes par scénario ne dimensionnent pas un déplacement de millions de lignes par jour.
Make facture aussi 2 crédits par seconde pour l’exécution de JavaScript ou de Python dans le « Make Code App ». Cette fonction étend un scénario par un calcul court ; elle ne remplace ni un IDE, ni un environnement de tests, ni un serveur capable de traiter durablement une charge importante.
Ce que Make fait bien et où il bloque
Make réduit le travail de connexion entre services. Les applications peuvent utiliser OAuth 2.0 ou des clés d’API, et l’interface permet de mapper les données d’un module à l’autre sans écrire le code de chaque intégration. Pour une suite de quelques SaaS, ce gain de mise en route est plus important que la liberté de choisir chaque composant technique.
La reprise après erreur est documentée. Pour des erreurs comme ConnectionError ou ModuleTimeoutError, la politique d’exponential backoff prévoit jusqu’à 8 tentatives. Les délais publiés vont de 1 minute à 24 heures lorsque « Store incomplete executions » est désactivé ; avec ce réglage activé, la progression commence plus vite. Après la huitième tentative échouée, le scheduling du scénario est désactivé.
« Store incomplete executions » conserve une exécution interrompue afin de permettre une reprise automatique ou manuelle. Sans cette conservation, une erreur en cours de traitement passe par un rollback qui annule les opérations déjà réalisées. Pour des données sensibles, « Keep data confidential » masque le contenu dans les journaux, au prix d’un diagnostic moins détaillé.
Les limites sont nettes pour les gros volumes, le code complexe et l’exécution locale. Free ne dépasse pas 5 minutes par scénario et ne déclenche pas plus souvent qu’une fois toutes les 15 minutes. Le « Make Code App » reste une extension facturée à la seconde, et un réseau privé ne devient accessible qu’avec l’agent Enterprise. Ces contraintes rendent Make peu adapté à un ETL, à un traitement long ou à une automatisation qui doit rester sur une machine interne.
La page d’accueil de l’éditeur mentionne la conformité GDPR, SOC 3 et SOC 2 Type II, le chiffrement et le SSO. Ces mentions indiquent les dispositifs annoncés, mais elles ne remplacent pas l’examen des exigences de sécurité propres à une organisation et aux données qu’elle traite.
Sans essai sur un compte réel, l’ergonomie et la reprise en production restent à juger sur le flux précis de l’acheteur.
Reprendre après une erreur
La documentation officielle distingue les erreurs des avertissements et décrit les gestionnaires d’erreurs, l’exponential backoff, « Throw » et les erreurs courantes. Un gestionnaire peut arrêter le scénario, ignorer un élément ou orienter l’erreur vers une autre branche selon le résultat attendu.
« Process data in order » traite les exécutions en série. Ce réglage protège l’ordre d’une synchronisation vers un CRM, mais il réduit le débit puisque l’exécution suivante attend la précédente. « Errors before deactivation » définit le nombre d’échecs consécutifs avant la désactivation automatique ; pour un webhook instantané, une seule erreur peut suffire.
« Commit after each module » valide les données étape par étape au lieu d’attendre la fin du scénario. Ce choix rend les états intermédiaires plus visibles, mais il faut vérifier les effets déjà validés lorsqu’un module suivant échoue. Pour une routine locale, les mécanismes comme systemd, journalctl et flock relèvent d’un autre modèle d’exécution ; les principes de contrôle et de reprise d’une routine permettent de les comparer.
Le choix d’un outil d’automatisation commence ainsi par trois contraintes : la cadence, la durée et l’emplacement des données. Si les trois tiennent dans les limites du cloud Make, le plan Free permet de commencer sans abonnement ; sinon, le prix Core est le premier coût à mettre en regard d’une solution auto-hébergée.