Série Accelerator : Création d'un Web Scraper résilient avec LangGraph et TrueFoundry

L'équipe des ventes est paniquée. Une importante conférence sur les soins de santé aura lieu la semaine prochaine. Le site Web de l'événement répertorie 200 conférenciers - médecins, cadres et chercheurs - répartis sur une douzaine de sous-pages paginées. Pour créer une liste de prospects, quelqu'un doit ouvrir le site, cliquer sur un nom, copier les informations dans une feuille de calcul, ouvrir un nouvel onglet, rechercher cette personne sur LinkedIn, copier l'URL du profil, puis la recoller.

Ils doivent le faire 200 fois.

Pour les ingénieurs, cette requête aboutit généralement à un script Python rapide utilisant Selenium ou BeautifulSoup. Vous inspectez la source de la page, recherchez le div contenant la classe speaker-name et extrayez le texte. Il fonctionne parfaitement pendant environ une semaine. Ensuite, le site Web met à jour son framework frontal, les classes CSS changent et le script se bloque.

Nous avons construit le Profil Crawler accélérateur pour arrêter ce cycle. Il s'agit d'un agent autonome qui navigue sur les sites Web et extrait les données en fonction de ce que dit la page, et non de la structure du code HTML.

Voici comment nous avons conçu la solution en utilisant LangGraph pour l'orchestration, Playwright pour l'interaction et TrueFoundry pour gérer l'infrastructure.

Le changement : des sélecteurs DOM à l'extraction sémantique

La principale raison pour laquelle les scripts de scraping échouent est leur dépendance au Document Object Model (DOM). Si vous demandez à un script de rechercher div.content-wrapper > h2.title, il s'interrompt dès qu'un développeur modifie le nom d'une classe.

Nous sommes passés à une approche agentique. Nous ne le disons pas au bot où les données sont localisées au pixel près. Au lieu de cela, nous transmettons le code HTML rendu (converti en Markdown) à un LLM. Le modèle lit le texte comme le ferait un humain. Il comprend qu'une section intitulée « Conférenciers principaux » contient les données que nous voulons, quelles que soient les balises sous-jacentes.

• Ancienne méthode (fragile) : Sélecteurs CSS codés en dur qui s'interrompent lors des mises à jour de l'interface utilisateur.
• Nouvelle méthode (résiliente) : Compréhension sémantique qui s'adapte aux changements de mise en page.

Architecture en profondeur

Nous avions besoin d'un système capable de gérer la prise de décisions, et pas simplement d'un script linéaire. L'application doit décider : Cette entrée est-elle une URL ou simplement le nom d'une entreprise ? Avons-nous trouvé un captcha ? Cette page est-elle une liste de personnes ou une biographie unique ?

Nous avons choisi LangGraph pour modéliser ce flux de travail en tant que machine à états, en particulier lorsque Langflow et LangGraph les décisions favorisent une orchestration dynamique.

Le flux logique

Le système fonctionne en boucle plutôt qu'en ligne droite :

1. Routeur d'entrée : Le système vérifie si l'utilisateur a fourni une URL directe ou simplement le nom d'une entreprise. S'il s'agit d'un nom, il utilise un outil de recherche pour trouver d'abord le bon domaine.
2. Navigation furtive : Nous utilisons une instance de Playwright modifiée pour charger la page. Il gère automatiquement les bannières de consentement aux cookies et le chargement différé des images.
3. Filtrage vectoriel (optimisation) : Une seule page de conférence peut contenir 200 liens de navigation. Les alimenter tous dans une fenêtre contextuelle LLM est lent et coûteux. Nous utilisons Intégrée la plus rapide pour intégrer le texte du lien et interroger un local Qdrant instance. Cela permet de filtrer la liste jusqu'aux 10 liens les plus pertinents pour « Équipe » ou « Intervenants ».
4. Extraction : Le LLM analyse le contenu filtré et extrait les entités structurées (nom, rôle, entreprise).
5. Enrichissement : Enfin, nous parcourons les noms extraits et utilisons un outil de recherche (Tavily) pour trouver leurs profils LinkedIn spécifiques.

Voici l'architecture du système :

‍

Intégration de l'infrastructure et de TrueFoundry

L'exécution de navigateurs headless et d'agents LLM en production entraîne des problèmes opérationnels : fuites de mémoire provenant de Chromium, limites de débit des API LLM et nécessité d'isoler les processus.

Nous l'avons déployé sur True Foundry pour gérer ces contraintes spécifiques.

1. La passerelle AI (observabilité et mise en cache)

Cette application utilise largement les LLM pour les décisions de navigation. Sans gouvernance, les coûts grimpent rapidement en flèche. Nous acheminons tous les modèles d'appels via Passerelle TrueFoundry AI.

• Mise en cache : Si l'agent extrait deux fois le même site, la passerelle fournit des réponses LLM mises en cache pour les étapes d'extraction. Cela réduit considérablement la latence et les coûts.
• Limitation de débit : Nous fixons des limites strictes par utilisateur afin d'éviter l'épuisement des quotas d'API lors de tâches par lots volumineuses.
• Basculement : En cas d'interruption d'OpenAI, la passerelle redirige automatiquement les demandes vers Anthropic ou Azure OpenAI sans échouer le crawl.

2. Protocole de contexte modèle (MCP)

Nous avons structuré l'application à l'aide du Protocole de contexte modèle (MCP). Le « Crawler » n'est pas simplement une fonction Python ; c'est un serveur MCP. Cela nous permet de mettre en sandbox l'environnement du navigateur. Si le navigateur tombe en panne (ce qui arrive souvent sur les sites JavaScript lourds), il ne supprime pas la logique principale de l'application.

Schéma de l'infrastructure

Comparaison : script et agent

Nous avons comparé l'approche de script Python standard à cette architecture.

Manipulation des boîtiers Edge

Il est facile de construire le chemin du bonheur. Pour le rendre fiable, il a fallu résoudre trois problèmes d'ingénierie spécifiques :

1. Données dupliquées : Les profils apparaissent souvent sur plusieurs pages (par exemple, « Leadership » et « À propos de nous »). Nous avons ajouté un Nœud de déduplication à la fin du graphique. Il transmet la liste complète à un LLM plus petit et moins cher pour fusionner les enregistrements en fonction de la similitude des noms avant l'enrichissement.
2. Détection anti-bot : Le dramaturge standard est facilement détecté par les WAF modernes. Nous avons implémenté un dramaturge non détecté dans le conteneur Docker, qui corrige l'empreinte du navigateur (objet Navigator, fournisseur WebGL) pour qu'elle apparaisse comme un appareil utilisateur standard.
3. Limites de jetons : Les grandes pages avec des politiques de confidentialité et des pieds de page de page gaspillent des jetons. Nous utilisons découpage basé sur les en-têtes pour diviser le markdown. Le LLM ne traite que les parties relatives à « l'équipe » ou aux « conférenciers », rejetant le reste.

Conclusion

Cette architecture résout le « dernier kilomètre » de l'acquisition de données en remplaçant les scripts fragiles par des agents adaptatifs. En l'exécutant sur TrueFoundry, nous nous assurons que le système est observable, maîtrisé les coûts et évolutif.

Vous pouvez déployer cette architecture exacte, y compris la configuration Gateway et les agents Dockerisés, à partir de la bibliothèque d'applications TrueFoundry dès aujourd'hui.

‍