L'archive chronologique du jeu vidéo
CODEX Chronique
Archive qui reconstitue la chronologie complète des licences de jeu vidéo : chaque événement daté, sourcé et remis dans l'ordre où il s'est produit, plutôt que dans l'ordre de sortie des jeux.
Le projet
Une licence de jeu vidéo s'étale sur quinze à vingt-cinq ans, change de studio en route, sort ses épisodes dans le désordre et déporte des pans entiers de son récit dans des romans, des comics ou des enregistrements audio cachés. Le joueur reçoit donc une histoire en morceaux, dans un ordre qui n'est pas le sien. CODEX remet ces morceaux dans l'ordre où ils se sont produits.
Le site ne résume pas les jeux : il date les événements, les rattache à la source qui les atteste et les relie entre eux. Ce qu'une œuvre laisse en suspens est consigné au même titre que le reste, dans des fiches appelées « zones d'ombre ».
L'archive est en cours de constitution : 6 éditeurs, 29 licences et 199 œuvres sont référencés, le relevé événement par événement ne fait que commencer. La progression est montrée plutôt que masquée — une licence dont la chronologie n'a pas démarré figure quand même, avec l'écart bien visible.
Fonctionnalités
- Quatre portes d'entrée dans l'archive : par éditeur, par licence, par œuvre ou par zone d'ombre
- Page d'œuvre qui calcule seule ce qu'il faut savoir avant de lancer un jeu, au lieu de le faire saisir à la main
- Fiches d'événement sourcées, avec les questions laissées ouvertes suivies une par une
- 252 pages statiques pré-générées au build, sans aucune requête au chargement
- Documentation intégralement bilingue français / anglais
Les difficultés rencontrées
La première modélisation rattachait chaque événement au jeu qui le met en scène. Elle tenait tant qu'un événement n'apparaissait que dans un seul jeu, puis dupliquait tout dès qu'une licence revenait sur son passé : le même fait existait en trois exemplaires, avec trois dates à maintenir. J'ai inversé la relation. Un événement appartient désormais à la chronologie de sa licence, et une œuvre n'est qu'une fenêtre ouverte dessus. Lire un jeu isolé ou une licence entière puise dans les mêmes données sans rien recopier, et c'est ce qui permet au site de calculer les prérequis d'un jeu au lieu de me les faire saisir.
Le contenu est du TypeScript, pas une base de données. Le choix vient d'un besoin qu'une base ne sait pas couvrir : un renvoi vers une œuvre inexistante devient une erreur de compilation, et non une requête qui ne renvoie rien en production. Le prix est réel — pas d'interface d'administration, il faut un éditeur et un build pour ajouter une entrée — mais sur un projet où chaque fiche demande des heures de vérification, le goulot n'est pas là.
Ce que j'en ai retiré
- Le modèle de données se choisit sur ce que le contenu fait réellement, pas sur ce qu'il a l'air d'être au premier coup d'œil : ma première version était intuitive et fausse.
- Le typage peut valider du contenu, pas seulement du code : le build refuse de passer sur une référence cassée.
- Une dépendance ajoutée est une chose qui peut casser un build dans deux ans. Le projet tient sur trois dépendances d'exécution, et c'est un budget assumé, pas un hasard.
- Afficher ce qui manque plutôt que le cacher : montrer l'écart entre une licence et ce qui en est consigné rend l'archive honnête et me sert de feuille de route.