Relu et mis à jour en juin 2026 — comportement natif de livraison des produits virtuels et de protection des téléchargements vérifié sur PrestaShop 1.7, 8 et 9.

Voici la vérité inconfortable sur la vente de fichiers numériques : la vente est la partie facile. La partie difficile commence juste après le paiement, quand le client s’attend à recevoir son fichier tout de suite, à pouvoir encore l’utiliser lorsqu’il changera d’ordinateur portable le mois prochain, et — si quelque chose se passe mal — se retrouve à un clic d’un litige de paiement que vous aurez du mal à contester. Les produits physiques laissent une trace : un numéro de suivi, une signature, un transporteur. Un téléchargement ne laisse rien, sauf si vous construisez cette trace vous-même. Ce guide traite précisément de cela : comment PrestaShop livre et protège réellement un fichier en coulisses, où son système natif est solide, où il vous laisse discrètement exposé, et comment combler les manques.

C’est la partie livraison et protection du commerce numérique. Le modèle économique plus large — comment définir des niveaux de prix, structurer les licences, gérer la TVA européenne et configurer un produit virtuel dès le départ — est un sujet à part entière, traité dans la vente de produits numériques sur PrestaShop. Ici, nous restons concentrés et allons en profondeur sur une seule question : une fois le paiement effectué, comment le fichier parvient-il au client en toute sécurité, et comment l’empêcher de circuler partout ailleurs ?

Comment PrestaShop sert réellement un fichier téléchargeable

Tableau de bord d'administration des produits numériques PrestaShop affichant validations, téléchargements, licences, domaines et compteurs de produits
Un tableau de bord des produits numériques suit les validations, les téléchargements, les licences, les domaines enregistrés et les produits numériques pour voir comment vos fichiers sont livrés.

Il est utile de comprendre ce qui se passe, car chaque décision de protection en découle. Lorsque vous marquez un produit comme produit virtuel et que vous y joignez un fichier, PrestaShop ne place pas ce fichier dans un dossier public. Il le stocke dans /download/, à la racine de votre installation, renommé avec un long hachage SHA1 sans extension — quelque chose comme /download/3f7a9c1e…. Ce dossier est fourni avec un fichier .htaccess qui interdit l’accès direct depuis le web : un client ou un robot qui tente de deviner des URL n’obtient donc rien.

Le téléchargement réel est orchestré par un contrôleur, et non par un lien statique. De PrestaShop 1.7 à 8, le fichier est servi via le contrôleur frontal get-file, atteint au moyen d’un lien de téléchargement sécurisé qui transporte un jeton de commande/téléchargement plutôt qu’un chemin public direct vers le fichier — la forme exacte de l’URL et ses paramètres varient selon la version et selon le parcours du client (page du compte, commande ou e-mail), il ne faut donc pas s’appuyer sur un format codé en dur. Avant d’envoyer le moindre octet, l’accès est conditionné par ce jeton de téléchargement/sécurité, par la validité et le statut payé de la commande, par la fenêtre d’expiration et par le nombre de téléchargements restants ; selon la route et le contexte, la connexion au compte peut aussi être exigée. Les métadonnées derrière tout cela vivent à deux endroits, et il est important de les distinguer. Les valeurs par défaut du produit se trouvent dans la table ps_product_download — les colonnes qui vous concernent sont nb_downloadable (combien de fois), date_expiration (jusqu’à quand), is_shareable et display_filename (le nom convivial vu par le client, distinct du nom haché sur le disque). Une fois la commande passée, l’état de téléchargement propre à cette commande — son propre hachage de téléchargement, son compteur restant et son échéance — est enregistré au niveau du détail de commande, de sorte que chaque achat suit son propre usage indépendamment des valeurs par défaut du produit.

Qu’est-ce que cela vous apporte concrètement ? Par défaut, PrestaShop vous donne déjà les deux choses que la plupart des marchands pensent devoir ajouter eux-mêmes : des fichiers inaccessibles par simple devinette d’URL, et des téléchargements réservés à une vraie commande payée, avec accès vérifié. Vous ne partez pas de zéro. Vous partez d’une base « sécurisée mais brute », et votre travail consiste à l’affiner.

Configurer correctement le produit virtuel natif

