Étude de cas

Hivelink — De zéro à 1 000 utilisateurs en 3 mois

Plateforme de mobilité urbaine temps réel — app passager, back-office exploitant et backend

Client: Hivelink Group — startup française de la mobilité urbaine
Rôle: Développeur full-stack unique — architecture, produit, développement, déploiement
Calendrier: Dépôt vide en novembre 2025 · mise en ligne publique en mai 2026 · 1 000 inscrits en août 2026
Stack: React 19 · TypeScript · Vite · Flask/Python · Firebase · Socket.IO · Leaflet/CARTO · GTFS-RT · Docker · Google Cloud Run

Le contexte

Hivelink voulait transformer un trajet en bus en une expérience qui donne envie de reprendre les transports en commun : savoir où est son bus en temps réel, signaler un problème, gagner des récompenses, échanger avec les autres voyageurs. Côté exploitant, il fallait une console pour piloter tout ça : incidents, communication, analyse de la satisfaction.

Au départ, il n'existait rien. Pas de code, pas de design system, pas d'infrastructure.

La contrainte structurante

Le produit devait fonctionner sans dépendre d'un accord commercial avec un opérateur de transport. J'ai donc conçu la plateforme sur les données ouvertes GTFS et GTFS-RT publiées par les réseaux : l'application est aujourd'hui opérationnelle sur quatre villes — Rennes (STAR), Bordeaux (TBM), Amiens (AMETIS) et Angers (IRIGO) — et l'ajout d'un nouveau réseau se fait depuis le back-office, par import de son flux GTFS, sans intervention de développement.

C'est ce choix d'architecture qui a permis de lancer vite, sur plusieurs villes à la fois, avec zéro friction commerciale.

Les villes sont couvertes via leurs données ouvertes GTFS, sans partenariat commercial avec les opérateurs.

Ce que j'ai construit

Deux applications reliées à un backend temps réel, développées seul.

L'application passager

Carte temps réel des véhicules alimentée par les flux GTFS-RT, suivi de trajet actif avec prochain arrêt et heure d'arrivée estimée, calculateur d'itinéraire, feed communautaire (publications, sondages, commentaires, notifications en temps réel), programme de fidélité et de récompenses, missions et classements gamifiés, événements sponsorisés avec validation partenaire, notation de trajet et bouton SOS. Le tout derrière un onboarding en 6 étapes avec consentement RGPD explicite.

Le back-office exploitant

Tableau de bord d'activité, cartographie des incidents et heatmap des remontées, analyse de la satisfaction par catégorie, modération du feed, campagnes de communication ciblées, gestion multi-réseaux avec import GTFS, suivi des validations de trajet, gestion des lots et des récompenses.

Les fondations

Design system maison (21 familles de composants, tokens, stories), couche temps réel WebSocket partagée entre les deux applications, authentification Firebase, monitoring Sentry, internationalisation, et pipeline CI/CD GitHub Actions vers Google Cloud Run avec environnements de staging et de production séparés.

Les résultats

1 000+ utilisateurs inscrits en 3 mois, sans budget d'acquisition
4,6/5 de note moyenne sur 76 avis — le produit ne fait pas qu'attirer, il satisfait
4 réseaux de transport couverts dès la première année, sans partenariat opérateur requis
Nouveau réseau ajoutable depuis le back-office par import GTFS, sans intervention de développement
Plateforme en production, déployée en continu et enrichie chaque semaine depuis le lancement
450 des 472 commits du projet (95 %) — architecture, produit et code tenus par une seule personne
~41 500 lignes de code livrées depuis un dépôt vide
2 applications + backend en production, CI/CD staging et production sur Google Cloud Run
Design system complet construit de zéro : 21 familles de composants, 226 fichiers React

Un projet similaire en tête ?

Discutons de votre idée — de l'architecture au déploiement.

Échangeons sur votre projet