La machine à leads SDR¶

Au départ, je voulais résoudre un problème simple : les SDR passaient trop de temps à chercher des entreprises, des contacts, à formuler des messages, et à relancer à la main.

Le vrai problème n'était pas le travail commercial. C'était tout ce qui précède : la préparation.

Le problème réel¶

Un SDR passe une grosse partie de son temps sur des tâches qui ne sont pas de la vente :

trouver des entreprises pertinentes ;
identifier les bons contacts ;
comprendre leur contexte technique ;
rédiger un message qui ne ressemble pas à un template générique ;
relancer sans oublier ;
tracker les résultats.

Chaque étape est chronophage. Chaque étape est répétitive. Et chaque étape, prise séparément, est "faisable manuellement" : c'est pour ça que les organisations tardent souvent à les automatiser.

L'objectif réel

Le but n'était pas d'automatiser la prospection de bout en bout, mais de préparer un travail commercial plus propre, plus rapide et plus contextualisé. Les SDR gardent la main sur l'envoi, le suivi et les décisions commerciales.

Ce que je voulais construire¶

Pas un CRM. Pas une "plateforme AI SDR". Pas un outil qui prétend tout faire.

Je voulais une machine d'aide à la prospection : semi-automatisée, avec du contrôle humain là où c'est nécessaire.

Concrètement :

données → enrichissement → scoring → génération → interface SDR → suivi

Chaque étape devait être compréhensible, modifiable, et observable.

Vue globale de l'architecture¶

flowchart LR
    A[Sources domaines\nAPI publique · Tranco · Autres]
    --> B[Liste de sites web\n+50 000 entreprises FR]

    B --> C[Crawler Scrapy\nDétection techno concurrente]

    C --> D[~10 000 entreprises\navec techno pertinente]

    D --> E[Enrichissement Hunter.io\nEntreprise + contacts]

    E --> F[BDD enrichie\nenvironnement n8n]

    F --> G[Matching pain points concurrents]
    F --> H[Matching références clients]

    G --> I[Scoring]
    H --> I

    I --> J[Assignation SDR\nrépartition équilibrée · 40/semaine]

    J --> K[Génération messages\nOpenRouter + GPT-4o-mini]

    K --> L[Microsoft Lists\nsuivi opérationnel]

    L --> M[Power Automate\nstatuts + relances]
    L --> N[Teams\nnotification hebdo]
    L --> O[Power BI\nreporting]

Les données de départ¶

Avant de détecter quoi que ce soit, il faut une liste de sites à analyser.

J'ai constitué une base à partir de plusieurs sources :

Source	Type
API publique	Données entreprises enrichies
Tranco	Classement de popularité de domaines
Autres listes	Compilations sectorielles

Résultat : plus de 50 000 sites web d'entreprises françaises à crawler.

Ce n'est pas une base parfaite. Beaucoup de sites sont inactifs, mal référencés, ou hors cible. C'est normal et anticipé : la qualité vient après, pas avant.

Le crawler Scrapy : détecter les technos concurrentes¶

J'ai construit ce crawler dans le cadre d'un projet dédié, j'en parle plus en détail dans cet article sur la construction d'un détecteur de technologies web avec Scrapy.

Un spider Scrapy parcourt chaque URL et cherche des traces de technologies dans le HTML, les scripts, les cookies, les headers et les meta tags.

Les technologies recherchées sont celles de l'écosystème emailing, CRM, marketing automation, événementiel :

	Techno	Catégorie
	Mailchimp	Emailing
	HubSpot	CRM / inbound
	Klaviyo	Emailing e-commerce
	Brevo	Emailing / CRM
	Salesforce	CRM enterprise
	ActiveCampaign	Marketing automation
	Mailjet	Emailing transactionnel
	Dialog Insight	Emailing québécois
	Sarbacane	Emailing FR
	Splio	Marketing automation FR
	Actito	Marketing automation
	Marketo	Marketing automation enterprise
	Weezevent	Billetterie / événementiel
	Mapado	Billetterie culturelle
	Eudonet	CRM associations

Sur environ 50 000 sites analysés, environ 10 000 entreprises ont été détectées avec une technologie pertinente.

La détection n'est pas magique

Les signatures sont parfois fragiles. Un script mutualisé peut générer des faux positifs. Certains sites chargent leurs outils de façon indirecte ou dynamique. La détection donne une probabilité, pas une certitude : d'où l'importance du scoring ensuite. → Comment fonctionne la détection en détail

