Test de Browsertrix Crawler : il archive ce que le navigateur a fait, pas ce que le code prétend

Browsertrix Crawler est le crawler d’archivage de Webrecorder : une image Docker qui pilote un véritable Chromium via Puppeteer, enregistre tout ce que le navigateur a récupéré, puis écrit le tout au format WARC — le standard de l’archivage web — avec, en option, un paquet WACZ WACZ contenant un index, une liste de pages et des journaux. Ce qui le distingue des outils de scraping auxquels il ressemble de loin, c’est justement sa finalité. Un scraper va chercher des données puis abandonne la page une fois les champs extraits ; un archiviste conserve la visite elle-même — les octets, les en-têtes, l’ordre d’arrivée — afin que la page puisse être rouverte longtemps après sa modification ou sa disparition. Webrecorder entretient cette couche de l’infrastructure du web, formats et moteur de relecture compris, bien avant que l’archivage ne ressemble à une catégorie de produit, et des bibliothèques, rédactions et chercheurs s’appuient dessus.

J’ai exécuté la version v1.14.0 dans Docker sur un environnement local de test contenant quatre classes d’endpoints volontairement différentes, et j’ai instrumenté les deux côtés du crawl : les enregistrements WARC pour le contenu archivé, et un compteur côté serveur pour les requêtes réellement reçues. La distinction utile ne se limitait pas au statique versus dynamique. Browsertrix a capturé un lien créé à l’exécution et un fetch() déclenché par la page, mais il n’a pas demandé deux URL littérales présentes dans une fonction JavaScript non appelée.

Le fichier app.js lié a bien été archivé intégralement, avec ses deux chemins littéraux, mais aucun de ces endpoints n’a généré d’enregistrement de réponse, d’enregistrement de requête, ni de hit serveur. La fonction qui les contenait n’a jamais été exécutée. Cet article évalue donc Browsertrix comme un archiviste de session navigateur, et non comme un inventaire de toutes les URL mentionnées dans le code source.

Ce qu’est vraiment Browsertrix Crawler

Beaucoup de gens arrivent en pensant à un scraper et repartent déçus. Rien dans le pipeline par défaut ne vous livre un CSV de prix produits, et s’y attendre revient à croire qu’une dashcam va vous rédiger un rapport de circulation. Le résultat est un enregistrement rejouable d’une session de navigation, et toutes les décisions de conception en découlent.

J’ai testé v1.14.0 le 27 juillet 2026 : webrecorder/browsertrix-crawler:latest avec le digest sha256:9d6800a8…, et crawl --version a confirmé la compilation. Le projet est sous AGPL-3.0. Toutes les mesures ont été effectuées via Docker avec Colima sur macOS arm64, sur l’environnement local contrôlé ; le compteur côté serveur fournissait une preuve indépendante des journaux Browsertrix et de l’analyse de l’archive.

AGPL-3.0 mérite qu’on s’y arrête. C’est un copyleft fort avec des obligations liées à l’usage réseau. Si Browsertrix Crawler doit être intégré à un produit commercial plutôt qu’utilisé comme outil autonome, faites lire la licence correctement avant toute mise en production. C’est une alerte, pas un avis juridique.

L’archive enregistre la session, pas le code source

Mon environnement de test exposait quatre types d’endpoints, séparés volontairement, car un archiviste les traite de façon très différente :

• Classe A — <a href> simple dans le HTML. Quatre pages et une chaîne de profondeur sur trois niveaux. N’importe quel crawler les trouve.
• Classe B — URL littérales dans une fonction qui ne s’exécute jamais. Deux chemins, /api/js-endpoint-7 et /api/js-endpoint-8, rangés comme chaînes dans un loadData() non appelé au sein de app.js.
• Classe C — lien construit à l’exécution. Un <a href> assemblé à partir de fragments JavaScript ('endpoint' + (6 * 7)) puis injecté dans le DOM. Le chemin contigu /runtime-only/endpoint42 n’existe dans aucun octet servi.
• Classe D — fetch() réellement émis par la page. Chemin assemblé de la même manière ('runtime-xhr-' + (33 * 3)), puis effectivement demandé au chargement.

Pour les classes C et D, les chemins complets étaient absents en tant que chaînes contiguës des fichiers servis. Les hits côté serveur et les enregistrements de réponse prouvent donc que la construction à l’exécution et les demandes réseau ont bien été exercées dans ce test.

