Web scraping en Java : créer un scraper Java fiable

La meilleure pile est celle qui est la moins complexe et qui renvoie les données de manière fiable. Commencez par interroger l’URL une seule fois, inspectez le corps de la réponse et comparez-le à ce que le navigateur affiche. Si les valeurs existent déjà dans la réponse du serveur, HttpClient et Jsoup suffisent généralement. Si la page expose une requête JSON, appelez plutôt ce point de terminaison. N’ajoutez le rendu ou l’automatisation du navigateur que lorsque les données dépendent réellement de JavaScript ou d’une interaction de l’utilisateur.

Cette règle de décision permet de garder un projet de scraping web en Java de petite taille, testable et peu coûteux à exploiter.

Avant de choisir une bibliothèque, déterminez comment les données cibles parviennent au navigateur :

Ne déduisez pas le type de page à partir de sa complexité visuelle. Une interface hautement interactive peut s'alimenter à partir d'un simple point de terminaison JSON, tandis qu'un simple tableau peut être assemblé dans le navigateur.

Suivez cette séquence d’inspection :

1. Envoyez une requête GET normale et enregistrez le statut, le type de contenu et la première partie du corps de la réponse.
2. Recherchez dans le code HTML renvoyé une valeur que vous pouvez voir à l'écran.
3. Ouvrez DevTools, rechargez la page et filtrez le panneau Réseau sur « Fetch/XHR ».
4. Inspectez les charges utiles des réponses, les méthodes de requête, les paramètres de requête, les en-têtes et les jetons de pagination.
5. Déterminez si l'accès requis correspond à une requête HTML directe, une requête JSON, un résultat affiché ou une interaction avec le navigateur.

Un point de terminaison JSON n’est pas automatiquement public ni sans restriction. Respectez les procédures d’authentification requises, observez les conditions d’utilisation du site et évitez de copier aveuglément des jetons à durée de vie limitée. De même, l’automatisation du navigateur n’est pas une solution universelle pour contourner les contrôles d’accès. Elle offre simplement à votre code Java un véritable environnement d’exécution de navigateur.

Pour les pages statiques, le web scraping avec Jsoup fonctionne bien car Jsoup transforme une chaîne HTML en un document interrogeable. Pour une étude plus approfondie de l’analyse syntaxique HTML en Java avec Jsoup, la couche d’analyse syntaxique peut être étudiée indépendamment de la couche réseau. Cette séparation prendra toute son importance plus tard, lorsque le mécanisme de récupération évoluera.

Évitez de regrouper les appels HTTP, les sélecteurs, la pagination, les tentatives de réessai et l’écriture de fichiers dans une seule main méthode. Une conception simple comportant quatre responsabilités suffit :

fetch:  URI -> status, headers, HTML
parse:  HTML + base URI -> typed records and next link
crawl:  decide which URI to visit next and enforce limits
output: validate, deduplicate, and persist records

Représentez la limite de la récupération à l’aide d’une interface :

public interface PageFetcher {
    FetchResult fetch(URI uri) throws IOException, InterruptedException;
}

public record FetchResult(
        URI uri,
        int statusCode,
        HttpHeaders headers,
        String body) {}

L’analyseur ne doit rien savoir des proxys, des cookies, des tentatives de reconnexion ou des pilotes de navigateur. Il reçoit du texte et une URI de base, puis renvoie des enregistrements de domaine. Le robot d’exploration gère les limites de pages, les URL visitées et l’ordre des requêtes. La couche de sortie gère la normalisation et le stockage.

Conservez les métadonnées de transport disponibles même lorsque l’analyseur ne les utilise pas. Les codes d’état, les en-têtes de réponse, les destinations finales des redirections et le temps écoulé sont utiles pour les décisions de nouvelle tentative et les diagnostics. Le fait de transmettre ces détails FetchResult empêche l’analyseur de devenir couplé à un client HTTP particulier.

Il ne s’agit pas d’un framework. C’est juste la structure minimale nécessaire pour permettre à un scraper web Java d’évoluer sans avoir à réécrire les sélecteurs à chaque fois que la couche de requêtes change. Cela crée également des points de test évidents : le code HTML enregistré permet de tester l’analyse, un faux PageFetcher permet de tester la logique d’exploration, et les fichiers temporaires permettent de tester la sortie.

Transformez maintenant le modèle de décision en un projet fonctionnel. La première version récupérera une page de présentation autorisée, analysera les fiches produits, résoudra les liens relatifs et affichera les enregistrements saisis. Les sections suivantes étendront le même récupérateur et le même analyseur plutôt que de les remplacer.

Utilisez un JDK Java 21 complet, et non une installation « runtime only » :

java -version
javac -version

HttpClient faisant partie du JDK, Jsoup est la seule dépendance requise pour l’exemple statique. Le code source fourni spécifie Jsoup 1.21.2, mais cette version est sensible à la date. Vérifiez la version actuelle compatible avec Java 21 avant la publication et relancez la compilation.

<!-- pom.xml -->
<properties>
    <maven.compiler.release>21</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <jsoup.version>1.21.2</jsoup.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.jsoup</groupId>
        <artifactId>jsoup</artifactId>
        <version>${jsoup.version}</version>
    </dependency>
</dependencies>

L'équivalent Gradle compact est :

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

dependencies {
    implementation 'org.jsoup:jsoup:1.21.2'
}

Choisissez un outil de compilation et utilisez-le de manière cohérente. Maven rend le graphe de dépendances explicite en XML ; Gradle est plus concis mais introduit son propre langage de compilation (DSL). Aucun des deux ne modifie l’architecture du scraper.

Une structure de code minimale permet de garder les responsabilités bien visibles :

src/main/java/example/
  PageFetcher.java
  FetchResult.java
  HttpPageFetcher.java
  Book.java
  BookParser.java
  StaticBookScraper.java

Le tutoriel utilise un seul fichier ci-dessous afin que vous puissiez l’exécuter rapidement. Une fois que la première requête fonctionne, répartissez les types imbriqués dans ces fichiers sans modifier leurs contrats publics. Cela facilite ensuite le test isolé des classes de crawler, de nouvelle tentative et de sortie.

Modélisez chaque ligne extraite sous forme d’enregistrement Java plutôt que de transmettre des listes parallèles de chaînes de caractères :

public record Book(
        String title,
        String price,
        URI detailUrl,
        URI sourcePage) {}

Un sélecteur CSS doit décrire une structure stable, et non une position fortuite. Privilégiez un conteneur de produit répété associé à des descendants sémantiques, tels que article.product_pod, h3 a, et .price_color. Évitez les sélecteurs construits à partir de noms de classes générés ou de longues div:nth-child(...) , à moins que le balisage ne vous laisse pas d’autre choix. Une fiche de référence sur les sélecteurs CSS est utile lorsque vous avez besoin de sélecteurs d’attribut, d’enfants, de frères ou composés.

Considérez chaque correspondance interne comme facultative. selectFirst() renvoie null lorsque le balisage change ; ne lisez donc l’élément qu’après l’avoir vérifié. Normalisez également le texte à la limite et conservez la page source à des fins de traçabilité.

static List<Book> parseBooks(String html, URI pageUri) {
    Document document = Jsoup.parse(html, pageUri.toString());
    List<Book> books = new ArrayList<>();

    for (Element card : document.select("article.product_pod")) {
        Element link = card.selectFirst("h3 a");
        Element price = card.selectFirst(".price_color");

        if (link == null || price == null) {
            continue;
        }

        String title = link.attr("title").trim();
        if (title.isBlank()) {
            title = link.text().trim();
        }

        String absoluteUrl = link.absUrl("href");
        String cleanPrice = price.text().trim();

        if (title.isBlank() || absoluteUrl.isBlank() || cleanPrice.isBlank()) {
            continue;
        }

        books.add(new Book(
                title,
                cleanPrice,
                URI.create(absoluteUrl),
                pageUri));
    }

    return List.copyOf(books);
}

