Vendre des oeuvres en ligne sans laisser les fichiers en accès libre

Le contexte

Un collectif artistique associatif souhaite un site pour présenter ses oeuvres, animer sa communauté et proposer certaines créations au téléchargement, gratuitement pour la plupart, contre paiement pour d’autres.

Le nom du collectif n’est pas publié ici, faute d’accord écrit à ce jour.

Le problème

Le site comportait un défaut de conception que je qualifierais de classique, au sens où je le rencontre très souvent : les fichiers étaient stockés dans un espace public.

Concrètement, l’adresse d’un fichier d’oeuvre était une adresse permanente, accessible sans compte, copiable, partageable et indexable par les moteurs de recherche. Le bouton de téléchargement payant existait bien dans l’interface, mais il ne protégeait rien : il suffisait de contourner l’interface pour récupérer le fichier.

Rien ne le signalait tant que personne ne cherchait, et le modèle payant du site ne tenait que sur cette ignorance.

Les contraintes

• La consultation doit rester entièrement libre, y compris pour les visiteurs sans compte. C’est une décision du client, et elle est structurante : on ne peut pas simplement tout fermer.
• Un budget associatif, qui exclut les solutions coûteuses de gestion de droits numériques.
• Un espace communautaire à modérer, avec les responsabilités qui accompagnent l’hébergement de contenus publiés par des tiers.
• Des contributeurs non techniques, qui doivent pouvoir publier sans assistance.

Mon intervention

Développement du site, conception du modèle de données et des règles d’accès, reprise de la sécurité du stockage, mise en place de l’espace membres et des outils de modération.

L’architecture

Le site est statique par défaut, avec des îlots dynamiques là où l’interaction l’exige : authentification, forum, profils, publication d’oeuvres. Les données et les fichiers vivent dans une base et un stockage hébergés.

Le coeur du sujet est le contrôle d’accès en base, activé au niveau des lignes. Chaque table porte ses propres règles : qui peut lire, qui peut écrire, qui peut supprimer. Un membre modifie son profil et pas celui des autres, un auteur ou un modérateur supprime un contenu, le reste est refusé par la base elle-même et non par l’interface.

Les règles sont donc portées par la base et non par l’interface, pour qu’elles s’appliquent aussi à qui n’utilise pas l’interface.

Les choix techniques

Le stockage est passé de public à privé, ce qui a invalidé toutes les adresses permanentes déjà diffusées. La lecture se fait désormais par liens temporaires signés, générés à la demande et périmés au bout d’un court délai. La consultation reste donc libre pour tout le monde, y compris les visiteurs anonymes, mais il n’existe plus d’adresse durable qui circule.

Le droit de télécharger est arbitré par l’application selon que l’oeuvre est gratuite ou payante.

La sécurité

Il y a ici une limite que je documente explicitement dans le code et que j’ai exposée au client.

Cette protection est une barrière douce. Ce que le navigateur peut afficher ou lire, il peut le capturer. Une image consultable peut être copiée depuis l’écran, un morceau écoutable peut être enregistré. La seule protection réellement dure consisterait à ne diffuser publiquement qu’une version dégradée et à ne vendre que l’original. Ce modèle a été écarté pour l’instant, en connaissance de cause.

Ce que le correctif change concrètement, et ce n’est pas rien : il n’existe plus de lien direct permanent vers un fichier, donc plus de partage massif d’une adresse, plus d’indexation par les moteurs de recherche, et plus de récupération triviale par contournement de l’interface.

Le résultat

Les fichiers d’oeuvres ne sont plus accessibles publiquement. Le site dispose d’un espace membres, d’un forum avec outils de modération, et de règles d’accès appliquées en base.

Le paiement en ligne n’est pas encore actif à ce jour, pour des raisons administratives extérieures au projet.

Ce que ce projet démontre

La capacité à reprendre un existant, à identifier le défaut qui compte parmi ceux qui ne comptent pas, et à le corriger sans casser le fonctionnement voulu par le client. La demande initiale ne portait pas sur la sécurité : c’est en regardant comment les fichiers étaient servis que le problème est apparu.

Cette réalisation illustre aussi une constante de ma manière de travailler : je documente les limites de ce que je livre, dans le code lui-même, à l’intention de celui qui passera après moi.