Chiffrement côté serveur ou côté client : à quel modèle faire confiance ?

Le chiffrement côté serveur chiffre les données sur le serveur après avoir reçu le texte en clair, ce qui exige de faire confiance au fournisseur du service. Le chiffrement côté client chiffre les données dans ton navigateur avant l'envoi, de sorte que le serveur ne voit jamais le texte en clair. Pour le partage de secrets, le chiffrement côté client est plus sûr parce qu'il élimine le service comme point de confiance — même un serveur compromis ne peut pas lire tes données.

Cet article compare les deux approches : comment elles fonctionnent, ce que chacune te demande de croire sur parole et où se situent les vrais compromis. Ce n'est pas un plaidoyer pour un camp — c'est un cadre pour évaluer quel modèle correspond à ton modèle de menace.

Pour un aperçu rapide de l'importance du chiffrement côté client, lis notre article précédent. Pour un examen détaillé de l'implémentation spécifique de Vaulted, lis notre analyse approfondie du zero-knowledge.

Comment fonctionne le chiffrement côté serveur

Dans le modèle côté serveur, le service prend en charge le chiffrement à ta place. Le déroulement typique :

Tu saisis un secret dans le navigateur
Ton navigateur envoie le texte en clair au serveur via TLS
Le serveur chiffre les données avec une clé qu'il gère lui-même
Le texte chiffré est stocké dans la base de données
Lorsque le destinataire demande le secret, le serveur le déchiffre et renvoie le texte en clair

La clé de chiffrement ne quitte jamais le serveur. Elle peut résider dans un module de sécurité matériel (HSM), un service de gestion de clés cloud (KMS) ou un fichier de configuration — mais le serveur la contrôle entièrement.

Le modèle de confiance côté serveur

Avec le chiffrement côté serveur, tu fais confiance :

À l'opérateur du service pour qu'il ne lise pas tes données (il détient la clé et le texte en clair en mémoire pendant le chiffrement/déchiffrement)
À l'infrastructure pour qu'elle ne soit pas compromise (un serveur compromis expose à la fois les clés et les données)
Aux employés de l'opérateur pour qu'ils n'abusent pas de leur accès (quiconque a accès au serveur peut potentiellement lire les secrets)
À la juridiction légale pour qu'elle ne contraigne pas à la divulgation (l'opérateur peut être forcé de remettre les données puisqu'il détient les clés)
Aux journaux et au monitoring du serveur pour qu'ils n'enregistrent pas le texte en clair (les frameworks de journalisation peuvent involontairement consigner des données sensibles)

Ce n'est pas forcément un mauvais modèle. De nombreux services l'utilisent avec succès — le stockage cloud, les fournisseurs d'e-mail et les services de base de données s'appuient tous sur le chiffrement côté serveur. La question est de savoir si le compromis convient à ton cas d'usage.

Comment fonctionne le chiffrement côté client

Dans le modèle côté client, le chiffrement a lieu dans le navigateur avant qu'aucune donnée n'atteigne le serveur. Le déroulement est différent :

Tu saisis un secret dans le navigateur
Le navigateur génère une clé de chiffrement et chiffre les données localement
Seul le texte chiffré est envoyé au serveur
La clé de chiffrement est transmise au destinataire par un canal séparé (généralement le fragment d'URL)
Le navigateur du destinataire déchiffre le texte chiffré localement

Le serveur ne voit jamais le texte en clair et ne détient jamais la clé de chiffrement. Il stocke et restitue des blocs chiffrés — rien de plus.

Vaulted utilise ce modèle. Chaque secret reçoit une nouvelle clé AES-256-GCM. La clé est placée dans le fragment d'URL (#), que les navigateurs n'incluent jamais dans les requêtes HTTP, conformément à la RFC 3986. Le serveur reçoit le texte chiffré et un IV aléatoire de 12 octets pour le stockage, mais la clé reste entièrement dans le lien partagé entre l'expéditeur et le destinataire.

Le modèle de confiance côté client

Avec le chiffrement côté client, tu fais confiance :

Au navigateur pour implémenter correctement la cryptographie (la Web Crypto API délègue à des moteurs cryptographiques natifs comme BoringSSL ou NSS)
Au code de l'application pour effectuer réellement le chiffrement côté client (tu peux le vérifier en inspectant les requêtes réseau)
Au canal de transmission du lien pour qu'il soit sûr (quiconque possède l'URL complète, fragment compris, peut déchiffrer le secret)
À l'appareil du destinataire pour qu'il ne soit pas compromis (après le déchiffrement, un logiciel malveillant ou une capture d'écran peut accéder au texte en clair)

Tu ne fais pas confiance au serveur, à l'opérateur du service, à ses employés ou à sa juridiction légale. Le serveur est un relais de stockage pour des données chiffrées qu'il ne peut pas lire.

Comparer les compromis

Aucun des deux modèles n'est universellement meilleur. Chacun fait des compromis différents entre sécurité, facilité d'utilisation et richesse fonctionnelle.

Propriétés de sécurité

Propriété	Côté serveur	Côté client
Exposition en cas de fuite serveur	Clés + texte chiffré exposés	Seul le texte chiffré exposé (inutile sans les clés)
L'opérateur peut lire les données	Oui (détient les clés)	Non (n'a jamais les clés)
Risque de contrainte légale	L'opérateur peut s'exécuter (a accès)	L'opérateur ne peut pas s'exécuter (n'a pas accès)
Risque d'interception du lien	Sans objet (pas de clé dans le lien)	URL complète = accès complet (atténué par une phrase secrète)
Attaque de l'homme du milieu	TLS protège le transit ; le serveur voit le texte en clair	TLS protège le texte chiffré ; la clé dans le fragment n'est jamais envoyée

Propriétés de facilité d'utilisation

Propriété	Côté serveur	Côté client
Charge de gestion des clés	Aucune pour l'utilisateur (le serveur s'en charge)	L'utilisateur doit partager le lien de façon sûre
Récupération de mot de passe	Possible (le serveur détient les clés)	Impossible (les clés ne sont que dans le lien)
Recherche et indexation	Le serveur peut chercher dans le texte en clair	Impossible sans déchiffrement
Souplesse de partage	Le serveur peut rechiffrer pour de nouveaux destinataires	Nécessite un nouveau lien par destinataire
Accès hors ligne	Nécessite une connexion au serveur pour déchiffrer	Possible si le texte chiffré et la clé sont mis en cache localement

