Scénario type — Modernisation d'une application mobile transport public

Trois raisons reviennent systématiquement sur ce type de mission. Une équipe mobile interne réduite doit maintenir l'application après livraison — React Native avec une très large part de code partagé signifie une seule base de code à entretenir au lieu de deux. Les délais contractuels imposent souvent une première mise en production en moins d'un an — React Native permet d'accélérer le développement sans sacrifier la qualité des modules natifs (NFC, notifications push, paiement) gérés en bare modules. Enfin, l'écosystème React Native pour l'accessibilité a atteint un niveau de maturité suffisant pour répondre aux exigences RGAA AA sans développements natifs spécifiques.

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 principal, rejette les requêtes hors domaine avant même d'appeler le LLM — une part très large des requêtes hors périmètre est ainsi bloquée sans coût de calcul supplémentaire. Deuxième niveau : le prompt système du LLM contient des dizaines de lignes de contraintes explicites sur les domaines autorisés et les comportements de repli (« je ne peux pas vous aider sur ce sujet, mais voici comment accéder à... »). Sur ce type de mission, le taux de réponses hors périmètre observé en production reste de l'ordre de quelques dixièmes de pourcent.

La certification RGAA AA est d'abord un bénéfice fonctionnel pour les usagers en situation de handicap, qui représentent entre 15 et 20 % de la population adulte en France selon les définitions retenues. Concrètement, la conformité RGAA AA signifie qu'un voyageur non-voyant peut utiliser l'application intégralement avec un lecteur d'écran, que les plans de lignes restent fonctionnels pour les voyageurs valides tout en étant décrits textuellement, que les formulaires sont navigables au clavier, et que tous les messages d'état sont annoncés aux lecteurs d'écran. Le bénéfice juridique est réel, mais viser le niveau AA dès la conception plutôt qu'en correctif final évite surtout plusieurs mois de reprises coûteuses après livraison.

Un système billettique propriétaire de ce type expose souvent des API anciennes (SOAP), incompatibles avec une consommation directe depuis une application mobile moderne. Sur ce type de mission, Nehos développe et maintient un wrapper REST (microservice hébergé côté infrastructure du client) qui fait le pont entre les API SOAP historiques et les requêtes REST/JSON attendues par l'application mobile. Cette couche d'adaptation nécessite plusieurs semaines de développement avec l'équipe billettique interne, dont une partie pour formaliser un contrat d'interface documenté et versionné, souvent inexistant avant l'intervention. Le flux de paiement est traité par un prestataire tiers : les données de carte ne transitent jamais par le wrapper ni par l'application mobile.

Sur ce type de mission — refonte complète, conformité RGAA AA, assistant IA embarqué, paiement intégré, équipe dédiée d'une dizaine de personnes sur plus d'un an — l'ordre de grandeur budgétaire type se situe entre 1,5 et 3 M€ HT pour le socle applicatif, avec des avenants possibles selon le périmètre additionnel demandé en cours de route. Ces montants sont illustratifs et donnés à titre d'ordre de grandeur : ils ne correspondent pas à une facturation réelle vers un client nommé. Le chiffrage définitif dépend toujours d'un audit initial spécifique à votre contexte.

Deux éléments font souvent la différence sur ce type de compétition. Le premier est la démonstration fonctionnelle imposée en soutenance plutôt qu'une simple présentation de slides : un prototype fonctionnel avec affichage de perturbations temps réel sur données publiques de test, et un premier prototype d'assistant IA répondant à des requêtes voyageurs types, pèse plus lourd qu'un support commercial. Le second est l'engagement contractuel sur des indicateurs mesurés à 18 mois — un engagement que des ESN plus importantes refusent souvent d'inclure dans leur offre, au motif que les résultats ne dépendent pas uniquement du prestataire. Accepter cet engagement, en contractualisant les conditions mesurables et les exclusions légitimes, rassure sur la motivation réelle à livrer un résultat.

Le mode hors-ligne type est partiel et assumé comme tel dans l'application. Les plans de toutes les lignes sont téléchargeables en cache local et accessibles sans réseau, tout comme les horaires théoriques de la journée en cours. En revanche, les informations de perturbation temps réel, l'assistant IA et les fonctions de paiement requièrent une connexion — ce qui est explicitement signalé dans l'interface. Cette décision de limiter le mode hors-ligne à l'essentiel plutôt que de créer une fausse impression de fiabilité sur des données périmées est généralement validée avec les équipes internes du client dès la phase d'architecture.