Prototype CyberScale — console de migration

Sortir Sporteo de Lovable, sans perdre une fonctionnalité.

Atlas est la console qui pilote la migration. Elle montre l'audit écran par écran, l'avancement par lots vers un code versionné sur GitHub, l'architecture multi-locataires prête pour la marque blanche, et l'application mobile installable sans store.

12

écrans audités

33 j

de charge chiffrée

5

failles à traiter en priorité

39 %

de la migration réalisée

Le point de départ

Lovable · React + TypeScript + Supabase

34 clubs, 8 420 membres et 11 960 réservations par mois en production.

La cible

Next.js + TypeScript + PostgreSQL · dépôt GitHub sporteo/sporteo-web

Code versionné, documenté, déployé automatiquement, reprenable par n'importe quel développeur.

Le métier

Réservation de créneaux pour clubs de sport

3 espaces de marque déjà prévus sur le même code, dont un en préparation.

4 interfaces, une application

Choisissez votre rôle pour explorer le prototype.

Avant de toucher une ligne

Audit technique

Le rapport qui tranche écran par écran ce qui est conservé, réécrit ou durci, avec les failles à corriger en priorité.

  • Verdict par écran
  • Failles classées par gravité
  • État des tables et des accès
Ouvrir l'interface
Pendant les travaux

Pilotage de la migration

L'avancement par lots, les tests qui rejouent les parcours critiques et le journal des mises en ligne depuis GitHub.

  • 5 lots datés
  • Suites de tests
  • Journal des déploiements
Ouvrir l'interface
La déclinaison suivante

Marque blanche

Un code unique, des données isolées par locataire, un thème, un logo et un domaine pilotés par configuration.

  • Aperçu rethémé en direct
  • Création d'un espace
  • Isolation des données
Ouvrir l'interface
Pour vos utilisateurs

Application mobile

L'application installable depuis le navigateur : écran d'accueil, plein écran, hors connexion et rappels. Aucun store.

  • Réservation de bout en bout
  • Mode hors connexion
  • Invite d'installation
Ouvrir l'interface

Comment on s'y prend

Quatre temps, dans cet ordre. Rien ne commence avant que l'audit soit rendu.

01

On lit tout l'existant

Code actuel, schéma de la base et accès. Vous savez où part chaque heure avant que la migration commence.

02

On pose le socle sur GitHub

Dépôt, architecture cible et mise en ligne automatisée. Les accès à la base repassent côté serveur, les secrets sortent du navigateur.

03

On migre par lots

Chaque lot est vérifié avant le suivant. La plateforme reste en ligne, aucune coupure, aucune perte de données.

04

On vous rend les clés

Documentation d'architecture, conventions, procédures et session de passation. Le projet reste reprenable sans nous.

Questions fréquentes

La plateforme reste-t-elle utilisable pendant la migration ?

Oui. Les lots basculent l'un après l'autre, chacun vérifié avant le suivant. Vos utilisateurs continuent de réserver pendant toute l'opération.

Que devient la base Supabase existante ?

Les données restent en PostgreSQL et ne bougent pas. Ce sont les accès qui changent : ils repassent côté serveur, avec des politiques par rôle et par locataire.

Pourquoi une application web installable plutôt qu'une application de store ?

Vos utilisateurs y accèdent par un simple lien, la mettent sur leur écran d'accueil et reçoivent les mises à jour immédiatement, sans validation extérieure.

Et si vous n'êtes plus là dans un an ?

Le dépôt GitHub vous appartient, l'architecture est documentée et les conventions écrites. N'importe quel développeur reprend le projet.