La plupart des workflows IA sont conçus pour la récupération, pas pour la recherche. Un agent récupère une page, en extrait ce dont il a besoin, répond à la question, et passe à autre chose. Posez-lui une question connexe le lendemain et il récupère à nouveau la même page. C'est très bien pour des consultations ponctuelles. Mais tout s'effondre dès que vous menez une recherche continue sur le même ensemble de sources.
La recherche est cumulative. Vous revenez aux sources, vous les comparez dans le temps, et vous posez de nouvelles questions à d'anciennes données. Si chaque question déclenche un nouveau crawl, votre assistant se comporte comme un moteur de recherche, pas comme un système de recherche. Le goulot d'étranglement n'est pas le crawling. C'est l'absence de mémoire.
Ce guide construit la mémoire manquante : un jeu de données de recherche persistant avec le Crawlbase Web MCP Server. Vous crawlez chaque page une seule fois, vous la stockez dans Crawlbase Cloud Storage sous forme d'instantané Markdown réutilisable, et vous exécutez chaque analyse ultérieure sur le jeu de données stocké plutôt que sur le web en direct. Un dépôt compagnon fournit les prompts, la configuration MCP, les URLs d'exemple, et un script d'ingestion utilisé tout au long du guide.
Pourquoi les workflows de recherche IA repartent sans cesse de zéro
Si vous avez déjà construit des workflows de recherche IA, vous connaissez le schéma. Vous demandez à un agent d'analyser la page de tarification d'un concurrent. Il crawle la page, extrait les détails, répond, et oublie. Quelques jours plus tard, vous posez une question différente sur la même entreprise, et il crawle à nouveau la page. La semaine suivante, vous comparez les fonctionnalités IA de dix concurrents, et chaque page est crawlée une troisième fois.
Rien n'est techniquement cassé. C'est ainsi que fonctionnent la plupart des systèmes de scraping IA aujourd'hui. Le problème, c'est que chaque question repart de zéro, parce que le système a été conçu autour de la récupération : récupérer, répondre, jeter.
La collecte continue est parfois précisément le but recherché. Un outil de surveillance de produits IA revisite les pages selon un calendrier justement pour détecter les nouveaux prix, les changements de stock ou les évolutions de notes. La recherche, elle, est différente. Vous ne guettez pas ce qui a changé lors de la dernière heure ; vous construisez un savoir que vous pourrez revisiter, comparer et réinterroger pendant des semaines. Traitez donc les pages comme des ressources réutilisables, pas comme des entrées jetables : crawlez une fois, stockez, et laissez l'analyse s'exécuter sur le jeu de données.
Architecture : des pages web aux ressources de recherche
Dès lors que vous traitez le contenu web comme un jeu de données plutôt que comme un résultat de recherche, la collecte et l'analyse deviennent deux problèmes distincts. Le Web MCP Server gère les deux ; Cloud Storage préserve les instantanés après la fin de la conversation ; un petit manifeste est le catalogue qui les relie entre eux.
Au lieu de revisiter un site à chaque nouvelle question, l'assistant travaille sur des instantanés qui existent déjà. Le manifeste indexe ce qui a été collecté (URLs, horodatages de crawl, noms d'entreprises, identifiants de stockage) sans forcer chaque document en mémoire.
Quand vous travaillez sur des dizaines ou des centaines de pages, les charger toutes est un gaspillage. Explorez d'abord les métadonnées, réduisez l'ensemble, et ne récupérez les documents complets que lorsqu'ils le méritent. Cela garde l'analyse rapide dès maintenant et compte encore plus à mesure que le jeu de données grandit.
Connectez le Web MCP Server
Pointez votre client MCP vers le Crawlbase Web MCP Server avant de construire quoi que ce soit. Si vous voulez d'abord un tour d'horizon plus complet de ce que le serveur expose, consultez notre introduction au Crawlbase Web MCP Server.
{ "mcpServers": { "crawlbase": { "type": "stdio", "command": "npx", "args": ["@crawlbase/mcp@latest"], "env": { "CRAWLBASE_TOKEN": "YOUR_TOKEN", "CRAWLBASE_JS_TOKEN": "YOUR_JS_TOKEN" } } } }
Le dépôt compagnon inclut un mcp-config.sample.json prêt à l'emploi. Déposez-le dans Cursor, Codex, ou tout client compatible MCP, remplacez les emplacements réservés aux tokens par vos identifiants Crawlbase, et redémarrez. Vous devriez alors voir des outils comme crawl_markdown, storage_count, storage_list, storage_get et storage_bulk_get. À partir de là, l'assistant peut crawler, stocker, récupérer et gérer le jeu de données sans aucun code personnalisé.
Construisez le jeu de données une seule fois
La liste d'URLs d'exemple contient vingt pages de tarification SaaS publiques. Le prompt de construction crawle chacune d'elles, stocke un instantané Markdown, et enregistre les métadonnées dans output/dataset-manifest.json.
Le seul paramètre qui compte est store=true. Sans lui, une page n'existe qu'à l'intérieur de la conversation en cours ; quand la session se termine, le contenu disparaît et la question suivante nécessite un nouveau crawl. Avec lui, Crawlbase conserve l'instantané dans Cloud Storage et retourne un RID que vous pouvez utiliser pour récupérer le document plus tard. Ce simple indicateur est ce qui transforme un flux de réponses temporaires en un jeu de données réutilisable.
Travaillez sur le jeu de données, pas sur le web
Une fois les pages stockées, le workflow change : vous interrogez un jeu de données, vous ne parcourez plus des sites. Le prompt d'analyse commence par les métadonnées, pas par les documents.
storage_count storage_list storage_bulk_get(as=metadata_only)
Utilisez les métadonnées pour voir ce qui existe et décider quels enregistrements méritent un examen plus approfondi, puis récupérez le Markdown complet uniquement là où vous en avez besoin. À partir de là, le même prompt construit une comparaison entre concurrents : il classe les modèles de facturation, extrait les noms des plans et les prix phares, et signale si une offre gratuite existe. Au final, vous pouvez répondre à des questions comme quel modèle de facturation est le plus courant, qui utilise une tarification à l'usage, et combien de fournisseurs publient une offre gratuite, le tout sans jamais toucher à nouveau aux pages en direct.
Détectez les changements dans le temps
« Quels concurrents ont modifié leur modèle de tarification au cours des trois derniers mois ? » est une question courante d'intelligence concurrentielle, et elle ne fonctionne que si vous avez conservé l'historique. Le prompt de détection de changements compare les instantanés dans le temps.
Avec un seul instantané par concurrent, il classe le modèle actuel et explique que les comparaisons dans le temps ne sont pas encore possibles. Avec plusieurs instantanés, il compare les versions et fait ressortir les évolutions réelles : le passage d'une tarification par siège à une tarification à l'usage, un forfait fixe qui devient hybride, ou une refonte de l'offre. Chaque crawl ajoute une couche. Le premier vous donne de la visibilité, le deuxième vous donne une comparaison, le troisième commence à révéler une tendance.
Au fil du temps, le jeu de données cesse d'être un tas de pages et devient un enregistrement de la façon dont ces pages évoluent.
Réutilisez et faites le ménage
Le bénéfice des instantanés stockés apparaît après la collecte : de nouvelles questions ne signifient plus de nouveaux crawls. Le prompt de réutilisation exécute des analyses entièrement différentes sur les mêmes vingt pages, notamment qui propose une offre gratuite, qui affiche côte à côte une tarification annuelle et mensuelle, qui mise sur une tarification à l'usage, et qui met en avant des fonctionnalités IA sur la page de tarification. Le matériau source est déjà collecté ; l'assistant lui pose simplement de nouvelles questions. Si vous voulez que l'agent agisse sur ces données dans une boucle en direct plutôt que d'analyser un ensemble stocké, consultez Créer des workflows d'agents IA avec le Web MCP.
Quand un projet se termine, supprimez les instantanés dont vous n'avez plus besoin afin qu'ils n'encombrent pas les sessions futures. Le prompt de nettoyage liste les enregistrements stockés, demande une confirmation, et supprime par lots. Parce que la suppression est irréversible, il confirme toujours avant de retirer quoi que ce soit.
Automatisez la collecte
Exécuter les prompts à la main est idéal tant que vous explorez. Une fois le workflow devenu routinier (mêmes sources, selon un calendrier, jeux de données qui grandissent), automatisez l'étape de collecte. Le ingest_dataset.py du dépôt fait exactement cela via la Crawling API.
pip install -r requirements.txt export CRAWLBASE_TOKEN="YOUR_CRAWLBASE_TOKEN" python ingest_dataset.py --urls urls.saas-pricing.txt
Le script lit la liste d'URLs, demande chaque page en Markdown, stocke l'instantané, et écrit un manifeste. La requête elle-même est délibérément simple :
response = requests.get( "https://api.crawlbase.com/", params={ "token": token, "url": url, "format": "md", "md_readability": "true", "store": "true", }, )
Elle demande une sortie Markdown avec format=md, active la lisibilité avec md_readability=true, et stocke le résultat avec store=true. Plutôt que de sauvegarder localement le corps des documents, elle capture ce dont elle a besoin pour les récupérer plus tard, le plus important étant le RID que Cloud Storage retourne pour chaque page. Ces enregistrements atterrissent dans output/dataset-manifest.json :
{ "generated_at": "...", "entry_count": 20, "stored_count": 20, "entries": [...] }
Considérez le manifeste comme le catalogue : les documents vivent dans Cloud Storage, et le manifeste enregistre comment les retrouver. Il accomplit le même travail que le workflow MCP, mais de façon reproductible.
De l'infrastructure plutôt que du re-crawling
Construire un jeu de données de recherche implique normalement d'assembler un crawler, une couche de stockage, un mécanisme de récupération, et un workflow d'analyse. Le Crawlbase Web MCP Server condense l'essentiel de tout cela en outils qui vivent à l'intérieur de Cursor, Codex, et d'autres clients MCP, et Cloud Storage garde les instantanés accessibles longtemps après le crawl.
Cela change l'équation économique. Collectez le contenu une seule fois et réutilisez-le à travers de nombreuses analyses, et chaque page devient une ressource de recherche plutôt qu'une réponse jetable. La valeur du jeu de données augmente tandis que le coût de la collecte reste à peu près fixe. La même idée sous-tend les pipelines d'apprentissage automatique, où les données collectées sont réutilisées à travers l'entraînement et l'évaluation ; voyez Web Scraping pour l'apprentissage automatique pour cet angle. Pour de la recherche de marché et de l'intelligence concurrentielle continues, ce basculement vaut souvent plus que le crawl lui-même.
Donnez à votre client IA le crawling, le stockage et la récupération dans un seul ensemble d'outils. Chaque crawl rend le JavaScript derrière une IP résidentielle rotative et retourne un Markdown propre, avec les instantanés préservés dans Cloud Storage en vue d'une réutilisation. Pas de pool de proxys, pas de flotte headless, pas de code personnalisé. Construisez votre premier jeu de données sur l'offre gratuite.
Points clés à retenir
- Les systèmes de recherche et les systèmes de récupération résolvent des problèmes différents ; la plupart des workflows IA sont conçus pour la récupération.
- Re-crawler les mêmes pages pour chaque question paie le coût de la collecte encore et encore.
- Le stockage persistant sépare l'acquisition de l'analyse, de sorte qu'un seul crawl sert à de nombreuses questions futures.
- L'exploration axée sur les métadonnées passe mieux à l'échelle que le chargement de chaque document.
- Les instantanés historiques sont ce qui rend possibles l'analyse de tendances et la détection de changements.
- Un jeu de données de recherche gagne en valeur au fil du temps parce que le coût de la collecte est amorti sur chaque question ultérieure.
- Le Crawlbase Web MCP Server combine le crawling, le stockage, la récupération et l'analyse en un seul workflow, et le dépôt compagnon en est une implémentation fonctionnelle.
Questions fréquentes
Quelle est la différence entre un jeu de données de recherche IA et une base de connaissances RAG ?
Une base de connaissances RAG est optimisée pour récupérer le contexte pertinent au moment de la requête : les documents sont découpés en fragments, transformés en embeddings, et recherchés afin qu'un modèle puisse répondre avec le bon contexte. Un jeu de données de recherche IA est optimisé pour l'accumulation : l'objectif est de collecter et de préserver l'information dans le temps afin qu'elle puisse alimenter de nombreuses analyses futures, notamment le RAG, l'intelligence concurrentielle, la recherche de marché et la détection de tendances. Vous pouvez construire un système RAG à partir d'un jeu de données de recherche, mais le jeu de données est plus large que n'importe quel pipeline de récupération unique.
Pourquoi stocker les pages web au lieu de les crawler à chaque fois ?
Le crawling répété convient aux questions ponctuelles mais est inefficace pour la recherche continue. Disons que vous collectez aujourd'hui vingt pages de tarification de concurrents ; demain vous comparez les fonctionnalités IA, la semaine suivante vous analysez les remises annuelles, un mois plus tard vous examinez l'offre entreprise. Les pages n'ont peut-être pas changé, et pourtant le crawling répété vous fait payer le coût de la collecte à chaque fois. Stocker les instantanés sépare l'acquisition de l'analyse, de sorte que le même jeu de données répond à de nombreuses questions futures sans jamais toucher à nouveau aux sources originales.
Pourquoi utiliser Markdown plutôt que du HTML brut ?
Le Markdown conserve l'information qui compte et abandonne l'essentiel du bruit de présentation. Les titres restent des titres, les listes restent des listes, les tableaux restent lisibles. Le HTML brut transporte des menus de navigation, des scripts et du style qui ajoutent peu à la recherche, et les instantanés Markdown sont plus faciles à lire, analyser, découper en fragments, transformer en embeddings et comparer d'une version à l'autre.
Puis-je utiliser cette approche pour des données autres que des pages de tarification SaaS ?
Oui. Le dépôt utilise des pages de tarification parce qu'elles sont faciles à appréhender et qu'elles illustrent des workflows d'intelligence concurrentielle, mais la même architecture convient à la documentation produit, aux rapports sectoriels, aux dépôts publics, aux articles de presse, au contenu des bases de connaissances, aux ressources académiques et aux sources de recherche de marché. Le workflow d'acquisition et de stockage reste le même, quel que soit ce que vous collectez.
Le Crawlbase Web MCP Server remplace-t-il les bases de données vectorielles et les embeddings ?
Non. Le Web MCP Server gère l'acquisition, le stockage et la récupération des documents sources. Les bases de données vectorielles et les modèles d'embeddings interviennent quand vous voulez de la recherche sémantique, des pipelines RAG, ou de la récupération basée sur la similarité. De nombreuses équipes utilisent le Web MCP Server comme couche d'acquisition et alimentent ensuite les documents stockés dans des pipelines d'embeddings, des stores vectoriels, ou des agents, de sorte que le jeu de données devient le socle sur lequel d'autres systèmes IA sont construits.
Crawlez n'importe quel site à grande échelle, sans combattre l'infrastructure.
Crawlbase gère les proxies, les empreintes et les CAPTCHA afin que votre équipe livre des pipelines de données au lieu de maintenir la plomberie de crawl. 1 000 requêtes gratuites, sans carte requise.