Le lien fonctionne sur votre site, mais pas au partage

Repérez ce qui manque avant de transmettre

Sur votre site, vous ouvrez le programme d’une rencontre sans problème. Puis vous copiez agenda.pdf ou un chemin commençant par une barre dans un courriel, et le destinataire n’atteint pas le fichier. Les questions consultées montrent cette difficulté et la surprise de perdre un morceau du chemin de base lors de la construction d’une adresse. Avant d’accuser le courrier ou le raccourcisseur, regardez ce qui a été copié : une référence relative nécessite un contexte pour obtenir sa destination complète. Elle peut être parfaitement valable sur un site. Hors de ce contexte, préparez une URL web complète et vérifiée. Résoudre l’adresse ne démontre pas l’existence du document ni son adéquation au public.

Identifiez la base donnant son sens au chemin

MDN explique que la résolution utilise une URL de base, sans simplement coller deux chaînes. Dans un document HTML, elle dépend normalement de son emplacement, mais un élément base avec href peut la modifier. Si le code ne montre qu’un chemin, ne devinez pas le domaine ou le dossier manquant. Préférez la fonction du navigateur pour copier l’adresse du lien, puis examinez le résultat plutôt que recopier l’attribut. Si vous entretenez le site, comparez la base réelle du document à la destination attendue avant correction. N’ajoutez pas une balise base à toute la page comme réparation rapide : elle peut changer la résolution d’autres références que celle étudiée. Établissez d’abord le contexte.

Vérifiez l’effet des barres de l’exemple

Les trois expressions illustrent la résolution avec le constructeur URL. Le domaine example.invalid et le fichier sont fictifs ; ils ne prouvent pas l’existence d’un programme téléchargeable. Avec une base terminée par event/, agenda.pdf produit une adresse dans ce dossier. Une référence commençant par/agenda.pdf repart de la racine de la même origine. Si la base finit par event sans barre finale, la résolution de agenda.pdf remplace ce dernier segment et revient à la racine. MDN et RFC3986 décrivent ces différences. N’ajoutez ni ne retirez de barres par habitude. Choisissez l’adresse correspondant à la ressource réelle et vérifiez la sortie complète, pas seulement le dernier nom de fichier.

Notez les résultats : d’abord https://example.invalid/event/agenda.pdf, puis https://example.invalid/agenda.pdf et encore https://example.invalid/agenda.pdf. Deux expressions donnant la même adresse ne prouvent pas que le dossier event existe ou devrait être omis sur votre site. Lors d’un véritable test, séparez adresse calculée, document ouvert et accès du public. Laissez non vérifié ce qui n’a pas été observé. Ces résultats décrivent une résolution locale de chaînes, pas un téléchargement ni un contrôle de serveurs.

new URL("agenda.pdf", "https://example.invalid/event/").href
new URL("/agenda.pdf", "https://example.invalid/event/").href
new URL("agenda.pdf", "https://example.invalid/event").href

Validez la ressource après résolution

Vérifiez que l’URL obtenue contient le domaine et le chemin attendus. Un constructeur peut produire une adresse syntaxiquement valide vers une mauvaise ressource ; il n’accorde aucun droit et ne contrôle pas le contenu. Pour une destination publique sans secret ni donnée personnelle, saisissez l’adresse complète dans le vérificateur Wiki URL et notez réponse HTTP et URL finale. Ouvrez aussi la ressource pour confirmer le bon programme et l’accès du public prévu. Une réponse200 seule ne démontre ni l’un ni l’autre. En présence de redirections, examinez la destination finale avant validation. Pour des documents privés, utilisez des moyens autorisés et évitez les outils externes. Gardez ces contrôles distincts.

Diffusez l’adresse approuvée et testez la réception

Après vérification de l’URL complète, utilisez-la dans le courriel ou document final. Si l’éditeur permet un nom de lien, conservez la destination approuvée même si le texte indique Programme de la rencontre. Ne remplacez pas l’adresse réelle par un chemin incomplet pour raccourcir l’affichage. Si un lien court ou QR est nécessaire, créez-le dans Wiki URL depuis la destination complète approuvée et testez exactement cette version. Le raccourcisseur ne devine pas le site ou dossier manquant et ne publie pas le fichier à votre place. Rouvrez le lien depuis la version reçue ou exportée, pas seulement l’aperçu de l’éditeur. Cette vérification révèle les différences du support distribué.

Conservez ensemble contexte, destination et preuves

Gardez référence initiale, base utilisée, URL résolue et version partagée pour reproduire le cas après un changement de dossier, modèle ou site. Ne remplacez pas aveuglément toutes les références relatives : le problème est de transporter un lien hors de son contexte, pas d’interdire une technique valable dans les pages. Si le fichier déménage, revoyez références et supports diffusés et convenez avec le responsable du maintien de l’accès. Ne promettez pas l’actualisation automatique d’un ancien QR. Le résultat utile associe une adresse complète vers le document prévu à un test du parcours réel. Wiki URL aide à vérifier et diffuser l’adresse ; la résoudre ne remplace ni l’examen du contenu ni les autorisations d’accès.