Comment nous protégeons vos réunions

Isolation des espaces de travail, imposée par la base de données

Une application multi-locataire fuit généralement parce qu’une requête, quelque part, a oublié son WHERE tenant_id = ?. Nous ne comptons pas sur la mémoire.

Chaque table contenant des données clients a la sécurité au niveau des lignes (Row-Level Security) de PostgreSQL activée et imposée. Les requêtes de l’application s’exécutent dans une transaction, sous un rôle de base de données dédié qui n’a aucun privilège pour contourner ces règles, avec l’identité de la personne qui interroge rattachée à la transaction. Une requête qui oublie de filtrer ne renvoie rien au lieu de renvoyer la réunion de quelqu’un d’autre, car c’est la base de données qui refuse, et non le code qui s’abstient de demander.

C’est vérifié, pas supposé. Un contrôle automatisé crée deux espaces de travail et prouve que chaque lecture et chaque écriture qui franchit la frontière est réellement refusée. Il s’exécute sur la vraie base de données et fait échouer la compilation si une table n’a pas de règle.

Chiffrement

• En transit : TLS partout, avec HSTS pour qu’un navigateur ne se rabatte jamais sur du HTTP simple.
• Au repos : la base de données et le stockage des fichiers sont tous deux chiffrés au repos par la plateforme.
• Enregistrements : les enregistrements importés sont stockés dans un espace privé, sans URL publique. La lecture passe par des liens signés de courte durée, émis uniquement après vérification de l’appartenance à l’espace de travail. Les enregistrements des appels en direct sont conservés par notre prestataire d’enregistrement, Recall.ai, et lus par un nouveau lien de courte durée, également après cette vérification.
• Identifiants tiers : les jetons Slack, Asana, Trello, ClickUp et HubSpot qu’un espace de travail connecte sont chiffrés un par un en AES-256-GCM, avec une clé conservée hors de la base de données. Une compromission de la base seule ne livre donc aucun jeton utilisable.
• Clés d’API : affichées une seule fois à la création et conservées uniquement sous forme d’empreinte SHA-256 : personne, nous compris, ne peut en relire une. Une clé est en lecture seule, ne voit que son propre espace de travail et peut être révoquée à tout moment. Le secret de signature d’un point de terminaison de webhook est chiffré comme les identifiants tiers ci-dessus.
• Mots de passe : bcrypt, coût 12. Les jetons de réinitialisation ne sont stockés que sous forme d’empreinte SHA-256 : une sauvegarde volée ne contient aucun lien de réinitialisation exploitable.

Contrôle d’accès

Quatre rôles dans un espace de travail : propriétaire, administrateur, membre et lecteur. La facturation n’est visible que du propriétaire. Les identifiants d’intégration ne sont visibles que des propriétaires et des administrateurs, et restent masqués même pour eux.

L’administration de la plateforme est une frontière entièrement distincte de tout rôle dans un espace de travail. Un propriétaire d’espace n’a aucun moyen d’y accéder, personne ne peut se l’attribuer via l’application, et un déclencheur de base de données bloque toute tentative. Chaque action d’administration est inscrite dans un journal d’audit avec son auteur, sa cible et ce qui a changé.

Liens de partage

Un propriétaire ou un administrateur peut publier une réunion précise sur un lien que toute personne le détenant peut ouvrir sans se connecter. C’est désactivé par défaut sur chaque réunion, et c’est la seule façon dont un contenu sort d’un espace de travail sans compte.

Le lien contient 32 octets aléatoires : il ne peut être ni deviné ni énuméré. Publier une réunion n’expose rien d’autre : la page partagée n’offre aucune navigation vers l’espace de travail, aucune liste de membres et aucune autre réunion. La transcription complète est un second choix, distinct du partage lui-même, et elle est exclue tant qu’elle n’est pas explicitement cochée. Les pages partagées sont marquées noindex pour ne pas apparaître dans les moteurs de recherche. Un lien peut recevoir une date d’expiration, et sa révocation prend effet immédiatement pour tout le monde, y compris pour ceux qui l’ont enregistré. Chaque partage, modification et révocation est inscrit dans le journal d’audit.

Abus et intégrité

• La signature de chaque webhook entrant est vérifiée avant que son contenu soit pris en compte : Recall.ai, Creem, Stripe et PayPal sans exception. Une requête non signée ou altérée est rejetée, pas traitée.
• La connexion, l’inscription, la réinitialisation du mot de passe, les invitations et tout ce qui déclenche un appel à un modèle sont soumis à une limite de fréquence.
• Le formulaire de réinitialisation du mot de passe donne la même réponse, que l’adresse ait un compte ou non : il ne peut pas servir à découvrir qui sont nos clients.
• L’URL de webhook Slack fournie par un espace de travail est limitée au propre domaine de Slack : le champ ne peut pas pointer vers une adresse interne pour forcer nos serveurs à la contacter.
• L’adresse de webhook fournie par un espace de travail doit être en https, et elle est refusée si elle pointe vers un réseau privé, localhost ou une adresse de métadonnées cloud. Cela est vérifié à l’enregistrement puis de nouveau au moment de la connexion, sur l’adresse réellement obtenue pour le nom, et les redirections ne sont jamais suivies. Chaque envoi est signé pour que le destinataire puisse vérifier qu’il vient de nous.
• Le texte issu d’une transcription ou d’un modèle de langage qui atteint un navigateur ou une boîte de réception est échappé à la sortie, jamais inséré comme du balisage.

Ce que deviennent vos données

Nous n’entraînons aucun modèle sur vos réunions, et nos prestataires de traitement ont contractuellement l’interdiction de le faire. Personne chez nous ne lit vos transcriptions. Supprimer une réunion supprime l’enregistrement, la transcription, le résumé et les actions ; les sauvegardes expirent sous 30 jours. La politique de confidentialité détaille l’ensemble des durées de conservation et la liste des sous-traitants.

Ce que nous n’avons pas fait

Nous préférons vous le dire plutôt que de vous laisser supposer le contraire :

• Pas de certification SOC 2 ni ISO 27001. Nous n’avons passé ni l’un ni l’autre de ces audits. Si votre processus d’achat en exige un, nous ne sommes pas encore prêts pour vous.
• Pas encore de test d’intrusion par un tiers. Les contrôles ci-dessus sont réels et testés par nos soins, mais personne d’extérieur n’a encore essayé de les contourner.
• Pas de SSO ni de SCIM. Connexion Google et e-mail, pas SAML.
• Pas d’engagement contractuel de disponibilité. Voir les conditions.

Ces points figurent sur notre feuille de route, à peu près dans cet ordre.

Signaler une vulnérabilité

Si vous trouvez quelque chose, écrivez-nous à security@notepik.com et laissez-nous un délai raisonnable pour corriger avant toute publication. Nous accusons réception sous deux jours ouvrés et vous tenons informé jusqu’à la résolution.

Nous n’avons pas de programme de prime aux bogues rémunéré pour le moment, et nous ne menacerons jamais quelqu’un qui signale de bonne foi un vrai problème.