[accueil]
Des tickets à validité limitée !
Un billet de bus/tram jamais utilisé mais périmé, vous ne comprenez pas pourquoi... A côté d'avantages majeurs, un système de billettique « sans contact » apporte aussi son lot d'effets secondaires : traditionnellement illimitée, la validité des tickets de bus jetables (ou même rechargeables) ne dépasse ainsi plus guère un an ou deux ! Et bizarrement, on ne l'avoue pas volontiers - voire pas du tout - aux usagers... Qu'à cela ne tienne, la preuve irréfutable tient en quelques lignes de Basic.
Un mouvement qui s'accélère
Dans le sillage de l'Ile-de-France, dont le passe Navigo est une indéniable réussite technique, de nombreuses métropoles régionales s'équipent de systèmes billettiques sans contact, et la contagion commence à s'étendre à des villes moyennes. Bien que la mise en service de tramways soit souvent un facteur déclenchant, les motivations sont en réalité plus profondes : réduction de la fraude, traçabilité accrue des voyageurs (à des fins purement statistiques, bien sûr), services novateurs, mais surtout gestion de l'interopérabilité et de l'intermodalité. L'utilisation d'un même ticket, d'un prix attractif, se banalise lors de correspondances entre bus, trains régionaux, tramways, autocars de ligne, voire bateaux, et même pour bénéficier de la gratuité de « parkings-relais » judicieusement situés en têtes de lignes.
Bien que transparent pour l'usager, un processus de « compensation comptable » est toutefois indispensable entre des exploitants de réseaux financièrement indépendants, parfois concurrents, et souvent subventionnés sur fonds publics.
La billettique sans contact permet de mettre en oeuvre une organisation centralisée, précise et cohérente, faisant appel soit à des passes nominatifs ou anonymes (pour les voyageurs réguliers), soit à des tickets jetables ou rechargeables un petit nombre de fois (pour les usagers occasionnels).
Parmi les acteurs de cette véritable révolution se trouvent deux grands groupes de transport (Kéolis et Véolia), deux principaux intégrateurs système (Parkeon et Vix), et bien sûr les fabricants de passes ou de tickets.
Une technologie originale
Intégrer une puce électronique sans contact et son antenne 13,56 MHz dans un ticket en papier rapidement biodégradable représentait un épineux défi technique, qui a été relevé avec brio par l'industriel français ASK. A la base de son procédé, l'impression d'éléments conducteurs au moyen d'encres à base d'argent.
Le « sandwich » d'un ticket sans contact fabriqué par ASK
Connectée à ce « circuit imprimé » pas comme les autres, une puce électronique apporte quelques centaines de bits de mémoire Eeprom, un identifiant (UID) garanti unique et réputé infalsifiable, et éventuellement des fonctions de sécurité réalisées en logique câblée. Un peu l'équivalent « sans contact » des télécartes, en somme, offrant par conséquent des possibilités de bricolage au moins aussi étendues.
La puce électronique SRT512, vue au microscope après extraction
Sans surprise, STMicroelectronics est l'un des principaux fournisseurs des composants mis en oeuvre, le plus courant étant le SRT512. L'un des moins coûteux, aussi, car le budget est extraordinairement serré, le prix de vente du ticket dépassant rarement 1,50 euro. Certains opérateurs ajoutent 0,30 euro au prix du transport pour la fourniture du « support », afin d'inciter à le recharger (en général jusqu'à quatre fois), mais d'autres l'incorporent d'office dans le prix du billet ou le laissent discrètement à la charge du contribuable épongeant le déficit d'exploitation. Un choix « politique », en fin de compte !
Conformément à une norme aucunement confidentielle dite « Intertic », la mémoire du ticket est partitionnée en une zone « distribution » et une zone « usage ». Dans la première, sécurisée par un certificat cryptographique (32 bits), l'équipement procédant à l'encodage du ticket inscrit les caractéristiques du « contrat » liant le transporteur au voyageur, ce dernier devant naturellement être informé de l'intégralité de ses conditions. Par un « arrêté tarifaire » voté par les élus de la collectivité territoriale pour les conditions générales, et par des mentions imprimées ou consultables sur un automate pour les conditions particulières. C'est juridiquement incontournable !
Dans la seconde, un « évènement de transport » horodaté s'enregistre lors de chaque présentation du ticket devant un valideur, que ce soit au départ, à chaque correspondance, ou parfois aussi à la sortie. Lors des contrôles également, les contrôleurs étant équipés de lecteurs portables dont il serait fort périlleux de sous-estimer la puissance informatique...
La « zone usage » est en général assez vaste pour accueillir deux évènements de transport, dont un nouveau viendra écraser le plus ancien. En cas d'échec d'écriture (éloignement prématuré du ticket), le dernier en date reste donc inchangé, ce qui permet de réitérer la tentative de validation comme si de rien n'était (mécanisme dit « anti-arrachement »). Chaque évènement de transport est authentifé par son propre certificat cryptographique (16 bits), dont le calcul (par un « module de sécurité » baptisé SAM) tient compte du numéro de série unique du ticket, et du contenu d'un ou deux compteurs à écriture irréversible, qui change lors de chaque validation ou rechargement. Même lorsque la lecture et l'écriture sont totalement libres, il peut donc suffire de modifier un seul bit pour que le ticket devienne « incohérent », et soit par conséquent refusé à la validation ou même au rechargement. A bon entendeur...
A0000010
25091220
0C019599
00000000
00000000
04000000
FFFFFFFD
00000000
00000000
0000B689
AB93D018
82B60004
E70F14F5
04000000
00002EE8
7A0A516A
Exemple de contenu d'un ticket validé une seule fois (en gras : les trois certificats cryptographiques, en italiques : les deux compteurs)
Lire et écrire dans les tickets !
Effacer et ré-écrire la mémoire de tickets usagés présente un très grand intérêt pour toutes sortes d'expérimentations personnelles hors du domaine des transports, mais là n'est pas notre propos aujourd'hui. Nous y reviendrons, c'est promis !
Lire un ticket au cours de sa vie normale est fort riche d'enseignements, mais l'interprétation de son contenu passe par une compréhension approfondie de la norme Intertic : au bas mot plusieurs semaines de travail à temps plein, et des dizaines d'essais sur le terrain si l'on part de zéro...
Trouver un lecteur contactless compatible avec le SRT512, et cela à un prix abordable, constitue naturellement un pré-requis incontournable. C'est là que l'on se rend compte à quel point la mentalité (et la confiance) des acteurs du monde de la carte a évolué, depuis l'obscure époque où il était question d'interdire la détention de lecteurs de cartes à puce, sous prétexte qu'ils pourraient servir à pirater la télévision à péage ou... la carte Vitale ! En effet, de plus en plus d'exploitants de réseaux proposent à leurs clients d'acheter en ligne leurs titres de transport, et vendent à prix coûtant des lecteurs utilisables à domicile, y compris pour tout autre chose. Bravo !
Depuis octobre 2011, chacun peut ainsi se procurer l'excellent LoGO d'ASK sur la boutique en ligne de CITURA, l'opérateur des transports en commun du grand Reims. Cela, à condition d'acheter auparavant (au prix de 5 euros) la carte Grand R, sans nécessité aucune d'habiter la région. Bref, une aubaine !
Le lecteur sans contact LoGO d'ASK
Moyennant une programmation appropriée (en ZCBasic, bien sûr !), le LoGO se révèle capable de lire non seulement les cartes Calypso (y compris le Navigo malgré son protocole antédiluvien dit B'), mais aussi les tickets jetables à SRT512. Cependant, leur rechargement à domicile n'est pas à l'ordre du jour...
Bien évidemment, nous avons longuement cherché (et finalement trouvé) une pirouette informatique permettant d'utiliser aussi, en concurrence, le lecteur Omnikey 5321 puisque faisant partie des kits BasicCard dual interface, il est déjà relativement répandu chez les pionniers du sans contact.
Un « juge de Paix » !
Selon la norme Intertic, il peut exister de nombreuses variantes de formatage, et cela pour chaque modèle de puce électronique susceptible d'équiper un ticket (SRT512, CTM512, CTS512, SRIX512, SRIX4K, et même Mifare ultralight). Et des sous-variantes se rencontrent également selon les catégories de titres de transport : voyage unique, carnet de 10 voyages, ticket journée, etc.). Pas question de gérer tout cela en quelques lignes de Basic, car il faudrait développer un « parseur » fort complexe dont l'utilité pratique serait de toute façon limitée pour le simple particulier. Le programme VALTIC que nous avons mis au point supporte pour l'instant les seuls tickets à SRT512 dans leurs différentes variantes de formatage. Autant dire qu'il est compatible avec les tickets jetables de tous les exploitants français qui ont bien voulu nous confier des échantillons, et très vraisemblablement avec bien d'autres, existants ou à venir. Et rien n'interdit de le faire évoluer si nécessaire !
Un ticket d'Angers
Un ticket de Dijon
Un ticket du Havre
Un ticket de Reims
Il faut savoir que la mémoire d'un SRT512 est organisée en 16 blocs de 32 bits, numérotés de 0 à 15, que le LoGO peut lire au moyen d'une simple commande Read Binary inspirée de celle définie dans la spécification PC/SC 2.0. Les blocs 5 et 6 sont occupés par deux compteurs, dont la lecture peut renseigner sur le nombre de fois que le ticket a été validé et/ou rechargé. A explorer absolument dans une seconde phase !
Le bloc n°0 jouant un rôle particulier (« zone système », notamment), c'est par le bloc n°1 qu'il faut commencer la lecture. En progressant, on trouvera, dans l'ordre :
- 24 bits identifiant « l'entité émettrice » du ticket et son pays (250h pour la France),
- 6 bits codant le numéro de version de l'application (autrement dit de la norme Intertic),
- 8 bits identifiant le fournisseur du contrat de transport.
- 16 bits définissant le type de tarification,
- 14 bits fixant la date de fin de validité du support (et non pas du contrat).
Nous y sommes ! Cette date est exprimée en nombre de jours à compter du 1er janvier 1997, pour des raisons « historiques » liées au déploiement de la billettique sans contact en région parisienne. Le maximum étant de 16383, cela nous projette jusqu'en 2041, ce qui peut paraître plus que confortable lors d'une lecture hâtive.
Oui mais voila, les « évènements de transport » qui sont inscrits dans la zone « usage » sont horodatés à raison de 11 bits pour l'heure (à compter de minuit) et de seulement 10 bits pour la date, exprimée en nombre de jours restants jusqu'à la date de fin de validité précitée...
Le « delta » maximum étant par conséquent de 1023 jours, la date de fin de validité ne peut pas être fixée à beaucoup plus d'une trentaine de mois après la date de première utilisation du ticket, elle-même postérieure ou identique à sa date de vente, elle-même postérieure ou identique à sa date d'encodage.
Bien compris ? Visiblement pas par tout le monde, à commencer par bon nombre de décideurs dont l'informatique n'est pas le métier ! Appliquant scrupuleusement la norme, avec d'ailleurs une bonne marge de sécurité, les intégrateurs semblent avoir programmé la plupart de leurs équipements d'encodage pour qu'ils octroient une durée de vie de deux ans, ou au mieux de 31 mois, aux tickets qu'ils produisent. Loin, très loin, donc, de la validité illimitée à laquelle les usagers avaient été habitués, et qui n'a généralement été contredite ni par les arrêtés tarifaires votés de bonne foi par les élus, ni par les conditions contractuelles diffusées par les exploitants.
Un exemple d'arrêté tarifaire voté par des élus locaux
Très embarrassant, donc, même si cela ressemble davantage à un malentendu qu'à un scandale, en dépit de choix peut-être discutables dans l'élaboration de la norme. Certes, le mécanisme du « delta » est astucieux, mais cela valait-il la peine de condamner délibérément la notion de validité illimitée pour économiser quelques bits sur un total de 512, tout en étant aussi généreux au niveau d'autres champs de données ? A croire que c'était voulu, dans le but de favoriser les supports plus durables que sont ces fameux « passes » (parfois gratuits) dans lesquels toutes les dates sont classiquement codées sur 14 bits (spécifications Calypso).
Ne tournons donc pas autour du pot : les tickets jetables sont manifestement destinés à être utilisés rapidement après leur achat ou leur rechargement. Cela va sans dire, paraît-il, mais encore mieux en le disant, même si c'est impopulaire...
#Include CARDUTIL.DEF
#Include COMMERR.DEF
#Include MISC.DEF
Declare Command &HFF &HCA UID(S$)
Declare Command &HFF &HB0 RBIN(S$)
Public V As Long, P As Byte
ComPort=101
REM (c)2013 Patrick GUEULLE
CLS:PRINT"VALTIC (pour lecteur LoGO ASK)":PRINT
Call WaitForCard:Call Sleep(100):ResetCard
Print:Print:Print "Le ticket ";
Call UID(P1P2=&H0000,Lc=0,S$,Le=8)
If SW1SW2<>&H9000 Then Print "est inconnu !":Goto Fin
Print"Numero ";
For F=1 TO 8
C$=MID$(S$,F,1):C=ASC(C$):C$=HEX$(C)
IF LEN(C$)=1 then C$="0"+C$
Print C$;
Next F:Print" ";
If Right$(S$,2)<>Chr$(&H02)+Chr$(&HD0) Then Print"est inconnu !":Goto Fin
R$=Mid$(S$,6,1):R=Asc(R$) And &HFC
If R<>&H30 Then Print"est inconnu !":Goto Fin
Print:Print
Call RBIN(P1=0,P2=1,Lc=0,S$,Le=4):Call CheckSW1SW2
If Right$(S$,1)<>Chr$(&H25) Then Print"est inconnu !":Goto Fin
Call RBIN(P1=0,P2=2,Lc=0,S$,Le=4):Call CheckSW1SW2
V$=Mid$(S$,2,1)+Mid$(S$,1,1)
Call RBIN(P1=0,P2=0,Lc=0,S$,Le=4):Call CheckSW1SW2
C$=Left$(S$,1)
P=ASC(C$) And &H1F
W$=Right$(S$,1)
Call RBIN(P1=0,P2=3,Lc=0,S$,Le=4):Call CheckSW1SW2
If P>16 Then W$=Right$(S$,1)
V$=V$+W$:T$=""
For F=1 TO 3
C$=MID$(V$,F,1):C=ASC(C$):C$=HEX$(C)
IF LEN(C$)=1 then C$="0"+C$
T$=T$+C$
Next F
T$=Mid$(T$,2,4):V=ValH(T$) And &H3FFF
Print"est valide";V;"jours au-dela du 01/01/1997, soit :"
Print
Print" ";V-6209,"jours au-dela du 01/01/2014"
Fin:
Print:Print
Call WaitForNoCard
Compilé en un exécutable Windows VALTIC.EXE, notre code source expérimental VALTIC.BAS permet de vérifier par soi-même : lancer l'application, poser un ticket sur le LoGO, puis prendre connaissance de son identifiant et du nombre de jours de validité au-delà du 1er janvier 1997. Par commodité, nous avons ajouté une ligne exprimant cette même limite à compter du 1er janvier 2014, et il sera facile d'actualiser cette fonction si l'utilité de ce petit logiciel venait à perdurer. On ne sait jamais...
D'ailleurs, le saviez-vous ? Il est enfantin de calculer le nombre de jours séparant deux dates, en effectuant une simple soustraction au moyen d'un tableur comme Excel ou Open Office ! Les possesseurs d'un lecteur Omnikey 5321 (avec la dernière version de son driver) utiliseront pour leur part le code-source VALTICK.BAS et l'exécutable VALTICK.EXE, encore et toujours obtenu par compilation avec le kit BasicCard gratuit.
#Include CARDUTIL.DEF
#Include COMMERR.DEF
Declare Command &HFF &HCA UID(S$)
Declare Command &HFF &HA0 GEN(S$)
Public V As Long, P As Byte
ComPort=102
REM (c)2013 Patrick GUEULLE
CLS:PRINT"VALTICK (pour lecteur Omnikey 5321 avec driver 1.2.9.2)":PRINT
Call WaitForCard:ResetCard
Print:Print:Print "Le ticket ";
Call UID(P1P2=&H0000,Lc=0,S$,Le=8)
If SW1SW2<>&H9000 Then Print "est inconnu !":Goto Fin
Print"UID ";
For F=1 TO 8
C$=MID$(S$,F,1):C=ASC(C$):C$=HEX$(C)
IF LEN(C$)=1 then C$="0"+C$
Print C$;
Next F
Print" ";
If Right$(S$,2)<>Chr$(&H02)+Chr$(&HD0) Then Print"est inconnu !":Goto Fin
R$=Mid$(S$,6,1):R=Asc(R$) And &HFC
If R<>&H30 Then Print"est inconnu !":Goto Fin
Print:Print
S$=Chr$(&H01)+Chr$(&H00)+Chr$(&H01)
Call GEN(P1P2=&H0007,Lc=3,S$,Le=0):Call CheckSW1SW2
S$=Chr$(&H01)+Chr$(&H00)+Chr$(&H0B)+Chr$(&H00)+Chr$(&H00)+Chr$(&H64)+Chr$(&H08)+Chr$(1)
Call GEN(P1P2=&H0005,Lc=8,S$,Le=0):Call CheckSW1SW2
If Right$(S$,1)<>Chr$(&H25) Then Print"est inconnu !":Goto Fin
S$=Chr$(&H01)+Chr$(&H00)+Chr$(&H0B)+Chr$(&H00)+Chr$(&H00)+Chr$(&H64)+Chr$(&H08)+Chr$(2)
Call GEN(P1P2=&H0005,Lc=8,S$,Le=0):Call CheckSW1SW2
V$=Mid$(S$,4,1)+Mid$(S$,3,1)
S$=Chr$(&H01)+Chr$(&H00)+Chr$(&H0B)+Chr$(&H00)+Chr$(&H00)+Chr$(&H64)+Chr$(&H08)+Chr$(0)
Call GEN(P1P2=&H0005,Lc=8,S$,Le=0):Call CheckSW1SW2
C$=Mid$(S$,3,1)
P=ASC(C$) And &H1F
W$=Right$(S$,1)
S$=Chr$(&H01)+Chr$(&H00)+Chr$(&H0B)+Chr$(&H00)+Chr$(&H00)+Chr$(&H64)+Chr$(&H08)+Chr$(3)
Call GEN(P1P2=&H0005,Lc=8,S$,Le=0):Call CheckSW1SW2
If P>16 Then W$=Right$(S$,1)
V$=V$+W$:T$=""
For F=1 TO 3
C$=MID$(V$,F,1):C=ASC(C$):C$=HEX$(C)
IF LEN(C$)=1 then C$="0"+C$
T$=T$+C$
Next F
T$=Mid$(T$,2,4):V=ValH(T$) And &H3FFF
Print"est valide";V;"jours a compter du 01/01/1997, soit :"
Print
Print" ";V-6209,"jours a compter du 01/01/2014"
Fin:
S$=Chr$(&H01)+Chr$(&H00)+Chr$(&H02)
Call GEN(P1P2=&H0007,Lc=3,S$,Le=0):Call CheckSW1SW2
Print:Print
Call WaitForNoCard
Vers une « sortie de crise » ?
En théorie, la date de fin de validité du support devrait pouvoir être ré-encodée par un équipement ayant accès à un SAM de type « distribution », mais en aucun cas par un valideur. Il nous semble donc voir là une solution élégante pour arrondir les angles sans passer par une réclamation en agence en cas d'expiration prématurée d'un titre de transport en principe « ni échangeable, ni remboursable » : offrir aux usagers une prolongation de la validité de leur ticket lorsqu'ils le rechargent (ce qui serait tout de même la moindre des choses !) ou mieux lorsqu'ils en consultent simplement le contenu sur une borne. En attendant le tramway, par exemple. Ou carrément à domicile, le LoGO étant alors piloté par une application en ligne, ayant accès au SAM approprié. Laissons donc cogiter calmement les professionnels et les élus en attendant les premières péremptions, inéluctables dans l'état actuel des choses...
Dans le cas, difficilement imaginable, où rien ne changerait sur le plan technique, il resterait évidemment possible d'informer tout bonnement la clientèle qu'en plus d'une augmentation du prix du ticket, elle doit désormais s'accomoder d'une durée de vie assez courte. Certains exploitants l'ont fait d'emblée, sous prétexte d'une prétendue fragilité de ces tickets de haute technologie, qui craignent tout au plus l'humidité et les pliages mais résistent victorieusement à la proximité d'un téléphone portable en fonctionnement. Il faut dire que l'utilisateur est contractuellement responsable de leur « bonne conservation », alors...
D'autres évoquent le risque (bien réel, celui-là) de validation intempestive de tickets conservés sur soi, si l'on passe trop près d'un valideur. Pourtant, il existe des étuis blindés, qu'il aurait pu être adroit d'offrir aux usagers lors du passage au sans contact. Mais il n'est jamais trop tard pour bien faire, n'est-ce pas ?
Patrick Gueulle
Tous les ouvrages de l'auteur
Vous voulez soutenir une information indépendante ? Rejoignez notre Club privé !
[contact & legal & cookies] [since 1997]