L’URI de base transmise à Jsoup.parse() est ce qui rend absUrl("href") utile. Elle résout les liens tels que catalogue/book.html par rapport à la page qui les contenait. Cette méthode est plus sûre que la concaténation de chaînes de caractères, en particulier lorsque la pagination redirige le robot d’indexation vers un sous-répertoire.

La résilience d’un sélecteur ne doit pas être confondue avec son imprécision. Un sélecteur tel que a peut survivre à une refonte mais renvoyer des liens de navigation sans rapport. Sélectionnez le conteneur stable le plus restreint, extrayez uniquement les champs qui lui appartiennent et comptez les champs obligatoires manquants. Pendant le développement, enregistrez un petit modèle HTML autorisé et testez l’analyseur par rapport à celui-ci. Cela permet de distinguer une régression du balisage d’un problème réseau.

Le programme en un seul fichier ci-dessous constitue un point de départ compilable pour le scraping Web avec Java HttpClient. Il sépare les tâches de récupération et d’analyse, vérifie le statut et le type de contenu, et limite à la fois la durée de connexion et le temps par requête.

package example;

import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpHeaders;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;
import java.util.ArrayList;
import java.util.List;

import org.jsoup.Jsoup;
import org.jsoup.nodes.Document;
import org.jsoup.nodes.Element;

public final class StaticBookScraper {
    record FetchResult(
            URI uri,
            int statusCode,
            HttpHeaders headers,
            String body) {}

    record Book(
            String title,
            String price,
            URI detailUrl,
            URI sourcePage) {}

    interface PageFetcher {
        FetchResult fetch(URI uri)
                throws IOException, InterruptedException;
    }

    static final class HttpPageFetcher implements PageFetcher {
        private final HttpClient client = HttpClient.newBuilder()
                .connectTimeout(Duration.ofSeconds(20))
                .followRedirects(HttpClient.Redirect.NORMAL)
                .build();

        @Override
        public FetchResult fetch(URI uri)
                throws IOException, InterruptedException {
            HttpRequest request = HttpRequest.newBuilder(uri)
                    .timeout(Duration.ofSeconds(60))
                    .header(
                            "User-Agent",
                            "Java21TutorialScraper/1.0 (+contact@example.com)")
                    .GET()
                    .build();

            HttpResponse<String> response = client.send(
                    request,
                    HttpResponse.BodyHandlers.ofString());

            return new FetchResult(
                    response.uri(),
                    response.statusCode(),
                    response.headers(),
                    response.body());
        }
    }

    static List<Book> parseBooks(String html, URI pageUri) {
        Document document = Jsoup.parse(html, pageUri.toString());
        List<Book> books = new ArrayList<>();

        for (Element card : document.select("article.product_pod")) {
            Element link = card.selectFirst("h3 a");
            Element price = card.selectFirst(".price_color");

            if (link == null || price == null) {
                continue;
            }

            String title = link.attr("title").trim();
            if (title.isBlank()) {
                title = link.text().trim();
            }

            String detailUrl = link.absUrl("href");
            String cleanPrice = price.text().trim();

            if (!title.isBlank()
                    && !detailUrl.isBlank()
                    && !cleanPrice.isBlank()) {
                books.add(new Book(
                        title,
                        cleanPrice,
                        URI.create(detailUrl),
                        pageUri));
            }
        }

        return List.copyOf(books);
    }

    public static void main(String[] args) throws Exception {
        URI start = URI.create("https://books.toscrape.com/");
        PageFetcher fetcher = new HttpPageFetcher();

        FetchResult response = fetcher.fetch(start);
        if (response.statusCode() < 200
                || response.statusCode() >= 300) {
            throw new IOException(
                    "Unexpected HTTP status "
                            + response.statusCode()
                            + " for "
                            + response.uri());
        }

        String contentType = response.headers()
                .firstValue("Content-Type")
                .orElse("");
        if (!contentType.toLowerCase().contains("text/html")) {
            throw new IOException(
                    "Expected HTML but received " + contentType);
        }

        List<Book> books = parseBooks(
                response.body(),
                response.uri());

        System.out.printf(
                "Fetched %s, extracted %d records%n",
                response.uri(),
                books.size());

        books.stream()
                .limit(3)
                .forEach(book -> System.out.printf(
                        "%s | %s | %s%n",
                        book.title(),
                        book.price(),
                        book.detailUrl()));
    }
}

Compilez-le via Maven ou Gradle afin que Jsoup figure dans le classpath. La sortie doit indiquer l’URL récupérée, le nombre d’éléments extraits et jusqu’à trois enregistrements. Ne codez pas en dur le nombre de pages attendu ni les titres d’exemple, car le contenu et le balisage du site d’entraînement peuvent changer.

Plusieurs détails sont intentionnels. Une HttpClient instance est réutilisée car les clients gèrent les connexions et la configuration. La requête a un délai limité, les redirections sont gérées explicitement et l’URI de la réponse finale devient l’URI de base de l’analyseur. Le programme vérifie que le code de statut se situe dans la plage 2xx plutôt que de se contenter de 200, puis vérifie que la réponse ressemble à du HTML avant d’appliquer les sélecteurs.

L’exemple lève une exception en cas d’échec de transport ou de protocole, car une commande d’une seule page doit signaler clairement son échec. Un robot d’indexation nécessite un comportement plus nuancé : classer l’échec, ne réessayer que les cas transitoires, enregistrer le résultat final et continuer lorsque la politique le permet. Nous ajouterons ce comportement ultérieurement sans modifier parseBooks().

Le User-Agent dans l’exemple identifie l’application plutôt que de se faire passer pour un navigateur spécifique. Certains sites peuvent exiger des en-têtes supplémentaires, mais ceux-ci doivent refléter la requête que vous effectuez réellement. Si un adaptateur de récupération ultérieur a besoin d’un secret, lisez-le avec System.getenv() et signalez clairement l’échec s’il est absent.

Un extracteur d’une seule page devient un robot d’indexation Java lorsqu’il choisit et suit des URL supplémentaires. Ce changement introduit un état et des règles de terminaison. Conservez le récupérateur et l’analyseur existants, puis ajoutez un coordinateur de robot d’indexation qui gère la page actuelle, l’ensemble des pages visitées, la limite de pages et le corps de la réponse mise en cache.

Le code Java de scraping avec pagination doit comporter plusieurs conditions d’arrêt. Arrêtez-vous lorsque le lien suivant disparaît, lorsque l’URL suivante est invalide, lorsqu’une URL se répète, en cas d’échec de la réponse ou lorsque la limite de pages configurée est atteinte. Cette limite vous protège contre les balises corrompues et la traversée accidentelle de l’ensemble du site.

Ajoutez un type de résultat et une méthode de crawl autour de l’ PageFetcher et parseBooks() :

record CrawlResult(
        List<Book> books,
        Map<URI, String> htmlByPage) {}

static CrawlResult crawlPages(
        URI start,
        int maxPages,
        PageFetcher fetcher)
        throws IOException, InterruptedException {

    if (maxPages < 1) {
        throw new IllegalArgumentException(
                "maxPages must be positive");
    }

    Set<URI> visited = new LinkedHashSet<>();
    Map<URI, String> cache = new LinkedHashMap<>();
    List<Book> books = new ArrayList<>();

    URI current = normalize(start);

    while (current != null && cache.size() < maxPages) {
        URI requested = normalize(current);
        if (!visited.add(requested)) {
            System.err.println(
                    "Stopping at repeated URL: " + requested);
            break;
        }

        FetchResult response = fetcher.fetch(requested);
        if (response.statusCode() < 200
                || response.statusCode() >= 300) {
            System.err.printf(
                    "Stopping after status %d for %s%n",
                    response.statusCode(),
                    requested);
            break;
        }

        URI finalUri = normalize(response.uri());
        if (cache.putIfAbsent(finalUri, response.body()) != null) {
            System.err.println(
                    "Stopping after redirect to cached URL: "
                            + finalUri);
            break;
        }
        visited.add(finalUri);

        books.addAll(parseBooks(
                response.body(),
                finalUri));

        Document document = Jsoup.parse(
                response.body(),
                finalUri.toString());

        Element next = document.selectFirst(
                "a[rel=next], li.next a");

        if (next == null) {
            current = null;
            continue;
        }

        String absoluteNext = next.absUrl("href");
        current = absoluteNext.isBlank()
                ? null
                : URI.create(absoluteNext);
    }

    return new CrawlResult(
            List.copyOf(books),
            Map.copyOf(cache));
}

