← 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 construisez un produit SaaS B2B. Vos clients téléchargent une liste de noms d'entreprises. Ils attendent un enregistrement propre en retour : tranche de revenus, effectifs, tech stack, cycle de financement, contacts clés, actualités récentes. Ils l'attendent en quelques minutes, pas en quelques jours. Et ils s'attendent à ce que ce soit exact.

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 TechCrunch. Le problème est d'y accéder de manière fiable.

Chaque source se brise différemment. Crunchbase sert une application côté client lourde qui se re-rend si elle soupçonne un bot. LinkedIn applique un rate limit agressif et modifie son DOM plus vite que vous ne pouvez corriger les sélecteurs (un article de communauté populaire évalue un scraper Python classique à environ 50 profils avant que le mur anti-bot ne tombe). Les sites web d'entreprises vont du HTML statique aux applications à page unique qui nécessitent un navigateur complet pour même afficher leur contenu. Les annuaires régionaux changent de mise en page chaque trimestre et se cachent derrière des blocages spécifiques aux pays. Selon un rapport de l'industrie de 2026 de GroupBWT, 10 à 15 % des crawlers dans certains secteurs verticaux nécessitent des correctifs hebdomadaires juste pour suivre les mises à jour anti-bot et la dérive du DOM.

Votre pipeline d'enrichissement commence donc comme une conception propre à cinq sources. Six mois plus tard, c'est un enchevêtrement de scrapers à moitié cassés, de files d'attente de réessai et d'un canal Slack appelé #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 sur 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 une minute. 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 réessai, et ce qui compte comme une "bonne" réponse.

Une plateforme comme FourA vous donne 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 beaucoup d'anciens annuaires B2B sont rendus sur le serveur. Ils veulent une requête HTTP rapide et à faible surcharge provenant d'une IP propre. C'est Single : une URL en entrée, une réponse en sortie. Ajoutez unblocker: true et il passe à travers les blocages au niveau du handshake qui arrêtent net un client HTTP classique. Single route à travers Proxy Finder automatiquement et retourne l'id du proxy au niveau supérieur de la réponse (r.proxy) afin que vos appels suivants puissent le renvoyer comme proxy:"<id>" pour conserver la même sortie lorsque vous avez besoin d'une continuité de session.

SPA lourdes en JavaScript. Crunchbase, les applications de style LinkedIn, et même les sites d'entreprises de taille moyenne ne retourneront pas les données que vous voulez à partir d'une simple réponse HTTP. Ils font le rendu sur le client. C'est 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 route à travers Proxy Finder en arrière-plan, sans étape de sélection séparée de votre côté.

Sources mixtes avec validation. Chaque requête à 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 avec un CAPTCHA, ou une coquille de données vide, ou un interstitiel d'excuses), le validateur la rejette. Votre pipeline peut alors router la même URL à travers Browser à la place. Cette seule fonctionnalité élimine la classe de bug la plus coûteuse dans l'enrichissement : l'échec silencieux qui écrit des données corrompues dans votre base de données.

Voici la forme 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 lourd 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 laquelle de vos sources reçoit quel outil. Nous nous assurons que l'outil passe réellement.

Résultats

Nous avons observé une poignée d'équipes passer de scrapers internes à un pipeline routé par FourA pendant la bêta publique. Le schéma est cohérent (chiffres illustratifs basés sur ce que nous avons vu dans la cohorte bêta) :

  • La latence d'enrichissement chute de 3 à 6 secondes par entreprise à moins de 1,5 seconde médiane sur les routes résidentielles en cache
  • Le taux d'échec silencieux (réponses 200 avec données vides) chute d'environ 8 % à moins de 1 % une fois que le bloc validate attrape les échecs partiels avant qu'ils n'atteignent la base de données
  • Le temps d'ingénierie sur la maintenance des scrapers chute de 1 à 2 ingénieurs à temps plein à un canal Slack qui reste pour la plupart silencieux
  • Le taux de succès au premier passage sur les annuaires protégés grimpe dans les 90 % lorsque unblocker: true est associé à un id de proxy propre

Un dernier chiffre mérite d'être signalé : nous avons vu l'exactitude au premier passage (bonnes données, bonne entreprise) être à la traîne par rapport au succès au premier passage d'environ quatre points. La leçon n'est pas que le scraping est difficile. C'est que vous devez toujours valider l'enregistrement par rapport à l'entreprise que vous avez réellement demandée (nous avons écrit sur ce modèle dans pourquoi votre web scraper continue de se casser).

Les chiffres qui comptent ne sont pas la taille du pool de proxy ou le nombre de requêtes. Ce sont le taux auquel votre endpoint d'enrichissement retourne les bonnes données du premier coup, et la pente de votre graphique de maintenance de scrapers au cours des six prochains mois.

À retenir

Les pipelines d'enrichissement échouent au ralenti. Le premier scraper que vous écrivez semble correct un mardi. À la troisième source, vous corrigez des sélecteurs à 23h. À la dixième, vous portez une dette de maintenance qui évolue avec votre base de clients. À la vingtième, vous avez discrètement arrêté d'intégrer de nouvelles sources car personne dans l'équipe ne veut s'occuper de 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, confiez-la à quelque chose qui le fait déjà, et votre équipe pourra passer son mardi sur le produit au lieu de trier les casses de sélecteurs.