Zapier, Make, n8n ou du code : sur quoi construire une automatisation qui dure ?

Une plateforme d'automatisation est le bon choix pour valider une idée : montée en une après-midi, sans développeur, et abandonnée sans regret si l'idée ne tient pas. Elle devient un mauvais choix dès que l'entreprise dépend du résultat, pour trois raisons mesurables : le coût augmente avec le volume traité au lieu de rester fixe, la logique métier vit dans un compte chez un tiers plutôt que dans un dépôt que vous possédez, et une mise à jour de la plateforme peut casser un enchaînement sans alerte. La règle utile : prototyper sur une plateforme, reconstruire en code le jour où l'automatisation devient indispensable.

La question se pose rarement en ces termes, parce qu'elle est presque toujours déjà tranchée : quelqu'un a monté un enchaînement sur une plateforme, ça marche, et deux ans plus tard l'entreprise en dépend. Le problème n'est pas d'avoir commencé là. Le problème est de ne jamais en être sorti.

Ce que les plateformes font très bien

Elles suppriment l'obstacle le plus cher d'un projet : le démarrage. Une idée peut être testée en une après-midi, par quelqu'un qui n'écrit pas de code, avec des connecteurs déjà prêts pour la plupart des logiciels du marché. Et surtout, elle peut être abandonnée sans que personne n'ait à justifier des semaines de développement.

Pour un premier essai, c'est le bon terrain, et je m'en sers pour cela.

Ce qui se retourne quand ça devient sérieux

• Le coût suit le volume. La facturation est liée au nombre d'opérations traitées. Une automatisation qui réussit traite plus, donc coûte plus, exactement quand elle devient indispensable.
• La logique n'est pas à vous. Elle vit dans une interface, dans un compte. On ne peut pas la relire ligne à ligne, ni la comparer entre deux versions, ni retrouver qui a changé quoi la semaine dernière.
• Rien n'est testable. Il n'existe pas de moyen de vérifier automatiquement qu'une modification n'a rien cassé ailleurs. On le découvre en production.
• Les pannes sont silencieuses. Un connecteur mis à jour change de comportement, l'enchaînement continue de tourner et produit des résultats faux. Personne ne reçoit d'alerte, parce que techniquement rien n'a échoué.
• La sortie est difficile. Au bout de deux ans, reconstruire ailleurs suppose de relire des dizaines d'écrans pour retrouver des règles que personne n'a documentées.

Ce que le code coûte, et ce qu'il rend

Le code demande plus de travail au départ, c'est sa seule mauvaise nouvelle. En échange : il tourne où vous voulez, y compris sur une machine dans vos locaux ; son coût ne dépend pas du volume traité ; chaque modification est datée et attribuée ; et on peut écrire des tests qui échouent avant la mise en production plutôt qu'après.

Ce n'est pas une préférence esthétique. C'est la différence entre une automatisation que vous possédez et une automatisation que vous louez.

La frontière, en pratique

Une plateforme est un prototype qui a réussi à passer en production. Le jour où l'entreprise en dépend, il faut la traiter comme une dette, pas comme une fondation.

Le moment du changement

Il y a un signal clair : la première fois que quelqu'un dit « il ne faut surtout pas toucher à ça ». À cet instant, l'automatisation est devenue critique et elle n'est pas outillée pour l'être. La reconstruction coûte une à trois semaines selon la complexité, et elle se paie d'elle-même en abonnements évités si le volume est là.

Le bon ordre est donc le même que partout ailleurs : tester vite et à bas coût, mesurer ce que ça rapporte, puis construire solidement ce qui a prouvé sa valeur. L'erreur n'est pas de commencer sur une plateforme. C'est de considérer que l'étape provisoire est l'arrivée.