static URI normalize(URI uri) {
    try {
        return new URI(
                uri.getScheme(),
                uri.getAuthority(),
                uri.getPath(),
                uri.getQuery(),
                null).normalize();
    } catch (URISyntaxException e) {
        throw new IllegalArgumentException(
                "Cannot normalize URI: " + uri,
                e);
    }
}

Cette méthode analyse deux fois le corps de chaque réponse récupérée : une fois pour les enregistrements et une fois pour le lien suivant. Cela ne coûte pas cher pour les petites pages, mais vous pouvez renvoyer à la fois les enregistrements et l’URI suivante à partir d’un seul appel d’analyseur si le profilage révèle un coût significatif. L’optimisation importante consiste à éviter une deuxième requête réseau, et non à supprimer prématurément une minuscule analyse du DOM.

Le groupe de sélecteurs prend en charge un lien de type rel=next et la forme du paginateur du site d’entraînement. Considérez-le comme un point de départ, et non comme un sélecteur universel. Examinez le paginateur réel et séparez les sélecteurs de navigation des sélecteurs de produits afin de pouvoir isoler facilement toute modification.

Appelez le robot d’indexation avec une capacité délibérément réduite pendant le développement :

CrawlResult result = crawlPages(
        URI.create("https://books.toscrape.com/"),
        3,
        new HttpPageFetcher());

System.out.printf(
        "Pages: %d, records: %d%n",
        result.htmlByPage().size(),
        result.books().size());

Le nombre 3 constitue une limite de sécurité pour cette exécution, et non un total présumé. N’augmentez-le qu’après avoir confirmé que le sélecteur « next-link » reste dans l’hôte et le chemin prévus. Dans le code de production, rejetez toute URL suivante hors site avant de la récupérer.

Pour la pagination JSON basée sur un curseur, la structure de la boucle est identique. Remplacez next.absUrl("href") par l’extraction du curseur ou du jeton suivant, et arrêtez-vous lorsque le jeton est absent ou répété. Ne devinez pas les numéros de page lorsque le serveur fournit une valeur de continuation explicite.

L’ensemble des URL visitées répond à une question : avons-nous déjà tenté cette URL normalisée ? Le cache HTML répond à une autre : avons-nous déjà téléchargé le contenu de cette URL finale ? Vous avez besoin des deux, car les redirections peuvent mapper plusieurs URL demandées vers une seule page, et les paginateurs mal formés peuvent pointer vers des pages antérieures.

La réutilisation du code HTML de découverte constitue un atout pratique pour les robots d’exploration Java dédiés au web scraping. Une conception courante mais inefficace consiste d’abord à parcourir la pagination pour collecter les URL, puis à récupérer à nouveau chaque URL lors de l’extraction parallèle. Le code ci-dessus stocke chaque réponse réussie au fur et à mesure qu’il découvre le lien suivant, de sorte qu’une phase d’analyse ultérieure puisse exploiter directement le cache :

List<Book> reparsed = cache.entrySet().stream()
        .flatMap(entry -> parseBooks(
                entry.getValue(),
                entry.getKey()).stream())
        .toList();

Aucun appel HTTP n’a lieu dans ce pipeline. Si vous parallélisez l’analyse par la suite, parallélisez ces valeurs mises en cache ou transmettez-les à votre propre exécuteur. Ne recourez pas silencieusement à un autre téléchargement.

La normalisation des URL doit être pratiquée avec modération. La suppression des fragments est généralement appropriée, car ceux-ci ne sont pas envoyés dans les requêtes HTTP. La suppression des paramètres de requête n’est généralement pas sans risque, car ces paramètres peuvent identifier des pages, des filtres ou des curseurs. Définissez des règles de canonicalisation pour la cible plutôt que de supprimer des données de manière globale.

Un cache en mémoire n’est limité que par maxPages et de la taille de la page. Pour un petit crawl de tutoriels, cela est acceptable. Pour une exécution de longue durée, stockez des instantanés de réponse sur disque ou traitez-les par lots limités. La mise en cache doit réduire le nombre de requêtes, et non créer un tas illimité.

La concurrence est un outil de débit, et non la garantie qu’un exploration se terminera plus rapidement. Le service distant, le réseau, le processeur, la mémoire et les limites de réponse peuvent tous devenir des goulots d’étranglement. Commencez de manière séquentielle, effectuez des mesures, puis introduisez une petite limite explicite. Une conception Java contrôlée de scraping Web parallèle doit indiquer clairement le nombre maximal de requêtes en cours de traitement.

Un pool fixe rend le plafond de requêtes égal au nombre de travailleurs. Soumettez une URL indépendante par tâche, conservez chacune d’entre elles Future, et attendez qu’elle soit terminée afin que les échecs de tâches ne soient pas perdus.

static List<Book> scrapeConcurrently(
        Collection<URI> urls,
        int maxInFlight,
        PageFetcher fetcher)
        throws InterruptedException, ExecutionException {

    ExecutorService executor =
            Executors.newFixedThreadPool(maxInFlight);

    Queue<Book> results = new ConcurrentLinkedQueue<>();
    Set<URI> claimed = ConcurrentHashMap.newKeySet();
    List<Future<?>> futures = new ArrayList<>();

    try {
        for (URI rawUrl : urls) {
            URI url = normalize(rawUrl);
            if (!claimed.add(url)) {
                continue;
            }

            futures.add(executor.submit(() -> {
                FetchResult response = fetcher.fetch(url);

                if (response.statusCode() >= 200
                        && response.statusCode() < 300) {
                    results.addAll(parseBooks(
                            response.body(),
                            response.uri()));
                } else {
                    System.err.printf(
                            "status=%d url=%s%n",
                            response.statusCode(),
                            url);
                }
                return null;
            }));
        }

        for (Future<?> future : futures) {
            future.get();
        }
    } finally {
        executor.shutdown();
        if (!executor.awaitTermination(
                30,
                TimeUnit.SECONDS)) {
            executor.shutdownNow();
        }
    }

    return List.copyOf(results);
}

ConcurrentLinkedQueue prend en charge les ajouts concurrents fréquents sans copier l’intégralité de la structure sous-jacente. ConcurrentHashMap.newKeySet() offre un comportement atomique de type « vu ou non vu » grâce à add(). Un ArrayList ou HashSet n’est pas sûr pour les écritures simultanées, à moins que l’accès ne soit synchronisé. CopyOnWriteArrayList constitue généralement un mauvais réceptacle de résultats, car chaque écriture copie son tableau sous-jacent.

La futures reste une ArrayList car seul le thread coordinateur y écrit. La sécurité des threads doit être appliquée là où le partage a réellement lieu, et non pas de manière systématique à toutes les collections.

L'appel à get() est important. Si une tâche lève une exception, le coordinateur reçoit une ExecutionException au lieu d’afficher un message de réussite optimiste alors que des pages ont échoué en silence. Dans un robot d’indexation fonctionnant en continu, décomposez cette cause, enregistrez l’URL et décidez si les autres tâches peuvent se poursuivre. Si le coordinateur est interrompu, conservez l’état d’interruption après le nettoyage plutôt que de l’ignorer.