Ce qui a été capturé, et ce qui ne l’a pas été

Deux instruments, vérifiés l’un par rapport à l’autre dans chaque case : les enregistrements de réponse WARC (ce qui figure dans l’archive) et le compteur côté serveur du fixture, indexé sur (Host header, path) (ce qui a réellement été demandé). Ils concordaient partout.

La classe C est celle qui distingue un vrai navigateur d’un crawl statique. L’extraction de liens par défaut lit le DOM rendu (a[href]->href, selon la documentation des options communes), donc un lien qui n’apparaît qu’après exécution du JavaScript est quand même mis en file, récupéré et archivé. La classe D arrive pour une autre raison : la page a elle-même émis la requête, et l’archiviste se trouvait sur le chemin réseau pour enregistrer tout ce qui transitait.

Une précision honnête sur la classe C : mon lien a été injecté synchrone au chargement de la page. Les liens qui apparaissent plus tard, pendant les behaviors de Browsertrix, constituent un autre cas, et il existe un ticket ouvert pour cela — #723, « Links on pages that are discovered during behaviors are not extracted ». Je n’ai pas testé ce scénario, donc je n’affirme rien à son sujet.

Le fichier a été archivé. Les endpoints, non.

Confirmer l’absence de capture pour la classe B a nécessité une vérification record par record dans le WARC, et non un simple total.

app.js est dans l’archive — un enregistrement de réponse, un corps JavaScript de 222 octets — et les deux littéraux de la classe B y apparaissent textuellement. En revanche, ni /api/js-endpoint-7 ni /api/js-endpoint-8 ne sont l’URI cible d’un seul enregistrement dans tout le fichier : zéro enregistrement de réponse, zéro enregistrement de requête. Chaque chaîne littérale n’apparaît qu’une seule fois dans l’ensemble de l’archive, et les deux occurrences se trouvent dans le corps stocké de app.js.

Cela élimine l’explication la plus simple (« app.js n’a jamais été récupéré »). L’archiviste a bien stocké le fichier qui référence ces endpoints, mais n’a jamais émis de requête pour eux, parce que loadData() n’a jamais été appelée. Les behaviors par défaut de Browsertrix étaient actifs — autoplay, autofetch, autoscroll, siteSpecific — et autofetch ne les a pas sauvés non plus, ce qui est logique quand on lit ce que fait autofetch : il va chercher les entrées img srcset, les feuilles de style et les URL data-*, pas les chaînes littérales enfouies dans les corps de fonctions.

Pour une comparaison illustrative sur le même fixture, j’ai aussi exécuté Katana v1.6.1 avec katana -u <seed> -jc -silent -nc -d 4. Son résumé de découverte brut montre le résultat inverse pour les deux classes JavaScript construites exprès :

Les deux commandes utilisaient le même fixture et les mêmes noms d’endpoints. Ce tableau n’est pas un classement général entre navigateur et crawl statique ; il montre pourquoi l’inventaire des endpoints et la préservation de session exigent des tests de couverture différents.

« Vrai navigateur, donc il capture tout ce que fait JavaScript » : on lit souvent cette formule. Elle est trop large. Il capture le trafic réellement exécuté. Un code qui référence une URL sans jamais l’appeler ne produit aucun trafic, et sans trafic, il n’y a aucun enregistrement.

Les corps de réponse sont bien là, avec une chose que je n’ai pas vérifiée

Pour les deux endpoints générés à l’exécution, j’ai extrait les corps de réponse HTTP archivés du WARC et confirmé qu’ils contiennent le JSON servi : 206 octets pour la cible du lien injecté à l’exécution, 201 octets pour la cible du fetch() à l’exécution. Ce ne sont donc pas des stubs d’index pointant vers du vide — le contenu lui-même est dans l’archive, ce qui est la condition préalable à une relecture correcte.

Ce que je n’ai pas fait, en revanche, c’est déployer pywb ou replayweb.page pour rendre l’archive. La présence du corps dans l’archive et la réussite du rendu en relecture sont deux affirmations différentes, et ce test ne couvre que la première. Le comportement de relecture, les contrôles d’authenticité, la chaîne de conservation et l’admissibilité comme preuve nécessitent tous une validation séparée.

Une capture de production demande un test d’acceptation plus large

