Automatiser son CRM avec Make en 30 minutes

Oui, trente minutes suffisent pour brancher un premier scénario : un lead arrive, un email part, une tâche se crée, l'équipe est prévenue. C'est vrai, et tous les articles s'arrêtent là.

Ce qu'ils ne disent pas, c'est ce qui se passe entre ce premier scénario et un système sur lequel une activité repose vraiment. Voici cette partie-là, à partir d'un pipeline qui traite aujourd'hui des dizaines de milliers de lignes par jour sans surveillance — et qui a commencé, lui aussi, par trente minutes de branchements.

Les trente premières minutes, sans détour

Le premier scénario utile tient en quatre blocs, et le choix de la plateforme importe peu à ce stade : Make, n8n et Zapier font tous les trois la même chose ici.

Un déclencheur — l'arrivée d'une ligne dans une base ou un formulaire rempli. Une vérification — l'email est-il valide, l'entreprise est-elle déjà connue. Une écriture dans le CRM. Une notification à qui doit agir.

Branchez ça, envoyez-vous un cas de test, vérifiez que la ligne arrive au bon endroit. C'est fait, et ça vous fera gagner du temps dès la première semaine.

Maintenant la question qui décide de tout le reste : que se passe-t-il quand ce scénario s'arrête et que personne ne le remarque ?

Ce qui casse réellement

Quatre pannes, relevées sur six mois de production. Aucune n'était prévisible en lisant la documentation.

Un jeton d'authentification expiré : quatre jours d'arrêt. Le scénario ne plantait pas. Il tournait, recevait des refus, les enregistrait, et ne signalait rien. Le coût n'est pas la panne, c'est le délai de découverte.

Un verrou bloqué par un fil d'exécution mort : dix heures. Le processus était vivant au sens du système, mais ne progressait plus. Aucune alerte ne se déclenche sur un processus vivant.

La mémoire épuisée sur un traitement lancé d'une traite : un traitement national perdu. L'écriture n'intervenait qu'à la fin ; il n'y avait rien à récupérer.

Les pare-feux applicatifs des sites visités : 362 refus en 48 heures. Celle-là n'est pas réparable, c'est une limite à intégrer dans les prévisions.

Le point commun des trois premières : elles sont silencieuses. Un scénario d'automatisation ne vous prévient jamais qu'il ne sert plus à rien.

Du script au système : sept changements

Voici ce qui a réellement changé entre la première version et celle qui tourne aujourd'hui. Aucun de ces points ne concerne la logique métier — elle n'a pas bougé.

Ce sont les trois lignes qui se règlent dans l'outil no-code lui-même. Les quatre autres — quotas d'API, budget par adresse IP, hébergement, volume — relèvent de l'infrastructure et sont détaillées dans l'étude de cas.

Relisez la colonne de gauche : c'est exactement ce que produit un tutoriel de trente minutes. Rien n'y est faux. C'est simplement une première version, et la confondre avec un système est ce qui fait perdre quatre jours à quelqu'un.

La règle des trente minutes

De tous ces changements, un seul mérite d'être fait le jour même : surveiller la progression, pas l'exécution.

La différence est essentielle. Surveiller l'exécution répond à « le scénario tourne-t-il ? » — et la réponse est oui, y compris quand il ne produit plus rien depuis quatre jours. Surveiller la progression répond à « le compteur a-t-il avancé depuis trente minutes ? », qui est la seule question utile.

Concrètement : un compteur incrémenté à chaque ligne traitée, une vérification périodique, une alerte si le compteur n'a pas bougé. Un quart d'heure de mise en place, qui aurait économisé quatre jours.

Ajoutez-y un chien de garde qui redémarre le service au-delà d'un délai sans progression, et la majorité des pannes se règlent sans vous.

Traduire ces quatre pannes en réglages Make et n8n

Chacune des pannes ci-dessus correspond à un réglage précis, disponible dans l'interface des deux plateformes. Aucun ne figure dans les tutoriels de trente minutes ; aucun ne demande d'écrire du code.

Contre le jeton expiré : sortir la surveillance du scénario surveillé. Les notifications d'erreur natives ne servent à rien ici — un scénario qui collectionne des refus ne « plante » pas, donc rien ne se déclenche. Le montage qui tient : le scénario principal horodate chaque lot traité, dans un data store côté Make ou une table côté n8n, et un second scénario, planifié et totalement indépendant, lit cet horodatage. Plus vieux que trente minutes : message sur votre téléphone. Une surveillance logée dans le scénario qu'elle surveille meurt avec lui.

Contre le verrou : un délai maximal d'exécution. Un traitement suspendu reste « en cours » aux yeux de la plateforme, indéfiniment. Dans n8n, les réglages du workflow permettent de fixer un timeout : au-delà, l'exécution est tuée et comptée en échec — ce qui, cette fois, déclenche bien une alerte. Make interrompt de lui-même les exécutions trop longues, ce qui joue le même rôle sans réglage. Un traitement tué se relance ; un traitement suspendu attend qu'on le remarque.

Contre la mémoire : des lots plafonnés, l'écriture à l'intérieur. Dans n8n, le nœud Loop Over Items découpe le flux en paquets de taille fixe — et le module d'écriture se place dans la boucle, jamais après elle. Dans Make, le déclencheur planifié limite le nombre d'enregistrements pris à chaque passage, avec un pointeur stocké pour reprendre au bon endroit. La panne qui avait englouti un traitement national ne coûte plus que le paquet en cours.

Contre les refus de pare-feu : une reprise qui sait renoncer. Les deux plateformes savent retenter automatiquement un module en échec. Ce réglage doit distinguer deux cas que l'interface confond : l'erreur passagère — un délai réseau, retenter ne coûte rien — et le refus délibéré d'un site qui a détecté la visite. Retenter face à un 403, c'est insister auprès d'un domaine qui vous a repéré, et le perdre définitivement. Les 362 refus essuyés en 48 heures sur le pipeline n'ont jamais été retentés : ils ont été comptés, puis intégrés à la prévision.

Une heure de réglages en tout, sur l'un ou l'autre outil. En face, ce qu'ils auraient évité : quatre jours, dix heures, un traitement national.

Make, n8n ou Zapier : le vrai critère

Le comparatif habituel oppose le prix et la simplicité. Ce n'est pas ce qui compte au bout de six mois.

Le critère décisif est la réversibilité. Que se passe-t-il le jour où vos scénarios critiques tournent chez un prestataire qui change sa tarification, ferme un connecteur ou tombe en panne ? Zapier et Make sont des services hébergés : rapides à démarrer, impossibles à récupérer. n8n s'auto-héberge : plus lent à mettre en place, et vos scénarios restent des fichiers que vous possédez.

La règle appliquée ici : les automatisations de confort sur un service hébergé, tout ce dont dépend le chiffre d'affaires sur une instance auto-hébergée. Un scénario qui envoie un message de bienvenue peut tomber une journée. Un scénario qui alimente le pipeline commercial, non.

Ce qu'il faut retenir

Faites les trente minutes, elles rapportent immédiatement. Mais dès que quelque chose d'important en dépend, ajoutez trois choses : une alerte sur la progression et non sur l'exécution, des lots plafonnés avec écriture au fil de l'eau, et une reprise automatique après incident.

C'est ce qui sépare un scénario qui marche d'un système qui tourne. Le premier prend une demi-heure. Le second n'en prend pas beaucoup plus, à condition de savoir quoi ajouter.

Cet article fait partie du Guide Complet de l'Automatisation B2B. Le pipeline dont sont tirés ces exemples est décrit dans cette étude de cas.