N’utilisez pas parallelStream() simplement pour gagner quelques lignes de code. Il utilise par défaut le pool « fork-join » commun, qui masque la limite de requêtes et peut entrer en conflit avec des tâches sans rapport dans le même processus. Un exécuteur explicite fournit au scraper une file d’attente, un cycle de vie et une capacité observables.

Un pool fixe est facile à appréhender et reste un bon choix par défaut pour un scraper web Java de taille modeste. Commencez par une limite mesurée faible, surveillez la latence et les codes d’état, puis augmentez-la progressivement. La documentation fournie mentionne de petites plages à titre de démonstration, mais il n’existe pas de nombre de threads universellement sûr. Les limites publiées par la cible et votre propre budget de requêtes sont plus importants.

Les threads virtuels de Java 21 facilitent la mise à l’échelle du code d’E/S bloquant sans nécessiter la gestion d’un vaste pool de threads au niveau de la plateforme. La JEP 444 d’OpenJDK les décrit comme des threads légers gérés par la JVM, destinés à prendre en charge des applications concurrentes à haut débit. Ils ne suppriment toutefois pas la nécessité de limiter la pression exercée sur un service distant.

Utilisez un thread virtuel par tâche et un sémaphore pour la limite HTTP effective :

static List<Book> scrapeWithVirtualThreads(
        Collection<URI> urls,
        int maxInFlight,
        PageFetcher fetcher)
        throws InterruptedException, ExecutionException {

    Semaphore permits = new Semaphore(maxInFlight);
    Queue<Book> results = new ConcurrentLinkedQueue<>();
    Set<URI> claimed = ConcurrentHashMap.newKeySet();
    List<Future<Void>> futures = new ArrayList<>();

    try (ExecutorService executor =
                 Executors.newVirtualThreadPerTaskExecutor()) {

        for (URI rawUrl : urls) {
            URI url = normalize(rawUrl);
            if (!claimed.add(url)) {
                continue;
            }

            futures.add(executor.submit(() -> {
                permits.acquire();
                try {
                    FetchResult response = fetcher.fetch(url);
                    if (response.statusCode() >= 200
                            && response.statusCode() < 300) {
                        results.addAll(parseBooks(
                                response.body(),
                                response.uri()));
                    }
                } finally {
                    permits.release();
                }
                return null;
            }));
        }

        for (Future<Void> future : futures) {
            future.get();
        }
    }

    return List.copyOf(results);
}

Le nombre de threads virtuels peut être élevé, mais seules maxInFlight tâches peuvent entrer dans le bloc de récupération. Acquérir le permis immédiatement avant l’opération soumise à la contrainte et le libérer dans finally. Ne le conservez pas pendant l’écriture d’enregistrements dans une base de données ou pendant l’exécution de tâches CPU sans rapport, à moins que ces opérations ne partagent la même limite.

Si la pagination a déjà mis en cache du code HTML, soumettez les tâches d’analyse sur le cache au lieu d’appeler fetcher à nouveau. L’analyse est généralement une tâche CPU, effectuez donc des tests de performance avant de lui attribuer des milliers de threads virtuels. Les threads virtuels sont principalement conçus pour optimiser les opérations bloquantes, et non pour accélérer tous les calculs.

Pour le web scraping avec des threads virtuels Java, la simplicité est le principal avantage. Si un pool fixe suffit déjà à gérer la charge de travail, les threads virtuels ne constituent pas une mise à niveau obligatoire. Dans les deux versions, ajoutez des tentatives de réessai et des limites par hôte avant d’augmenter la concurrence.

Un scraper fiable ne traite pas de la même manière toutes les réponses autres que celles du code 2xx. Réessayez les échecs qui sont vraisemblablement temporaires, tels que les limites de débit, certaines erreurs de serveur, les délais d’expiration et les réinitialisations de connexion. Ne réessayez pas aveuglément en cas d’échecs d’authentification, de requêtes interdites, de pages manquantes ou de requêtes mal formées. Ces cas nécessitent généralement une modification des identifiants, des autorisations, de l’URL ou de la structure de la requête.

La politique de réessai ci-dessous encapsule le même PageFetcher contrat. Elle limite le nombre de tentatives, respecte une Retry-After avant de calculer le délai de repli local, ajoute du jitter et enregistre les échecs définitifs. La sémantique HTTP correspondante est définie dans la section « Retry-After » de la RFC 9110.

final class RetryingHttpFetcher implements PageFetcher {
    record Failure(
            URI uri,
            int attempts,
            Integer statusCode,
            String message,
            String bodyPreview) {}

    private final HttpClient client;
    private final int maxAttempts;
    private final Duration baseDelay;
    private final Duration maxDelay;
    private final Queue<Failure> failures =
            new ConcurrentLinkedQueue<>();

    RetryingHttpFetcher(
            HttpClient client,
            int maxAttempts,
            Duration baseDelay,
            Duration maxDelay) {

        if (maxAttempts < 1) {
            throw new IllegalArgumentException(
                    "maxAttempts must be positive");
        }

        this.client = client;
        this.maxAttempts = maxAttempts;
        this.baseDelay = baseDelay;
        this.maxDelay = maxDelay;
    }

    @Override
    public FetchResult fetch(URI uri)
            throws IOException, InterruptedException {

        for (int attempt = 1;
             attempt <= maxAttempts;
             attempt++) {

            HttpRequest request = HttpRequest.newBuilder(uri)
                    .timeout(Duration.ofSeconds(60))
                    .header(
                            "User-Agent",
                            "Java21TutorialScraper/1.0 "
                                    + "(+contact@example.com)")
                    .GET()
                    .build();

            HttpResponse<String> response;
            try {
                response = client.send(
                        request,
                        HttpResponse.BodyHandlers.ofString());
            } catch (IOException error) {
                if (!isTransient(error)
                        || attempt == maxAttempts) {
                    recordFailure(
                            uri,
                            attempt,
                            null,
                            error.toString(),
                            "");
                    throw error;
                }

                Duration delay = backoff(attempt);
                logRetry(
                        uri,
                        null,
                        error.getClass().getSimpleName(),
                        attempt,
                        delay,
                        "");
                Thread.sleep(delay);
                continue;
            }

            int status = response.statusCode();
            if (status >= 200 && status < 300) {
                return new FetchResult(
                        response.uri(),
                        status,
                        response.headers(),
                        response.body());
            }

            String preview = preview(response.body(), 300);
            boolean retryable = isRetryableStatus(status);

            if (!retryable || attempt == maxAttempts) {
                String message = retryable
                        ? "retry limit reached"
                        : "non-retryable HTTP status";

                recordFailure(
                        response.uri(),
                        attempt,
                        status,
                        message,
                        preview);

                throw new IOException(
                        message + ": " + status
                                + " for " + response.uri());
            }

            Duration delay = retryAfter(
                    response.headers()).orElseGet(
                            () -> backoff(attempt));

            logRetry(
                    response.uri(),
                    status,
                    "HTTP",
                    attempt,
                    delay,
                    preview);

            Thread.sleep(delay);
        }

        throw new IllegalStateException(
                "Retry loop exited unexpectedly");
    }

    List<Failure> failures() {
        return List.copyOf(failures);
    }

    private boolean isRetryableStatus(int status) {
        return status == 408
                || status == 429
                || status == 500
                || status == 502
                || status == 503
                || status == 504;
    }

    private boolean isTransient(IOException error) {
        for (Throwable cause = error;
             cause != null;
             cause = cause.getCause()) {
            if (cause instanceof HttpTimeoutException
                    || cause instanceof ConnectException
                    || cause instanceof SocketException) {
                return true;
            }
        }
        return false;
    }

    private Optional<Duration> retryAfter(
            HttpHeaders headers) {

        return headers.firstValue("Retry-After")
                .flatMap(this::parseRetryAfter)
                .map(this::capDelay);
    }

