2025/content/liens-morts/index.md

title, seo

title	seo
Liens morts	noindex true

Il est inévitable, surtout quand on crée beaucoup de liens, de se retrouver confronter à des liens morts. C'est ce que l'on appelle le link-rot.

Par soucis de transparence, pour faciliter le suivi des liens morts et pour inciter mes éventuels lecteurs vers lesquels j'ai créé un lien devenu mort à m'indiquer comment le corriger, je présente ici une page générée automatiquement, contenant le rapport des liens morts détectés sur mon site.

Je m'efforce d'automatiser le processus de détection de ces liens morts, autant pour les liens internes à mon site que pour les liens externes. S'il est parfaitement légitime de me tenir pour responsable de la vivacité de mes propres liens internes, personne ne peut me rendre responsable des liens externes. Ce n'est pas mon travail. Je n'ai aucune obligation de maintenir un outil de vérification et la transparence des résultats. Je le fais par plaisir du travail bien fait et par respect pour mes visiteurs, mais je n'ai aucune emprise sur les nombreux facteurs externes déterminant si un lien est accessible ou non par mon outil.

Méthodologie

Le rapport publié sur cette page est produit par la commande manage links check external. La vérification des liens internes existe aussi, mais elle n'alimente pas cette page.

Extraction des URL

Avant toute requête réseau, l'outil parcourt les fichiers markdown et yaml du dossier content/. Il en extrait les URL externes uniques depuis le frontmatter, le corps des articles et les fichiers de métadonnées. Pour chaque URL, il conserve tous les emplacements précis où elle apparaît. Les liens présents dans du code, dans un texte barré, dans une valeur YAML commentée, ou dans certaines propriétés volontairement ignorées comme aliases, alias et comments_url, ne sont pas pris en compte.

Sélection des URL à contrôler

Certaines URL sont ignorées avant même la phase réseau. C'est le cas des domaines explicitement exclus de la vérification. C'est aussi le cas des URL déjà couvertes par mes fichiers de remplacements ou de suppressions logiques. A l'inverse, certains domaines sont explicitement marqués comme morts. Lorsqu'une URL appartient à cette dernière liste, elle est signalée comme morte sans aucun accès réseau.

Vérification réseau

Les URL restantes sont vérifiées au moyen d'un véritable navigateur headless, piloté par Playwright avec Chromium, et non plus par un simple client HTTP. Le contrôle est parallélisé sur plusieurs threads. En revanche, deux URL relevant d'un même hôte ne sont jamais vérifiées en parallèle. Un délai minimal configurable peut en outre être imposé entre deux accès au même hôte. Chaque URL est ouverte dans un contexte de navigation neuf, sans réutiliser l'état d'une URL à l'autre. Le navigateur se présente avec un user-agent de navigateur de bureau, la locale fr-FR, le fuseau horaire Europe/Paris et un en-tête Accept-Language cohérent. Les erreurs de certificats TLS sont ignorées. Le temps maximal accordé à une navigation est de 30 secondes. Les redirections ordinaires sont suivies comme le ferait un navigateur classique. Le dernier état observé et son historique sont ensuite enregistrés dans un cache local.

Interprétation des résultats

Par défaut, tout code HTTP compris entre 200 et 399 est considéré comme accessible. Une URL qui déclenche immédiatement un téléchargement est elle aussi considérée comme accessible. Les réponses 429 sont traitées comme une limitation temporaire et ne sont pas classées comme des liens morts. Certaines pages de protection anti-bot ou de filtrage applicatif sont reclassées comme "Accès protégé", même lorsqu'elles répondent en 403, et ne sont pas non plus considérées comme mortes. En revanche, un timeout, une erreur navigateur sans code HTTP exploitable, une page Wayback indiquant qu'aucune capture n'existe, ou un domaine explicitement marqué comme mort sont considérés comme des erreurs. Autrement dit, le rapport ne reproduit pas simplement les codes HTTP. Il publie le verdict final du navigateur, enrichi par quelques heuristiques destinées à réduire les faux positifs les plus grossiers.

Cache

Une URL dont le dernier état est un succès 2xx ou 3xx n'est pas revérifiée avant 30 jours. Une erreur 4xx ordinaire est revérifiée au bout d'un jour. Une erreur 5xx est revérifiée au bout de 7 jours. Les timeouts de 30 secondes, les réponses classées en "Accès protégé" et les réponses 429 sont revérifiés à chaque exécution. Les autres erreurs navigateur sans code HTTP exploitable sont revérifiées au bout d'un jour. Tant qu'une entrée de cache reste valide, son dernier verdict est réutilisé tel quel.

Rapport