Enrichissement Hunter.io¶

Une fois les entreprises identifiées comme pertinentes, le workflow appelle l'API Hunter.io pour :

enrichir les données de l'entreprise (secteur, taille, pays, description) ;
récupérer des contacts commerciaux pertinents liés au domaine ;
rattacher les contacts aux bonnes entreprises.

L'objectif n'est pas d'avoir "le plus de contacts possible". Un mauvais contact pollue le workflow et fait perdre du temps au SDR.

Les limites à anticiper

Données absentes pour certains domaines ;
Emails introuvables ou non vérifiés ;
Erreurs 404 si le domaine n'est pas indexé par Hunter.io ;
Il faut gérer proprement ces cas dans le workflow pour ne pas bloquer tout le pipeline sur une seule erreur.

Bases métier : pain points et références clients¶

C'est probablement la partie la moins "technique" du projet, mais l'une des plus utiles.

Base de pain points concurrentsBase de références clients

Pour chaque technologie concurrente détectée, j'ai constitué une base structurée de pain points potentiels :

délivrabilité insuffisante ;
support difficile à joindre ;
coût élevé pour le volume traité ;
segmentation limitée ;
manque d'accompagnement à l'usage ;
intégrations complexes ou absentes ;
UX peu ergonomique ;
faibles capacités d'automatisation ;
reporting limité.

Quand le workflow détecte qu'une entreprise utilise un concurrent précis, il récupère automatiquement les pain points associés et les injecte dans le contexte de génération du message.

J'ai aussi constitué une base de nos références clients avec :

le secteur d'activité ;
le contexte du projet ;
la technologie remplacée ou complémentée ;
la problématique résolue.

Objectif : que chaque message puisse mentionner une preuve commerciale contextualisée, pas juste "on a des clients dans ce secteur".

L'idée n'est pas de se vanter. C'est de donner aux SDR un argument crédible et pertinent pour l'interlocuteur en face.

Scoring¶

Le workflow score chaque entreprise selon plusieurs critères avant de la soumettre aux SDR.

Critère	Pondération indicative
Effectif 11-50 salariés	+1
Effectif 51-200	+3
Effectif 201-500	+3
Effectif 501-1000	+3
Effectif 1001-5000	+2
Effectif 5001-10 000	+2
Effectif 10 001+	+1
Type : partenariat	+2
Type : entreprise publique	+3
Type : association / non-profit	+2
Type : organisme gouvernemental	+3
Peu ou aucun contact trouvé	score négatif
Plusieurs contacts pertinents	score positif
Technologie concurrente prioritaire	score plus élevé

Une leçon importante

Quand tout est intéressant, plus rien ne l'est. Le scoring sert surtout à forcer une priorisation.

Le score n'est pas une vérité absolue. C'est un outil de tri. Il peut évoluer, être ajusté, être contredit par le SDR. Mais sans lui, le workflow enverrait tout sans hiérarchie, et les SDR se retrouveraient noyés.

Workflow n8n : le coeur du système¶

Le workflow n8n orchestre toutes les étapes après l'enrichissement.

Workflow n8n "Recherche et traitement des infos contact" : schedule, tri, assignation commerciale, agents IA, création de fiche et notification.

Les grandes étapes :

Récupération des entreprises enrichies depuis la base ;
Tri par score décroissant ;
Limitation à 40 entreprises par semaine (garde-fou volontaire) ;
Vérification des garde-fous (doublons, entreprises déjà traitées) ;
Assignation automatique aux 3 commerciaux SDR avec répartition équilibrée ;
Récupération des contacts associés ;
Ajout des champs commerciaux (pain points, références) ;
Matching pain points selon la techno détectée ;
Matching références clients selon le secteur ;
Génération du message de prospection (Message 1) ;
Génération du message de relance ;
Création des lignes dans Microsoft Lists ;
Calcul des statistiques du lot ;
Notification Teams aux commerciaux.

Pourquoi 40 entreprises par semaine ?

Ce n'est pas une limite technique. C'est un choix délibéré. Un flux trop important dégrade la qualité du suivi, dépasse la capacité de traitement réelle des SDR, et finit par être ignoré. 40 par semaine bien préparées valent mieux que 200 mal suivies.

Génération IA : OpenRouter + GPT-4o-mini¶

