Answer what leaves the bench

Every page in the ecosystem repeats that the cloud is optional and that no
account is needed. The page that should back it up had a "Security model"
section which said nothing about what is sent or stored — a promise made
everywhere and evidenced nowhere.

It now states what a device actually transmits, taking the scale as the
worked example, and the four things a reader deserves before trusting
any of it: identification is local so a lookup never waits on the
network; going without an account costs exactly one thing, sync; a
signed-in device holds a credential, so sign out and forget the WiFi
before passing it on, because a reflash clears neither; and the LAN API
is unauthenticated by choice.

The Firebase key visible in the sources is named for what it is — a
public project identifier, not a leaked secret — since that is the first
thing an attentive reader finds and misreads.

Sourced from the scale's own CLOUD.md, which stays canonical and is
linked rather than restated.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: BenGlut

docs/concepts/inventory-and-cloud-sync.md

@@ -34,6 +34,50 @@ The authoritative field-by-field data model is documented in the
 [Firebase integration repo](https://github.com/TigerTag-Project/TigerTag_Firebase_Integration)
 (`docs/03-data-model.md`) — the reference for third-party integrators.
 
+## What leaves your bench, and what stays
+
+The ecosystem says everywhere that the cloud is optional. Here is what that
+actually means, and what it costs when you say no.
+
+**Identification is local by design.** A device does not ask a server what a tag
+is. The brand and material tables live in its own storage and are refreshed from
+the **public** [reference repository](https://github.com/TigerTag-Project/TigerTag-RFID-Guide)
+at most once a day. So a lookup never waits on the network, and it works with
+the internet down.
+
+**Without an account you lose exactly one thing: sync between devices.** A
+[TigerScale](../products/tigerscale.md) still weighs, still reads tags, still
+identifies brand and material, still serves its own web UI on your LAN. Nothing
+about the chip itself needs us — that is the whole point of writing the data
+[on the chip](./tigertag-chip.md).
+
+**With an account, here is what a device actually sends.** Taking the scale as
+the worked example, on each completed weighing and on a heartbeat it writes,
+under your own user document: the spool's tag UIDs, net/gross/container weight,
+firmware version, WiFi signal and IP, calibration factor, last-heartbeat time,
+battery state, and screen state. Diagnostics and measurements — no more. Every
+field is documented in
+[the scale's own reference](https://github.com/TigerTag-Project/Tiger-Scale-V3/blob/main/docs/TELEMETRY.md).
+
+**And here is what it stores locally, which matters more.** A signed-in device
+holds a refresh token, your user id and your WiFi credentials. It never stores
+your password — sign-in exchanges it for tokens. But treat a provisioned device
+as **holding a credential**: before you lend, sell or give one away, sign out
+*and* forget the WiFi. A plain reflash does not clear either — that storage is
+preserved on purpose so a firmware update does not cost you your setup.
+
+**Two deliberate choices worth knowing.** A device's LAN API is
+**unauthenticated**: anyone already on your network can read its state and
+trigger a tare. That is a simplification for a home network — put it on a guest
+VLAN if you do not trust yours. And the Firebase key visible in the source is a
+**public project identifier**, not a secret; every Firebase client ships it, and
+access control is enforced by server-side rules against the signed-in user, not
+by hiding a string.
+
+For the scale, all of this is documented in full in
+[`docs/CLOUD.md`](https://github.com/TigerTag-Project/Tiger-Scale-V3/blob/main/docs/CLOUD.md),
+which is canonical.
+
 ## Sharing model (summary)
 
 - Each user has a public **discovery code** (`XXX-XXX`) for O(1) friend lookup.

i18n/fr/concepts/inventory-and-cloud-sync.md

@@ -1,5 +1,5 @@
 ---
-sourceHash: d67e44df11ee69b32eae54fed3cd722e38cba87031c99976c1cee0a879d054c5
+sourceHash: 5283f746f604b2bf5956044ddd3e902a6a6aa39e61026868a794fb05bd51458d
 sourcePath: docs/concepts/inventory-and-cloud-sync.md
 ---
 
@@ -42,6 +42,56 @@ Le modèle de données faisant foi, champ par champ, est documenté dans le
 [dépôt d'intégration Firebase](https://github.com/TigerTag-Project/TigerTag_Firebase_Integration)
 (`docs/03-data-model.md`) — la référence pour les intégrateurs tiers.
 
+## Ce qui sort de votre établi, et ce qui y reste
+
+L'écosystème répète partout que le cloud est facultatif. Voici ce que cela
+signifie concrètement, et ce que cela coûte de dire non.
+
+**L'identification est locale par conception.** Un appareil ne demande pas à un
+serveur ce qu'est une puce. Les tables de marques et de matières vivent dans sa
+propre mémoire et sont rafraîchies depuis le
+[dépôt de référence](https://github.com/TigerTag-Project/TigerTag-RFID-Guide)
+**public** au plus une fois par jour. Une lecture n'attend donc jamais le
+réseau, et elle fonctionne internet coupé.
+
+**Sans compte, vous perdez exactement une chose : la synchronisation entre
+appareils.** Une [TigerScale](../products/tigerscale.md) pèse toujours, lit
+toujours les puces, identifie toujours la marque et la matière, et sert
+toujours sa propre interface web sur votre réseau local. Rien de ce qui touche
+à la puce elle-même n'a besoin de nous — c'est tout l'intérêt d'écrire les
+données [sur la puce](./tigertag-chip.md).
+
+**Avec un compte, voici ce qu'un appareil envoie réellement.** En prenant la
+balance comme exemple : à chaque pesée terminée et à chaque battement de cœur,
+elle écrit, sous votre propre document utilisateur, les UID des puces de la
+bobine, les poids net / brut / du contenant, la version du firmware, la
+puissance du signal WiFi et l'adresse IP, le facteur de calibration, l'horodatage
+du dernier battement, l'état de la batterie et l'état de l'écran. Des mesures et
+du diagnostic — rien d'autre. Chaque champ est documenté dans
+[la référence de la balance](https://github.com/TigerTag-Project/Tiger-Scale-V3/blob/main/docs/TELEMETRY.md).
+
+**Et voici ce qu'elle stocke localement, ce qui compte davantage.** Un appareil
+connecté détient un jeton de rafraîchissement, votre identifiant utilisateur et
+vos identifiants WiFi. Il ne stocke jamais votre mot de passe — la connexion
+l'échange contre des jetons. Mais considérez un appareil provisionné comme
+**détenant un identifiant** : avant de le prêter, de le vendre ou de le donner,
+déconnectez-vous *et* oubliez le WiFi. Un simple reflash n'efface ni l'un ni
+l'autre — cette mémoire est préservée volontairement, pour qu'une mise à jour du
+firmware ne vous coûte pas votre configuration.
+
+**Deux choix délibérés à connaître.** L'API locale d'un appareil n'est **pas
+authentifiée** : quiconque est déjà sur votre réseau peut lire son état et
+déclencher une tare. C'est une simplification assumée pour un réseau
+domestique — placez l'appareil sur un VLAN invité si vous ne faites pas
+confiance au vôtre. Et la clé Firebase visible dans les sources est un
+**identifiant public de projet**, pas un secret : tous les clients Firebase
+l'embarquent, et le contrôle d'accès est appliqué par des règles côté serveur
+contre l'utilisateur connecté, pas en cachant une chaîne de caractères.
+
+Pour la balance, tout cela est documenté en détail dans
+[`docs/CLOUD.md`](https://github.com/TigerTag-Project/Tiger-Scale-V3/blob/main/docs/CLOUD.md),
+qui fait foi.
+
 ## Modèle de partage (résumé)
 
 - Chaque utilisateur dispose d'un **code de découverte** public (`XXX-XXX`)