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

Construire un pipeline d'enrichissement d'entreprises B2B

Vous devez enrichir des milliers d'entreprises chaque jour à partir d'annuaires, de sites web et de la presse ? Voici comment construire un pipeline d'enrichissement B2B qui ne casse pas toutes les semaines.

b2blead generationdata enrichmentcompany enrichmentuse case

Le défi

Vous construisez 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 quelques jours. Et ils s'attendent à ce qu'elle soit exacte.

Les données existent. Elles se trouvent 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 se comporte différemment lorsqu'elle casse. Crunchbase propose une application côté client lourde qui se regénère si elle suspecte un robot. LinkedIn applique des rate limits agressifs et modifie son DOM plus rapidement que vous ne pouvez corriger vos sélecteurs (un article de communauté populaire évalue un scraper Python de base à environ 50 profils avant que le mur anti-bot ne tombe). 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 leurs mises en page chaque trimestre et bloquent l'accès selon le pays. Selon un rapport sectoriel 2026 de GroupBWT, 10 à 15 % des crawlers dans certains secteurs nécessitent des corrections hebdomadaires simplement pour suivre les mises à jour anti-bot et les dérives du DOM.

Votre pipeline d'enrichissement commence donc par une architecture propre à cinq sources. Six mois plus tard, c'est un enchevêtrement de scrapers à moitié cassés, de files d'attente de tentatives et d'un canal Slack nommé #scraper-alerts que plus personne n'ouvre (nous avons déjà écrit sur le coût caché de la maintenance de vos propres scrapers). Les plaintes concernant la qualité des données s'accumulent dans votre file d'attente de support. Votre équipe commence à plaisanter en disant que le nom de l'entreprise aurait dû être « 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 a besoin de quel outil, de quel proxy, de quelle politique de retry, et ce qui constitue une « bonne » response.

Une plateforme comme FourA vous offre trois produits qui correspondent directement aux trois classes de sources que vous allez cibler.

Annuaires et registres HTML statiques. 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 request HTTP rapide et légère depuis une IP propre. C'est Single : une URL en entrée, une response en sortie. Ajoutez unblocker: true et cela permet de franchir les blocages au niveau du handshake qui stoppent net un client HTTP classique. Single passe automatiquement par Proxy Finder en arrière-plan et renvoie l'identifiant du proxy au niveau supérieur de la response (r.proxy) afin que vos appels suivants puissent le renvoyer sous la forme proxy:"<id>" pour conserver la même sortie lorsque vous avez besoin d'une continuité de session.

Applications monopages (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 response HTTP. Ils effectuent le rendu côté client. C'est Browser : un navigateur complet exécute la page, lance le JavaScript et vous renvoie l'HTML généré, les cookies et des captures d'écran. Comme Single, il passe par Proxy Finder en arrière-plan, sans étape de sélection distincte de votre côté.

Sources mixtes avec validation. Chaque request envoyée à l'API de FourA accepte un bloc validate. Vous pouvez exiger des codes d'état spécifiques, des correspondances de headers ou des correspondances de sous-chaînes dans le corps. Si la response est un échec partiel (une page 200 avec un CAPTCHA, une structure de données vide ou un écran intermédiaire « nous sommes désolés »), le validateur la rejette. Votre pipeline peut alors router la même URL via Browser à la place. Cette seule fonctionnalité élimine la catégorie de bug la plus coûteuse en enrichissement : l'échec silencieux qui écrit des données aberrantes dans votre base de données.

Voici la structure d'un appel à source unique :

curl -X POST https://api.foura.ai/api/single \
  -H "Authorization: Bearer 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 riche en JavaScript :

curl -X POST https://api.foura.ai/api/browser \
  -H "Authorization: Bearer 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 quel outil attribuer à chacune de vos sources. Nous nous assurons que l'outil parvient bien à destination.

Résultats

Nous avons vu plusieurs équipes abandonner leurs scrapers internes au profit d'un pipeline routé par FourA pendant la bêta publique. Le schéma est constant (chiffres illustratifs basés sur nos observations au sein de la cohorte bêta) :

  • La latence d'enrichissement passe de 3 à 6 secondes par entreprise à une valeur médiane inférieure à 1,5 seconde sur les routes résidentielles mises en cache
  • Le taux d'échec silencieux (responses 200 avec des données vides) chute d'environ 8 % à moins de 1 % dès lors que le bloc validate intercepte les échecs partiels avant qu'ils n'atteignent la base de données
  • Le temps d'ingénierie consacré à la maintenance des scrapers passe de 1 ou 2 ingénieurs à plein temps à un canal Slack qui reste généralement silencieux
  • Le taux de réussite au premier essai sur les annuaires protégés dépasse les 90 % lorsque unblocker: true est associé à un identifiant de proxy propre

Un autre chiffre mérite d'être souligné : nous avons constaté que l'exactitude au premier essai (les bonnes données pour la bonne entreprise) accuse un retard d'environ quatre points par rapport au succès au premier essai. La leçon n'est pas que le scraping est difficile. C'est que vous devez toujours valider la fiche par rapport à l'entreprise demandée (nous avons décrit ce schéma dans pourquoi votre scraper web continue de casser).

Les chiffres qui comptent ne sont pas la taille du pool de proxies ou le nombre de requests. Ce sont le taux auquel votre endpoint d'enrichissement renvoie les bonnes données dès le premier essai, et la courbe de votre graphique de maintenance des scrapers sur les six prochains mois.

Ce qu'il faut retenir

Les pipelines d'enrichissement tombent en panne au ralenti. Le premier scraper que vous écrivez semble fonctionner correctement un mardi. À la troisième source, vous corrigez des sélecteurs à 23 heures. À la dixième, vous portez une dette de maintenance qui évolue au rythme de votre base de clients. À la vingtième, vous avez discrètement cessé d'intégrer de nouvelles sources parce que personne dans l'équipe ne souhaite s'occuper de la suivante.

Le goulot d'étranglement n'a jamais été la source. C'est 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, confiez-la à un outil qui s'en charge déjà, et votre équipe pourra consacrer son mardi au produit plutôt qu'au tri des sélecteurs cassés.