Le lab, le prototypage en support du conseil
Après avoir été responsable de la billettique en Île-de-France pendant plus de dix ans, j’ai voulu reprendre la matière première là où elle se trouve vraiment – dans la carte et dans le téléphone – afin de me retrouver en situation de me poser les mêmes questions que les industriels billetticiens ou acteurs du digital qui sont confrontés à la lecture (ou à l’écriture) d’un passe sans contact (dans sa version physique ou dématérialisée). J’ai testé le cas de figure de l’Île-de-France, car c’est plus aisé pour moi d’y réaliser des tests (et je connais – un peu – le réseau et sa tarification), mais la démarche est généralisable à tout réseau qui dispose d’une billettique sans-contact, notamment avec le standard Calypso – ce qui est le cas de bon nombre de réseaux urbains et régionaux en France.
Le résultat est une application Android minimale, proche de celle mise à disposition de contrôleurs. Son scope fonctionnel est le suivant : approcher un passe Navigo – carte plastique ou cartonnée, ou passe sur smartphone – et voir s’afficher le type de support, les titres et leur validité, et les dernières validations enregistrées (mode, ligne, station, heure). Rien qui n’existe déjà dans un valideur ou un portable de contrôle. Mais le faire soi-même, avec les moyens du bord, permet de mieux appréhender l’écosystème.
Un standard ouvert, un écosystème d’outils
Premier élément qui est lié à la stratégie que j’ai moi-même appliquée au sein d’IDFM et qui simplifie les choses : lire une carte Navigo est un problème largement résolu, et résolu de façon générale et au grand jour. Le format billettique francilien s’appuie en effet sur des normes publiques – couches ISO 14443 et 24192, carte à puce et cardlet Calypso, structure de données Intercode – portées par des associations internationales et documentées. Autour, une communauté a produit depuis des années des outils libres capables de parcourir ces cartes et d’en restituer le contenu, comme le fait par exemple Eclipse Keyple.
C’est un point à porter au crédit des choix faits il y a plus de vingt ans en Île-de-France et sur de nombreux territoires français, villes, métropoles, régions : le format de la carte n’appartient à aucun industriel en particulier. L’interopérabilité – plusieurs opérateurs, plusieurs fabricants de cartes, plusieurs générations de supports qui coexistent – est inscrite dans la stratégie de distribution de l’autorité et traduite dans la conception du système billettique. Mon prototype n’a rien inventé : il s’est appuyé sur un standard ouvert, s’est inspiré de quelques projets open source et a utilisé un panel de cartes pour reconstituer les encodages, et vérifié le tout sur des supports réels.
Ce qu’on lit, ce qui manque
Le contenu de la carte se décode proprement : le forfait, ses zones, ses dates, le solde d’un carnet, le titre qui serait retenu à la prochaine validation. Le journal transport aussi : métro, entrée, 18 h 34.
Là où c’est plus délicat, c’est pour nommer le lieu ou le numéro de ligne commerciale. La validation référence une station ou un arrêt par un code interne – hérité de la billettique, propre à chaque réseau. Or ce code n’est publié nulle part avec sa correspondance vers les identifiants de l’open data, ce qui nécessite la mise en place de tables de transcodage entre billetticiens et acteurs des référentiels topologiques et de transport. Résultat : je décode parfaitement une entrée RER, sans toujours pouvoir dire à quelle gare, je ne sais pas exactement caractériser sur quel numéro commercial de ligne a eu lieu une validation bus.
C’est la même leçon que pour n’importe quel service bâti sur ces données : une référence n’a de valeur que si l’on publie aussi les tables de passage qui la relient aux autres. Le travail de mise en cohérence est invisible, jamais valorisé, et pourtant déterminant.
Lire n’est pas exactement contrôler
Le contenu d’un passe – titres de transport, dernières validations – se lit sans aucun contrôle d’accès : n’importe quel téléphone NFC y accède. C’est un choix de conception assumé, et sain.
En revanche, le vérifier – authenticité du support, absence de clonage, signature du contrat – suppose des clés de sécurité détenues par l’autorité et distribuées dans des modules dédiés, les SAM. Sans ces clés, un outil de « contrôle » lit et affiche, mais n’est pas totalement résistant à la fraude technologique : il est informatif, pas à 100% fiable ou opposable.
Cette nuance structure tout ce qui touche aux équipements de contrôle, à la validation au sol ou embarquée, mais s’étend également à l’open payment : jusqu’où peut-on aller avec une lecture simple, et à partir de quand faut-il la chaîne de sécurité complète. C’est a fortiori le cas pour l’écriture sur une carte de transport, qui nécessite des modules de sécurité dotés de clés spécifiques. Ainsi, mon prototype lit un support, il ne peut pas écrire dessus.
Le passe devient un logiciel
Le passe sur smartphone a nécessité de faire évoluer la technologie. Deux implémentations coexistent : l’élément sécurisé matériel du téléphone, qui se comporte exactement comme une carte (aux spécificités propriétaires Apple près pour passer en mode Express / ECP et activer l’interaction avec le smartphone sans déverrouillage d’écran), et l’émulation logicielle par le système, un peu plus lente et impliquant des particularités de lecture. Dans ce second cas – l’émulation HCE – le titre n’est plus une carte : c’est un jeton signé, à durée de validité courte, resynchronisé régulièrement par l’application du téléphone.
Une donnée d’usage dans la poche
Le journal, ce sont les dernières validations : mode, lieu, heure, titre utilisé. Cette donnée alimente différents type de cas d’usage.
C’est avant tout la matière première des statistiques de fréquentation par la validation et de la politique tarifaire. Elle remonte ainsi régulièrement de façon anonymisée dans des systèmes centraux et permet de réaliser des analyses poussées de fréquentation, d’utilisation des titres de transport, ou encore de mettre en oeuvre une rémunération incitative des transporteurs. En Île-de-France, ce sont des milliards de validations qui sont ainsi exploitées.
Mais la validation, c’est aussi une tranche de l’historique de déplacement d’une personne, stockée dans un support que l’on peut lire librement. Cette lecture libre des événements de validation et des contrats de transport détenus des usagers peut alimenter des usages dérivés de la carte de transport : la lecture de son identifiant pour un usage ABT (Account Based Ticketing) sur certains systèmes, la présentation du passe et la lecture des abonnements pour accorder un tarif réduit ou l’accès à un équipement (parc-relais, consignes vélos, toilettes en gare…) par exemple.
Ces usages sont encadrés par le RGPD et la CNIL s’est historiquement penchée sur ce sujet pour mettre en place un cadre d’utilisation des données billettiques, dans les systèmes billettiques des AOM ou des exploitants ainsi que dans les systèmes tiers.
Ce que l’exercice révèle
Ce prototype a été développé avec un PC, un simple smartphone et des ressources publiques. C’est possible car le standard est ouvert et que la rétro-ingénierie du format a été faite, publiquement, il y a longtemps. Développer un traitement de titre minimal n’est plus un exercice réservé à quelques rares initiés, ce qui contribue à ouvrir le marché.
Et en pratique
Cette application n’est pas un produit diffusable. C’est un moyen de rester dans le dur et de mettre un peu de réalisme dans les discussions sur la billettique avec les autorités organisatrices, les opérateurs, les industriels ou les fournisseurs de services numériques multimodaux (FSNM) : gouvernance de la donnée billettique, définition contractuelle du contrôle, technologie de dématérialisation du passe, référentiels, interopérabilité.
