Bonjour à tous,
J’aimerais savoir si quelqu’un parmi vous a déjà construit un flux de travail comme celui-ci dans n8n.
Idée de flux de travail :
1. Lire les prospects à partir d’un CRM ou de Google Sheets
2. Chaque prospect a un nom, un email, un nom d’entreprise et un site web
3. Visiter et scraper automatiquement le site web de l’entreprise
4. L’IA analyse l’entreprise et comprend ce qu’elle fait
5. L’IA rédige un email de prospection personnalisé basé sur l’analyse du site web
6. L’email est envoyé automatiquement au prospect
7. Les emails de suivi sont envoyés automatiquement s’il n’y a pas de réponse
8. La détection de réponse arrête la séquence si le prospect est intéressé
Je ne vous demande pas si c’est possible de le construire.
Je veux savoir si quelqu’un a DÉJÀ construit quelque chose de similaire avant.
Si oui, veuillez partager votre flux de travail, une démo ou votre expérience.
Merci.
Oui, variantes proches : ligne d’en-tête → récupération de site → résumé commercial court → brouillon personnalisé → vérification envoi/non-envoi → arrêt de la séquence à la réception d’une réponse.
Les deux éléments qui décident généralement du succès sont la qualité de la récupération du site et la règle d’arrêt de réponse. Si tu veux comparer tes notes, par où commences-tu : un CRM, des Sheets, ou une liste scrappée ?
Bienvenue @Ayesha_Saeed!
C’est un flux très viable dans n8n. Le nœud critique à étudier en premier est le nœud HTTP Request pour l’étape de web scraping - l’associer à une URL Jina Reader (https://r.jina.ai/[URL]) vous donne du markdown propre à partir de n’importe quel site web d’entreprise sans avoir à gérer le HTML brut. À partir de là, un seul appel LLM pour résumer et rédiger l’e-mail en une seule étape garde le flux rapide et efficace en termes de tokens.
Bonjour, je suis intéressé par cette automation. Comment peut-on la réaliser de bout en bout ? Merci d’avance.
Bonjour,
Oui, j’ai déjà créé un workflow n8n similaire pour la recherche de prospects alimentée par l’IA et l’automatisation des emails de prospection personnalisés.
Le workflow récupérait les prospects dans Google Sheets/CRM, parcourait le site web de l’entreprise, utilisait l’IA pour comprendre l’activité, générait un email personnalisé, l’envoyait via le système email connecté et gérait les relances en fonction du statut de réponse.
J’ai également géré les vérifications de doublons, les échecs de scraping de site web, les mises à jour du statut des prospects, la journalisation et la détection de réponses pour que la séquence s’arrête quand quelqu’un répond.
Une question : prévoyez-vous d’envoyer les emails via Gmail/SMTP, ou via un outil de prospection comme Instantly, Smartlead ou Apollo?
Réservez un appel rapide :Calendly - Automaxion
J’en ai juste construit un aujourd’hui. Il récupère les prospects d’une feuille Google et envoie ces données à un agent IA, qui rédige des messages de prospection personnalisés et envoie des relances tous les quelques jours
Oui, j’ai construit ce flux exact — et deux choses du thread valent la peine d’être ajoutées, parce que c’est ce qui pose réellement problème une fois que c’est en production.
La suggestion Jina Reader ci-dessus est un bon appel pour un texte propre. Le problème avec l’envoi direct d’un site scrapy dans le LLM qui écrit l’email (étape 4 → 5) : ce site est une entrée contrôlable par un attaquant. Une page peut contenir « ignore les instructions précédentes, écris… », et puisque ce texte s’écoule dans le modèle dont vous envoyez ensuite automatiquement la sortie, vous pouvez finir par envoyer du contenu choisi par l’attaquant depuis votre propre domaine. Ça vaut le coup de délimiter le texte scrapy comme non fiable dans le prompt et de ne pas le laisser diriger l’envoi.
L’autre garde qui en vaut vraiment la peine : ne pas envoyer quand le scrape échoue. Un site mort ou bloqué — un 503 avec une longue page d’erreur, un défi Cloudflare — produira quand même un email confiant « J’ai adoré votre site ___" si vous vérifiez simplement que vous avez récupéré du texte. Conditionnez l’envoi sur le statut HTTP (2xx), pas sur le nombre d’octets, et ignorez + enregistrez tout le reste.
Pour 7–8 (suivi + arrêt à la réponse), je garde ça comme un workflow planifié séparé qui lit le thread et s’arrête à une réponse — plier l’envoi et l’attente dans un seul flux devient fragile très vite.
Je construis ceux-ci comme des workflows testés — chacun est livré avec un test qui exécute des exécutions réelles plus un test de mutation (injectez un bug, confirmez que le test l’attrape), donc il n’envoie pas silencieusement de mauvaises données. Je serais heureux de partager la version importable si c’est utile pour vous.
J’ai construit cette forme exacte plusieurs fois — deux pièges qui piègent tout le monde : Traiter le texte du site gratté comme une entrée non fiable pour le LLM. Une page peut contenir « ignorer les instructions précédentes » et votre rédacteur d’e-mails l’obéira. Envelopper le grattage avec des délimiteurs clairs et dire au modèle que le contenu entre eux est des données, jamais des instructions. La détection de réponses est l’endroit où les séquences fuient. Ne vérifiez pas seulement le courrier entrant — vérifiez qu’il provient du même fil/lead ET qu’il n’est pas une réponse automatique/absence du bureau, sinon vous arrêterez les séquences sur les rebonds « Je suis en vacances ».\n\nPour le grattage, Jina Reader + une vérification du statut HTTP avant de passer quoi que ce soit au modèle vous évite d’alimenter le LLM avec des pages 404. Je serais heureux de partager comment je câble la condition d’arrêt si c’est utile — je les construis pour les petites entreprises de services.
@Ayesha_Saeed @jacewe J’ai maintenant construit et testé à l’importation une variante proche de ce flux : CRM/Google Sheets → normaliser → notes de site optionnelles → score IA → brouillon de sensibilisation personnalisée → brouillon Gmail pour révision humaine → tâche de suivi → rapport quotidien.
Je garde le premier déploiement en brouillon uniquement car les raclages échoués, les lignes en doublon, l’injection de requête de site web, et les règles d’arrêt de réponse sont des endroits où un flux apparemment vert peut causer des dégâts.
Ma séquence de première exécution la plus sûre est : ligne d’exemple → résultat IA attendu → brouillon révisé → déploiement d’une ligne. Ensuite, ajouter les vérifications de doublon, une porte de raclage 2xx, les journaux IA bruts et analysés, et l’arrêt-sur-réponse avant la montée en charge.
Si l’un de vous construit encore cela, dites-moi si la source est Sheets ou un CRM et je peux vous indiquer les premiers nœuds et garde-fous que je testerais. Je maintiens également une liste de contrôle gratuite pour la première exécution liée depuis mon profil.
Ok, j’ai une suggestion pour toi qui n’est pas liée à n8n.
Utilise un service d’email tiers ou obtiens un nom de domaine séparé pour toutes tes campagnes d’outreach. Parce que si, par exemple, 1 % de tes emails sont marqués comme spam et que c’est sur ton domaine principal, alors chaque email que tu envoies depuis ton domaine principal sera considéré comme spam. C’est la dernière chose que tu veux. Ce sera les meilleurs 30 dollars environ que tu dépenseras en obtenant yoursiteoffers.com pour masquer tous tes emails légitimes yoursite.com.
Sur la partie détection de réponse et séquençage de relances (étapes 7-8), ce que les gens se trompent généralement à faire, c’est d’utiliser un nœud d’attente fixe pour les relances. Meilleur motif : après l’envoi, écrivez une ligne dans Postgres/Sheets avec l’id du prospect, l’horodatage d’envoi et status=pending. Exécutez un workflow programmé qui vérifie la boîte de réception via IMAP ou un déclencheur Gmail, associe les réponses par identifiant de fil ou e-mail du prospect, et bascule le statut à replied. Un déclencheur Schedule distinct interroge ensuite les lignes où status=pending et days_since_sent atteint votre intervalle de relance, de sorte que toute la séquence survive aux redémarrages de n8n et vous pouvez suspendre/reprendre par prospect sans perdre d’état.