Automatiser sans usine à gaz : par où commencer avec Make ou n8n

Il y a un moment précis où une équipe comprend qu'elle a un problème d'automatisation : quelqu'un recopie pour la centième fois une ligne d'un outil vers un autre, un devis part avec une erreur de saisie, un lead attend trois jours une réponse qui aurait dû partir en trois minutes. La réaction naturelle est de vouloir tout automatiser d'un coup. C'est exactement ainsi qu'on construit une usine à gaz : des dizaines de scénarios enchevêtrés que plus personne ne comprend six mois plus tard, et qui cassent en silence.

L'automatisation utile fonctionne à l'inverse : un flux, bien choisi, bien cartographié, mis en production, surveillé. Puis un deuxième. Voici la méthode que nous appliquons chez DL Consulting.

1. Repérer les tâches qui coûtent réellement

Toutes les tâches répétitives ne méritent pas d'être automatisées. Le bon candidat combine trois caractéristiques : il revient souvent, il suit des règles stables, et son erreur a une conséquence visible (un client mécontent, une facture fausse, un lead perdu). Une tâche pénible mais rare, ou dont les règles changent chaque semaine, est un mauvais premier chantier.

L'exercice concret tient en une semaine : demandez à chaque personne de l'équipe de noter, pendant cinq jours, les gestes qu'elle répète et le contexte dans lequel ils arrivent. Pas d'estimation en pourcentage, pas de chiffre sorti d'un tableur : des faits. « Chaque matin, j'exporte le CSV du CRM et je le recolle dans le tableau de suivi. » « À chaque demande entrante, je crée un dossier, je préviens le commercial, j'ajoute une ligne. » Ces phrases sont vos candidats.

Le filtre de priorisation

• Fréquence : quotidien ou pluri-quotidien plutôt que mensuel.
• Stabilité : les règles n'ont pas changé depuis plusieurs mois.
• Périmètre : la tâche traverse au maximum deux ou trois outils.
• Conséquence : une erreur se voit et coûte quelque chose.
• Propriétaire : une personne identifiée pourra valider le résultat.

2. Cartographier le flux AVANT de toucher à un outil

C'est l'étape que tout le monde saute, et c'est celle qui décide du résultat. Avant d'ouvrir Make ou n8n, écrivez le flux tel qu'il existe : quel événement le déclenche, quelles données entrent, quelles décisions sont prises, quelles exceptions existent, où il se termine.

1. 01Le déclencheur : un formulaire soumis, un e-mail reçu, une ligne créée, une heure fixe.
2. 02Les données : quels champs, dans quel format, avec quelles valeurs obligatoires.
3. 03Les décisions : les « si / alors » que la personne prend aujourd'hui de tête.
4. 04Les exceptions : les cas où la personne sort du process — ce sont eux qui font casser les automatisations.
5. 05La sortie : ce qui doit exister à la fin, et qui doit être prévenu.

Cette cartographie révèle presque toujours deux choses : une partie du process est inutile et peut simplement disparaître, et une autre partie repose sur un savoir implicite que personne n'avait jamais écrit. Vous n'automatisez jamais un process : vous l'écrivez d'abord, vous le simplifiez ensuite, et vous automatisez ce qu'il en reste.

3. Make ou n8n : choisir sans se tromper

Les deux outils font le même métier — orchestrer des étapes entre des applications — mais ils ne s'adressent pas au même contexte.

Make

• Service hébergé : rien à installer, rien à maintenir.
• Interface visuelle très lisible, prise en main rapide par une équipe non technique.
• Large catalogue de connecteurs prêts à l'emploi.
• Tarification à l'opération : le coût suit le volume, ce qui devient un sujet quand les scénarios tournent en boucle.
• Vous dépendez d'un tiers pour l'hébergement de vos données de transit.

n8n

• Disponible en cloud ou auto-hébergé sur votre infrastructure.
• Nœuds de code (JavaScript / Python) : la flexibilité va beaucoup plus loin dès que la logique se complique.
• Auto-hébergement : maîtrise de la donnée, coût lié au serveur plutôt qu'au volume d'exécutions.
• Demande une compétence technique pour l'installation, les mises à jour et les sauvegardes.
• Versionnable et scriptable, donc adapté à une logique d'actif durable.

Règle simple : si votre équipe est non technique et que le volume reste modéré, commencez sur Make. Si vous avez une contrainte de confidentialité des données, un volume élevé, ou une logique métier qui déborde du glisser-déposer, allez sur n8n auto-hébergé. Et n'ayez pas peur de mélanger : beaucoup d'organisations gardent Make pour les flux marketing simples et n8n pour les flux métier sensibles.

4. Un seul flux, jusqu'en production

Le premier chantier doit être fini, pas large. Choisissez le flux qui coûte le plus dans la liste, construisez-le, faites-le tourner en parallèle du process manuel pendant quelques jours, comparez les résultats, puis coupez le manuel. Cette période de double run est ce qui crée la confiance de l'équipe : elle voit que la machine produit la même chose qu'elle, sans oubli.

Documentez au passage, dans le scénario lui-même : nommez les modules en langage métier, pas « HTTP Request 3 ». Un flux qu'on ne peut pas relire est un flux qu'on ne pourra pas réparer.

5. Brancher ses outils : l'API plutôt que le bricolage

Un connecteur natif est confortable, mais il ne couvre jamais tout. Dès qu'un champ manque, passez par l'API de l'outil via un appel HTTP : c'est presque toujours plus stable qu'un contournement par e-mail, scraping ou export de fichier. Trois réflexes valent d'être pris tout de suite : stocker les clés d'API dans le gestionnaire de secrets de la plateforme et jamais en dur dans un module, gérer explicitement les erreurs et les limites de débit, et prévoir l'idempotence — c'est-à-dire faire en sorte qu'une exécution rejouée deux fois ne crée pas deux fois la même donnée.

6. Quand ajouter un agent IA

Un modèle de langage n'a rien à faire dans un flux dont les règles sont déterministes. « Si le montant dépasse X, envoyer au manager » ne demande pas d'IA : ça demande une condition. L'IA devient pertinente exactement là où la règle est impossible à écrire : comprendre une demande formulée en texte libre, extraire des informations d'un document non structuré, résumer un échange, classer une intention, rédiger un premier jet.

Dans ce cas, encadrez-le : demandez une sortie structurée (JSON) plutôt que du texte libre, validez cette sortie avant de l'écrire dans un système, et gardez un humain dans la boucle sur les décisions à conséquence. L'agent propose, la personne valide — au moins tant que le taux d'erreur n'est pas connu.

7. Les pièges qui coûtent le plus cher

• Sur-automatiser : automatiser un process qu'il aurait fallu supprimer. On accélère alors le mauvais geste.
• Absence de monitoring : sans alerte sur les exécutions en échec, une automatisation casse et personne ne le sait avant qu'un client le signale.
• Le scénario monolithe : un flux de soixante modules qui gère cinq cas différents. Découpez en flux courts, appelés les uns par les autres.
• L'automatisation orpheline : elle a été construite par une personne qui est partie, sans documentation ni accès partagés.
• Les données de test en production : testez avec des jeux dédiés, sinon vous enverrez un vrai e-mail à un vrai client.

Commencez petit, mesurez, étendez

Un flux en production qui tourne tous les jours et que l'équipe comprend vaut mieux que dix scénarios ambitieux à moitié finis. Prenez la tâche la plus coûteuse, écrivez-la, simplifiez-la, automatisez-la, surveillez-la. Puis recommencez. C'est lent la première semaine, et c'est ce qui fait tenir le système au bout d'un an.