Le format NDEF expliqué simplement
Approchez un tag NFC correctement encodé de n'importe quel smartphone récent : le lien s'ouvre, la carte de visite s'affiche, le Wi-Fi se connecte.
Si cela fonctionne partout de la même façon, c'est parce que les tags et les téléphones partagent un format commun : le NDEF.
Cet article explique ce que contient un message NDEF, puis va plus loin pour ceux qui veulent le détail : l'anatomie d'un enregistrement, octet par octet, et les structures TLV qui le stockent dans la mémoire de la puce.
NDEF, le langage commun du NFC
NDEF signifie NFC Data Exchange Format, le format d'échange de données défini par le NFC Forum, l'organisme qui standardise la technologie.
Son rôle est de garantir qu'un contenu écrit sur un tag pourra être compris par n'importe quel lecteur, quel que soit le fabricant de la puce ou du téléphone.
Le NDEF est aussi indépendant du matériel : que le tag soit de Type 1, 2, 3, 4 ou 5, le message qu'il transporte est écrit et lu exactement de la même manière. C'est pour cette raison que le même lien encodé fonctionne aussi bien sur un NTAG213 que sur une puce ISO 15693.
Un message, plusieurs enregistrements
Un message NDEF est un conteneur qui regroupe un ou plusieurs enregistrements.
Chaque enregistrement se compose de trois parties : un petit en-tête de quelques octets, un type qui annonce la nature du contenu (une URL, du texte, une carte de visite...), et la charge utile (le payload), c'est-à-dire le contenu lui-même.
Dans la plupart des cas, un message contient un seul enregistrement, généralement une URL, mais rien n'empêche d'en écrire plusieurs : une URL, plus un enregistrement texte, plus un enregistrement application, par exemple. Le téléphone lit les enregistrements dans l'ordre, mais la plupart des smartphones n'interprètent et n'exécutent que le premier.
Important : si vous placez plusieurs enregistrements sur un tag, mettez toujours le contenu principal en première position, sinon il sera totalement ignoré par le téléphone.
Les types d'enregistrements les plus courants
Voici les principaux types de contenus pour un tag NFC :
- URL / URI : ouvre un site web.
- Texte : affiche du texte.
- vCard : ajoute un contact (nom, téléphone, email, ...).
- Wi-Fi / Bluetooth : connecte à un réseau ou à un appareil.
- MIME / Media : transporte des fichiers bruts ou des formats de données.
- Type externe : stocke des données personnalisées, propres à une application.
- AAR (Android) : lance une application Android ou ouvre le Play Store (ignoré par les iPhone).
Note : la plupart des actions spécifiques (réseaux sociaux, paiements, liens personnalisés) reposent en réalité sur des enregistrements URL ou MIME.
Anatomie d'un enregistrement URL
Le NDEF a été conçu pour des puces où chaque octet compte, et les URL bénéficient d'une optimisation dédiée : les préfixes les plus courants sont remplacés par un code d'un seul octet. Le « https://www. » entier devient le code 02. Résultat : l'adresse complète https://www.wakdev.com ne prend que quinze octets.
Ces quinze octets se composent de : quatre octets d'en-tête (D1 01 0B 55, qui annoncent un enregistrement unique de type U pour URI avec onze octets de contenu), le code préfixe 02, puis les dix caractères de wakdev.com. C'est cette compression qui permet à une petite puce de 64 octets de contenir un lien court, et à un NTAG213 de stocker une URL d'environ 132 caractères.
Chaque bit de cet en-tête a un rôle.
Le premier octet regroupe cinq drapeaux et un champ de 3 bits. MB (Message Begin) marque le premier enregistrement du message, ME (Message End) le dernier. CF (Chunk Flag) signale un contenu fragmenté, que vous ne verrez pratiquement jamais sur un tag. SR (Short Record) indique un enregistrement court dont la longueur tient sur un seul octet. IL (ID Length) annonce la présence d'un identifiant optionnel.
Les trois bits restants forment le TNF (Type Name Format), la famille à laquelle appartient le type. Pour une URL, sa valeur est 001, celle attribuée aux types « well-known » du NFC Forum. D'autres valeurs existent pour les types MIME ou les types définis par des tiers, mais elles ne sont pas nécessaires ici.
Appliqué à notre premier octet, D1, soit 1101 0001 en binaire : MB vaut 1, ME vaut 1 (l'enregistrement est seul, il ouvre et ferme donc le message), CF vaut 0, SR vaut 1 (format court), IL vaut 0 (pas d'identifiant), et TNF vaut 001 (type well-known).
Viennent ensuite la longueur du type (01 : un seul caractère), la longueur de la charge utile (0B : onze octets, écrite sur un seul octet grâce au drapeau SR ; un enregistrement long en utiliserait quatre), puis le type lui-même : U (0x55), la lettre qui annonce une URI.
La charge utile ferme l'enregistrement. Pour une URL, sa structure est simple : un premier octet pour le code préfixe (02 pour https://www.), puis le reste de l'adresse caractère par caractère, un octet chacun (les dix octets de wakdev.com).
Onze octets au total, exactement ce que la longueur annonçait. Dans un message à plusieurs enregistrements, seul le premier porte MB et seul le dernier porte ME : c'est ainsi que le lecteur sait où le message commence et où il se termine.
Les TLV : ranger le message en mémoire
Sur les tags de Type 1, 2 et 5, le message est stocké en mémoire à l'aide de structures TLV, pour Tag-Length-Value : chaque information est précédée d'un octet T qui annonce sa nature et d'un octet L qui donne sa longueur. Le message NDEF voyage dans un TLV de type 03. Un TLV Terminator (FE) marque la fin des données utiles, et quelques autres types servent à l'intendance : 00 pour un octet nul de remplissage, 01 et 02 pour décrire les zones mémoire verrouillées et réservées. La longueur L tient sur un octet jusqu'à 254 octets de contenu ; au-delà, elle passe en format long (FF suivi de deux octets), ce qui autorise des messages de plusieurs kilooctets sur les puces plus grandes.
Tout en haut de la mémoire se trouve le Capability Container (CC), quatre octets qui présentent le tag au lecteur : l'octet magique E1, la version du format (10), la capacité de la zone NDEF exprimée en multiples de huit octets, et les droits d'accès. Sur un NTAG213, le CC contient E1 10 12 00 (0x12, soit 18, fois 8 : 144 octets de zone NDEF, avec lecture et écriture libres). La mémoire utilisateur enchaîne ensuite avec 03 (un message NDEF arrive), 0F (quinze octets), les quinze octets de notre URL wakdev.com, et FE (fin des données). Trois octets d'enrobage autour du message : c'est tout le mécanisme. Les autres familles de tags emballent les choses différemment mais suivent la même logique : le Type 3 décrit son message dans un bloc d'attributs de 16 octets, et le Type 4 le stocke dans de véritables fichiers (un fichier CC et un fichier NDEF), accessibles via des commandes APDU.
Écrire du NDEF sans se soucier des octets
En pratique, vous n'aurez jamais à assembler ces octets vous-même. Avec l'application NFC Tools, sélectionnez « Écrire », ajoutez un ou plusieurs enregistrements (une URL vers https://www.wakdev.com, un enregistrement texte, etc.), puis approchez le tag : l'application compose le message, les en-têtes, les TLV et le Capability Container conformément à la spécification, et le résultat est lisible par tous les smartphones compatibles.
Côté lecture, Android reconnaît nativement les tags NDEF. Sur iPhone, la lecture automatique en arrière-plan fonctionne à partir des iPhone XS et XR, et NFC Tools permet de lire et d'écrire à partir de l'iPhone 7 sous iOS 15.6 ou plus récent, en lançant le scan depuis l'application.
À retenir
Le NDEF se résume à quelques éléments : un message, un ou plusieurs enregistrements typés, un en-tête où chaque bit a une fonction, et des TLV qui rangent le tout en mémoire derrière un Capability Container de quatre octets.
C'est ce qui garantit qu'un tag encodé aujourd'hui sera compris par les téléphones de demain, quelle que soit la puce qui le porte. Et comme NFC Tools écrit du NDEF strictement standard, TLV et en-têtes compris, vos tags fonctionneront partout.
