Automatiser sans que vos données
sortent de chez vous.

La question n’est jamais « quel outil d’automatisation ». Elle est : vos données peuvent-elles transiter par un service que vous ne contrôlez pas, et à quel volume travaillerez-vous dans deux ans ?

Quand la réponse est non, ou quand le volume rend la facturation à l’usage déraisonnable, n8n devient le bon outil. Il s’installe sur votre infrastructure, il ne facture pas à l’opération, et son code est ouvert. En contrepartie il demande une compétence disponible, que la plupart des organisations n’ont pas en interne. C’est exactement ce que nous apportons.

Nous ne recommandons pas n8n par principe. Nous le recommandons quand l’arbitrage le désigne, et nous disons l’inverse quand une plateforme hébergée suffit.

C’est la première question, et elle n’est pas technique. Elle porte sur ce que vous acceptez de confier, et sur qui s’occupera de la machine.

Les trois raisons qui font pencher vers l’auto-hébergement

• La nature des données. Dossiers de santé, pièces comptables, données de ressources humaines, informations sous contrainte contractuelle. Quand une clause vous interdit de faire sortir la donnée, l’arbitrage est déjà tranché.
• Le volume. Les plateformes hébergées facturent à l’opération ou à la tâche. Un scénario de huit étapes déclenché deux mille fois par mois consomme seize mille opérations, pas deux mille. Passé un certain seuil, l’abonnement devient comparable au coût d’une infrastructure dédiée.
• La réversibilité. Un scénario n8n vous appartient, s’exporte et se réinstalle ailleurs. C’est une différence de nature avec une plateforme dont vous ne pouvez pas sortir sans reconstruire.

Les trois raisons de rester sur une plateforme hébergée

Personne en interne pour surveiller un serveur. Un volume faible, où l’abonnement coûte moins qu’une heure de maintenance mensuelle. Ou un besoin de connecteurs très spécifiques, mieux couverts ailleurs.

Nous le disons au cadrage plutôt qu’après. Vendre une installation auto-hébergée à une structure qui n’a personne pour la faire vivre, c’est vendre une dépendance de plus, pas une autonomie.

Ce que l’auto-hébergement implique réellement

Une machine à tenir à jour, des sauvegardes testées, une supervision qui alerte un humain, et une procédure de restauration que quelqu’un a déjà exécutée au moins une fois. Ce n’est pas lourd, mais ce n’est pas nul, et cela ne disparaît jamais.

C’est précisément ce que nous prenons en charge quand vous nous le confiez, et ce que nous documentons quand vous voulez le reprendre.

Toutes les tâches répétitives ne méritent pas une automatisation. Une automatisation qui fait gagner deux heures par mois et qui en demande une de maintenance n’est pas un gain, c’est un déplacement de charge.

Le calcul que nous faisons avant de construire

Trois chiffres, et ils se posent avant la première ligne de scénario. Combien de fois par mois la tâche se produit. Combien de temps elle prend à chaque fois. Et ce que coûte une erreur quand elle passe inaperçue.

Le troisième est celui qu’on oublie et celui qui décide. Une tâche rare mais dont l’erreur se paie cher mérite d’être automatisée avant une tâche fréquente et sans conséquence.

Les flux qui rendent le plus, dans notre expérience

• La création de fiche à partir de l’endroit où l’information arrive vraiment : un formulaire, une boîte partagée, un canal de discussion. Tant qu’il faut recopier, quelqu’un oubliera.
• Le rapprochement entre deux outils qui ne se parlent pas, typiquement la facturation et le suivi commercial.
• La relance, qui est la tâche la plus détestée et la moins bien faite parce qu’elle repose sur la mémoire.
• La consolidation d’un chiffre que plusieurs personnes recalculent chacune de leur côté, avec des résultats différents.

Ce que nous refusons

Automatiser un processus que personne n’a jamais écrit. Une automatisation fige la manière de faire : la construire sur un processus flou revient à graver le flou dans le marbre, et à le rendre plus difficile à corriger qu’avant.

Automatiser une décision qui demande un jugement humain. On peut préparer la décision, rassembler les éléments, alerter la bonne personne. Trancher à sa place produit des erreurs que personne ne voit passer.

C’est le point sur lequel les projets d’automatisation se distinguent le plus, et il n’apparaît dans presque aucun devis.

Une automatisation échoue toujours, un jour

Un outil connecté change son interface, un identifiant expire, un service tiers est indisponible dix minutes. Ce n’est pas une hypothèse pessimiste, c’est le fonctionnement normal d’un système qui dépend d’autres systèmes.

La question n’est donc pas d’éviter l’échec, elle est de savoir ce qui se passe quand il arrive. Une automatisation silencieuse qui tombe un vendredi soir produit des données incomplètes tout le week-end, et personne ne le découvre avant que le client ne le signale.

Notre règle, appliquée sans exception

Toute automatisation qui touche un client ou une facture lève une alerte visible par un humain, pas seulement une ligne dans un journal que personne n’ouvre.

Concrètement : une alerte dans l’outil que la personne concernée ouvre déjà, avec le nom du scénario, ce qu’il faisait, et ce qui reste à reprendre à la main. Une alerte qui dit seulement « erreur » ne sert à rien.

La reprise, qui compte autant que l’alerte

Un flux qui échoue à mi-parcours laisse un état intermédiaire. Nous concevons donc les scénarios pour qu’un nouvel essai ne produise pas de doublon, et pour que ce qui a déjà été fait ne soit pas refait. C’est invisible quand tout va bien et décisif le jour où ça casse.

