NaraNara
    ← Retour au blog

    Chiffrement de bout en bout ou côté client : quelle différence ?

    Comprenez pourquoi la gestion des clés et la politique de récupération font la différence entre chiffrement de bout en bout et chiffrement côté client....

    N
    L'équipe Nara

    Deux appareils communiquant de façon chiffrée

    Le chiffrement côté client désigne l'endroit où vos données sont verrouillées ; le chiffrement de bout en bout garantit ce qui reste verrouillé pendant tout le trajet. La vraie question n'est donc pas technique mais patrimoniale : qui détient la clé ? Si c'est vous seul, le fournisseur ne peut rien lire, ni sur ses serveurs ni en transit. Mais les deux modèles restent vulnérables si votre appareil est compromis ou si le fournisseur propose une récupération de mot de passe mal conçue.

    En bref:

    • La sécurité du chiffrement dépend principalement de la gestion des clés, qui doit privilégier la détention exclusive par l'utilisateur pour garantir la confidentialité.
    • Le chiffrement de bout en bout verrouille le contenu en transit entre deux appareils, tandis que le chiffrement côté client protège dès l'origine, notamment pour le stockage.
    • La compromission de l'appareil ou la présence de logiciels malveillants réduit considérablement l'efficacité de tout système de chiffrement.
    • La visibilité des métadonnées permet souvent de déduire des profils comportementaux, indépendamment de la solidité du contenu chiffré.
    • La politique de récupération des clés et la gestion des accès sont des critères essentiels pour évaluer le véritable niveau de confidentialité d'un service.

    Table des matières

    Chiffrement de bout en bout vs chiffrement côté client : deux logiques différentes

    Ces deux termes se recoupent souvent dans les discours commerciaux, ce qui entretient la confusion. Pourtant, ils décrivent des choses distinctes.

    Le chiffrement de bout en bout (E2EE) désigne une architecture où les données restent illisibles depuis l'appareil qui les envoie jusqu'à celui qui les reçoit. Aucun intermédiaire, y compris le fournisseur du service, ne peut déchiffrer le contenu en transit. C'est un modèle pensé pour la communication entre deux ou plusieurs identités.

    Le chiffrement côté client (CSE), lui, décrit une opération : les données sont chiffrées sur l'appareil de l'utilisateur avant même de quitter la machine. Ce chiffrement local protège le contenu pendant l'envoi et pendant le stockage, sans préjuger de ce qui se passe ensuite sur les serveurs. Dans la pratique, les deux approches se recoupent souvent pour le stockage zéro-knowledge : une donnée chiffrée côté client, si le fournisseur ne détient jamais la clé, produit une garantie proche de celle de l'E2EE.

    Concrètement, cela donne :

    • E2EE : verrouille le trajet entre deux points, typique des applications de messagerie (Signal Protocol, avec ses clés de session renouvelées à chaque message).
    • CSE : verrouille le lieu d'origine, typique du stockage cloud, où la clé peut être dérivée directement depuis le mot de passe de l'utilisateur.
    • Recoupement : un service de sauvegarde chiffré côté client, sans clé conservée par le fournisseur, devient de facto une architecture zéro-knowledge proche de l'E2EE.

    Qui détient réellement les clés, et pourquoi cela change tout

    La gestion des clés est le nœud de toute l'affaire. En E2EE, les clés sont généralement négociées entre les participants eux-mêmes, souvent via un échange de clés type Diffie-Hellman, renouvelé à chaque session pour garantir la confidentialité persistante. Dans un modèle de chiffrement côté client appliqué au stockage, la clé provient le plus souvent d'une dérivation locale à partir du mot de passe de l'utilisateur, sans jamais transiter vers le serveur.

    Cette distinction a des conséquences directes :

    • Une clé négociée entre pairs limite le risque à la compromission d'un des deux appareils.
    • Une clé dérivée d'un mot de passe fait porter tout le poids de la sécurité sur la robustesse de ce mot de passe.
    • Un mécanisme de récupération (escrow, partage de clé en plusieurs fragments ou shards) réintroduit un tiers capable, techniquement, de reconstituer l'accès. Cela affaiblit la promesse zéro-knowledge, même si le fournisseur affirme le contraire.

    Conseil de pro : activez systématiquement l'authentification à plusieurs facteurs et, si le service le permet, utilisez une clé matérielle plutôt qu'un code envoyé par SMS. Pensez aussi à faire tourner vos clés de chiffrement régulièrement quand l'option existe, plutôt que de garder la même depuis la création du compte.

    Ce que le chiffrement ne protège pas : endpoints, métadonnées et promesses marketing

    Aucun chiffrement, aussi solide soit-il, ne protège un appareil déjà infecté. Si l'appareil de l'émetteur ou du destinataire est compromis par un logiciel malveillant, un enregistreur de frappe ou un outil d'espionnage comme Pegasus, l'attaquant accède aux données en clair avant même qu'elles soient chiffrées, ou après leur déchiffrement à l'arrivée. L'E2EE et le CSE deviennent alors inopérants, non parce qu'ils ont échoué, mais parce que le problème se situe en amont du chiffrement.

    Deuxième angle mort : les métadonnées. Un fournisseur qui ne peut pas lire le contenu de vos messages voit souvent encore qui communique avec qui, à quelle heure, depuis quel appareil, et parfois la taille des fichiers échangés. Ces informations, cumulées, dessinent un profil comportemental détaillé sans qu'une seule ligne de contenu n'ait été lue.

    Enfin, méfiez-vous du vocabulaire. Un service qui annonce « chiffré au repos » ne garantit rien contre l'accès du fournisseur lui-même : cela signifie seulement que les données sont verrouillées sur le disque, mais le fournisseur détient souvent la clé pour les déchiffrer à la demande. Les termes à rechercher réellement sont « zéro-knowledge » ou « chiffrement côté client vérifiable », qui impliquent une impossibilité technique, et non une simple politique interne, d'accès aux données.

    Trois limites du chiffrement expliquées

    Messagerie ou stockage : quel modèle choisir selon l'usage

    Le bon modèle dépend presque toujours de la nature de l'échange.

    1. Communications en temps réel entre identités connues : privilégiez l'E2EE. C'est le terrain naturel des protocoles comme Signal, où chaque message est chiffré individuellement entre deux appareils identifiés, avec renouvellement des clés à chaque échange.
    2. Stockage ou sauvegarde de fichiers sensibles : privilégiez une architecture zéro-knowledge basée sur du chiffrement côté client. Des services comme Proton Drive, Tresorit ou Cryptomator illustrent cette logique : le fichier est verrouillé avant même de quitter l'appareil, et le fournisseur ne conserve jamais la clé de déchiffrement.
    3. Scénarios mixtes : une sauvegarde chiffrée côté client combinée à une synchronisation entre appareils, ou une indexation locale des fichiers pour permettre une recherche sans jamais exposer le contenu en clair au serveur. Ces architectures existent, mais elles coûtent cher en complexité technique et en fluidité d'usage.

    Ce que vous perdez en confort quand vous gagnez en confidentialité

    Le zéro-knowledge a un prix, et ce prix se paie en fonctionnalités. Un fournisseur qui ne voit jamais vos données ne peut pas non plus vous offrir certains services pratiques.

    • Recherche plein texte dans vos fichiers ou vos messages : difficile à réaliser côté serveur sans casser la promesse de confidentialité.
    • Aperçus automatiques de documents ou de photos dans une interface web.
    • Modération automatisée des contenus signalés, puisque le fournisseur ne peut littéralement pas les lire.
    • Récupération de compte simplifiée : un mot de passe oublié sans mécanisme de secours signifie, dans un vrai système zéro-knowledge, une perte de données définitive.

    Pour les entreprises, la parade passe par la formation des équipes à la gestion rigoureuse des mots de passe et par des sauvegardes hors ligne des clés critiques, stockées séparément du service lui-même.

    Ce que le RGPD attend réellement de votre chiffrement

    Sous l'article 32 du RGPD, le chiffrement figure explicitement parmi les mesures techniques et organisationnelles attendues pour protéger les données personnelles selon le niveau de risque. Ce n'est pas une case à cocher isolée : c'est une brique dans un ensemble plus large.

    La CNIL recommande d'associer le chiffrement à l'authentification forte et à la minimisation des données plutôt que de considérer le chiffrement comme une protection suffisante à elle seule. Concrètement, cela implique :

    • Chiffrer les données sensibles, en transit et au repos, avec un niveau adapté au risque réel.
    • Activer une authentification à plusieurs facteurs sur tous les comptes ayant accès à des données personnelles.
    • Ne collecter et ne conserver que les données strictement nécessaires, pendant une durée définie.
    • Documenter les mesures prises, car la sécurité des données combine toujours technique et gouvernance.

    Le chiffrement ne résout en revanche ni les obligations de conservation légale, ni la question des métadonnées accessibles au fournisseur : ce sont des sujets à traiter séparément, dans votre politique de confidentialité.

    Comment choisir entre les deux modèles : la checklist à suivre

    Avant de trancher, identifiez la menace que vous voulez réellement neutraliser. Un fournisseur indiscret, un attaquant réseau, ou un appareil potentiellement compromis appellent des réponses différentes.

    1. Définissez la menace prioritaire : protection contre le fournisseur lui-même, contre une interception réseau, ou contre un vol d'appareil.
    2. Posez trois questions au fournisseur : qui détient les clés, quelle est la politique de récupération en cas de mot de passe perdu, et quelles métadonnées restent visibles côté serveur.
    3. Vérifiez la robustesse de vos accès : mot de passe unique et complexe, authentification à plusieurs facteurs, clé matérielle si disponible.
    4. Testez la politique de récupération avant d'en avoir besoin : un service zéro-knowledge honnête vous préviendra qu'un mot de passe perdu est, par principe, irrécupérable.
    Critère à vérifier Ce qu'il révèle
    Qui détient la clé de déchiffrement Distingue un vrai zéro-knowledge d'un simple chiffrement au repos
    Existence d'un mécanisme de récupération Signale un compromis entre confort et confidentialité stricte
    Visibilité des métadonnées Indique ce que le fournisseur peut déduire sans lire le contenu
    Authentification proposée Détermine la résistance réelle contre un endpoint compromis

    Cette checklist de sécurité pour évaluer une application de partage de photos détaille chacun de ces points pour les usages familiaux.

    Comment Nara applique le chiffrement de bout en bout à vos souvenirs

    Nara a construit son architecture de partage de souvenirs autour du chiffrement de bout en bout, précisément parce que les albums de famille contiennent ce qu'on a de plus intime : visages d'enfants, moments privés, récits partagés entre proches.

    Concrètement, cela se traduit par :

    • Une authentification sécurisée à chaque connexion, pour limiter le risque d'accès non autorisé au compte.
    • Un système d'invitation contrôlé, où seules les personnes explicitement conviées peuvent contribuer à un souvenir partagé.
    • Une conservation des médias sans dégradation qui préserve l'authenticité du souvenir.

    Pour aller plus loin sur les critères à examiner avant de choisir une application de ce type, cet article sur la sécurité et le partage de photos en famille détaille les questions à poser à tout fournisseur.

    Ce que les décideurs devraient vraiment retenir de ce débat

    La plupart des guides sur ce sujet s'arrêtent à la définition et laissent le lecteur croire qu'un chiffrement « fort » suffit à garantir la confidentialité. C'est une erreur d'analyse. Le chiffrement le plus robuste au monde ne protège rien si la politique de récupération de mot de passe contient une porte dérobée, ou si l'appareil de l'utilisateur est déjà infecté avant même que la première clé ne soit générée.

    Ce que les décideurs devraient vraiment retenir de ce débat — overview diagram

    Ce que j'observe, c'est un déséquilibre récurrent entre le marketing des fournisseurs et la réalité technique : on vend du « chiffré » comme un label absolu, alors que la véritable question est toujours la même, qui peut reconstruire la clé, et dans quelles conditions. Un service qui répond honnêtement « personne, pas même nous » mérite plus de confiance qu'un service qui promet une sécurité totale sans jamais détailler sa gestion des clés.

    Si vous devez prioriser une seule chose avant toute autre, ce n'est pas le protocole cryptographique utilisé. C'est la politique de récupération. Elle révèle, plus que tout argument commercial, si un fournisseur a réellement construit un système zéro-knowledge ou s'il a simplement habillé un chiffrement classique d'un vocabulaire rassurant.

    — Théo Rosen

    Sources

    Recommandations