← Tous les articles
Cas d'usage 6 min de lecture

Construction d'un pipeline d'enrichissement d'entreprises B2B

Vous devez enrichir quotidiennement des milliers d'entreprises à partir d'annuaires, de sites web et de la presse ? Voici comment construire un pipeline d'enrichissement B2B qui ne tombe pas en panne chaque semaine.

b2blead generationdata enrichmentcompany enrichmentuse case

Le défi

Vous développez un produit SaaS B2B. Vos clients importent une liste de noms d'entreprises. Ils s'attendent à recevoir une fiche propre en retour : tranche de chiffre d'affaires, effectif, stack technique, levée de fonds, contacts clés, actualités récentes. Ils l'attendent en quelques minutes, pas en plusieurs jours. Et ils s'attendent à ce qu'elle soit exacte.

La donnée existe. Elle se trouve sur Crunchbase, sur les pages À propos des entreprises, sur les pages d'entreprises LinkedIn, sur Google Maps, sur Glassdoor, sur les registres du commerce régionaux, sur les archives de TechCrunch. Le problème est d'y accéder de manière fiable.

Chaque source casse différemment. Crunchbase sert une application côté client lourde qui se réexécute si elle soupçonne un bot. LinkedIn applique un rate limit agressif et modifie son DOM plus vite que vous ne pouvez corriger vos sélecteurs (un article communautaire populaire estime qu'un scraper Python standard est bloqué après environ 50 profils). Les sites web d'entreprises vont du simple HTML statique aux applications monopages qui nécessitent un navigateur complet pour afficher leur contenu. Les annuaires régionaux modifient leur structure chaque trimestre et bloquent les accès hors de leur zone géographique. Selon un rapport sectoriel 2026 de GroupBWT, 10 à 15 % des crawlers dans certains secteurs nécessitent des correctifs hebdomadaires uniquement pour suivre les évolutions de détection de bots et les dérives du DOM.

Votre pipeline d'enrichissement commence donc avec une architecture propre à cinq sources. Six mois plus tard, c'est un enchevêtrement de scrapers à moitié cassés, de files d'attente de retry et d'un canal Slack nommé #scraper-alerts que plus personne n'ouvre (nous avons déjà abordé le coût caché de la maintenance de vos propres scrapers). Les réclamations sur la qualité des données s'accumulent dans votre support. Votre équipe commence à plaisanter en disant que l'entreprise aurait dû s'appeler "Cinq scrapers et une prière".

L'approche

Oubliez les scrapers un instant. La partie difficile de l'enrichissement n'est pas l'extraction. C'est le routage : décider quelle source nécessite quel outil, quel proxy, quelle politique de retry, et ce qui constitue une réponse valide.

Une plateforme comme FourA vous fournit trois produits qui correspondent directement aux trois catégories de sources que vous allez rencontrer.

Annuaires et registres en HTML statique. La plupart des registres du commerce régionaux et de nombreux annuaires B2B plus anciens sont générés côté serveur. Ils nécessitent une requête HTTP rapide et légère depuis une IP propre. C'est le rôle de Single : une URL en entrée, une réponse en sortie. Ajoutez unblocker: true et vous franchissez les blocages au niveau du handshake qui arrêtent net un client HTTP standard. Single route automatiquement via Proxy Finder et renvoie le proxy id au niveau racine de la réponse (r.proxy), permettant à vos appels suivants de le transmettre sous forme de proxy:"<id>" pour conserver la même IP de sortie si vous avez besoin d'une continuité de session.

SPA riches en JavaScript. Crunchbase, les applications de type LinkedIn et même les sites d'entreprises de taille moyenne ne renverront pas les données souhaitées à partir d'une simple réponse HTTP. Ils effectuent le rendu côté client. C'est le rôle de Browser : un navigateur complet exécute la page, lance le JS et vous renvoie le HTML rendu, les cookies et les captures d'écran. Comme Single, il passe par Proxy Finder en coulisses, sans étape de sélection distincte de votre côté.

Sources mixtes avec validation. Chaque requête adressée à l'API de FourA accepte un bloc validate. Vous pouvez exiger des codes d'état spécifiques, des correspondances d'en-têtes ou des correspondances de sous-chaînes dans le corps. Si la réponse est un échec partiel (une page 200 demandant une vérification, une coquille de données vide ou un écran d'attente « nous sommes désolés »), le validateur la rejette. Votre pipeline peut alors rediriger la même URL via Browser. Cette seule fonctionnalité élimine la catégorie de bugs la plus coûteuse en enrichissement : l'échec silencieux qui écrit des données corrompues dans votre base de données.