Compromis fonctionnels

Fonctionnalité	Côté serveur	Côté client
Journalisation d'audit du contenu	Possible	Impossible (le serveur ne peut pas lire le contenu)
Politiques basées sur le contenu	Possible (DLP, analyse de conformité)	Impossible sans déchiffrement
Rotation des clés	Le serveur peut rechiffrer avec de nouvelles clés	Nécessite de régénérer et de repartager les liens
Contrôle d'accès multipartite	Le serveur peut gérer des clés par utilisateur	Chaque destinataire a besoin de la clé directement
Garantie zero-knowledge	Non	Oui

Quand le chiffrement côté serveur est acceptable

Le chiffrement côté serveur est un choix raisonnable quand :

Tu fais confiance à l'opérateur du service et à ses pratiques de sécurité
Tu as besoin de fonctionnalités qui exigent un accès aux données côté serveur (recherche, partage, analyse de conformité)
La sensibilité des données ne justifie pas le coût en facilité d'utilisation du chiffrement côté client
Tu évolues dans un environnement réglementé où les certifications de conformité de l'opérateur comptent plus que les garanties zero-knowledge
La complexité de la gestion des clés doit être prise en charge par le service, pas par l'utilisateur

Les services de stockage cloud, l'e-mail d'entreprise et le chiffrement géré des bases de données utilisent tous ce modèle de manière efficace.

Quand le chiffrement côté client est nécessaire

Le chiffrement côté client devient nécessaire quand :

Tu ne peux pas ou ne devrais pas confier tes données à l'opérateur du service
Les données sont assez sensibles pour qu'une fuite serveur ne doive pas exposer le texte en clair
Tu as besoin d'une garantie zero-knowledge — une preuve mathématique que le serveur ne peut pas lire tes données
Des exigences légales ou de conformité imposent que l'opérateur du service n'ait aucun accès au contenu
Tu veux une protection contre les menaces internes chez le fournisseur du service

Le partage de secrets est l'un des cas d'usage les plus forts pour le chiffrement côté client. Les données sont sensibles par nature (mots de passe, clés API, identifiants), le partage est éphémère (limité en consultations, limité dans le temps) et la relation de confiance est minimale (tu ne connais peut-être pas l'opérateur du service, ou tu ne lui fais pas confiance).

L'approche de Vaulted

Vaulted s'appuie exclusivement sur le chiffrement côté client. Chaque secret est chiffré dans le navigateur avec une nouvelle clé AES-GCM avant qu'aucune donnée n'atteigne le serveur. La clé voyage uniquement dans le fragment d'URL, et une protection par phrase secrète facultative ajoute une seconde couche via la dérivation de clé PBKDF2 et l'encapsulation de clé AES-KW.

Le serveur stocke le texte chiffré avec une durée de vie et un compteur de consultations. Il ne peut ni déchiffrer, ni rechercher, ni inspecter le contenu. Une fuite complète de la base de données ne livre que des blocs chiffrés — inutilisables en pratique sans les clés qui n'existent que dans les liens partagés.

Pour tous les détails cryptographiques — génération de clé, gestion de l'IV, encapsulation par phrase secrète et les appels exacts à la Web Crypto API — lis notre analyse approfondie du chiffrement zero-knowledge.

Faire ton choix

Le bon modèle de chiffrement dépend de ce que tu protèges et de qui tu es prêt à croire sur parole.

Si tu as besoin de fonctionnalités comme la recherche, la récupération ou la gestion centralisée des clés, le chiffrement côté serveur est le choix pratique. Si tu as besoin d'une garantie que personne — ni le service, ni ses employés, ni une décision de justice — ne peut lire tes données, le chiffrement côté client est le seul modèle qui l'offre.

Pour le partage de secrets, la réponse est claire : les données sont sensibles, l'interaction est brève, et moins il y a de parties capables d'accéder au texte en clair, mieux c'est.

Prêt à partager un secret avec un chiffrement zero-knowledge ? Crée un secret sur Vaulted — tes données ne quittent jamais ton navigateur en clair.