Expert n8n et Make : construire, reprendre, réparer

Une automatisation qui tombe en panne fait du bruit. Une automatisation qui tombe à moitié n’en fait aucun.

C’est la situation dans laquelle j’interviens le plus souvent : des scénarios n8n ou Make construits il y a deux ans, qui tournent encore, sauf que trois d’entre eux ne se déclenchent plus depuis des semaines et que personne ne s’en est aperçu. Développeur indépendant, je reprends ce parc, je le répare, je le documente et je le surveille. Le diagnostic prend une trentaine de minutes par scénario, et les accès restent à votre nom.

Ce que je reprends

Presque tout le monde propose de construire des automatisations. Beaucoup moins de monde accepte d’ouvrir celles de quelqu’un d’autre, parce que c’est moins gratifiant et plus difficile à chiffrer d’avance.

Je lis ce qui tourne déjà. Ce qui marche reste en l’état. Ce qui échoue sans prévenir est réparé, puis surveillé. Ce qui a été bricolé pour contourner un manque est repris proprement, et ce qui ne sert plus à rien est éteint après que vous l’avez confirmé.

Le diagnostic dit trois choses pour chaque scénario : pourquoi il casse, si la réparation tient ou s’il faut le réécrire, et ce que sa disparition coûterait. La procédure complète, avec les sept causes de panne classées par fréquence, est dans l’article Reprendre un scénario n8n ou Make qui a cassé.

Le cas le plus fréquent : celui qui l’a construit est parti

Un stagiaire doué, un responsable des opérations parti ailleurs, un prestataire qu’on ne rappelle plus. Les scénarios tournent toujours, personne ne sait ce qu’ils font exactement, et tout le monde évite d’y toucher.

Vous récupérez un inventaire écrit : ce que fait chaque scénario, ce dont il dépend, ce qui se passe le jour où il tombe. La documentation est comprise dans la reprise. C’est aussi la partie qui vous permet de me remplacer, ce qui est le but.

n8n, Make ou Zapier

Deux critères tranchent, et la liste des fonctionnalités n’en fait pas partie.

Le volume. Zapier facture à la tâche et devient cher vite. Make encaisse des scénarios ramifiés pour un tarif raisonnable. n8n auto-hébergé a un coût fixe, donc il gagne mécaniquement au-delà d’un certain nombre d’exécutions mensuelles.

Ce qui circule. Des données ordinaires peuvent passer chez l’éditeur sans que ça pose de problème. Des dossiers clients, des pièces comptables ou des données de santé, c’est autre chose : là, n8n installé sur un serveur français ou chez vous est le seul montage qui tienne devant votre DSI.

J’utilise les trois. Ce qui me permet de dire quand chacun devient un mauvais choix, y compris n8n, qui demande d’entretenir un serveur là où Make n’en demande aucun.

Pour que ça ne recasse pas

Un scénario ne casse presque jamais tout seul. C’est son environnement qui bouge : un jeton expire, un éditeur change le format de son API, un champ est renommé dans le logiciel d’en face.

Ce que j’installe systématiquement sur un parc repris : une alerte sur l’échec d’exécution, et une surveillance de ce qui aurait dû se déclencher et ne s’est pas déclenché. Le second point est celui qui manque partout. Une erreur s’affiche dans l’interface et finit par se voir ; une absence ne s’affiche nulle part.

Vient ensuite la reprise des dossiers restés en attente pendant la panne, qui est souvent le vrai travail. Réparer le scénario prend une heure. Rattraper les trois semaines de commandes qui ne sont jamais parties en prend davantage.

Ce que je ne fais pas

Je ne vends pas d’abonnement de maintenance à l’année sur un parc que je n’ai pas lu. Le diagnostic vient toujours en premier, et il conclut parfois qu’il n’y a rien à surveiller parce qu’il faut tout réécrire.

Je ne promets pas de permanence 24/7. Le délai d’intervention est écrit au contrat, à la hauteur de ce qu’une personne seule peut tenir. Une activité qui exige une astreinte de nuit a besoin d’une équipe.

Et je ne conseille pas le no-code par principe. Quand un traitement doit avaler quarante mille lignes toutes les nuits, un scénario visuel est le mauvais outil, et je vous dirai d’écrire du code — ou de laisser votre éditeur le faire si son connecteur existe déjà.