Les réglages qui déterminent le comportement de livraison se trouvent dans l’onglet Produit virtuel du produit (en 1.7 et versions ultérieures, définissez d’abord le type de produit sur Produit virtuel, ce qui fait apparaître l’onglet). Les champs semblent anodins ; de mauvaises valeurs sont pourtant à l’origine de la plupart des demandes de support reçues par les vendeurs de produits numériques.

RéglageCe qu’il contrôleValeur raisonnable & pourquoi
Nombre de téléchargements autorisés (nb_downloadable)Combien de fois la même commande peut récupérer le fichierPas 1. Un client qui change d’ordinateur, perd le fichier ou subit une connexion interrompue a besoin d’un nouvel essai. 3 à 5 téléchargements absorbent les re-téléchargements légitimes sans encourager le partage massif.
Date d’expirationLa date après laquelle le lien cesse de fonctionnerLaissez-la généreuse ou vide, sauf si vous vendez volontairement un accès limité dans le temps. Une expiration trop agressive transforme « je l’ai acheté l’année dernière » en ticket de support.
Nombre de joursNombre de jours pendant lesquels le lien reste valide après la commande30 à 90 pour des produits ponctuels ; pratiquement illimité si vous promettez un accès continu. Associez cela au re-téléchargement depuis le compte, ci-dessous.
Fichier / nom du fichierLe fichier réellement envoyé, limité par les paramètres serveur upload_max_filesize et post_max_sizeUtilisez ce champ seulement pour les fichiers petits à moyens. Les gros fichiers doivent être placés sur un stockage cloud — voir plus bas.

Un piège mérite d’être signalé : un véritable produit virtuel ne doit avoir ni poids ni livraison. Si un article numérique entraîne encore le tunnel de commande vers une étape de livraison, c’est qu’il a été configuré comme produit physique avec fichier plutôt que comme produit virtuel. Vérifiez que le type est bien virtuel afin de sauter l’étape du transporteur et de ne pas demander d’adresse de livraison pour un téléchargement.

Trois modèles de livraison, et quand utiliser chacun

La « livraison » d’un fichier n’est pas une réalité unique. Il existe trois schémas, et le bon choix dépend presque entièrement de la taille du fichier et du niveau de traçabilité dont vous avez besoin.

ModèleAdapté àLe point de vigilance
Téléchargement natif depuis le compte (contrôleur get-file)La plupart des fichiers jusqu’à quelques centaines de Mo ; le choix par défaut et le chemin le plus sûrLe fichier est diffusé via votre serveur web — les gros fichiers occupent des processus PHP et sollicitent votre max_execution_time.
Pièce jointe par e-mailDes charges très légères — une clé de licence, un PDF unique, un petit modèle sous environ 10 MoLimites de pièces jointes des fournisseurs (souvent 25 Mo), filtrage antispam et aucun contrôle d’accès une fois le fichier dans une boîte de réception. Correct pour des clés, inadapté pour des fichiers de valeur.
Stockage cloud avec URL signéesGros logiciels, formations vidéo, packs de ressources haute résolutionNécessite une URL signée et limitée dans le temps (S3, GCS ou équivalent), générée pour chaque commande — jamais un lien public permanent, sous peine de le voir indexé et partagé.

La règle de décision est simple. En dessous de quelques centaines de mégaoctets, laissez le contrôleur natif de PrestaShop faire le travail : il est déjà sécurisé et lié à la commande. Au-delà, ne faites pas transiter le fichier par votre serveur web ; hébergez-le sur un stockage cloud et fournissez une URL signée qui expire. Le contrôleur natif protège l’accès ; le stockage cloud protège la réactivité de votre serveur lorsque tout le monde télécharge en même temps.

Une protection qui dissuade sans punir les acheteurs

Vous ne pouvez pas rendre un fichier incopiable. Toute personne qui prétend le contraire vous vend du DRM. L’objectif honnête est plus étroit et atteignable : faire de l’achat légitime le chemin le plus simple, et rendre le repartage occasionnel assez traçable pour faire hésiter. Trois mesures portent presque tout l’effort.

Filigrane par client

