n8n, Make et Zapier : hébergement, journaux, reprise et agents

Un comparatif n8n, Make et Zapier ne devrait pas commencer par « lequel est le meilleur ? », mais par « que se passe-t-il lorsque le flux échoue ? ». Un scénario qui déplace une donnée ou envoie un message peut sembler simple ; il devient risqué lorsqu’il reçoit deux fois le même événement, perd un identifiant ou utilise un compte trop puissant. Verdict rapide : pour débuter, retenez l’outil qui vous permet de construire un flux petit, de lire ses journaux et de l’arrêter sans ambiguïté. Pour un usage d’équipe, ajoutez des rôles, des revues et une procédure de reprise avant de connecter des services réels.

Cette page est le duel entre n8n, Make et Zapier. Le choix entre un outil visuel, un workflow versionné et un script reste sur le guide de méthode. Les quotas et les connecteurs se relisent sur les sites officiels au moment de la décision. La section du 2026-10-18 ne recopie aucun prix : un montant non figé sur la page tarifaire est écrit « à vérifier ». Une éventuelle mention affiliée sur Vibarche devra être identifiable et ne remplacera jamais l’analyse des droits, des erreurs ou du coût total.

Mise à jour du 2026-10-18 : n8n, Make et Zapier

Cette section reprend les docs officielles lues le 2026-10-18. Aucun flux n’a été exécuté pour l’écrire, et la lecture ne classe pas les outils. Les pages tarifaires ont été ouvertes le même jour. Le montant affiché dépend du cycle de facturation et du volume choisi, donc aucun prix n’est recopié. Chaque montant reste à vérifier.

Hébergement

n8n documente deux façons de tourner. Cloud est géré par n8n. L’autre s’installe sur votre infrastructure, sur site ou dans un cloud privé. La page d’installation cite Docker Compose, un script en une ligne, et des guides pour quelques fournisseurs. Sans clé de licence, l’instance est en édition Community. Une clé Business ou Enterprise change l’édition. S’enregistrer ouvre, toujours gratuitement, des dossiers, le debug dans l’éditeur et des données d’exécution personnalisées. La page « Choose how to use n8n » nomme Starter, Pro et Enterprise pour Cloud, et Community, Registered Community, Business et Enterprise pour l’auto-hébergement. Elle dit que le journal courant est inclus, et que le streaming de logs, le SSO, les projets et le contrôle de version Git demandent un plan payant. La page tarifaire, relue le même jour, affiche aussi un bloc Business. La correspondance exacte entre ces deux pages est à vérifier avant de choisir une édition.

Le guide Héberger n8n sur un VPS sert si vous installez vous-même. Il sépare l’installation de l’exposition publique. Il ne remplace pas la doc de la version que vous lancez.

Make, sur les pages relues, ne décrit pas l’installation de son moteur sur un serveur à vous. L’agent sur site est un autre objet. C’est un programme Enterprise, installé sur votre machine, pour que les scénarios Make atteignent des applications locales sans modifier le pare-feu. Les scénarios restent exécutés chez Make. Si l’agent ne répond plus, Make le vérifie toutes les quatre minutes. Les scénarios associés continuent, et le module qui passe par l’agent renvoie une erreur 500.

L’aide Zapier relue décrit un service de compte, avec un historique et des rôles. Elle ne décrit pas l’installation du moteur sur une machine à vous. La page tarifaire parle d’« advanced deployment options » pour Enterprise, sans dire dans le texte extrait si cela veut dire un hébergement chez vous. Ce point est à vérifier.

Journaux

n8n distingue l’exécution manuelle, lancée depuis l’éditeur, et l’exécution de production, lancée par un déclencheur publié. Sur un plan payant, seules les exécutions de production comptent dans le quota. Un appel manuel, un sous-workflow et un workflow d’erreur n’y comptent pas. On peut masquer les données d’exécution. Le statut, la durée et les noms de nœuds restent visibles, pas le contenu des entrées ni des sorties. Le propriétaire ou l’admin peut imposer ce masque à toute l’instance. Révéler une donnée masquée s’inscrit dans l’audit si le streaming de logs est branché. Le masque ne chiffre pas la base. Quelqu’un qui lit la base directement voit les données. Un console.log dans un nœud Code n’est pas masqué.

Le tableau de la page tarifaire n8n, relu le 2026-10-18, affiche une rétention maximale des journaux d’exécution de 7 jours en Starter, 30 jours en Pro, et sans limite en Enterprise. La colonne Business n’y figurait pas. Sa durée est à vérifier. Le streaming vers un système externe est listé dans le bloc Enterprise de cette page, alors que la page de choix de déploiement dit seulement « plan payant ». L’édition exacte qui l’ouvre est à vérifier.