Parler de votre cas

Dites-moi combien de scénarios tournent chez vous, dans quel outil, et depuis quand personne ne les a ouverts. C’est assez pour vous dire si ça vaut un diagnostic.

Décrire votre cas · Faire mesurer d’abord · Où tout ça peut tourner

Questions fréquentes

Qui peut reprendre une automatisation n8n ou Make en France ?
Trois profils s'en chargent. Les freelances no-code, rapides et peu chers, qui calent quand le problème sort du cadre de l'outil. Les agences d'automatisation, qui facturent un forfait de reprise et vous confient souvent un profil junior. Les développeurs qui pratiquent aussi le no-code, moins nombreux, capables de lire le scénario et de descendre dans le code quand le connecteur ne suffit plus. Je suis du troisième groupe. Mon profil est public sur Malt avec neuf avis notés 5 sur 5, donc vous pouvez vérifier avant d'appeler.
Combien coûte la reprise d'une automatisation existante ?
Le diagnostic prend une trentaine de minutes par scénario et vous dit ce qui est réparable, ce qui doit être réécrit et ce qui ne sert plus à rien. La réparation elle-même va de quelques heures à quelques jours selon l'état. Reprendre revient presque toujours moins cher que reconstruire, et dans le cas contraire vous l'apprenez avant de payer.
Pourquoi un scénario n8n ou Make s'arrête-t-il du jour au lendemain ?
Les causes les plus fréquentes sont banales : un jeton d'authentification expiré, une API dont l'éditeur a changé le format sans prévenir, un quota dépassé, un champ renommé dans le logiciel d'en face. Aucune ne vient de n8n ou de Make eux-mêmes. C'est pour cette raison qu'un scénario construit une fois et jamais surveillé finit toujours par tomber : ce n'est pas lui qui bouge, c'est tout ce qui l'entoure.
n8n, Make ou Zapier : lequel choisir pour une PME ?
Zapier convient aux enchaînements simples entre outils grand public, avec le tarif le plus élevé au volume. Make gère des scénarios ramifiés à un coût raisonnable et reste hébergé chez l'éditeur. n8n s'auto-héberge, ce qui le rend pertinent quand les données ne doivent pas transiter chez un tiers ou quand le volume rend l'abonnement absurde. Le critère décisif est rarement la fonctionnalité : c'est le volume mensuel et la sensibilité de ce qui circule.
Que faire quand la personne qui a créé les automatisations est partie ?
C'est la demande la plus courante sur ce terrain. Je lis ce qui tourne, je le documente au passage, et vous récupérez un inventaire écrit : ce que fait chaque scénario, ce dont il dépend, ce qui se passe s'il tombe. Beaucoup d'entreprises découvrent à cette occasion que deux ou trois scénarios ne servaient plus à rien depuis un an. La documentation fait partie de la reprise, elle n'est pas facturée en supplément.
Peut-on être prévenu automatiquement quand une automatisation tombe en panne ?
Oui, et c'est la première chose que j'installe sur un parc repris. Une alerte sur l'échec d'exécution, et une surveillance de ce qui devrait tourner et ne tourne plus, ce qui est le cas le plus dangereux. Un scénario en erreur laisse une trace dans l'interface. Un scénario qui ne démarre plus n'en laisse aucune, et personne ne le remarque avant que le mois soit passé.
Faut-il auto-héberger n8n ou utiliser la version en ligne ?
La version en ligne suffit tant que les données qui transitent sont ordinaires et que le volume reste modéré. L'auto-hébergement devient intéressant sur deux critères : des données que vous ne voulez pas voir passer chez un tiers, ou un volume où l'abonnement dépasse le coût d'un serveur. Je l'installe sur votre compte chez un hébergeur français, avec les sauvegardes et la surveillance, et les accès sont à votre nom.
Le no-code suffit-il, ou faut-il développer ?
n8n et Make couvrent la grande majorité des enchaînements entre logiciels, et les utiliser coûte bien moins cher que d'écrire le même traitement en code. La limite arrive quand un connecteur n'existe pas, quand la logique devient trop ramifiée pour rester lisible, ou quand les performances comptent. À ce moment un nœud de code dans le scénario règle souvent le problème sans tout reconstruire. Savoir où passe cette frontière est le métier.