Le web perd la mémoire : combattre la pourriture numérique

En 2014, la climatologue Dr Maria Chen publie un jeu de données révolutionnaire sur la fonte de la banquise arctique. Elle l'héberge sur les serveurs de son université, le cite dans trois articles évalués par des pairs et le partage avec une douzaine de listes de diffusion académiques. En 2019, l'université migre son infrastructure web. L'URL casse. Le jeu de données disparaît. Aucune copie n'existe dans une archive publique. Cinq ans de travail de terrain, réduits à une erreur 404.

L'histoire de Chen n'a rien d'exceptionnel. C'est la norme. Le web perd sa mémoire à un rythme vertigineux, et la plupart d'entre nous ne s'en rendent compte que lorsqu'on a besoin d'un contenu qui n'existe plus.

Le link rot et l'érosion silencieuse de l'histoire du web

Les chercheurs appellent ça le link rot : ce processus lent et implacable par lequel les URL cessent de fonctionner. Une étude du Pew Research Center a montré qu'environ 38 % des pages web de 2013 étaient devenues inaccessibles au bout de dix ans. Ce n'est pas une petite erreur d'arrondi. Cela représente plus d'un tiers des connaissances web enregistrées pour une seule année, simplement disparues.

Les causes sont banales. Des entreprises fusionnent et changent de nom. Des factures d'hébergement restent impayées. Des systèmes de gestion de contenu sont remplacés. Des gouvernements restructurent leurs sites après des élections. L'auteur d'un blog décède, et personne ne renouvelle le nom de domaine. Pris isolément, aucun de ces événements ne semble catastrophique. Mais ils s'accumulent. Année après année, le web se débarrasse de son passé comme de la peau morte.

Et les conséquences ne sont pas abstraites. Des tribunaux ont cité des URL dans des décisions de justice, pour découvrir qu'elles étaient mortes quelques mois plus tard. Des journalistes ont perdu leurs sources. Des communautés en ligne entières (leurs conversations, leurs blagues internes, leurs œuvres créatives, leur savoir collaboratif) ont été effacées en une nuit, parce qu'une plateforme a décidé de changer de cap ou de fermer. Vous vous souvenez de Vine ? de Google+ ? du GeoCities original ? Chaque fermeture a effacé un morceau de patrimoine culturel qui ne pourra jamais être entièrement reconstitué.

Pourquoi l'archivage web devient plus difficile, et non plus facile

On pourrait penser que nous progressons sur ce sujet. Le stockage est bon marché. La bande passante abonde. Nous disposons d'outils d'archivage matures et d'organisations dédiées à la préservation. Alors pourquoi le problème s'aggrave-t-il ?

Deux forces convergent. La première est technique. Le web moderne est bien plus difficile à archiver que les pages HTML statiques des débuts d'Internet. Les applications monopages génèrent leur contenu entièrement en JavaScript. Les sites pilotés par des API n'ont pas d'URL stable à capturer. Les paywalls, les barrières d'authentification et les flux de contenu personnalisés créent des pages qui changent pour chaque visiteur, y compris pour les robots d'archivage.

La seconde est politique. L'explosion des grands modèles de langage a provoqué une levée de boucliers contre le crawling. Les éditeurs et les propriétaires de sites, inquiets que leur contenu serve à entraîner des systèmes d'IA sans autorisation, ont déployé des mesures de blocage agressives. Ils modifient leurs fichiers robots.txt, mettent en place la détection de bots et bloquent des plages d'adresses IP entières associées à la collecte de données.

Voici les dégâts collatéraux : ces mesures de blocage ne font presque jamais la différence entre un crawler d'IA commercial et un crawler d'archivage. La Wayback Machine de l'Internet Archive respecte le robots.txt. Quand un site bloque tous les bots sans distinction, les robots d'archivage sont exclus eux aussi. Le propriétaire veut empêcher l'entraînement des IA. Ce qu'il obtient réellement, c'est qu'aucune trace historique de son contenu ne survivra.

Bloquer les crawlers d'archivage pour empêcher le scraping par les IA revient à brûler une bibliothèque pour empêcher quelqu'un de photocopier un livre. L'intention se comprend. Les dégâts collatéraux pour la mémoire historique sont énormes.

