Lien cassé après passage en minuscules : que conserver

Le texte visible peut cacher une autre adresse

Vous préparez un message avec le programme d’une journée. Le lien original ouvre le document, mais sa version publiée échoue malgré une apparence identique. Avant de remettre le fichier en ligne, copiez l’adresse du lien publié et comparez-la à l’original. Lire les lettres affichées ne suffit pas : un éditeur peut montrer un libellé associé à une autre adresse. Le problème peut concerner cette destination enregistrée plutôt que le document lui-même.

Les questions consultées documentent des doutes sur la casse des URL et des situations où le texte gardait son écriture tandis que la destination devenait minuscule. Elles signalent un besoin réel, sans affirmer que chaque plateforme souffre actuellement de ce défaut. Ce guide utilise un programme public et WikiURL pour repérer les différences. Il ne suppose ni que chaque lettre modifiée entraîne une erreur, ni que le vérificateur puisse réparer automatiquement la configuration d’un autre site.

Le domaine et le chemin suivent des règles différentes

RFC 3986 précise que le schéma et le nom d’hôte ne distinguent pas la casse ; les autres composants sont présumés sensibles sauf règle particulière contraire. Transformer EXAMPLE.invalid en example.invalid diffère donc du remplacement de Guias par guias ou de AB12 par ab12. Les deux exemples utilisent un domaine fictif sans fonctionnement. Remplacez-le par une destination réelle autorisée avant un essai de connexion ; les adresses servent ici uniquement à comparer du texte.

Le serveur détermine comment résoudre ses chemins et interpréter les paramètres de son application. Certains sites redirigent les variantes ; d’autres peuvent fournir des ressources différentes ou des erreurs. Ne concluez pas qu’un chemin acceptera les minuscules parce que le domaine les accepte. Google Search explique aussi traiter /APPLE et /apple comme des URL distinctes. Cela guide la cohérence d’un site géré, sans autoriser le renommage libre des liens fournis par un service externe.

https://EXAMPLE.invalid/Guias/PlanA.pdf?edicion=AB12
https://example.invalid/guias/plana.pdf?edicion=ab12

Comparez les composants avant toute transformation

Dans l’exemple JavaScript, URL sépare hôte, chemin et requête. MDN décrit pathname comme le composant de chemin et précise que les paramètres de requête n’en font pas partie. L’exécution analyse une chaîne sans se connecter au site fictif. Le nom d’hôte est normalisé, mais Guias, PlanA et AB12 gardent leur écriture. Cette séparation permet de désigner précisément la différence entre deux copies, sans confondre le domaine avec l’identifiant de la ressource.

Évitez d’appliquer toLowerCase à l’adresse entière comme nettoyage. Si l’identifiant appartient à une autre application, vous ignorez si sa combinaison de lettres est significative. Conservez également noms et valeurs des paramètres tels que fournis. Pour vos propres libellés d’une nouvelle campagne, convenez de l’écriture lors de leur création : c’est différent de transformer après coup un lien identifiant déjà une ressource. Gardez une copie originale pour comparer les changements ultérieurs.

const u = new URL("https://EXAMPLE.invalid/Guias/PlanA.pdf?edicion=AB12");
console.log(u.hostname); // example.invalid
console.log(u.pathname); // /Guias/PlanA.pdf
console.log(u.search);   // ?edicion=AB12

Vérifiez chaque version publique avec WikiURL

Pour une adresse publique sans secret, utilisez Vérifier URL de WikiURL et examinez l’état HTTP et la destination finale détectée. Si une copie originale et une copie modifiée doivent être comparées, vérifiez-les séparément. N’envoyez pas de lien privé de gestion, de jeton ou d’adresse confidentielle. Limitez le test aux variantes concrètes disponibles, sans énumérer d’identifiants ni rechercher les ressources d’autrui. Une différence de réponse peut aider à situer le début du problème.

Si l’original fonctionne et la copie minuscule renvoie une erreur, restaurez l’écriture originale avant diffusion. N’attribuez pas chaque 404 exclusivement à la casse : une ressource peut avoir été retirée ou son chemin mal copié. Si les deux réponses sont 200, ouvrez les pages pour confirmer programme, date et contenu. Le statut seul ne démontre pas l’équivalence. Examinez une redirection jusqu’à la destination détectée, puis dans le navigateur du lecteur, en contrôlant la ressource réellement reçue.

Modifiez la destination du bouton, pas seulement son libellé

Ouvrez l’option de modification du lien dans l’outil de rédaction. Examinez le champ d’adresse plutôt que le seul texte du bouton. L’exemple HTML distingue href du mot PDF. L’adresse est fictive et doit être remplacée avant utilisation. Vous pouvez afficher un libellé court ou en majuscules sans changer les lettres de l’adresse réelle. L’essentiel est que la destination enregistrée corresponde à celle approuvée, quelle que soit la présentation du libellé.

Après enregistrement ou publication, recopiez l’adresse du lien final et ouvrez-la dans le contexte prévu pour le public. Pour un document exporté, vérifiez le fichier exporté ; pour un message, le message reçu. L’éditeur avant envoi ne prouve pas le résultat publié. En cas de transformation inattendue, corrigez le champ concerné ou consultez le responsable de la plateforme, en gardant les deux versions comme preuve du changement observé. Contrôlez ensuite la correction dans la version distribuée.

<a href="https://example.invalid/Guias/PlanA.pdf?edicion=AB12">PDF</a>

Créez le lien court ou le QR depuis l’adresse vérifiée

Une fois la destination correcte, collez-la exactement dans WikiURL pour créer le lien court ou le QR à partager. Préservez aussi l’écriture renvoyée par l’outil et testez le résultat final. Ne mettez pas l’URL entière en majuscules pour le design et ne supposez pas que chaque code court tolère les changements de lettres. Un QR représente le texte qu’il contient ; il ne devine pas la variante du chemin voulue par l’auteur.

Si vous gérez le site et souhaitez une adresse facile à dicter, demandez un chemin stable ou une redirection délibérée, puis vérifiez-la. Écrire une version plus jolie ne crée pas une destination inexistante. Consignez l’adresse approuvée, ses emplacements et les vérifications avant impression ou envoi. La règle pratique est simple : le libellé peut suivre le design ; l’adresse reste inchangée jusqu’à confirmation, par le responsable de la ressource, d’une alternative réellement fonctionnelle.