Dans Make, l’historique d’un scénario montre la date, le statut, la durée, les opérations, les crédits consommés, le volume transféré, puis le détail des bundles. L’export CSV est documenté. Le nombre de jours conservés dépend du plan. L’aide renvoie au tarif et ne donne pas de chiffre, donc la durée est à vérifier. La recherche plein texte dans les sorties de modules est indiquée à partir de Pro. Elle ne voit que les exécutions lancées après la montée de plan. « Keep data confidential » arrête la conservation de la charge utile. Le journal indique encore qu’un run a eu lieu, sans la charge utile. Les journaux d’audit, sur Enterprise seulement, sont gardés 12 mois. Les owners et admins d’organisation y accèdent, ainsi que les admins d’équipe.

Zap history liste les runs, leur statut, et jusqu’à 10 000 entrées. L’aide dit qu’elle ne garantit pas plus de 60 jours de données de run. La page légale de conservation, dont la mise à jour indiquée est le 17 avril 2026, donne d’autres délais pour le contenu et les métadonnées des Zaps : 7 jours dans les logs, 29 à 69 jours dans le compte, jusqu’à 4 mois dans les sauvegardes. On ne peut pas en déduire un seul délai. Effacer un run déjà réussi, filtré, en attente ou arrêté n’annule pas l’action faite. Effacer un run encore en cours l’empêche de finir. Sur Team et Enterprise, les admins et owners voient l’usage de tous les Zaps. Un membre ne voit que les siens et ceux qui lui sont partagés.

Reprise

Un workflow n8n peut désigner un workflow d’erreur. Celui-ci doit commencer par un Error Trigger. La charge reçue contient execution.retryOf quand le run est lui-même une reprise. La page des exécutions relue ce jour dit que ces runs de workflow d’erreur ne comptent pas dans le quota. Pour débugger, la page « Debug executions » dit de charger les données d’un échec dans l’éditeur avec « Debug in editor », puis de relancer là, avec ces données. Une URL de doc tentée pour un rejeu en place a répondu 404. Les boutons de reprise hors éditeur sont à vérifier.

Make, avec « Store incomplete executions », range le run raté pour le reprendre. Sans ce réglage, le run s’arrête et passe en rollback. Le handler Retry sort le bundle en échec, garde l’erreur et la suite du scénario, puis relance tout seul ou attend. Il exige les exécutions incomplètes. ConnectionError et RateLimitError sont déjà retentés si ces exécutions sont activées, sans ajouter ce handler. Une reprise d’exécution incomplète ne part que si le scénario est actif, avec la configuration du moment de l’erreur. Une erreur de données ou de runtime demande souvent une correction, pas un nouveau passage à l’identique. Les versions enregistrées d’un scénario sont gardées 60 jours, sauf la dernière, gardée jusqu’à la suivante. Make peut aussi proposer de récupérer des changements non enregistrés après une session coupée.

Zapier rejoue les étapes en statut errored, à la main ou par autoreplay. L’autoreplay tente jusqu’à 5 fois. Les écarts lus sur la page sont 5 minutes, puis 30 minutes, 1 heure, 3 heures et 6 heures. Le Zap doit être allumé, le compte doit avoir assez de tasks, et le rejeu doit partir dans les 60 jours du déclencheur. Filter et Paths ne sont pas rejoués. Un rejeu d’erreur ne relance pas les étapes déjà réussies. Rejouer tout le run, étapes réussies comprises, est documenté à part, et chaque étape réussie recompte des tasks. Zapier écrit qu’il tente le rejeu sans garantir le succès. Sur le plan Free, le rejeu manuel vu sur cette page est limité aux runs en erreur. Rejouer un run on hold à la main demande un plan payant. Activer l’autoreplay pour tout le compte, sur Team ou Enterprise, demande un super admin ou l’owner.

Un error handler Zapier est un chemin alternatif, pas un retry du même pas. La page le liste sur Free, Professional, Team et Enterprise, puis écrit qu’en redescendant sur Free on ne peut plus en ajouter, et qu’un Zap qui en contient s’éteint. Ces deux phrases sont sur la même page. Une fois publié, l’autoreplay de ce Zap est coupé. L’autoreplay du compte, lui, ne bouge pas. On ne peut pas rejouer à la main un run qui a un error handler. On peut rejouer le run entier.

Permissions