    private Optional<Duration> parseRetryAfter(
            String rawValue) {

        String value = rawValue.trim();

        try {
            long seconds = Long.parseLong(value);
            return Optional.of(Duration.ofSeconds(
                    Math.max(0, seconds)));
        } catch (NumberFormatException ignored) {
            // Try the HTTP-date form next.
        }

        try {
            Instant retryAt = ZonedDateTime.parse(
                    value,
                    DateTimeFormatter.RFC_1123_DATE_TIME)
                    .toInstant();

            Duration delay = Duration.between(
                    Instant.now(),
                    retryAt);

            return Optional.of(
                    delay.isNegative()
                            ? Duration.ZERO
                            : delay);
        } catch (DateTimeParseException ignored) {
            return Optional.empty();
        }
    }

    private Duration backoff(int attempt) {
        long multiplier =
                1L << Math.min(attempt - 1, 10);

        long ceiling = Math.min(
                maxDelay.toMillis(),
                baseDelay.toMillis() * multiplier);

        long floor = Math.min(
                baseDelay.toMillis(),
                ceiling);

        long millis = ceiling <= floor
                ? ceiling
                : ThreadLocalRandom.current()
                        .nextLong(floor, ceiling + 1);

        return Duration.ofMillis(millis);
    }

    private Duration capDelay(Duration delay) {
        return delay.compareTo(maxDelay) > 0
                ? maxDelay
                : delay;
    }

    private void recordFailure(
            URI uri,
            int attempts,
            Integer status,
            String message,
            String bodyPreview) {

        failures.add(new Failure(
                uri,
                attempts,
                status,
                message,
                bodyPreview));
    }

    private void logRetry(
            URI uri,
            Integer status,
            String kind,
            int attempt,
            Duration delay,
            String bodyPreview) {

        System.err.printf(
                "retry url=%s status=%s kind=%s "
                        + "attempt=%d/%d waitMs=%d body=%s%n",
                uri,
                status == null ? "-" : status,
                kind,
                attempt,
                maxAttempts,
                delay.toMillis(),
                bodyPreview);
    }

    private static String preview(
            String body,
            int maxChars) {

        if (body == null) {
            return "";
        }

        String oneLine = body.replaceAll("\\s+", " ").trim();
        return oneLine.substring(
                0,
                Math.min(maxChars, oneLine.length()));
    }
}

Construisez-la avec des limites explicites plutôt qu’avec des constantes éparses :

HttpClient client = HttpClient.newBuilder()
        .connectTimeout(Duration.ofSeconds(20))
        .followRedirects(HttpClient.Redirect.NORMAL)
        .build();

PageFetcher fetcher = new RetryingHttpFetcher(
        client,
        4,
        Duration.ofMillis(500),
        Duration.ofSeconds(30));

Le délai local augmente approximativement de 500 millisecondes vers 1, 2 et 4 secondes, avec un élément aléatoire à l’intérieur de chaque plage. Une Retry-After a la priorité, mais cette implémentation applique le délai maximal configuré. Si attendre moins longtemps que ce que le serveur exige enfreindrait votre politique d’exploitation, arrêtez la tâche ou reprogrammez-la au lieu de plafonner le délai et de réessayer immédiatement.

N’ajoutez pas 403 à l’ensemble de réessais par défaut. Cela peut signifier que la requête est interdite ou bloquée, et la répétition sans modification de la cause ne fait qu’engendrer davantage de trafic. De même, 400, 401, et 404 sont généralement des problèmes de configuration, d’authentification ou d’URL. Une couche de réessais Java pour le web scraping doit être prudente, car chaque réessai consomme du budget de requêtes.

Les journaux de tentatives de réessai servent au diagnostic, et non au déversement de données. Enregistrez l’URL, le statut ou le type d’exception, le numéro de tentative, le temps d’attente et un bref aperçu du corps de la réponse sur une seule ligne. N’enregistrez jamais les clés API, les en-têtes d’autorisation, les cookies de session, les réponses complètes de connexion ni les charges utiles complètes contenant des données personnelles.

Suivez les résultats au niveau de l’exploration séparément des tentatives de requête :

final class CrawlMetrics {
    private final LongAdder pagesAttempted = new LongAdder();
    private final LongAdder pagesSucceeded = new LongAdder();
    private final LongAdder pagesFailed = new LongAdder();

    void attempted() {
        pagesAttempted.increment();
    }

    void succeeded() {
        pagesSucceeded.increment();
    }

    void failed() {
        pagesFailed.increment();
    }

    void printSummary() {
        System.out.printf(
                "crawl attempted=%d succeeded=%d failed=%d%n",
                pagesAttempted.sum(),
                pagesSucceeded.sum(),
                pagesFailed.sum());
    }
}

Incrémenter attempted une seule fois lorsque le robot accepte une page, et non pas à chaque nouvelle tentative. Incrémenter exactement un résultat final une fois que la récupération a abouti ou que la politique a été épuisée. À l’arrêt, afficher une liste compacte des échecs à partir RetryingHttpFetcher.failures() et des totaux agrégés. Cela fournit aux exécutions planifiées un rapport de sortie utile sans saturer les journaux avec chaque réponse réussie.

Lorsque la concurrence est activée, incluez un identifiant d’exécution et conservez chaque événement de journalisation sur une seule ligne. Cela rend la sortie entrelacée consultable. Dans un journaliseur de production, utilisez des champs structurés plutôt que d’analyser du texte brut.

Lorsque le récupérateur statique renvoie du code HTML valide mais pas les données que vous pouvez voir dans un navigateur, ne remplacez pas immédiatement l’intégralité du scraper. Déterminez d’abord d’où le navigateur a obtenu l’état manquant. Conservez parseBooks() ou son équivalent indépendant du parseur, puis ne remplacez que le fournisseur de récupération lorsque le rendu ou l’état de session est réellement nécessaire.

Le contenu dynamique est un contenu inséré ou modifié par JavaScript après la réponse initiale. Il peut tout de même provenir d’une source de données accessible, plus simple à exploiter que l’automatisation du navigateur.

Vérifiez ces emplacements dans l’ordre :

1. Recherchez la valeur visible dans le code HTML brut.
2. Inspectez les <script type="application/ld+json"> les blocs et autres états sérialisés intégrés au document.
3. Rechargez la page avec DevTools ouvert et filtrez les requêtes réseau sur Fetch/XHR.
4. Sélectionnez la requête qui renvoie les enregistrements et inspectez ses champs : méthode, URL, charge utile, réponse et pagination.
5. Vérifiez que la reproduction de cette opération est autorisée et que les identifiants ou jetons requis peuvent être obtenus de manière légitime.

Pour le JSON-LD intégré, Jsoup peut localiser le script tandis qu’une bibliothèque JSON analyse son texte :

Document document = Jsoup.parse(html, pageUri.toString());

for (Element script : document.select(
        "script[type=application/ld+json]")) {
    String json = script.data().trim();
    if (!json.isBlank()) {
        // Parse with the JSON library selected for the project.
    }
}

Pour un point de terminaison Fetch/XHR, appelez-le avec HttpClient comme n’importe quelle autre requête :

HttpRequest request = HttpRequest.newBuilder(apiUri)
        .timeout(Duration.ofSeconds(30))
        .header("Accept", "application/json")
        .GET()
        .build();

HttpResponse<String> response = client.send(
        request,
        HttpResponse.BodyHandlers.ofString());

Puis analysez response.body() avec Jackson, org.jsonou une autre bibliothèque de votre choix. Ne parsez pas le DOM visuel lorsque la réponse sous-jacente autorisée contient déjà des champs structurés stables.

L’inspection du réseau permet également de déterminer si la pagination utilise des numéros de page, des curseurs, des corps de requête POST ou des en-têtes de requête. Cependant, une requête capturée dans DevTools peut inclure des signatures à durée de vie limitée, une autorisation spécifique à l’utilisateur ou des valeurs anti-CSRF. La rejouer en dehors de la session autorisée peut échouer ou enfreindre la politique. Ne reproduisez que la requête stable minimale que votre cas d’utilisation est autorisé à effectuer.

