Outils de capture de sites web : un guide complet

Notre position est claire : nous sommes Geonode et nous vendons des proxys, qui ne sont pratiquement jamais nécessaires dans ce cas précis. La mise en miroir d’un site pour lequel vous disposez d’une autorisation est une tâche à source unique et à volume modéré qui fonctionne parfaitement via votre propre connexion. Si vous envisagez d’utiliser des proxys pour cela, cela signifie généralement que vous effectuez une mise en miroir à un débit que le site désapprouve, et la solution appropriée consiste à ralentir le débit plutôt qu’à répartir la charge. Il existe une véritable exception — la mise en miroir de contenu spécifique à une région — qui est mentionnée ci-dessous. Tout le reste de cet article fonctionne à partir d’un ordinateur portable, sans aucune infrastructure.

Ce que font réellement ces outils

Quatre étapes, pour chaque outil de cette catégorie.

Récupérer une page. Télécharger le code HTML. Identifier les ressources. Analyser le code pour repérer les images, les feuilles de style, les scripts et les polices, puis les suivre également. Suivre les liens. Découvrir d’autres pages dans le périmètre que vous avez défini. Réécrire les références. Remplacer les URL absolues par des chemins relatifs afin que la copie fonctionne à partir de votre système de fichiers.

C'est cette quatrième étape qui distingue un « ripper » d'un « crawler ». Un crawler collecte des données ; un ripper produit une copie locale navigable, et la réécriture des liens fait toute la différence.

Les utilisations légitimes sont banales : archiver un site avant sa mise hors ligne, emporter de la documentation hors ligne pour un déplacement ou un réseau restreint, migrer d’une plateforme à une autre, conserver une trace de conformité et préserver son propre travail lorsqu’un hébergeur cesse ses activités.

wget : la solution par défaut

Déjà présent sur la plupart des systèmes Unix, il convient à une grande partie des tâches.

wget --mirror --convert-links --adjust-extension --page-requisites \
     --no-parent --wait=1 --random-wait \
     https://example.com/docs/

Chaque option a sa raison d’être, et le manuel de wget les décrit avec précision.

**--mirror

** « active les options adaptées à la création de miroirs. Cette option active la récursivité et l'horodatage, définit une profondeur de récursivité infinie et conserve les listes de répertoires FTP. Elle équivaut actuellement à -r -N -l inf --no-remove-listing

. »

**--page-requisites

** « oblige Wget à télécharger tous les fichiers nécessaires à l’affichage correct d’une page HTML donnée. Cela inclut notamment les images intégrées, les sons et les feuilles de style référencées ». Sans cette option, vous obtenez du code HTML sans mise en forme et sans images.

**--convert-links

** réécrit les références « une fois le téléchargement terminé… afin de les rendre compatibles avec un affichage local », ce qui affecte « non seulement les liens hypertextes visibles, mais également toute partie du document renvoyant vers du contenu externe ».

**--adjust-extension

** ajoute l’extension .html

aux pages servies au format HTML sans extension HTML — le manuel donne l’exemple suivant : « vous souhaitez créer un miroir d’un site distant qui utilise des pages .asp, mais vous voulez que les pages du miroir soient consultables sur votre serveur Apache standard ».

**--no-parent

** garantit « que seuls les fichiers situés en dessous d’une certaine hiérarchie seront téléchargés », ce qui limite la tâche à /docs/

plutôt qu’à l’ensemble du site.

**--wait=1

** est l’option de courtoisie, et le manuel la recommande explicitement : « L’utilisation de cette option est recommandée, car elle allège la charge du serveur en réduisant la fréquence des requêtes.» Associez-la à --random-wait

, qui, comme le note le manuel, a été « inspirée par cette recommandation peu judicieuse visant à bloquer l’accès à un site web à de nombreux utilisateurs sans rapport avec le problème, en raison des actions d’un seul ».

Deux autres options méritent d’être connues. -Q

