Étude de cas · Plateforme d'enchères en direct

Blisterr

En cours · depuis 2026

Plateforme d'enchères en direct pour objets de collection : le vendeur anime une diffusion, les acheteurs enchérissent en temps réel. Nous avons repris l'application Flutter et le backend existants pour livrer une version plus rapide, portée par une architecture hybride LL-HLS et LiveKit et une infrastructure provisionnée à la demande.

Contexte

Plateforme d'enchères en direct pour cartes TCG, figurines et objets de collection. Le vendeur lance une diffusion, les acheteurs enchérissent sur chaque lot en temps réel. Nous avons repris une application Flutter et un backend déjà en production pour livrer une version plus rapide, sans interruption de service.

Le défi

Reprendre une application et un backend déjà en production sans interrompre le service. Côté application, la migration de 237 StatefulWidgets vers hooks et Riverpod, de 93 StateNotifiers vers le code généré @riverpod, le retrait de GetIt et l'adoption de GoRouter ont touché environ 2 500 fichiers. Côté backend, la migration de MongoDB vers PostgreSQL devait s'effectuer sans coupure. La diffusion vidéo devait rester sous trois secondes de latence tout en maîtrisant les coûts.

Notre approche

Nous avons mené une migration progressive selon le modèle Strangler Fig. L'application Flutter est passée par vagues à hooks et Riverpod, avec providers générés, retrait de GetIt et navigation GoRouter, tout en restant en production. Le backend migre de MongoDB vers PostgreSQL 17 avec Prisma, table par table. Pour la diffusion, une architecture hybride LL-HLS et LiveKit maintient la latence sous trois secondes. L'infrastructure est provisionnée à la demande et dimensionnée pour chaque direct, ce qui divise environ par six le coût par heure-spectateur par rapport à une architecture entièrement WebRTC. Le backend compte 6 680 tests et 97 % de couverture.

Technologies
FlutterNestJSPostgreSQLLiveKitLL-HLSHetznerCloudflare
Résultat

En production depuis 2026, en itération continue. Le coût par heure-spectateur est environ six fois inférieur à celui d'une architecture entièrement WebRTC, avec une latence maintenue sous trois secondes côté spectateurs.