29 automations Zapier + Make remplacées en quatre semaines

#softwareengineering #architecture #nocode #claudecode

La facture que je ne comprenais plus

Un matin de mars, je relis la liste des prélèvements récurrents de L'Atelier Palissy, et je tombe sur une ligne qui me surprend par sa régularité : Zapier Pro, 73,50 dollars, tous les mois depuis dix-huit mois. À côté, un Make Pro plus petit mais tout aussi discret. Je fais le compte : vingt-et-un Zaps actifs, neuf scénarios Make, quelques-uns à l'arrêt, quelques-uns manifestement cassés depuis des semaines. Personne ne s'en apercevait, parce que chaque automation vivait sur son propre dashboard, avec sa propre histoire, ses propres logs que personne ne regardait jamais.

Je ne savais pas exactement ce que chacune faisait. Je savais qu'il y en avait environ trente, qu'elles faisaient passer des données de Formidable vers Mailchimp, de Meta Lead Ads vers une Google Sheet partagée, de Stripe vers un mail de confirmation, qu'elles se déclenchaient sur webhook, sur polling, sur horaire, et qu'une moitié des pannes silencieuses du système venait probablement de là. Je n'avais pas l'énergie d'aller voir, parce qu'aller voir, c'était ouvrir un outil dans lequel je n'étais pas chez moi.

Vingt-huit jours plus tard, il n'y en avait plus. Zéro Zap, zéro scénario Make, tout remplacé par trois cents lignes de TypeScript qui tournent dans mon ERP Rembrandt, sous Sentry, sous tests, avec une seule vue d'ensemble que je regarde le matin au café.

Si tu as 30 secondes. Les automations Zapier/Make paient trois dettes invisibles : elles vivent hors de ta base, elles loguent ailleurs que ton monitoring, et elles se déclenchent sur des règles qu'on finit par ne plus lire. Remplacer trente automations par un pipeline événementiel unique prend quatre semaines, pas six mois, à condition de tenir une règle d'or : ne jamais couper un Zap avant d'avoir validé son remplacement en double écriture pendant trois à cinq jours. L'article donne la méthode, le calendrier et le coût évité.

Trois dettes invisibles

La première dette que les outils no-code produisent s'appelle, dans la littérature interne qui n'existe pas encore, la dette distribuée. Tes données vivent à trois endroits à la fois, et aucun des trois n'est canonique. Mon CRM pensait que la vérité était dans Google Sheets. Mailchimp pensait que la vérité venait de Zapier. Supabase ne pensait rien parce que je n'y écrivais qu'une partie de ce qui se passait. Le jour où un prospect arrive dans trois onglets différents avec trois orthographes différentes, personne ne sait quel enregistrement est le vrai. La seule façon de trancher, c'est de choisir un endroit qui gagne par construction, et de faire tout le reste en esclave.

La deuxième dette est l'absence de monitoring unifié. Un Zap qui casse envoie un email à l'adresse qui a créé le compte Zapier, éventuellement à personne. Un scénario Make qui échoue dans sa troisième étape laisse les deux premières consommer des quotas, et la seule trace est un petit chiffre rouge dans un dashboard que personne n'ouvre. Sentry, Datadog, Grafana — aucun n'agrège. Tu apprends que ton automation est morte quand un client appelle pour dire qu'il n'a pas reçu son mail de confirmation.

La troisième dette est la plus silencieuse, et c'est celle des règles qu'on oublie d'avoir écrites. Un Zap créé il y a onze mois pour gérer un cas particulier de saison estivale continue de tourner l'hiver suivant, et il route un lead Paris vers l'adresse mail d'une collaboratrice qui a quitté la maison. Tu ne le vois pas, parce que le lead arrive quand même, apparemment. Personne ne relit un Zap. C'est fait pour qu'on n'ait pas à le lire. C'est précisément ce qui en fait une dette.

La règle d'or que j'ai mise quinze jours à admettre

Ma première tentative, début avril, était naïve. J'écrivais un remplaçant Rembrandt, je coupais le Zap, je passais au suivant. Mon troisième essai s'est fini en Slack à vingt-trois heures, un lead Meta perdu parce que mon webhook n'était pas déployé sur le bon environnement Vercel, et la certitude que si je continuais comme ça, j'allais casser au moins un élément critique avant la fin de la semaine.

J'ai posé la règle suivante, que j'ai tenue jusqu'au dernier Zap.

Ne jamais couper un Zap avant d'avoir validé son remplacement en double écriture pendant trois à cinq jours.

Concrètement : j'écris le remplaçant, je le déploie, il tourne en même temps que le Zap. Chaque lead arrive en double dans ma Supabase, et dans l'adresse mail de l'équipe qui reçoit la notification. Pendant trois à cinq jours, je compare : même lead, mêmes données, mêmes timings, mêmes mails envoyés ? Si oui, je coupe le Zap. Si non, je désactive mon code et j'ai encore un filet qui tourne pendant que je comprends ce qui a cassé.

Le pire effet de bord possible pendant la transition, c'est un lead reçu en double par l'équipe commerciale. C'est un agacement, pas une catastrophe. Un lead perdu, c'est une catastrophe silencieuse qu'on découvre un mois plus tard.

L'architecture qui a remplacé les trente automations

La cible est d'une simplicité qui ne se voyait pas tant que je restais dans les outils no-code.

