Chiffrement côté serveur ou côté client : la différence décisive

Presque tous les services de transcription vantent le « chiffrement ». Mais tous les chiffrements ne protègent pas aussi bien. La différence décisive ne réside pas dans l’algorithme – mais dans la question de savoir qui détient la clé.

Cet article explique la différence entre le chiffrement côté serveur et le chiffrement côté client, et pourquoi cela fait une différence fondamentale pour vos fichiers audio.

Ce que le « chiffrement at rest » signifie vraiment

« Encryption at rest » signifie : les données sont enregistrées sous forme chiffrée. Le hic : le prestataire détient la clé. Tout collaborateur ayant accès à la base de données, tout administrateur cloud et tout pirate qui compromet le serveur peut déchiffrer les données.

La plupart des services cloud chiffrent les données dès qu’elles sont stockées sur le disque dur. Cela protège contre le vol de disques durs physiques – un scénario qui se produit rarement dans les centres de données professionnels. Cela ne protège pas contre :

• Les attaques contre l’application : quiconque pénètre dans l’application a accès à la fonction de déchiffrement.
• L’accès interne : les administrateurs du prestataire peuvent lire les données à tout moment.
• Les demandes des autorités : le prestataire peut déchiffrer les données et les communiquer.
• L’entraînement d’IA : le prestataire pourrait utiliser vos données pour améliorer ses modèles.

En bref : le chiffrement côté serveur protège le disque dur, pas vos données.

Ce que le chiffrement côté client fait différemment

Avec le chiffrement côté client, votre fichier audio est chiffré dans le navigateur avant d’atteindre le serveur. Le serveur ne stocke que des blobs chiffrés – il ne détient pas la clé. Même le prestataire ne peut pas lire les données stockées.

Le déroulé en détail :

• 1. Génération de la clé : pour chaque fichier, une clé de 256 bits qui lui est propre est générée dans le navigateur (File Encryption Key).
• 2. Chiffrement local : le fichier audio est chiffré avec AES-256-GCM directement dans le navigateur. Le serveur ne reçoit que des octets chiffrés.
• 3. Sécurisation de la clé : la clé du fichier est chiffrée avec votre clé maître personnelle, puis stockée ainsi sur le serveur. Sans votre mot de passe, personne ne peut y accéder.

Le résultat : seules des données chiffrées se trouvent sur le serveur. Aucun collaborateur du prestataire, aucun pirate et aucune autorité ne peut les déchiffrer sans votre clé.

La comparaison directe

Le tableau suivant montre la différence en un coup d’œil :

• Qui chiffre ? Chiffrement côté serveur : le prestataire. Chiffrement côté client : votre navigateur.
• Qui détient la clé ? Chiffrement côté serveur : le prestataire. Chiffrement côté client : vous seul.
• Le prestataire peut-il lire ? Chiffrement côté serveur : oui. Chiffrement côté client : non.
• Protection en cas de fuite ? Chiffrement côté serveur : limitée (la clé est souvent compromise en même temps). Chiffrement côté client : totale (la clé ne se trouve pas sur le serveur).
• Communication aux autorités ? Chiffrement côté serveur : le prestataire peut déchiffrer. Chiffrement côté client : le prestataire ne peut fournir que des blobs chiffrés.
• RGPD art. 34(3)(a) ? Chiffrement côté serveur : obligation de notification en cas de fuite. Chiffrement côté client : aucune obligation de notification, car les données sont illisibles.

Ce qui est stocké sur le serveur

Avec le chiffrement côté client, seules des données chiffrées résident durablement sur le serveur. La transcription est enregistrée sous forme chiffrée et ne peut être déchiffrée que par l’utilisateur lui-même. Les fichiers audio originaux sont automatiquement supprimés après le traitement – il ne reste sur le serveur qu’une version de lecture chiffrée.

Le résultat : même nous, en tant que prestataire, ne pouvons pas lire les transcriptions et fichiers audio stockés.

Comment reconnaître le type de chiffrement utilisé par un service

Si un service de transcription affirme que « vos données sont chiffrées », posez des questions précises :

• « Qui détient la clé de déchiffrement ? »– si le prestataire la détient, il s’agit d’un chiffrement côté serveur.
• « Vos collaborateurs peuvent-ils lire mes transcriptions ? » – chez les prestataires honnêtes pratiquant un chiffrement côté serveur, la réponse est : en théorie, oui.
• « Que se passe-t-il en cas de fuite de données ? »– si le prestataire évoque des obligations de notification au titre de l’art. 34 du RGPD, cela indique des données déchiffrables.
• « Puis-je vérifier moi-même le chiffrement ? » – avec un chiffrement côté client, vous pouvez vérifier dans l’onglet réseau du navigateur que seuls des octets chiffrés sont envoyés.

Quand le chiffrement côté serveur suffit-il ?

Le chiffrement côté serveur n’est pas mauvais en soi. Pour des contenus non sensibles – par exemple la transcription d’un podcast public – il peut suffire. Mais pour :

• Les dictées médicales et les entretiens avec les patients
• Les entretiens avec les clients dans les cabinets d’avocats
• Les réunions de direction et les entretiens stratégiques
• Les entretiens journalistiques avec des sources confidentielles
• Les entretiens RH et les évaluations du personnel
• Les audiences judiciaires et les témoignages

… le chiffrement côté client est la seule architecture qui offre une protection réelle. Car la question n’est pas de savoir si un prestataire abusera de vos données – mais qu’il en est techniquement incapable.

Conclusion

« Chiffré » n’est pas synonyme de « protégé ». La différence décisive réside dans la question de savoir qui contrôle la clé. Le chiffrement côté serveur protège les disques durs. Le chiffrement côté client protège vos données – y compris vis-à-vis du prestataire lui-même. Quiconque travaille avec des enregistrements audio confidentiels devrait connaître cette différence.