Pour chaque entreprise, le pipeline génère deux messages personnalisés.

flowchart LR
    A[Entreprise enrichie]
    --> B[Techno détectée]

    B --> C[Pain points associés]
    B --> D[Référence client pertinente]

    C --> E[Prompt structuré]
    D --> E

    E --> F[GPT-4o-mini via OpenRouter]

    F --> G[Message 1\nde prospection]
    F --> H[Message de relance]

Le modèle reçoit un prompt structuré avec :

le nom et le domaine de l'entreprise ;
la technologie détectée et ses pain points ;
la référence client sélectionnée ;
les contraintes de ton et de format.

L'IA est utile, mais elle n'est pas le coeur du système. Le coeur, c'est l'assemblage entre données, règles métier, scoring et workflow opérationnel.

GPT-4o-mini intervient uniquement sur la formulation et la contextualisation. Il ne décide pas de qui contacter, ni de quand, ni avec quel argument : ça, c'est la logique métier structurée dans le workflow.

Microsoft Lists : l'interface opérationnelle SDR¶

Le résultat final atterrit dans une Microsoft List, partagée avec les commerciaux.

Chaque ligne correspond à une entreprise, avec ses contacts, ses messages préparés, et ses statuts.

Statuts prospectStatuts emailStatuts commercial

Statut	Signification
`nouveau`	Lead créé, pas encore traité
`en_cours`	Commercial a pris en main
`clos`	Traitement terminé (quelle qu'en soit l'issue)

Statut	Signification
`envoye`	Message envoyé
`non_repondu`	Pas de réponse après 5 jours
`repondu`	Réponse reçue
`erreur`	Erreur à l'envoi

Statut	Signification
`rdv`	Rendez-vous obtenu
`refus`	Refus explicite
`hors_cible`	Lead non pertinent

Pourquoi Microsoft Lists ?

Microsoft Lists n'est pas l'outil le plus glamour du monde, mais pour ce cas précis, il faisait exactement ce dont j'avais besoin : une interface simple, filtrable, partageable et connectée à Power Automate. Pas besoin de construire un outil interne, pas besoin de former l'équipe sur un nouveau produit. Les SDR travaillaient déjà dans l'écosystème Microsoft.

Notification Teams et adoption¶

Chaque nouveau lot SDR déclenche un message dans Teams, envoyé automatiquement aux commerciaux.

Ce message contient :

le nombre de leads créés et assignés ;
la répartition par commercial ;
les consignes de gestion des statuts ;
les règles sur les relances ;
le lien direct vers la liste Microsoft Lists ;
le lien vers le workflow n8n si besoin de debug.

Message Teams envoyé automatiquement lors de la création d'un nouveau lot SDR, avec répartition par commercial et consignes de gestion.

Cette partie est souvent sous-estimée. Un workflow technique ne sert à rien si les utilisateurs ne comprennent pas comment l'utiliser, ni quand il a tourné, ni quoi faire ensuite.

La documentation opérationnelle n'est pas du luxe. C'est ce qui fait la différence entre un outil utilisé et un outil abandonné.

Power Automate : le suivi automatique des statuts¶

Une fois les leads dans Microsoft Lists, des flux Power Automate gèrent le suivi automatique :

passage automatique au statut en_cours quand le commercial ouvre la fiche ;
détection "non répondu après 5 jours" : bascule du statut email ;
détection de réponse reçue ;
gestion des erreurs d'envoi ;
clôture automatique dès qu'un statut commercial est renseigné ;
mise à jour du champ last_email_sent_at ;
rappels de relance.

Liste des flux Power Automate gérant les statuts, relances et clôtures automatiques.

Power Automate complète n8n sur tout ce qui touche à l'environnement Microsoft : là où n8n orchestre la génération et la création des leads, Power Automate gère la vie opérationnelle de chaque lead dans Lists.

Power BI : rendre le système observable¶

Le tableau de bord Power BI permet de suivre l'ensemble des performances SDR.

Quelques chiffres issus du tableau de bord sur la période de lancement :

KPI	Valeur
Leads total	~2 000
Leads en cours	270
Leads clos	62
Refus	7
Erreurs email	26
Hors cible	31

Le dashboard inclut aussi les répartitions par commercial et par source de leads, le détail exportable des prospects, et le délai moyen de réponse.

Ce que ça change vraiment