définit un quota de téléchargement afin qu’un miroir illimité ne remplisse pas votre disque. Et -l

définit une profondeur de récursion si la valeur « infinite » s’avère trop généreuse.

Les limites de wget sont bien réelles : il n’exécute pas de JavaScript, sa réécriture de liens est bonne mais pas parfaite sur les sites complexes, et il ne dispose pas d’interface graphique. Pour un site de documentation ou un blog statique, rien de tout cela n’a d’importance.

HTTrack : le grand classique graphique

HTTrack est l'outil dédié le plus connu de sa catégorie : open source, multiplateforme, il dispose à la fois d'une interface graphique et d'une ligne de commande. Le projet est toujours actif.

Ses atouts par rapport à wget : une véritable interface pour ceux qui ne passent pas leur temps dans un terminal, une meilleure gestion des structures de liens complexes, la reprise des projets en cours et un mode de mise à jour qui ne réplique que les éléments modifiés.

Ses points faibles : la même limitation fondamentale (pas d’exécution de JavaScript), une syntaxe de filtrage qui demande un certain apprentissage, et une réputation auprès des opérateurs de sites qui pousse certains à le bloquer par agent utilisateur.

Pour un utilisateur non technicien qui a besoin d’une copie navigable d’un site statique, c’est l’outil recommandé. Pour toute personne à l’aise avec un shell, wget fait le même travail avec moins de surprises.

Outils pour pages uniques

Une approche différente du problème, et souvent la bonne.

Si vous souhaitez obtenir une page complète plutôt qu’un site entier, les outils qui intègrent tout dans un seul fichier HTML autonome sont plus utiles qu’un site miroir. Ils intègrent les images sous forme d’URI de données, intègrent le CSS et produisent un fichier unique que vous pouvez envoyer par e-mail, archiver ou ouvrir n’importe où sans aucune dépendance.

Les extensions de navigateur de cette catégorie constituent la solution la plus pratique pour la plupart des utilisateurs, et elles présentent un avantage décisif par rapport à tous les outils en ligne de commande présentés ici : elles capturent la page telle qu’elle s’affiche, une fois que le JavaScript s’est exécuté. Pour une application moderne, cela fait toute la différence entre une copie fonctionnelle et une coquille vide.

Le compromis, c’est qu’elles sont manuelles : une page à la fois, avec un clic de l’utilisateur. Pour quelques pages, cela convient ; pour un millier, ce n’est plus le cas.

ArchiveBox et les outils de conservation

ArchiveBox est la solution de choix lorsque l’objectif est la conservation plutôt que la consultation hors ligne. Il prend en charge les URL et génère simultanément plusieurs formats d’archivage : HTML, capture d’écran, PDF, texte extrait et fichier WARC.

Le format WARC mérite d’être connu, car c’est celui utilisé par les archives Web. Il stocke les transactions HTTP elles-mêmes plutôt qu’une approximation du système de fichiers, ce qui signifie que les en-têtes, les codes d’état et les octets exacts sont préservés. Pour tout ce qui exige une grande fidélité — domaine juridique, conformité, recherche —, il s’agit d’un enregistrement nettement meilleur qu’un répertoire de code HTML réécrit.

ArchiveBox s’auto-héberge, gère un index et prend en charge le JavaScript grâce à un navigateur sans interface graphique. Il est plus lourd que wget, mais produit un résultat plus durable.

Pourquoi ils ont tous du mal avec les sites modernes

L’explication unique derrière la plupart des déceptions dans cette catégorie.

Le rendu JavaScript. wget et HTTrack récupèrent le code HTML et l’analysent. Une application monopage renvoie un document presque vide accompagné d’un ensemble de scripts, et le contenu est assemblé dans le navigateur. Ce que vous dupliquez, c’est la coque.

