Actualités · La sécurité chez Blackbear
Ce que nos serveurs peuvent voir
Tout service cloud conserve des métadonnées sur vous. La plupart enfouissent ce fait à la page neuf de leur politique de confidentialité. Nous préférons publier le registre.
Voici ce que stockent les serveurs de Blackbear, vérifié par rapport au schéma réel de notre base de données au moment de publier cet article. Pas la version marketing. Les colonnes.
Votre compte
Vous pouvez vous connecter avec un e-mail, un numéro de téléphone, Google ou Apple. Quel que soit votre choix, l’identifiant est stocké chiffré au repos et retrouvé par hachage à clé. Nous pouvons déchiffrer votre e-mail quand nous devons vous envoyer un lien magique, et il n’apparaît jamais en clair dans nos journaux.
La connexion par téléphone passe par Twilio Verify pour envoyer les codes. Nous ne stockons jamais les codes ; Twilio voit forcément votre numéro pour envoyer le SMS.
Si vous payez pour la synchronisation, c’est Stripe qui détient vos informations de paiement. Nous détenons une référence client, votre offre et l’état de votre abonnement. Nous ne voyons jamais votre carte.
Synchronisation
Pour chaque modification que vous synchronisez, le serveur enregistre : le type d’élément (un fichier, une tâche, un événement), son identifiant, des métadonnées de version pour résoudre les conflits, un horodatage, celui de vos appareils qui l’a envoyée, et sa taille en octets. Le contenu lui-même est du texte chiffré, scellé sur votre appareil comme décrit dans la partie 1.
Une modification synchronisée, telle que la voit notre base de données
Ce que nous pouvons lire
Ce que nous ne pouvons pas lire
Les champs lisibles servent à acheminer et à ordonner vos modifications entre appareils. Le contenu, ce sont vos véritables données : du texte chiffré que nous ne pouvons pas ouvrir.
Alors oui : nous pourrions voir que vous synchronisez plus de tableurs que de notes, et que vous êtes actif le matin en semaine. Ce sont de vraies métadonnées, et nous ne prétendrons pas le contraire. Ce que nous ne pouvons pas voir : les titres, le texte, les tags, les noms de dossiers, ni quoi que ce soit à l’intérieur de vos fichiers.
Les lignes des médias sont plus sobres encore : une clé de stockage opaque se terminant par .enc, un nombre d’octets, et la catégorie générale du fichier issue de la validation à l’envoi. Vos noms de fichiers n’entrent jamais dans la clé de stockage ni dans la base de données.
Messagerie
La boîte aux lettres est un relais, pas une archive. Une ligne de message contient le compte de l’expéditeur, le compte du destinataire, un identifiant de conversation, des horodatages et l’enveloppe scellée. Nous pouvons voir qui échange avec qui, et quand. Nous ne pouvons pas voir ce qui se dit.
La conservation est mécanique : les messages remis sont supprimés au bout de 24 heures. Les messages non remis attendent leur destinataire jusqu’à 30 jours, puis sont supprimés.
Espaces partagés
Pour la collaboration, le serveur stocke l’appartenance aux groupes par empreinte de clé, les rôles signés, les époques des clés et les mises à jour chiffrées. Il peut savoir que cinq empreintes partagent un document et à quel point elles le modifient activement. Il ne peut pas en lire un mot. La partie 3 détaille tout cela.
Appareils
Votre liste d’appareils indique, pour chacun, une plateforme, l’heure de la dernière synchronisation et un curseur de synchronisation. Les noms d’appareils sont aujourd’hui stockés tels que vous les avez saisis : appelez un appareil « MacBook » plutôt que d’un nom que vous n’aimeriez pas nous voir lire.
Journaux de sécurité
Nous gardons une trace des événements de sécurité : connexions, échecs, opérations sensibles, avec l’adresse IP et l’agent utilisateur. Elle sert à détecter les abus, et elle ne reste pas brute. Après une courte période active, chaque enregistrement est réduit au minimum : l’IP est masquée, l’agent utilisateur ramené à un nom de plateforme, et l’identifiant de votre compte remplacé par un identifiant de confidentialité opaque. Les enregistrements minimisés sont chiffrés et archivés, et les lignes brutes sont supprimées.
Même nos propres journaux perdent leurs détails identifiants selon un calendrier fixe.
Statistiques
Notre site (celui-ci) envoie un unique signal de page vue à notre propre API. Pas de cookies, pas d’empreinte du navigateur, et Do Not Track est respecté. Les valeurs identifiantes sont hachées avec un sel renouvelé chaque jour, les valeurs brutes sont jetées, et les lignes sont supprimées au fil d’une fenêtre glissante. L’app n’est jamais suivie. Pas de télémétrie, pas de SDK, pas de scripts tiers. Nous ne pouvons pas faire de tests A/B sur vous. Nous découvrons les bugs quand vous nous les signalez.
Au bout du compte
Nous avons construit Blackbear pour que la réponse honnête à « que savez-vous de moi ? » reste courte. Un identifiant chiffré. Du texte chiffré avec des formes et des horodatages. Un relais qui oublie en quelques heures. Des journaux qui oublient délibérément.
Une promesse de confidentialité invérifiable n’est qu’une impression. Un registre que vous pouvez nous opposer est un engagement public. Voici le nôtre, vérifié ligne par ligne par rapport au schéma en production le 15 août 2026.
Pour aller plus loin
- Why Metadata Matters — l’explication claire et accessible de l’EFF
- HMAC — le hachage à clé derrière la recherche de nos identifiants
- Data at rest — ce que signifie, et ne signifie pas, le chiffrement au repos
- AES-GCM — l’algorithme qui scelle nos archives de journaux
- Do Not Track — le signal du navigateur que nous respectons
La sécurité chez Blackbear
- 1. Ce que nous ne pouvons pas lire
- 2. Ce que nos serveurs peuvent voir (vous êtes ici)
- 3. Un partage qui reste scellé