Le fixture répond clairement à une question étroite : un lien runtime synchrone et une requête émise par la page deviennent-ils du trafic réseau et des enregistrements d’archive ? Un travail de préservation en production peut échouer de plusieurs autres façons tout en produisant un WACZ valide.

Commencez par la relecture. Ouvrez le paquet dans le système de replay qui sera réellement utilisé pour la collection et comparez un ensemble fixe de pages avec la référence prise au moment de la capture. Vérifiez le texte rendu, les images, les styles, la navigation et les interactions qui comptent pour l’archive. Puis inspectez le panneau réseau du navigateur de relecture pour repérer les sous-ressources manquantes. Un corps de réponse peut exister dans le WARC alors que la relecture échoue quand même, parce que la réécriture, les index, le timing, les origines ou les dépendances ne s’alignent pas. Cette revue n’a pas franchi cette limite.

Le comportement dynamique mérite son propre jeu de fixtures. Ici, le lien de classe C est apparu de manière synchrone au chargement. Les applications réelles peuvent révéler du contenu après des temporisations, du scroll, la fermeture d’un consentement, des changements de route, des web components ou de longues chaînes d’API. Placez une cible connue derrière chaque comportement dont vous dépendez et vérifiez à la fois le hit serveur et le corps archivé. Les behaviors par défaut de Browsertrix sont des entrées utiles pour ce test, pas une preuve que chaque état différé a été atteint. Le ticket #723 est particulièrement pertinent si les liens apparaissent pendant les behaviors plutôt qu’au cours de l’exécution initiale de la page.

Les captures authentifiées posent des questions de session. Vérifiez que l’état de connexion entre bien dans le profil navigateur, survit aux navigations requises et ne fuit pas vers des collections qui devraient rester isolées. Testez le renouvellement des jetons et les chemins de déconnexion. Si l’archive contient du contenu privé ou personnel, testez l’accès et la rétention des fichiers obtenus dans le même plan d’acceptation. Une capture techniquement complète peut encore être mal gérée après collecte.

Les service workers, le streaming média, les WebSockets, les téléchargements, les frames cross-origin et les URL signées méritent chacun une page représentative s’ils sont importants pour la cible. Le fixture de onze pages ne dit rien à leur sujet. Il n’établit pas non plus le comportement du crawler lorsqu’une page reste active pendant plusieurs minutes, émet des requêtes après la fenêtre d’attente habituelle ou nécessite des gestes utilisateur. Évitez de transformer « vrai Chromium » en promesse de couverture universelle ; définissez les comportements du navigateur que la collection doit préserver et rendez chacun d’eux observable.

Enfin, conservez les éléments de preuve nécessaires pour diagnostiquer les manques. Sauvegardez le digest exact de l’image et la commande, les journaux Browsertrix, les listes de pages, les index, les sommes de contrôle WARC/WACZ, les preuves des requêtes côté serveur quand elles existent, ainsi qu’un petit manifeste de vérité terrain. Pour des captures répétées, consignez l’heure, la configuration et l’environnement en même temps que l’artefact. Ces traces ne rendent pas une preuve recevable juridiquement, mais elles rendent une affirmation technique reproductible et permettent de voir si une différence ultérieure vient de la cible, du crawler ou de la pile de relecture.

Ce que ce fixture à petits corps a coûté en octets

Ce fixture ne sert que quelques centaines d’octets par page, donc ses ratios de surcharge ne doivent pas être extrapolés à des sites riches en assets. Dans ce cadre étroit, j’ai mesuré la composition de l’archive plutôt que sa seule taille finale :

Les comptes par type et les totaux d’octets figurent dans le fichier public capture-summary.json ; les parts utilisent 17,024 octets de contenu total comme dénominateur.

Dans cette exécution sur petits corps, les enregistrements de requête dépassaient le contenu des réponses, et les octets de requête plus urn:pageinfo: représentaient environ 2,1× le payload de réponse. Cela décrit le mélange d’enregistrements de ce fixture, pas un ratio WARC général.

Sur disque, sur trois exécutions isolées :

En prenant les médianes, on obtient quatre ratios :

Et à l’intérieur du WACZ lui-même :

Cette dernière ligne m’a surpris. Près d’un tiers du paquet d’archive, sur un petit crawl, correspond au journal de crawl plutôt qu’au web.

