Comment un smartphone lit un tag NFC : modes de fonctionnement et format NDEF expliqués

Le téléphone ne lit pas directement une mémoire : il établit une communication radio à 13,56 MHz

Un smartphone NFC intègre un contrôleur radio capable de générer un champ électromagnétique à 13,56 MHz, fréquence utilisée par les systèmes NFC et par plusieurs technologies RFID HF. Lorsqu’un tag passif entre dans ce champ, l’antenne du tag récupère une partie de l’énergie disponible. Cette énergie alimente momentanément la puce et lui permet de répondre au lecteur sans batterie propre.

La lecture ne consiste donc pas à photographier une étiquette ou à détecter simplement sa présence. Le téléphone met en œuvre une succession d’opérations radio et logiques : activation du champ, détection d’un dispositif, anticollision éventuelle, sélection d’une technologie, échange de commandes, lecture de blocs mémoire, puis interprétation des données selon un format reconnu. Cette distinction est essentielle dans un projet IoT, car une antenne visible ou une puce compatible avec 13,56 MHz ne garantit pas à elle seule une compatibilité avec un smartphone.

Le tag peut contenir des données brutes propres à son fabricant, un identifiant, des compteurs, des mesures ou un message NDEF. Le téléphone ne comprend directement que les formats pris en charge par son système d’exploitation et par son contrôleur NFC. Dans un usage professionnel, il faut donc distinguer trois niveaux : la couche radio, le protocole de communication et la structure applicative des données.

Les technologies sans contact prises en charge par les smartphones NFC

Le terme NFC recouvre plusieurs technologies proches, mais non interchangeables dans tous les cas. Les smartphones prennent généralement en charge les familles définies ou référencées par le NFC Forum, notamment NFC-A, NFC-B, NFC-F et NFC-V. Elles correspondent respectivement à des technologies issues de la famille ISO 14443 Type A, ISO 14443 Type B, JIS X 6319-4 et ISO 15693, avec des différences de modulation, de codage, de distance de lecture et de débit.

Le tableau suivant permet de situer les principaux cas rencontrés sur le terrain :

Technologie	Référence courante	Usage fréquent	Point d’attention
NFC-A	ISO 14443 Type A	Tags NFC grand public, cartes sans contact, NTAG	Très répandue dans les smartphones et les tags de proximité
NFC-B	ISO 14443 Type B	Cartes d’identification et applications sécurisées	Support variable selon les téléphones et les systèmes
NFC-F	JIS X 6319-4	Cartes de transport et systèmes régionaux	Présence plus dépendante du marché et du modèle
NFC-V	ISO 15693	Étiquettes HF à portée supérieure et applications industrielles	La distance réelle reste fortement liée à l’antenne et au tag

Un tag ISO 15693 n’est donc pas automatiquement un tag NDEF, et un tag ISO 14443 ne contient pas nécessairement un message lisible par une application mobile. Le protocole radio définit la manière d’échanger des bits ; NDEF définit ensuite une manière standard de représenter des objets applicatifs tels qu’une URL, du texte ou une donnée métier.

Les trois modes NFC : lecteur, carte et communication entre appareils

Un smartphone NFC peut fonctionner selon plusieurs rôles. Le mode le plus visible est le mode lecteur, dans lequel le téléphone génère le champ radio et interroge un tag passif. C’est le fonctionnement utilisé pour ouvrir une URL, afficher une fiche produit, lire un identifiant de maintenance ou récupérer une configuration d’équipement.

Le mode émulation de carte inverse la logique. Le téléphone se comporte comme une carte sans contact auprès d’un terminal externe. Il est utilisé pour le paiement mobile, les titres de transport, les badges dématérialisés et certaines solutions d’accès. Dans ce cas, le téléphone peut s’appuyer sur un élément sécurisé matériel, sur un environnement sécurisé intégré ou sur un mécanisme de type Host Card Emulation. Une application ne peut pas reproduire librement tous les comportements d’une carte bancaire ou d’un badge propriétaire : les exigences de sécurité, de certification et de gestion des clés sont déterminantes.

