LECTEUR OU COUPLEUR ?
Dans le monde de la carte sans contact - comme dans celui de la carte à puce -, il est fréquent d’appeler simplement « lecteur » l’objet électronique qui alimente la carte et communique avec elle.
Mais comme souvent avec la technologie, ce vocabulaire d’usage ne traduit pas fidèlement le rôle ou la complexité de cet objet. Tâchons d’y voir plus clair...
LIRE, MAIS PAS QUE...
Tout d’abord, une carte à puce, qu’elle soit à contact ou sans contact, ne se lit pas comme on lirait un fichier sur une clé USB ou un secteur sur une disquette.
Une carte se contente de répondre à un certain nombre de commandes plus ou moins normalisées, souvent après un processus d’authentification, voire dans le cadre d’une communication chiffrée.
Si certaines commandes permettent effectivement de lire, d’autres servent à écrire, manipuler le solde d’un compte, vérifier la validité d’un abonnement… Le choix des commandes, et donc du type de transaction à réaliser, ne concerne finalement pas le « lecteur » mais l’application qui le pilote.
COUPLEUR VS SMART READER
L’application qui pilote le « lecteur » tourne sur un système hôte (généralement un PC) et voit le « lecteur » comme une passerelle technique permettant d’envoyer des commandes à la carte et de récupérer les réponses à ces commandes.
Les normes ISO ont consacré le mot coupleur (coupling device en anglais) pour cette passerelle technique, qui est finalement bien plus qu’un simple « lecteur ».
SCHÉMA DE FONCTIONNEMENT D'UN COUPLEUR
La logique applicative se trouvant dans le PC, cette solution offre davantage d'évolutivité. Le coût sera celui du développement.
Chez SpringCard, les « smart readers » désignent des produits qui associent un coupleur et un petit applicatif embarqué. Ils sont capables d’effectuer une transaction simple avec la carte en toute autonomie, et en ressortent un numéro ou un identifiant court conforme aux attentes du système de traitement.
SCHÉMA DE FONCTIONNEMENT D'UN « SMART READER »
La logique applicative se trouvant intégrée au « smart reader », cette solution offre une mise en oeuvre rapide mais à l'évolutivité limitée.
Il existe beaucoup de cas où l’architecture {coupleur + système hôte} est peu pertinente.
C’est par exemple le cas quand un système hôte existant n’est pas assez rapide ou n’a pas la capacité mémoire nécessaire pour effectuer lui-même les transactions avec les cartes.
C’est encore le cas lorsqu’on ne s’intéresse pas à la carte pour autre chose qu’un numéro ou autre identifiant court : pour des raisons de coût ou d’évolutivité du système, le « lecteur » de carte doit alors être plus ou moins interchangeable avec un lecteur de code barre ou de piste magnétique.
FOCUS SUR LES PRODUITS SPRINGCARD
Les produits « smart readers » s'identifient chez SpringCard à leur suffixe /RDR dans leur nom ou à l’appellation RFID Scanner pour les produits émulant un clavier USB.
Tous nos produits dont le nom comporte « PC/SC » sont des coupleurs. Ils répondent au standard d’interopérabilité PC/SC qui unifie la mise en oeuvre des coupleurs contact ou sans contact en environnement PC.
D’autres produits, comme le module K663 et la CSB4, sont également des coupleurs mais fonctionnent selon un protocole propriétaire à SpringCard.
Vous constaterez que de nombreux coupleurs et « smart readers » partagent la même électronique. Cela permet de passer d’un mode de fonctionnement à l’autre simplement en mettant à jour le firmware !
UNE PETITE HISTOIRE...
Le parking du centre ville accueille deux types des clients : les occasionnels et les abonnés. Les clients occasionnels sont traités classiquement par des tickets en carton avec piste magnétique. Les abonnés, eux, sont équipés de badges magnétiques lus par les mêmes lecteurs que les tickets en carton. Mais le système se révèle cher à l’usage : « démagnétisation » fréquente des badges, encrassement des têtes de lecture, usure des pièces mobiles…
Il est donc décidé de remplacer les badges magnétiques par des badges sans contact et de mettre un « lecteur » à chaque point de passage.
Coupleur ou smart reader ? That is the question !
Matthieu, le responsable technique du parking Léonard de Vinci, analyse l’infrastructure existante :
- pas d’informatique au niveau des barrières d’entrée et de sortie
- les lecteurs magnétiques sont reliés par de longues lignes série à un ordinateur situé dans le local du gardien
- le logiciel de gestion de parc de l’ordinateur lui donne satisfaction depuis de nombreuses années : pourquoi en changer ?
Il opte donc pour la solution « smart readers » pour équiper bornes et colonnes.
Une fois paramétrés, les « lecteurs » savent vérifier l’authenticité des cartes et renvoient le numéro d’abonné qui s’y trouve. Moyennant une évolution minime du logiciel de gestion, ils peuvent cohabiter avec les lecteurs magnétiques.
Matthieu est pleinement satisfait : pour un coût d’investissement raisonnable, il a amélioré le confort des abonnés et diminué les opérations de maintenance sur les lecteurs magnétiques.
Mais l’histoire ne s’arrête pas là...
Quelques mois plus tard, le parking du centre ville signe un partenariat avec la compagnie qui assure le transport urbain : tous les clients de la compagnie auront la gratuité du stationnement à condition de présenter en sortie leur titre de transport validé dans le tramway dans les deux heures qui précédent.
Matthieu demande au transporteur s’il possède un serveur avec une API (interface de programmation qui permet de se « brancher » sur une application pour échanger des données) qui permette de savoir si le titre interrogé est bien éligible à la gratuité.
Or, le réseau de transport ne possède pas de système dématérialisé pour la circulation de ses données : pour des raisons liées à la performances du système mais aussi de confidentialité, les données ne sont disponibles que sur les cartes.
Les « lecteurs » du parking du centre ville ne doivent donc plus simplement« lire » les cartes mais également les interroger pour identifier le type de carte : abonné parking, abonné transport, occasionnel transport.
Et pour les cartes de transport, il ne s’agit plus d’aller chercher un numéro, mais d’en vérifier la validité et de parcourir l’historique des événements pour retrouver la date et l’heure de la dernière validation sur le tram.
Pour complexifier la problématique, le schéma de mise en oeuvre du système prévoit que les « lecteurs » écrivent dans la carte un événement correspondant à l’entrée ou à la sortie du parking afin qu’une même carte ne puisse pas offrir la gratuité à plusieurs véhicules.
Matthieu doit cette fois opter pour des coupleurs et changer son logiciel pour implémenter cette logique de traitement complexe.
Et il est encore satisfait : non seulement il a apporté un service nouveau, mais il a acquis la pleine maîtrise des transactions avec les cartes et peut désormais faire évoluer son schéma applicatif sans limite.
À ce qu’il paraît, Matthieu songe à dématérialiser ses badges d’abonnés sur smartphone NFC...