Le format NDEF expliqué simplement
Approchez n'importe quel 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 configure.
Cette magie apparente repose sur un ingrédient discret : le NDEF, langue commune que parlent tous les tags et tous les téléphones.
Cet article vous explique ce qui se cache dans cette enveloppe universelle, puis pour les curieux : l'anatomie exacte d'un enregistrement, octet par octet, et les fameux TLV qui l'emballent dans la mémoire de la puce NFC.
NDEF, la langue commune 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 : garantir qu'un contenu écrit sur un tag soit compris par n'importe quel lecteur, quel que soit le fabricant de la puce ou du téléphone.
Le NDEF est indépendant du matériel : que le tag soit de Type 1, 2, 3, 4 ou 5, le message qu'il transporte s'écrit et se lit de la même manière. C'est la raison pour laquelle un même lien encodé fonctionne aussi bien sur un tag NTAG213 que sur une puce ISO 15693.
Un message, des enregistrements
Un contenu NDEF s'organise comme un courrier : une enveloppe (le message) contenant une ou plusieurs cartes (les enregistrements, ou records en anglais).
Chaque enregistrement se compose de trois éléments : un petit en-tête de quelques octets, un type qui annonce la nature du contenu (une URL, un texte, une carte de visite...), et la charge utile, c'est-à-dire le contenu lui-même.
Un message peut ne contenir qu'un seul enregistrement (le cas le plus courant : une URL), mais rien n'empêche d'en glisser plusieurs dans la même enveloppe : une URL accompagnée d'un texte et d'un enregistrement d'application, etc. Le téléphone lit les enregistrements dans l'ordre, mais la plupart des smartphones n'interprètent et n'exécutent que le TOUT PREMIER enregistrement.
Important : Si vous mettez plusieurs enregistrements sur un tag, placez toujours le contenu principal en première position, sous peine qu'il soit 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 un texte.
- vCard : Ajoute un contact (nom, tél, e-mail, ...).
- Wi-Fi / Bluetooth : Connecte à un réseau ou un appareil.
- MIME / Médias : Transporte des fichiers ou formats de données bruts.
- Type Externe (External Type) : Permet d'enregistrer des données spécifiques.
- AAR (Android) : Lance une app android ou ouvre le Play Store (ignoré par les iPhone).
Note : La majorité des actions spécifiques (réseaux sociaux, paiement, liens personnalisés) reposent en réalité sur des enregistrements URL ou MIME.
L'anatomie d'un enregistrement URL
Le NDEF a été pensé pour des puces où chaque octet compte, et son astuce la plus élégante concerne les URL : les préfixes les plus courants sont remplacés par un code d'un seul octet. Ainsi, « https://www. » tout entier tient dans le code 02. Résultat concret : l'adresse complète https://www.wakdev.com occupe quinze octets seulement.
Décomposons-les : quatre octets d'en-tête (D1 01 0B 55, qui annoncent un enregistrement unique, de type U comme URI, avec onze octets de contenu), puis le fameux code 02 du préfixe, puis les dix caractères de wakdev.com. C'est cette compression qui permet à une petite puce de 64 octets de loger confortablement un lien court, et à une NTAG213 d'accueillir une URL d'environ 132 caractères.
Regardons maintenant cet en-tête à la loupe, car chaque bit y a un rôle.

Le premier octet d'un enregistrement concentre cinq drapeaux et un champ de trois bits. Les drapeaux : MB (Message Begin) marque le premier enregistrement du message, ME (Message End) le dernier, CF (Chunk Flag) signale un contenu découpé en morceaux (rarissime sur les tags), SR (Short Record) indique un enregistrement court dont la longueur tient sur un seul octet, et 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, il vaut 001, la valeur des types bien connus du NFC Forum (d'autres valeurs existent pour les types MIME ou les types définis par un tiers, mais elles ne nous concernent pas ici).
Reprenons notre premier octet D1, soit 1101 0001 en binaire : MB à 1, ME à 1 (l'enregistrement est seul, il ouvre et ferme le message), CF à 0, SR à 1 (format court), IL à 0 (pas d'identifiant), et TNF à 001 (type bien connu).
Suivent la longueur du type (01 : un seul caractère), la longueur de la charge utile (0B : onze octets, sur un seul octet grâce au drapeau SR ; un enregistrement long l'écrirait sur quatre octets), puis le type lui-même : U (0x55), la lettre qui annonce une URI.
La charge utile ferme la marche, et pour une URL elle suit une grammaire d'une simplicité désarmante : un premier octet donne le code du préfixe (02 pour https://www.), puis le reste de l'adresse s'écrit caractère par caractère, un octet chacun, soit les dix octets de wakdev.com.
Onze octets en tout, exactement ce qu'annonçait la longueur. Et dans un message à plusieurs enregistrements, seul le premier porte MB et seul le dernier porte ME : c'est ainsi que le lecteur sait où l'enveloppe commence et finit.
Les TLV : l'emballage du message dans la mémoire
Reste une question : comment ce message est-il rangé dans la mémoire brute de la puce ?
Sur les tags de Types 1, 2 et 5, la réponse s'appelle TLV, pour Tag-Length-Value : chaque information posée en mémoire est précédée d'un octet T qui annonce sa nature et d'une longueur L. Le message NDEF voyage dans un TLV de type 03 ; un TLV terminateur FE marque la fin des données utiles ; et d'autres types existent pour l'intendance (00 pour un octet de remplissage, 01 et 02 pour décrire les zones de verrouillage et de mémoire réservée). La longueur L tient sur un octet jusqu'à 254 octets de contenu ; au-delà, elle passe au format long (FF suivi de deux octets), ce qui permet des messages de plusieurs kilo-octets sur les grandes puces.
En tête de mémoire trône enfin le Capability Container (CC), le sommaire de quatre octets qui présente 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. Mettons tout bout à bout sur une NTAG213 : le CC contient E1 10 12 00 (0x12, soit 18, fois 8 : 144 octets de zone NDEF, en lecture et écriture libres), puis la mémoire utilisateur enchaîne 03 (un message NDEF arrive), 0F (quinze octets), les quinze octets de notre URL wakdev.com, et FE (terminé). L'intendance complète aura coûté trois octets autour du message : voilà toute la mécanique. Les autres familles emballent différemment mais dans le même esprit : le Type 3 décrit son message dans un bloc d'attributs de seize octets, et le Type 4 le range dans de véritables fichiers (un fichier CC et un fichier NDEF), consultés par commandes APDU.
Écrire du NDEF sans se soucier des octets
Bonne nouvelle : vous n'aurez jamais à assembler ces octets vous-même. Avec l'application NFC Tools, il suffit de choisir « Écrire », d'ajouter un ou plusieurs enregistrements (une URL vers https://www.wakdev.com, un texte,...), puis d'approcher le tag : l'application compose l'enveloppe, les en-têtes, les TLV et le Capability Container dans les règles de l'art, et le message devient 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 dès les iPhone XS et XR, et NFC Tools permet de lire et d'écrire depuis l'iPhone 7 sous iOS 15.6 au minimum, en lançant la lecture depuis l'application.
Ce qu'il faut retenir
Le NDEF est l'enveloppe universelle du NFC : un message, un ou plusieurs enregistrements typés, un en-tête où chaque bit a sa fonction, et des TLV qui rangent le tout en mémoire derrière un sommaire de quatre octets.
C'est lui 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 c'est parce que NFC Tools écrit du NDEF rigoureusement standard, TLV et en-têtes compris, que vos tags fonctionnent partout, du premier essai au millionième passage.