Ce que nous documentons systématiquement

Chaque scénario porte un nom explicite, une description de ce qu’il fait et de ce qui se passe s’il échoue, et la liste des outils qu’il touche. Dix minutes à la construction, et la différence entre une automatisation qui survit à un départ et une qui meurt avec.

Nous livrons les trois, ce qui nous permet de recommander sans arrière-pensée commerciale. Voici l’arbitrage tel que nous le posons.

Ce que n8n gagne

La maîtrise des données, puisque tout reste chez vous. Le coût au volume, puisqu’il ne facture pas à l’opération. La réversibilité, puisque les scénarios s’exportent. Et une souplesse réelle pour les cas particuliers, parce qu’il assume qu’on écrive un peu de code quand c’est le chemin le plus court.

Ce qu’il perd

La mise en route est plus longue. Le catalogue de connecteurs est moins fourni sur les outils grand public. Et surtout, il ajoute une infrastructure à tenir, ce qui n’est pas un détail pour une structure sans compétence technique disponible.

Le seuil de bascule, en pratique

Tant que le flux se lit comme une phrase, « quand ceci arrive, fais cela, puis cela », les trois conviennent et le plus simple gagne. Dès qu’il faut écrire « sauf si », « pour chacun des éléments » ou « en attendant que », la représentation visuelle cesse d’être un confort et devient une nécessité.

Nous avons détaillé cet arbitrage, chiffres de facturation à l’appui, dans notre comparatif n8n ou Make, et la mécanique de facturation dans Make ou Zapier. La démarche complète, tous outils confondus, est décrite sur la page automatisation des processus.

C’est la contrepartie de l’auto-hébergement, et elle n’apparaît presque jamais dans les devis. Une instance n8n est un service exposé sur internet qui détient les clés de tous vos outils connectés. Sa compromission ne vaut pas la compromission d’un site vitrine.

Ce que nous mettons en place systématiquement

• Un accès restreint. L’interface d’administration n’est pas ouverte au monde entier, et l’authentification est renforcée. C’est la mesure qui coûte le moins et qui écarte l’essentiel des balayages automatiques.
• Des identifiants cloisonnés. Chaque outil connecté reçoit un compte dédié aux droits minimum, jamais le compte administrateur d’un dirigeant. Une automatisation qui lit des factures n’a pas besoin de pouvoir en supprimer.
• Des secrets stockés dans le coffre de l’outil, jamais écrits en clair dans un scénario. Un scénario s’exporte, se partage et se copie ; un identifiant qui y figure en clair voyage avec lui.
• Des sauvegardes testées, portant à la fois les scénarios et leur historique d’exécution. Une sauvegarde jamais restaurée n’est pas une sauvegarde, c’est une hypothèse.
• Une supervision qui alerte un humain quand l’instance ne répond plus, pas seulement quand un scénario échoue.

La mise à jour, qui est le vrai sujet dans la durée

Un logiciel auto-hébergé ne se met pas à jour tout seul, et c’est la différence de fond avec une plateforme hébergée. Les correctifs de sécurité s’appliquent, ou ils ne s’appliquent pas. Dans le second cas l’instance continue de fonctionner normalement, ce qui est exactement le piège : rien ne signale le retard, jusqu’au jour où une faille connue est exploitée.

Nous appliquons donc un rythme fixé plutôt qu’un traitement au gré des alertes, avec un environnement de test avant la production quand le nombre de scénarios le justifie. Un correctif critique fait exception et s’applique sans attendre.

Ce qui se passe si l’instance tombe

Les déclenchements manqués ne se rattrapent pas d’eux-mêmes. Nous concevons donc les scénarios pour qu’une reprise ne produise pas de doublon, et nous documentons ce qui doit être repris à la main. C’est invisible quand tout va bien et décisif le jour où ça casse.

Qui porte tout cela

Si personne n’est disponible en interne, nous le portons, et c’est une ligne distincte chiffrée sur le nombre de scénarios en production. Si quelqu’un l’est, nous le formons et nous lui laissons la procédure écrite. Ce que nous refusons, c’est l’entre-deux : une instance livrée à une équipe qui n’a ni le temps ni la procédure finit toujours par se dégrader en silence.

Comparer deux devis d’automatisation n’a aucun sens tant qu’on ne sait pas ce que chacun inclut. Voici notre découpage.

Ce qui est toujours compris

• La cartographie de ce qui se passe réellement, pas de ce que le processus théorique prévoit.
• L’arbitrage entre auto-hébergement et plateforme, écrit, avec ses conséquences.
• La construction, les tests, la gestion des erreurs et les alertes.
• La documentation en français et la formation de la personne qui reprendra la main.

Ce qui se chiffre à part

L’hébergement de l’instance, qui est à votre nom et dépend de votre volume. Les abonnements aux outils connectés, pour la même raison. Et les développements spécifiques, quand un outil métier ne propose aucun moyen standard de se connecter.

Nous les sortons du forfait volontairement. Les y inclure permettrait d’afficher un prix plus rond, au prix d’un arbitrage que vous ne verriez pas passer.

La supervision dans la durée

Une instance auto-hébergée demande quelqu’un qui la surveille. Si personne n’est disponible en interne, cela fait partie de ce que nous prenons en charge, et c’est une ligne distincte, chiffrée sur le nombre de scénarios en production plutôt que sur un forfait indifférencié.