cloudflare vient de sortir un endpoint /crawl et tout le monde perd la tête.

calmez-vous. laissez-moi vous dire ce que c'est vraiment, ce que ce n'est pas, et pourquoi vous en avez probablement pas besoin.
l'endpoint /crawl est un wrapper. vous lui donnez une URL, il lance des navigateurs headless sur l'infra de Cloudflare, suit les liens, rend le JavaScript, et vous renvoie du markdown ou du JSON. tout avec 1 appel API.
c'est cool mais pas révolutionnaire.
firecrawl fait ça. crawl4AI fait ça. spider fait ça. ils le font depuis des mois. cloudflare l'a juste ajouté à son produit Browser Rendering existant et tout le monde a agi comme s'ils avaient inventé le crawling.
ce qui EST intéressant : c'est cloudflare. ça veut dire que c'est bon marché ($0.09/heure).
mais le truc c'est que vous n'avez probablement même pas besoin d'un crawler.
il y a 8 façons qu'un agent IA lise une page web. la plupart vont directement aux solutions complexes alors qu'une requête HTTP de 50ms aurait fait le job. donc décortiquons-les toutes, de la plus simple à la plus excessive.
1. HTTP brut
votre agent envoie une requête, reçoit du HTML. c'est tout.
comme lire le code source d'un livre au lieu de la page imprimée. marche super bien pour les sites simples, blogs, wikis, docs. casse sur n'importe quoi qui utilise JavaScript pour charger le contenu.
vitesse : ~50ms. coût : gratuit.
2. readability parser
la même chose, mais avec une étape de nettoyage. supprime les barres de nav, les pubs, les pieds de page, les bannières de cookies. vous donne juste le texte de l'article en markdown propre.
ne gère pas le contenu rendu en JavaScript. mais pour les articles et les docs, c'est parfait, et c'est ce que j'utilise quotidiennement.
vitesse : ~100ms. coût : gratuit.
3. navigateur headless (local)
lance un Chrome invisible qui charge la page comme un humain le ferait. JavaScript s'exécute, le contenu se rend, tout se charge. vous pouvez cliquer, scroller, remplir des formulaires, vous connecter.
le problème : lent (2-10s), consomme ~200MB de RAM par instance, et vous maintenez l'infra.
outils : Playwright, Puppeteer, Selenium.
4. API navigateur cloud
pareil que #3 mais quelqu'un d'autre fait tourner le navigateur. vous envoyez une URL, recevez la page rendue. c'est là que vit le /crawl de Cloudflare, ainsi que Browserbase et Steel.
pas de galères d'infra, scale facilement, bon marché. tradeoff : moins de contrôle sur les interactions.
5. API de scraping gérée
c'est le niveau de lutte anti-bot. ScrapingBee, Bright Data, proxies rotatifs, résolution de CAPTCHA, IPs résidentielles. pour quand le site vous combat activement.
ça marche. coûte $49-499+/mois.
6. crawler natif IA
Firecrawl, Crawl4AI, Spider. crawl + render + conversion automatique en markdown/JSON propre. construit pour les pipelines RAG. définissez les schémas d'extraction en langage naturel.
la "nouvelle vague" avec laquelle Cloudflare concurrence maintenant.
7. extraction LLM
skipper le code entièrement. versez le contenu de la page dans un LLM, demandez "quel est le prix ?" en anglais simple. pas de sélecteurs CSS, pas de regex, pas de maintenance quand le site se redesigne.
inconvénient : cher à grande échelle (les tokens s'accumulent vite). meilleur comme dernière étape après nettoyage avec les méthodes 1-6.
8. APIs officielles
celui que tout le monde oublie. X, Reddit, la plupart des SaaS, ils ont des APIs. données structurées, pas de parsing, pas de jeux anti-bot. quand une API existe, c'est toujours le bon choix.
les bonnes configurations combinent 2-3 :
→ fetch → readability → LLM pour l'extraction d'articles bon marché
→ cloud browser → LLM pour les sites lourds en JavaScript
→ sniffer l'API réelle dans DevTools → l'appeler directement, le graal, gratuit, plus rapide, plus fiable
→ crawler IA → vector DB pour les bases de connaissances complètes
coûts réels pour 10 000 pages/mois
• HTTP Fetch : $0
• Jina Reader : $0
• Cloudflare Browser : ~$5
• Spider : ~$4.80
• Firecrawl : $47/mo
• ScrapingBee : $49-147/mo
• Bright Data : $499+/mo
2 règles que je suis :
commencez simple. API > fetch > readability > browser. n'ajoutez de la complexité que quand la méthode plus simple échoue. je vois des gens lancer Playwright pour des sites où curl fonctionne bien.
la plupart des sites n'ont pas besoin du rendu JS. 60%+ du web est statique ou server-rendu. testez d'abord avec un simple fetch.