Threat model
Nous supposons le vol d'appareil, l'interception réseau et l'exposition accidentelle via backup ou cloud sync. Nous supposons que les identifiants de l'utilisateur peuvent être compromis. Nous ne supposons pas d'adversaires de niveau étatique avec accès physique à des appareils déverrouillés — Fluera n'est pas un outil de secret, c'est un outil d'étude.
Dans ce modèle, trois garanties :
- Les données locales sont illisibles sans la clé. Un appareil volé produit un blob chiffré.
- Les données synchronisées sont chiffrées en transit et au repos. Le cloud sync n'est pas chiffré de bout en bout : en tant que responsable du traitement, Fluera peut techniquement y accéder. Nous ne vendons jamais ce contenu et ne l'utilisons jamais à des fins publicitaires.
- La télémétrie est consensuelle et désidentifiée. Les analytics ne peuvent pas relier un utilisateur à son contenu, même en cas de breach complet.
Au repos : SQLCipher, AES-256
Chaque cahier Fluera vit dans une base SQLite locale chiffrée avec SQLCipher — une extension largement auditée qui chiffre de manière transparente chaque page de la base avec AES-256-CBC et un contrôle d'intégrité HMAC-SHA512 par page.
La clé de la base de données locale est une clé aléatoire de 256 bits générée par Fluera et conservée dans le stockage sécurisé de la plateforme — Keychain sur iOS/macOS, Keystore sur Android, DPAPI sur Windows et libsecret sur Linux. Ce n’est ni le mot de passe de ton compte ni une phrase secrète de synchronisation cloud, et cette clé locale n’est jamais envoyée aux serveurs de Fluera.
En transit : TLS 1.3
Tout le trafic réseau est en TLS 1.3 avec des suites de chiffrement modernes.
Synchronisation entre appareils
Le cloud sync, lorsqu'il est activé, stocke tes cahiers sur une infrastructure UE (Supabase, région eu-north-1). Les données sont chiffrées en transit (TLS) et au repos au niveau de l'infrastructure. Ce n'est pas un chiffrement de bout en bout : en tant que responsable du traitement, Fluera peut techniquement accéder au contenu synchronisé. Nous ne le vendons jamais et ne l'utilisons jamais à des fins publicitaires. La synchronisation est opt-in par cahier — tu peux en garder certains uniquement en local pendant que tu en synchronises d'autres.
Pour une confidentialité maximale, garde les cahiers sensibles uniquement en local : la base SQLite locale reste chiffrée avec SQLCipher. Un export .fluera protégé par mot de passe est chiffré séparément avec AES-256-GCM ; ce mot de passe protège uniquement le fichier et n’est pas lié à la synchronisation cloud.
Collaboration P2P : directe, chiffrée
La collaboration en temps réel utilise WebRTC DataChannel avec chiffrement DTLS-SRTP. Supabase Realtime n'agit que comme broker de signaling — pour la mise en place de la connexion — pas comme relais du trafic réel du canvas. Après le handshake, les éditions du canvas circulent en peer-to-peer. Le serveur ne les voit pas.
Sur des NATs restrictifs, nous passons par TURN — auquel cas le relais ne voit que des paquets DTLS chiffrés qu'il ne peut pas déchiffrer.
Appels d'IA : via proxy, jamais directs
Les appels aux modèles Google Gemini (Socratic Mode, Ghost Map, LaTeX OCR, Exam Session) sont servis via Google Vertex AI et traités dans l'UE (europe-west4 NL / europe-west1 BE). Ils passent par un proxy qui garde la clé API côté serveur. Les appareils clients ne voient jamais la clé. Le proxy applique un rate limit par plan et journalise les durées d'appel pour la facturation — jamais le contenu du canvas.
Si tu désactives les fonctionnalités d'IA dans Paramètres → Confidentialité, aucun contenu du canvas n'est envoyé à l'IA, pas même en fallback d'OCR on-device.
Télémétrie : opt-in, hashée, allowlistée
Les analytics produit sont désactivés par défaut. Lorsqu'ils sont activés, les événements sont limités à une whitelist côté serveur (début/fin de session, invocation de fonctionnalité, durée d'appel d'IA — jamais le contenu). L'ID utilisateur est hashé en SHA-256 sur l'appareil ; l'ID en clair ne sort jamais du client. Les événements sont conservés 180 jours, puis agrégés ou supprimés.
Journal d'audit (comptes Institutionnels)
Chaque accès aux cahiers partagés — qui, depuis quel appareil, quand — est écrit dans un journal d'audit append-only. Les administrateurs peuvent exporter le journal en CSV ou JSON pour des contrôles de conformité. Le journal est write-once : la suppression exige une justification documentée et est, elle-même, journalisée.
Récupération des données
Les cahiers synchronisés sont associés à ton compte : après la procédure habituelle de récupération du compte, reconnecte-toi pour les télécharger sur un nouvel appareil. Il n’existe aucune phrase secrète distincte pour la synchronisation cloud à mémoriser. La récupération du compte ne peut pas reconstruire un cahier resté uniquement en local si les données de l’appareil ont été effacées ; active la synchronisation pour les cahiers que tu veux pouvoir récupérer sur plusieurs appareils.
Responsible disclosure
Les chercheurs en sécurité sont les bienvenus. Signale les vulnérabilités à lorenco@fluera.dev avec chiffrement PGP (clé publiée sur le profil GitHub). Nous répondons sous 24 heures, patchons les problèmes critiques sous 72, et créditons les rapporteurs dans le hall of fame, sauf demande d'anonymat.
Périmètre : l'app Fluera (toutes plateformes), le service de synchronisation, le proxy d'IA et ce site marketing. Hors périmètre : les services tiers (Supabase, Google, Apple, Sentry, RevenueCat) — signale-les aux vendors correspondants.
Évaluations externes
Fluera n'a, à ce jour, ni certification SOC 2 ni ISO 27001. Elles sont sur la roadmap enterprise et seront annoncées publiquement une fois obtenues. Nous préférons ne pas déclarer des contrôles que nous ne vérifions pas de manière indépendante.
La liste des sous-traitants est publique et tenue à jour. Le Data Processing Agreement est disponible sur demande à lorenco@fluera.dev.