Télécharger un document : vérifier le fichier reçu, pas seulement le bouton

Un bouton « Télécharger » répond au clic, puis le client retrouve un fichier au nom incompréhensible. Il l’ouvre et découvre une page de connexion à la place du document attendu. Ce scénario fictif rappelle qu’un téléchargement se vérifie jusqu’au fichier reçu, pas seulement jusqu’à l’animation du bouton.

Catalogue PDF, notice, compte rendu ou export : le parcours doit annoncer ce qui sera fourni et permettre de le retrouver. Voici les points à préciser avec votre prestataire web avant d’accepter cette fonctionnalité. Les exemples utilisent des documents de test, sans données clients réelles.

Annoncer le document avant le clic

Le libellé doit aider la personne à choisir le bon fichier. « Télécharger la notice du modèle A, PDF » est plus précis qu’une série de boutons identiques « Télécharger ». Si une version ou une langue distingue plusieurs documents, indiquez-la à proximité. Affichez une taille seulement si elle correspond au fichier réellement servi.

Le W3C explique que l’objectif d’un lien doit pouvoir être compris à partir de son texte, seul ou avec son contexte déterminable par programme. Un texte descriptif facilite notamment le choix parmi une liste de liens présentée par une aide technique. W3C : comprendre l’objectif des liens.

Pour un catalogue fictif, préparez deux notices aux titres proches. Demandez à une personne de retrouver celle du bon modèle sans ouvrir les deux fichiers. Cette petite recette permet de repérer un intitulé ambigu avant de discuter des détails techniques. Elle ne remplace pas une évaluation complète de l’accessibilité.

Distinguer aperçu et téléchargement

Une page peut proposer « Consulter le PDF » et « Télécharger le PDF ». Définissez l’intention de chaque action. Un aperçu qui s’ouvre dans le navigateur peut être utile, mais il ne correspond pas forcément à ce qu’attend une personne qui souhaite conserver le document pour plus tard.

MDN décrit l’en-tête HTTP Content-Disposition : inline indique que le contenu peut être affiché dans le navigateur ; attachment indique qu’il doit être proposé comme pièce à télécharger. Des paramètres permettent aussi de suggérer un nom de fichier. MDN : en-tête Content-Disposition.

Le développeur doit vérifier les instructions envoyées avec la réponse du serveur, pas seulement le texte du bouton. Dans un parcours utilisant un stockage externe, cette vérification concerne aussi le service qui livre finalement le fichier après les éventuelles redirections.

Le navigateur et ses réglages conservent une influence sur l’expérience : demande de confirmation, enregistrement ou ouverture peuvent varier. Votre recette doit donc préciser les navigateurs et appareils essayés, plutôt que promettre une fenêtre identique partout.

Tester le vrai lien, y compris sur un autre domaine

L’attribut HTML download peut demander de traiter un lien comme un téléchargement. Il n’agit pas de la même manière pour toutes les adresses. La documentation MDN indique qu’il s’applique aux URL de même origine et à certains schémas locaux comme blob et data ; pour les autres URL, l’attribut est ignoré, même si le serveur distant peut encore déclencher un téléchargement avec Content-Disposition. MDN : liens et attribut download.

Un bouton validé avec un fichier situé dans le site peut donc se comporter autrement une fois relié au stockage de production. Demandez un essai avec le circuit réel prévu : même service de stockage, même type de redirection et même mécanisme d’accès, mais avec un document fictif.

Pour un document privé, vérifiez séparément les droits de consultation. Un nom de fichier correct ou un téléchargement réussi ne démontre pas que l’accès est protégé. Notre guide sur les documents d’un espace client traite ce contrôle spécifique ; il reste nécessaire même si la livraison du fichier fonctionne.

Donner au fichier un nom utile et un contenu reconnaissable

Choisissez une convention que l’équipe comprend : type de document, référence utile et version lorsque celle-ci compte. Évitez d’exposer inutilement des informations personnelles dans un nom visible sur un appareil partagé. Pour les essais, utilisez par exemple une notice portant un identifiant fictif et une date de révision inscrite dans son contenu.

Le nom suggéré peut être adapté par le navigateur aux contraintes du système de fichiers. MDN signale aussi que le nom fourni par Content-Disposition peut prendre le dessus sur celui de l’attribut download. Ne considérez donc pas le nom écrit dans le code du bouton comme une preuve du résultat obtenu.

Contrôlez le fichier sauvegardé : son nom, son extension, son ouverture dans l’outil prévu et son contenu. Une extension PDF ajoutée à une réponse d’erreur ne transforme pas cette réponse en document PDF. Pour un export, vérifiez les données attendues à l’intérieur avec un jeu de test connu.

Faites également remplacer le document de test par une nouvelle version, puis recommencez le parcours. L’intitulé de la page, le nom reçu et le contenu doivent désigner la même version. Si ce n’est pas le cas, le prestataire devra examiner la génération, le stockage et les éventuelles copies en cache.

Prévoir les échecs et garder une preuve de recette

Testez une session expirée, un document retiré et une indisponibilité simulée du service dans l’environnement de test. Le parcours doit expliquer comment poursuivre, sans afficher une réussite lorsque le fichier n’a pas été obtenu. Évitez un message définitif « Fichier enregistré » fondé uniquement sur le clic : déclencher une action ne prouve pas que la personne a conservé le document.

Conservez une courte fiche pour chaque essai :

• page de départ et document demandé ;
• compte de test et état de connexion ;
• appareil et navigateur utilisés ;
• résultat attendu, notamment aperçu ou téléchargement ;
• nom et contenu du fichier effectivement reçu ;
• comportement observé en cas d’échec.

Refaites les essais après un changement de stockage, de génération de PDF ou de connexion utilisateur. Le résultat à accepter est concret : une personne choisit le bon document, obtient un fichier exploitable et sait quoi faire si l’opération échoue. Cette preuve vaut davantage qu’une capture montrant seulement un bouton au bon endroit.