
LiBlul — Gérant · Développeur Full Stack
LiBlul — une plateforme de visites virtuelles 360°
Une plateforme où créer une visite virtuelle 360° est devenu simple — éditeur visuel, partage en un lien
En bref
Problème
Un éditeur visuel simple, une diffusion performante des panoramas lourds, une infrastructure qui absorbe les pics.
Intervention
Une plateforme SaaS full stack — éditeur, pipeline d’optimisation à l’import, hébergement auto-managé.
Résultat
Une plateforme en ligne qui permet de créer et publier des visites virtuelles sans compétence technique.
Contexte
Les visites virtuelles 360° restent coûteuses à produire et à publier. LiBlul vise à rendre leur création accessible : importer des panoramas, composer une visite, la partager.
Problème
Construire une plateforme de ce type, c’est tenir trois sujets à la fois : un éditeur visuel simple pour des utilisateurs non techniques, une diffusion performante des scènes (panoramas lourds), et un service qui absorbe les pics de visiteurs sans coûter une fortune.
Contraintes
- Utilisateurs finaux non techniques : l'éditeur doit se comprendre sans documentation.
- Panoramas volumineux : le temps de chargement conditionne la conversion.
- De la donnée utilisateur à protéger (comptes, contenus privés).
Solution
Itérer sur l’éditeur avec de vrais usages, garder le socle simple tant que tout suit, et mesurer ce qui compte : visites créées, visites consultées, temps de chargement.
Résultat
Une plateforme en ligne qui permet de créer et publier des visites virtuelles sans compétence technique.
Ce que ce projet démontre
Concevoir un produit complet — de l’éditeur aux comptes en passant par la diffusion — et le piloter du concept aux opérations.
Sous le capot
Stack, décisions d’architecture — le détail technique derrière le résultat.
Mon rôle
Gérant et développeur full stack : produit, UX, développement, infrastructure et monitoring.
Architecture
- Application full stack : Angular côté client, API côté serveur.
- Pipeline d’optimisation des panoramas (adaptation aux écrans et réseaux).
- Hébergement auto-managé, monitoring et sauvegardes automatisées.
Décisions clés
- Optimisation à l’import, pas à la consultation : la fluidité se paie une seule fois, à l’import — pas à chaque visite.
- Éditeur nodal assumé mais cadré : composer une visite reste visuel, sans exposer la complexité technique.
- Infrastructure maîtrisée : même arbitrage coût/contrôle que les autres projets, avec monitoring au niveau produit.
Challenges
Le compromis qualité d’image / poids des fichiers : une visite qui charge mal ne convertit pas. Le deuxième challenge est le produit lui-même : distinguer ce qui rend un éditeur « simple » (moins d’options ? meilleurs défauts ? meilleurs parcours ?).
Vous souhaitez rendre un contenu complexe accessible ? Parlons de votre projet.
Décisions d’architecture
Optimisation à l’import, pas à la consultation
Pourquoi : Les panoramas sont volumineux et le temps de chargement conditionne la conversion.
Conséquence : La fluidité se paie une seule fois, à l’import — pas à chaque visite.
Éditeur nodal assumé mais cadré
Pourquoi : Des utilisateurs non techniques doivent se servir de l’éditeur sans documentation.
Conséquence : Composer une visite reste visuel, sans exposer la complexité technique.
Infrastructure maîtrisée
Pourquoi : Absorber les pics sans coûter une fortune.
Conséquence : Monitoring au niveau produit et sauvegardes automatisées.