L'Internet Archive : sous pression, mais toujours indispensable

L'Internet Archive est ce qui se rapproche le plus d'une bibliothèque publique pour le web. Sa Wayback Machine a archivé plus de 800 milliards de pages web depuis 1996. Ce chiffre donne le vertige, et il ne représente pourtant qu'une fraction de ce qui a été publié en ligne.

L'organisation a affronté de sérieux vents contraires. Les batailles juridiques autour de son programme de prêt Open Library ont consommé ressources et attention. L'effet dissuasif plus large sur le travail de préservation numérique a été bien réel : d'autres institutions ont suivi ces procès et sont devenues plus prudentes quant à ce qu'elles acceptaient d'archiver.

Mais le plus grand défi est tout simplement l'échelle. Le web croît plus vite que n'importe quelle organisation ne peut le capturer. Et le passage à des applications dynamiques et très riches en JavaScript fait que le crawling traditionnel capture de moins en moins de ce que les utilisateurs voient réellement. Un crawler qui télécharge le HTML brut d'une application React récupère une div vide et un paquet de JavaScript, pas l'article, ni les images, ni les éléments interactifs.

• Les applications rendues côté client nécessitent des navigateurs headless pour capturer des instantanés exploitables
• Le contenu piloté par API n'a souvent pas d'URL stable et explorable
• Les contenus multimédias (vidéos, podcasts, visualisations interactives) exigent des approches de préservation spécifiques
• Le rythme de croissance du contenu web dépasse de loin la capacité de crawling de n'importe quelle organisation
• L'incertitude juridique rend les institutions réticentes à archiver de manière agressive

Ce n'est pas une raison de renoncer aux archives centralisées. C'est une raison de ne plus dépendre uniquement d'elles.

Outils d'archivage web auto-hébergés que tout développeur devrait connaître

La bonne nouvelle : pas besoin d'être une institution pour archiver le web. Un écosystème croissant d'outils open source rend l'infrastructure d'archivage accessible aux particuliers et aux petites équipes. Certains de ces outils sont étonnamment puissants.

ArchiveBox est la référence pour un usage personnel. C'est un outil auto-hébergé qui prend des URL et les sauvegarde dans plusieurs formats : HTML, PDF, capture d'écran, WARC, et d'autres. Donnez-lui vos favoris de navigateur, un flux RSS ou une simple liste d'URL en texte brut, et il construira une archive locale consultable. La mise en place prend quelques minutes :

# Set up ArchiveBox with Docker
docker pull archivebox/archivebox
mkdir -p ~/web-archive && cd ~/web-archive
docker run -v $PWD:/data -it archivebox/archivebox init --setup
# Archive some URLs
docker run -v $PWD:/data -it archivebox/archivebox add \
'https://example.com/important-report' \
'https://example.org/research-dataset'
# Launch the web UI to browse your archive
docker run -v $PWD:/data -p 8000:8000 archivebox/archivebox server 0.0.0.0:8000

Pour capturer les sites très riches en JavaScript, Webrecorder adopte une approche différente. Au lieu de crawler, il enregistre votre session de navigation réelle : chaque requête réseau, chaque élément chargé dynamiquement, chaque interaction. Le résultat est une capture haute fidélité, stockée au format WARC ou WACZ, qui peut être rejouée dans le navigateur avec ReplayWeb.page. C'est la différence entre photographier un bâtiment et réaliser une visite 3D complète.

Browsertrix, issu lui aussi du projet Webrecorder, pousse cette approche à plus grande échelle. C'est un système de crawling cloud-native qui utilise de vraies instances de navigateur pour rendre et capturer les pages. Universités, bibliothèques et administrations publiques s'en servent pour mener des programmes d'archivage institutionnels. Si vous devez archiver des milliers de pages avec un rendu JavaScript complet, c'est l'outil qu'il vous faut.

Intégrer la préservation dans votre workflow de développement

Inutile de faire tourner un système d'archivage complet pour faire la différence. De petites décisions dans la façon de construire et de déployer vos sites ont un impact considérable sur la possibilité de préserver leur contenu. Voici ce qui compte vraiment.