La mesure était stable : le payload de réponse revenait strictement identique sur les trois exécutions (5,339 B à chaque fois), tandis que WARC.gz et WACZ variaient de moins de 0,4 %.

Ces ratios ne s’appliquent pas à des pages réelles avec images, polices et gros bundles JavaScript. Mais le point structurel reste le même : les enregistrements de requête et de page-info créent une surcharge indépendante de la taille du payload. Mesurez un échantillon représentatif avant de planifier le stockage de production ; ne multipliez pas le ratio de 10× de ce fixture par une estimation de corpus.

Configuration, et espace disque à prévoir

Une fois Docker ou Colima installé et démarré, la configuration spécifique à Browsertrix est docker pull webrecorder/browsertrix-crawler:latest, puis docker run … crawl --url … --generateWACZ. L’image embarque Chromium, donc aucun navigateur séparé ni environnement Python n’était nécessaire.

Ce que cette commodité coûte, sur les exécutions mesurées ici :

Le conteneur est l’endroit où se concentre la friction, et la ligne téléchargement + décompression correspond au coût d’un navigateur embarqué. Je l’ai exécuté avec --shm-size 1g, et comme mon fixture se trouvait sur l’hôte tandis que le crawl tournait dans le conteneur, j’ai eu besoin de --add-host=host.docker.internal:host-gateway et d’un fixture lié à 0.0.0.0 plutôt qu’au loopback. Si vous crawlerez le web public, vous pouvez ignorer cette étape réseau ; mais si vous archivez quelque chose sur votre propre machine ou sur un hôte de staging interne, prévoyez-y un après-midi.

Le répertoire de sortie est la ligne la plus facile à sous-estimer. Extrapolez cette croissance à un vrai crawl et prévoyez le stockage avant de commencer, pas après que votre disque se soit rempli à 3 h du matin.

Le démarrage du navigateur contribue probablement de manière notable à un crawl de 28–30 secondes pour seulement onze pages, mais je n’ai pas isolé le démarrage du temps de navigation ou de packaging. Aucune conclusion de débit par page ne découle de cette exécution.

Planifier le stockage sans abuser des ratios du fixture

La bonne façon de dimensionner une collection est empirique. Sélectionnez des pages qui représentent la distribution réelle de la cible : shells d’application légers, landing pages riches en images, téléchargements de documents, longs articles et vues authentifiées si elles entrent dans le périmètre. Capturez chaque classe avec les behaviors et paramètres de packaging prévus. Mesurez le payload de réponse, le WARC, le WACZ, les index, les journaux, les résidus de profil navigateur et tout espace temporaire restant pendant une exécution. Le pic d’utilisation disque compte autant que la taille finale du paquet si le packaging conserve brièvement plusieurs copies.

Séparez les composants fixes et variables. L’image conteneur de 3.51 GB est une surcharge de déploiement partageable par plusieurs captures sur un même worker. Les enregistrements de requête, les enregistrements de page-info, les index et les listes de pages croissent avec l’activité du crawl. Les corps de réponse dépendent fortement de la cible, tandis que les journaux dépendent de la durée d’exécution et du niveau de verbosité. La rétention et la réplication multiplient ensuite la collection finale indépendamment du comportement du crawl. Un modèle de capacité qui résume tout en « octets par page » sera fragile.

La compression et la déduplication ont aussi besoin de contenu représentatif. Le payload de réponse de ce fixture était identique octet par octet sur trois exécutions, mais cela ne dit rien des pages avec publicités changeantes, horodatages, réponses personnalisées ou URLs d’assets anti-cache. Si des captures répétées font partie du programme, mesurez des captures successives des mêmes pages et inspectez les enregistrements revisit au lieu de supposer que des pages visuellement inchangées se dédupliquent bien. De même, testez si les journaux et index sont conservés au même niveau de réplication que le payload de préservation.

Opérationnellement, fixez des seuils d’alerte avant le début de la collecte. Surveillez l’espace libre, la croissance par collection, les échecs de packaging et la taille des profils navigateur ou des répertoires temporaires. Lancez un exercice de restauration à partir du WACZ stocké, pas seulement un contrôle de somme de vérification. Les ratios ci-dessus sont utiles parce qu’ils révèlent les composants existants ; l’échantillon représentatif indique leur taille réelle pour votre site.

