Une information critique, disponible au bon moment.
Les équipes de chargement doivent identifier les véhicules électriques présents dans les trains. BoardingPax transforme cette opération terrain en une donnée exploitable par les équipes opérationnelles et les secours.
CLIENT
Getlink
PROJET
BoardingPax
TYPE
Application mobile métier · PWA · Temps réel
ENJEU
Sécurité opérationnelle · Terrain · Disponibilité
Sur le terrain, quelques secondes peuvent changer la manière d'intervenir.
Les équipes chargées du boarding doivent disposer d'un moyen simple et rapide pour enregistrer les véhicules présents lors du chargement.
Une opération apparemment simple, mais dont la qualité de l'information conditionne directement la sécurité.
L'enjeu sécurité
Parmi les véhicules, les électriques nécessitent une attention particulière en cas d'incendie : leur identification peut apporter une information importante aux équipes chargées de l'intervention.
Le défi : transformer une opération manuelle en donnée fiable
Les équipes doivent pouvoir enregistrer les informations directement sur le terrain, sans ralentir le processus.
L'application devait être suffisamment simple pour être utilisée dans une opération réelle, sans ajouter de complexité au travail des équipes.
Conçue pour être utilisée dans les conditions réelles du terrain
L'interface est au service des équipes, pas l'inverse.
Mobile
L'application est conçue pour être utilisée directement depuis un terminal mobile.
Rapide
Les informations doivent pouvoir être enregistrées sans ralentir le processus de chargement.
Lisible
L'interface doit être compréhensible immédiatement.
Synchronisée
Les données doivent être disponibles dans le système central.
Fiable
L'application intervient dans un processus où la qualité de l'information compte.
De l'identification à l'information de sécurité.
Une opération simple côté utilisateur peut nécessiter une chaîne technique fiable côté système.
Cette phrase résume parfaitement le projet.
Une application mobile soutenue par une architecture distribuée
L'architecture a été conçue pour absorber les variations de charge et permettre aux différents composants d'évoluer indépendamment.
L'application mobile s'appuie sur des services backend qui orchestrent la synchronisation, le traitement et le stockage des données terrain.
Des composants indépendants, capables d'évoluer et d'absorber des variations de charge.
Une expérience simple pour un système complexe
L'utilisateur ne devrait pas avoir à comprendre l'architecture qui se trouve derrière l'application.
1 action
Une seule action côté utilisateur déclenche toute une chaîne de traitement côté système : validation, identification, synchronisation, traitement et stockage.
La complexité doit rester du côté du logiciel, pas de l'utilisateur.
Une architecture au service de l'opération
Microservices
Des responsabilités isolées, une évolution facilitée.
APIs
Des interfaces claires entre les composants.
Synchronisation temps réel
Les données terrain remontent au système central.
Tests automatisés
Valider chaque évolution avant déploiement.
Déploiement continu
Des mises en production régulières et maîtrisées.
Observabilité
Identifier rapidement un problème en production.
Une architecture capable d'absorber les pics d'activité
Les opérations de chargement ne sont pas constantes. L'architecture doit pouvoir absorber des variations d'utilisation sans nécessiter un dimensionnement permanent au maximum.
FAIBLE CHARGE
Ressources adaptées
PIC D'ACTIVITÉ
Scalabilité automatique
C'est précisément pour cela qu'Azure Functions a été retenu : adapter automatiquement les capacités backend à la charge.
Une application conçue pour un usage opérationnel continu
Déploiement automatisé
Des mises en production maîtrisées et reproductibles.
Tests
Une couverture de tests pour sécuriser chaque évolution.
Architecture distribuée
Pas de point unique de défaillance.
Monitoring
Une surveillance continue de l'application.
Gestion des erreurs
Des comportements prévus face aux situations dégradées.
Reprise
Des procédures pour revenir à un état stable.
La donnée n'est pas une fin : elle doit pouvoir servir à l'intervention.
L'identification des véhicules électriques permet de transmettre une information supplémentaire aux équipes susceptibles d'intervenir en cas d'incident.
La technologie au service du terrain
Chaque choix technique répond à une contrainte du projet.
PWA
Pour permettre une expérience mobile sans imposer une application native spécifique.
Azure Functions
Pour adapter automatiquement les capacités backend à la charge.
Microservices
Pour isoler les responsabilités et faciliter l'évolution du système.
React + TypeScript
Pour construire l'interface métier.
Ce projet démontre notre capacité à…
Concevoir des applications métier terrain
Créer une interface adaptée à des utilisateurs qui travaillent hors d'un environnement de bureau.
Transformer une opération en processus digital
Capturer une information directement à la source.
Construire des systèmes fiables
Concevoir l'architecture en fonction des contraintes opérationnelles.
Connecter les données terrain au SI
Faire circuler l'information entre l'application et les systèmes existants.
Concevoir pour des environnements exigeants
Prendre en compte disponibilité, sécurité et montée en charge.
Votre entreprise n'a pas besoin d'exploiter le tunnel sous la Manche pour avoir des équipes terrain.
Les problématiques sont souvent similaires.
Une application mobile peut transformer une opération terrain en processus numérique fiable et traçable.
Vos équipes travaillent sur le terrain ?
Donnez-leur un outil conçu autour de leur réalité opérationnelle.
Vos équipes travaillent encore avec des outils génériques sur le terrain ?
Nous pouvons transformer vos opérations terrain en applications simples pour vos utilisateurs et robustes pour votre système d'information.
Pas besoin d'avoir déjà choisi la technologie.