Le troisième mode est la communication de pair à pair, historiquement associé à l’échange de données entre deux appareils NFC. Il est beaucoup moins central dans les usages mobiles actuels que la lecture de tags et l’émulation de carte. Les systèmes d’exploitation modernes privilégient souvent d’autres mécanismes de proximité pour transférer des fichiers ou établir une session. Pour une architecture IoT, il est généralement plus pertinent de concevoir un tag comme point de déclenchement et d’utiliser ensuite Bluetooth Low Energy, Wi-Fi ou le réseau cellulaire pour les échanges volumineux.

La séquence réelle d’une lecture NFC par un smartphone

Lorsqu’un utilisateur approche son téléphone d’un tag, plusieurs étapes se déroulent en quelques dizaines ou centaines de millisecondes. Le contrôleur NFC active d’abord son champ et recherche des réponses correspondant aux technologies configurées. Le tag, qui fonctionne par couplage inductif, détecte le champ et répond avec une modulation de charge. Cette variation est détectée par l’antenne du téléphone.

Pour certaines technologies, le lecteur exécute ensuite une procédure d’anticollision. Elle permet de distinguer plusieurs tags présents dans le champ et de sélectionner un dispositif précis. L’identifiant radio du tag intervient dans cette phase, mais il ne doit pas être confondu avec une preuve d’authenticité. Un UID peut être lisible, clonable dans certains scénarios ou modifiable selon la famille de puces ; il ne constitue pas automatiquement une identité cryptographique fiable.

Une fois le tag sélectionné, le contrôleur échange des commandes adaptées à la technologie détectée. Selon la puce, il peut lire des pages, des blocs ou une zone mémoire organisée par fichiers. Si le tag annonce une capacité NDEF, le téléphone localise la zone de données, lit la longueur du message et récupère les octets correspondants. Le système d’exploitation analyse ensuite le type de contenu et décide de l’action : notification, ouverture d’une page, invocation d’une application ou transmission à une application spécialisée.

La distance de lecture annoncée dans une fiche technique ne doit pas être considérée comme une valeur opérationnelle universelle. Elle dépend de la taille des antennes, de leur orientation, de la puissance du contrôleur, de la présence de métal, de l’épaisseur du support, du boîtier du téléphone et du temps pendant lequel l’utilisateur maintient le téléphone en position. En production, un test avec le modèle de smartphone réellement utilisé est indispensable.

NDEF : le format qui rend un tag NFC interopérable

NDEF, pour NFC Data Exchange Format, est un format de message standardisé par le NFC Forum. Il fournit une structure commune pour transporter des informations sur des tags et entre équipements NFC. Un message NDEF contient un ou plusieurs enregistrements. Chaque enregistrement possède notamment un indicateur de type, une longueur de type, une longueur d’identifiant, une longueur de charge utile, un champ d’identifiant éventuel et la charge utile elle-même.

Le champ TNF, ou Type Name Format, indique comment interpréter le type de l’enregistrement. Un enregistrement peut utiliser un type bien connu du NFC Forum, un type MIME, une URI absolue ou un type spécifique à une application. Les indicateurs MB et ME signalent respectivement le début et la fin d’un message. Les indicateurs SR et IL permettent de gérer certains formats courts et la présence d’un identifiant.

Dans la pratique, les types les plus utilisés sont les suivants :

• URI : une adresse web, une adresse de téléchargement ou un schéma applicatif personnalisé ;
• Text : un texte accompagné d’informations de langue et d’un indicateur d’encodage ;
• MIME : un contenu associé à un type reconnu par une application, par exemple une donnée JSON ou un document métier ;
• Smart Poster : une structure combinant généralement une URI, un titre et éventuellement une information d’action ;
• type externe : un format défini par une organisation ou un éditeur pour une application particulière.

Un message NDEF n’est pas nécessairement limité à une URL. Pour une application industrielle, il peut contenir une référence d’actif, une version de configuration, un identifiant de procédure ou un lien vers une ressource distante. Il faut toutefois éviter d’y stocker des informations sensibles en clair : la plupart des tags NDEF sont lisibles par tout appareil compatible placé à proximité.

Comment un tag stocke un message NDEF en mémoire

La puce NFC ne réserve pas toujours une zone immédiatement exploitable comme un fichier. Dans de nombreux tags NFC-A de type 2, la mémoire est organisée en pages et le message NDEF est précédé d’une structure de capacité qui indique notamment la taille disponible et l’état de la zone. Le contenu est ensuite encodé dans des TLV, c’est-à-dire des ensembles type-longueur-valeur. Le TLV NDEF signale la présence du message ; des zones peuvent aussi indiquer une fin de données ou des informations réservées au fabricant.

