Test Apache Nutch : quatre limites qui déterminent s’il s’exécute et ce qu’il trouve

Apache Nutch est un crawler de l’Apache Software Foundation dont le développement a commencé en 2004. C’est un système basé sur JVM et Hadoop, pensé comme une boucle plutôt qu’une simple commande de flux continu : les URL de départ sont d’abord injectées dans une base persistante, puis on enchaîne les cycles generate → fetch → parse → updatedb, avec des emplacements de plugins pour le protocole, le parser, le filtre d’URL et le scoring. À la sortie, on alimente en général un index de recherche comme Solr ou Elasticsearch, plutôt qu’un CSV.

J’ai exécuté Nutch 1.22 sur un site de test local contrôlé — un site qui journalise chaque requête côté serveur, de sorte que les résultats sont jugés à partir de ce que le serveur a vraiment vu, et non de ce que le crawler prétend avoir fait. Quatre limites ont structuré l’essai : la version du JDK, http.agent.name, le périmètre de crawl et la présence de parse-js dans plugin.includes. La boucle complète a été relancée plusieurs fois avec la configuration testée ; si l’on change le JDK ou si l’identité de l’agent reste vide, l’exécution s’arrête avant même de récupérer des pages utiles.

La limite liée au JDK apparaît avant même le début du crawl. Nutch 1.22 ne démarrait pas ici avec JDK 26.0.1 : le premier job Hadoop s’est arrêté dans Subject.getSubject() après que Java a supprimé le chemin du SecurityManager. Nutch embarque Hadoop 3.4.2, alors que la correction n’a atterri dans Hadoop 3.4.3 que sept jours après la sortie de Nutch 1.22. Par ailleurs, parse-js a fait passer la récupération de deux littéraux de fichiers JavaScript de 0/2 à 2/2, sans exécuter de navigateur.

À quoi sert Nutch, et à quoi il ne sert pas

Nutch n’est pas un scraper. L’extraction de champs structurés n’est pas sa mission : il découvre et récupère des URL à grande échelle, garde une base persistante de ces URL et de leur état (le crawldb), puis vous remet des segments qu’un autre composant transforme en index. Si vous le pointez vers un catalogue en espérant obtenir un tableau de noms et de prix, vous récupérerez plutôt un crawldb.

Cette architecture explique l’essentiel de ce qui suit. Nutch précède d’environ deux décennies l’ère des crawlers en binaire unique, et il a été conçu pour le problème pour lequel Hadoop a lui-même été pensé : crawler plus de pages qu’une seule machine ne peut en contenir. Le faire tourner sur un ordinateur portable contre un jeu de test de 12 pages, c’est comme louer un train de fret pour déplacer une bibliothèque — instructif sur le train, peu pertinent si l’on attend l’ergonomie d’un vélo.

La version actuelle est la 1.22, annoncée le 17 février 2026. Le projet est sous licence Apache-2.0 ; le dépôt affichait 3 272 étoiles et 8 issues ouvertes au moment de ma vérification le 27 juillet 2026, et la branche master avait été poussée quatre jours plus tôt. C’est un projet maintenu, pas abandonné — ce qui est le bon angle pour comprendre le problème de JDK : une fenêtre de packaging fermée une semaine trop tôt, et non un manque de maintenance.

La matrice de versions : JDK 24+, Hadoop 3.4.2 et une correction de deux lignes

Le blocage vient d’une interaction à trois versions, et la seule partie que vous contrôlez réellement est le JDK utilisé par Nutch. Le tout premier job Hadoop, sur le JDK par défaut de la machine, s’est arrêté à l’initialisation :

java.lang.UnsupportedOperationException: getSubject is not supported
    at java.base/javax.security.auth.Subject.getSubject(Subject.java:277)
    at org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:588)
    at org.apache.nutch.crawl.Injector.inject(Injector.java:473)

Code retour 255. Zéro page récupérée. bin/nutch inject n’atteint même pas le réseau — il initialise un LocalJobRunner Hadoop, qui cherche à savoir qui est l’utilisateur courant, ce qui appelle Subject.getSubject(), que JEP 486 a transformé en exception inconditionnelle lorsque JDK 24 a supprimé définitivement le SecurityManager. Mon JDK hôte était OpenJDK 26.0.1, donc bien au-delà de cette limite.