Les rôles d’instance n8n lus ce jour sont Owner, Admin et Member. Admin est documenté sur Cloud Pro, Cloud Enterprise, et l’Enterprise auto-hébergé. Le owner voit et peut modifier tous les workflows. La doc lui conseille un second compte Member pour construire, parce qu’on ne voit pas qui a créé un workflow. Les rôles de projet limitent un espace. Editor est indiqué pour Cloud Pro et l’Enterprise auto-hébergé. Viewer est indiqué pour Cloud Enterprise et l’Enterprise auto-hébergé. Des rôles d’instance personnalisés sont documentés. LDAP, SAML et OIDC ont leurs pages. La doc renvoie encore à la page tarifaire pour savoir quelle édition ouvre quelle fonction.

Chez Make, scénarios, connexions, webhooks, clés et data stores appartiennent à une équipe. On ne change pas l’équipe d’un objet. Sous le plan Teams, l’organisation n’a qu’une équipe et ne gère pas les rôles. Team Admin gère les membres et peut supprimer l’équipe. Team Member édite les ressources sans gérer les membres. Team Operator lit, et peut activer, arrêter ou planifier. Team Monitoring lit, journaux compris, sans faire tourner les scénarios. Team Guest ne traite que les demandes d’identifiants qui lui sont adressées. Les owners et admins de l’organisation ont toujours les droits Team Admin. Créer l’agent sur site demande un rôle d’organisation Owner, Admin ou App dev.

Zapier Team a owner, admin et member. Enterprise ajoute super admin. Il n’y a qu’un owner. L’audit log est pour le super admin et l’owner. Un admin invite, retire des membres et gère l’accès aux apps, y compris pour Agents. Il ne voit pas l’audit log. Sur un asset, owner, editor et viewer ne font pas les mêmes gestes. Viewer n’existe que pour Canvas, Tables et Agents. Une connexion privée empêche les autres de modifier l’étape, même s’ils ont le Zap. Ils peuvent quand même lire ce qui traverse l’historique de cette étape.

Agents

Un agent n8n est un objet du projet, à côté des workflows. Il a un modèle, des instructions, des outils, et il peut exiger une approbation avant un outil sensible. Un tour de conversation compte comme une exécution, dans le même quota que les workflows. La page auto-hébergée relue dit que les agents sont là à partir de n8n 2.32.3 sur tous les plans auto-hébergés sauf Enterprise, et que le support Enterprise auto-hébergé n’est pas encore là. Le mode queue n’est pas pris en charge pour les agents. La base de fichiers en auto-hébergé est en preview et demande un sandbox Daytona. La page tarifaire Cloud, relue le même jour, liste « Agents, MCP and AI nodes » dans Starter. Les deux pages ne décrivent pas le même périmètre. Le branchement MCP est traité dans MCP et n8n.

L’agent Make vit dans le scénario. Le fournisseur d’IA de Make est indiqué sur tous les plans. Les autres fournisseurs sont indiqués sur les plans payants. Les outils peuvent être des modules, des scénarios ou des serveurs MCP. Une connexion de secours est documentée si la connexion principale échoue. Le délai d’étape lu sur la page du module est de 300 secondes par défaut, 600 au maximum. Le coût en tokens ou en crédits n’est pas un prix de plan. Il est à vérifier.

Zapier documente encore des agents sur agents.zapier.com : instructions, déclencheur, actions, sources, puis publication. Cette page dit qu’ils consomment des activities, pas des tasks de Zap, et qu’un admin ou l’owner Enterprise doit ouvrir l’accès au compte. Une autre page, relue le même jour, dit que Zapier migre ces agents vers une étape AI by Zapier dans l’éditeur. Cette étape peut demander une approbation avant chaque outil, et ses runs apparaissent dans Zap history. Elle est facturée en tasks. Un run qui dépasse 75 tasks se met en pause pour relecture. Les sources de connaissance des agents ne sont pas encore reprises dans AI by Zapier. La page de migration les annonce pour le troisième trimestre 2026. La date de cette lecture, le 2026-10-18, est postérieure à ce trimestre, et la page n’a pas été recoupée avec une annonce plus récente. Le report est à vérifier. Le calendrier de la même page place la fin des essais Enterprise au 15 août 2026, donc avant cette lecture. Ce qu’il reste de ces comptes ensuite n’y est pas redit. Les deux descriptions coexistent dans l’aide. Un compte ouvert après le 15 août 2026 peut encore tomber sur l’une ou l’autre.

La page légale Zapier, datée du 17 avril 2026, dit que les conversations et journaux d’activité d’un agent restent dans le compte jusqu’à la suppression de l’agent, puis jusqu’à 4 mois dans les sauvegardes. Supprimer l’agent ne retire pas ce qui a déjà été envoyé vers un workflow ou une table.

