Le contexte

Stage réalisé au sein de l'unité APS (Actia Projet Sûreté)d'Actia Railway, la division Mobilitydu groupe ACTIA spécialisée dans l'hypervision pour la sûreté des réseaux de transport (SNCF, métros). J'ai été intégré à l'équipe R&D, en méthode agile, avec un projet autonome et un suivi régulier de mon maître de stage.

L'équipe maintient VisioSpace, un hyperviseur client-serveur historique en C/C++ (plus de 600 modules) qui agrège des centaines de flux vidéo et gère des alarmes complexes. Ma mission : concevoir de zéro un client web léger pour s'affranchir du client lourd Windows, devenu difficile à concilier avec les exigences de cybersécurité.

L'application — Vigiter UI (React / Redux)

J'ai développé Vigiter UI, la refonte web de la brique stratégique de supervision : grille de moniteurs vidéo, plans de rames interactifs et gestion des alarmes. Stack imposée par l'équipe : React + Vite, avec une architecture rigoureuse (séparation présentation / logique métier, services dédiés au parsing XML et aux API, CSS compartimenté par composant).

• Cartographie interactive des rames : parsing XML asynchrone, plans décodés en Base64 et mis en cache, caméras positionnées dynamiquement avec cônes de vision en SVG.
• Mur d'images en glisser-déposer : grille de 1 à 4 flux simultanés réagençables à la souris (dnd-kit), zoom numérique jusqu'à x16 et capture d'écran horodatée.
• Interface temps réel non bloquante : alertes, points d'intérêt et téléchargements gérés en modales sans jamais geler la lecture vidéo.
• Robustesse des données : édition hors-ligne avec sauvegarde locale, autocomplétion des gares (API SNCF), anti-rebond et normalisation des métadonnées corrompues.

Le défi technique : streaming temps réel vers le web

Le cœur de la difficulté : afficher en direct plusieurs flux vidéo avec une latence minimale. Les flux fmp4 ne contenaient pas de temps absolu (UTC), rendant la synchronisation native du navigateur impossible. Après des recherches poussées sur l'API Media Source Extensions, j'ai déplacé le problème côté serveur.

J'ai conçu et développé de bout en bout DashMP4Transpacker, un serveur de streaming C++ natif (Winsock2), un langage que je découvrais, capable d'encapsuler des frames brutes en fMP4 et de les exposer en segments MPEG-DASH (génération dynamique du manifeste .mpd, file circulaire en RAM, support CORS, mutualisation des flux RTSP, watchdog & live catch-up). J'ai ensuite branché les caméras réelles anonymisées en réutilisant les briques réseau éprouvées du socle logiciel de l'entreprise, ce qui évitait de réimplémenter une couche réseau de bas niveau tout en facilitant l'intégration avec le client lourd existant.

J'ai enfin mené une étude comparative des protocoles de transport sur un même banc de test : DASH (latence trop élevée), WebRTC/UDP (très faible latence mais bloqué par les pare-feu) et WebSockets/TCP— identifié comme la piste la plus prometteuse, conciliant faible latence et franchissement natif des pare-feu d'entreprise.

Ce que j'en retiens

Repartir d'une page blanche sur un environnement imposé m'a appris à structurer rigoureusement mon code et à assumer des choix d'architecture. J'ai progressé en développement front-end avancé, découvert le C++ et les API navigateur bas niveau, et compris la rigueur de la recherche technique (tests de latence, arbitrages client/serveur). Une expérience qui a confirmé mon attrait pour l'ingénierie logicielle.