La sortie de secours classique ne fonctionne pas non plus. Ajouter -Djava.security.manager=allow, l’option qui réactivait autrefois l’ancien comportement, est rejeté par la JVM avant même le chargement du code de Nutch :

Error occurred during initialization of VM
java.lang.Error: A command line option has attempted to allow or enable the Security
Manager. Enabling a Security Manager is not supported.

Code retour 1, et impasse par conception — l’option a disparu avec la fonctionnalité.

La cause racine se trouve dans la version de Hadoop embarquée avec Nutch 1.22. Le problème getSubject est suivi sous HADOOP-19212 et corrigé dans Hadoop 3.4.3 et 3.5.0 ; Nutch 1.22 embarque hadoop-common-3.4.2. Nutch 1.22 est sorti le 17 février 2026, et Hadoop 3.4.3 a suivi environ une semaine plus tard.

Ce n’est pas non plus un problème de dépendance à Solr ou à un cluster Hadoop. On suppose souvent que Nutch a besoin d’un cluster Hadoop et d’un Solr en fonctionnement pour faire quoi que ce soit. Ce n’est pas le cas. Le mode local utilise le LocalJobRunner de Hadoop, en processus — pas de démon HDFS, pas de YARN, pas de cluster. Toute la boucle inject → generate → fetch → parse → updatedb s’exécute sur une seule machine, sans autre installation. Le mur du JDK relève uniquement d’une incompatibilité de version dans les bibliothèques embarquées, et il vous bloque avant même que la question de l’infrastructure n’entre en jeu.

La matrice pratique des versions, mesurée sur les trois lignes :

La correction tient en deux commandes. Installez un JDK LTS et indiquez-le à Nutch :

brew install openjdk@17
export NUTCH_JAVA_HOME=/opt/homebrew/opt/openjdk@17

C’est une installation keg-only, donc elle ne modifie pas le JDK par défaut du système. La CI de Nutch cible elle-même Java 17, et le projet a annoncé publiquement que la 1.22 est la dernière version compatible avec Java 11 et que la 1.23 exigera Java 17. Un JDK LTS n’est donc pas un contournement : c’est la configuration prise en charge. Le décalage se situe entre ce que Nutch supporte et ce que brew install openjdk vous installe en 2026, et ce sont deux questions différentes qui se heurtent dès la première commande.

À partir de là, tout a tourné sur OpenJDK 17.0.20, avec une boucle complète propre.

Installation mesurée : 396 Mo et une propriété qui bloque tout

« Lourd » est l’adjectif qu’on entend tout de suite, mais sans mesure il ne veut pas dire grand-chose. Voici ce que contient réellement la distribution binaire décompressée de Nutch 1.22 :

À titre de comparaison, un crawler Go moderne comme katana se présente sous la forme d’un seul binaire d’environ 50 Mo, sans JVM ni JAR externe.

Ensuite, il y a la porte d’entrée dont personne ne vous prévient. Le nutch-site.xml fourni est vide, et http.agent.name est vide par défaut. Tant qu’il n’était pas renseigné, mon premier crawl a récupéré zéro chemin et a consigné :

ERROR Fetcher: No agents listed in 'http.agent.name' property.

Le simple fait de définir cette propriété — rien d’autre — a suffi à rendre le fetch fonctionnel. Quand la propriété reste vide, la commande se termine sans récupérer de pages et le journal affiche l’erreur ci-dessus ; ce n’était pas silencieux.

La configuration minimale viable s’est révélée tenir en trois artefacts : conf/nutch-site.xml (nom de l’agent, jeu de plugins, portée), conf/regex-urlfilter.txt (cadrage par hôte) et un fichier d’URL de départ. Ce n’est pas énorme. C’est juste trois fichiers de plus que crawler run <url>.

Ce qu’il a trouvé : l’interrupteur de plugin qui compte

Le site de test comportait trois classes d’endpoints volontairement différentes, et le comportement de Nutch s’est séparé nettement selon elles :

