Pendant environ dix-huit mois, j’ai dirigé la refonte complète d’un outil connecté aux serveurs de Star Citizen. Utilisé localement par les développeurs du jeu et en production par les Game Masters et le support, il devait réunir de nombreuses sources de données tout en restant simple à étendre.
Un outil branché sur le jeu
Live Tools était un outil interne directement connecté aux serveurs du jeu. Les développeurs de Star Citizen l’utilisaient en local pour vérifier que les événements et les données attendus apparaissaient correctement. En production, les Game Masters et le support s’en servaient pour comprendre une situation et agir sur les données d’un joueur.
L’interface suivait le contexte sélectionné. Un identifiant de joueur présent dans une table pouvait ouvrir une nouvelle fenêtre avec sa fiche, les données associées et les actions disponibles. Plusieurs fenêtres et panneaux pouvaient rester visibles pour naviguer entre un joueur, un groupe, un lobby ou une autre entité.
Repenser le socle et les usages
La refonte devait remplacer l’application existante par une base plus intuitive et plus simple à étendre. Le backend du jeu exposait de nombreux services et flux gRPC, alors que chaque écran frontend avait besoin d’une vue cohérente des données utiles à son contexte.
Il fallait aussi éviter que l’ajout d’une source de données ou d’un composant demande de reconstruire une intégration spécifique. La nouvelle version devait absorber cette variété dans un cadre commun, tout en restant utilisable pour du debug local et des opérations en production.
Mon périmètre de lead
J’ai dirigé le travail de deux développeurs frontend. Je faisais les revues de code, définissais la direction technique et participais aux priorisations produit ainsi qu’aux choix de design de l’interface.
J’ai porté l’architecture de la refonte : monorepo, micro-frontends avec Module Federation, GraphQL BFF, packages UI et Data, génération des hooks Apollo et système déclaratif de modules. La version était nouvelle, puis sa livraison a été sécurisée progressivement par la QA et par des déploiements locaux utilisés par les développeurs du jeu.
Une architecture guidée par le contexte
Agréger gRPC derrière un GraphQL BFF
Le backend du jeu restait organisé autour de services gRPC. J’ai mis en place une gateway GraphQL qui agrégeait leurs flux et présentait au frontend un contrat adapté à ses écrans. Le package Data centralisait Apollo, les types et la génération automatique des hooks.
Déclarer un module plutôt que recâbler une interface
Le système de modules associait de manière déclarative une source de données, un contexte et un composant. Une équipe pouvait ajouter une nouvelle datasource et son interface sans reproduire toute la plomberie nécessaire pour les connecter.
Faire du contexte un élément de navigation
Les fenêtres et les panneaux partageaient le contexte sélectionné. Cliquer sur une donnée comme player_id ouvrait les vues et actions disponibles pour ce joueur. Cette organisation rendait les relations entre données directement explorables depuis l’outil.
Une livraison pour des usages réels
Les développeurs pouvaient vérifier localement les événements et les données attendus. En production, les Game Masters et le support pouvaient ouvrir les vues liées à un joueur dans le même outil pour traiter une situation.
Ajouter une source ou un module passait par la déclaration d’un contexte, d’un flux et d’un composant, plutôt que par une nouvelle intégration spécifique.
L’héritage pour l’équipe suivante
La partie la plus durable du travail a consisté à transformer des besoins très différents en règles d’extension explicites. L’équipe suivante pouvait ajouter une source ou une action sans reconstruire l’écran.