Un téléphone peut-il lire le tag d'un livre de bibliothèque ?

La famille qu'un téléphone lit déjà

Les bibliothèques se sont fixées sur les cartes de voisinage, ISO/IEC 15693, parce qu'un portique doit lire un tag à l'intérieur d'une couverture pendant qu'une personne le franchit, et la page des cartes de voisinage expose pourquoi cette catégorie convient au travail. Le NFC Forum a adopté la même famille comme Type 5, que recense la page des types de tags.

Un téléphone rencontre donc un tag de bibliothèque comme un tag ordinaire qu'il prend en charge, et non comme un objet étranger. C'est l'inverse d'une puce de chronométrage, qui vit dans une tout autre bande et qu'aucun téléphone ne lira jamais.

Ce qu'un téléphone n'obtient pas, c'est la distance. La norme a été conçue autour d'une grande antenne fixe, et un téléphone en apporte une petite, donc le contact reste un contact. Le portique lit à un mètre parce que le portique fait un mètre de large.

Des blocs, pas une notice de catalogue

Un tag de bibliothèque n'est pas écrit en NDEF, donc rien sur lui n'est une adresse web et rien n'ouvre de page. Il porte un identifiant unique fixé à la fabrication et un petit bloc de mémoire écrit par le système de la bibliothèque.

Ce que contient cette mémoire est fixé par un modèle de données de bibliothèque plutôt que par les spécifications NFC : un numéro d'exemplaire, la bibliothèque propriétaire, parfois un numéro de partie pour un ensemble en plusieurs volumes. Une application de téléphone qui n'implémente pas ce modèle affiche les octets bruts, ce que voit la plupart des gens qui essaient.

Le numéro d'exemplaire n'est pas le titre du livre. Passer de l'un à l'autre demande le catalogue de la bibliothèque, qui appartient à la bibliothèque, et cette séparation est voulue.

L'octet que lit le portique

Les cartes de voisinage portent sur un octet un identifiant de famille d'application, et il est plus utile qu'il n'en a l'air. La pile NFC d'Android et ses définitions de commandes en montrent tout le mécanisme : une commande d'inventaire peut être envoyée avec l'identifiant de famille d'application présent, pour que seuls les tags portant cette valeur répondent, et deux commandes distinctes l'écrivent puis le verrouillent contre toute modification ultérieure.

Un lecteur peut donc trier une population de tags sur un seul octet sans lire la moindre mémoire, et un portique peut décider si un exemplaire a le droit de quitter le bâtiment sans rien demander à une base de données.

La même réponse rend aussi un identifiant de format de stockage des données, qui dit à un lecteur comment la mémoire est organisée. Entre les deux octets, un portique sait ce qu'il regarde avant d'avoir lu un bloc.

C'est pourquoi la fonction antivol d'un tag de bibliothèque n'est ni un ruban séparé ni une seconde puce : c'est une valeur dans le tag, changée quand l'exemplaire est emprunté et rechangée quand il revient.

Ce qu'il ne faut pas faire d'un tag de bibliothèque

Ne pas y écrire. Un téléphone sait écrire sur un tag Type 5 dont la mémoire n'est pas verrouillée, et un livre emprunté n'est pas à vous pour le reformater : réécrire un bloc, ou l'identifiant de famille d'application, sort l'exemplaire de la circulation jusqu'à ce qu'un bibliothécaire le répare. La page du verrouillage explique pourquoi les dégâts ne sont pas toujours réparables de votre côté.

Lire est une autre affaire, et c'est là que se tient la préoccupation ancienne de la profession pour la vie privée. Un tag répond à quiconque en approche un lecteur, donc un numéro d'exemplaire dans un sac peut être lu par quelqu'un debout à côté de vous, et la page du suivi expose ce que cela permet et ne permet pas.

La défense est celle décrite plus haut : le tag porte un numéro plutôt qu'un titre, et l'emprunteur n'y figure nulle part. Ce qu'un inconnu apprend est qu'un exemplaire existe, pas ce qu'il est ni qui l'a.