Contenu piloté par API. Même lorsque le code HTML initial contient du contenu, la navigation ultérieure peut récupérer du JSON depuis une API. Ces requêtes sont effectuées par du code, et non par des liens dans le balisage ; par conséquent, un miroir qui suit les liens ne les détecte jamais.

Défilement infini et chargement différé. Le contenu qui s’affiche à la suite d’une interaction ne figure pas du tout dans le balisage.

Routage côté client. Des URL qui n’atteignent jamais le serveur. Un miroir ne peut pas récupérer ce qui n’a jamais été demandé.

Authentification et personnalisation. Tout ce qui se trouve derrière une connexion, et tout ce qui diffère d’un utilisateur à l’autre.

Les solutions de contournement, par ordre de difficulté :

Vérifier s’il existe une exportation statique. Les sites de documentation proposent souvent un PDF ou un ensemble de fichiers téléchargeables. Renseignez-vous avant de vous lancer.

Vérifier s’il existe une API. Si le contenu provient d’une API, le récupérer directement est plus simple et plus complet que de créer un miroir de l’interface utilisateur.

Utiliser un outil basé sur un navigateur pour les pages qui nécessitent réellement un rendu. Playwright permet de naviguer, d’attendre le chargement du contenu et d’enregistrer le code HTML rendu, ce qui constitue une copie miroir prenant en charge JavaScript, au prix de l’écriture d’un script et d’une consommation de bande passante considérablement plus importante.

Se contenter d’une copie miroir partielle. Dans de nombreux cas, les parties statiques d’un site correspondent de toute façon à ce que vous recherchiez.

Réaliser une copie miroir d’un site JavaScript avec Playwright

La solution pratique à privilégier lorsque les outils classiques ne fournissent qu’une coquille vide. Il ne s’agit pas d’un outil de capture polyvalent, mais cela suffit pour capturer un ensemble défini de pages telles qu’elles sont affichées.

import { chromium } from 'playwright';
import { writeFile, mkdir } from 'fs/promises';
import { dirname } from 'path';

const urls = [/* the pages you want */];

const browser = await chromium.launch();
const ctx = await browser.newContext();
const page = await ctx.newPage();

for (const url of urls) {
  await page.goto(url, { waitUntil: 'domcontentloaded' });
  await page.waitForSelector('main', { timeout: 15000 }).catch(() => {});

  const html = await page.content();          // rendered DOM, not source
  const path = 'mirror' + new URL(url).pathname.replace(/\/$/, '/index') + '.html';
  await mkdir(dirname(path), { recursive: true });
  await writeFile(path, html);

  await page.waitForTimeout(1000 + Math.random() * 1000);
}

await browser.close();

Quatre éléments sont importants ici.

**page.content()

renvoie le DOM tel qu’il est affiché**, et non le code HTML source. C’est précisément la raison pour laquelle cette approche fonctionne là où wget échoue : vous obtenez le balisage tel qu’il existe après avoir été construit par JavaScript.

Attendre un sélecteur, et non l’inactivité du réseau. Les pages comportant des balises d’analyse ou des WebSockets ne sont jamais inactives ; ainsi, la commande « waitUntil: 'networkidle'

» aboutira simplement à un délai d’expiration sur de nombreux sites modernes. Attendre un élément dont on sait qu’il doit être présent est à la fois plus rapide et plus fiable.

La pause délibérée entre les pages. Même principe que « --wait

» dans wget, et tout aussi nécessaire.

Pas de réécriture des liens. C’est la véritable limite : vous obtenez du code HTML rendu avec des références absolues ; le contenu doit donc disposer d’une connexion Internet pour s’afficher correctement. Ajouter une réécriture implique d’analyser chaque document, de télécharger chaque ressource et de réécrire les références — ce qui revient à réimplémenter wget, et à ce stade, il est plus simple de combiner les deux : utilisez Playwright pour afficher et enregistrer, puis lancez wget sur les fichiers enregistrés pour récupérer les ressources.

