La plupart des automatisations de prospection meurent en semaine trois. Pas parce que l’idée était mauvaise, mais parce que personne n’a prévu la deuxième exécution. La première, c’est une démo : on appuie sur play, on regarde les nœuds passer au vert, on se prend pour un magicien. La deuxième tape dans un rate limit, retraite les quatre cents mêmes domaines que vous avez déjà contactés, et écrit tranquillement des doublons dans votre CRM. Ce qui suit, c’est la structure qui survit au contact d’un vrai pipeline : quatre workflows n8n, un seul rôle chacun, reliés par une table plutôt que par l’espoir.
Quatre workflows, pas un canvas géant
L’erreur n8n la plus répandue en prospection : construire un canvas énorme qui collecte, enrichit, score, rédige et pousse vers le séquenceur. Ça marche une fois. Puis un nœud lâche à l’étape quatorze et vous n’avez aucune idée de ceux qui, sur neuf cents items, sont déjà passés. Découpez la machine en quatre : un collecteur qui ne produit que des domaines, un enrichisseur qui ne fait que remplir, un scoreur qui ne fait que classer, un rédacteur qui ne fait qu’écrire. Chacun lit et écrit dans la même table.
Cette table est le contrat qui les lie. Postgres, Airtable, Baserow, un simple tableur à faible volume — le stockage n’a presque aucune importance, tant que le domaine sert de clé primaire et que chaque ligne porte une colonne de statut. Collecte. Enrichi. Score. Brouillon. File. Envoi. Réponse. Chaque workflow sélectionne les lignes dans un état et les fait passer au suivant. Si une exécution explose à mi-parcours, les lignes déjà traitées ont avancé et le reste sera repris demain, sans le moindre nettoyage manuel.
C’est aussi ce qui rend l’ensemble explicable. Quand un client demande pourquoi telle boutique a reçu tel email, vous avez une ligne horodatée à chaque transition et le payload brut qui a produit le texte. Essayez de répondre à ça depuis un canvas de quarante nœuds sans persistance et vous comprendrez pourquoi ce découpage vaut l’heure supplémentaire.
Workflow un : le collecteur
Commencez par un Schedule Trigger à une heure peu glamour, puis un nœud Set qui porte le filtre. Gardez le filtre à un seul endroit — vous le modifierez chaque semaine, et l’éparpiller sur cinq nœuds HTTP garantit que deux d’entre eux vont dériver. Un filtre typique pour une agence qui vend de l’optimisation de conversion : plateforme Shopify, pays France et Belgique, plus de quarante produits, trafic mensuel entre trois mille et soixante mille. Un nœud HTTP Request appelle ensuite /v1/stores/search avec ces paramètres et votre clé API dans un header.
Avant de paginer, comptez. Envoyez une seule requête avec le même filtre et lisez le total. Si le nombre revient à douze, ou à quatre cent mille, quelque chose cloche dans votre filtre et vous voulez le savoir avant de cramer une nuit d’appels API. Faites passer ce total par un nœud IF : sous un plancher, on s’arrête et on se notifie ; au-dessus d’un plafond, on s’arrête et on resserre. Seule la bande du milieu continue. Ce nœud à lui seul a économisé plus de quota que toutes les autres optimisations réunies.
La pagination dans n8n est une boucle, et la version la plus propre utilise un nœud Code qui garde le curseur, plus un Loop Over Items qui réinjecte les pages dans le HTTP Request. Plafonnez sèchement — vingt pages par nuit empêchent un filtre parti en vrille d’avaler un mois de quota à trois heures du matin. Écrivez chaque domaine renvoyé dans la table en upsert sur la colonne domaine, pour que relancer le collecteur reste toujours sans conséquence.
Workflow deux : l’enrichisseur
Le collecteur vous donne des domaines et une fiche superficielle. L’enrichisseur ne creuse que sur les lignes que vous comptez vraiment contacter, parce que la profondeur coûte des appels et qu’il n’y a aucune raison d’en payer pour des boutiques que vous n’ouvrirez jamais. Sélectionnez les lignes à l’état collecte, plafonnez le lot à quelques centaines, et lancez trois appels par domaine : /v1/stores/:domain pour la fiche complète, /v1/stores/:domain/catalog pour les produits, /v1/stores/:domain/trend pour l’historique mensuel.
Le troisième est celui que tout le monde saute et c’est le plus précieux. L’endpoint trend renvoie environ 170 points mensuels de trafic organique et de positions organiques. Un nœud Code qui compare les trois derniers mois à la même fenêtre un an plus tôt transforme une ligne statique en récit : cette boutique gagne quarante pour cent, celle-là glisse depuis cinq mois d’affilée. Le sens de la courbe, c’est le pitch. Le reste, c’est du contexte.
Utilisez Loop Over Items par lots de dix, avec un nœud Wait d’une seconde entre chaque — pas par peur du throttling, mais parce que ça rend les exécutions lisibles et les reprises indolores. Réglez chaque nœud HTTP sur retry on fail, trois tentatives, et branchez la sortie continue-on-fail vers une voie qui marque la ligne en échec plutôt que de tuer l’exécution. Un domaine injoignable ne doit jamais vous coûter les deux cents autres.
Workflow trois : le scoring, en code, à un seul endroit
Le scoring tient dans un seul nœud Code, avec les pondérations déclarées en haut sous forme de nombres simples que vous pouvez expliquer à un client à voix haute. Un jeu qui fonctionne : correspondance de plateforme, tranche de taille du catalogue, tranche de trafic, existence ou non d’une fiche Google Business, nombre d’avis et note, présence de mentions en visibilité IA, sens de la courbe. Chacun apporte un nombre de points borné. Vous additionnez, vous plafonnez à cent, vous réécrivez le total dans la ligne avec le détail des composantes, pour pouvoir déboguer un score bizarre plus tard.
Deux filtres durs passent avant le score, pas après. D’abord l’exclusion : on jette tout ce qui est déjà dans le CRM, tout ce qui figure sur une liste de suppression, tout ce qui a été contacté dans les quatre-vingt-dix derniers jours. Ensuite la joignabilité : pas d’email de contact atteignable, pas de ligne. Scorer un lead injoignable, c’est se sentir productif sans rien produire, et ça gonfle tous les tableaux de bord que vous construirez par-dessus.
Un nœud Switch découpe ensuite la sortie en trois. Les scores hauts partent dans une file manuelle qu’un humain lit avant que quoi que ce soit ne bouge. Les scores moyens vont au workflow de rédaction. Les scores bas atterrissent dans une table de nurturing que vous rescorerez au trimestre suivant — une boutique à deux mille visites ce mois-ci peut en faire vingt mille dans six, et comme les données de trend sont déjà là, rescorer coûte un appel au lieu d’une découverte complète.
Workflow quatre : rédiger sous contrat de preuve
Le workflow de rédaction prend une ligne enrichie et produit un email. Il utilise un nœud LLM, mais l’intéressant n’est pas le modèle — c’est le contrat qu’on lui impose. Le system prompt reçoit la fiche boutique en données structurées et une règle au-dessus de toutes les autres : chaque affirmation factuelle de l’email doit être rattachable à un champ nommé, et si le champ est vide, la phrase ne s’écrit pas du tout.
En pratique le modèle renvoie deux choses : l’email, et la courte liste des champs qu’il a utilisés. Un nœud Code en aval vérifie que chaque champ cité est bien présent et non vide dans la ligne source. Si le modèle affirme que la boutique vend des cosmétiques et que la catégorie est vide, le brouillon est rejeté et la ligne repart en file. Ce seul contrôle supprime l’immense majorité des âneries assénées avec aplomb qui rendent la prospection automatisée gênante, et il coûte une quinzaine de lignes de JavaScript.
Gardez le texte court et laissez la donnée porter. Une observation précise, une implication, un livrable, une demande à faible friction. Le livrable est le vrai différenciateur : un audit d’une page de leur fiche Google Business, une page produit réécrite, un graphe de leur courbe organique sur trois ans. Le générer, c’est une autre branche du même workflow, et c’est la raison pour laquelle quelqu’un répond à un inconnu.
La gestion d’erreurs, c’est ça le vrai produit
Déclarez un error workflow au niveau de l’instance et pointez-y tous vos workflows de prospection. Il doit faire trois choses : écrire l’id d’exécution en échec et le nom du nœud dans une table, poster un message sur un canal que vous lisez vraiment, et — c’est le point important — ne pas réessayer automatiquement. Les retries automatiques sur un enrichissement en échec, c’est comme ça qu’on découvre le lundi qu’on a consommé un mois de quota pendant le week-end.
L’idempotence est l’autre moitié du travail. Chaque écriture est un upsert sur la clé domaine. Chaque envoi est conditionné à un horodatage d’envoi. Chaque workflow commence par ne sélectionner que les lignes de l’état dont il a la charge. Faites ces trois choses et vous pourrez tout relancer à n’importe quel moment sans crainte, ce qui est la seule condition pour que vous mainteniez encore ce système dans six mois.
Enfin, loguez la forme des données, pas seulement les échecs. Un récapitulatif hebdomadaire qui indique combien de lignes sont entrées dans chaque état, le score médian et la part de brouillons rejetés par le test de preuve vous dira qu’un filtre s’est périmé des semaines avant que votre taux de réponse ne le fasse. La dégradation silencieuse est le vrai risque en automatisation ; les erreurs bruyantes sont le cas facile.
Le raccourci MCP pour ce que vous n’avez pas encore construit
n8n embarque un nœud MCP Client, et un serveur MCP est inclus dans toutes les offres, ce qui veut dire que vous pouvez brancher un agent sur les mêmes données que vos workflows avant d’écrire le moindre nœud HTTP. C’est la façon la plus rapide d’explorer : demander en langage naturel quelles plateformes dominent tel pays, combien de boutiques répondent à un filtre encore brouillon, à quoi ressemble vraiment une boutique précise. Quand une exploration devient quelque chose que vous voulez faire tourner chaque nuit, portez-la sur des nœuds HTTP explicites — le déterministe bat le malin pour tout ce qui tourne sur un cron.
La répartition des rôles qui tient dans le temps : des agents pour la découverte et pour la rédaction, des nœuds classiques pour tout ce qui est planifié. La découverte est ambiguë et gagne énormément à un modèle capable de poser une meilleure deuxième question. Une collecte nocturne n’a rien d’ambigu, et gagne au contraire à être ennuyeuse, reproductible et bon marché.
Ce qu’il faut garder manuel
L’envoi. Tous les opérateurs qui font tourner ça au volume arrivent au même endroit : la machine construit la liste, l’enrichit, la score et écrit le brouillon, et un humain appuie sur le bouton. Pas seulement par prudence juridique, même si elle existe — parce que la personne qui lit cinquante brouillons chaque matin est la boucle de retour la plus rapide que vous aurez jamais sur votre filtre, votre offre et votre texte. Automatisez la recherche, gardez le jugement.
Commencez par un seul segment. Une plateforme, un pays, une offre. Faites tourner les quatre workflows de bout en bout sur deux cents boutiques avant de les lâcher sur des milliers. La donnée ne va nulle part — 153 515 boutiques vérifiées sur 60 plateformes seront encore là le mois prochain, et la contrainte n’a jamais été le stock. Ça a toujours été de savoir si votre pipeline tourne encore au trentième jour.