Prix

Pages ouvertes le 2026-10-18 : n8n, Make et Zapier. Aucun montant n’est recopié. Chaque prix est à vérifier.

Pages relues le 2026-10-18

Présentation : ce qu’un outil d’automatisation fait réellement

Un outil d’automatisation relie un déclencheur à une ou plusieurs actions. Le déclencheur peut être manuel, planifié, issu d’un webhook ou produit par un service connecté. Les actions peuvent créer un enregistrement, envoyer un e-mail, appeler une API ou modifier un fichier. Entre les deux, on trouve généralement un filtrage, une transformation de données, une condition, une validation ou un délai.

Les produits peuvent proposer des interfaces très différentes, mais les questions de fond sont stables : quelles données entrent dans le flux, qui peut le modifier, avec quel compte il agit, quelles traces il laisse et comment éviter une répétition. Le bon outil n’est donc pas nécessairement le plus riche en intégrations ; c’est celui dont les contrôles correspondent au risque de votre action.

Tableau comparatif pour évaluer chaque outil

Critère	Question à poser	Vérification pratique
Déclencheur	Est-il manuel, planifié, webhook ou événement ?	Rejouer une entrée de test
Intégrations	Quels comptes, données et scopes sont requis ?	Lire les permissions avant connexion
Transformation	Les formats invalides sont-ils gérés ?	Envoyer une entrée volontairement incomplète
Journal	Peut-on voir l’entrée, l’étape et l’erreur ?	Ouvrir un historique d’exécution
Reprise	Retry, reprise manuelle, anti-doublon ?	Couper une étape de test
Gouvernance	Qui crée, modifie, valide et désactive ?	Vérifier les rôles disponibles
Export	Peut-on récupérer la configuration ?	Exporter un scénario non sensible
Coût	Quotas, dépassements et utilisateurs ?	Relever la page officielle datée

Ce tableau ne donne pas un score. Un flux personnel de notification accepte d’autres compromis qu’un workflow qui synchronise un CRM, gère une facture ou ouvre un ticket de sécurité. La ligne « à vérifier » est une sortie acceptable : elle montre qu’une décision manque de preuve plutôt que d’inventer une propriété.

Cas d’usage selon le profil

Débutant : apprendre sans créer d’effet irréversible

Commencez par une notification interne ou une copie de données fictives. Utilisez un compte de test, une boîte e-mail de test et un canal privé. N’automatisez ni paiement, ni suppression, ni envoi client à la première tentative. Votre objectif est d’observer la différence entre un déclencheur, une donnée, une condition et une action, puis de savoir retrouver le journal quand quelque chose ne se passe pas comme prévu.

Freelance ou petite équipe : gagner du temps sans perdre le contrôle

Nommez le workflow, son propriétaire, les comptes qu’il utilise et sa finalité. Ajoutez une étape de validation humaine avant l’action qui sort de votre système : publication, e-mail, création de facture ou modification de données. Une automatisation fiable doit être désactivable rapidement. Testez aussi ce que fait la plateforme si une API externe répond lentement ou renvoie une erreur.

Équipe technique : intégrer un workflow au produit

Séparez les environnements de test et de production. Employez des identifiants de service avec le minimum de permissions, conservez les secrets hors des exports et définissez l’idempotence : la même entrée ne doit pas produire deux fois la même action. Dans beaucoup de cas, un workflow reçoit un webhook ; gardez donc un identifiant d’événement, une trace et une stratégie de rejeu. Le no-code ou low-code n’exonère pas de ces règles d’intégration.

Avantages et limites des approches courantes

Une plateforme d’automatisation hébergée réduit la maintenance de l’infrastructure et peut accélérer un prototype. Vérifiez cependant les limites d’exécution, les régions, les journaux et les possibilités d’export. Une solution auto-hébergée peut offrir davantage de contrôle sur le réseau et les données, mais exige que quelqu’un applique les mises à jour, sauvegarde la configuration et surveille l’instance. Un outil intégré à un SaaS peut être le plus simple pour un flux local, mais il peut réduire votre capacité à relier d’autres services ou à migrer.

Le compromis utile n’est pas « cloud contre serveur », mais « responsabilités assumées contre responsabilités déléguées ». Une équipe sans personne pour exploiter un serveur devrait éviter d’adopter un outil auto-hébergé uniquement parce qu’il semble moins cher. Inversement, une équipe ayant des exigences fortes de réseau ou de données doit vérifier qu’une plateforme hébergée couvre réellement ses contraintes avant de la connecter.