Et prévoyez le coût de la bande passante. Un navigateur récupère toutes les images, polices, scripts et vidéos en préchargement ; cela consomme donc environ un ordre de grandeur de trafic en plus qu’un miroir wget des mêmes pages. Bloquer les requêtes de polices et de médias avec page.route()

permet de réduire considérablement ce trafic lorsque ces éléments ne font pas partie de ce que vous souhaitez conserver.

Choisir un outil

Cette dernière ligne mérite d’être soulignée à part, car c’est souvent le cas où les gens choisissent la solution la plus compliquée. Si vous êtes propriétaire du site, utilisez la fonction d’exportation de la plateforme. Un dump de base de données, une compilation de site statique ou une sauvegarde effectuée par l’hébergeur est complète, inclut ce que la mise en miroir ne peut pas voir et ne prend que quelques minutes. Mettre en miroir votre propre site revient à choisir la version compliquée d’une tâche simple.

Les règles qui s'appliquent dans tous les cas

Quel que soit l'outil utilisé.

** Le fichier «robots.txt » s'applique à vous.** wget le respecte par défaut. HTTrack le respecte par défaut. Il est possible de configurer ces deux outils pour qu'ils ne le respectent pas, mais il s'agit alors d'un choix délibéré qui a des conséquences. Il s’agit désormais d’une norme — RFC 9309 — et nous avons abordé sa lecture dans comment lire un fichier robots.txt.

La limitation du débit n’est pas facultative. Un miroir sans --wait envoie des requêtes aussi vite que la connexion le permet, ce qui est impossible à distinguer d’une attaque du point de vue du serveur. Une requête par seconde constitue un seuil minimum raisonnable.

Les droits d’auteur ne disparaissent pas. Télécharger une copie pour une lecture hors ligne personnelle est une chose ; la republier en est une autre. Le contenu reste la propriété de son détenteur.

Les conditions d’utilisation peuvent l’interdire purement et simplement, quelle que soit la faisabilité technique.

La bande passante coûte de l’argent au site. Un miroir d’un site volumineux peut transférer plusieurs gigaoctets, et quelqu’un doit payer pour cela.

Demandez. Pour toute demande importante, un e-mail est plus rapide qu’une solution de contournement. Les propriétaires de sites acceptent souvent, et proposent parfois une offre groupée qui vous évite complètement cette démarche.

À quoi servent les proxys, en bref

Comme il s’agit de notre produit, la réponse honnête est courte.

Vous n’en avez pas besoin pour mettre en miroir un site que vous êtes autorisé à reproduire à un rythme raisonnable depuis un seul emplacement. Cela représente la grande majorité des utilisations légitimes, et une seule connexion suffit.

Vous pourriez en avoir besoin si le site propose un contenu différent selon les régions et que vous souhaitez accéder aux versions régionales — par exemple, un site de documentation avec des pages localisées, ou un catalogue présentant un stock spécifique à chaque pays. Dans ce cas, la géographie est le facteur déterminant, et il s’agit d’un cas d’utilisation légitime.

Vous n’en avez pas besoin pour aller plus vite, et y recourir pour cette raison signifie que vous effectuez une mise en miroir à un débit que le site jugerait inacceptable. La réponse appropriée à cela est l’--waite, et non la distribution.

Si le cas régional s’applique, la bande passante du centre de données est le choix judicieux — la nôtre commence à 0,14 $/Go, selon notre page de tarifs en septembre 2026 — et sachez qu’une copie miroir complète se mesure en gigaoctets, donc le calcul est important.

Questions fréquentes

Qu'est-ce qu'un « website ripper » ?

Il s'agit d'un outil qui télécharge les pages et les ressources d'un site web vers un espace de stockage local et réécrit les liens afin que la copie fonctionne hors ligne. C'est cette réécriture des liens qui le distingue d'un « crawler », qui collecte des données plutôt que de créer un miroir navigable.

