Skip to content
← Retour au blogue

10 juillet 2026 · 6 min de lecture

Moderniser Cyberline Racing : cinq versions d’Unity et un nouveau backend

Comment nous avons fait passer un jeu de course et de combat d’un build Unity vieux de dix ans, au backend mort, à un code moderne et maintenable.

Cyberline Racing est un jeu de course et de combat motorisé pour Android, développé à l’origine par Magicindie Softworks. aIPc Soft le maintient et le publie désormais, et le remettre en forme a été un véritable projet de modernisation. Voici en quoi ce travail consiste réellement, car c’est une situation courante : un bon produit bâti sur une technologie que le temps a laissée derrière.

Le point de départ

Le jeu est arrivé sous la forme d’un grand projet Unity : des centaines de scripts de gameplay, neuf circuits, une économie de garage et d’améliorations, des achats intégrés, des publicités récompensées et de la sauvegarde infonuagique. Sur le plan des mécaniques, il était solide et amusant. Techniquement, il était bloqué : il reposait sur une très ancienne version d’Unity, et son backend en ligne tournait sur un service (App42) devenu inactif. Les sauvegardes infonuagiques et les fonctions connectées n’avaient plus rien à quoi se raccrocher.

On ne peut pas publier cela sur une boutique moderne, ni le rafistoler. Il fallait une véritable modernisation.

Gravir l’échelle d’Unity

On ne peut généralement pas faire franchir à un projet Unity plusieurs versions majeures d’un seul bond : des API disparaissent, le rendu change, des plugiciels cassent. Nous avons donc monté l’échelle une version prise en charge à la fois : Unity 5 → 2017 → 2018 → 2019 → 2020.3, avec l’objectif d’atteindre une version LTS actuelle avant la publication.

À chaque étape, nous corrigions ce que la version cassait, vérifiions que le jeu fonctionnait toujours, puis seulement alors passions à la suivante. C’est plus lent qu’il n’y paraît, mais c’est la seule manière fiable de garder un grand projet fonctionnel à travers une décennie d’évolutions du moteur. Tout au long, nous validions sur un appareil réel plutôt que de nous fier à l’éditeur.

Remplacer un backend mort

L’ancien backend App42 n’allait pas revenir; nous en avons donc bâti un nouveau, à partir de zéro, sur une pile moderne, sobre et fiable : Java 21, Spring Boot 3.3 et MongoDB. Il gère les composantes en ligne dont le jeu a besoin, sur une infrastructure que nous contrôlons et pouvons maintenir. Le nouveau backend est entré en service en juillet 2026.

La leçon

Ancien ne veut pas dire sans valeur. Beaucoup de logiciels précieux sont prisonniers de vieux environnements : jeux, outils internes, applications que des clients utilisent encore. Le travail est ingrat : migrer avec soin, vérifier sans cesse, et remplacer les parties abîmées par quelque chose de réellement maintenable.

Si vous avez un produit dans cette situation, qui fonctionne mais reste coincé sur une vieille technologie, c’est exactement le genre de problème que nous prenons en charge.

Vous avez un projet en tête?

Dites-nous ce qu’il vous faut : un site web, une application, une image de marque, un menu. Nous répondons en 1 à 2 jours ouvrables.

Entamer la conversation