Le RSI Launcher permet d’installer, mettre à jour et lancer Star Citizen. Chez Turbulent, j’ai participé à la maintenance de la première version avant de devenir Lead Développeur sur la V2. J’ai porté son architecture frontend, sa migration, son socle de développement et son design system avec une équipe de quatre à cinq développeurs.
Un point d’entrée critique
Le launcher se trouve entre le joueur et le jeu. Il gère l’installation, les mises à jour, plusieurs environnements, l’état des services et les réglages nécessaires avant le lancement.
Cette position rend les problèmes immédiatement visibles. Une erreur de téléchargement, une mise à jour instable ou une information ambiguë peut empêcher l’accès au jeu. La fiabilité et la compréhension de l’interface comptent autant que l’ajout de nouvelles fonctions.
Il fallait donc refondre l’existant : consolider ce qui fonctionnait, traiter les points de friction des utilisateurs et améliorer leur expérience, sans partir d’une feuille blanche.
Passer de la V1 à la V2
La modernisation devait se faire sur une application existante, avec un historique technique et des versions déjà utilisées. Une réécriture complète aurait concentré trop de risques dans une seule livraison.
Le travail consistait à réduire la fragilité d’une base JavaScript historique, partager les composants et les conventions, suivre les évolutions majeures d’Electron et continuer à livrer. Il fallait aussi maintenir l’intégration avec un moteur natif C++ central pour le téléchargement, la vérification et la mise à jour du jeu, tout en coordonnant plusieurs équipes réparties sur différents fuseaux horaires.
Ma responsabilité sur la V2
Après avoir contribué à la maintenance de la V1, j’ai été Lead Développeur sur la V2. J’ai défini l’architecture frontend, préparé la migration, mis en place le socle du projet et accompagné une équipe de quatre à cinq développeurs. La livraison était collective, mais la direction technique et la cohérence d’ensemble faisaient partie de mes responsabilités.
Je travaillais notamment sur la migration TypeScript, l’architecture du monorepo, le design system, les échanges entre Node.js et le moteur natif C++, ainsi que sur plus de dix montées de version majeures d’Electron. L’objectif était de rester proche d’une version actuelle du runtime au printemps 2023, sans interrompre les livraisons du produit.
Moderniser sans interrompre le produit
Migrer progressivement vers TypeScript
Le passage à TypeScript a été traité comme une évolution de la base active. Les zones modifiées pouvaient être typées au fil du travail, sans bloquer les autres livraisons dans l’attente d’une conversion complète.
Organiser le code en monorepo
Le monorepo a rapproché les parties du produit qui devaient partager leurs outils, leurs types et leurs composants. L’objectif n’était pas de centraliser par principe, mais de rendre les dépendances et les conventions plus explicites.
Construire un design system utilisable par le produit
Le design system devait réduire les variations inutiles et rendre les nouveaux écrans plus cohérents. Il ne remplaçait pas les décisions produit. Il fournissait une base commune pour les composants, les états et les comportements récurrents.
Faire évoluer Electron sans arrêter le produit
Les montées de version d’Electron demandaient de suivre les changements de runtime, de dépendances et de sécurité sans perdre les comportements attendus du launcher. Elles ont été intégrées comme des évolutions régulières plutôt que repoussées jusqu’à devenir un chantier isolé.
Stabiliser la frontière avec le moteur natif
Le téléchargement et la mise à jour du jeu reposaient sur un moteur C++ central. L’application Electron devait échanger avec lui à travers des bindings Node.js sans exposer cette complexité dans l’interface. Cette frontière demandait des contrats explicites, des états d’erreur compréhensibles et une coordination étroite avec les autres équipes.
Une base prête pour la suite
L’équipe frontend a livré l’ensemble de l’expérience visible de la V2 sur une architecture conçue pour évoluer. Le projet a adopté TypeScript, une organisation monorepo et un design system commun, tandis que la base Electron continuait de progresser. Le launcher concernait alors plus d’un million d’utilisateurs.
Launcher 2.0 propose une gestion plus complète des téléchargements, des environnements et de l’état des services. Les captures publiques présentées ici illustrent le produit et son contexte, pas une réalisation individuelle.
Travailler au rythme d’un produit vivant
Le point difficile était l’ordre des changements. TypeScript, Electron, le monorepo et le design system devaient avancer sans créer une longue période où le produit serait impossible à livrer.
Les choix techniques prenaient leur sens dans le rythme quotidien de l’équipe et dans la fiabilité attendue par les joueurs.