Concevoir autour de données qu'on ne possède pas

Le jour où j'ai commencé à structurer la base de données de mon outil, une question m'a arrêté net : qui est propriétaire de ce que je suis en train de modéliser ? Mon projet est un compagnon pour un MMO existant, pas un jeu original. Les classes, les sorts, les objets, les zones, tout ce contenu vient d'un éditeur qui ne m'a rien cédé. Je peux écrire tout le code que je veux, ce code m'appartient, mais les données qu'il manipule ne sont pas les miennes. Cette phrase toute simple a fini par gouverner la moitié de mes décisions d'architecture.

Le code et les données ne sont pas la même chose

C'est une confusion que je vois souvent, y compris chez moi au début : on ouvre un dépôt sous licence libre et on suppose que tout ce qu'il contient est couvert par la même liberté. Ce n'est pas vrai.

Le code

Une licence comme l'AGPLv3 porte sur le code, sur l'architecture logicielle, sur la manière dont j'ai organisé mes services et mes composants. Elle donne à quiconque le droit de reprendre mon travail d'ingénierie, de le modifier, de le redéployer, à condition de partager les modifications. C'est une licence pensée pour du logiciel qu'on a écrit soi-même.

Les données

Dans mon dépôt cohabitent aussi des fichiers qui décrivent le contenu du jeu : noms de compétences, statistiques, textes descriptifs, parfois des identifiants d'assets graphiques. Rien de tout cela n'est mon travail créatif. Je ne les ai pas inventés, je ne les ai pas dessinés, je n'ai fait que les organiser pour qu'un site web puisse les afficher.

Les placer dans le même dépôt que mon code ne les fait pas basculer sous ma licence. Ce sont deux régimes juridiques distincts qui partagent le même espace de stockage, et rien de plus. Traiter cette cohabitation comme une fusion, c'est le genre d'erreur qui a l'air anodine jusqu'au jour où elle ne l'est plus.

Ce qui m'a aidé, concrètement, c'est de matérialiser cette frontière dans la structure même du projet plutôt que de la garder comme une intention floue. Un dossier pour le code, clairement documenté comme libre. Un espace distinct, avec ses propres règles d'accès, pour tout ce qui provient de l'éditeur. La séparation physique force la séparation mentale, et elle rend visible à toute personne qui contribue au projet ce qu'elle a le droit de redistribuer et ce qu'elle n'a pas le droit de toucher.

Dire clairement qui on n'est pas

Un projet fan qui fonctionne bien commence par admettre publiquement ce qu'il n'est pas. Ce n'est pas une formalité qu'on ajoute en bas de page pour se couvrir, c'est une posture honnête envers les joueurs qui utilisent l'outil. Une mention de non-affiliation, un disclaimer visible, une page de mentions légales qui explique la nature du projet : tout cela sert à éviter la confusion entre l'éditeur du jeu et un outil communautaire indépendant. Je préfère qu'un joueur comprenne dès la première visite qu'il utilise un projet de fan, construit sans lien officiel avec le studio qui a créé le jeu, plutôt que de laisser planer une ambiguïté qui profiterait à court terme à ma crédibilité perçue.

Pourquoi la transparence protège

Cette transparence a aussi un effet pratique : elle clarifie, en cas de désaccord avec l'éditeur, que je n'ai jamais prétendu parler en son nom ni me faire passer pour lui. Un projet qui joue la transparence dès le départ négocie depuis une position plus saine qu'un projet qui a laissé croire à une proximité qu'il n'avait pas.

Deux niveaux de données, pas un seul

La question qui suit naturellement est celle de la diffusion. Tout ce que je stocke en interne n'a pas vocation à être rediffusé publiquement dans son intégralité. J'ai fini par concevoir deux couches de données distinctes.

Couche interne

Complète, elle me sert à faire fonctionner les calculs et les recommandations de l'outil.

Couche publique

Filtrée, elle ne montre que ce qui est nécessaire à l'usage réel du site, sans exposer de jeux de données bruts qui pourraient être aspirés et redistribués ailleurs sous une autre forme.

Ce n'est pas une architecture compliquée à mettre en place si on y pense dès le départ. C'est en revanche difficile à corriger après coup, quand une API publique expose déjà tout par habitude.

Ma règle

Par défaut, rien ne sort tant que je n'ai pas décidé consciemment que cela devait sortir.

La version qui fuit

Tout exposer, puis fermer au cas par cas : la version qui finit toujours par laisser filer quelque chose qu'on regrette.

Des comptes utilisateurs, donc des obligations

Il y a un dernier point qu'on oublie facilement parce qu'il ne concerne pas l'éditeur du jeu mais les utilisateurs eux-mêmes. Dès qu'un projet fan propose des comptes, une sauvegarde de préférences, un historique de builds ou de personnages, il traite des données personnelles. Le statut de projet non commercial ou amateur ne dispense de rien face au RGPD.

Export: Droit pour l'utilisateur de récupérer ses propres données.
Suppression: Droit de les faire effacer.
Minimisation: Ne collecter que ce qui est réellement nécessaire.
Base légale: Une justification claire pour chaque traitement.

Ces obligations s'appliquent que le projet soit porté par une société ou par une seule personne dans son temps libre.

J'ai pris l'habitude de traiter cette question comme partie intégrante de la conception, pas comme une case à cocher juridique ajoutée plus tard. Une section de compte qui permet à l'utilisateur de voir et supprimer ses propres données coûte peu à construire dès le départ, et coûte cher à ajouter après coup sur une base d'utilisateurs déjà installée.

Ce que ça change dans ma façon de penser

À retenir

Construire sur des données qu'on ne possède pas ne devrait pas être traité comme un détail légal qu'on règle après avoir codé. C'est une contrainte de conception au même titre que la performance ou la sécurité. Séparer ce qui est à moi de ce qui est emprunté, l'afficher publiquement, ne diffuser que ce qui doit l'être, et respecter les données des utilisateurs autant que celles de l'éditeur : ce sont des garde-fous qu'on pose avant d'écrire la première ligne de schéma, pas des correctifs qu'on ajoute quand quelqu'un s'en plaint. Un projet fan qui dure est un projet qui sait, à chaque instant, ce qui lui appartient et ce qui ne lui appartient pas.