Stocker sur le tag, ou stocker sur un serveur ?
La décision la plus lourde de conséquences d'un déploiement, et elle se prend avant de commander les tags. Sur le tag veut dire hors ligne et définitif. Sur un serveur veut dire modifiable, illimité et dépendant de la couverture. Tout le reste du projet découle de celle que vous retenez.
Deux objets différents
Un tag qui porte un contenu est un petit document définitif. Un tag qui porte un lien est un pointeur vers un document qui peut changer.
Ils se ressemblent, ils coûtent la même chose, et ils ne se comportent en rien pareil une fois déployés. Choisir entre eux, c'est choisir si le déploiement sera modifiable.
Ce qui plaide pour le tag
Il fonctionne sans réseau. C'est l'argument, et là où il s'applique rien ne rivalise.
Il n'a par ailleurs aucune dépendance. Aucun serveur à maintenir, aucun domaine à renouveler, aucune facture d'hébergement dans cinq ans. Un tag écrit aujourd'hui fonctionne encore quand l'organisation qui l'a écrit est passée à autre chose, ce qui compte pour les étiquettes d'équipement et les installations de longue durée.
Et rien n'est demandé à personne. Le contenu arrive de l'objet que le visiteur a en main : aucune requête n'est émise et aucun serveur n'apprend qu'un contact a eu lieu. Là où cette discrétion compte, c'est une propriété réelle et non marginale.
Ce qui plaide pour le serveur
Le contenu peut changer après déploiement. C'est l'argument, et il est décisif bien plus souvent qu'on ne le prévoit au moment de la conception.
Tout déploiement contient une erreur découverte plus tard : un mauvais numéro, une page déplacée, une campagne qui s'achève. Sur un serveur, c'est une correction de cinq minutes. Sur un tag, c'est aller récupérer les tags.
La capacité cesse aussi d'être une contrainte, le pointeur étant court et ce qu'il désigne illimité. Et une seule écriture identique peut servir tout un lot quand la puce recopie son identifiant, ce qui supprime purement et simplement l'étape d'encodage tag par tag.
Comment trancher
Posez une question : y aura-t-il du réseau là où les gens présenteront leur téléphone ?
Si la réponse honnête est non, ou pas de façon fiable, le contenu va sur le tag et vous dimensionnez la puce en conséquence. Un champ, une cave, une salle pleine, un navire.
Si la réponse est oui, écrivez une adresse courte sur votre propre domaine et gardez tout le reste sur le serveur. C'est la bonne réponse pour la grande majorité des déploiements, et ceux qui la regrettent sont ceux qui ont supposé une couverture qu'ils n'avaient pas.
L'hybride fonctionne aussi, et il est sous-employé. Écrivez l'information essentielle en texte et un lien à côté, de sorte que le contact donne quelque chose d'utile hors ligne et quelque chose de plus riche là où il y a de la couverture. Cela coûte de la mémoire et supprime le pire mode de défaillance.
Questions fréquentes
Peut-on changer d'avis plus tard ?
Seulement si les tags sont déverrouillés et physiquement accessibles. C'est l'asymétrie pratique : passer d'un lien à un contenu embarqué se prévoit facilement, réécrire mille tags posés ne se prévoit pas.
Un lien signifie-t-il que mes visiteurs sont suivis ?
Il signifie qu'une requête atteint votre serveur, ce qu'implique n'importe quelle page web. Ce qui est enregistré relève de votre décision, et garder le contenu sur le tag évite la requête entièrement.
Lequel est le plus fiable ?
Le tag, si fiable veut dire fonctionner sans couverture. Le serveur, si fiable veut dire être encore juste dans deux ans.
Et un QR code à côté ?
Il ne coûte rien, il est lisible par les téléphones sans NFC, et il rend le lien visible pour ceux qui ne savent pas qu'il faut approcher le téléphone. Pour un déploiement public, c'est une assurance presque gratuite.