Au-delà des API : pourquoi 65% des entreprises font désormais du scraping de données pour entraîner l’AI

Il y a tout juste 5 ans, lorsqu’on parlait d’obtenir des données pour une entreprise, un seul terme revenait : API. Le fournisseur propose un endpoint, vous signez un contrat, payez les appels et obtenez un flux de données structuré et net. Cela semblait être une solution universelle au problème de l’accès aux données.

Le développement de l’AI générative a entièrement réécrit cette règle. Selon différentes données, 65% des entreprises qui développent ou entraînent des modèles d’AI utilisent déjà le web scraping comme source de données principale ou complémentaire, avec les API ou en les remplaçant. Il ne s’agit ni d’une anomalie temporaire ni d’un détour pour ceux qui ne trouvent pas de fournisseur d’API adapté. C’est un changement fondamental dans la manière dont les entreprises considèrent les données comme des actifs.

Si votre entreprise construit un pipeline de ML, entraîne un LLM à partir de ses propres données sectorielles ou alimente des systèmes RAG avec des informations publiques à jour, la question passe de « Avons-nous besoin de scraping ? » à « Comment développer nos activités de scraping, les maintenir légales et stables ? » Ici, l’infrastructure est déterminante.

Faits essentiels :

• Les LLM ont besoin d’un volume immense d’informations à jour et propres à chaque zone géographique afin de produire des réponses utiles lors de l’entraînement.
• Les API fournissent des volumes limités de données qui ne sont pas actualisées en temps réel. Elles ignorent aussi de nombreuses sources utiles, comme les forums locaux, qui peuvent ne pas disposer d’endpoint API.
• Le scraping remplace les API, car il permet d’obtenir une quantité illimitée de données depuis de nombreuses sources, de cibler des contenus propres à une zone géographique et de ne manquer aucun changement.
• La réussite du scraping dépend non seulement du code du scraper, mais aussi de l’infrastructure qui permet de contrôler les sessions, de répartir le trafic, de définir des paramètres de ciblage et d’imiter le comportement d’utilisateurs réels pour éviter les refus.
• DataImpulse est un fournisseur de proxies éthique qui propose des proxies residentiels, mobiles et de datacenter prêts pour le scraping dans 195 localisations. Un pool de 90M+ proxies, une facturation au Go, du trafic sans expiration et une assistance humaine 24 h/24, 7 j/7 rendent les proxies DataImpulse adaptés non seulement au web scraping, mais aussi à la collecte de données pour l’AI, au suivi des prix, à l’ad verification, au suivi des SERP et plus encore.

Pourquoi les API ne répondent plus aux besoins des équipes d’AI

Les API sont parfaites lorsque le fournisseur de données sait exactement ce dont vous avez besoin et accepte de vous les fournir. Cependant, l’entraînement des modèles modernes requiert une approche totalement différente.

• Volume de données limité : la majorité des API ne renvoient que la quantité de données que le fournisseur a choisi de fournir. Les données historiques, les pages de niche, les images dans leur résolution d’origine, le balisage de page, tous ces détails sont souvent exclus des résultats d’API.
• Les limites de débit sont conçues pour les produits, pas pour le ML. À l’origine, les limites d’API étaient définies selon les besoins des intégrations entre applications, qui exigent des centaines à des milliers d’appels par jour. Obtenir des données pour entraîner un modèle de ML demande des millions de requêtes. Les échelles ne correspondent tout simplement pas.
• Délai entre l’événement et la disponibilité des données : pour certains modèles, comprendre le contenu actuel, comme les prix des concurrents, les actualités ou les tendances des réseaux sociaux, est crucial. La valeur des données diminue à chaque heure de retard. Or les API s’actualisent selon le calendrier du fournisseur, et non selon les évolutions en temps réel ni vos besoins.
• Coûts : les offres d’API destinées aux entreprises, conçues pour des volumes élevés, sont souvent plusieurs fois plus coûteuses que la création de votre propre pipeline de données, surtout lorsqu’il s’agit de données multimodales, telles que des images, vidéos, fichiers PDF, etc. De plus, les API ne fournissent tout simplement pas les données brutes correspondantes.
• Limites des sources de données accessibles : une énorme partie du WEB, notamment les forums locaux, les places de marché de moindre importance, les sites d’actualités régionaux et les sources de niche, ne possède pas d’API propre pour extraire les données. Pourtant, toutes sont des sources précieuses que vous ne pouvez pas exclure. Le web scraping est la seule solution dans ce cas.

Ce que les équipes d’AI recherchent réellement sur le Web

Parler de « données pour l’AI » reste vague tant que vous ne savez pas exactement quelles données recherchent les équipes d’entreprise :

• Corpus propres à un domaine pour entraîner les LLM : documents juridiques, publications médicales, documentation technique de niche, où les modèles génériques obtiennent de mauvais résultats.
• Données sur les prix des concurrents et la diversité des produits, pour l’entraînement de modèles d’intelligence tarifaire dynamique.
• Jeux de données multimodaux : images de produits, plans de locaux, textes de couverture pour des modèles de vision par ordinateur.
• Tendances et évolutions du sentiment issues de forums, d’avis et des réseaux sociaux, pour des modèles qui anticipent la demande ou les risques de réputation.
• Données alternatives pour les modèles financiers : offres d’emploi, images d’entrepôts, avis d’employés, tout ce qui procure plusieurs heures d’avance par rapport aux sources traditionnelles.

