A-t-on jamais besoin d'un tag de grande capacité ?
Trois situations le justifient. Un contenu qui doit fonctionner sans réseau, plusieurs enregistrements sur un même tag, et des données qui ne sont pas du NDEF. En dehors d'elles, un tag de grande capacité porte un lien court entouré d'une mémoire vide que vous avez payée et n'emploierez jamais.
La réponse honnête est rarement
La plupart des déploiements écrivent une adresse web et rien d'autre. Une adresse entre sur la puce la moins chère du marché avec de la marge : la capacité ne devient jamais la contrainte qui mord.
Acheter de la capacité pour un lien revient à acheter de la mémoire vide. Elle ne se lit ni plus vite, ni de plus loin, ni plus sûrement.
Les trois cas
Aucun réseau au point de contact. Un tag en sous-sol, sur un bateau, dans un entrepôt sans couverture, ou lors d'un événement où la connexion s'effondre sous la charge. Si le contenu doit arriver sans qu'une requête quitte le téléphone, il doit être sur le tag, et sa taille réelle fixe alors l'exigence.
Plusieurs enregistrements sur un même tag. Chaque enregistrement porte son propre en-tête : les empiler multiplie le surcoût autant que les contenus. Le comportement des téléphones face à plusieurs enregistrements est de surcroît inégal, et ce cas mérite d'être questionné avant d'être financé.
Des données qui ne sont pas du NDEF. Une organisation propriétaire lue par votre propre logiciel, dans un système fermé dont vous maîtrisez les deux bouts. La capacité est alors ce que votre format exige et aucun des raisonnements habituels ne s'applique.
Ce que coûte d'en acheter un quand même
À l'unité, pas grand-chose. Sur une grosse commande, assez pour se voir, et l'argent n'achète rien de mesurable.
Le coût plus subtil est qu'il masque un problème de conception. Une équipe qui règle une question de taille de contenu en achetant de la mémoire ne s'est pas demandé si le contenu appartenait au tag, et cette question a d'ordinaire une meilleure réponse.
Les références de grande capacité sont par ailleurs stockées dans moins de formats : le choix peut discrètement contraindre ce que le tag peut physiquement être.
L'alternative
Écrivez une adresse courte sur votre propre domaine et laissez le serveur porter le contenu.
Le tag devient petit, bon marché et définitif. Le contenu devient illimité, modifiable et corrigeable après déploiement, ce qu'aucun stockage embarqué n'offre.
L'exception reste le cas hors ligne, et elle mérite d'être testée plutôt que supposée. Un endroit sans couverture aujourd'hui peut en avoir l'an prochain, et un endroit couvert aujourd'hui peut ne plus l'être pendant un événement.
Questions fréquentes
Une mémoire plus grande peut-elle nuire ?
Pas sur le plan du fonctionnement. Elle coûte plus cher, se décline dans moins de formats, et peut masquer une décision de conception qui méritait qu'on s'y arrête.
Un tag de grande capacité se lit-il plus lentement ?
Pas du fait de sa capacité. Ce qui prend du temps est la quantité de données réellement lues : un grand tag portant un message court se lit aussi vite qu'un petit.
Quelle taille acheter si l'on hésite ?
Mesurez votre contenu réel sur un échantillon, ajoutez de la marge, et achetez la plus petite référence qui passe. Prototyper avec dix tags coûte bien moins cher que d'en surspécifier mille.
Peut-on répartir un contenu sur deux tags ?
Rien dans la norme ne réunit deux contacts en un seul message : cela ne fonctionne donc pas comme réponse à une limite de capacité. Un contenu trop gros pour un tag appartient à un serveur.