Pour Ken Sakamura, professeur à l’Université de Tokyo et conférencier lors du dernier congrès sur les RFID , il ne peut exister de smart tag sans une gestion à la fois stricte et planétaire de toutes les étiquettes intelligentes. Toutes, et cela englobe aussi bien les RFID HF et VHF, les NFC, les multiples périphériques de l’Internet des Objets (certains utilisant des fréquences et des protocoles totalement exotiques) et même les étiquettes code à barre EAN ou QRCode. Ce serait à la fois une architecture « intelligente » au service de l’homme et un redoutable système inquisitorial capable de fliquer, d’analyser, d’interpréter les moindres faits et gestes des usagers et des objets situés dans l’infrastructure UID2 (Ubiquitous Identifier version 2). C’est également, à l’heure actuelle, la seule porte de sortie normée et ouverte qui permette de s’affranchir des architectures propriétaires imposées par les fabricants d’étiquettes, des disparités techniques, des limitations normatives qui rendent incompatibles les codes à barre, les NFC, les RFID, les SmartMeters et autres SmartProbes passées, présentes et à venir.
L’idée du professeur Sakamura est simple : attribuer un identifiant unique de 128 bits (2E128 objets identifiables) à chaque objet connecté, indépendamment de la technologie ou technique sur laquelle il repose. Un code 128 bits tient « à l’aise » tant dans un RFID que sur un QRCode. Cette idée d’identifiant unique n’est pas nouvelle. Les adresses IP routables du réseau public, celles, plus anciennes, du réseau X25, les VID et surtout PID du monde USB… Qui dit identifiant unique pense annuaire, donc autorité d’enregistrement. Celle du projet Ucode se trouve au Japon, qui joue à la fois le rôle de TLD (Top Level Domain) et de « root », la première délégation de TLD se situant en Finlande, à Oulu. Il n’existe pas encore de SLD, serveurs de second niveau.
Mais immatriculer du composant communiquant n’est pas franchement révolutionnaire. Ce qui l’est, c’est que chaque numéro unique peut à son tour constituer une jointure sur une toute autre base de description (Wiki, page Web, base de données SQL etc.). Une requête émise par un téléphone portable peut alors, une fois aiguillée par le bon numéro UID, fournir des mégaoctets d’informations sur le produit ou le lieu « étiqueté ». En approchant un smartphone compatible NFC/RFID/lecteur optique d’un repère inséré sur une borne ou un vestige de mur, l’utilisateur lira immédiatement « La chapelle : Rasée par le Prince Noir, incendiée par les Huguenots, pillée par les Sans-culotte aux révolutions de 89, 30 et 48, est entièrement d’époque… » avec liens pointant chacun à leur tour sur les liens Wiki des différentes périodes de troubles susmentionnées. Ceci ne peut de toute évidence tenir dans les 32 K d’une étiquette RFID, la notion de jointure « a posteriori » frise donc l’idée de génie. C’est l’équivalent du « IN ADDR ARPA » de nos Domain.txt qui renvoient au nom de domaine à partir d’un simple numéro IP.
Mais le système fonctionne également dans le sens inverse et peut enrichir à chaque requête une autre base de données qui sera libre d’associer le profil du requérant, sa position géographique, la date de Relation, toutes données relatives aux autres objets satellites à l’objet IoT. C’est de la collecte de métadonnées dopée aux stéroïdes anabolisants. A un premier niveau, une relation UCR (pour Ucode) peut par exemple relier consultation, historique des précédentes requêtes et surtout, par le truchement d’un autre protocole UCR : concrètement à partir d’une étiquette « palette de biscottes », les autres étiquettes de chaque boîte de 12 paquets de biscottes, puis de chaque paquet en particulier. En allant plus avant, un « tag » noyé dans l’épaisseur d’un trottoir pourrait également signaler tant des informations géolocalisées (noms de rues avoisinantes, historique du lieu …) mais aussi la liste des magasins proches, des biens vendus dans lesdits magasins (dont les fameuses biscottes) etc. Il n’existe aucune limite dans la « profondeur » avec laquelle ces relations UCR peuvent être enchaînées et interrogées et qui sont à même de générer à leur tour des liens d’informations. UID, c’est l’hypertext des objets de l’IoT. Les âmes sensibles peuvent craindre que ce profil ne soit complété par les récents achats stockés dans la mémoire de la carte de crédit possédée par le requérant, l’historiques des derniers trajets, les habitudes de consommation, les fréquentations géographiques (Synagogue, Temple ou église, local syndical, clubs privés), dans le but de de parfaire le profil. Et compte tenu de la rapidité de non-réaction des organismes chargés de la surveillance des libertés individuelles (voir le précédent des NFC bancaires en France), il serait surprenant que personne n’ose piocher dans cette manne d’indiscrétions. D’ailleurs, si la « norme » UID définit les interactions entre serveurs d’identifiants et serveurs de contenus associés, elle n’en légifère aucun aspect.
Car la gestion des numéros UID elle-même est strictement encadrée par quelques RFC (RFC6588 notamment), normes Japonaises, recommandations ITU (H642), API de requêtes vers les TLD, intégration avec d’autres architectures tel OpenStack. Des normes qui évitent d’esquisser tout cadre précis destiné à policer les bases de contenus complémentaires que souhaiterait ajouter qui le vendeur de biscottes, qui la municipalité dispensatrice d’étiquettes radio d’informations. L’application mobile chargée d’émettre les requêtes ne doit respecter que le bon usage des API servant à dialoguer avec les TLD UID2… le reste est à l’avenant de l’auteur de « l’app », flicage compris ou non. Et le nombre de systèmes de gestion pouvant être concerné par une simple requête est quasi illimité. A titre d’exemple, un projet expérimental déployé au Japon reposent sur 5 plateformes : Kokosil, qui gère les informations d’emplacement et les relations entre ces différents emplacements, Monosil, qui supervise les objets eux-mêmes et les relations entre objets (l’écosystème des objets disposant d’un identifiant UID2), Kotosil qui administre et délivre les « contenus » ou informations complémentaires, Daresil qui jongle avec les utilisateurs, groupes d’utilisateurs et relations inter-utilisateurs du réseau UID2, et Kachisil, chargée de s’occuper des comptes et accès aux services payants (car à l’instar de tout service de fourniture de contenu transitant par une « app » pour téléphone mobile, il peut être envisageable de facturer lesdits contenus, remember le Minitel). Une interrogation, 5 requêtes associées, autant de remontées de métadonnées.
Pour l’heure, un tel projet est embryonnaire, mais, à l’exception de quelques concurrents conçus par quelques grandes administrations (la NSA notamment, et très probablement un projet approchant chez Google), il n’existe pas de réel équivalent au système Ucode/UID2. Les chances pour qu’il soit un jour adopté aux USA et en Europe ne sont pas nulles. Et quand bien même cette initiative du professeur Ken Sakamura se solderait par un échec qu’il y a trop à gagner en termes d’analyse Big Data qu’une architecture concurrente ne puisse voir le jour. Certes, les vendeurs d’étiquettes résisteront encore quelques temps, dans l’espoir de voir leur solution propriétaire l’emporter sur une réponse normée, internationale et ouverte. Mais la pression du marché sera plus forte, celle effectuée par les grands utilisateurs qui déjà emploient parfois quatre ou cinq technologies de marquage différentes et souhaitent un peu plus qu’un retour sur investissement limité à la logistique.
