Détection IA de signaux d'affaires pour les SDR

Les bases commerciales disent qu’une entreprise existe, rarement pourquoi elle mérite d’être contactée maintenant. J’ai donc assemblé un système qui collecte des traces publiques (WTTJ, LinkedIn, Trustpilot, sites web), les qualifie avec un LLM et les transforme en contexte utilisable par des SDR. Cette page relie les quatre notes techniques qui le composent.

Les notes techniques liées

Détecter les technologies web avec Scrapy

Un moteur de détection de stack à partir du HTML, des scripts, des cookies, des headers et des signatures.

→ Lire la note
La machine à leads SDR

Base d’entreprises, Hunter.io, pain points, références clients, n8n, Microsoft Lists et Power BI pour préparer la prospection.

→ Lire la note
Veille concurrentielle multi-source

Trustpilot, LinkedIn, sites web, Supabase et un LLM pour extraire des signaux concurrentiels.

→ Lire la note
Signaux d’expansion avec WTTJ, LinkedIn et n8n

WTTJ via Algolia, LinkedIn, pages d’actualités et Redis pour repérer des indices de croissance.

→ Lire la note

Le problème

Les commerciaux manquent rarement de données : nom, secteur, taille, contacts, technologies supposées, levées de fonds. Ce qui manque, c’est ce qui a changé. Une base décrit une entreprise ; un signal d’affaires décrit un mouvement : recrutements en série sur WTTJ, posts LinkedIn sur un nouveau marché, avis Trustpilot négatifs récurrents, changement de stack marketing.

Avant ce système, je passais mon temps à ouvrir des sites, lire le code source, parcourir des offres d’emploi et croiser des onglets pour en tirer un message crédible. Chaque tâche était simple, l’ensemble était lent et impossible à industrialiser.

Les outils existants (bases B2B, intent data, plateformes de sales intelligence) ne me convenaient pas : données statiques, scoring opaque, coût élevé. Je voulais pouvoir changer les sources, les règles, les prompts et les seuils, et surtout voir le raisonnement.

Un signal n’est pas une vérité

Une offre d’emploi ne prouve pas l’hypercroissance, un avis négatif ne prouve pas qu’un concurrent va mal, un script dans le HTML ne prouve pas qu’une techno est réellement utilisée. Le système formule des hypothèses, pas des certitudes.

Ce que j’ai construit

Le principe : collecter, structurer, puis seulement ensuite appeler l’IA.

flowchart LR
    A[Sources publiques] --> B[Collecte]
    B --> C[Nettoyage et extraction]
    C --> D[Qualification IA]
    D --> E[Scoring explicable]
    E --> F[(Supabase)]
    F --> G[Interface SDR]

La stack : n8n pour orchestrer, Scrapy (avec Playwright en fallback) pour le crawl, Supabase pour historiser entreprises et signaux, OpenRouter avec gpt-4o-mini pour la qualification, Apify pour LinkedIn, Hunter.io pour les contacts, Redis pour limiter la concurrence sur les APIs, Microsoft Lists et Power BI côté équipe.

Les briques, dans l’ordre :

Signaux techniques. Scrapy collecte HTML, scripts, cookies et headers ; un moteur de signatures produit un score de confiance par technologie, en gardant ses preuves. Détail : détecteur de technologies web avec Scrapy.
Enrichissement et personnalisation. Hunter.io fournit les contacts. Le LLM ne part jamais d’une page blanche : il reçoit les technos détectées, des pain points préparés par techno concurrente et des références clients du secteur. Je ne lui demande pas « écris un email », mais « propose un angle prudent et vérifiable pour un SDR ». Détail : la machine à leads SDR.
Signaux d’expansion. Pour WTTJ, interroger l’index Algolia que le site appelle lui-même (clé search-only publique) est bien plus stable que parser du HTML (moins d’une heure de travail, contre plusieurs jours en parsing). Le piège : sans le bon slug d’entreprise, l’API renvoie zéro résultat sans erreur, et le signal disparaît en silence. Détail : signaux d’expansion avec WTTJ, LinkedIn et n8n.
Veille concurrentielle. Un avis isolé est anecdotique ; quand Trustpilot, LinkedIn et le site racontent la même chose, le signal devient solide. Détail : veille concurrentielle multi-source.
Sortie SDR. Microsoft Lists avec des statuts simples, notifications Teams, suivi dans Power BI. Peu glamour, mais compris par une équipe déjà sous Microsoft.

Le scoring est volontairement lisible : des points selon la source, la fraîcheur (moins de 30 jours), la présence de plusieurs sources et l’adéquation à l’ICP, plafonnés à 100. Il sert à trier, pas à prédire.

Les chiffres

Après plusieurs semaines, les signaux venaient à 35 % de LinkedIn, 25 % de WTTJ, 20 % des sites et actualités, 12 % de Trustpilot et 8 % de la détection technique. La pertinence estimée est presque inversée :

Source	Pertinence estimée	Commentaire
Détection technique	~70 %	Précis si les signatures sont bonnes
WTTJ	~65 %	Fiable, dépend du slug et de la déduplication
Trustpilot	~55 %	Biais vers les expériences extrêmes
Sites web / actualités	~45 %	Hétérogène, blogs souvent abandonnés
LinkedIn	~25 %	Beaucoup de marque employeur générique

Ce qui a coincé

La donnée web est sale. Redirections, certificats expirés, rendu JavaScript, blogs sans date, slugs qui ne ressemblent pas au nom de l’entreprise. Le coût n’est pas le premier crawler, c’est la gestion des exceptions.
L’IA appelée trop tôt. Envoyer du contenu brut au LLM donnait des réponses longues, des hallucinations et un JSON difficile à parser. Nettoyer, extraire les champs utiles, puis imposer un JSON strict a stabilisé la sortie.
Les doublons. Même post récupéré deux fois, offre WTTJ republiée, page crawlée à plusieurs dates. Un hash company_id:source:title:published_at a réglé le problème.
Le volume. 200 signaux faibles par semaine, c’est inutilisable. Le bon indicateur est le nombre de signaux actionnables, pas le nombre détecté.
n8n qui grossit. Très rapide pour prototyper, mais dès que la logique métier s’étoffe, il faut sous-workflows, nommage, logs et sorties normalisées.

Si je recommençais, je versionnerais les prompts dès le départ (une colonne prompt_version sur chaque signal), je construirais un jeu de cas métier (« post marque employeur générique → non pertinent ») et je sortirais plus tôt la logique métier de n8n.

À retenir

Un système RevOps utile n’est pas celui qui automatise le plus, c’est celui qui rend le bon contexte disponible au bon moment. L’IA y sert à classer et résumer des données déjà structurées ; si une règle simple suffit, je garde la règle. Et la décision reste humaine : le SDR voit la source, peut invalider le signal et choisir de ne pas contacter.