Documentez ces hypothèses à côté de l’estimation de capacité et réexaminez-les après le crawl pilote.

Discipline du périmètre, testée avec deux contrôles

Les crawlers d’archivage qui s’égarent sont un vrai risque opérationnel — vous pouvez vous retrouver avec un problème juridique et une facture de stockage en même temps. Ma page d’accueil pointait vers http://outofscope.test:<port>/page/out, un autre hostname renvoyant vers le même fixture, donc un hit portant cet en-tête Host prouverait une récupération hors périmètre sans impliquer de trafic Internet réel.

La deuxième ligne donne du sens à la première. Avec any, le lien a été atteint deux fois, donc il était atteignable — le zéro sous le scope prefix par défaut traduit une vraie discipline de périmètre, pas un lien que le crawler n’aurait pas remarqué. Il existe un rapport ouvert concernant des visites hors périmètre dans d’autres configurations, #788, que je n’ai pas reproduit sous le scope prefix par défaut sur ce fixture. Bon à savoir ; pas quelque chose que je prétends avoir observé.

La robustesse n’a rien eu d’extraordinaire, dans le bon sens. Une route renvoyant HTTP 500 et un lien mort ont tous deux été demandés, le crawl s’est terminé proprement avec un WARC et un WACZ valides, et le lien mort a été stocké comme enregistrement revisit dédupliqué au lieu de tout faire échouer.

Avantages et inconvénients

Avantages

• Capture les liens DOM injectés à l’exécution et les appels fetch() émis par la page — confirmés à la fois dans l’archive et côté serveur, sur des chemins qui n’existent nulle part sous forme littérale.
• Le HTML statique et la traversée en profondeur sont complets : 4/4 liens, 3/3 dans la chaîne de profondeur, aucun manque.
• Une fois Docker/Colima démarré, un seul docker run produit un WARC et un WACZ ; Chromium est inclus dans l’image.
• Le scope prefix par défaut a tenu, avec zéro récupération hors périmètre ; any a élargi comme documenté, donc le réglage fait bien ce qu’il annonce.
• La sortie est une archive fondée sur des standards (WARC, empaquetée en WACZ avec index CDX et liste de pages) plutôt qu’un blob propriétaire.
• Archives presque déterministes : payload identique octet par octet sur trois exécutions, taille disque variant de moins de 0,4 %.
• Comportement propre en cas d’échec : une route 500 et un lien cassé n’ont pas interrompu le crawl.

Inconvénients

• Les URL littérales dans du JavaScript non exécuté ne sont tout simplement pas découvertes (0/2), même lorsque le fichier qui les contient est archivé. C’est cohérent par conception, mais cela reste une vraie lacune si votre objectif est l’inventaire d’endpoints.
• Empreinte lourde : ~1 GB à télécharger, 3.51 GB sur disque, et des répertoires de sortie qui grossissent vite.
• La surcharge en octets est importante sur les petites pages — les enregistrements request plus pageinfo dépassaient le payload réel, et environ 30 % du WACZ était constitué du journal de crawl.
• AGPL-3.0 implique un vrai travail de conformité pour une intégration commerciale.
• Ce n’est pas un outil de données structurées. Pas de schéma, pas de mapping de champs, pas de lignes propres à la fin.
• Le débit par page est volontairement modeste, puisque chaque page passe dans un vrai navigateur.

Qui devrait l’utiliser, et qui ne devrait pas

Browsertrix vise les équipes dont l’artefact requis est une archive de ressources récupérées par navigateur plutôt qu’un tableau de lignes extraites. Dans ce fixture, les corps de réponse récupérés à l’exécution étaient présents dans le WARC et intégrés dans le WACZ. Bibliothèques, rédactions et chercheurs sont des utilisateurs plausibles, mais une adoption en production devrait tester séparément la relecture rendue, l’authentification, les service workers, les flows de consentement, les comportements différés, les assets en streaming, les contrôles de rétention et toute exigence de traitement probatoire.

Passez votre chemin si ce qu’il vous faut vraiment, ce sont des données. Si l’objectif est « donne-moi tous les produits et prix de ces 400 pages dans un tableur », un archiviste est une voie étrange pour y arriver — vous archiverez des gigaoctets puis devrez encore écrire du code d’extraction sur les fichiers WARC. Évitez-le aussi si vous cartographiez la surface d’API d’une application, car le résultat de la classe B dit clairement qu’un parseur JavaScript statique trouvera des endpoints que Browsertrix ne touche jamais. Et si Docker vous rebute ou si une image de 3,5 GB pose problème dans votre environnement, ce n’est pas l’outil qui va se plier à vos contraintes.

