Normalisation billettique

Une norme pour les tickets sans contact

INTERTIC est constitué :

• d’une norme française homologuée et référencée : NF P99-410 Mai 2014, Billettique appliquée aux transports - Règles d’interopérabilité pour la codification des données billettiques - Billets sans contact (INTERTIC),
• d’un fascicule de documentation référencé : FD P99-416 Juin 2014, Billetique appliquée aux transports - Règles d’interopérabilité pour la codification des données billetiques - Billets sans contact - Fascicule de documentation INTERTIC.

Ces documents sont disponibles via la boutique afnor

Principe

INTERTIC est l’équivalent d’INTERCODE pour les billets sans contact. Son périmètre est cependant plus large qu’INTERCODE, puisqu’au-delà de l’interface "présentation", la norme concerne également l’interface "session".

A quoi sert INTERTIC ?

Cette norme a le même objectif qu’INTERCODE, elle décrit les données, les structures de données, la façon de les coder et les principales règles d’utilisation. Cependant, INTERTIC va au-delà, car contrairement à INTERCODE, pour les billets sans contact, on ne s’appuie pas sur Calypso.
L’architecture logicielle des cartes est une architecture en couche. Avec INTERCODE, on ne normalise que la couche présentation, et on renvoie à Calypso pour les couches inférieures.
Avec INTERTIC il a été nécessaire d’aller plus loin dans la normalisation, car on ne peut pas renvoyer aux spécifications Calypso, pour la gestion de la sécurité par exemple.
Cela a pour conséquence que la norme doit décrire chaque billet du marché en tenant compte des spécificités des fournisseurs (objet du fascicule de documentation). Lorsqu’un nouveau produit apparaîtra sur le marché, le fascicule de documentation sera mis à jour pour le décrire.

Un document normatif pour favoriser les échanges entre systèmes informatiques

Afin d’enrichir le service offert à l’usager des transports collectifs, et développer l’intermodalité, il est nécessaire de faire communiquer entre eux plusieurs systèmes billettiques, on parle alors d’interopérabilité technique entre systèmes.

Dans certains cas, il faut permettre les échanges de données entre back-offices de plusieurs systèmes.

Illustration : Un support unique (par exemple une carte à puce sans contact) permet aux usagers de voyager sur les réseaux A, B et C partenaires d’un bassin d’interopérabilité.
Si l’on veut offrir à l’usager la possibilité de se rendre indifféremment auprès de l’un ou l’autre des réseaux A, B ou C pour acheter des titres de ces réseaux, ou effectuer des opérations de service après vente (reconstitution de carte en cas de perte), alors les informations de ventes devront être échangées entre les back-offices des systèmes A, B et C.

Afin de rationaliser, et optimiser ces échanges, il a été décidé de normaliser les formats d’échanges d’informations entre back-offices. C’est l’objet d’INTERBOB (INTERopérabilité du Back-Office Billettique).

INTERBOB concerne les échanges unitaires de données clients (comme des extraits de fiches client) et de données événementielles, qui concernent des opérations sur les supports et sur les titres, comme :
Les opérations billettiques réalisées (distribution, validation…)
Les opérations billettiques à réaliser (suspendre un titre, interdire un support…)

INTERBOB ne concerne pas l’échange de gammes tarifaires (description des tarifs).

Dans le cadre défini par INTERBOB, si deux organisations sont amenées à échanger des informations, l’émetteur, en respectant le formalisme de message INTERBOB défini sur le bassin d’interopérabilité, pourra être assuré que le partenaire destinataire saura interpréter correctement son contenu.

La norme INTERBOB a été publiée en décembre 2016 sous la référence NF P99-512. Elle est disponible sur la boutique afnor https://www.boutique.afnor.org/.

Le fascicule de documentation FD P99-503 publié en 2006 n’est pas remis en cause, il définit les principes généraux d’INTERBOB. Il est disponible sur la boutique afnor https://www.boutique.afnor.org/.

Ainsi, le référentiel documentaire INTERBOB est aujourd’hui constitué :

• du fascicule FD P99-503 Août 2006 : définition du cadre et des grands principes
• de la norme NF P99-512 : normalisation des formats d’échanges d’informations entre Back-offices.

