Contexte
Ces outils servent de brique amont dans une chaîne de prospection et d'exploitation. La valeur n'est pas seulement dans l'interface, mais dans la capacité à récupérer, qualifier et transmettre les bonnes informations.
Le besoin
Le besoin n'était pas de collecter des données pour le principe. Il fallait construire une logique exploitable par d'autres briques, notamment la prospection, les agents et le CRM.
La réponse construite
Construction d'outils de lancement, de sélection et de collecte, capables d'alimenter des workflows plus larges de qualification et d'exploitation commerciale.
Ce que ce projet montre concrètement
Ces outils servent surtout à rendre la collecte et la qualification plus exploitables dans une chaîne de prospection plus large.
Fonctions clés
Interconnexions
Ce que cela change
Ce qui était dur, ce qu'on a tranché
Enjeux techniques
- Identifier les bonnes sources et arbitrer entre annuaires publics, APIs payantes et scraping browser
- Tenir face aux protections anti-bot (Cloudflare, rate limits, fingerprinting) sans se faire bannir
- Normaliser des schémas hétérogènes entre sources pour produire une donnée exploitable en aval
- Gérer la fraîcheur de la donnée — savoir quand re-scraper sans tout retraiter
- Maîtriser les coûts d'enrichissement payant (Apollo, Hunter, etc.) sans dégrader la couverture
Choix de stack
- Node.js + TypeScript
Manipulation de strings/JSON omniprésente, écosystème scraping mature (Playwright, Cheerio), cycle de dev rapide. Un seul langage du scraper au dashboard.
- Playwright
Pour les sites SPA qui ne servent rien sans JavaScript. Plus stable que Puppeteer sur le long terme, support multi-browser pratique pour contourner certains anti-bots.
- Postgres avec colonnes jsonb
On stocke la donnée brute en jsonb (rejouable si la logique change) et la donnée normalisée en colonnes typées (requêtable rapidement). Le meilleur des deux mondes.
- BullMQ pour la file de scraping
Paralléliser sans tuer les sites cibles. Throttle par source, retry exponentiel, dead-letter queue pour analyser les échecs.
- Hébergement self-hosted
Les datacenters AWS/GCP sont blocklistés par défaut sur les anti-bots sérieux. Notre infra avec IPs résidentielles + proxies évite 80% des blocages dès le départ.
Difficultés rencontrées
Les sites changent sans prévenir
Les sélecteurs CSS deviennent obsolètes du jour au lendemain. On a versionné les adapters par source et mis en place des alertes si le scraping retourne 0 résultat ou un schéma anormal.
Anti-bot agressif
Cloudflare, Datadome, Akamai. On a mis en place une rotation de proxies résidentiels, des headers réalistes, du throttle adaptatif par source, et basculé sur Playwright headed pour les cas durs.
Données sales
Formats de date hétérogènes, accents perdus, capitalisation aléatoire, doublons cachés. Pipeline de normalisation strict avec règles versionnées et possibilité de rejouer sur la donnée brute.
Coût des APIs d'enrichissement
Un appel Apollo coûte cher, multiplié par 50K leads ça pique. Cache 30j sur les enrichissements, batchs nocturnes, filtrage en amont pour ne payer que ce qui sera réellement exploité.
Ce qu'on a appris
- Commencer par 1 source bien maîtrisée plutôt que 10 sources approximatives. La qualité de pipeline prime sur la quantité de connecteurs.
- Toujours stocker la donnée brute AVANT normalisation. Si la logique de parsing change, on rejoue sans re-scraper.
- Logs détaillés et alertes > recovery automatique pendant les premiers mois. Mieux vaut savoir vite ce qui casse.
- Le budget anti-bot doit être pensé dès le jour 1, pas en feature à venir. C'est ce qui fait la différence entre un POC et un outil qui tient.
Quelques vues utiles pour voir comment le projet se présente concrètement.