C’est la protection qui offre le meilleur rapport valeur/friction pour les documents et les médias. Marquez chaque PDF, image ou archive téléchargé avec le nom, l’e-mail ou l’ID de commande de l’acheteur. Cela ne bloque pas un pirate déterminé — et ce n’est pas grave, car ce n’est pas lui la cible. La cible, c’est le client ordinaire qui transférerait facilement un fichier à un collègue ou à un forum. Dès que son propre nom apparaît sur chaque page, la plupart ne le font plus. Et lorsqu’un fichier fuit malgré tout, le filigrane vous indique de quel compte il provient. La fonctionnalité native de produit virtuel ne pose pas de filigrane ; c’est la raison la plus fréquente pour laquelle les vendeurs se tournent vers un module.

Clés de licence (quand le fichier seul n’est pas le produit)

Pour un logiciel, le fichier est souvent sans valeur sans clé. Fournissez une clé unique par commande, validez-la à l’installation ou périodiquement auprès de votre serveur, et le fichier qui fuit devient simplement un installateur divulgué qui ne s’activera pas. La stratégie plus profonde — clés perpétuelles ou par abonnement, liaison à un domaine, licences par niveaux — relève de la vente de produits numériques sur PrestaShop ; ici, il suffit de retenir que la livraison de la clé fait partie de la livraison : la clé doit arriver en même temps que le téléchargement, à la fois dans l’e-mail de confirmation et sur la page du compte, sinon vous venez de créer une file d’attente au support.

Limites de téléchargement et expiration comme filet de sécurité discret

Les valeurs nb_downloadable et date_expiration définies plus haut ne relèvent pas seulement du rangement — elles plafonnent la diffusion possible d’un achat avant que le lien ne devienne inactif. Bien réglées (quelques téléchargements, une fenêtre raisonnable, avec re-téléchargement disponible depuis le compte), elles sont invisibles pour les acheteurs honnêtes et imposent une vraie limite au partage de liens.

Ce qu’il vaut mieux éviter : les DRM lourds (Adobe DRM, Widevine, FairPlay). Ils ajoutent de la friction pour les personnes qui vous ont payé, cassent sur des appareils que vous n’aviez pas anticipés et sont malgré tout contournés par les personnes qui vous inquiétaient. Pour une petite ou moyenne boutique, le bilan est négatif. Filigrane, clé et limite — puis concentrez votre énergie sur l’expérience.

Mises à jour et re-téléchargements : la partie qui fidélise

Contrairement à un produit physique, un produit numérique est censé s’améliorer. Un acheteur qui a reçu un modèle, un plugin ou un ebook le trimestre dernier suppose qu’il pourra récupérer la version corrigée ce trimestre-ci — et accepte mal de devoir payer à nouveau. Le produit virtuel natif remplace le fichier sur le disque lorsque vous en envoyez un nouveau, mais il n’a pas de notion de versions : pas de journal des modifications, pas de signal « vous êtes en v2, la v3 est disponible », pas de notification aux anciens acheteurs. Le socle pratique que vous devez à vos clients est donc le suivant :

  • Re-téléchargement depuis le compte — le minimum. Leur page de commande doit toujours servir le fichier actuel, dans la fenêtre de téléchargement que vous avez définie.
  • Notification de mise à jour — même un simple e-mail lorsqu’une nouvelle version est publiée. Cela ramène les clients sur votre boutique et justifie discrètement votre prix.
  • Un journal des modifications — les acheteurs doivent savoir ce qui a changé avant de prendre la peine de re-télécharger.
  • Une période de mises à jour définie — « 12 mois de mises à jour, renouvellement optionnel » est durable ; « mises à jour à vie » est un engagement ouvert que vous regretterez sur un produit que vous finirez peut-être par retirer.

La gestion des versions, les journaux de modifications par publication et la notification des acheteurs existants sont précisément les manques où un outil conçu pour cela mérite sa place — nous y revenons plus bas.

Construire la preuve de livraison à laquelle personne ne pense avant qu’il soit trop tard

C’est là que les vendeurs de produits numériques se font mal, et cela mérite sa propre section, car le système natif enregistre très peu d’éléments utiles en cas de litige. Un client affirme n’avoir jamais reçu le fichier. Avec un colis, vous produiriez un numéro de suivi. Avec un téléchargement, vous avez… ce que vous avez journalisé. Si vous n’avez rien, vous perdez le litige et payez les frais.