nb : On notera qu’il existe un document de travail, non publié par l’AFNOR et appelé "fascicule 2 d’INTERBOB", qui traite de la description détaillée de messages représentant certains des flux modélisés dans le document FD P99-503, avec un objectif de mise en œuvre opérationnelle des échanges de données entre systèmes de billettique interopérable. Ce document de travail intermédiaire de la démarche "INTERBOB" est disponible ci-dessous (il comporte deux parties).

Document de travail 2008 "fascicule 2 d’INTERBOB _ Partie 1"

Document de travail 2008 "fascicule 2 d’INTERBOB _ Partie 2"

Qu’est-ce que c’est ?

Il s’agit d’une norme française homologuée dont la version courante est parue en mars 2020 (cette version remplace le texte de 2013).

Elle est disponible sur la boutique AFNOR

Son principe est le suivant : La norme NF P99-502 définit un certain nombre de listes de valeurs nécessaires à la gestion de l’interopérabilité des applications billettiques et monétiques.

A quoi sert la norme NF P99-502 ?

Le développement des applications billettiques interopérables rend nécessaire la mise en place d’un certain nombre de listes de valeurs afin d’en assurer la bonne gestion. La norme NF P99-502 définit ces listes de valeurs et leurs modes de gestion dans le but d’en optimiser la fiabilité.
Que trouve-t-on dans la norme NF P99-502 ?

Les systèmes de numérotation définis sont au nombre de trois :

• _NAO_ Un système de numérotation à vocation nationale permettant d’identifier les autorités organisatrices de transport public. Ce numéro (NAO) peut être utilisé à chaque fois que l’autorité organisatrice de transport public a besoin de s’identifier pour ses applications billettiques et monétiques.
  La norme contient la liste des numéros réservés pour chaque périmètre de transports urbains, collectivité d’outre-mer, syndicat mixte SRU, département et région, connus lors de la rédaction de la norme.
  Toute autorité organisatrice de transports qui souhaite utiliser le NAO qui lui est réservé doit en faire la demande auprès de l’AFIMB (l’annexe A de la norme contient le formulaire de demande).
  Le numéro à utiliser dans les applications interopérables est de préférence le numéro d’identification de l’AO ou du groupement d’AO dont la ou les zones géographiques englobe l’ensemble des exploitants.
• _AID_ Un système d’identification des applications billettiques interopérables françaises, grâce aux AID (Application IDentifiers).
  Un AID représente 16 octets codés en héxadécimal. Il se compose de plusieurs parties identifiant chacune une caractéristique de l’application à laquelle il se rapporte (la zone géographique, la norme utilisée par exemple). La norme définit la composition précise de l’AID, pour chacune de ses parties.
• _KVC_ Un système d’identification des jeux de clés de sécurité des applications billettiques interopérables françaises : grâce aux KVC.
  La norme définit ce qu’est un KVC (Key Version and Category = identificateur de version et de catégorie de clé), et son utilisation. Elle fournit également des valeurs de cet octet KVC pour toutes les clés de projets billettiques interopérables qui existent (ou pourront exister) en France.

Afin d’éviter les conflits entre les KVC de plusieurs clés, toute Autorité Organisatrice ayant besoin d’utiliser des valeurs de KVC différentes de celles attribuées par la norme est tenue d’en avertir l’AFIMB, autorité d’enregistrement en charge de la gestion de la liste des KVC (l’annexe B de la norme fournit le formulaire de saisine de l’AFIMB.)

La publication de la version 2020 de la norme NF P99-502 intègre notamment les conséquences des lois de réformes territoriales sur la gouvernance des applications billettiques.

Une norme pour les bases de données

Transmodel - norme EN 12896 (ou Modèle de Données Européen de référence pour les opérations de Transport Public) définit le modèle conceptuel de base de données (MCD) permettant de réaliser le système central d’information d’un système de transport.

Cette norme propose une structure de référence pour organiser une base de données unique dans laquelle se trouvent toutes les données utiles au transporteur.

Elle peut être utilisée partiellement, complétée ou adaptée afin de :

• définir une base de données qui constitue le coeur du système informatique, à laquelle seront reliées des applications soit directement, soit par l’intermédiaire d’interfaces ;
• permettre la génération des messages d’échange, particulièrement lors de la mise en place des interfaces entre différents systèmes informatiques.

Transmodel forme une suite de standards avec les normes d’interface NeTEx (échange de données d’offre théorique) et SIRI (échange de données temps réel) et facilite l’interopérabilité des systèmes (1).