Tutoriel : comparer trois outils avec le même scénario

Étape 1 : dessiner le flux minimum

Écrivez sur une ligne : « quand un formulaire de test est reçu, valider le champ e-mail, créer une ligne fictive et notifier un canal de test ». Ajoutez l’action interdite : « ne pas envoyer de message à un client ».

Vérification : le résultat attendu est observable et l’action externe reste confinée à vos comptes de démonstration.

Étape 2 : connecter le minimum de permissions

Créez un compte ou un projet de test par service. Refusez les scopes superflus. Si l’outil demande un accès administrateur pour une simple lecture, documentez ce point comme un risque, ne l’ignorez pas.

Vérification : vous pouvez expliquer chaque autorisation accordée et la supprimer après l’essai.

Étape 3 : réaliser un cas nominal

Lancez une entrée valide puis notez les étapes visibles dans le journal. Mesurez le temps de mise en place, mais aussi le nombre de réglages cachés et d’opérations manuelles nécessaires.

Vérification : une seconde personne peut identifier l’entrée, le résultat et le propriétaire du flux sans vous demander où chercher.

Étape 4 : simuler deux erreurs

Envoyez une donnée invalide, puis rendez le service cible indisponible ou retirez son accès de test. Vérifiez que l’erreur est visible, que le flux ne tourne pas sans fin et qu’une reprise ne duplique pas l’enregistrement.

Vérification : vous savez distinguer un échec définitif d’une reprise autorisée et pouvez arrêter le flux.

Étape 5 : contrôler la sortie et le changement

Exportez la configuration si le produit le permet. Désactivez le workflow puis vérifiez qu’aucune exécution planifiée ne reste active. Notez ce qui serait nécessaire pour recréer le flux ailleurs.

Vérification : vous détenez au moins une description complète du scénario, de ses comptes et de ses variables non secrètes.

Problèmes fréquents et solutions

Le même événement produit deux actions

Ajoutez un identifiant d’événement, une condition d’existence ou une étape de déduplication. Ne supposez pas qu’un webhook est livré une seule fois : testez le rejeu avec une entrée fictive.

Le workflow échoue sans explication claire

Cherchez un journal d’exécution, un champ de réponse et l’étape précise concernée. Si l’outil ne rend pas ce diagnostic accessible au niveau dont vous avez besoin, réduisez son périmètre ou choisissez une autre approche.

Une personne part et plus personne ne peut modifier le flux

Évitez les comptes personnels comme unique propriétaire. Ajoutez un compte d’équipe, documentez les connexions et testez la reprise d’accès avant l’incident.

Les coûts deviennent imprévisibles

Mesurez les exécutions, les branches et les données traitées lors d’un mois de test. Vérifiez les limites actuelles chez l’éditeur ; ne basez pas un budget sur une ancienne capture ou une offre promotionnelle.

FAQ

Quel est le meilleur outil d’automatisation ?

Celui qui permet de réaliser votre scénario avec des permissions minimales, des journaux lisibles, une reprise contrôlée et une sortie documentée.

Puis-je automatiser une action irréversible ?

Seulement avec une validation, un propriétaire, une trace et une stratégie de retour proportionnés au risque. Commencez par une simulation.

Faut-il choisir un outil auto-hébergé ?

Seulement si vous avez une raison concrète et la capacité de maintenir sécurité, sauvegarde, mises à jour et supervision. L’auto-hébergement n’est pas une garantie de simplicité ou d’économie.

Comment éviter de donner trop de droits ?

Utilisez des comptes de test, des scopes limités, des identifiants de service et une revue de chaque connexion avant activation.

Peut-on choisir via un lien d’affiliation ?

Un lien commercial éventuel doit être déclaré, mais il ne remplace pas l’essai, les permissions et la vérification des conditions actuelles.

Recommandation finale

Comparez n8n, Make et Zapier en faisant échouer le même petit flux dans chacun d’eux. Le bon candidat est celui dont vous comprenez les droits, les traces, les erreurs et l’arrêt. La section du 2026-10-18 ne choisit pas à votre place. Elle dit ce que les docs écrivaient ce jour-là. Cette méthode donne un choix défendable selon votre budget et votre niveau technique, sans transformer un tableau marketing en décision d’architecture.

Sources et limites

Les connecteurs, limites et plans évoluent. Les URL précises relues le 2026-10-18 sont dans la section de cette date. Cet article est une méthode de sélection plus une lecture datée, pas un benchmark, un prix ou une recommandation rémunérée.