Comment télécharger un site web dans son intégralité ?

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent --wait=1 URL prend en charge la plupart des sites statiques. Pour une alternative graphique, HTTrack remplit la même fonction. Pour un site utilisant beaucoup de JavaScript, aucun de ces deux outils ne fonctionnera correctement et vous devrez opter pour une approche basée sur un navigateur.

Pourquoi mon site web téléchargé semble-t-il défectueux ?

Généralement, c’est dû à l’absence de la balise --page-requisites, ce qui empêche le téléchargement des feuilles de style et des images, ou à l’absence de la balise --convert-links, ce qui fait que les références pointent toujours vers le site en ligne. Si les pages sont vides plutôt que dépourvues de style, cela signifie que le site affiche son contenu via JavaScript et qu’un outil de capture non-rendu ne peut pas le récupérer.

Le téléchargement d’un site web est-il légal ?

Le téléchargement à des fins personnelles hors ligne est généralement sans conséquence ; la republication est une autre histoire, car le droit d’auteur s’applique toujours. Les conditions d’utilisation peuvent interdire purement et simplement le téléchargement automatisé, quels que soient les moyens techniques utilisés. Cela varie selon les juridictions et ne constitue pas un avis juridique.

Puis-je télécharger un site web qui utilise JavaScript ?

Pas avec wget ou HTTrack, qui récupèrent et analysent le code HTML sans exécuter de scripts. Vous devez utiliser une approche basée sur un navigateur : une extension de fichier unique pour chaque page, ou un script Playwright qui navigue sur le site, attend le chargement du contenu et enregistre le résultat affiché.

Quel est le meilleur outil gratuit pour télécharger un site web ?

wget si vous êtes à l’aise avec la ligne de commande, car il est déjà installé et parfaitement adapté aux sites statiques. HTTrack si vous préférez une interface graphique. ArchiveBox si l’objectif est la conservation plutôt que la navigation, car il génère des fichiers WARC en plus du HTML.

Comment télécharger un site web sans se faire bloquer ?

Prévoyez un délai d’au moins une seconde entre les requêtes, respectez les règles d’robots.txt (Cache-Validation), identifiez-vous honnêtement et limitez la portée à l’aide de --no-parent et d’une limite de profondeur. La plupart des blocages de ce type proviennent d’une mise en miroir à pleine vitesse, ce qui, du point de vue du serveur, ressemble à une attaque.

Dois-je utiliser un proxy pour télécharger un site web ?

Uniquement si vous avez besoin de versions régionales spécifiques du contenu. Pour une copie miroir ordinaire à un débit raisonnable, une seule connexion suffit. Recourir à des proxys pour aller plus vite signifie que vous transférez à un débit que le site n’approuve pas, et la solution à cela est d’activer un délai.

Conclusion

Pour un site statique, le problème est résolu et l’outil est déjà installé sur votre machine. Une seule commande wget avec cinq options permet d’obtenir une copie locale consultable, et la seule option que les gens oublient souvent est celle qui rend le processus plus « courtois ».

Pour une application moderne, aucun des outils classiques ne fonctionne, et la raison n’est pas une lacune que l’on peut contourner par la configuration. Ils récupèrent et analysent le code HTML ; le contenu est assemblé par JavaScript après la récupération. Les options réalistes sont une capture via un navigateur pour les pages importantes, une API si elle existe, ou une exportation si vous êtes propriétaire du site — et cette dernière solution est souvent la plus difficile à mettre en œuvre.

Quel que soit l’outil utilisé, trois principes s’appliquent indépendamment de celui-ci. Limitez le débit, car une copie miroir à pleine vitesse est impossible à distinguer d’une attaque. Respectez la norme «robots.txt », car il s’agit d’une norme et l’ignorer est un choix. Et pour toute demande importante, demandez : un e-mail ne prend qu’une minute et permet bien souvent d’obtenir un ensemble de données qui rend toute cette démarche inutile.