• Classe A — liens HTML ordinaires (4 pages, plus une chaîne de profondeur 3 liens)
• Classe B — endpoints n’existant que comme littéraux de chaîne dans un fichier JavaScript lié : l’un comme argument d’appel, fetch('/api/js-endpoint-7'), l’autre comme affectation, const other = "/api/js-endpoint-8"
• Classe C — endpoint n’existant qu’après exécution du JavaScript, lorsqu’il est injecté dans le DOM

Résultats, d’après les journaux d’accès côté serveur, répétés trois fois :

Identique sur les trois répétitions. Déterministe.

Le saut de la classe B est celui qu’on sous-estime le plus. Nutch a trouvé les deux endpoints intégrés dans le JavaScript sans exécuter de navigateur, en s’appuyant sur l’analyse regex du contenu JavaScript réalisée par le plugin parse-js. Le fichier app.js lui-même a été récupéré dans les deux configurations — Nutch traite <script src> comme un lien sortant quoi qu’il arrive — la différence porte donc uniquement sur le fait de lire ou non le contenu du fichier à la recherche de chaînes ressemblant à des URL. Activez le plugin, et il détecte les deux formes littérales.

Sur ce jeu de test, Nutch en configuration par défaut et katana en mode standard ont atteint le même ensemble de la classe A, tandis que Nutch avec parse-js et katana avec -jc ont atteint les classes A et B sans navigateur. La version de Katana et la commande complète ne sont pas documentées dans cet article ; il s’agit donc ici d’un contexte, pas d’un benchmark produit strict.

La classe C constitue la vraie limite. Aucune configuration statique n’y est parvenue, ce qui est attendu : récupérer un endpoint qui n’existe qu’après exécution du script impose d’exécuter réellement ce script. J’ai bien essayé de remplacer protocol-http par protocol-htmlunit, le protocole d’exécution JavaScript pur Java de Nutch. Il s’est chargé et a tourné sans planter, mais dans le même harness à quatre tours il n’a terminé qu’un seul tour, n’a récupéré que la page de départ et app.js, n’a atteint ni A, ni B, ni C, et le deuxième tour a signalé 0 records selected for fetching. C’est un probe sous-configuré, pas un verdict sur les capacités d’HtmlUnit. Ce que cela établit est plus limité : remplacer le protocole par un moteur d’exécution JS n’est pas un changement plug-and-play, et la classe C est restée hors de portée dans toutes les configurations testées.

Contrôle du crawl et comportement en cas d’échec

La profondeur n’est pas un paramètre. Il n’existe pas de --depth 3 dans Nutch ; la profondeur correspond au nombre de tours generate → fetch → parse → updatedb que vous exécutez, car le tour R récupère la frontière découverte au tour R-1. Ma chaîne de profondeur l’a confirmé précisément :

C’est propre et mécanique, mais cela signifie que la profondeur est un nombre d’itérations dans votre script, pas un argument.

Venons-en au piège. La valeur par défaut livrée par Nutch est db.ignore.external.links=false, associée à un filtre d’URL permissif +. — ce qui signifie qu’un crawl Nutch par défaut suivra des liens hors du site de départ. J’ai amorcé une page contenant un lien vers un chemin dans le périmètre et un autre vers un autre nom d’hôte ; le crawl a récupéré l’hôte externe. Deux signaux indépendants concordaient : le crawldb de Nutch l’a marqué db_fetched, et le compteur serveur de l’autre hôte a enregistré la requête.

Rester dans le périmètre est opt-in, et les deux remèdes fonctionnent de manière vérifiable :

Si vous ne crawlez qu’un seul site, définissez l’une de ces options avant votre premier vrai lancement. Une mise en garde méthodologique : ce test est sensible à la charge du serveur local, donc ces trois lignes proviennent d’une exécution où rien d’autre n’a touché le fixture. Le comportement lui-même est mécaniquement clair et soutenu par deux signaux indépendants ; les valeurs de la table correspondent à une exécution propre, pas à une moyenne de plusieurs essais.

Les sitemaps constituent une étape à part. La politesse est activée — un crawl normal a bien récupéré /robots.txt — mais le sitemap lui-même nécessite sa propre commande :

C’est un modèle différent de celui des crawlers qui intègrent les fichiers connus en ligne, et cela vous coûte une commande supplémentaire, mais le résultat est complet.