Tous ces cas ont un point commun : des données dispersées entre les domaines et actualisées chaque seconde. Et aucune API ne peut tout couvrir.

Quels problèmes pose le scraping à l’échelle de l’entreprise

Votre pipeline de scraping peut fonctionner parfaitement dans le cadre d’un projet pilote de 500 requêtes, puis, après des tests réussis et le passage au véritable scraping avec des millions de requêtes, tomber soudainement en panne. C’est que l’échelle révèle des problèmes impossibles à repérer sans une charge élevée.

• Refus d’IP

Les sites Web détectent en quelques minutes une activité anormale provenant d’une seule IP. Les IP de datacenter d’où arrivent des requêtes en masse sont mises sur liste noire plus vite qu’un processus de collecte de données ne peut se terminer.

• Contenu propre à une zone géographique

Les prix, la disponibilité et les publicités ciblées par région, toutes ces données n’existent pas si votre requête provient du « mauvais » endroit. Si un modèle doit comprendre les marchés brésilien, allemand ou japonais, le trafic doit sembler en provenir.

• CAPTCHA et fingerprinting de navigateur

Les systèmes modernes de protection contre les bots ne s’appuient pas uniquement sur l’analyse des IP : ils prennent également en compte les schémas comportementaux, les empreintes TLS, les headers de requêtes et d’autres signaux. En général, la détection s’effectue sur 5 couches. Si un seul de ces signaux paraît suspect, le scraper risque d’être bloqué et tout le pipeline devient aussi impuissant qu’un poisson échoué, jusqu’à ce qu’un développeur le corrige.

• Qualité des données

Pour être efficace, votre modèle a besoin de données exactes pour son entraînement. Lorsque votre scraper est bloqué à répétition, collecte des données partielles ou compromises, ou se retrouve pris dans des honey pots et autres pièges à scrapers, le modèle apprend de mauvais signaux et la valeur de son assistance est discutable. Le pire est que vous ne le découvririez qu’après avoir déjà investi beaucoup d’argent dans le scraping et l’entraînement.

• Risques juridiques et de conformité

Les équipes d’entreprise ne peuvent pas se permettre de faire du scraping et de voir ce qui se passera. Elles ont besoin d’une infrastructure qui leur permet de réguler la fréquence des requêtes, de respecter robots.txt et de documenter les sources pour les audits, particulièrement dans les secteurs et pays strictement réglementés.

Séparément, chacun de ces problèmes peut être résolu. Cependant, ils ne se présentent pas séparément : ils forment un ensemble. Les résoudre est un travail à part entière, pas un réglage ponctuel.

Quand l’infrastructure décide

Le meilleur scraper est inutile s’il est bloqué par la plateforme cible dès la deuxième minute. Le code est important, mais le système qui l’entoure ne doit pas non plus être sous-estimé.

• Rotation d’IP : un pool de proxies permet de répartir les requêtes afin qu’aucune IP ne s’approche du seuil de détection. Cela imite des schémas de trafic naturels, typiques d’utilisateurs. D’une certaine manière, votre scraper est aussi un utilisateur qui tente de comprendre une vaste quantité de données.
• Ciblage géographique précis : les requêtes doivent provenir de l’endroit pour lequel ce modèle établira ensuite des prévisions et travaillera. Si vous prévoyez d’utiliser un modèle pour prédire les prix au Japon, mais employez des données européennes, le modèle donnera ensuite des réponses non pertinentes pour le lieu cible, et cela se produira en phase de production, lorsqu’il sera le plus coûteux de le corriger.
• Fiabilité : le SLA d’uptime et le temps de réponse des proxies déterminent le temps que l’équipe de développement consacre à corriger le pipeline plutôt qu’à entraîner et améliorer le modèle lui-même. Pour les entreprises, les temps d’arrêt coûtent des sorties retardées.
• Contrôle des sessions : lorsque vous devez conserver la même session sans qu’une IP soit bloquée, même le scraper le plus sophistiqué ne suffit pas sans proxies.
• Conformité : les fournisseurs de proxies destinés aux entreprises qui proposent des pools d’IP obtenus de manière éthique et respectent les réglementations locales prennent une partie de la charge juridique des équipes d’AI, qui incomberait sinon aux équipes de conformité.

En résumé

Les entreprises qui commencent tout juste à développer leurs propres modèles traitent souvent un projet pilote de cent requêtes et un projet à grande échelle d’un million de requêtes comme une seule et même chose, simplement à une échelle supérieure. En réalité, ce sont deux choses différentes qui exigent des approches distinctes : pour un système prêt pour la production, le point faible n’est pas le scraper lui-même, mais la nécessité d’obtenir les données d’entraînement de manière légale, rapide et stable. La question n’est donc pas « Devons-nous vraiment passer des API au scraping de données, et avons-nous besoin de proxies pour cela ? », mais « Combien nous coûte une semaine supplémentaire perdue à travailler avec les données limitées que fournissent les API, pendant que nos concurrents lancent de nouveaux modèles et développent leur collecte de données ? »

Questions fréquemment posées