Aller au contenu
Cette page a été traduite automatiquement depuis l’anglais. Signalez une erreur ou proposez une correction.

Documentation développeur

Construisez sur TigerSystem : lisez des puces, dialoguez avec le cloud, ou intégrez votre propre matériel et vos propres logiciels. Rien ne demande d’autorisation — le protocole est ouvert.

Lire un TigerTag demande n’importe quel smartphone NFC, un lecteur USB ACR122U branché sur un ordinateur, ou un appareil DIY — un simple ESP32 avec un module lecteur PN532 ou RC522 (l’approche retenue par TigerScale). Du matériel courant, rien de propriétaire. À partir de ce seul scan, intégrez partout où une identité est utile :

  • ERP / gestion de stock — reliez l’identité et les quantités des bobines au système d’inventaire existant de votre entreprise.
  • Suivi de consommation — enregistrez quel matériau est parti dans quel travail, quelle machine ou quelle commande client.
  • Tableaux de bord et automatisations sur mesure — supervision de ferme d’impression, alertes de stock bas, déclenchement de réapprovisionnement.
  • Systèmes de prêt — fablabs, écoles, makerspaces qui gèrent les entrées et les sorties de matière.
  • Projets de R&D, privés ou publics — un support d’identité ouvert, réinscriptible et documenté avec lequel expérimenter.

Aucun de ces usages n’a besoin de nos applications ni de notre cloud : la puce

  • un SDK suffisent. N’ajoutez la surface compte que si vous voulez des comptes et de la synchronisation.

Construisez-le et il est TigerTag Compatible : gratuit, auto-déclaré, sans audit et sans autorisation. Passez-le à l’audit et il peut devenir TigerTag Certified — ouvert à tout ce que construit un tiers, matériel ou logiciel, dans deux périmètres (TigerTag et TigerTag+). Ce qui sépare les paliers n’est pas la nature de votre produit ; c’est le fait que quelqu’un ait vérifié ou non. Compatible dit « ça marche » sur votre parole, Certifié dit « nous l’avons testé » sur la nôtre (critères, contactez-nous via l’organisation GitHub).

La gouvernance comporte délibérément deux portes : n’importe qui peut implémenter le protocole et dire « compatible avec TigerTag » — sans autorisation, jamais — et afficher le logo TigerTag, non modifié, pour le dire : dans votre application, votre documentation, votre fiche en boutique. Cet usage référentiel est libre. Seuls les partenaires certifiés (listés dans le registre des certifiés) peuvent apposer la marque — logo ou nom — sur une puce de quelque format que ce soit (puce, inlay, sticker, étiquette, support), une bobine ou un emballage, où elle cesse de décrire une compatibilité pour affirmer une origine ; la mention en texte seul « Compatible with TigerTag » sur la boîte d’un lecteur, d’une imprimante ou d’une application compatibles reste libre, et eux seuls peuvent émettre des signatures TigerTag+ (TigerTag détient la clé privée). La porte de la marque relève du marketing ; la porte de la signature relève de la technique ; aucune des deux ne restreint le protocole d’une seule ligne — une puce non certifiée fonctionne parfaitement, elle ne peut simplement pas prouver son origine.

Deux détails qu’il vaut mieux avoir exactement justes. La revendication de compatibilité couvre aussi le palier + : vérifier une signature TigerTag+ est gratuit, hors ligne et sans restriction — les clés publiques sont publiées — de sorte qu’un lecteur qui les vérifie peut dire « compatible avec TigerTag+ ». Ce qu’il ne peut pas faire, c’est appeler une étiquette un TigerTag+ si cette étiquette ne porte pas réellement une signature émise par TigerTag. Et le mot « certifié » ne s’attribue jamais soi-même : TigerSystem l’accorde, personne ne le revendique.

C’est délibérément le modèle qu’utilisent Zigbee et Matter — un palier Compatible gratuit, ouvert à tous, et un palier Certifié accordé, qui signifie quelque chose pour l’acheteur précisément parce qu’il est accordé. Politique complète, paliers de certification et éléments de marque : TRADEMARK.md et CERTIFICATION.md.

Je veux… À lire
Voir qui a déjà construit sur TigerTag Intégrations tierces
Comprendre les briques Vue d’ensemble de l’architecture
Savoir quel dépôt fait quoi Dépôts
Lire et écrire des puces TigerTag SDK
Échanger des inventaires sous forme de fichiers Le format .ttag
Afficher la couleur d’une bobine comme le font toutes les autres applications La pastille de matière — et son moteur de rendu de référence en direct
Synchroniser avec l’inventaire cloud de l’utilisateur API compte et intégration
Comprendre la charge utile de la puce La puce TigerTag
flowchart LR
  YOU[Your app / device] -->|"NFC (SDK)"| TAG[TigerTag chip]
  YOU -->|"Firebase (documented surface)"| CLOUD[("The shared account database")]
  YOU -->|"reference data"| CDN[cdn.tigertag.io]
  1. Puce seule — analysez et encodez les puces avec un SDK. Pas de compte, pas de réseau.
  2. Connecté au cloud — authentifiez le compte de l’utilisateur lui-même et lisez/écrivez ses données dans le cadre des règles de sécurité côté serveur (contrat d’intégration).
  3. Matériel — des exemples fonctionnels existent pour ESP32/Arduino, Home Assistant et une passerelle Spoolman (voir les exemples du dépôt d’intégration).
  • Gestion des versions — les publications de produits suivent SemVer ; la charge utile de la puce porte sa propre version de format pour la rétrocompatibilité.
  • Nommage — des noms auto-descriptifs plutôt qu’encodés ou astucieux ; pas de valeurs magiques à états multiples.
  • Des ID, jamais des libellés — toute logique qui dépend d’une valeur des tables de référence (id_aspect, id_brand, id_material, id_type, id_diameter, id_measure_unit, id_version…) compare son ID numérique, jamais son libellé sous forme de chaîne. Un libellé est un texte d’affichage : il est traduit, il peut être renommé ou corrigé dans la base de référence, et il se lit différemment dans chaque langue — un ID ne change jamais. Gardez l’ID à côté du libellé, nommez les ID sur lesquels vous branchez (par ex. aspect Tricolor 24, Rainbow 145, Bicolor 252), et réservez les libellés à l’affichage.
  • Couleur — la couleur d’une bobine est stockée comme une donnée, pas comme une image, donc chaque surface doit transformer cette donnée en la même image : la convention de la pastille de matière est normative, et s’accompagne d’un moteur de rendu de référence auquel confronter votre propre implémentation.
  • Contributions — chaque dépôt a son propre guide ; les contributions à la documentation suivent le CONTRIBUTING.md d’ici.