Voici la structure d'un appel à source unique :

curl -X POST https://api.foura.ai/api/single \
  -H "X-API-Key: pk_live_..." \
  -d '{
    "url": "https://registry.example.com/company/123",
    "unblocker": true,
    "followRedirects": 5,
    "validate": {
      "status": { "accept": [200] },
      "data":   { "fail":   ["captcha", "blocked", "access denied"] }
    }
  }'

Et l'équivalent Browser pour un site d'entreprise utilisant intensivement JavaScript :

curl -X POST https://api.foura.ai/api/browser \
  -H "X-API-Key: pk_live_..." \
  -d '{
    "url": "https://www.example-saas.com/about",
    "unblocker": true
  }'

La logique de routage réside dans votre propre pipeline. La fiabilité réside dans le nôtre. Vous décidez quelle source utilise quel outil. Nous nous assurons que l'outil aboutit réellement.

Résultats

Nous avons suivi plusieurs équipes ayant migré de scrapers internes vers un pipeline routé par FourA pendant la bêta publique. La tendance est constante (chiffres indicatifs basés sur ce que nous avons observé sur la cohorte bêta) :

  • Latence d'enrichissement : chute de 3 à 6 secondes par entreprise à une médiane inférieure à 1,5 seconde sur les routes résidentielles en cache
  • Taux d'échec silencieux (réponses 200 avec des données vides) : chute d'environ 8 % à moins de 1 % dès que le bloc validate intercepte les échecs discrets avant qu'ils n'atteignent la base de données
  • Temps d'ingénierie sur la maintenance des scrapers : passe de 1 ou 2 ingénieurs à temps plein à un canal Slack globalement silencieux
  • Taux de réussite au premier essai sur les annuaires protégés : grimpe au-delà de 95 % lorsque unblocker: true est associé à un identifiant de proxy propre

Un autre chiffre mérite d'être souligné : nous avons constaté que l'exactitude dès le premier essai (bonnes données, bonne entreprise) accusait un retard d'environ quatre points sur le succès brut. La leçon n'est pas que le scraping est difficile. C'est que vous devez toujours valider l'enregistrement par rapport à l'entreprise demandée (nous avons détaillé ce modèle dans pourquoi votre scraper web ne cesse de casser).

Les métriques importantes ne sont ni la taille du pool de proxys ni le volume de requêtes. Ce sont la fréquence à laquelle votre endpoint d'enrichissement renvoie les bonnes données dès le premier essai, et l'évolution de la courbe de maintenance de vos scrapers au cours des six prochains mois.

Ce qu'il faut retenir

Les pipelines d'enrichissement tombent en panne au ralenti. Le premier scraper que vous écrivez fonctionne parfaitement un mardi. À la troisième source, vous patchez des sélecteurs à 23 h. À la dixième, vous accumulez une dette de maintenance proportionnelle à votre base de clients. À la vingtième, vous cessez discrètement d'ajouter de nouvelles sources car personne dans l'équipe ne veut assumer la suivante.

Le goulot d'étranglement n'a jamais été la source. C'était le routage : choisir le bon outil, le bon proxy, la bonne règle de validation pour chaque URL, à chaque fois. Construisez cette couche une fois, déléguez-la à un système conçu pour cela, et votre équipe pourra consacrer son mardi au produit plutôt qu'à réparer des sélecteurs cassés.