webclaw : extraire du markdown propre depuis une URL, sans quitter son terminal

Le problème concret : deux sorties inutilisables

Le README pose le diagnostic sans détour. La plupart des outils de scraping rendent à un agent soit une page bloquée, un mur de connexion ou une coquille d'application vide, soit du HTML brut encombré de navigation, de scripts, de styles, de publicités et de blocs répétés. Dans les deux cas, le contenu utile n'arrive pas jusqu'au modèle. webclaw se place sur ce créneau : une URL en entrée, du markdown, du texte, du JSON ou un format dit LLM en sortie. La cible est explicite dans les topics du dépôt et dans le README : agents IA, pipelines RAG, et développeurs qui veulent appeler l'outil depuis un terminal, un client MCP ou une application. Le projet se présente aussi comme alternative auto-hébergée à plusieurs services d'extraction, mais cette comparaison vient de l'auteur, pas d'un tiers.

Ce que fait réellement le binaire

La commande de base est volontairement courte : `webclaw https://example.com --format markdown`. Le README en donne la sortie, un titre et un paragraphe, sans balise ni script. Trois formats sont documentés : markdown, llm et json. Le format json sert de matière première à la comparaison dans le temps, avec `--diff-with` qui prend un fichier JSON produit précédemment. Deux options de filtrage structurent l'extraction : `--only-main-content` pour ne garder que le corps principal, et les paires `--include` / `--exclude` qui acceptent des sélecteurs CSS. L'exemple du README inclut `article, main, .content` et exclut `nav, footer, .sidebar, .ad`. C'est un mécanisme de sélection par sélecteurs, pas un modèle de langage qui devine quoi garder. Cette distinction compte : le résultat est reproductible, et une page mal découpée se corrige en ajustant les sélecteurs.

Crawl, cartographie et extraction structurée

Au-delà de la page unique, le tableau des outils liste huit fonctions. `crawl` suit les liens de même origine, `map` découvre les URL sans extraire chaque page, `batch` traite plusieurs URL en parallèle. Le crawl se pilote avec `--crawl --depth 2 --max-pages 50`, deux garde-fous qui évitent d'aspirer un site entier par accident. `extract` convertit le contenu en données structurées et `summarize` résume une page ; le tableau précise pour ces deux lignes : local avec un LLM local ou configuré. C'est la limite la plus importante du tableau. Les six autres outils sont marqués comme entièrement locaux, mais l'extraction structurée et le résumé dépendent d'un modèle, local ou distant. Un lecteur qui cherche du 100 % hors ligne doit le savoir avant de bâtir son pipeline dessus. Le README mentionne aussi `--brand` pour récupérer couleurs, polices et logos, sans détailler la méthode.

Deux chemins d'installation, deux niveaux de contrôle

Pour un agent, le chemin court est `npx create-webclaw` : l'installeur détecte les clients compatibles MCP et écrit leur configuration. Le README cite Claude Code, Claude Desktop, Cursor, Windsurf, OpenCode et Codex CLI. Si vous préférez écrire la configuration vous-même, le bloc JSON est fourni : un serveur nommé webclaw, commande `npx`, arguments `-y` et `@webclaw/mcp`. Pour un usage hors agent, quatre voies existent : Homebrew via `brew tap 0xMassi/webclaw` puis `brew install webclaw`, les binaires précompilés macOS, Linux et Windows depuis les releases GitHub, l'image Docker `ghcr.io/0xmassi/webclaw`, et Cargo avec `cargo install --git https://github.com/0xMassi/webclaw.git webclaw-cli` ou `webclaw-mcp`. La compilation depuis les sources demande des outils natifs ; le README liste les prérequis par distribution, par exemple `pkg-config libssl-dev cmake clang git build-essential` sur Debian et Ubuntu, ou `xcode-select --install` sur macOS. Ce détail n'est pas cosmétique : sans ces paquets, la compilation échoue.

Ce que le dépôt ne dit pas

Le README s'arrête au tableau des outils, tronqué dans le matériel fourni. Plusieurs points restent donc non vérifiables ici. Aucune architecture interne n'est décrite : on ne sait pas comment le moteur choisit entre requête HTTP simple et rendu de navigateur, ni comment le TLS fingerprinting mentionné dans les topics est implémenté. Aucun chiffre de performance n'est avancé, et je n'en avancerai pas. La question du JavaScript est la plus gênante : le README indique que la plupart des sites s'extraient en local sans clé d'API, et qu'il faut définir `WEBCLAW_API_KEY` pour les pages protégées contre les bots et rendues en JavaScript. Autrement dit, le mode local a une frontière, et cette frontière passe par le service hébergé webclaw.io. Pour une application sensible à la souveraineté des données, ce n'est pas un détail d'implémentation, c'est un choix d'architecture à évaluer.

Alternatives : Firecrawl et Crawl4AI

Les topics du dépôt positionnent webclaw face à Firecrawl et Crawl4AI, entre autres. La différence tient à la langue et au mode de distribution. Crawl4AI est un projet Python : on l'intègre comme bibliothèque dans un environnement Python existant, ce qui évite un binaire séparé mais impose l'écosystème Python et ses dépendances. webclaw est écrit en Rust et se distribue comme binaire, image Docker ou paquet Homebrew, ce qui le rend appelable depuis n'importe quel langage via la CLI ou l'API REST. Firecrawl, lui, est d'abord un service, avec une API compatible reproduite dans les exemples du dépôt. webclaw propose les deux : le service hébergé et le serveur auto-hébergeable. Le compromis est clair : un binaire Rust unique évite d'embarquer un runtime Python, mais vous perdez l'accès direct aux bibliothèques Python de traitement de données qui entourent souvent ces pipelines.

Licence AGPL-3.0 et coût de maintenance

webclaw est publié sous AGPL-3.0. Cette licence impose des obligations dès lors que le logiciel est mis à disposition sur un réseau : le code source des modifications doit être proposé aux utilisateurs du service. Pour un usage interne, l'impact est faible. Pour un service exposé à des clients, il faut en tenir compte avant d'intégrer webclaw dans un produit propriétaire. Je ne donne pas de conseil juridique ici, seulement le constat de la licence déclarée. Côté maintenance, le rythme est soutenu : v0.6.20 et v0.6.21 le 16 août 2026, v0.6.22 le 30 août 2026. Trois versions en un mois sur une série 0.6.x signifie que l'API et les formats de sortie peuvent encore bouger. Un pipeline qui parse la sortie JSON de `--diff-with` doit prévoir de suivre ces changements, pas de figer une version et l'oublier.

Conclusion éditoriale

webclaw convient aux équipes qui veulent une étape d'extraction déterministe dans une chaîne RAG ou un agent, et qui acceptent d'auto-héberger un binaire Rust sous AGPL-3.0. Il ne convient pas si vous avez besoin d'un rendu JavaScript complet sans dépendance externe : le README indique que les pages protégées ou rendues côté client passent par WEBCLAW_API_KEY et le service hébergé. Avant d'adopter, lancez `webclaw https://votre-site-cible --format markdown` sur trois ou quatre pages représentatives, dont une derrière un mur de connexion, et vérifiez ce qui sort réellement.

Sources officielles

1. 0xMassi/webclaw on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases