Exemple de situation — Modernisation d'une application mobile de transport public
Exemple de situation, pas un client réel : refonte d'une application mobile voyageurs pour un opérateur de transport public. React Native, assistant IA, RGAA AA, paiement intégré. Ce que nous regardons en priorité, et comment nous procéderions.
Durée
Selon le périmètre, défini après l'audit
Équipe
Équipe dédiée, dimensionnée après l'audit
Technologies clés
Temps réel
Objectif de l'exemple : afficher une perturbation en quelques secondes plutôt qu'en plusieurs minutes
RGAA AA
Objectif de l'exemple : conformité vérifiée par un audit tiers indépendant
Avant / après
Les indicateurs (satisfaction voyageurs, note sur les stores, incidents) sont mesurés avant et après la refonte, sur la base choisie avec le client
#Exemple de situation — Modernisation d'une application mobile de transport public : info trafic temps réel, assistant IA, RGAA AA, paiement intégré
Exemple de situation, pas un client réel. Refonte complète d'une application mobile en React Native sur architecture événementielle, conformité RGAA AA visée dès la première version, assistant IA (perturbations en temps réel et itinéraires alternatifs), paiement intégré. Cette page illustre la méthode et les points d'attention ; elle ne contient aucun résultat chiffré.
#Contexte de l'exemple
Cet exemple est une situation type, imaginée pour illustrer notre méthode. Il ne décrit aucun client réel. Il met en scène un opérateur de transport public urbain dont l'application mobile est devenue le canal numérique principal, mais qui a été développée par plusieurs prestataires successifs sur une architecture ancienne, sans temps réel.
Il est soumis à l'obligation de conformité RGAA niveau AA et veut intégrer le paiement des titres de transport, ce qui suppose le respect de la norme PCI-DSS et une intégration avec une billettique ancienne.
#Le défi
Quatre contraintes se superposent. La fiabilité temps réel : une perturbation doit s'afficher en quelques secondes, y compris sous forte charge. La conformité RGAA AA : contrastes, navigation au clavier, lecteurs d'écran, alternatives textuelles, plans de lignes accessibles. L'intégration du paiement et de la billettique : un système propriétaire ancien expose des API SOAP, qui demandent une couche d'adaptation sous contrainte PCI-DSS.
L'assistant IA voyageurs : il doit répondre en langage naturel sur les itinéraires et les perturbations, sans inventer d'horaires ni sortir de son périmètre.
#Ce que nous mesurons
Nous ne promettons pas de résultat chiffré à l'avance. Au démarrage, nous choisissons avec le client les indicateurs qui comptent (satisfaction des voyageurs, note sur les stores, nombre d'incidents en production, conformité RGAA vérifiée par un audit tiers), nous relevons leur valeur avant la refonte, puis nous les mesurons après la mise en production. La décision d'aller plus loin s'appuie sur ces relevés.
Questions & réponses
Questions fréquentes sur ce scénario type
Trois raisons reviennent sur ce type de projet. Une équipe mobile interne réduite doit maintenir l'application après la livraison : une large part de code partagé signifie une seule base de code à entretenir au lieu de deux. Les délais imposent souvent une première mise en production rapide, et React Native permet d'avancer vite tout en gardant des modules natifs (NFC, notifications push, paiement). Enfin, l'écosystème React Native pour l'accessibilité est assez mature pour viser le RGAA AA, à condition de le tester sur de vrais appareils avec de vrais lecteurs d'écran.
L'assistant embarque des garde-fous à deux niveaux. Premier niveau : un classificateur de requêtes léger, placé en amont du modèle de langage, écarte les demandes hors domaine avant même d'appeler le modèle. Deuxième niveau : les consignes du modèle précisent les sujets autorisés et les réponses de repli (« je ne peux pas vous aider sur ce sujet, mais voici comment accéder à... »). Le taux de réponses hors périmètre se mesure en production, avec des échantillons relus par des humains, et fait partie des indicateurs suivis.
La conformité RGAA AA est d'abord un bénéfice fonctionnel pour les usagers en situation de handicap. Concrètement, un voyageur non-voyant peut utiliser l'application intégralement avec un lecteur d'écran, les plans de lignes sont décrits textuellement, les formulaires sont navigables au clavier, et les messages d'état sont annoncés aux lecteurs d'écran. Le bénéfice juridique existe aussi, mais viser le niveau AA dès la conception évite surtout de longues reprises après la livraison.
Un système de billettique propriétaire ancien expose souvent des API anciennes (SOAP), peu adaptées à une application mobile moderne. Nous développerions une couche d'adaptation (un microservice hébergé côté infrastructure du client) qui fait le pont entre ces API et les requêtes REST/JSON attendues par l'application. Elle se construit avec l'équipe billettique interne, et il faut souvent formaliser un contrat d'interface documenté et versionné, qui n'existe pas toujours. Le paiement est traité par un prestataire tiers : les données de carte ne transitent ni par la couche d'adaptation ni par l'application.
Un projet de cette ampleur (refonte complète, conformité RGAA AA, assistant IA, paiement intégré) se chiffre après un audit initial propre à votre contexte. Nous établissons un devis sur mesure, chiffré en 48 h après un premier échange. L'audit approfondi (5 jours) fait partie des points de départ possibles : il coûte 2 125 € HT.
Deux éléments font souvent la différence. Le premier est la démonstration fonctionnelle plutôt qu'une présentation de diapositives : un prototype avec affichage de perturbations en temps réel sur des données publiques de test, et un premier assistant IA répondant à des questions types, pèse plus lourd qu'un support commercial. Le second est la transparence sur la façon dont les résultats seront mesurés : les indicateurs, la base de comparaison et les exclusions légitimes sont écrits dans le contrat.
Le mode hors-ligne est partiel, et assumé comme tel dans l'application. Les plans des lignes sont téléchargeables en cache local, tout comme les horaires théoriques de la journée en cours. En revanche, les perturbations en temps réel, l'assistant IA et le paiement exigent une connexion, ce qui est signalé dans l'interface. Limiter le hors-ligne à l'essentiel évite de donner une fausse impression de fiabilité sur des données périmées.