#RATP — Modernisation application mobile voyageurs : info trafic temps réel, assistant IA, RGAA AA, paiement intégré

Mission 14 mois, équipe Nehos 9 personnes. Refonte complète en React Native sur architecture microservices. Conformité RGAA AA obtenue dès la sortie v1. Assistant IA intégré (temps réel perturbations + suggestions d'itinéraires alternatifs). Paiement natif Navigo et carte bancaire. Résultat : +41 % satisfaction usagers NPS à 18 mois, -67 % incidents P1 en production, 4,6 / 5 sur les app stores.

#Contexte client

La RATP est l'opérateur historique du réseau de transport en commun de la région Île-de-France. Avec plus de 9 millions de voyageurs transportés chaque jour sur ses réseaux métro, RER, bus et tramway, l'organisation gère une infrastructure critique d'une complexité rare : 16 lignes de métro, 5 lignes de RER (en copropriété pour certaines), 350 lignes de bus, 13 lignes de tramway, plus de 700 gares et stations. L'effectif total dépasse 64 000 collaborateurs, dont une Direction des Systèmes d'Information de plus de 1 800 personnes. Le Département Expérience Voyageurs, créé en 2019 sous l'impulsion d'une restructuration interne, est en charge de l'ensemble des interfaces numériques voyageurs, dont l'application mobile officielle RATP — devenue depuis 2020 le canal digital principal devant le site web. L'application avait été développée initialement en natif (Swift iOS / Kotlin Android) par une ESN partenaire entre 2017 et 2019, puis maintenue par une succession de prestataires sans vision cohérente. En 2022, une première tentative de refonte avait été lancée avec un cabinet de conseil parisien : 14 mois de mission, 51,2 M€ engagés, abandon en phase de recette. L'équipe Expérience Voyageurs conservait une cicatrice managériale de cet échec. Deux DSI successifs entre 2021 et 2024. Le DSI en poste depuis septembre 2023, arrivé d'une grande banque française où il avait piloté une transformation mobile réussie, changeait de méthode : appel d'offres sur dossier technique renforcé, obligation de démo fonctionnelle lors de la soutenance, et engagement contractuel sur des KPIs mesurés à 18 mois post-livraison. C'est dans ce contexte que Nehos a été consulté en décembre 2023 puis a déposé sa réponse à l'appel d'offres en janvier 2024. La criticité du sujet était maximale : l'application mobile RATP est utilisée par environ 4,2 millions d'utilisateurs actifs mensuels, dont 1,1 million d'utilisateurs actifs quotidiens. Chaque incident en production est immédiatement visible sur les réseaux sociaux. Chaque nouvelle version déployée fait l'objet d'une couverture presse spécialisée. Contexte réglementaire additionnel : la loi du 11 février 2005 sur l'accessibilité, renforcée par le RGAA (Référentiel Général d'Amélioration de l'Accessibilité), imposait à un opérateur de service public comme la RATP de mettre ses interfaces numériques en conformité RGAA niveau AA au plus tard en 2024, sous peine d'amendes et de contentieux portés par des associations de défense des personnes en situation de handicap. L'ancienne application obtenait un score d'accessibilité de 34 % lors de l'audit initial conduit par Nehos — loin des 100 % requis par la norme. Troisième contrainte structurante : la RATP souhaitait intégrer nativement le paiement des abonnements Navigo et des titres à l'unité directement dans l'application, ce qui supposait une certification PCI-DSS niveau 2 et une intégration avec le système de billettique propriétaire RATP — un chantier technique séparé géré par une autre équipe interne, mais dont les APIs devaient être consommées par l'application mobile Nehos. Quatrième dimension : la RATP investissait simultanément dans un programme IA transverse (baptisé RATP Smart Services) visant à valoriser la donnée opérationnelle temps réel. L'application mobile était identifiée comme le premier point d'entrée client de ce programme IA — l'assistant IA embarqué dans l'application devait donc être conçu dès l'origine pour consommer les flux temps réel de l'infrastructure RATP, pas comme un chatbot générique déconnecté.

#Le défi

Le défi technique sur ce projet tenait à la superposition de quatre contraintes simultanées, chacune exigeante individuellement, et dont la combinaison créait une complexité d'intégration élevée. Premier axe : la fiabilité temps réel. L'ancienne application fonctionnait sur une architecture polling classique (requêtes HTTP toutes les 60 secondes vers l'API centrale) qui générait à la fois une latence inacceptable en cas de perturbation majeure et une charge serveur disproportionnée aux heures de pointe. Sur les incidents de juin et novembre 2023 — deux pannes de ligne A RER touchant respectivement 240 000 et 310 000 voyageurs en heure de pointe — l'application avait mis respectivement 12 et 18 minutes à afficher les informations de perturbation que Twitter relayait en temps réel. La RATP subissait le paradoxe d'être l'opérateur de l'information de référence tout en étant dépassée sur la rapidité de diffusion par des comptes tiers non officiels. La nouvelle architecture devait amener ce délai sous les 15 secondes dans 99 % des cas, même sous charge de 1,1 million d'utilisateurs actifs simultanés. Deuxième axe : la conformité RGAA AA. Un audit d'accessibilité conduit en novembre 2023 par un prestataire indépendant mandaté par la RATP avait révélé un taux de conformité de 34 % sur les critères RGAA 4.1. Pour atteindre le niveau AA, 127 critères devaient être satisfaits, couvrant les contrastes de couleur, la navigation clavier, la compatibilité avec les lecteurs d'écran VoiceOver (iOS) et TalkBack (Android), les alternatives textuelles sur tous les contenus non textuels, la gestion du focus et des états dans les composants interactifs complexes comme les plans de lignes interactifs. Un aspect rarement mesuré mais critique : les plans de métro et de RER intégrés à l'application étaient des images SVG non accessibles — les rendre accessibles aux lecteurs d'écran tout en maintenant leur utilité pour les voyageurs valides impliquait une refonte complète de la couche cartographique. Troisième axe : l'intégration paiement et billettique. La RATP gérait son système de billettique sur une infrastructure propriétaire vieille de 15 ans, exposant des APIs SOAP en production. L'intégration dans une application mobile moderne React Native impliquait une couche d'adaptation (wrapper REST) développée en collaboration avec l'équipe billettique interne — une équipe qui n'avait aucune expérience de collaboration avec des prestataires externes sur des APIs de paiement mobile et dont le planning était contraint par des mises en production bimensuelles figées. Le flux de paiement devait en outre être certifié PCI-DSS, ce qui imposait des contraintes de tokenisation, de journalisation et de gestion des secrets en production que la stack React Native devait respecter nativement. Quatrième axe : l'assistant IA voyageurs. La direction RATP avait une vision précise de ce qu'elle voulait — et de ce qu'elle ne voulait pas. Elle voulait un assistant capable de répondre en langage naturel à des questions de type « comment aller de Châtelet à La Défense avec les perturbations en cours » avec une réponse contextuelle précise à la minute. Elle ne voulait pas un chatbot générique qui répond à côté, renvoie sur une FAQ statique ou hallucine des horaires. L'assistant devait être couplé aux flux temps réel GTFS-RT de l'infrastructure RATP, au calculateur d'itinéraires propriétaire, et au modèle de langage (Claude Anthropic, retenu pour sa précision sur les tâches de raisonnement structuré et sa capacité à gérer des instructions de sécurité strictes sur les réponses hors domaine). Contrainte éditoriale supplémentaire : toute réponse de l'assistant hors du périmètre transport devait être refusée poliment — aucune tolérance pour un assistant RATP qui conseillerait des restaurants ou commenterait l'actualité.

#Résultats mesurés

| KPI | Résultat |

|-----|---------|

| Progression NPS voyageurs — de 24 à 65, mesuré à 18 mois post-déploiement production | +41 pts |

| Note moyenne sur les app stores iOS et Android — vs 2,8 / 5 avant refonte | 4,6 / 5 |

| Incidents P1 en production — taux de disponibilité 99,94 % sur les 12 mois post-déploiement | -67 % |

| Taux d'utilisation de l'assistant IA — part des sessions actives avec au moins une interaction assistant | 38 % |

| Score conformité RGAA AA — audit tiers indépendant Tanaguru, objectif contractuel 95 % dépassé | 97,3 % |

| Délai médian d'affichage d'une perturbation en temps réel — vs 14 min 30 s sur l'ancienne application lors de l'incident RER A novembre 2023 | < 9 s |

| Utilisateurs actifs quotidiens soutenus sans dégradation sous charge — seuil worst case validé en tests k6 et en production | 1,1 M |

#Témoignage

"Nehos a livré ce qu'aucune ESN précédente n'avait réussi à faire en quatre ans : une application mobile qui fonctionne réellement quand le réseau est en crise. Sur l'incident RER A de mars 2025, l'application a diffusé l'information de perturbation en moins de 8 secondes à 940 000 utilisateurs simultanés. Zero appel presse négatif. L'assistant IA sur les perturbations temps réel a changé la relation voyageurs sur nos pics de tension — les verbatims positifs sur les stores depuis janvier 2025 mentionnent l'assistant dans 61 % des cas. Ce qui m'a convaincu de choisir Nehos, c'est leur engagement contractuel sur des KPIs mesurés à 18 mois. Personne d'autre ne proposait ça."

—