D'abord, concevez pour l'archivabilité. Utilisez des URL stables et lisibles. Ne liez pas la structure de vos URL à des identifiants de base de données ou à des jetons de session. Assurez-vous que le contenu essentiel est présent dans la réponse HTML initiale, et non chargé entièrement en JavaScript côté client après le chargement de la page. Si vous développez une application monopage, prévoyez un rendu côté serveur ou une génération statique en solution de repli. Ce ne sont pas seulement de bonnes pratiques pour l'archivage. Ce sont aussi de bonnes pratiques pour le SEO, l'accessibilité et les performances.

Ensuite, soyez chirurgical avec votre robots.txt. Si vous voulez bloquer les crawlers d'entraînement d'IA, bloquez-les nommément. Ne jetez pas une couverture sur tous les bots qui passent sur votre site.

# robots.txt — block AI crawlers, welcome archival bots
# Explicitly allow archival crawlers
User-agent: ia_archiver
Allow: /
User-agent: archive.org_bot
Allow: /
# Block specific AI training crawlers
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: anthropic-ai
Disallow: /
User-agent: ClaudeBot
Disallow: /
# Default: allow everything else
User-agent: *
Allow: /

Ce n'est pas un système parfait (les user agents peuvent être falsifiés), mais c'est un effort de bonne foi qui laisse la porte ouverte à la préservation légitime tout en la fermant à l'entraînement non désiré.

Troisièmement, automatisez vos soumissions d'archivage. Chaque fois que vous publiez quelque chose, envoyez-le à la Wayback Machine. Cela ne demande que quelques lignes de code et peut être intégré à n'importe quel pipeline CI/CD ou hook post-publication :

import requests
import time
def archive_url(url: str, retries: int = 3) -> str:
"""Submit a URL to the Wayback Machine's Save Page Now endpoint."""
save_url = f"https://web.archive.org/save/{url}"
for attempt in range(retries):
try:
resp = requests.get(save_url, timeout=30)
if resp.status_code == 200:
location = resp.headers.get("Content-Location", resp.url)
return f"Archived: https://web.archive.org{location}"
except requests.RequestException:
if attempt < retries - 1:
time.sleep(2 ** attempt)
return f"Failed to archive {url} after {retries} attempts"
# Wire this into your publish script
new_post = "https://yourblog.com/posts/new-article"
print(archive_url(new_post))

La logique de nouvelle tentative compte. L'endpoint de sauvegarde de la Wayback Machine est très sollicité, et les échecs transitoires sont fréquents. Un peu de résilience fait une grande différence.

Comprendre WARC : le format de fichier derrière les archives web

Si vous voulez travailler avec des archives web, vous devez comprendre WARC. C'est le format de fichier normalisé ISO utilisé par l'Internet Archive, Webrecorder et la plupart des outils d'archivage sérieux. Imaginez un fichier WARC comme un enregistrement complet de chaque requête et réponse HTTP impliquée dans le chargement d'une page : le HTML, les feuilles de style, les scripts, les images, les appels API. Absolument tout.

C'est cette exhaustivité qui rend la relecture possible. Un fichier WARC ne stocke pas seulement le HTML brut : il conserve tout le contexte nécessaire pour reconstruire la page telle qu'elle apparaissait au moment de la capture. Voici comment en lire un par programmation :

from warcio.archiveiterator import ArchiveIterator
def inspect_warc(filepath: str):
"""List all HTTP responses captured in a WARC file."""
with open(filepath, "rb") as stream:
for record in ArchiveIterator(stream):
if record.rec_type == "response":
url = record.rec_headers.get_header("WARC-Target-URI")
status = record.http_headers.get_statuscode()
content_type = record.http_headers.get_header("Content-Type")
print(f"[{status}] {url} ({content_type})")
inspect_warc("my-archive.warc.gz")

Le format WACZ, plus récent, s'appuie sur WARC en ajoutant une couche d'index et de métadonnées dans un conteneur ZIP. L'avantage pratique est énorme : les fichiers WACZ s'ouvrent directement dans un navigateur avec ReplayWeb.page, sans aucune infrastructure serveur. Vous pouvez envoyer un fichier WACZ par e-mail et votre interlocuteur peut immédiatement parcourir le site archivé. C'est ce type d'accès sans friction qui rend la préservation réellement utile, et pas seulement techniquement possible.