Les tags de type 4 s’appuient généralement sur une organisation plus proche d’un système de fichiers et utilisent des commandes définies dans le cadre d’ISO 14443-4 et des spécifications NFC Forum. Cette différence devient importante lors du choix du support. Un développeur qui écrit directement des pages mémoire sans respecter la cartographie NDEF peut produire un tag détecté par le téléphone mais considéré comme mal formé ou vide par le système.

La capacité nominale annoncée par le fabricant n’est pas toujours égale à la capacité utile du message. Il faut soustraire les zones de contrôle, la structure NDEF et les éventuelles données système. Pour un simple lien, quelques dizaines d’octets suffisent. Pour un enregistrement MIME, une configuration ou plusieurs enregistrements, il faut vérifier la capacité disponible avant l’écriture.

Le cycle de vie du tag doit également être défini. Après une phase de validation, un message peut être rendu permanent par verrouillage de certaines pages ou par activation d’une protection en écriture. Cette opération est souvent irréversible. En environnement industriel, il est préférable de distinguer les tags de test, les tags réinscriptibles et les tags déployés, puis de documenter précisément la clé, la zone et la procédure de protection utilisées.

Lire un tag NFC dans une application mobile : recommandations de développement

La détection par le système d’exploitation et la lecture applicative sont deux étapes différentes. Un téléphone peut afficher une notification pour un message NDEF standard sans qu’une application métier soit installée. À l’inverse, une application peut utiliser des API bas niveau pour dialoguer avec un tag connu, lire des blocs ou exécuter des commandes spécifiques lorsque le format NDEF ne suffit pas.

Une implémentation robuste doit notamment :

1. identifier les technologies supportées par le tag avant de choisir les commandes de lecture ;
2. prévoir les erreurs de communication, les pertes de champ et les retraits trop rapides du téléphone ;
3. valider la longueur des données avant tout traitement ;
4. contrôler le type MIME ou le type applicatif au lieu de faire confiance au seul contenu ;
5. gérer les encodages de texte, les caractères non ASCII et les différences de représentation des URI ;
6. journaliser les erreurs sans enregistrer inutilement des données personnelles ou des secrets.

Sur Android, les mécanismes de découverte NFC permettent de recevoir des événements liés aux tags et d’utiliser des technologies comme NfcA, NfcB, NfcV ou IsoDep selon le matériel. Sur iOS, les API Core NFC permettent de lire plusieurs familles de tags et des messages NDEF, avec des contraintes de session et de compatibilité définies par Apple. Les comportements de déclenchement en arrière-plan et les capacités de lecture peuvent varier selon la version du système et le modèle d’appareil.

Pour une application déployée auprès de techniciens, il faut tester non seulement la lecture nominale, mais aussi les scénarios de terrain : gants, faible luminosité, téléphone protégé par une coque, tag posé sur métal, orientation variable et présence de plusieurs tags. Une bonne interface doit signaler clairement si le tag a été détecté, si le contenu est valide et si l’opération métier a réellement été enregistrée côté serveur.

NFC, sécurité et traçabilité : ce que la lecture d’un tag ne prouve pas

Un tag NFC peut déclencher une action mobile, mais cette action ne constitue pas automatiquement une authentification. Une URL NDEF peut être remplacée si le tag est réinscriptible. Un identifiant lu dans une mémoire publique peut être copié. Un tag collé sur un produit peut être déplacé vers un autre produit. Ces risques sont particulièrement importants dans la lutte contre la contrefaçon, le contrôle de maintenance et la traçabilité logistique.

Le niveau de sécurité doit être aligné sur la menace. Pour une simple redirection vers une page d’information, un tag NDEF verrouillé peut être suffisant. Pour prouver qu’un objet est bien celui enregistré dans un système, il faut envisager une puce dotée de fonctions cryptographiques, une authentification mutuelle, une signature des données ou une vérification côté serveur. Certaines familles de tags proposent des mécanismes d’authentification, de comptage ou de signature dynamique, mais leur intégration demande une analyse des clés, des procédures de personnalisation et du modèle de menace.

