Automatisation de prospection TeamIA avec Lemlist et n8n

Le besoin de TeamIA ne se limitait pas à récupérer une liste de contacts. Chaque campagne devait porter une offre, des critères de ciblage, des fonctions de décideurs, des exclusions et des instructions de message. Une fois les données enrichies, il fallait encore comprendre pourquoi contacter cette entreprise et décider si le message était exploitable.

J’ai conçu une application métier qui rassemble ces étapes. Le travail livré comprend l’interface de revue, la configuration des campagnes et segments, les API de réception des prospects, la persistance des décisions et le raccordement au moteur n8n. Le cockpit donne à l’équipe une file de travail consultable, au lieu de lui demander de suivre les exécutions techniques une par une.

Une campagne peut être en brouillon, active ou en pause. Elle contient l’offre à présenter, les problèmes métiers ciblés, les intitulés de poste recherchés ou exclus et les consignes de personnalisation. Les segments précisent notamment le pays, la localisation, les secteurs, la taille des entreprises et leur quota. Ces paramètres alimentent le workflow plutôt que de rester dispersés dans ses nœuds.

La version examinée impose un plafond de dix prospects par jour sur le total des campagnes actives. C’est une limite de fonctionnement du périmètre initial, pas une mesure de performance. Les segments et la pagination permettent de poursuivre la recherche de façon organisée ; la montée en charge doit ensuite être dimensionnée selon les quotas fournisseurs et la capacité de revue de l’équipe.

La fiche prospect sépare quatre vues : décideur, entreprise, analyse IA et message. Elle regroupe le score d’entreprise, les informations de contact, le statut de l’email, les technologies renseignées, une synthèse de recherche et le potentiel d’automatisation identifié. Les filtres par campagne, marché et statut aident à retrouver les dossiers à traiter.

Le signal commercial dispose de champs pour sa source et sa date. L’utilisateur peut donc consulter l’élément qui motive l’approche et vérifier sa pertinence avant d’écrire. Le score sert à ordonner la revue ; il n’est pas présenté comme une probabilité de conversion. Une synthèse IA ou un email marqué comme vérifié demande toujours une utilisation adaptée au contexte de prospection.

Next.js et React portent le cockpit et les routes API. PostgreSQL sur Supabase conserve les campagnes, les segments, les entreprises déjà traitées et les prospects. n8n lit les segments actifs, orchestre la recherche et prépare les données. Lemlist fournit les fonctions de recherche et d’enrichissement utilisées par cette chaîne.

Une API d’ingestion reçoit les résultats normalisés. Les entrées sont validées côté serveur avant leur enregistrement, et une clé de déduplication permet de rattacher les retours au même prospect. Les accès navigateur et les échanges avec l’automatisation utilisent des mécanismes d’authentification distincts. Les secrets d’intégration et la connexion PostgreSQL restent côté serveur.

La déduplication commence au niveau de l’entreprise. Le système construit une clé à partir du domaine normalisé, ou d’un identifiant disponible, puis réserve les entreprises retenues en base. Une contrainte d’unicité et une insertion qui ignore les conflits écartent les comptes déjà traités avant la recherche de nouveaux décideurs.

Cette réservation et la progression de pagination sont enregistrées dans une transaction. L’ingestion possède aussi sa propre clé pour les prospects. Ces deux niveaux répondent à des problèmes différents : éviter de retraiter une entreprise et rattacher correctement les données d’un contact. Ils rendent les reprises plus contrôlables, sans promettre que toute défaillance d’un fournisseur est automatiquement résolue.

Les dossiers passent par des statuts explicites : enrichissement en attente, à relire, validé, correction demandée ou refusé. Le sujet et le corps du message sont éditables ; un commentaire accompagne la revue. Les boutons de décision enregistrent le statut, le texte et la remarque dans la fiche.

Dans le périmètre présenté, valider ne signifie pas envoyer. Le cockpit ne contient pas d’action d’expédition des emails de prospection. Un éventuel raccordement à un outil d’envoi constitue une étape supplémentaire, à définir avec ses exclusions, ses limites de fréquence et ses conditions de validation.

Le résultat concret est une interface qui relie le paramétrage des campagnes à la revue des prospects, avec des états persistants et un accès aux informations utiles à la décision. Les captures présentent cette interface avec des entreprises, contacts et messages fictifs. Aucun fichier de prospects ni accès au cockpit privé n’est publié dans cette étude de cas.

Je ne dispose pas ici de mesures vérifiées sur le temps gagné, les rendez-vous obtenus ou le chiffre d’affaires attribuable au projet. Pour évaluer son impact, les indicateurs à suivre sont le taux de doublons écartés, le coût d’enrichissement par dossier exploitable, le temps de revue et la proportion de messages corrigés ou validés. Les résultats commerciaux nécessitent un suivi distinct après prise de contact.

Cette approche convient aux agences B2B et équipes commerciales qui ont des critères de ciblage précis, plusieurs offres et un besoin de contrôle sur les messages préparés par l’IA. Le cadrage commence par les sources de données autorisées, les règles de qualification, les outils existants et la personne responsable de la revue.

Une première version peut couvrir une campagne, un parcours d’enrichissement et une file de validation. Les volumes, droits d’accès, intégrations CRM et éventuels envois sont ensuite définis selon les contraintes réelles. Pour discuter d’un logiciel de prospection sur mesure, le plus utile est de partir d’une campagne concrète et de son processus actuel.