Le point de départ : pourquoi construire plutôt qu'acheter
Le choix de construire un système propriétaire plutôt que d'acheter une solution existante n'a pas été motivé par le coût, mais par le contrôle : pouvoir ajuster précisément les critères de scoring, choisir les sources de données pertinentes pour le marché français, et faire évoluer chaque agent indépendamment des cycles de mise à jour d'un fournisseur tiers.
L'architecture : 7 workflows n8n interconnectés
Nom de fichier suggéré :
canvas-n8n-7-agents-prospectia.webpAlt text suggéré : "Capture d'écran du canvas n8n montrant les sept workflows interconnectés du système ProspectIA"
Le système repose sur sept workflows n8n distincts : Onboarding (collecte du profil client), Discovery (recherche d'entreprises), Normalisation (nettoyage des données brutes), Enrichissement (complétion des coordonnées), Signal & Scoring (évaluation et priorisation), Delivery (livraison au client) et un Master Orchestrator qui coordonne l'ensemble chaque matin. Chaque agent est un workflow n8n séparé, appelé par le suivant via des nœuds "Execute Workflow" — un canevas fusionné unique aurait été plus simple à visualiser, mais impossible à exécuter correctement en production.
Les sources de données utilisées
La découverte d'entreprises s'appuie sur plusieurs sources croisées : Google Places pour les entreprises locales, SerpAPI pour la recherche web structurée, et Pappers pour les données d'immatriculation françaises, en particulier les codes NAF qui permettent un ciblage sectoriel précis. L'enrichissement des coordonnées de contact s'appuie sur Hunter.io. La base de données du système repose sur Supabase, avec des tables dédiées aux clients, aux profils ICP et à la configuration des sources.
Voir ce système appliqué à votre propre ICP
Cette architecture n'est pas théorique : c'est celle qui livre des leads chaque matin aux clients ProspectIA.
Découvrir les offres ProspectIA →Les problèmes rencontrés en construisant le système
Trois catégories de problèmes sont revenues le plus souvent. D'abord, des erreurs de mapping de champs dans Supabase (colonnes mal nommées, valeurs non définies) qui provoquaient des échecs silencieux difficiles à diagnostiquer — la leçon retenue : toujours vérifier le schéma réel des tables avant de câbler un mapping, plutôt que de supposer sa structure. Ensuite, des erreurs CORS sur le formulaire d'onboarding hébergé en local : un formulaire HTML servi en `file://` ne peut pas effectuer de requêtes HTTP externes, ce qui a nécessité un hébergement public (Netlify Drop) même pour une simple phase de test. Enfin, la nécessité d'importer chaque workflow individuellement dans n8n : un export JSON fusionné reste utile comme référence visuelle de l'architecture globale, mais n'est pas exécutable tel quel — chaque agent doit exister comme workflow nommé séparément pour que les appels "Execute Workflow" fonctionnent.
Ce que ce système change au quotidien pour un client
Concrètement, un client ProspectIA ne se connecte à aucun outil de recherche : chaque matin, une liste de leads déjà découverts, enrichis et scorés est livrée directement dans son espace de travail. Le temps auparavant passé à chercher des entreprises et des contacts est intégralement redirigé vers la prise de contact et la vente elle-même.
→ Voir en détail les 7 agents qui composent cette architecture : Agents IA pour la prospection commerciale : le guide complet
Ce que je referais différemment
Avec le recul, isoler et valider chaque agent individuellement avec un identifiant client codé en dur, avant de les connecter au Master Orchestrator, aurait évité plusieurs semaines de débogage sur un système entièrement interconnecté où une seule erreur silencieuse pouvait bloquer tout le pipeline. La règle que je retiens : valider chaque brique séparément avant d'assembler le tout, même quand l'envie est de voir le système complet fonctionner au plus vite.
Le détail d'un incident réel : le mapping Supabase cassé
L'un des bugs les plus longs à diagnostiquer est venu d'une incohérence de nommage entre les workflows n8n et les tables Supabase : certains nœuds référençaient un champ `client_id`, d'autres directement `id`, sur les tables clients, profils ICP et configuration des sources. Résultat : des échecs silencieux, sans message d'erreur explicite, où des workflows s'exécutaient "avec succès" tout en traitant des données vides ou incorrectes. La leçon retenue : avant de câbler un mapping de champs entre deux systèmes, toujours vérifier le schéma réel de chaque table plutôt que de se fier à ce qu'on suppose qu'il devrait être.
Pourquoi l'e-mail de bienvenue n'était pas encore branché
Le nœud SendGrid chargé d'envoyer l'e-mail de bienvenue après l'onboarding d'un nouveau client restait volontairement en pause pendant la phase de test : mieux valait valider manuellement que chaque agent en amont (Onboarding, Discovery, Normalisation) fonctionnait correctement avant d'automatiser une communication visible par le client final. Ce choix illustre un principe plus général : automatiser dans l'ordre, de l'interne vers l'externe, pour ne jamais exposer un client à une erreur qu'un test manuel aurait pu détecter en amont.
Les prochaines étapes du système
La feuille de route inclut la validation individuelle de chaque agent restant avec un identifiant client codé en dur avant de les connecter tous au Master Orchestrator, ainsi que la correction du nœud Google Sheets qui doit créer un onglet dédié par client plutôt que d'utiliser un modèle fixe partagé — un point de fragilité identifié qui pourrait bloquer l'agent de livraison si plusieurs clients étaient onboardés simultanément.
FAQ — 7 questions fréquentes
Pourquoi construire un système de prospection IA plutôt qu'acheter une solution existante ?
Principalement pour garder le contrôle sur les critères de scoring, choisir des sources de données adaptées au marché ciblé, et faire évoluer chaque composant indépendamment des cycles de mise à jour d'un fournisseur tiers.
Combien d'agents IA compose le système ProspectIA ?
Sept agents : Onboarding, Discovery, Normalisation, Enrichissement, Signal & Scoring, Delivery, et un Master Orchestrator qui coordonne l'exécution des six autres chaque matin.
Quelles sources de données sont utilisées pour la découverte d'entreprises françaises ?
Google Places pour les entreprises locales, SerpAPI pour la recherche web structurée, et Pappers pour les données d'immatriculation françaises, en particulier les codes NAF pour un ciblage sectoriel précis.
Quels sont les problèmes techniques les plus fréquents en construisant un système multi-agents avec n8n ?
Les erreurs de mapping de champs entre les workflows et la base de données (Supabase), les erreurs CORS liées à un hébergement local du formulaire d'entrée, et la nécessité d'importer chaque workflow individuellement plutôt que d'utiliser un export fusionné.
Un canevas n8n fusionné avec tous les agents est-il utilisable en production ?
Non, il reste utile comme référence visuelle de l'architecture globale, mais chaque agent doit exister comme workflow nommé séparément pour que les appels 'Execute Workflow' fonctionnent réellement.
Quelle est la meilleure méthode pour construire un système multi-agents complexe ?
Valider chaque agent individuellement, avec des données de test codées en dur, avant de le connecter aux autres via l'orchestrateur central — plutôt que de tenter de faire fonctionner l'ensemble du pipeline dès le départ.
Combien de temps faut-il pour construire un système de prospection IA à sept agents ?
Le temps varie selon la complexité des sources de données et les intégrations nécessaires (base de données, enrichissement, email transactionnel), mais compter plusieurs semaines de développement et de débogage est réaliste pour un système complet en production.