Des automatisations qui ne cassent pas : la stack ennuyeuse

J’ai construit des dizaines d’intégrations entre des outils SaaS — CRM ↔ facturation, webhook ↔ base de données, « quand X se passe dans le service A, faire Y dans le service B ». Le pattern qui ne m’a jamais laissé tomber est aussi le moins excitant.

Trois primitives, dans l’ordre

Si un collègue me demande comment construire une nouvelle automation, la réponse est toujours la même :

1. L’idempotence en premier. Chaque opération doit être safe à rejouer. Dérivez une clé depuis une entrée stable (l’ID de l’événement, pas le timestamp). Stockez-la. Sautez en cas de collision.
2. Retry avec backoff, jamais en silence. Les échecs arrivent. La question c’est si vous êtes au courant. Remontez chaque retry qui atteint son plafond.
3. Une ligne de log persistante par événement. Pas un flux de logs debug. Une ligne structurée avec : ID d’événement, source, action effectuée, résultat, durée. C’est votre couche forensics quand les choses partent en vrille à 3h du matin.

Faites ça bien et vous pouvez construire presque n’importe quoi par-dessus.

La stack sur laquelle je reviens toujours

• Receiver de webhook — n’importe quoi qui peut vérifier une signature en 20 lignes.
• Queue — Cloudflare Queues, BullMQ, ou même une table Postgres avec SELECT ... FOR UPDATE SKIP LOCKED. Le choix importe moins que la discipline.
• Store d’idempotence — Redis avec un TTL de 7 jours, ou KV avec la même durée. N’allez pas chercher une ligne en base.
• Une destination de logs — pino + un agrégateur hébergé. Cherchable, daté, parseable.

Vous remarquerez qu’il n’y a pas d’orchestrateur dans cette liste — pas de n8n, pas de Zapier, pas de workflow engine. C’est délibéré. n8n en particulier est excellent pour les workflows d’équipe et les intégrations rapides entre outils SaaS. Mais ces outils sont la couche haute, pas la fondation. Construisez les primitives en premier, ajoutez l’orchestration par-dessus. Sautez la fondation et même un workflow n8n bien configuré devient un risque le jour où il fait tourner quelque chose de critique.

L’erreur que je vois encore et encore

Les équipes se tournent vers un moteur de workflows dès le premier jour. Les workflows sont géniaux quand vous avez 50+ processus branchants à maintenir. La plupart des équipes ont cinq automatisations qui tournent chacune quelques milliers de fois par jour. Pour ça, le code bat la config — à chaque fois.

Une fonction bien typée avec les trois primitives intégrées est plus fiable, plus debuggable, et (franchement) plus rapide à livrer qu’un workflow visuel en six étapes que quelqu’un doit penser à maintenir.

Stack ennuyeuse. Moins de réveils à 3h.