Construisez vos preuves volontairement :

  • Journalisez chaque téléchargement avec l’horodatage, l’adresse IP, l’agent utilisateur et le compte client / la commande concernés. C’est votre numéro de suivi.
  • Envoyez un e-mail de livraison qui décrit explicitement ce qui a été acheté et contient le lien de téléchargement — ainsi, « je n’ai jamais rien reçu » est contredit dans la propre boîte de réception du client.
  • Conservez les enregistrements d’accès — heures de connexion, historique des téléchargements par commande — afin qu’un schéma de téléchargements répétés affaiblisse une réclamation de type « jamais reçu ».
  • Disposez de conditions générales que le client accepte avant l’achat, afin que les règles de ce qu’il a acheté soient consignées.
  • Répondez rapidement avec ces preuves ; les prestataires de paiement évaluent les litiges selon la capacité du vendeur à démontrer la livraison, et un journal de téléchargement propre suffit souvent.

S’il ne faut retenir qu’une chose de ce guide, retenez celle-ci : transformez la livraison en événement journalisé. Un téléchargement qui laisse une trace horodatée, avec adresse IP, fait la différence entre gagner et perdre les litiges qui grignotent discrètement les marges du numérique.

Quand le système natif atteint ses limites

La livraison native de PrestaShop est réellement bonne sur les fondamentaux — stockage sécurisé, accès conditionné à la commande, limites de téléchargement. Elle atteint ses limites exactement sur les points ci-dessus : elle ne pose pas de filigrane, ne gère pas les versions, ne génère ni ne lie de clés de licence, ne journalise pas les téléchargements avec le niveau de détail utile pour un litige, et ne notifie pas les anciens acheteurs des mises à jour. Ce ne sont pas des cas marginaux pour un vendeur numérique sérieux ; c’est le travail quotidien.

C’est précisément l’écart que notre module Digital Revolution est conçu pour combler, et il répond à chacun des problèmes soulevés dans ce guide. Qu’est-ce que cela change concrètement pour vous ? Les téléchargements arrivent via des liens temporaires basés sur des jetons, qui résistent au partage au lieu de dépendre seulement de limites. Chaque téléchargement est personnalisé avec des informations de filigrane, de sorte qu’un fichier divulgué pointe vers le compte dont il provient — le piratage devient traçable, pas seulement interdit. Les fichiers sont livrés automatiquement dès que le paiement est confirmé, avec le lien et toute clé de licence dans le même e-mail, ce qui élimine les tickets « où est mon téléchargement ? ». La gestion des versions permet aux clients existants de recevoir le fichier mis à jour (et un journal des modifications), afin que les mises à jour renforcent la fidélité au lieu de créer de la charge support. Et chaque téléchargement est journalisé avec l’IP, l’agent utilisateur et l’ID de filigrane — exactement la preuve de livraison décrite plus haut, conservée pour vous au lieu d’être reconstituée dans l’urgence au milieu d’un litige. Pour les vendeurs qui distribuent des logiciels ou des modules, il ajoute des types de licence, une liaison au domaine afin qu’une clé ne puisse pas être installée partout à la fois, et une gestion de l’ensemble depuis le portail client. Il s’installe et se configure depuis le back-office, pas via une facture de développeur.

Où la livraison rejoint le reste de votre exploitation

Protéger et livrer le fichier n’est qu’un maillon de la chaîne. Quelques tâches voisines déterminent si l’ensemble de l’expérience tient debout :

Questions fréquentes

Où PrestaShop stocke-t-il les fichiers téléchargés par les clients ?

Dans le dossier /download/, à la racine de votre installation, renommés avec un long hachage SHA1 sans extension — jamais dans un dossier web public. Ce dossier est fourni avec un .htaccess qui interdit l’accès direct : deviner une URL ne donne donc rien à un robot. Le téléchargement réel est orchestré par un contrôleur frontal (la route get-file en 1.7–8) qui vérifie un jeton de téléchargement, le statut payé/valide de la commande, la fenêtre d’expiration et le nombre de téléchargements restants avant de diffuser le moindre octet.

Combien de téléchargements dois-je autoriser par achat ?

Pas 1. Un client qui change d’ordinateur, subit une connexion interrompue ou efface un disque a besoin d’un nouvel essai. Trois à cinq téléchargements absorbent les re-téléchargements légitimes sans encourager le partage massif. Le régler sur 1 est la cause la plus fréquente des tickets de support « j’ai perdu mon fichier ». Associez un compteur raisonnable au re-téléchargement depuis le compte client.

