Sécurité & confidentialité

Données personnelles

Ce que nous gardons, ce que nous filtrons, et ce qu'il se passe quand vous partez.

La suppression est effective, les journaux sont filtrés, et notre pipeline de reporting d'erreurs retire les PII avant qu'elles ne quittent le serveur. Les comptes guest qui restent inutilisés disparaissent tout seuls. Vous pouvez exercer chacun de vos droits RGPD en écrivant à [email protected].

Suppression effective

Quand vous supprimez votre compte, vos identifiants, tokens, mots de passe et clés API sont nullifiés immédiatement et vos sessions actives révoquées. L'enregistrement peut être conservé pour préserver l'intégrité des données liées (conversations, membres du foyer), mais aucune information permettant de vous identifier n'y subsiste.

Journaux épurés

Nos journaux filtrent automatiquement plus de 60 types de champs sensibles : jetons, codes de confirmation, clés API, cookies, IBAN, numéros de carte, empreintes vocales et faciales.

Monitoring sans PII

Notre outil de reporting d'erreurs (Sentry) n'enregistre pas d'informations personnellement identifiables par défaut, et un second filtre est appliqué avant envoi pour garantir qu'aucun jeton ni secret ne quitte notre environnement.

Droits RGPD

En tant qu'éditeur basé en Europe, nous respectons le Règlement Général sur la Protection des Données. Vous pouvez exercer vos droits d'accès, de rectification, d'effacement, de portabilité, de limitation et d'opposition en écrivant à [email protected].

Minimisation des données

Nous ne collectons que ce que chaque fonctionnalité demande. Le formulaire d'inscription demande email et mot de passe — pas de numéro de téléphone, pas d'adresse postale, pas de date de naissance. Chaque champ optionnel est clairement signalé et reste vide si vous ne le remplissez pas.

Purge des comptes guest inactifs

Les comptes guest — créés via POST /users/guest — sont soft-deleted automatiquement s'ils restent dormants pendant 30 jours. La purge tourne chaque nuit à 03:30 UTC.

Export / portabilité

Sur demande, nous fournissons un export lisible par machine de vos données personnelles (conversations, membres, liste d'appareils, services connectés). Traitement sous un mois, généralement sous une semaine.

Credentials tiers chiffrés

Si vous connectez un service tiers (Gmail, Google Calendar, Spotify, une banque via Nordigen, votre propre clé OpenAI), ses jetons d'accès vivent dans une colonne chiffrée séparée avec une clé déterministe distincte de la clé primaire — donc une fuite de l'une ne compromet pas l'autre.

Plongée technique

Mécaniques de suppression

Quand vous supprimez votre compte, nous nullifions atomiquement les champs d'authentification (encrypted_password, auth_token, email, unconfirmed_email, confirmation_code), révoquons chaque AuthSession, et passons status='deleted'.

Les conversations et les lignes de foyer sont préservées parce qu'elles portent des références depuis d'autres membres du foyer, mais la foreign-key utilisateur n'a plus aucun chemin vers vous — votre contenu devient des lignes orphelines. Après 30 jours, les lignes orphelines sont garbage-collected. Si vous souhaitez une suppression littérale et immédiate (plutôt que soft-delete + GC), écrivez à [email protected] avec votre demande.

Journaux filtrés

Le config.filter_parameters de Rails est étendu avec une liste d'environ 60 noms de champs couvrant :

  • Jetons : auth_token, user_token, device_token, access_token, refresh_token, bearer, id_token, jwt, authorization
  • Clés API : *_api_key (OpenAI, Anthropic, Gemini)
  • Secrets : cookie, card, cvv
  • Identifiants financiers : iban, rib
  • Codes : pairing_code, confirmation_code
  • Champs biométriques : face_embedding, voice_profile, audio, embedding

Le filtre s'applique aux logs de requête ET à la sortie d'inspection de params — toute valeur sous l'une de ces clés est remplacée par [FILTERED] avant tout écriture sur disque.

Purge des guests inactifs

Les comptes guest sont créés par des utilisateurs qui essaient Twoody sans s'inscrire — ils obtiennent une session à usage unique, pas de mot de passe, pas de vrai email. Laissés tels quels, ils encombreraient la base indéfiniment.

Un job nocturne (PurgeInactiveGuestsJob) cible les guests dont les timestamps de création et de dernière activité datent tous deux de plus de 30 jours, passe status='deleted', nullifie encrypted_password et auth_token, mais garde la ligne pour que les FKs depuis queries/discussions restent valides. Aucun utilisateur ne peut pointer rétrospectivement vers une ligne que vous auriez occupée — la ligne est toujours là, mais ce n'est plus vous.

Notre objectif : si vous partez, votre départ est visible dans notre SQL sous forme de vides, pas sous forme de quelque chose que nous pourrions utiliser. La minimisation des données est un objectif de conception, pas une checklist — nous ne collectons pas ce dont nous n'avons pas besoin, et nous ne gardons pas ce que nous n'utilisons pas.

Sujets liés