Une architecture efficace sépare souvent les données publiques et la décision métier. Le tag transporte un identifiant ou un jeton court. Le smartphone transmet ce jeton à un service qui vérifie son statut, son contexte, sa date d’utilisation et éventuellement les droits de l’opérateur. Cette approche permet de révoquer un identifiant, de détecter des lectures anormales et d’éviter de stocker des données sensibles dans la mémoire radio.

Dans une chaîne logistique, NFC est particulièrement adapté à l’identification de proximité, à la preuve d’une opération ou à l’accès à une fiche d’instruction. Pour le suivi massif de palettes et de colis à distance, la RFID UHF EPC Gen2, désormais référencée sous ISO 18000-63, répond généralement mieux aux besoins de lecture en volume et sans visée directe. NFC et UHF ne sont donc pas concurrents dans tous les projets : ils peuvent être complémentaires dans une architecture de traçabilité.

Choisir le bon tag NFC pour un prototype ou un déploiement industriel

Le choix d’un tag ne doit pas se limiter à la capacité mémoire ou au prix unitaire. Les critères techniques à examiner comprennent :

• la technologie radio et sa compatibilité avec les téléphones visés ;
• la capacité NDEF réellement disponible ;
• le nombre de cycles d’écriture et la rétention des données ;
• la présence de métal, de liquide ou de matériaux absorbants autour de l’antenne ;
• la résistance à la température, aux produits chimiques, aux chocs et au lavage ;
• la possibilité de verrouillage ou d’authentification ;
• la forme, l’adhésif et le procédé de pose ;
• la traçabilité de la personnalisation et du contrôle qualité.

Pour un prototype avec smartphone, une famille de tags NDEF courante permet de valider rapidement le parcours utilisateur. En revanche, un prototype convaincant ne suffit pas à valider un déploiement. Le support final peut modifier l’accord d’antenne, réduire la distance de lecture ou rendre l’écriture impossible après collage sur une pièce métallique. Les tags dits on-metal utilisent une construction adaptée, mais ils doivent eux aussi être testés sur la géométrie et le matériau définitifs.

Il est recommandé de mesurer le taux de lecture plutôt que de retenir uniquement la meilleure distance obtenue en laboratoire. Un protocole de validation peut définir plusieurs modèles de téléphones, des orientations imposées, un temps maximal de présentation, une température de fonctionnement et un pourcentage minimal de lectures réussies. Pour un usage de maintenance, la vitesse de l’opérateur et la position naturelle du tag sont souvent plus représentatives que la distance maximale annoncée par le fabricant.

FAQ : lecture NFC et format NDEF

Un smartphone peut-il lire n’importe quelle puce RFID HF ?

Non. La fréquence de 13,56 MHz ne suffit pas à garantir la compatibilité. Le téléphone et la puce doivent partager une technologie prise en charge, comme ISO 14443 ou ISO 15693, et le tag doit exposer des commandes compatibles. Une puce propriétaire ou un badge sécurisé peut nécessiter un lecteur spécialisé.

Un tag NFC doit-il obligatoirement contenir un message NDEF ?

Non. NDEF est un format d’échange standard, mais certaines applications lisent directement des blocs mémoire ou utilisent une structure propriétaire. Un téléphone peut détecter un tag sans afficher de contenu exploitable si aucune donnée NDEF reconnue n’est présente.

La lecture de l’UID permet-elle d’authentifier un produit ?

Non, pas à elle seule. L’UID sert principalement à l’identification au niveau radio et peut être copié, simulé ou insuffisant face à une attaque. Une authentification fiable demande généralement une fonction cryptographique et une vérification côté système d’information.

Pourquoi un tag fonctionne-t-il avec un téléphone mais pas avec un autre ?

Les performances dépendent du contrôleur NFC, de l’antenne, du boîtier, de la version du système et des technologies activées. La position de l’antenne dans le téléphone varie également. Un déploiement doit donc être testé sur les modèles réellement autorisés, et non sur un seul appareil de développement.

Peut-on stocker une donnée JSON complète dans un tag NFC ?

Oui, si la capacité du tag est suffisante et si l’application sait interpréter un enregistrement MIME ou un type applicatif. Toutefois, un tag a souvent une mémoire limitée. Pour une architecture industrielle, il est généralement préférable de stocker un identifiant court ou un jeton et de conserver les données métier dans un système sécurisé.