Deux comportements plus petits se sont bien comportés.

Gestion des erreurs : un crawl sur une page contenant un lien vers une erreur 500 et une 404 s’est terminé proprement sur tous les tours, a tout de même récupéré les quatre pages de classe A, et a consigné chaque échec séparément :

Rien n’a déraillé.

Politesse : avec un thread par file, l’écart entre deux fetchs sur le même hôte suivait le paramètre :

Le réglage fait exactement ce qu’il annonce. La valeur par défaut livrée est 5,0 secondes, ce qui est prudent et, là encore, probablement correct pour un outil conçu pour crawler des serveurs qui ne sont pas les vôtres.

La taxe du batch, en secondes

Chaque commande Nutch démarre une nouvelle JVM. Ce seul fait pèse davantage sur le profil temporel que n’importe quel aspect du fetch.

Le plancher effectif par job — démarrage JVM + initialisation Hadoop, mesuré via la phase triviale la moins coûteuse — est d’environ 1,77 seconde. Multipliez cela par quatre commandes par tour, ajoutez l’inject initial, et la vue d’ensemble d’un crawl complet ressemble à ceci :

Cet écart ne vient pas du débit de fetch ; les deux outils demandent le même petit ensemble de pages. Il est architectural. Nutch paie un coût fixe de processus à chaque phase parce que ces phases sont conçues comme des jobs MapReduce. Sur un petit crawl local, l’installation domine. Ce coût fixe devrait devenir une part plus faible d’un job plus long, mais ce test n’a pas mesuré l’échelle à partir de laquelle Nutch et katana se croisent, ni si leur ratio s’inverse.

Avantages et inconvénients

Avantages

• Découverte statique déterministe : classe HTML 4/4, chaîne de profondeur 3/3, identique sur trois exécutions répétées.
• parse-js récupère les endpoints littéraux présents dans un fichier JavaScript (2/2) sans navigateur, en couvrant à la fois les formes en argument d’appel et en affectation.
• Deux contrôles de périmètre vérifiés qui contiennent complètement un crawl (db.ignore.external.links et le filtre d’hôte regex-urlfilter).
• L’ingestion de sitemap via bin/nutch sitemap a permis un rappel complet 2/2 sur des endpoints qu’un crawl normal ne voyait pas du tout.
• Robuste en cas d’échec : les erreurs 500 et 404 sont gérées avec des états distincts dans le crawldb, et le crawl continue.
• Dans cette exécution locale, l’intervalle observé sur un même hôte était cohérent avec le délai configuré à 1,0 seconde ; la valeur par défaut livrée est 5,0 secondes.
• Apache-2.0, activement maintenu, 78 plugins, et un crawldb persistant qui suit l’état de chaque URL d’un tour à l’autre.
• Fonctionne en mode local sans cluster, sans HDFS et sans Solr requis.

Inconvénients

• Ne fonctionne pas sur JDK 24 ou plus récent, où la suppression du SecurityManager pose problème (j’ai mesuré l’échec sur 26.0.1) — Hadoop 3.4.2 embarqué précède le correctif upstream et l’option de secours a disparu, donc un JDK LTS figé est une condition préalable stricte, pas une préférence.
• ≈396 Mo décompressés, 188 JARs de bibliothèque, 78 répertoires de plugins, 35 fichiers de configuration.
• Une nouvelle JVM par commande signifie ~1,77 s de surcoût fixe par phase ; ~45 s pour un crawl de profondeur 4 sur 12 pages contre ~13 s pour un crawler mono-binaire sur la même base.
• La valeur par défaut livrée suit les liens vers des hôtes externes ; rester sur un seul site est opt-in.
• http.agent.name est vide à l’installation et le fetcher refuse de tourner tant que vous ne le renseignez pas.
• Pas de drapeau de profondeur — la profondeur est un nombre d’itérations que vous gérez vous-même.
• Les endpoints rendus à l’exécution dans le DOM sont restés inaccessibles dans toutes les configurations testées, et l’insertion d’un protocole exécutant du JavaScript n’a pas été un simple remplacement direct.
• J’ai testé le mode local sur un seul hôte avec un petit fixture. Le mode distribué/HDFS, l’indexation Solr, hostdb, la reprise et la replanification des recrawls incrémentaux n’entraient pas dans ce test — considérez-les comme non testés ici, pas comme validés.