Meta Ads    ──┐
Formidable  ──┤
Stripe      ──┤──► Webhooks Rembrandt ──► Supabase (source unique)
Manuel      ──┘                              │
                                             ├── Gmail SMTP (notifs internes)
                                             ├── Slack (alertes équipe)
                                             ├── Meta CAPI (feedback campagnes)
                                             ├── automation_logs (traçabilité)
                                             └── Cron → Mailchimp puis Brevo

Un seul point d'entrée par source, un seul endroit de stockage, un fan-out en parallèle vers les outils de notification. Le cœur tient dans un fichier qui s'appelle lib/lead-pipeline.ts et qui exécute en parallèle les intégrations sortantes après chaque insert dans la table contacts.

export async function runLeadPipeline(lead: Lead) {
  await Promise.allSettled([
    syncMailchimp(lead),
    notifySlack(lead),
    notifyGmail(lead),
    sendMetaCapi(lead),
    generateFirstContactDraft(lead),
  ])
  await logAutomation(lead, /* status par outil */)
}

Promise.allSettled plutôt que Promise.all parce que si Slack est down, je veux quand même envoyer le mail. Chaque résultat alimente une table automation_logs qui est la seule chose que je regarde le matin : combien de leads sont arrivés, quels outils ont réussi, quels ont échoué, sur quelle fenêtre temporelle.

Le calendrier tel qu'il s'est vraiment passé

Semaine	Ce que j'ai fait	Zaps coupés
S1	Pipeline central + client Slack + table `automation_logs`	0
S2	Formidable direct en double écriture	0
S3	Coupe des dix Zaps Formidable + webhook Meta en double	10
S4	Coupe des huit Zaps Meta + webhook Stripe	18
S5	Scénarios Make (PDFs, crons) et nettoyage	21
S6	Kill Zapier Pro, downgrade planifié	21/21

Le jour de la coupe finale, je n'ai pas dormi de la nuit précédente, et le lendemain j'ai ouvert mon dashboard automation_logs toutes les heures. Treize jours plus tard, rien n'avait cassé. Je maintiens encore aujourd'hui une route morte, sync-gsheets-leads, que je n'appelle jamais mais qui me sert de filet réactivable jusqu'à la fin du mois.

Ce qu'on gagne qu'on ne soupçonnait pas

Le gain économique saute aux yeux — une centaine d'euros par mois d'abonnements consolidés. Mais ce qui m'a surpris, c'est un gain de compréhension. La première semaine après la coupe, je me suis aperçu que je comprenais mon système pour la première fois en dix-huit mois. Je pouvais ouvrir un fichier, relire une règle de routage, la modifier, la tester, la déployer en vingt minutes. Avant, même une modification banale — changer l'adresse destinataire d'un mail de notification — passait par cinq onglets Zapier et une peur sourde d'en casser un en bougeant un autre.

Deux scènes courtes me reviennent. La première, j'ai dû appeler Gaspard, notre prestataire informatique, pour récupérer le mot de passe du compte Zapier. Il l'avait, il me l'a donné, il n'a pas demandé pourquoi je voulais y aller. La seconde, plus matinale, Françoise était sortie de son bureau avec sa tasse à la main et s'était plantée devant le mien : « Bon. Tes doublons Meta, tu comptes les garder combien de temps ? Parce que Hélène reçoit deux mails pour le même lead, elle commence à s'agacer, celle-là. » C'était la troisième semaine, je lui ai répondu « Encore deux jours », elle a acquiescé, reposé sa tasse, et la coupe a été faite le lendemain soir. J'ai retenu que la double écriture a un coût de patience d'équipe qu'il ne faut ni minimiser ni étirer au-delà du nécessaire.

Il y a une hygiène particulière à ce qu'un système se tienne en un seul endroit. On la sous-estime tant qu'elle n'est pas là, parce que les outils no-code vendent précisément la promesse qu'elle est partout, qu'elle n'a plus à être pensée. La vérité est que si elle n'est pas pensée en un seul endroit, elle est juste enfouie. Elle coûte moins cher à écrire, et beaucoup plus cher à vivre.

Ce que tu peux copier dans ton projet

Patterns réutilisables extraits de cette migration, indépendants de ma stack :

La règle d'or — double écriture trois à cinq jours avant coupe. Pas négociable. Un lead en double vaut mieux qu'un lead perdu. Le temps supplémentaire se paie une fois et se rembourse à chaque incident évité
Un pipeline événementiel unique — une fonction runPipeline(event) appelée après chaque insert, qui exécute en parallèle (Promise.allSettled) les intégrations sortantes et trace le résultat de chacune dans une table dédiée
Une table automation_logs — une ligne par événement, une colonne par outil sortant avec son statut. C'est le seul dashboard qu'on regarde le matin, et il remplace tous les dashboards séparés des outils no-code
Un filet réactivable post-coupe — garde la route morte encore deux semaines. Le jour où un bug te surprend, c'est quinze secondes de vercel.json pour remettre le filet. Après, tu supprimes pour de bon

Et une discipline plus large : tout outil qui loge ta logique métier hors de ta base te fait payer trois dettes — distribuée, sans monitoring, illisible. Zapier et Make sont utiles pour prototyper. Ils deviennent dangereux dès que l'activité sérieuse en dépend.

Et vous, combien d'automations no-code font tourner votre système en ce moment, et quand a été la dernière fois qu'une personne les a toutes relues ? Je lis les commentaires.

Code compagnon : rembrandt-samples/lead-pipeline/ — runLeadPipeline avec Promise.allSettled, schéma automation_logs, diagramme hub-and-spoke, MIT, prêt à copier.