Puis-je empêcher les gens de partager le fichier après l’achat ?

Vous ne pouvez pas rendre un fichier incopiable — quiconque prétend le contraire vend du DRM. L’objectif atteignable consiste à rendre le repartage occasionnel traçable et légèrement moins pratique. Les trois mesures qui portent presque tout l’effort : filigrane par client (marquer le nom/l’e-mail de l’acheteur sur chaque téléchargement), clés de licence pour les logiciels, et limites de téléchargement raisonnables avec expiration. Les DRM lourds (Adobe DRM, Widevine, FairPlay) ajoutent de la friction pour les acheteurs honnêtes et sont contournés malgré tout par les personnes qui vous inquiétaient.

PrestaShop ajoute-t-il un filigrane aux téléchargements ou les journalise-t-il pour les litiges de paiement ?

Non. Le produit virtuel natif est sécurisé et lié à la commande, mais il ne pose pas de filigrane sur les fichiers, ne gère pas leurs versions, ne génère ni ne lie de clés de licence, et journalise très peu d’informations utiles pour un litige de paiement. Ces manques constituent le quotidien d’un vendeur numérique sérieux — filigrane par client, livraison automatique avec clé, gestion des versions et journal de téléchargement avec IP/agent utilisateur sont exactement ce qu’ajoute Digital Revolution.

Comment gagner un litige de paiement « je n’ai jamais reçu mon téléchargement » ?

Transformez la livraison en événement journalisé. Enregistrez chaque téléchargement avec l’horodatage, l’IP, l’agent utilisateur et la commande concernée — c’est votre numéro de suivi. Envoyez un e-mail de livraison qui nomme explicitement ce qui a été acheté et fournit le lien, afin que « je n’ai rien reçu » soit contredit dans la propre boîte de réception du client. Les prestataires de paiement évaluent les litiges selon la capacité du vendeur à prouver la livraison, et un journal de téléchargement propre suffit souvent.

En résumé

Vendre des fichiers paraît simple vu de l’extérieur — pas d’entrepôt, pas de transporteur, une marge pure. Le travail se déplace simplement vers un endroit moins visible : s’assurer que la bonne personne reçoit le fichier, que les mauvaises personnes ne l’obtiennent pas, que le fichier s’améliore avec le temps, et que chaque livraison laisse une trace défendable lorsque de l’argent est en jeu. PrestaShop vous fournit gratuitement une base sécurisée, conditionnée à la commande ; la valeur que vous ajoutez par-dessus, ce sont le filigrane, la gestion des versions, la livraison automatique avec clé et un journal de téléchargement qui permet de gagner les litiges. Faites cela correctement, et le « produit numérique sans friction » se comporte enfin comme tel — pour le client comme pour vous.

Partager cet article:
David Miller

David Miller

Founder, mypresta.rocks

David Miller est un spécialiste PrestaShop fort de plus de dix ans d'expérience concrète et le fondateur de mypresta.rocks, un studio de développement situé à Tychy, en Pologne. Il conçoit et maintient un catalogue de 152 modules PrestaShop — dont 21 suites « Revolution » couvrant le SEO, le checkout, la sécurité, la performance, le marketing, la recherche, le support et la gestion d'entrepôt — qui améliorent chaque jour de vraies boutiques, testés sur PrestaShop 1.7.8, 8.x et 9.x. Il assure également la maintenance de boutiques en production réalisant plusieurs millions de chiffre d'affaires annuel : son travail se juge donc sur des ventes réelles, pas sur des démos. Son expérience couvre l'ensemble du e-commerce — performance, sécurité, SEO et marketing — et va au-delà de PrestaShop, jusqu'à WooCommerce, Shopify et les systèmes sur mesure. Sur le blog, il écrit sur la face technique de PrestaShop : ce que la plateforme fait vraiment, ce qui casse en production et quelles solutions tiennent dans la durée.

Cet article vous a plu ?

Recevez nos derniers conseils, guides et mises à jour de modules dans votre boîte mail.

Commentaires

Aucun commentaire pour le moment. Soyez le premier !

Soyez le premier à poser une question ou à partager un retour utile.

Chargement...
Retour en haut