Dans le cadre de la révision de la norme Transmodel, il a été décidé de la scinder en 8 parties et d’étendre les domaines fonctionnels traités, afin d’assurer une totale cohérence avec NeTEx et SIRI. Ces nouveaux éléments intégrés à Transmodel sont par exemple :

• une représentation spatiale détaillée des arrêts ;
• des concepts (2) liés à l’accessibilité ;
• un modèle des équipements (3) de transport public (4) ainsi que certains aspects (5) du mode ferré longue distance ;
• un modèle pour le transport à la demande.

Sur les 8 parties prévues pour Transmodel révisé, les 3 premières parties sont publiées. Elles concernent :

• la partie 1 : les concepts communs, partagés par l’ensemble des domaines fonctionnels ;
• la partie 2 : les éléments spatiaux qui permettent de représenter la topologie du réseau de transport en commun ;
• la partie 3 : les composants temporels, tels que les courses, les horaires et les services voiture.

Elles sont disponibles auprès de l’AFNOR sous la référence NF EN 12896.

Cette nouvelle version de Transmodel est en cours d’intégration à la norme GDF (Geographic Data Files - ISO 14825)
qui modélise la voirie et constitue la base de la cartographie pour les navigateurs embarqués.

Plaquette de présentation TRANSMODEL

Pour en savoir plus reportez-vous aux sites www.normes-donnees-tc.org et www.transmodel-cen.eu (en anglais)

Notes :

(1) C’est-à-dire l’échange aisé de données entre applications

(2) Ce sont des concepts qui permettent d’exprimer l’accessibilité, soit en termes de pertinence pour les BESOINS D’UTILISATEUR spécifiques, soit en terme de limitations de l’accessibilité (par exemple disponibilité d’un ascenseur, d’un escalier roulant, présence d’annonces sonores, …).

(3) Le concept générique « EQUIPMENT » est décliné en différentes classes qui permettent de décrire à la fois les équipements fixes (par exemple des automates de vente), et les éléments embarqués (liés au véhicule). Quelques exemples de ces classes : Waiting & Luggage Equipment, Passenger Service Equipment, Ticketing Equipment, Access Equipment, Sign Equipment Models.

(4) Proposés par la norme IFOPT (EN 28701).

(5) Dans certains concepts, on introduit des éléments permettant de décrire le mode ferré longue distance. Exemple dans la classe « Submode », on introduit « international rail »

Ces échanges sont régis par la norme CEN TS 16794, disponible sur la boutique AFNOR.

Hoplink est une solution billettique qui facilite l’interopérabilité entre les réseaux de transports. Hoplink est gratuit et accessible à tous les réseaux équipés d’un système de billettique sans contact basé sur le standard Calypso, soit 125 villes dans 25 pays à travers le monde. Il permet de mettre en place une interopérabilité entre réseaux de transport, sans nécessité d’accord commercial entre eux.

Pour en savoir plus sur l’utilisation d’Hoplink, reportez-vous à la fiche Cerema « L’utilisation d’Hoplink pour développer l’interopérabilité ». Cette fiche de 8 pages date de septembre 2018, elle est disponible en téléchargement gratuit sur www.cerema.fr : pour télécharger uniquement la fiche, sélectionnez « PDF gratuit », puis « ajouter au panier ».

Les technologies mises en œuvre dans les systèmes billettiques sont en constante évolution, du fait de l’enrichissement des fonctionnalités, mais également de la mise à niveau des mécanismes de protection contre la fraude. L’interopérabilité des systèmes billettiques locaux constitue une préoccupation nouvelle, comme en témoignent le projet d’une application billettique commune aux autorités organisatrices des transports, en France, et,au niveau européen, la création récente de la «smart ticketing alliance» (STA). Les autorités organisatrices des transports prennent en compte ces évolutions dans un cadre budgétaire contraint. C’est dans ce contexte qu’elles ont souhaité le lancement par l’AFIMB d’une démarche destinée à identifier les conditions permettant d’assurer sur le long terme une meilleure capacité d’évolution des systèmes billettiques, une réduction de leur coût global et une meilleure interopérabilité. L’AFIMB a mis en place à cet effet un groupe de travail, animé par la société Spirtech. La réflexion s’est concentrée sur le «système d’acceptation billettique» ou, dans la terminologie de la norme ISO24014 (IFM), le «medium access device». Il s’agit des éléments du système billettique, tels que les valideurs ou les serveurs de vente à distance, qui mettent en relation le client et le système billettique par l’intermédiaire d’un objet portable.Les conclusions de ce groupe de travail ont pris la forme d’un référentiel «architecture et sécurité des systèmes d’acceptation billettique». L'architecture du système d’acceptation billettique décrite dans le référentiel est fondée sur les principes suivants :