Autorisation et rétention

Les contrôles de périmètre ne remplacent pas une autorisation. Définissez les hôtes autorisés, la rétention et l’accès aux archives avant tout crawl, en particulier lorsque des captures durables peuvent contenir des données personnelles. Le test prefix/any montre qu’un changement de configuration modifie la portée réseau ; il n’établit pas quel périmètre est légal pour une collection donnée.

Lecture connexe : aspect juridique du web scraping et de l’archivage.

Alternatives selon le résultat attendu

Choisissez selon l’artefact. Browsertrix vise la préservation en WARC/WACZ. Une bibliothèque d’automatisation navigateur comme Playwright expose une page programmable, mais vous laisse le packaging de capture à gérer. Les crawlers de découverte d’endpoints inventorient les URL, tandis que les outils d’extraction renvoient du texte ou des enregistrements structurés. Ces catégories peuvent partager un navigateur tout en répondant à des besoins différents.

Lecture connexe : avis sur Heritrix.

Divulgation : Thunderbit est le produit de l’éditeur et n’a pas été testé dans ce fixture Browsertrix. Il appartient à la catégorie de l’extraction managée, en produisant du texte de page ou des données structurées plutôt qu’une archive fondée sur des standards. Cette revue ne valide que la frontière de sortie, pas une comparaison de performance ou de capacités.

Essayez Thunderbit pour l’extraction de données web

Verdict

Utilisez Browsertrix Crawler lorsque la sortie requise est une capture WARC/WACZ et qu’un Chromium conteneurisé convient au déploiement. Sur ce fixture, les enregistrements d’archive et les hits serveur concordaient pour les liens DOM synchrones et les fetch() émis par la page, le scope prefix par défaut excluait le second hôte, et les routes d’échec n’empêchaient pas la création d’une archive valide.

Avant une utilisation en production, validez la relecture, les comportements différés, les sessions authentifiées, les service workers, la composition du stockage sur des pages représentatives et les obligations de licence. La limite testée ici est plus étroite : les références de code qui ne s’exécutent jamais n’ont produit ni requête ni enregistrement d’archive pour leurs cibles, même si le script contenant ces références a bien été conservé.

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

FAQ

Quelle est la différence entre WARC et WACZ ici ? WARC contient les requêtes, réponses et enregistrements associés capturés. WACZ regroupe le WARC avec des index, des listes de pages, des métadonnées et des journaux pour la distribution et les outils de relecture. Cette revue a examiné les deux paquets, mais n’a pas rendu de relecture.

Comment estimer le stockage ? Mesurez des pages représentatives et conservez la composition complète du WACZ, y compris les journaux et les index, dans l’échantillon. Les ratios de cet article proviennent de corps de réponse exceptionnellement petits et ne doivent pas être multipliés par un nombre d’URL de production.

Va-t-il quitter le site ciblé ? Pas avec le réglage par défaut, d’après mes tests. Avec --scopeType prefix, un lien vers un autre hostname n’a été récupéré aucune fois ; en passant à --scopeType any, il a été récupéré deux fois, ce qui prouve que le lien était atteignable et que le zéro du scope par défaut relevait bien d’une discipline de périmètre. Il existe un rapport amont ouvert sur des visites hors périmètre dans d’autres configurations que je n’ai pas reproduit avec le réglage par défaut, donc vérifiez vos propres paramètres de scope au lieu de supposer.

Que dois-je tester avant d’affirmer la fidélité de la relecture ? Chargez le WACZ dans le système de relecture prévu et comparez les pages rendues, les interactions et les sous-ressources requises avec la capture live ou de référence. La présence du corps dans le WARC est nécessaire, mais elle ne vérifie pas à elle seule la relecture rendue.

Browsertrix transforme-t-il une page archivée en lignes structurées ? Non. Sa sortie est un paquet d’archives, pas un tableau de champs sélectionnés. Si le livrable attendu est une liste de produits, prix, contacts ou tout autre schéma, il faut encore une étape d’extraction après la capture — ou un autre outil dont la sortie principale est déjà structurée.