Vérificateur de liens cassés
Collez une liste d'URLs, une par ligne, et lancez la vérification. Chaque lien reçoit un statut réel ou l'indication honnête qu'il n'est pas vérifiable depuis le navigateur.
Comment fonctionne cet outil ?
Pour chaque URL de votre liste, l'outil envoie une requête HTTP de type HEAD directement depuis votre navigateur, avec au maximum 5 requêtes en parallèle pour ne pas surcharger les serveurs testés et rester raisonnable pour votre connexion. Aucune URL n'est jamais transmise à un serveur Toolyz : tout le trafic part de votre propre navigateur vers les sites que vous vérifiez, exactement comme si vous cliquiez sur chaque lien vous-même.
Trois résultats sont possibles. Un badge OK signifie que le site a répondu avec un code de succès (200 à 299). Un badge Erreur HTTP signifie que le site a répondu, mais avec un code d'erreur explicite (404, 500, 403...). Un badge Non vérifiable depuis le navigateur (CORS) signifie que le navigateur a bloqué la lecture de la réponse avant même d'obtenir un code — c'est le cas le plus fréquent, détaillé dans la FAQ ci-dessous.
Pourquoi la vérification de liens depuis un navigateur a des limites
Un vérificateur de liens qui tourne entièrement dans le navigateur, sans aucun serveur intermédiaire, se heurte nécessairement à la politique de sécurité CORS des navigateurs modernes. Cette politique empêche un script JavaScript de lire la réponse d'une requête envoyée vers un autre domaine, sauf si ce domaine l'autorise explicitement. C'est un mécanisme de protection essentiel du web, pas une faille : sans lui, n'importe quel site visité pourrait sonder silencieusement votre intranet ou vos services internes. Le résultat concret pour cet outil est que beaucoup de liens externes, en particulier vers des sites qui n'ont pas activé les en-têtes CORS pour ce type d'usage, ressortiront comme « non vérifiables ». Ce n'est pas une erreur de l'outil : utilisez le bouton « Ouvrir » pour vérifier visuellement ces liens au cas par cas, ou considérez un statut « non vérifiable » comme un signal à contrôler manuellement plutôt qu'une confirmation d'échec.
C'est la limitation centrale de cet outil, et la raison d'être de cette FAQ. Par sécurité, les navigateurs appliquent la politique CORS (Cross-Origin Resource Sharing) : un script JavaScript exécuté sur toolyz.app ne peut lire la réponse d'un autre site que si ce site autorise explicitement les requêtes cross-origin via des en-têtes HTTP dédiés. La grande majorité des sites web n'activent pas ces en-têtes pour de simples requêtes de vérification, car ce n'est pas leur usage prévu. Résultat : le navigateur bloque la lecture de la réponse avant même que le code de statut (200, 404, 500...) ne soit accessible au script, et l'outil ne peut que constater l'échec sans savoir si le lien est réellement cassé ou parfaitement valide.
Oui, totalement. Selon les sites que vous testez, il n'est pas rare que la majorité, voire la quasi-totalité des URLs externes ressortent en « non vérifiable ». Ce n'est pas un bug de l'outil : c'est le comportement attendu du CORS tel que défini par les standards web. Seuls les sites qui autorisent explicitement les requêtes cross-origin (souvent des API publiques ou des CDN) donneront un statut « OK » ou « Erreur HTTP » exploitable.
Techniquement, un serveur intermédiaire (souvent appelé proxy) qui relaierait les requêtes pourrait contourner le CORS, puisque la restriction s'applique au navigateur, pas à un serveur. Mais Toolyz est un site 100 % côté client, sans aucun backend : c'est un choix produit assumé, qui garantit qu'aucune URL que vous saisissez n'est jamais envoyée à un serveur tiers ni journalisée quelque part. Ajouter un proxy irait à l'encontre de ce principe de confidentialité, même si cela lèverait la limitation.
Un statut « OK » signifie que la requête HEAD envoyée depuis votre navigateur a reçu un code de réponse entre 200 et 299. Cela reste un bon indicateur, mais certains sites bloquent spécifiquement les requêtes HEAD ou se comportent différemment selon l'origine, la localisation géographique ou l'user-agent de la requête. Le résultat reflète l'accessibilité du lien au moment du test, depuis votre navigateur.
Ce statut apparaît uniquement quand le site testé autorise les requêtes cross-origin et a effectivement répondu avec un code d'erreur (404 introuvable, 500 erreur serveur, 403 accès refusé...). Ces cas sont fiables, car le navigateur a bien reçu et pu lire une réponse du serveur distant.
Pas depuis un simple script exécuté dans un navigateur sur un autre domaine : c'est justement ce que le CORS empêche par conception, pour protéger les utilisateurs contre des requêtes malveillantes silencieuses. Une vérification exhaustive nécessite soit un outil serveur dédié (souvent payant ou à héberger soi-même), soit une extension navigateur avec des permissions élargies, soit un contrôle manuel via le bouton « Ouvrir » de chaque ligne.