Archivage communautaire et filet de sécurité des bénévoles

Une partie des efforts de préservation les plus spectaculaires se déroule en mode crise. Quand une plateforme annonce sa fermeture, un groupe de bénévoles appelé ArchiveTeam se mobilise. Ils ont sauvé des contenus de GeoCities, Vine, Google+ et de dizaines de services plus petits. Leur méthode est simple : bombarder la plateforme mourante de requêtes d'archivage avant que les serveurs ne s'éteignent, stocker tout au format WARC, puis le téléverser à l'Internet Archive pour un accès public.

Tout le monde peut contribuer. Le Warrior d'ArchiveTeam est une appliance virtuelle que vous faites tourner sur votre propre matériel. Elle se connecte à leurs serveurs de coordination, récupère des tâches d'archivage et met votre bande passante et votre puissance de calcul au service de l'opération de sauvetage en cours. C'est de l'archivage distribué dans sa forme la plus populaire.

Mais les sauvetages d'urgence restent un dernier recours. L'objectif réel est de rendre la préservation routinière. Des communautés thématiques s'impliquent de plus en plus : des projets open source qui archivent leurs listes de diffusion et leurs gestionnaires de tickets, des acteurs du patrimoine culturel qui préservent les ressources en langues autochtones, des rédactions qui conservent les archives de leurs enquêtes. Les outils existent. La partie la plus difficile consiste à maintenir, année après année, la coordination humaine et le financement nécessaires.

Une boîte à outils pratique pour la préservation numérique

Si vous avez lu jusqu'ici et voulez passer à l'action, voici votre kit de démarrage. Ce sont les outils les plus matures et les mieux entretenus pour l'archivage web, à toutes les échelles.

• ArchiveBox : archivage personnel auto-hébergé. Sauvegarde les pages en HTML, PDF, WARC et captures d'écran. Idéal pour préserver vos propres recherches et références.
• Browsertrix : crawling depuis un navigateur à l'échelle institutionnelle. Utilise de vraies instances de navigateur pour un rendu JavaScript complet.
• Webrecorder : enregistre votre session de navigation pour une capture interactive haute fidélité. Produit des fichiers WARC/WACZ.
• ReplayWeb.page : rejoue les fichiers WARC/WACZ directement dans le navigateur. Aucun serveur nécessaire.
• SingleFile : extension de navigateur qui enregistre une page web complète dans un seul fichier HTML autonome. Ultra simple.
• warcio : bibliothèque Python pour lire, écrire et traiter les fichiers WARC par programmation.
• Heritrix : le crawler open source de l'Internet Archive. De qualité industrielle, courbe d'apprentissage abrupte.
• ArchiveTeam Warrior : appliance virtuelle pour rejoindre les projets d'archivage distribués et bénévoles.
• API de la Wayback Machine : accès programmatique pour soumettre et récupérer des pages archivées.
• Conifer : service d'archivage web géré pour les particuliers et les petites équipes qui ne veulent pas héberger eux-mêmes.

Le web ne se préservera pas tout seul

Il existe un mythe tenace selon lequel Internet n'oublie jamais. C'est faux. Il oublie en permanence. Le web ressemble davantage à une rivière qu'à une bibliothèque : le contenu y circule, et à moins que quelqu'un ne capture délibérément un instantané, il disparaît dès que la source s'assèche.

Les développeurs disposent ici d'un levier inhabituel. Nous écrivons les fichiers robots.txt. Nous concevons les schémas d'URL. Nous choisissons entre rendu serveur et rendu client. Nous construisons les pipelines de déploiement qui pourraient, avec quelques lignes de code supplémentaires, soumettre chaque nouvelle page à une archive publique. Ce ne sont pas des actes héroïques. Ce sont de petites décisions techniques qui déterminent si l'histoire du web survivra.

Le jeu de données du Dr Chen est toujours perdu. Aucune archive ne l'a capturé avant que l'URL ne casse. Mais chaque jour, quelqu'un publie quelque chose qui compte : une enquête journalistique, un jeu de données scientifique, un fil de discussion communautaire qui sera cité pendant des années. La question n'est pas de savoir si ce contenu finira par disparaître. Il disparaîtra. La question est de savoir si quelqu'un en aura sauvegardé une copie à temps.