Le 10 mars 2026, une ligne est apparue dans le Changelog de Cloudflare : « Crawl entier websites with a single API call. » Derrière cette sobriété, une infrastructure capable de traiter jusqu’à 100 000 pages par job, avec rendu JavaScript, respect du robots.txt et sortie en HTML, Markdown ou JSON structuré. Pour les développeurs qui construisent des pipelines RAG ou des agents IA, c’est un raccourci bienvenu. Mais les limites du plan gratuit et une tension structurelle propre à Cloudflare méritent d’être lues avant d’adopter l’outil.
Ce que fait concrètement l’endpoint /crawl
L’endpoint POST https://api.cloudflare.com/client/v4/accounts/{account_id}/browser-rendering/crawl prend une URL de départ et découvre les pages via trois sources : le sitemap du site, les liens trouvés sur chaque page et l’URL initiale. Le crawl est asynchrone : on soumet la requête, on reçoit un job ID, on interroge l’état via GET et on récupère les résultats avec pagination curseur.
Le paramètre render: true (valeur par défaut) lance un navigateur Headley Chromium qui exécute le JavaScript avant extraction. C’est ce qui rend le service utile pour les applications React, Vue.js ou Angular. Avec render: false, le service récupère le HTML statique sans navigateur, plus rapide et gratuit pendant la bêta. Les formats de sortie disponibles sont HTML brut, Markdown et JSON structuré. Ce dernier s’appuie sur Workers AI pour extraire des données selon un prompt configurable, ce qui entraîne une facturation séparée.
Les paramètres qui définissent vraiment la portée du crawl
L’argument « une seule requête » est vrai dans sa forme. La portée réelle dépend des paramètres qu’on lui passe.
| Paramètre | Valeur par défaut | Maximum | Usage |
|---|---|---|---|
| limit | 10 pages | 100 000 pages | Nombre total de pages à crawler |
| depth | illimité | 100 000 | Profondeur de suivi des liens |
| maxAge | 86 400 secondes | 604 800 secondes | Durée de validité du cache par page |
| source | all | all / sitemaps / links | Source de découverte des URLs |
| Durée max du job | 7 jours | 7 jours | Les résultats sont conservés 14 jours après complétion |
Les paramètres includePatterns et excludePatterns acceptent des wildcards (* et **) pour cibler ou exclure des chemins d’URL précis. L’authentification HTTP, les cookies et les en-têtes personnalisés sont supportés, ce qui permet de crawler du contenu derrière une authentification basique. Pour les SPAs, waitForSelector et gotoOptions permettent d’attendre qu’un élément DOM soit chargé avant extraction.
Les limites que les tutoriels oublient de mentionner
Sur le plan Workers Free, /crawl est limité à 5 jobs par jour et 100 pages par job. Soit 500 pages quotidiennes au maximum. Pour un site de documentation de quelques milliers de pages, c’est un plafond bas. La documentation du plan Workers Paid (5 $/mois, soit environ 4,60 € en mars 2026) n’affiche pas de limite chiffrée équivalente et indique que des ajustements sont traités au cas par cas.
Le plan Workers Paid inclut 10 heures de Browser Rendering, facturées 0,09 $ l’heure (environ 0,08 €). Avec un crawl-delay d’une seconde, on atteint environ 3 600 pages par heure. Le coût unitaire par page est donc faible sur des volumes modérés. Sur des dizaines de milliers de pages avec JavaScript lourd, la facture monte autrement.
Autre contrainte peu citée : les requêtes proviennent du réseau Cloudflare (ASN 13335) avec des en-têtes identifiables. Les propriétaires de sites peuvent bloquer ce bot via leur configuration WAF. Cloudflare le reconnaît dans sa documentation : le service « se comporte comme un bot bien identifié ». Ce n’est pas un outil furtif.
Le paradoxe Cloudflare : le même acteur vend la serrure et le passe-partout
Cloudflare protège une large part du web contre le scraping via Bot Management, Turnstile et WAF. Ce même Cloudflare vend désormais un service de crawl pour extraire le contenu de sites tiers. La limite est posée dans la documentation : l’endpoint /crawl ne peut pas bypasser Cloudflare Bot Management ni résoudre les CAPTCHAs, y compris sur les sites protégés par Cloudflare lui-même.
Le fil Hacker News du jour du lancement a mis ce point sur la table. Un développeur a parlé de « protection racket textbook » : créer la friction, vendre l’accès. Un autre a souligné que les requêtes issues de l’ASN 13335 sont identifiables et bloquables, réduisant l’utilité du service pour les cas où la cible ne veut pas être crawlée. La discussion a aussi fait ressortir que des outils comme Firecrawl produisaient de meilleurs résultats dans certains tests pratiques.
Pour les propriétaires de sites qui utilisent déjà « AI Crawl Control » de Cloudflare (l’option qui bloque les crawlers d’entraînement IA), l’endpoint /crawl respecte ces directives par défaut. C’est cohérent éthiquement. Mais ça pose une vraie question de gouvernance : qui décide quels crawlers sont légitimes quand le même acteur vend les deux côtés de la transaction ?
Alternatives et positionnement par rapport aux outils spécialisés
L’endpoint /crawl cible trois usages selon la documentation officielle : alimenter des pipelines RAG (Retrieval-Augmented Generation) avec la documentation d’un produit, construire des bases de connaissances pour agents IA et surveiller les changements de contenu via le paramètre modifiedSince.
Les concurrents directs opèrent sur des modèles différents. Firecrawl facture à la page via crédits : son plan Hobby coûte environ 15 € par mois pour 3 000 crédits. Son plan Standard est à environ 77 € par mois pour 100 000 pages. Apify, plus complexe, propose un plan Starter à environ 27 € par mois sur base de compute-units. La différence principale : Firecrawl et Apify sont des services dédiés au scraping avec des volumes garantis et documentés. Cloudflare /crawl est un endpoint ajouté à une infrastructure existante, dont les limites sur plan payant restent à clarifier.
Pour les équipes qui développent déjà sur Cloudflare Workers, l’intégration est naturelle. Pour ceux qui cherchent des garanties de volume à grande échelle, la transparence tarifaire des alternatives spécialisées reste un argument concret.
La chaîne IA que Cloudflare est en train de construire
Avant cet endpoint, ingérer un site de documentation dans un pipeline IA nécessitait d’assembler plusieurs outils : un crawler (Scrapy, Puppeteer ou Playwright), un pipeline de nettoyage HTML, une conversion en Markdown et une gestion des pages JavaScript. L’endpoint /crawl consolide ces étapes en un seul appel avec une sortie Markdown directement exploitable.
La combinaison avec AutoRAG, le service RAG managé annoncé par Cloudflare en parallèle, montre la direction : une chaîne « crawl-chunk-vectorise-serve » sans quitter l’écosystème. C’est pratique pour un développeur solo ou une petite équipe. C’est aussi une dépendance structurelle supplémentaire envers un acteur qui contrôle déjà une part significative de l’infrastructure web mondiale. Le débat technique est simple. Le choix d’architecture, lui, ne l’est pas forcément.
