Les assistants de codage IA génèrent des API, produisent des composants frontend, et écrivent des tests en quelques secondes. Mais un modèle ne peut raisonner que sur ce qu'il sait déjà ou sur ce que vous collez dans son contexte, et cela s'effondre dès l'instant où vous intégrez une API inconnue, travaillez avec une documentation qui a changé hier, ou construisez sur une plateforme en évolution rapide.
Demandez à Codex d'intégrer un nouveau service et il générera le client avec assurance, câblera l'authentification, et définira les variables d'environnement. Tout semble correct jusqu'à ce que vous le confrontiez à la documentation officielle : un paramètre requis manque, un endpoint a été renommé, l'authentification exige désormais un en-tête supplémentaire. Rien de tout cela n'est évident avant l'exécution, parce que le code généré paraît toujours plausible.
La solution habituelle consiste à briser votre élan : ouvrir la documentation dans un autre onglet, fouiller GitHub pour trouver le dernier README, coller les sections pertinentes dans le chat, et demander une régénération jusqu'à ce que tout concorde. La friction ne vient pas de l'écriture du code. Elle vient des allers-retours entre la recherche et l'implémentation.
Le Crawlbase Codex Plugin supprime cette coupure. Adossé au Crawlbase Web MCP Server, il donne à Codex un accès en direct au web via le langage naturel : crawler du HTML, extraire du Markdown propre, prendre des captures d'écran, et éventuellement conserver des pages dans Crawlbase Cloud Storage, le tout sans quitter votre éditeur. Un dépôt compagnon fournit les prompts, les fichiers d'exemple, et la structure de projet utilisés ici. Clonez-le avant de commencer :
git clone https://github.com/ScraperHub/turn-codex-into-a-full-stack-web-scraper.git cd turn-codex-into-a-full-stack-web-scraper
À la fin, vous aurez installé le plugin, vérifié son fonctionnement avec un test de fumée, récupéré de la documentation en direct directement depuis GitHub, et fait construire à Codex un scraper full-stack minimal à partir de cette documentation. Plus utile encore, vous disposerez d'un workflow applicable à presque toutes les tâches assistées par IA où une information exacte et à jour compte.
Pourquoi le développement assisté par IA a besoin de données web en direct
Les modèles excellent à raisonner sur le contexte qu'on leur fournit. Leur point faible n'est pas la programmation, c'est l'information qui a changé après l'entraînement. La documentation évolue en permanence : les SDK ajoutent des paramètres, les API déprécient des endpoints, les exigences d'authentification changent, et les notes de version portent des détails d'implémentation qui n'atteignent jamais les tutoriels.
Sans accès web en direct, la boucle est manuelle : demander à Codex d'intégrer une API, obtenir un code presque correct, le comparer à la documentation actuelle, recoller les différences dans le chat, et régénérer. Avec le plugin, Codex referme cette boucle lui-même.
Au lieu de rassembler la documentation à la main, Codex récupère la version actuelle avant d'écrire la moindre ligne de code.
Ce qu'est le Crawlbase Codex Plugin
L'écosystème des plugins OpenAI Codex vous permet d'étendre Codex avec des compétences réutilisables, des intégrations d'applications, et des serveurs MCP. Le Crawlbase Codex Plugin empaquette le Crawlbase Web MCP Server dans un plugin qui expose le crawling de production via le langage naturel. Une fois installé, vous pouvez demander à Codex de :
- Crawler une page web et retourner du HTML.
- Extraire du Markdown propre à partir d'un article.
- Prendre des captures d'écran pleine page.
- Crawler des sites rendus en JavaScript.
- Stocker les pages crawlées dans Crawlbase Cloud Storage, et les récupérer plus tard sans crawler à nouveau.
En coulisses, le plugin lance npx -y @crawlbase/mcp, transmet vos identifiants Crawlbase via des variables d'environnement, et dialogue avec l'infrastructure de crawling de Crawlbase. Le diagramme d'en-tête ci-dessus retrace tout le parcours : votre prompt part vers Codex, Codex appelle le plugin, le plugin pilote le Web MCP Server, et Crawlbase gère le rendu, les nouvelles tentatives, la rotation de proxys, l'anti-bot, et le stockage en coulisses. De votre côté, tout se passe via des prompts.
Vous pourriez demander à Codex d'écrire du code de scraping à partir de zéro, mais il devinerait face à une cible mouvante : le balisage du site, sa posture anti-bot, et la forme actuelle de l'API. Le plugin achemine chaque requête via la Crawling API, de sorte que Codex hérite du rendu JavaScript, de la rotation d'IP résidentielles, et de la gestion anti-bot, et récupère un contenu propre dès le premier appel.
Ce que vous allez construire
L'objectif n'est pas seulement de scraper un site, mais de construire un workflow d'ingénierie reproductible qui associe la documentation en direct au développement assisté par IA. Au cours des cinq prochaines étapes, vous installerez le plugin, le validerez avec un test de fumée, récupérerez la dernière documentation Web MCP depuis GitHub, utiliserez cette documentation pour générer un scraper full-stack minimal, et découvrirez où les captures d'écran et Cloud Storage s'insèrent dans des workflows plus larges.
Étape 1 : Installer le plugin
Clonez le plugin dans le répertoire des plugins de Codex :
git clone https://github.com/crawlbase/crawlbase-codex-plugin ~/.codex/plugins/crawlbase-mcp
Exportez vos tokens d'API Crawlbase (si vous n'avez pas encore de compte, inscrivez-vous à Crawlbase d'abord). Le dépôt compagnon inclut un .env.example listant les variables qu'il attend :
export CRAWLBASE_TOKEN=your_token_here export CRAWLBASE_JS_TOKEN=your_js_token_here
Redémarrez Codex. Le plugin apparaît alors sous le nom Crawlbase Web Scraper, exposant des outils comme crawl, crawl_markdown, crawl_screenshot, et les opérations Cloud Storage. Le .mcp.json fourni lance npx -y @crawlbase/mcp et lit vos identifiants depuis l'environnement, de sorte qu'aucun secret ne réside dans le plugin lui-même, ce qui le rend sûr pour des environnements partagés et versionnés.
Étape 2 : Vérifier avec un test de fumée
Avant de générer le code de l'application, confirmez que tout le pipeline fonctionne. Collez prompts/00-smoke-test.txt dans Codex, ou demandez simplement :
Get the markdown content of https://example.com
La requête ne fait presque rien, à dessein. Si tout est bien câblé, Codex appelle crawl_markdown et retourne du Markdown propre (titre, en-têtes, corps) au lieu de HTML brut. Cela confirme tout le chemin d'exécution, depuis votre prompt en passant par Codex, le plugin, et le Web MCP Server, jusqu'à la Crawling API. Ce chemin est la colonne vertébrale du reste du tutoriel : vous décrivez le résultat, et le serveur alimente le contexte de Codex en contenu web en direct. En cas d'échec, vérifiez que CRAWLBASE_TOKEN est exporté et redémarrez Codex après avoir installé le plugin.
Étape 3 : Récupérer la dernière documentation avant d'écrire du code
Plutôt que de laisser Codex intégrer Crawlbase de mémoire, donnez-lui d'abord la documentation actuelle depuis GitHub. Collez prompts/01-fetch-api-readme.txt dans Codex ; il récupère le README Web MCP depuis l'URL brute GitHub, couvrant les variables d'environnement, les outils MCP, store=true, la récupération depuis Cloud Storage, et le comportement de stockage spécifique à chaque token.
Les données d'entraînement vieillissent. Récupérer le README directement depuis GitHub signifie que Codex travaille à partir de la même documentation qui se trouve aujourd'hui sur la branche main. Si le README est volumineux, crawlez-le avec store=true et récupérez-le plus tard avec storage_get en utilisant as=markdown (voir la documentation Cloud Storage).
Étape 4 : Générer le scraper full-stack
Avec la documentation actuelle dans le contexte, demandez à Codex de générer l'application en utilisant prompts/02-build-full-stack-scraper.txt. Le prompt demande trois couches :
| Couche | Responsabilité |
|---|---|
| Backend |
POST /scrape, appelle la Crawlbase Crawling API |
| Frontend | Champ URL, bouton d'envoi, panneau de résultats |
| Projet | README, .env.example, .gitignore, instructions d'exécution |
Codex dispose désormais de vos exigences, du contexte de votre projet, et de la dernière documentation, il génère donc à partir de la référence d'API actuelle plutôt que de données d'entraînement historiques. Testez l'application sur books.toscrape.com ou un autre site public d'entraînement. Si le Markdown retourné est vide parce que le site dépend de JavaScript, réessayez avec CRAWLBASE_JS_TOKEN, en suivant la documentation que vous avez récupérée à l'étape 3.
Étape 5 : Itérer avec des données web en direct
Ouvrez prompts/03-iterate-with-live-data.txt. Il regroupe des workflows pour comparer la sortie Markdown, prendre des captures d'écran, stocker de la documentation avec store=true, et réessayer les pages rendues en JavaScript. À ce stade, la recherche, l'implémentation, et le débogage vivent tous à l'intérieur d'une seule conversation Codex au lieu d'être dispersés entre plusieurs onglets.
Conserver les crawls avec Cloud Storage
De nombreux workflows de scraping ne s'arrêtent pas à une seule requête. Vous pourriez avoir besoin de revisiter de la documentation, de comparer l'évolution d'une page, ou de retraiter le même crawl sans solliciter à nouveau le site cible. Définissez store: true sur n'importe quel crawl et, au lieu de retourner la page en ligne, Crawlbase conserve le HTML sous-jacent dans Cloud Storage et retourne des métadonnées telles que rid, stored_at, storage_url, et token_type. Vous gérez le contenu stocké avec :
-
storage_getetstorage_bulk_get -
storage_listetstorage_count -
storage_deleteetstorage_bulk_delete
Un détail mérite d'être connu : que vous appeliez crawl, crawl_markdown, ou crawl_screenshot, l'artefact stocké est toujours le HTML sous-jacent. Lorsque vous récupérez une page stockée sous forme de Markdown, Crawlbase le génère à partir de ce HTML au moment de la récupération. Les captures d'écran ne sont pas conservées dans Cloud Storage ; elles reviennent séparément via une URL de capture d'écran temporaire.
Comprendre les partitions de stockage
Cloud Storage partitionne les pages crawlées selon le token d'API utilisé pour le crawl. Les pages récupérées avec CRAWLBASE_TOKEN résident dans un silo différent de celles récupérées avec CRAWLBASE_JS_TOKEN, parce que les crawls standard et les crawls rendus en JavaScript s'exécutent sur des infrastructures différentes.
token_type de normal ou js ; transmettez cette même valeur (via use_js_token) aux outils de stockage afin d'interroger la partition dans laquelle la page a réellement atterri.Chaque réponse de crawl réussie inclut un champ token_type (normal ou js) qui vous indique où le document a été stocké. Réutilisez cette valeur pour les opérations de stockage ultérieures : si une page a été crawlée avec le token JavaScript, transmettez use_js_token: true à storage_get, storage_list, ou storage_bulk_get. Une réponse "Not found" ne signifie généralement pas que le document a disparu ; elle signifie que vous interrogez la mauvaise partition. Vérifier le token_type du crawl d'origine suffit normalement à trouver le bon silo.
Bonnes pratiques d'ingénierie
Le workflow ci-dessus est parfait pour les prototypes ; quelques pratiques lui permettent de tenir à mesure que les projets grandissent.
- Récupérez la documentation actuelle avant de générer du code d'intégration. Les API et les SDK évoluent vite, et donner au modèle la documentation d'aujourd'hui réduit fortement les endpoints dépréciés, les paramètres erronés, et les flux d'authentification obsolètes.
-
Gardez les identifiants dans des variables d'environnement. Committez un
.env.examplepour que les autres sachent ce qui est requis, mais ne committez jamais de vrais tokens. -
Stockez les gros crawls au lieu de les insérer en ligne. Pour les grandes pages de documentation ou les jeux de données,
store: truegarde la conversation ciblée et vous permet de récupérer le contenu plus tard. - Traitez le code généré comme du code de production. Validez les codes de statut, définissez des délais d'expiration raisonnables, et faites remonter des erreurs pertinentes. Assistée par IA ou non, une gestion robuste des erreurs est ce qui rend une application fiable.
À mesure que les projets dépassent le stade du prototype, la concurrence, les nouvelles tentatives, la surveillance, et la fiabilité de l'infrastructure commencent aussi à compter ; notre guide sur la montée en charge des projets de web scraping couvre ces préoccupations de production.
Conclusion
Les assistants de codage IA donnent le meilleur d'eux-mêmes lorsqu'ils peuvent raisonner sur des informations actuelles plutôt que sur des données d'entraînement historiques. Associer le Crawlbase Codex Plugin au Crawlbase Web MCP Server donne à Codex un accès direct au contenu web en direct : il peut récupérer de la documentation, extraire du Markdown propre, prendre des captures d'écran, et construire des applications à partir des dernières informations disponibles, le tout dans une seule conversation.
Donnez à Codex (et à tout client MCP) un accès web en direct en un seul appel d'outil. Chaque crawl rend le JavaScript derrière une IP résidentielle rotative et retourne un Markdown propre, avec Cloud Storage en option pour la réutilisation. Pas de pool de proxys, pas de flotte headless, pas de code de scraping à maintenir. Obtenez vos tokens d'API et construisez sur l'offre gratuite.
Questions fréquentes
Qu'est-ce que le Crawlbase Codex Plugin ?
C'est une extension pour OpenAI Codex qui intègre le Crawlbase Web MCP Server dans votre workflow de développement. Une fois installé, Codex peut crawler des pages web, extraire du Markdown propre, prendre des captures d'écran, et gérer Crawlbase Cloud Storage via des prompts en langage naturel. Au lieu d'écrire vous-même l'infrastructure de scraping, vous demandez à Codex de récupérer du contenu web en direct et de l'utiliser comme contexte pour la génération de code.
Pourquoi utiliser le Web MCP Server plutôt que de demander à Codex de générer un scraper ?
Codex est doué pour générer du code de scraping, mais il n'a aucun accès aux sites en direct ou à la documentation à moins que vous ne les lui fournissiez. Le plugin donne à Codex un accès web en temps réel via l'infrastructure de Crawlbase, de sorte qu'il peut récupérer la dernière documentation d'API, crawler des sites, rendre des pages JavaScript, et générer du code à partir d'informations actuelles plutôt que de données d'entraînement potentiellement obsolètes.
Puis-je utiliser le plugin pour des sites web fortement chargés en JavaScript ?
Oui. Il prend en charge à la fois les pages statiques et les pages rendues en JavaScript. Avec CRAWLBASE_JS_TOKEN configuré, Codex utilise le rendu JavaScript de Crawlbase pour crawler des sites dynamiques, extraire le contenu après l'exécution des scripts, et prendre des captures d'écran rendues.
Pourquoi storage_get retourne-t-il « Not found » après le stockage d'une page ?
Les pages crawlées avec CRAWLBASE_TOKEN sont stockées séparément des pages crawlées avec CRAWLBASE_JS_TOKEN. Si une page a été crawlée avec le token JavaScript, transmettez use_js_token: true aux outils de stockage. La plupart des réponses « Not found » signifient simplement que vous interrogez la mauvaise partition de stockage, et non que la page est absente.
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.