Playstables : maintenir un projet après la liquidation

De 2022 à 2025, nous avons assuré la direction technique de Playstables — Stables —, une plateforme communautaire menée pour le PMU à la croisée des courses hippiques et des actifs numériques. Chaque cheval, sous forme de jeton, correspondait à un véritable cheval de course : les joueurs constituaient leur écurie, entraînaient leurs chevaux et les engageaient dans des courses. Le lancement, début 2023, avait été largement commenté.

Le projet s’est arrêté. Restait une question que presque personne ne se pose au lancement : que fait-on de ce qui survit ?

Ce qui survit, et ce qui meurt#

Un service en ligne qui ferme emporte tout ce qui vivait dans sa base de données. Les comptes, les scores, les historiques, les messages : hors sauvegarde, il n’en reste rien, et personne ne les réclame.

Les jetons inscrits sur une chaîne publique, eux, ne s’éteignent pas. Ils restent dans le portefeuille de leur détenteur, indéfiniment, sans que personne — ni l’éditeur, ni le liquidateur, ni le détenteur lui-même — puisse les faire disparaître.

C’est ici que se trouve le malentendu le plus répandu sur ces actifs. Le jeton n’est pas l’objet : c’est une référence vers l’objet. Dans l’immense majorité des projets, ce que le jeton désigne — l’image du cheval, ses caractéristiques, sa description — est servi par un serveur tout à fait ordinaire, à une adresse tout à fait ordinaire.

Éteignez ce serveur, laissez expirer le nom de domaine, et il reste ceci : une propriété incontestable sur une référence qui ne pointe plus vers rien. L’actif est intact et vide.

Le risque que personne n’anticipe#

Il y a plus gênant qu’un jeton vide.

Un nom de domaine ne se met pas en sommeil. Passé sa période de restitution, il retombe dans le domaine public et se rachète dans la journée. Or celui d’un projet arrêté a trois propriétés qui en font une cible remarquable :

• il est connu d’une communauté identifiée ;
• cette communauté détient des portefeuilles ;
• ses membres attendent, par construction, des nouvelles du projet.

Un site remontant à cette adresse, reprenant l’apparence d’origine et annonçant une « migration des actifs » ou une « compensation des détenteurs », n’aurait aucun mal à convaincre. Ce scénario n’est pas théorique : c’est un mode opératoire courant, et il ne demande qu’un domaine expiré.

Laisser mourir le domaine d’un projet arrêté, ce n’est pas économiser quelques dizaines d’euros. C’est transformer un projet clos en risque pour ses anciens utilisateurs. Nous avions décrit ce mécanisme d’expiration et son irréversibilité en écrivant sur le prestataire injoignable ; ici, l’enjeu n’est plus la continuité d’un site, c’est la sécurité de gens qui ne sont plus clients de personne.

Ce que nous avons proposé#

Notre rôle s’arrêtait avec le projet. Nous avons proposé qu’il ne s’arrête pas complètement, sur trois points précis :

Maintenir le nom de domaine. C’est le geste le moins cher et le plus utile. Tant qu’il est détenu, il ne peut pas être repris. Le maintenir suppose seulement que quelqu’un en assume le renouvellement et surveille la date d’expiration — c’est-à-dire très peu, à condition que ce soit décidé et attribué.

Conserver ce qui donne un sens aux actifs. Les métadonnées et les images désignées par les jetons ne pèsent presque rien, et ce sont elles qui font la différence entre un actif lisible et une coquille. Les figer sous forme de fichiers, servis statiquement, coûte quelques euros par an et n’exige aucune maintenance : c’est exactement le genre de charge qu’une architecture statique permet de porter pendant des années sans y penser.

Archiver le reste, une fois. Le code, la configuration, la documentation, les sauvegardes. Non pas pour les exploiter, mais pour pouvoir répondre à une question dans deux ans — et il y a toujours une question dans deux ans.

Pourquoi nous avons construit Archivum#

Ce troisième point revient si souvent que nous en avons fait un service.

Archivum répond à une question rarement posée : que deviennent les fichiers, les sites et les courriels d’une organisation qui ferme ? C’est d’abord notre propre outil d’archivage de projets techniques — la mémoire numérique que l’on conserve, puis dont on arbitre le devenir.

L’usage interne n’est pas une coquetterie. Un service d’archivage dont l’éditeur n’archive rien lui-même n’a aucune raison d’être cru. Et c’est en l’utilisant pour nos projets clos que nous mesurons ce qu’on oublie systématiquement de conserver : non pas le code, qu’on sauvegarde par réflexe, mais le contexte — pourquoi telle décision, à quel nom tel compte, quel prestataire pour quel morceau.

Ce que tout projet devrait écrire au démarrage#

Aucun cahier des charges ne contient de section sur la fin du projet. C’est pourtant quelques lignes, et elles n’ont jamais coûté un euro :

1. Qui détient le nom de domaine, et qui en assume le renouvellement si la structure disparaît.
2. Où sont les sauvegardes, sous quel format, et jusqu’à quand elles sont conservées.
3. Ce qui doit rester accessible aux utilisateurs après l’arrêt du service, et à quel coût annuel.
4. Qui décide, et à quel moment on informe les utilisateurs.

Ajoutons-en une cinquième pour les projets manipulant des données personnelles : leur sort ne s’éteint pas avec l’activité. Le règlement continue de s’appliquer à des données qui n’ont plus de responsable désigné, ce qui est précisément la situation qu’il faut éviter de créer.

Ce que nous en retenons#

Un projet qui s’arrête n’est pas un échec — les paris audacieux ont le droit de ne pas aboutir, et celui-ci nous a beaucoup appris.

Ce qui serait un échec, ce serait de le laisser s’arrêter mal : un domaine récupéré par un tiers, des actifs devenus illisibles, une communauté livrée à elle-même. La différence entre les deux ne tient pas à des moyens, elle tient à une décision — et à quelqu’un qui accepte de la porter après que tout le monde est parti.

C’est, au fond, la partie la moins spectaculaire du métier, et l’une de celles dont nous sommes le plus satisfaits.