Comment Spun chiffre vos données, du chiffrement WhatsApp aux appels de groupe
Le détail honnête, scénario par scénario, du chiffrement WhatsApp, des appels et des données stockées : ce qui est chiffré de bout en bout, ce qui n'est chiffré qu'en transit et ce que Spun doit pouvoir lire pour que le produit fonctionne.
En un coup d'œil
Le chiffrement par scénario
Voici chaque type de données que Spun traite et la manière exacte dont il est protégé. Nous indiquons E2EE Oui uniquement lorsqu'aucun système de Spun ne peut lire le contenu.
| Scénario | E2EE | Remarques |
|---|---|---|
Appel vocal individuel (Spun → Spun) DTLS-SRTP (WebRTC) | Oui | WebRTC en pair-à-pair pur. Les clés sont négociées entre les deux terminaux : Spun ne les détient jamais. |
Appel vidéo individuel (Spun → Spun) DTLS-SRTP (WebRTC) | Oui | Comme pour la voix. Les relais TURN ne voient que des paquets chiffrés lorsque la connexion P2P directe échoue. |
Appel de groupe (3 participants ou plus) TLS 1.2+ vers le SFU, DTLS-SRTP pour les médias | Non | Le SFU de LiveKit Cloud déchiffre les médias pour les acheminer vers les autres participants. C'est l'architecture SFU standard. |
Salle de traduction (mode P2P, 2 participants au plus) DTLS-SRTP (WebRTC) | Oui | Bascule vers le SFU si un troisième participant rejoint la salle (voir la ligne ci-dessus). |
Salle de traduction (mode SFU, 3 participants ou plus) TLS 1.2+ vers le SFU | Non | Le SFU de LiveKit a accès aux médias pour les traduire et les remixer. |
Messages WhatsApp (dans WhatsApp) Signal Protocol (Meta) | Partiel | WhatsApp lui-même est chiffré de bout en bout entre les participants. Mais dès que votre fournisseur de passerelle reçoit vos messages entrants pour votre compte, la passerelle et Spun voient le texte en clair : c'est ainsi que fonctionne la boîte de réception. |
Messages WhatsApp (dans Spun) TLS 1.2+ | Non | Nécessaire à l'affichage de la boîte de réception, à la recherche, aux fonctions d'IA et aux automatisations. |
Spun Chat et messages d'équipe TLS 1.2+ | Non | En clair au repos, pour que les messages puissent être recherchés et traités par les fonctions d'IA que vous activez. |
Pièces jointes (images, vidéos, documents) TLS 1.2+ (Cloudflare R2 + S3 SigV4) | Non | R2 gère les clés. Spun signe des URL de courte durée pour contrôler l'accès par organisation. |
Données de carte de paiement TLS 1.2+ directement vers Stripe | Partiel | Stripe Elements collecte les données de carte directement dans le navigateur : elles n'atteignent jamais les serveurs de Spun. Nous ne recevons qu'un identifiant client opaque. |
Requêtes et réponses de l'IA TLS 1.2+ vers le fournisseur d'IA | Non | Envoyées via TLS à OpenAI, AssemblyAI, etc. Le masquage des données personnelles (lorsqu'il est activé) retire les champs sensibles avant l'envoi. |
Sauvegardes de la base de données TLS 1.2+ | Non | Chiffrement standard des sauvegardes gérées. |
E2EE = chiffré de bout en bout. « Oui » signifie que même Spun ne peut pas lire les données. « Partiel » signifie chiffré de bout en bout au sein d'un tiers (Stripe, WhatsApp), mais visible par Spun pour la partie que nous traitons.
En transit
Tout ce qui circule entre votre navigateur, nos serveurs et nos sous-traitants ultérieurs est chiffré par TLS.
TLS 1.2+ partout sur le réseau
Tout le trafic navigateur ↔ Spun, Spun ↔ passerelle WhatsApp, Spun ↔ OpenAI / AssemblyAI / Deepgram / Sarvam / Azure et Spun ↔ Stripe est chiffré par TLS. Les versions plus anciennes du protocole sont désactivées sur l'équilibreur de charge.
Une périphérie protégée par Cloudflare
Cloudflare termine le TLS en périphérie et chiffre à nouveau vers l'origine. Les certificats d'origine lient les requêtes à nos serveurs Hetzner. Le WAF et la protection DDoS sont toujours actifs.
URL signées de courte durée
Les téléchargements de médias utilisent des URL présignées S3 SigV4 limitées à un seul objet, avec une expiration fixe. Même une URL divulguée cesse de fonctionner une fois expirée.
Au repos
Les données stockées sont isolées par organisation grâce à la sécurité au niveau des lignes de PostgreSQL, et les médias ne sont accessibles que par des URL signées limitées à un seul objet.
PostgreSQL avec sécurité au niveau des lignes
Chaque table contenant des données de clients est soumise à des politiques de sécurité au niveau des lignes (RLS) de PostgreSQL qui imposent l'isolation entre organisations. Même une requête à laquelle il manquerait par erreur un filtre d'organisation est refusée au niveau de la base de données.
L'Allemagne d'abord, avec une cellule aux États-Unis
La cellule principale (plan de contrôle, serveurs d'application, PostgreSQL et Redis) fonctionne chez Hetzner à Nuremberg (Allemagne, UE). Une deuxième cellule fonctionne à Manassas, en Virginie. Chaque organisation est rattachée à une seule cellule, et chaque nouvelle organisation est créée sur la cellule de l'UE.
Cloudflare R2 pour les médias
Les images, vidéos, fichiers audio et documents sont stockés dans Cloudflare R2. L'accès ne passe jamais par une adresse de compartiment public, uniquement par une URL signée limitée à un seul objet.
Appels vocaux et vidéo
Ce qui est réellement chiffré de bout en bout, ce qui ne l'est pas, et pourquoi. Nous ne présentons pas les appels de groupe comme chiffrés de bout en bout, parce qu'ils ne le sont pas.
Voix et vidéo en individuel : un vrai E2EE
Lorsque deux utilisateurs de Spun s'appellent, l'audio et la vidéo sont chiffrés de bout en bout avec DTLS-SRTP entre les deux navigateurs. Le serveur de Spun ne relaie que la signalisation SDP. Même si Cloudflare TURN doit servir de relais (NAT symétriques, pare-feu), il ne voit que des paquets chiffrés.
Appels de groupe (3 ou plus) : chiffrés en transit, pas de bout en bout
Les appels audio et vidéo de groupe et les salles de traduction à plusieurs participants utilisent LiveKit Cloud comme SFU (selective forwarding unit). Les médias sont chiffrés avec DTLS-SRTP entre chaque client et le SFU, mais le SFU les déchiffre à la réception pour les acheminer vers les autres participants. C'est l'architecture SFU standard, et elle n'est pas chiffrée de bout en bout.
Salles de traduction : le P2P d'abord lorsque c'est possible
Les salles de traduction essaient d'abord le P2P (E2EE) lorsque seuls deux participants sont présents, et basculent vers le SFU lorsqu'un troisième rejoint la salle ou lorsque les appareils sont trop limités pour le P2P. Le mode de connexion est visible dans l'interface d'appel.
Pourquoi nous ne revendiquons pas un E2EE complet pour les appels de groupe
LiveKit prend en charge un mode facultatif de chiffrement de bout en bout (avec l'API Encoded Insertable Streams) qui protège les médias même vis-à-vis du SFU. Il n'est pas activé actuellement sur les appels de groupe de Spun : l'ajouter suppose un mécanisme d'échange de clés entre les participants et une compatibilité navigateur/codec vérifiée pour chaque client pris en charge.
Si le chiffrement de bout en bout des appels de groupe est une exigence pour vous, contactez-nous à [email protected] : il figure sur la feuille de route et nous vous tiendrons informé de son avancement.
Paiements et identité
Les données les plus sensibles sont traitées par des prestataires spécialisés, si bien que Spun ne les voit et ne les stocke jamais.
Les données de carte vont directement à Stripe
Stripe Elements collecte les numéros de carte, les CVC et les dates d'expiration dans une iframe qui les transmet directement à Stripe, sans aucun passage par les serveurs de Spun. Nous ne recevons qu'un identifiant opaque de client ou de moyen de paiement. Stripe est certifié PCI-DSS niveau 1.
Les mots de passe sont hachés avec Argon2
Les comptes avec e-mail et mot de passe utilisent Argon2id avec un sel propre à chaque utilisateur. Nous ne conservons ni ne journalisons aucun mot de passe en clair. La connexion avec Google délègue entièrement l'authentification à Google : aucun mot de passe n'existe jamais dans Spun pour ces comptes.
Clés API et webhooks signés
Toutes les charges utiles des webhooks tiers (WhatsApp, Stripe, webhooks d'extensions) sont signées en HMAC-SHA256 et vérifiées côté serveur. Les jetons API des extensions sont des JWT de courte durée (RS256) avec un endpoint JWKS publié.
Messages WhatsApp : les limites de l'E2EE
L'E2EE de WhatsApp protège les messages tant qu'ils se trouvent dans l'infrastructure de WhatsApp. Dès que votre fournisseur de passerelle reçoit un message pour votre compte, la passerelle voit le texte en clair. C'est le cas de tous les fournisseurs de l'API WhatsApp Business : c'est ainsi que fonctionnent les boîtes de réception professionnelles.
D'autres questions ?
Pour un détail technique précis (suites de chiffrement, autorités de certification, politique de rotation des clés, etc.) ou pour demander une réponse à un questionnaire de sécurité, écrivez à [email protected].