Ce workflow de complexité minimale est au cœur du scraping web dynamique en Java : inspectez d’abord le chemin d’accès aux données, puis n’ajoutez l’exécution que lorsque l’accès aux données dépend de celle-ci.

Si l’exécution de JavaScript est nécessaire, optez soit pour la récupération de la page rendue, soit pour le contrôle total du navigateur, en fonction de l’interaction requise :

Un moteur de rendu géré doit respecter les mêmes PageFetcher limites et renvoyer FetchResult. Cela préserve l’analyseur et le robot d’indexation. Ne codez pas en dur un adaptateur de fournisseur tant que son point de terminaison actuel, son authentification, ses indicateurs de rendu, ses en-têtes et cookies transférés, ses limites et sa sémantique d’erreur n’ont pas été vérifiés.

Utilisez Selenium lorsque l’état requis n’existe qu’après un comportement du navigateur, tel que cliquer sur un onglet, valider un formulaire, faire défiler une liste infinie ou attendre un routage côté client. Au moment de la publication, vérifiez la selenium-java version et la configuration du pilote de navigateur. Les versions épinglées dans la documentation source sont sensibles au facteur temps.

Un parcours Java minimal de web scraping avec Selenium se présente comme suit :

ChromeOptions options = new ChromeOptions();
options.addArguments("--headless");

WebDriver driver = new ChromeDriver(options);

try {
    driver.get(targetUrl);

    WebDriverWait wait = new WebDriverWait(
            driver,
            Duration.ofSeconds(10));

    wait.until(
            ExpectedConditions.presenceOfElementLocated(
                    By.cssSelector(".result-card")));

    String renderedHtml = driver.getPageSource();
    URI finalUri = URI.create(driver.getCurrentUrl());

    List<Book> books = parseBooks(
            renderedHtml,
            finalUri);

    System.out.println(
            "Rendered records: " + books.size());
} finally {
    driver.quit();
}

Utilisez une attente explicite pour un état prouvant que les données sont prêtes. Les temps d’attente fixes font perdre du temps ou échouent lorsque la page est plus lente que prévu. Si un clic déclenche une pagination, attendez un changement significatif, tel que l’obsolescence de l’ancien conteneur de résultats ou la mise à jour d’un marqueur de page, avant de relire les données.

Placez toujours quit() en finally. Fermer uniquement la fenêtre active peut laisser des processus du pilote en arrière-plan. Le mode « headless » supprime l’interface visible, mais ne garantit pas de meilleures performances pour toutes les pages. Si vous avez besoin d’informations générales sur ce qu’est un navigateur « headless » et en quoi son architecture diffère de celle d’un client HTTP, considérez cela comme un sujet opérationnel distinct de l’analyse syntaxique du HTML.

Ni le rendu géré ni Selenium n’accordent l’autorisation d’accéder à du contenu restreint. Il s’agit de choix d’exécution, et non de contournements de politiques.

La gestion de session consiste à conserver l’état de l’utilisateur d’une requête à l’autre, généralement via des cookies. Associez-en un CookieManager à un client réutilisable HttpClient, lancez la procédure de connexion autorisée, puis utilisez ce même client pour les pages suivantes.

static HttpResponse<String> loginAndFetch(
        URI loginUri,
        URI dataUri)
        throws IOException, InterruptedException {

    CookieManager cookieManager = new CookieManager();
    cookieManager.setCookiePolicy(CookiePolicy.ACCEPT_ALL);

    HttpClient sessionClient = HttpClient.newBuilder()
            .cookieHandler(cookieManager)
            .followRedirects(HttpClient.Redirect.NORMAL)
            .connectTimeout(Duration.ofSeconds(20))
            .build();

    String username = requireEnv("SCRAPER_USERNAME");
    String password = requireEnv("SCRAPER_PASSWORD");

    String form = "username=" + encode(username)
            + "&password=" + encode(password);

    HttpRequest login = HttpRequest.newBuilder(loginUri)
            .timeout(Duration.ofSeconds(30))
            .header(
                    "Content-Type",
                    "application/x-www-form-urlencoded")
            .POST(HttpRequest.BodyPublishers.ofString(form))
            .build();

    HttpResponse<String> loginResponse = sessionClient.send(
            login,
            HttpResponse.BodyHandlers.ofString());

    if (loginResponse.statusCode() < 200
            || loginResponse.statusCode() >= 400) {
        throw new IOException(
                "Login failed with status "
                        + loginResponse.statusCode());
    }

    HttpRequest protectedPage =
            HttpRequest.newBuilder(dataUri)
                    .timeout(Duration.ofSeconds(30))
                    .GET()
                    .build();

    return sessionClient.send(
            protectedPage,
            HttpResponse.BodyHandlers.ofString());
}

static String requireEnv(String name) {
    String value = System.getenv(name);
    if (value == null || value.isBlank()) {
        throw new IllegalStateException(
                "Missing environment variable " + name);
    }
    return value;
}

static String encode(String value) {
    return URLEncoder.encode(
            value,
            StandardCharsets.UTF_8);
}

Cet exemple ne concerne qu’un simple formulaire qui crée des cookies. Un processus protégé contre les attaques CSRF nécessite généralement une requête GET préalable, l’extraction d’un jeton caché ou d’une autre valeur fournie par le serveur, puis l’envoi de cette valeur avec le formulaire. Certaines applications utilisent OAuth, l’authentification multifactorielle, des jetons « bearer », des vérifications d’appareil ou un état lié au navigateur. Il n’existe pas de recette générique sûre pour la connexion à ces systèmes.

Vérifiez la réussite à l’aide d’un indicateur de page authentifiée ou d’une redirection attendue, et non pas simplement d’une 200 réponse de connexion. Limitez l’acceptation des cookies si l’exploration s’étend à des domaines sans rapport, et n’enregistrez jamais le magasin de cookies. Un guide d’introduction aux cookies HTTP peut vous aider lors du débogage des paramètres de domaine, de chemin d’accès, d’expiration, Secureet SameSite comportement.

Les champs affichés prouvent que les sélecteurs ont été appariés une fois. Ils ne prouvent pas que le résultat est utilisable. Définissez le critère de réussite en termes d’enregistrements normalisés et traçables qui satisfont aux vérifications des champs obligatoires et sont stockés de manière durable. C’est là qu’un outil de scraping d’apprentissage devient un pipeline de données fiable.

Normalisez immédiatement après l’extraction afin que chaque composant en aval perçoive la même structure. Regroupez les espaces blancs répétés, convertissez les espaces insécables le cas échéant, rejetez les champs obligatoires laissés vides et conservez la page source à l’origine de chaque enregistrement.

record RawBook(
        String title,
        String priceText,
        String detailUrl,
        URI sourcePage) {}

record Book(
        String title,
        String priceText,
        URI detailUrl,
        URI sourcePage) {}

static Optional<Book> normalize(RawBook raw) {
    String title = cleanText(raw.title());
    String price = cleanText(raw.priceText());
    String detail = cleanText(raw.detailUrl());

    if (title.isBlank()
            || price.isBlank()
            || detail.isBlank()
            || raw.sourcePage() == null) {
        return Optional.empty();
    }

    URI detailUri;
    try {
        detailUri = URI.create(detail);
    } catch (IllegalArgumentException error) {
        return Optional.empty();
    }

    if (!detailUri.isAbsolute()) {
        return Optional.empty();
    }

    return Optional.of(new Book(
            title,
            price,
            detailUri,
            raw.sourcePage()));
}

static String cleanText(String value) {
    if (value == null) {
        return "";
    }

    return value
            .replace('\u00A0', ' ')
            .replaceAll("\\s+", " ")
            .trim();
}

