Cette page existe pour que vous voyiez exactement ce que FerrLabs collecte, sous quelle forme, et comment l'éteindre. Rien sur cette page n'est collecté aujourd'hui. La télémétrie est opt-in sur tous les produits FerrLabs. Ce document est l'engagement que nous tiendrons avant de basculer la valeur par défaut sur "actif".
Nous ne basculerons pas en on-by-default tant que chaque event listé ci-dessous n'est pas réellement émis, que le mécanisme d'opt-out ne fonctionne pas dans les trois surfaces (CLI, app, serveur), et que cette page ne lit pas la liste des events depuis le code source (pour rendre toute dérive impossible). Le travail est suivi dans FerrLabs-Cloud#166.
1. Pourquoi collecter quoi que ce soit
Nous shippons cinq produits. Sans données d'usage agrégées nous ne pouvons pas savoir quelles fonctionnalités sont utilisées, quels parcours cassent, quels produits méritent nos efforts. Les options honnêtes étaient soit d'opérer dans le noir, soit de collecter le signal le plus petit possible — anonyme, hashé, avec la liste complète des events publique. Nous avons choisi la seconde.
2. Ce que nous ne collectons jamais
Règles dures. N'apparaîtront jamais dans aucun payload de télémétrie, opt-in ou non :
- Adresses email, noms, avatars — toute chaîne identifiante de votre compte.
- Valeurs des secrets stockées dans FerrVault — le contenu, les métadonnées autour, les chemins dans vos vaults.
- Titres ou corps des issues dans FerrTrack — uniquement des comptes et types d'event, jamais le contenu.
- Contenu des pages ou events analytics des visiteurs FerrGrowth — vos visiteurs ne deviennent pas nos données.
- Code source, messages de commit, chemins de fichiers traités par la CLI FerrFlow.
- Prompts, complétions, ou tout payload des runs d'agents FerrFleet — nous enregistrons qu'un run a eu lieu et le slug d'agent first-party utilisé, jamais ce qu'il a fait.
- Adresses IP — droppées au point d'ingestion avant que l'event n'atteigne le stockage.
- Cookies ou fingerprinting navigateur sur ferrlabs.com ou n'importe quel site produit.
3. Ce que nous collectons
Les events sont groupés par produit. Chaque ligne est un nom d'event réel tel qu'il apparaît
dans le code. Une fois le travail #166 livré, cette liste sera générée depuis
Kit/crates/telemetry au build — toute dérive entre la doc et la réalité devient impossible.
3.1 CLI FerrFlow
| Event | Quand il se déclenche | Champs |
|---|---|---|
cli.run | Une fois par invocation, après la fin de la commande. | command (enum : bump, release, changelog, …), exit_code (int), duration_ms (int), cli_version (string), os (linux/macos/windows), arch (x86_64/aarch64). |
cli.error | Sur erreur non gérée, à la place de cli.run. | command, error_code (FFXXXX), cli_version. Le
corps du message d'erreur n'est pas envoyé. |
3.2 API FerrLabs + app.ferrlabs.com
| Event | Quand il se déclenche | Champs |
|---|---|---|
org.created | Nouvelle organisation créée. | org_hash, user_hash (le créateur). |
org.member.added | Un membre est ajouté à une org. | org_hash, actor_hash, role (owner/admin/member/billing/auditor). |
product.activated | Une org active un abonnement produit. | org_hash, product (enum), tier (free/pro/team/enterprise). |
product.tier_changed | Abonnement upgradé ou downgradé. | org_hash, product, tier_from, tier_to. |
product.canceled | Abonnement annulé. | org_hash, product. |
auth.login | Login réussi. | user_hash, method (password / oauth-google / oauth-github / sso). |
auth.signup | Nouveau compte créé. | user_hash, method. |
3.3 Events SaaS par produit
FerrVault, FerrTrack, FerrGrowth, FerrFleet émettent des compteurs d'usage qui correspondent à
leurs fonctionnalités catalogue (par exemple
vault.secret.injected, track.issue.created,
growth.site.published, fleet.agent.run). La liste complète des events
de chaque produit vit sous /telemetry# suivi de son slug — peuplée quand le produit ship
et émet son premier event.
4. Hashing
Chaque champ *_hash est BLAKE3-keyed sur l'UUID original avec un sel
server-side qui tourne tous les 90 jours. Le sel est gardé dans le FerrLabs Vault (sealed K8s secret
aujourd'hui) et n'est jamais écrit sur du stockage lisible côté client.
Conséquences pratiques :
- La même org ou le même user produit un hash stable pendant ~90 jours, puis un nouveau. Les cohortes peuvent être analysées dans une fenêtre ; les jointures cross-window sont impossibles.
-
Même avec le sel,
org_hashne peut pas être inversé vers l'org id original — BLAKE3 est une fonction à sens unique. - Sans le sel, aucune table arc-en-ciel ne fonctionne contre l'espace UUID.
5. Stockage et rétention
- Où : une hypertable TimescaleDB dans le cluster Postgres principal de FerrLabs (UE, France). Aucun sous-traitant tiers.
- Events bruts : 90 jours. Aligné avec la rotation du sel — vieux hashes et vieilles données expirent ensemble.
- Agrégats : conservés indéfiniment sous forme de comptes uniquement (par exemple
"
org.createdpar jour par produit"). Pas de lignes par event, pas de chemin retour vers un hash, pas de chemin retour vers une org. - Backups : même rétention. Les snapshots de backup de plus de 90 jours ne contiennent pas d'events bruts.
6. Comment opt-out
Trois surfaces, selon le produit :
6.1 CLI FerrFlow
Définissez l'une ou l'autre :
FERRFLOW_TELEMETRY=0DO_NOT_TRACK=1(le standard cross-outils)
Au premier run après installation, la CLI affiche une ligne :
Telemetry on. See ferrlabs.com/telemetry. Opt out: FERRFLOW_TELEMETRY=0. Une fois
opt-out, aucun event n'est généré. La CLI ne ré-active jamais silencieusement la télémétrie
entre deux versions.
6.2 app.ferrlabs.com
Un toggle vit dans /settings/prefs → "Télémétrie". L'opt-out s'applique immédiatement à votre compte ; le prochain appel API pose le flag server-side pour que même les events émis côté serveur liés à votre user_hash arrêtent d'être enregistrés.
6.3 Opt-out à l'échelle de l'org
Les owners et admins d'org peuvent désactiver la télémétrie pour toute l'organisation dans /settings/org → "Télémétrie". Cela surcharge les préférences individuelles des membres pour les events liés à l'org (changements d'abonnement, ajouts de membres, usage produit). Les events personnels (login, signup) respectent toujours la préférence individuelle du membre.
7. Vérification
Les events listés en section 3 sont générés depuis Kit/crates/telemetry au build une
fois #166 livré. Vous pouvez auditer le source à
github.com/FerrLabs/Kit/crates/telemetry.
Si vous voulez inspecter le format wire vous-même, chaque event est un POST JSON vers
https://api.ferrlabs.com/v1/telemetry. Lancez la CLI FerrFlow derrière
mitmproxy ou l'outil DNS de votre choix — le payload correspond à cette page.
8. Modifications de ce document
Les changements de la position télémétrie, de la liste des events, de la fonction de hash ou de
la politique de rétention sont documentés dans le
changelog public avec le tag product: ferrlabs
et le label type: security ou type: breaking selon. Nous annonçons les changements
qui élargissent la collecte au moins 30 jours avant qu'ils n'entrent en production.
Questions : privacy@ferrlabs.com.