Hardware
TestTesteur NFC
Testez vos étiquettes NFC depuis le navigateur via l'API Web NFC. Lisez et écrivez des enregistrements NDEF (texte, URI) et verrouillez les tags en mode lecture seule. Compatible Chrome Android en HTTPS.
Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons toutÀ propos du Testeur NFC
Testez et interagissez avec vos tags NFC directement dans le navigateur grâce à l'API Web NFC (NDEFReader). Lisez des enregistrements NDEF (texte, URI, MIME), écrivez de nouveaux contenus et verrouillez les tags en lecture seule. Parfait pour les développeurs NFC, projets IoT et tests d'étiquettes sans contact sur Android.
How to use:
- Utilisez Chrome 89+ sur Android avec HTTPS.
- Touchez « Lire le tag » et approchez votre appareil d'un tag NFC pour lire ses enregistrements NDEF.
- Consultez toutes les informations : type, ID, numéro de série et enregistrements (texte, URI, MIME).
- Pour écrire, choisissez le type d'enregistrement (texte ou URI), saisissez le contenu puis « Écrire sur le tag ».
- Approchez un tag NFC inscriptible pour enregistrer le nouvel enregistrement NDEF.
- Utilisez « Verrouiller » pour basculer le tag en lecture seule (opération irréversible).
- Touchez « Arrêter le scan » pour mettre fin à un scan actif et éteindre la radio NFC afin d'économiser la batterie.
- Suivez toutes les actions dans le journal et utilisez « Exporter CSV » ou « Exporter JSON » pour enregistrer un rapport de test QA.
Compatibilité navigateur
- Chrome pour Android 89+ : support complet
- Edge pour Android : compatible (Chromium)
- Navigateurs desktop : non pris en charge
- Safari/Firefox : non compatible
- HTTPS obligatoire (top-level uniquement)
- Interaction utilisateur nécessaire pour lancer le NFC
Références techniques
- MDN Web NFC API : https://developer.mozilla.org/fr/docs/Web/API/Web_NFC_API
- Chrome for Developers - Web NFC : https://developer.chrome.com/docs/capabilities/web-apis/nfc
- Spécification Web NFC : https://w3c.github.io/web-nfc/
- Spécification du format NDEF : https://nfc-forum.org/our-work/specification-releases/specifications/nfc-forum-assigned-numbers-register/
Questions Fréquemment Posées
L'outil utilise l'API Web NFC pour lire et écrire des enregistrements NDEF (Format d'Échange de Données NFC) sur des étiquettes NFC passives comme NTAG213, NTAG215, NTAG216, MIFARE Ultralight et de nombreuses étiquettes ISO 14443A. Lorsque vous tapez une étiquette contre le dos du téléphone, le navigateur expose les enregistrements à l'intérieur — typiquement texte, URI ou charges MIME. Vous pouvez aussi écrire vos propres enregistrements et éventuellement verrouiller l'étiquette en lecture seule de manière permanente. L'outil n'effectue pas d'émulation de carte (il ne peut pas prétendre être une carte de crédit ou un pass de transport) et il ne prend pas en charge les opérations lecteur/écrivain sur des étiquettes cryptographiques avancées comme MIFARE DESFire ou les cartes à puce sans contact ISO 14443B, car Web NFC est volontairement limité à NDEF.
Les étiquettes NFC sont peu coûteuses (environ 10–50 centimes pièce) et de plus en plus utilisées dans les étiquettes de détail, cartes de visite, affiches intelligentes, déclencheurs domotiques, expositions de musée et authentification de produits. Tester importe parce que les étiquettes proviennent de nombreux fournisseurs avec des tailles de mémoire, états de protection en écriture et données préchargées variables. Avant de déployer des étiquettes en production, vous voulez vérifier la capacité (NTAG213 a 144 octets de mémoire utilisateur, NTAG216 a 888 octets), confirmer que l'étiquette accepte votre charge NDEF et vérifier que l'appareil que vous voulez supporter se déclenche réellement au tap. Tester aide aussi à déboguer les pannes : une étiquette qui "cesse de fonctionner" peut simplement avoir été verrouillée accidentellement, manquer de mémoire ou avoir une antenne physiquement endommagée.
Trois propriétés dominent : capacité mémoire, fiabilité de scan et facteur de forme. NTAG216 avec 888 octets de mémoire utilisateur contient de longues URLs, vCards ou plusieurs enregistrements ; NTAG213 avec 144 octets convient pour des URLs courtes mais rejettera des charges plus grandes avec une erreur d'écriture. La fiabilité de scan vient de la taille d'antenne — des antennes circulaires plus grandes (≥25 mm) lisent à plus grande distance et tolèrent un désalignement, ce qui importe pour affiches et emballages où les utilisateurs n'aligneront pas parfaitement le téléphone. Le facteur de forme (autocollant, porte-clés, carte plastique, bracelet) affecte durabilité et prix. Pour les tests et prototypages quotidiens, NTAG215 (504 octets) est un point idéal — il stocke environ une vCard ou une longue URL et est largement supporté par les applications style Amiibo.
Trois causes communes. Premièrement, l'URL peut être trop longue pour l'étiquette — tout ce qui dépasse la mémoire utilisateur de votre étiquette moins le surcoût NDEF (typiquement 10–20 octets) sera tronqué ou rejeté. Deuxièmement, l'étiquette peut avoir été écrite mais non verrouillée, et une tentative d'écriture ratée ultérieure a corrompu les enregistrements — réécrivez un enregistrement URI propre et réessayez. Troisièmement, votre téléphone peut avoir NFC désactivé, être en mode avion, ou le tap peut ne pas s'aligner avec la bobine NFC. Les iPhones (XS et plus récents) lisent les étiquettes NDEF en arrière-plan seulement quand l'écran est allumé et déverrouillé ; les iPhones plus anciens nécessitent l'app Raccourcis. Les téléphones Android lisent généralement les étiquettes chaque fois que l'écran est allumé, mais les économiseurs de batterie peuvent désactiver NFC dans certains profils d'énergie.
NDEF définit un petit ensemble de types d'enregistrement "bien connus". Texte (TNF=1, type "T") contient un code de langue et une chaîne UTF-8 — idéal pour de courtes notes lisibles qui ne devraient déclencher automatiquement aucune app. URI (TNF=1, type "U") contient une seule URL ou autre URI et c'est ce qui déclenche la plupart des actions automatiques : taper une étiquette URL sur un téléphone moderne ouvre généralement le navigateur sans demander. MIME-media (TNF=2) permet d'intégrer toute charge avec type MIME, comme application/json ou image/png, utile quand une app spécifique est enregistrée pour gérer ce MIME. Affiches intelligentes (TNF=1, type "Sp") enveloppent une URI avec un titre et un indice d'action. Pour la plupart des cas d'usage grand public, l'enregistrement URI est ce que vous voulez — les enregistrements texte sont largement silencieux sur iOS.
Le verrouillage écrit un bit fusible unidirectionnel dans la mémoire de configuration de l'étiquette qui empêche définitivement les écritures futures. Après verrouillage, l'étiquette devient en lecture seule et aucun lecteur NFC ne pourra jamais modifier son contenu — ni le vôtre, ni celui de quelqu'un d'autre, ni même celui du fabricant. Vous devriez verrouiller les étiquettes que vous expédiez aux utilisateurs finaux ou placez dans la nature (expositions de musée, authentification de produit, autocollants d'objets perdus) afin qu'un passant malveillant ne puisse pas écraser votre URL avec un lien de phishing. Vous ne devriez pas verrouiller les étiquettes pendant le prototypage car les erreurs sont irrécupérables. Certaines étiquettes supportent aussi la "protection par mot de passe" via un PWD 4 octets plus PACK 2 octets sur NTAG21x, qui donne une protection réversible de lecture ou d'écriture sans brûler le bit de verrouillage — utile pour les étiquettes devant être mises à jour sur le terrain mais résistantes à la manipulation occasionnelle.
Le support est inégal. Android Chrome 89+ sur téléphones avec matériel NFC supporte Web NFC complet pour lecture et écriture — c'est la plateforme cible principale. iOS Safari n'implémente pas Web NFC ; les iPhones lisent les étiquettes NDEF uniquement via des apps iOS natives ou le lecteur en arrière-plan intégré, qui ouvre des URLs mais ne peut pas les exposer à un site web. Les navigateurs bureau n'ont pas de support Web NFC car les PC n'ont pas de matériel NFC. La spécification Web NFC nécessite aussi un contexte HTTPS (ou localhost pendant le développement), et l'utilisateur doit accorder la permission par origine lors de la première utilisation. Si votre cible de test est les utilisateurs iOS, prévoyez aussi de publier une app iOS ou de compter sur la gestion d'étiquettes intégrée pour les URLs simples.
NFC est un sous-ensemble de RFID HF (haute fréquence) fonctionnant à 13,56 MHz, régi principalement par ISO/IEC 14443 (cartes de proximité) et ISO/IEC 15693 (cartes de voisinage), plus les types d'étiquettes NFC Forum 1–5. NFC ajoute le mode peer-to-peer et l'émulation de carte par-dessus la fonctionnalité RFID lecteur/écrivain plate, bien que Web NFC n'expose que le mode lecteur/écrivain contre NDEF. Les étiquettes grand public communes sont NFC Forum Type 2 (famille NTAG21x de NXP, ISO 14443A) ; Type 4 (DESFire, utilisée en transport) supporte une cryptographie plus forte ; Type 5 (ISO 15693, ICODE SLIX) lit à plus grande distance et est utilisée en bibliothèques et inventaire. RFID UHF (860–960 MHz, EPC Gen2) est un protocole complètement différent utilisé en chaîne d'approvisionnement et n'est pas adressable depuis les téléphones.
Web NFC est délibérément limité à deux choses : le message NDEF (les enregistrements texte, URI ou MIME stockés sur le tag) et le numéro de série du tag, aussi appelé UID, que ce testeur affiche sous forme de chaîne hexadécimale séparée par des deux-points comme 04:A2:1B:7C:5D:6E:80. Cet UID est lu directement depuis la puce et c'est ce que les techniciens QA et réparation utilisent pour identifier un tag physique précis dans un lot. Ce que Web NFC N'expose PAS est tout aussi important à savoir : il ne peut pas indiquer le type de puce (il ne signalera pas « NTAG215 » contre « MIFARE Ultralight »), la taille de mémoire totale ou libre, l'état de verrouillage/mot de passe ni aucune page mémoire de bas niveau. Le navigateur n'expose que NDEF plus l'UID, donc tout « type de tag » ou « capacité » affiché par un outil est une déduction, pas une lecture matérielle. Pour une identification complète de la puce, il faut une application lectrice native émettant des commandes ISO 14443 brutes, ce que la plateforme web n'autorise volontairement pas.
Oui. Chaque opération de lecture, d'écriture et de verrouillage est enregistrée dans le journal de session avec un horodatage ISO 8601, l'action effectuée, le numéro de série/UID du tag (lorsqu'il est disponible) et le type d'enregistrement NDEF décodé ainsi que sa charge. Utilisez le bouton « Exporter CSV » pour un fichier compatible tableur (colonnes : timestamp, action, serial, recordType, data) que vous pouvez joindre à un ticket de support, comparer sur un lot de tags ou importer dans une feuille de suivi. Utilisez « Exporter JSON » pour un enregistrement structuré et lisible par machine que vous pouvez alimenter dans des pipelines QA automatisés. Le nom du fichier inclut un horodatage (nfc-session-<timestamp>.csv/json) pour que plusieurs sessions ne s'écrasent jamais. Tout s'exécute localement dans le navigateur sur la pile Web NFC — aucune donnée de tag n'est envoyée — offrant aux laboratoires de réparation un artefact auditable prouvant quel UID contenait quelle charge et quand il a été vérifié.
CONNECTIVITé5
WUTOOLS