Définissez les champs obligatoires en fonction de l’usage prévu, et non en fonction de ce qui se trouve être facile à sélectionner. Une URL de détail peut être essentielle pour la traçabilité, tandis qu’une URL d’image peut être facultative. Si le prix doit être calculé ou trié, analysez le montant et la devise pour les placer dans des champs de type spécifiques à la cible. Ne supprimez pas les symboles et ne partez pas du principe que tous les sites utilisent les mêmes séparateurs décimaux et de milliers.

Conservez les enregistrements invalides visibles à l’aide de compteurs ou d’un échantillon limité de motifs de rejet. Ignorer silencieusement chaque divergence peut transformer une régression du sélecteur en une exécution apparemment réussie avec peu de données. Dans le même temps, ne conservez pas des pages sensibles dans leur intégralité simplement pour expliquer une seule ligne erronée.

L’URL source doit figurer dans l’enregistrement même si elle ne fait pas partie du schéma métier final. Elle vous permet de reproduire une extraction, d’examiner les conflits et d’identifier le modèle de page qui a échoué.

Choisissez une clé de déduplication ayant une signification dans le domaine. Une URL de détail canonique est souvent préférable à un titre, car les titres peuvent se répéter ou changer. Pour une petite exécution en mémoire, conservez l’ordre de première apparition à l’aide d’un LinkedHashMap:

Map<URI, Book> uniqueByUrl = new LinkedHashMap<>();

for (Book book : normalizedBooks) {
    uniqueByUrl.putIfAbsent(
            normalize(book.detailUrl()),
            book);
}

List<Book> uniqueBooks =
        List.copyOf(uniqueByUrl.values());

Si les pages suivantes contiennent des valeurs plus récentes, utilisez une règle de fusion explicite au lieu de putIfAbsent. Dans tous les cas, consignez le nombre de doublons.

Un générateur de fichiers CSV sans dépendance pour l’enregistrement actuel Book enregistrement peut ressembler à ceci :

static void writeCsv(
        Path path,
        Iterable<Book> books)
        throws IOException {

    try (BufferedWriter writer = Files.newBufferedWriter(
            path,
            StandardCharsets.UTF_8)) {

        writer.write(
                "title,price,detail_url,source_page");
        writer.newLine();

        for (Book book : books) {
            writer.write(String.join(",",
                    csv(book.title()),
                    csv(book.priceText()),
                    csv(book.detailUrl().toString()),
                    csv(book.sourcePage().toString())));
            writer.newLine();
        }
    }
}

static String csv(String value) {
    String escaped = value.replace("\"", "\"\"");
    return "\"" + escaped + "\"";
}

Pour le format JSON, une bibliothèque telle que Jackson permet de sérialiser les enregistrements Java après avoir choisi et vérifié la version de ses dépendances. Pour une base de données, utilisez des instructions préparées JDBC, regroupez par lots un nombre limité d’enregistrements, validez délibérément les modifications et laissez une contrainte d’unicité appliquer la règle d’identité.

Pour la sortie vers un fichier, écrivez dans un chemin temporaire et ne déplacez le fichier à son emplacement définitif qu’après la fermeture réussie de l’éditeur. Cela empêche qu’une exécution ayant échoué ne présente un fichier CSV ou JSON à moitié écrit comme un jeu de données complet.

Ne conservez pas un ensemble de résultats illimité dans le seul but de l’écrire à la fin. Transférez les enregistrements acceptés vers un programme d’écriture, mettez-les en file d’attente vers un seul consommateur chargé de l’écriture en base de données, ou vidangez des lots limités. Séparez la limite de concurrence réseau de la capacité de la file d’attente de sortie afin que le stockage lent génère une contre-pression plutôt qu’une croissance illimitée de la mémoire.

Un statut HTTP réussi peut tout de même ne produire aucun enregistrement si un sélecteur a changé, si une page de consentement est apparue ou si la requête a reçu un modèle différent. Suivez les métriques des pages et des enregistrements à la limite de l’analyseur :

final class ExtractionMetrics {
    private final LongAdder pagesParsed = new LongAdder();
    private final LongAdder emptyPages = new LongAdder();
    private final LongAdder accepted = new LongAdder();
    private final LongAdder rejected = new LongAdder();
    private final LongAdder duplicates = new LongAdder();

    void recordPage(
            URI uri,
            int containers,
            int acceptedOnPage,
            int rejectedOnPage) {

        pagesParsed.increment();
        accepted.add(acceptedOnPage);
        rejected.add(rejectedOnPage);

        if (containers == 0 || acceptedOnPage == 0) {
            emptyPages.increment();
            System.err.printf(
                    "empty-extraction url=%s "
                            + "containers=%d accepted=%d "
                            + "rejected=%d%n",
                    uri,
                    containers,
                    acceptedOnPage,
                    rejectedOnPage);
        }
    }

    void duplicate() {
        duplicates.increment();
    }

    void printSummary() {
        System.out.printf(
                "extraction pages=%d empty=%d "
                        + "accepted=%d rejected=%d "
                        + "duplicates=%d%n",
                pagesParsed.sum(),
                emptyPages.sum(),
                accepted.sum(),
                rejected.sum(),
                duplicates.sum());
    }
}

Transmettez le nombre de conteneurs sélectionnés séparément des enregistrements acceptés. Un nombre nul de conteneurs suggère que la structure de la page ou la réponse est incorrecte. Des conteneurs ne contenant aucun enregistrement accepté indiquent que la validation des champs obligatoires échoue. Il s’agit là d’incidents distincts.

Pour les exécutions Java de scraping Web planifiées, comparez les comptages à une valeur attendue configurée, dérivée de votre propre historique, et non à un benchmark universel. Émettez une alerte en cas de zéros inattendus, de changements brusques ou d’un taux de rejet élevé, puis conservez un petit échantillon à des fins de diagnostic. Veillez à ce que les journaux normaux restent concis : une ligne par échec de requête, une ligne par avertissement d’extraction si nécessaire, et un résumé de l’exécution.

La préparation à la production repose principalement sur la définition de limites. Définissez ce que le crawler est autorisé à demander, la charge de travail qu’il peut effectuer, les données qu’il peut conserver et les conditions dans lesquelles il doit s’arrêter. Ces contrôles sont plus importants que l’ajout d’une bibliothèque supplémentaire à une pile Java de web scraping.

Configurez une liste blanche de schémas, d’hôtes et de préfixes de chemins d’accès. Rejetez les redirections hors site et les liens suivants avant de les planifier. Définissez le nombre maximal de pages, la durée maximale écoulée, la taille maximale de réponse, la concurrence par hôte, le nombre total de tentatives de requête et une limite de sortie. Un budget de requêtes empêche qu’un bug de sélecteur ou un calendrier cyclique ne se transforme en un crawling illimité.

Limitez le débit à l’aide d’un plafond de concurrence et, le cas échéant, d’un intervalle minimum entre les requêtes. Tenez compte des réponses de limitation de débit et réduisez la pression plutôt que de considérer les nouvelles tentatives comme un débit supplémentaire. Récupérez uniquement les ressources nécessaires au jeu de données, mettez en cache les réponses de découverte et évitez de télécharger des images, des scripts ou des feuilles de style lorsque le code HTML brut suffit.

Conservez les informations confidentielles en dehors du contrôle de version. Lisez les identifiants et les clés API à partir de variables d’environnement ou d’un gestionnaire de secrets, validez-les au démarrage et masquez-les dans les journaux. Examinez les en-têtes HTTP pour le web scraping en tant qu’entrées de protocole, et non comme des éléments décoratifs. N’envoyez que les en-têtes dont votre requête a besoin, et utilisez un identifiant d’application valide lorsque la cible en attend un.

Avant la collecte, examinez quatre aspects distincts :

• Législation applicable : les exigences varient selon la juridiction, le type de données, la méthode d’accès et l’utilisation.
• Conditions d’utilisation du site web : les restrictions contractuelles et les utilisations autorisées peuvent différer de l’accessibilité technique.
• Confidentialité : réduisez au minimum les données à caractère personnel, définissez la durée de conservation, sécurisez les données en sortie et documentez la finalité.
• robots.txt : considérez les directives relatives aux robots d’indexation comme un signal opérationnel et consultez le protocole standardisé d’exclusion des robots (Robots Exclusion Protocol).

