Votre PDF s’ouvre au lieu de se télécharger : vérifiez le lien

Définissez le besoin du destinataire du PDF

Vous envoyez le programme d’une journée avec un bouton Télécharger, mais le document apparaît dans un onglet. Une autre personne obtient un téléchargement alors qu’elle voulait lire. Aucune situation ne prouve seule que le lien est cassé. Avant de modifier l’URL, décidez si vous voulez faciliter la lecture, fournir une copie ou proposer les deux, puis vérifiez le comportement réel sur l’appareil du destinataire.

Les questions consultées montrent deux besoins : télécharger un PDF externe depuis HTML et l’afficher malgré les préférences du navigateur. Ce guide prend un programme public comme exemple. WikiURL aide à examiner la réponse et la destination d’une URL ; il ne configure pas le serveur du document et ne remplace pas la visionneuse du visiteur. Séparez le contenu demandé, les instructions du serveur et leur interprétation par le navigateur.

Les en-têtes orientent la présentation du fichier

MDN explique que Content-Disposition indique un affichage dans le navigateur ou un traitement comme pièce jointe. RFC 6266 définit inline et attachment. Les exemples représentent deux réponses alternatives, et non un bloc à envoyer ensemble. Content-Type décrit le type PDF et filename propose un nom. Ces en-têtes viennent du serveur qui fournit le fichier. Écrire leurs noms dans le bouton ou l’adresse ne configure pas sa réponse.

Inline exprime une intention d’affichage, tandis qu’attachment demande un traitement en téléchargement. Cela ne garantit pas une expérience identique : MDN rappelle l’influence du navigateur, des réglages et d’autres facteurs. Un téléchargement peut être enregistré automatiquement ou ouvert ensuite. Demandez au responsable de l’hébergement d’examiner la réponse réelle du fichier final. Évitez une modification globale affectant chaque document si seul le programme concerné doit changer de comportement.

Content-Type: application/pdf
Content-Disposition: inline; filename="programa.pdf"

Content-Type: application/pdf
Content-Disposition: attachment; filename="programa.pdf"

Ne confondez pas le nom du lien et son contenu

L’adresse fictive de l’exemple ne fonctionne pas : remplacez example.invalid par votre domaine publié avant les essais. Vérifiez que la destination fournit le programme approuvé plutôt qu’une annonce, une connexion privée ou une erreur. Un chemin finissant en .pdf est un indice, pas une vérification du contenu. Renommer l’URL ne transforme pas une page HTML en PDF et ne répare pas un document endommagé.

Si vous gérez le site, examinez la requête du fichier dans les outils réseau du navigateur et les valeurs Content-Type et Content-Disposition de la réponse finale. Sinon, transmettez au responsable l’URL, le comportement observé et le résultat souhaité. Faites vérifier le bon fichier, sans captures contenant cookies ou identifiants. Conservez l’original approuvé : changer un nom ou des en-têtes ne signifie pas que le contenu du programme a été révisé.

https://example.invalid/documentos/programa.pdf

L’attribut download n’est pas une commande universelle

Sur une page que vous contrôlez, vous pouvez proposer un lien HTML avec download. MDN limite son fonctionnement aux URL de même origine et aux cas blob et data pris en charge. Pour une URL d’une autre origine, l’attribut est ignoré et une navigation normale intervient ; le serveur cible peut encore demander un téléchargement via Content-Disposition. N’annoncez pas une correction du fichier externe par ce seul attribut ou par le texte du bouton.

Un lien court ajoute une destination au parcours sans transformer le PDF d’un autre serveur en fichier de votre origine. Un QR représente une adresse et n’installe pas davantage d’instructions de téléchargement. Avec un hébergement externe, utilisez les options documentées ou demandez au propriétaire l’URL de distribution appropriée. Sans contrôle sur sa réponse, une page de lecture accompagnée d’instructions claires peut être plus utile qu’une promesse de téléchargement automatique impossible à garantir.

Examinez le parcours public avec WikiURL

Entrez l’URL publique du programme dans Vérifier URL de WikiURL. Examinez l’état HTTP et la destination finale détectée en cas de redirection. N’envoyez aucune adresse privée, lien d’administration ou secret. Si le résultat aboutit à une connexion ou à une autre ressource, corrigez d’abord la destination partagée. Le statut 200 décrit la réponse à cette vérification ; il ne démontre pas que le visiteur a enregistré le PDF sur son appareil.

Ouvrez ensuite exactement le lien à envoyer sur ordinateur et téléphone. Vérifiez le titre et la date du programme, sa lisibilité et la possibilité d’enregistrer une copie avec les commandes disponibles. Le vérificateur ne reproduit ni la visionneuse ni les préférences de chaque lecteur. Si le résultat technique diffère de l’expérience dans le navigateur, notez les deux contextes. Un seul essai ne permet pas de promettre la même expérience à chaque personne.

Annoncez clairement le résultat et gardez une trace

Pour la lecture, Voir le programme en PDF évite de promettre un enregistrement immédiat. Si vous proposez un téléchargement testé, précisez le document et sa taille lorsqu’elle est connue. Vous pouvez joindre une courte instruction pour enregistrer depuis la visionneuse lorsqu’elle s’ouvre. N’imposez pas de modifier les réglages généraux du navigateur pour un seul programme et ne cachez pas la destination derrière plusieurs boutons ambigus.

Conservez l’URL finale, la version et les appareils testés avant de créer le QR ou diffuser le lien court. Recommencez après un changement d’hébergement ou de fichier : la réponse reçue peut changer. Le résultat utile est un programme correct, accessible au public prévu, avec des instructions honnêtes pour lire ou enregistrer. Ouvrir un onglet et télécharger sont deux comportements distincts que le message du lien doit refléter.