• assurer l’indépendance entre le logiciel applicatif et l'équipement sur lequel il s'exécute;
• séparer les parties communes à toutes les solutions et les parties spécifiques;
• permettre la délocalisation de certaines fonctions;
• utiliser des technologies génériques;
• prendre en compte l'expérience acquise par les industriels ayant déjà intégré tout ou partie de ces principes.

De ces principes découle naturellement une architecture modulaire: le système d’acceptation billettique est constitué d’un nombre limité de modules logiciels.En premier lieu, le référentiel recense les fonctions devant être assurées par les systèmes d’acceptation billettique, puis il définit les modules logiciels de sorte que ceux-ci soient:

• spécifiques à une ou plusieurs fonctions, chaque fonction étant assurée par un seul module;
• susceptibles d’être utilisés par un large ensemble de clients;
• reliés par des interfaces normalisées réalisées par des services web;
• remplaçables par tout fournisseur.

Les services web assurent l’indépendance vis-à-vis du système d’exploitation (OS) et du matériel. Ils offrent également toute souplesse pour placer un module soit dans le terminal qui communique avec le support de titres, soit dans un équipement distant centralisant des traitements.Le groupe de travail formule enfin en conclusion du référentiel des recommandations pour sa mise en œuvre concrète. Il préconise:

• dans un premier temps, d’élaborer à partir du référentiel un recueil des exigences fonctionnelles de l’architecture modulaire des systèmes d’acceptation billettique; ce recueil d’exigences est destiné à être intégré dans les appels d’offres des autorités organisatrices;
• puis, de rédiger les spécifications fonctionnelles et techniques des interfaces et modules décrits dans le référentiel; de réaliser un démonstrateur permettant de vérifier la validité des choix techniques

--> Ce contenu est issu du document "Référentiel Architecture et Sécurité des systèmes d'acceptation billettique" (2013), produit par Spirtech pour le compte de l'AFIMB. Ce document est disponible sur demande écrite adressée au secrétaire de la Commission de Normalisation CN03, à l’adresse bntra-CN03@cerema.fr

Le document de référence concernant l'interopérabilité est celui produit par Nextendis pour le compte du BNTRA : "Interopérabilité billettique appliquée aux systèmes SI-serveur / Exigences d’implémentation" (2018).

--> Ce document est disponible sur demande écrite adressée au secrétaire de la Commission de Normalisation CN03, à l’adresse bntra-CN03@cerema.fr

Le Cerema a également publié une fiche : "L'interopérabilité des systèmes billettiques légers centrés sur le back-office" (2018), disponible gratuitement ici (fiche n°5).

Lorsqu’une autorité organisatrice de la mobilité souhaite mettre à disposition des voyageurs une application NFC émulant, sur téléphone mobile, son application billettique locale (ABL) habituellement logée dans une carte, la façon de faire classique consiste à installer un package Calypso dans un élément sécurisé du téléphone mobile (SIM ou eSE). Cette façon de faire présente le double avantage d’être totalement compatible avec les cartes, et d’avoir le même niveau de sécurité que celles-ci.

Cependant, faute d’élément sécurisé adéquat, de nombreux téléphones ne sont pas éligibles à cette solution. Pour ceux-ci, une alternative est le portage de l’application en HCE (solution d’émulation de carte s’appuyant sur la seule mémoire du mobile) – et plus précisément un portage conforme aux spécifications HCE Calypso, qui mettent en place de nombreuses mesures visant à sécuriser le HCE qui, sinon, serait inutilisable. Ces spécifications sont disponibles sur le site du support technique Calypso (https://calypsostandard.net/).

Reste une problématique : les applications billettiques locales actuelles ne permettent pas, nativement, d’héberger les signatures de sécurité imposées par la sécurisation Calypso. C’est pour pallier cette problématique que le GT4 (Groupe de Travail n° 4 de la Commission de Normalisation CN03, en charge de la billettique) a rédigé une recommandation de mise en œuvre, nommée « Gestion en HCE des applications billettiques classiques ».

Ce document est disponible sur demande écrite adressée au GT4, par l’intermédiaire du secrétaire de la Commission de Normalisation CN03 dont l’adresse est bntra-CN03@cerema.fr