Aucune de ces vérifications ne se substitue aux autres, et ce tutoriel ne constitue pas un avis juridique. Un cadre dédié à la conformité juridique du web scraping peut faciliter la vérification, mais la formulation finale et le cas d’utilisation concret doivent passer par le processus habituel de conformité ou de révision éditoriale du site.

Avant de programmer le robot d’exploration, vérifiez que :

• que les versions de Java 21, de Jsoup, de Selenium (le cas échéant) et des pilotes de navigateur sont verrouillées et testées ;
  
• Que le code HTML initial, les données réseau et l’approche de récupération choisie correspondent toujours à la page.
  
• Les sélecteurs de produit, de lien suivant et de connexion sont conformes aux critères actuellement autorisés.
  
• Les délais d’expiration de connexion et de requête sont limités.
  
• Les limites de taille de page, de requête, de nombre d’octets, de durée et de sortie sont configurées.
  
• La taille fixe du pool ou les autorisations par sémaphore garantissent le respect de la limite prévue pour les requêtes en cours.
  
• Les statuts de nouvelle tentative, le nombre maximal de tentatives, Retry-Afterle délai de réessai et la gigue se comportent comme prévu.
  
• Les identifiants proviennent d’un stockage de secrets approuvé et ne figurent pas dans les journaux.
  
• Les champs obligatoires, les clés de déduplication, les chemins de sortie et les écritures atomiques sont testés.
  
• Les avertissements de résultat vide ainsi que les totaux des tentatives, des succès, des échecs, des acceptations et des rejets sont visibles.
  
• Les exécuteurs s’arrêtent, les pilotes de navigateur se ferment, les programmes d’écriture se ferment et les tâches interrompues sont nettoyées.
  
• Les conditions générales, la politique de confidentialité, les directives relatives aux robots et l’examen de conformité applicable sont complets.
  

Lancez d’abord un test « canary » délibérément restreint. Inspectez la répartition des statuts, le nombre d’enregistrements, les motifs de rejet, le fichier de sortie et le comportement de nettoyage avant d’augmenter le budget alloué à la page.

• Commencez par la réponse brute. Utilisez HttpClient et Jsoup pour le code HTML du serveur, privilégiez une source JSON autorisée lorsqu’elle expose les enregistrements, et n’ajoutez l’exécution via le navigateur qu’en cas de nécessité.
• Séparez la récupération, l’analyse, l’exploration et la sortie afin que les mêmes sélecteurs résistent aux changements au niveau des tentatives de réessai, des sessions, du rendu ou du fournisseur de requêtes.
• Fixez des limites strictes concernant la pagination, la concurrence, le nombre de tentatives, le temps écoulé et la taille de la sortie. Les threads virtuels nécessitent toujours un sémaphore ou une limite équivalente en cours d’exécution.
• Ne réessayez que les échecs transitoires plausibles, respectez Retry-After, utilisez un backoff limité avec gigue, et conservez les échecs définitifs avec suffisamment de contexte pour les diagnostiquer.
• Considérez la validation des enregistrements, la déduplication, les avertissements de résultats vides et la persistance durable comme faisant partie intégrante de la correction du code Java de scraping Web, et non comme un nettoyage à effectuer après l’extraction.

Ces réponses traitent des limites des outils qui conduisent souvent à une suringénierie. Faites votre choix en fonction de l’emplacement des données, des transitions d’état requises, de la possibilité de répéter une requête en toute sécurité, ainsi que des contraintes imposées par la cible et votre propre environnement d’exécution. Vérifiez à nouveau ces hypothèses chaque fois que la page ou le modèle d’accès change.

Non, Jsoup n’exécute pas de JavaScript. Il analyse le code HTML ou XML que vous lui fournissez et expose des API de traversée du DOM et de sélecteurs CSS. Il ne clique pas sur les contrôles, n’attend pas les mises à jour asynchrones, ne gère pas un DOM de navigateur en temps réel et n’expose pas les variables JavaScript, sauf si celles-ci ont été sérialisées dans le code HTML. Vous pouvez tout de même utiliser Jsoup après le rendu d’une page par un autre composant en lui transmettant le balisage final. Il peut lire le texte d’un élément script, mais il ne peut pas évaluer ce script.

Utilisez Selenium lorsque les données ou l’état requis n’existent qu’après un comportement réel du navigateur, tel que cliquer, faire défiler, remplir un formulaire, gérer un routage côté client ou attendre des mises à jour pilotées par JavaScript. Il est également utile pour déboguer la manière dont une page atteint cet état. Si le code HTML initial ou une requête JSON autorisée contient les données, HttpClient et Jsoup sont plus simples, plus déterministes et plus faciles à utiliser. Un véritable navigateur ajoute un temps de démarrage, une consommation de mémoire, le cycle de vie du pilote et davantage de modes de défaillance.

Définissez une limite explicite de requêtes en cours d’exécution et ajustez-la progressivement à partir d’un niveau de départ bas. Avec un exécuteur fixe, la taille du pool constitue la limite maximale. Avec des threads virtuels, utilisez un sémaphore ou un limiteur de débit, car l’exécuteur peut créer de nombreuses tâches. Appliquez des limites par hôte, limitez les tâches en file d’attente et les tampons de sortie, surveillez la latence et la répartition des états, et réduisez la concurrence en cas d’étranglement ou d’augmentation des défaillances. Prévoyez une limite globale distincte si un même processus interroge plusieurs hôtes.

Réessayer 429, réponses sélectionnées 5xx réponses telles que 500, 502, 503, ainsi que 504, les délais d’expiration des requêtes et les échecs de connexion transitoires lorsque le nombre de tentatives est limité. Respectez Retry-After et, dans le cas contraire, utilisez un recul exponentiel avec gigue. Ne réessayez pas à plusieurs reprises la plupart des 4xx réponses tant que vous n’en avez pas corrigé la cause. Soyez particulièrement vigilant avec les requêtes POST non idempotentes, car leur répétition peut entraîner des actions en double côté serveur, même après un délai d’expiration. Enregistrez le statut final ou l’exception une fois le quota de tentatives épuisé.

Un scraper Java fiable commence par un choix judicieux en matière d’accès aux données. Examinez le code HTML renvoyé et le trafic réseau du navigateur avant de choisir vos outils. Pour les pages statiques, réutilisez un HttpClient, analysez-le avec Jsoup, modélisez des enregistrements typés et veillez à ce que l’analyseur reste indépendant des détails de transport. Étendez ensuite cette même base de code avec une pagination limitée, un suivi des URL visitées, du HTML mis en cache, des limites de concurrence explicites, des tentatives de réessai sélectives, des sessions basées sur des cookies, une validation et une sortie durable.

Les contrôles importants sont visibles et finis : plafonds de pages, délais de requête, autorisations en cours, tentatives de réessai, diagnostics de réponse, champs obligatoires, limites de sortie et arrêt propre. Ces contrôles permettent d’expliquer les échecs. Ils vous permettent également de modifier une couche sans déstabiliser le reste du pipeline Java de scraping Web.

N’utilisez Selenium que lorsque l’interaction avec le navigateur fait partie des exigences, et non pas simplement parce qu’une page utilise JavaScript. Si ce workflow nécessite réellement des clics, du défilement, des formulaires ou un état de rendu sans que vous ayez à gérer vous-même l’infrastructure du navigateur, l’API navigateur de WebScrapingAPI constitue une option hébergée raisonnable à évaluer.

Commencez par une seule page autorisée, enregistrez un modèle de parseur et lancez un petit test « canary ». Une fois que les comptages, les échecs et les résultats semblent corrects, augmentez progressivement le budget de crawl tout en continuant à respecter les contraintes de la cible et votre propre contrôle de conformité.