Qui devrait l’utiliser, et qui devrait passer son tour

Nutch vaut le coup lorsque le crawl lui-même est le point difficile. Si vous construisez un index de recherche, réalisez un crawl large multi-domaines, avez besoin d’une base d’URL persistante avec état par URL et logique de reprise, ou prévoyez de distribuer le travail sur plusieurs machines à terme, c’est une infrastructure qui fait ce travail spécifique depuis avant la plupart des alternatives. Le système de plugins permet de modifier le protocole, le parser, le filtre et le comportement de scoring sans forker quoi que ce soit. Les valeurs de politesse par défaut sont conservatrices d’une manière qui montre que les mainteneurs ont longuement réfléchi à la façon d’être de bons citoyens sur le web.

Passez votre chemin si vous voulez des données structurées à partir de quelques pages. Nutch les récupérera et les analysera, puis vous remettra un crawldb et des segments en attendant que vous apportiez un indexeur. Passez votre chemin si vos cibles sont des applications single-page rendues côté client — la classe C est restée hors de portée dans tout ce que j’ai exécuté. Passez votre chemin si votre équipe n’utilise pas déjà la JVM, car vous ajouteriez une chaîne d’outillage Java, un verrouillage sur un JDK LTS et 396 Mo de JARs à une pile qui n’en comporte aucun. Et si le besoin est « crawler un site, en profondeur de quatre niveaux, une fois par semaine », vous passerez plus de temps sur la boucle de tours et les fichiers de configuration que le crawl ne le mérite.

Pour la plupart des personnes à la recherche d’un scraper, c’est d’ailleurs ce dernier cas qui correspond à la réalité. Ce n’est pas une critique de Nutch — c’est un décalage entre l’outil et la mission. Si vous voulez une vue plus large du paysage, notre tour d’horizon des scrapers open source et les meilleurs projets GitHub de web scraping couvrent plus en détail l’extrémité la plus légère du spectre.

Alternatives, y compris la place de notre propre stack

D’abord, le cadrage honnête : Nutch est gratuit, sous licence Apache, auto-hébergé, et à vous pour toujours sans coût par requête. C’est un vrai avantage, et rien de ce qui suit ne l’efface.

Article connexe : Test de Browsertrix Crawler.

Dans l’univers open source, la comparaison dépend de ce que vous cherchez à optimiser. Si vous voulez un framework Python avec contrôle du crawl et une philosophie centrée sur les requêtes, Scrapy est souvent un analogue plus proche ; cet article n’a pas mesuré son empreinte d’installation sur la même base. Si vous voulez un crawler Go compact sans navigateur, Colly est une autre option à évaluer. Si votre problème consiste à transformer des pages en contenu prêt pour un LLM plutôt qu’à découvrir des URL, Crawl4AI vise une autre couche.

Un service managé comme Thunderbit place le fetch, le rendu et l’extraction derrière une API, tandis que Nutch garde l’état du crawl et l’infrastructure sous votre contrôle. Thunderbit n’a pas été exécuté sur ce fixture ; il s’agit donc ici d’une comparaison de modèle de propriété, pas d’une affirmation sur un rappel équivalent ou sur les performances sur pages dynamiques.

Le compromis est entre maîtrise et surcharge, et il n’est pas subtil. Nutch vous donne un contrôle total, un crawldb persistant, une scalabilité pensée pour le cluster et un coût marginal nul — en échange d’une JVM, d’un verrouillage sur un JDK LTS, de 396 Mo de JARs, d’une boucle par tours et de votre propre couche d’indexation. Une API managée vous fournit une sortie structurée dès le premier appel et aucune infrastructure — en échange d’une tarification à l’appel et d’un contrôle moindre sur la frontière de crawl. Si votre mission est « indexer 50 millions de pages », le modèle de Nutch est le bon et une API serait absurde. Si votre mission est « extraire des enregistrements structurés de 200 pages produit avant jeudi », c’est l’inverse.

Essayez Thunderbit pour l’extraction de données web

Verdict