Sans reporting, le système reste un bricolage. Avec Power BI, il devient pilotable. On peut identifier ce qui marche, ajuster le scoring, changer les seuils, comparer les commerciaux. Le système sort du statut "expérimentation" pour entrer dans celui d'"outil de gestion".

Ce qui a cassé ou était plus complexe que prévu¶

Qualité des donnéesEnrichissement incompletAlignement humainMaintenance des signatures

Les données web sont sales. Beaucoup de domaines renvoient des erreurs, des redirects, du HTML cassé, des sites vides. La base de départ avait une qualité très variable et nécessitait des étapes de nettoyage qui n'étaient pas prévues au départ.

Hunter.io ne connaît pas tous les domaines. Sur une partie des entreprises détectées, l'enrichissement renvoie peu ou rien. Il a fallu gérer ces cas proprement sans faire planter tout le workflow, et décider quoi faire de ces entreprises : les garder, les écarter, les remettre en file d'attente ?

Le plus difficile n'était pas technique. C'était d'aligner les SDR sur les statuts, les règles de gestion, et la façon d'interpréter les leads générés automatiquement. Un système automatisé qui n'est pas adopté ne sert à rien.

Les signatures Scrapy vieillissent. Un concurrent peut changer de CDN, renommer ses scripts, ou charger ses outils différemment. La détection n'est jamais "finie".

Ce que j'ai appris¶

Sur les données¶

Toujours partir du pire scénario : données manquantes, erreurs API, domaines invalides. La robustesse du pipeline vient de sa capacité à gérer les cas limites sans tout bloquer.

Sur le scoring¶

Un bon score de priorisation vaut mieux qu'un mauvais score de confiance. Le scoring sert à décider quoi traiter en premier, pas à prédire des résultats.

Sur l'IA¶

GPT-4o-mini offre un très bon rapport coût/performance pour de la rédaction à volume. Pour ce type de tâche, personnalisation de messages à partir d'un contexte structuré, il fait exactement ce qu'on lui demande sans surcoût inutile.

Sur les workflows¶

Un workflow long et complexe est difficile à maintenir et à debugger. Mieux vaut découper tôt en sous-workflows clairs, avec des logs lisibles et des points de contrôle visibles.

Sur l'adoption¶

Un outil technique sans documentation opérationnelle finit toujours par être mal utilisé ou abandonné. La notification Teams et les consignes claires ont été aussi importantes que le code.

Les limites actuelles¶

Ce qui reste imparfait

Scalabilité : le système tourne sur un volume maîtrisé de 40 leads/semaine par choix. À plus grande échelle, certains composants demanderaient à être repensés.
Dépendances API : Hunter.io, OpenRouter, n8n : chaque composant peut tomber. Il faudrait des fallbacks plus robustes.
Qualité variable : les messages générés sont bons en moyenne, mais pas toujours parfaits. Un passage humain reste nécessaire sur certains leads.
Maintenance des signatures : la détection Scrapy demande une mise à jour régulière.

Ce que je referais autrement¶

Normalisation des données en amontMonitoring dès le départDécoupage des workflowsGestion des erreurs Hunter.io

J'aurais normalisé les données plus tôt dans le pipeline : casse, encodages, doublons de domaines. Ça aurait évité des corrections à faire après coup.

Le debugging dans n8n est faisable mais pas toujours agréable sur des workflows longs. J'aurais ajouté des logs structurés et des alertes plus tôt.

Le workflow principal est devenu assez dense. Le découper en sous-workflows dès le départ aurait rendu l'évolution plus facile.

J'ai géré les erreurs Hunter.io au fur et à mesure. Il aurait mieux valu définir une stratégie claire dès le départ : retry, mise en attente, exclusion.

Ce que j'explorerais ensuite¶

Pistes d'évolution

Scoring probabiliste basé sur l'historique de conversion ;
Détection de changements de stack dans le temps (monitoring continu) ;
Clustering des entreprises par profil techno + secteur ;
Intégration directe dans un CRM pour éviter la couche Microsoft Lists ;
Extension à d'autres pays avec adaptation des signatures et des sources de domaines.

Je pensais construire un outil de prospection. J'ai surtout construit un système d'assemblage : des données, des règles, du scoring, de la génération, et une interface opérationnelle.

Chaque brique prise séparément est simple. C'est l'assemblage qui crée la valeur.

Un pipeline lisible et stable vaut souvent mieux qu'un système "intelligent" impossible à maintenir.