Quests, c’est une application que j’ai imaginée après la Gamers Assembly 2025. L’idée : donner aux participants d’un événement gaming une raison de bouger, de se parler, de découvrir les stands autrement — via des quêtes, des tokens, un classement qui vit en temps réel. Sauf qu’une appli qui tourne sur un salon grand public, ça veut dire des centaines de comptes, des photos, des pseudos, des interactions, et une partie du public qui a moins de quinze ans. Beaucoup de données personnelles, donc, et un cadre légal qui ne se discute pas. Je voulais partager comment j’ai traité ça, parce que c’est le genre de sujet qu’on repousse et qu’on paye cher ensuite — et parce qu’au départ, je n’y connaissais rien.
Partir de zéro sur le RGPD
Autant être honnête : quand j’ai commencé, mes connaissances en protection des données tenaient sur un post-it. Comme beaucoup de développeurs, je savais qu’il « fallait être conforme » sans trop savoir ce que ça voulait dire concrètement dans le code.
J’ai passé plusieurs semaines là-dessus avant d’écrire les parties sensibles. Concrètement : poser les mêmes questions à Claude, ChatGPT et Codex, puis confronter leurs réponses entre elles pour repérer ce sur quoi elles convergeaient et ce qui méritait vérification. Aller lire directement les ressources de la CNIL et le texte du RGPD quand un point restait flou. Interroger aussi des IA spécialisées en droit pour des questions précises, sachant qu’aucune de ces réponses ne remplace un avis juridique, mais qu’elles aident à cadrer les bonnes questions. À partir de tout ça, j’ai construit des plans — un par axe : minimisation, mineurs, droits des personnes, durées de conservation, sécurité — et je les ai éprouvés un par un contre les cas concrets de l’appli, pour vérifier qu’aucun angle ne passait à travers.
Ce n’est pas la démarche d’un juriste, et je ne prétends pas l’être. C’est celle d’un dev qui prend le sujet au sérieux, croise ses sources, et préfère se tromper en étant trop prudent.
Pourquoi je n’ai pas remis ça à plus tard
Quand tu construis une appli de quêtes pour un événement, tu te retrouves vite avec plusieurs types de données à gérer : le pseudo affiché, parfois une photo de profil, les preuves de quêtes que les gens envoient (souvent des photos, parfois des audios), les interactions entre participants, la progression, le classement. Pris un par un ça paraît inoffensif. Rapporté à des centaines de personnes réunies deux jours, dont des mineurs, ça ne l’est plus.
Le RGPD demande des choses simples à dire et pénibles à tenir : ne garder que ce qui sert, pour une raison claire, pendant une durée limitée, avec une base légale[1], et en laissant aux gens la main sur leurs infos. Et dès qu’il y a des mineurs, la CNIL attend un niveau de vigilance supérieur[2].
La tentation, sur un projet perso mené vite, c’est de se dire qu’on verra la conformité « quand ce sera stable ». Le problème, c’est que la conformité touche à la façon dont tu modélises tes données. Revenir dessus après coup, c’est reprendre le schéma, les relations, la moitié des requêtes. C’est d’ailleurs une des premières choses qui est ressortie de mes recherches, et la raison pour laquelle j’ai attaqué le sujet avant le code : autant traiter ça comme une contrainte d’archi, au même titre que la perf ou l’UX.
Commencer par ce qu’on ne stocke pas
Le premier réflexe, c’était de lister ce que l’appli allait refuser de garder, avant même de lister ce qu’elle allait enregistrer.
Ça a donné quelques décisions nettes, résumées ici par ce que l’appli garde et ce qu’elle refuse délibérément :
| On garde | On ne garde pas |
|---|---|
| Un pseudo et une identité de jeu | Le nom réel du participant — inutile pour avancer dans une quête |
| Une connexion via un compte que la personne a déjà (Discord, Google, Apple), avec le minimum d’infos pour ouvrir une session | Un nouveau couple identifiant / mot de passe à créer, stocker et protéger |
| Des preuves de quête prises sur place (photo, audio) liées à l’événement | Un espace de partage libre de contenus personnels |
| Une position, un pseudo, un score dans le classement | Toute information qui exposerait davantage un participant que nécessaire |
Le principe qui tient tout ça ensemble : moins tu gardes de données sensibles, moins tu as de surface à défendre.
À chaque fois que j’hésitais à garder un champ, je me posais la même question : à quoi il sert, précisément, dans le déroulé d’une quête ou d’un classement ? Quand je n’avais pas de réponse claire, le champ dégageait.
Le vrai sujet : les mineurs
C’est la partie qui m’a demandé le plus de conception. Un événement gaming, il y a des ados, parfois des enfants avec leurs parents. Les laisser s’inscrire et participer comme tout le monde, ce n’était pas possible.
Le principe que j’ai retenu, c’est qu’un compte de mineur n’existe jamais seul. Il est rattaché à un adulte, et c’est cette supervision qui débloque l’accès aux fonctionnalités. L’âge déclaré range le compte dans un groupe, et le groupe décide de ce qui est ouvert ou fermé par défaut.
Par défaut, sur un compte supervisé, il n’y a aucune visibilité publique : le profil n’apparaît pas dans les galeries communautaires ni dans les espaces où les participants se découvrent entre eux. Les interactions sociales sont coupées, et l’adulte ne peut les rouvrir que fonctionnalité par fonctionnalité, s’il le souhaite. La personnalisation du profil est bridée — je n’allais pas mettre un enfant en position de publier librement une photo ou une bio. Et sa présence au classement peut être désactivée.
Concrètement, l’expérience d’un mineur est plus pauvre en exposition. C’est volontaire. L’adulte qui supervise peut l’élargir, mais tant qu’il ne fait rien, tout reste fermé.
Un point qui n’était pas évident au début, et qui est ressorti de mes lectures côté CNIL[2] : il ne suffit pas de savoir qu’une personne a coché « oui ». Il faut pouvoir dire quand, et à quelle version des conditions ça se rapporte. Si on me demande un jour de prouver un consentement donné six mois plus tôt, sans cette trace c’est infaisable — et l’ajouter après coup sur des comptes déjà créés est bien plus lourd que de le prévoir dès le départ. C’est typiquement le genre de détail qu’on ne voit pas venir tant qu’on n’a pas creusé le sujet.
Les droits des personnes, comme des fonctions du produit
Le RGPD garantit à chacun de pouvoir accéder à ses données, les corriger, s’opposer à un traitement, demander leur suppression. Sur beaucoup de petites applis, ces droits existent sur le papier mais se règlent, en vrai, avec un mail traité à la va-vite.
Je voulais que ces demandes soient des objets à part entière dans l’appli. Une rectification, une opposition, une suppression, c’est enregistré, suivi, traité via un parcours dédié côté admin, avec une trace de comment ça s’est résolu. L’objectif n’est pas juste de répondre dans le mois : c’est de pouvoir montrer, si on me le demande, comment chaque demande a été prise en charge.
Ça oblige aussi à connaître sa base par cœur. Pour chaque donnée, savoir où elle est, à qui elle se rattache, et ce que ça casse si on la supprime. Un droit à l’effacement, ça ne vaut quelque chose que si le schéma te permet de l’exécuter proprement, sans laisser des lignes orphelines partout.
Ce que deviennent les données après l’événement
Une appli événementielle a une particularité : elle sert un événement, puis l’événement se termine. Et là, la question, c’est : qu’est-ce qu’on garde ?
J’ai séparé deux choses. D’un côté, tout ce qui relève du jeu et de l’édition — scores, progressions, soumissions de quêtes et médias associés, classements, interactions, participations. Ça a une durée de vie liée à l’événement. Après la clôture, ça part dans une remise à zéro encadrée, tracée, que je déclenche volontairement. De l’autre, ce qui relève du compte et de la conformité — le compte lui-même, les rôles, les consentements parentaux, les journaux de supervision, les demandes adressées au responsable de traitement. Ça, on le garde au-delà de l’édition, parce que ça répond à d’autres obligations : pouvoir rouvrir un compte, prouver un consentement, documenter une demande.
Chaque remise à zéro laisse une trace : quand, pourquoi, combien de lignes concernées. Et je peux la simuler avant de l’exécuter pour vérifier ce qu’elle va toucher. L’idée est toujours la même : nettoyer ce qui n’a plus lieu d’être là, et pouvoir en rendre compte.
Ce que j’en retire
Trois choses, surtout.
La conformité, c’est de l’architecture, pas du vernis qu’on applique à la fin. Les décisions qui coûtent cher, ce sont celles du début : comment tu modélises l’identité, comment tu relies un mineur à un adulte, comment tu sépares ce qui est public de ce qui ne l’est pas. Prises en amont, elles ne coûtent presque rien.
La traçabilité compte autant que l’action. Supprimer une donnée, c’est bien. Pouvoir dire quand et pourquoi tu l’as fait, c’est ce que le cadre légal attend vraiment.
Et restreindre par défaut, quitte à ouvrir ensuite, évite l’essentiel des mauvaises surprises. Pour les mineurs comme pour la visibilité des profils, partir d’un accès fermé qu’on élargit au cas par cas, c’est beaucoup plus sûr que l’inverse.
La V2 continue dans cette direction : une repasse complète sur les durées de conservation en suivant les référentiels de la CNIL[3], un traitement à part pour les données de visiteurs et leurs statistiques, et un test grandeur nature de la clôture sur plusieurs éditions pour vérifier que ce qui se passe est bien ce que j’ai prévu.
Quests est un projet BS Studio, déployé pour la première fois à la Gamers Assembly 2026. La fiche du projet.