Automatisation

Sept ans de développement, la plus grosse communauté du secteur, et surtout un modèle économique qui ne te punit pas de réussir : tu paies un serveur, pas des opérations. Un scénario qui traite dix mille éléments coûte le même prix qu'un scénario qui en traite dix.

Trois raisons concrètes pour lesquelles nous l'enseignons en premier :

Tu peux l'héberger chez ton client. Ses données ne sortent pas. Cet argument seul débloque des missions dans la santé, le droit et le secteur public.

Tu peux mettre du code quand le glisser-déposer coince. Un nœud JavaScript ou Python au milieu du flux évite la contorsion en douze modules que les outils purement visuels imposent.

Sa bibliothèque de modèles est énorme et importable. Un scénario se partage en un fichier .json que l'autre importe en trente secondes : c'est aussi la forme sous laquelle nous livrons nos propres modèles.

Sa contrepartie honnête : l'auto-hébergement est un vrai sujet d'exploitation (sauvegardes, mises à jour, certificat). Si personne chez toi ne veut s'en occuper, l'offre infonuagique existe et reste raisonnable.

Deux garde-fous se posent à l'installation, et pas après : la durée maximale d'une exécution et le nombre d'exécutions simultanées, réglés par variable d'environnement sur une instance auto-hébergée. Les deux arrêtent réellement quelque chose, ils ne se contentent pas de notifier. Une connexion tombée, elle, se rouvre depuis la liste des identifiants du compte, jamais depuis le nœud qui l'utilise.

L'éditeur visuel reste le meilleur du marché pour comprendre ce qui se passe : on voit la donnée circuler bulle après bulle, et le débogage pas à pas est un excellent outil pédagogique. Pour une première automatisation, c'est le chemin le plus court vers le déclic.

Le point de bascule à connaître : chaque module traversé consomme une opération. Un scénario qui boucle sur cent lignes de tableur brûle cent opérations par module de la boucle. Les factures surprises viennent presque toujours de là, jamais du nombre de scénarios.

Corollaire à connaître avant de régler un déclencheur planifié : un réveil qui ne trouve rien consomme quand même l'opération du module de déclenchement. Un scénario sondé au quart d'heure paie donc environ 2 900 opérations par mois avant d'avoir traité le moindre dossier. Le décompte exact figure sur la page de tarification de l'éditeur, qui reste la seule référence opposable : ces règles bougent.

Trois plafonds existent déjà dans l'outil, et il faut savoir lequel arrête vraiment. Après une série d'erreurs consécutives sur le même scénario, Make le désactive. Quand les opérations de ton offre sont épuisées, les scénarios cessent de tourner jusqu'à la remise à zéro du cycle de facturation, ou jusqu'à l'achat d'opérations supplémentaires : ce n'est donc pas un arrêt définitif, c'est un arrêt qui s'achète. Les alertes de consommation, en revanche, se contentent d'écrire un courriel et laissent tout passer. Lis l'intitulé jusqu'au bout avant de croire que tu es protégé.

La réautorisation d'une connexion tombée se fait depuis la liste des connexions du compte, jamais depuis le scénario. Le bouton change de nom d'une version à l'autre de l'interface ; l'endroit, lui, ne bouge pas.

Sa vraie force est la couverture applicative : des milliers d'intégrations, y compris des logiciels métier que ni n8n ni Make ne connaissent. Le jour où le CRM du client est un outil que personne d'autre ne supporte, Zapier règle le problème en une soirée.

Son modèle logique reste plus pauvre : les branchements, les boucles et la reprise d'erreur y sont moins expressifs. Pour un flux linéaire, c'est parfait ; pour un système, tu sentiras vite le plafond.

Quand tu autorises Make ou n8n sur un compte Google, le service délivre deux jetons : un jeton d'accès de courte durée, une heure par défaut, qui sert aux appels, et un jeton de rafraîchissement de longue durée qui sert uniquement à en redemander un nouveau. C'est le second qui tient la porte ouverte, et c'est donc lui qu'il faut regarder.

Ce qui coupe un jeton de rafraîchissement chez Google, et rien d'autre : six mois sans le moindre appel ; une application restée en statut « test » dans la console du développeur, auquel cas le jeton expire au bout de sept jours ; une décision d'administrateur sur le domaine ; et un changement de mot de passe uniquement si la connexion porte des portées Gmail. Une connexion Drive ou Agenda survit à un changement de mot de passe, une connexion Gmail non. C'est la nuance que presque tout le monde résume de travers, dans un sens ou dans l'autre.

Chez Microsoft et chez Slack, les durées et les règles de révocation diffèrent. Le réflexe qui vaut partout : la révocation se fait sur la page du service, elle est immédiate, et elle casse volontairement les scénarios qui s'appuyaient dessus. Supprimer la connexion côté Make ou n8n efface le jeton rangé là, mais laisse l'autorisation enregistrée chez le service.