Apache Nutch mérite d’être évalué si vous lancez un crawl continu, multi-domaines, et que vous exploitez déjà une infrastructure JVM. Sur ce fixture, sa découverte statique a été déterministe à chaque répétition, parse-js a trouvé les deux endpoints JavaScript littéraux, les échecs sont restés représentés dans le crawldb, et l’espacement observé des requêtes correspondait au délai configuré.

Évaluez honnêtement le coût d’entrée. Nutch 1.22 a échoué ici sur JDK 26.0.1 ; OpenJDK 17.0.20 est la configuration LTS réellement vérifiée dans ce test, tandis que Java 21 n’a pas été testé. Ensuite, définissez http.agent.name, fixez explicitement votre périmètre et tenez compte du plancher fixe observé d’environ 1,77 seconde par phase dans ce petit test local. Le sens de ce compromis dépend de la durée du crawl, de son ampleur et du besoin de persistance d’état.

Essayez Thunderbit pour l’extraction de données web Get Started Free

FAQ

Pourquoi Apache Nutch échoue-t-il avec « getSubject is not supported » ? Sur JDK 24 ou plus récent, JEP 486 a rendu Subject.getSubject() systématiquement fautif, alors que Hadoop 3.4.2 embarqué continuait de l’appeler. Le premier job Hadoop échoue donc avant toute récupération de page, et l’ancien contournement -Djava.security.manager=allow ne permet plus de démarrer la VM. Utilisez la configuration Java 17 vérifiée et définissez NUTCH_JAVA_HOME ; Java 21 peut être pris en charge, mais ce test n’a pas exécuté la boucle complète dessus.

Quelle version de Java dois-je utiliser avec Nutch 1.22 ? Java 17 est le choix le plus sûr — la CI de Nutch le cible, et il a fonctionné sans problème dans mes tests sur OpenJDK 17.0.20. Java 11 reste également pris en charge pour la 1.22, même si le projet a annoncé que la 1.23 exigera Java 17. Tout JDK à partir de 24 ne fonctionnera pas. Une installation Homebrew keg-only (brew install openjdk@17) avec NUTCH_JAVA_HOME permet de conserver le JDK par défaut du système inchangé.

Nutch peut-il crawler des sites très riches en JavaScript ? Partiellement, et la distinction est importante. Avec le plugin parse-js activé, Nutch a trouvé les deux endpoints qui n’existaient que comme littéraux de chaîne dans un fichier JavaScript lié — 2/2, sans navigateur. Il n’en a trouvé aucun avec le jeu de plugins par défaut. En revanche, un endpoint qui n’apparaît qu’après exécution du JavaScript et modification du DOM est resté inaccessible dans toutes les configurations statiques que j’ai testées, et le remplacement par le protocole HtmlUnit n’a pas été un changement direct et immédiat dans mon essai. Pour des applications rendues côté client, prévoyez un protocole exécutant du JavaScript et un vrai travail de configuration, ou utilisez un autre outil.

Nutch a-t-il besoin que Hadoop et Solr soient installés ? Non. Le mode local utilise le LocalJobRunner de Hadoop en processus — pas de cluster, pas de démon HDFS, pas de YARN — et toute la boucle inject → generate → fetch → parse → updatedb fonctionne sur une seule machine sans autre installation. Solr est la destination d’indexation habituelle, mais le crawl lui-même n’en dépend pas. Cela dit, les JARs Hadoop sont embarqués (13 au total, version 3.4.2), ce qui explique précisément pourquoi le problème de compatibilité JDK existe.

Comment empêcher Nutch de crawler d’autres sites ? Définissez-le explicitement, car la valeur par défaut livrée ne le fait pas. Nutch 1.22 fournit db.ignore.external.links=false avec un filtre d’URL permissif, et dans mon test le crawl par défaut a suivi un lien vers un autre hôte et l’a récupéré. Soit vous définissez db.ignore.external.links=true dans nutch-site.xml, soit vous ajoutez une règle d’hôte dans conf/regex-urlfilter.txt (par exemple +^https://example\.com/ suivi de -.). Les deux méthodes ont entièrement contenu le crawl lors des tests, vérifié à la fois dans le crawldb de Nutch et dans le journal des requêtes du serveur cible.