Fondamentaux

Chiffrement de bout en bout : ce qu’il protège et quelles sont ses limites

Le chiffrement de bout en bout empêche les intermédiaires de lire le contenu d’une communication, mais n’équivaut ni à une confidentialité totale ni à l’anonymat.

Par Daniel Sardá · Publié: 31 octobre 2026

7 min de lecture1 492 mots

Ana écrit un message pour Bruno et appuie sur « envoyer ». Entre eux se trouvent un réseau, des serveurs et, peut-être, plusieurs appareils. Le chiffrement de bout en bout vise à ce que le contenu quitte l’appareil d’Ana sous forme chiffrée et ne puisse être déchiffré qu’aux extrémités prévues, comme le téléphone de Bruno. Le service peut ainsi acheminer le message sans disposer de la clé nécessaire pour le lire.

Il s’agit d’une protection importante pour la vie privée, car elle réduit la confiance que nous devons accorder à ceux qui exploitent l’infrastructure. Toutefois, elle ne rend pas toute la communication invisible. Elle ne garantit pas non plus que les téléphones soient sûrs, que les sauvegardes soient protégées de la même manière ou que personne ne sache qui a parlé avec qui.

Idée clé : Le chiffrement de bout en bout protège le contenu entre les participants prévus ; il ne s’agit pas d’une promesse de confidentialité totale.

Ce que signifie « de bout en bout »

Chiffrer consiste, de manière simplifiée, à transformer une information lisible en données qui ne sont pas compréhensibles sans la clé appropriée. Dans un système de bout en bout bien conçu, les clés qui permettent d’accéder au contenu restent sous le contrôle des clients participants, et non du serveur qui distribue les messages.

Les « extrémités » sont généralement les appareils ou les clients autorisés des personnes qui communiquent. Si Bruno utilise un téléphone et un ordinateur, par exemple, le système peut devoir chiffrer le message pour chaque appareil autorisé. L’implémentation concrète varie, mais la propriété essentielle demeure identique : l’intermédiaire ne devrait ni recevoir le contenu en texte clair ni posséder les clés pour le récupérer.

La norme de messagerie sécurisée Messaging Layer Security décrit précisément un environnement dans lequel un service de distribution peut acheminer des messages protégés sans accéder à leur contenu. Cela ne signifie pas que toutes les applications emploient ce protocole ni que toutes offrent les mêmes garanties. « Chiffrement » est un terme vaste ; ce qui est déterminant, c’est l’endroit où l’information est déchiffrée et qui contrôle les clés.

Le parcours d’un message chiffré

Revenons au message d’Ana. Son application prend le texte et le chiffre avant de l’envoyer. Le serveur reçoit un ensemble de données qu’il peut stocker temporairement ou acheminer vers Bruno, mais qu’il ne devrait pas pouvoir transformer en message original. Lorsque le contenu parvient à un appareil autorisé de Bruno, cet appareil utilise la clé correspondante pour le déchiffrer.

L’image d’un coursier transportant un paquet fermé aide à comprendre le concept. Il connaît les données nécessaires à la livraison — comme l’origine, la destination ou le moment —, mais ne peut pas l’ouvrir. L’analogie a toutefois une limite : dans les systèmes numériques, il peut y avoir davantage d’informations opérationnelles exposées.

Cette conception répartit le pouvoir d’une manière significative. Si le prestataire ne possède pas les clés, sa bonne volonté cesse d’être la seule barrière face à la lecture. Pour une société ouverte, réduire la dépendance à l’égard des intermédiaires publics ou privés protège une sphère de décision personnelle. Malgré tout, la conception et les extrémités doivent être fiables.

Ce n’est pas la même chose que le chiffrement en transit

Une connexion protégée par TLS — la technologie courante derrière HTTPS — chiffre également les informations pendant leur transit. TLS 1.3 établit un canal confidentiel et intègre entre deux pairs. La différence réside dans l’identité de ces pairs.

Dans un service sans chiffrement de bout en bout, il peut exister un canal TLS entre Ana et le serveur, et un autre entre le serveur et Bruno. Le message se trouve protégé contre quiconque tente de l’intercepter sur le réseau, mais le serveur peut le recevoir sous une forme lisible avant de le réexpédier. Avec le chiffrement de bout en bout (E2EE), en revanche, le contenu demeure chiffré lors de son passage par le serveur.

Les deux couches sont complémentaires. Un service de messagerie de bout en bout peut toujours utiliser un transport sécurisé pour protéger des informations supplémentaires et rendre plus difficiles les altérations ou l’observation pendant le trajet.

Distinction utile : TLS protège un canal entre pairs ; le chiffrement de bout en bout vise à protéger le contenu depuis l’appareil émetteur jusqu’aux appareils récepteurs autorisés.

Ce qu’il protège et face à qui

Le chiffrement de bout en bout limite l’accès des intermédiaires au contenu des messages, appels ou fichiers couverts par le système. Il peut offrir une protection face à :

• des personnes qui interceptent le trafic sur un réseau non sécurisé ;
• des opérateurs d’infrastructure qui transportent ou stockent le contenu chiffré ;
• des intrus qui obtiennent des données du serveur, mais pas les clés des extrémités.

Ces garanties dépendent du modèle de menace : de qui l’on cherche à protéger l’information et de quelles capacités dispose cette entité. Le chiffrement de bout en bout évite de traiter chaque intermédiaire comme un lecteur potentiel, mais les participants accèdent bel et bien au contenu. C’est pourquoi affirmer que « personne ne peut lire les messages » serait inexact.

Ce qui reste exposé

La première limite concerne les métadonnées des communications : des données relatives à la communication, et non nécessairement son contenu. Selon l’architecture du service, elles peuvent inclure des identifiants, des adresses IP, des horaires, des destinataires, la taille des messages ou la fréquence des contacts. L’Electronic Frontier Foundation avertit que le chiffrement de bout en bout ne dissimule pas nécessairement ces informations.

Cela explique également pourquoi confidentialité et anonymat ne sont pas synonymes. Une conversation peut être illisible pour le serveur tout en restant associée à des comptes, des numéros ou des connexions identifiables.

La seconde limite se situe au niveau des extrémités. Une fois déchiffré, le message apparaît sur un écran. Un téléphone infecté, déverrouillé ou partagé peut l’exposer. La vie privée et la sécurité numérique dépendent aussi de cette protection quotidienne. Le destinataire peut le copier, le photographier, l’exporter ou le montrer à une autre personne. Le chiffrement protège le canal, il ne contrôle pas tout ce qui advient après la distribution.

Les notifications et les sauvegardes ont également leur importance. Un aperçu sur l’écran verrouillé peut révéler une partie du texte. Une sauvegarde stockée via un autre système peut bénéficier de protections différentes. Il ne faut pas supposer que, parce qu’une conversation utilise le chiffrement de bout en bout, toutes ses copies en font autant.

Avertissement : Un canal confidentiel ne compense pas un appareil compromis et n’étend pas automatiquement sa protection aux captures d’écran, exportations et sauvegardes.

Clés, identité et authentification

Le chiffrement répond à une question : qui possède la clé nécessaire pour lire ? L’authentification répond à une autre : cette clé appartient-elle réellement à Bruno ?

Si un attaquant parvient à se faire passer pour le destinataire lors de l’échange de clés, Ana pourrait chiffrer pour la mauvaise personne. Les systèmes modernes intègrent des mécanismes pour détecter cette usurpation ; certains permettent de vérifier des codes ou des empreintes de sécurité par un autre canal. La spécification du protocole Sesame de Signal montre comment les sessions, les identités et la multiplicité des appareils font partie de la problématique, bien que ses détails ne se généralisent pas à l’ensemble des services.

Pour des communications particulièrement sensibles, vérifier l’identité de la clé offre une garantie supplémentaire. Il s’agit d’une décision liée au contexte, aux conséquences d’une erreur et à la personne face à laquelle on cherche à se protéger.

Comment évaluer une promesse de confidentialité

L’étiquette « chiffrement » à elle seule en dit peu. Avant de confier des informations sensibles à un service, il convient de se demander :

• Le contenu est-il déchiffré sur le serveur ou seulement sur les appareils prévus ?
• Qui contrôle les clés et le prestataire peut-il les obtenir ?
• Quels contenus sont couverts : messages, appels, fichiers et groupes ?
• Quelles métadonnées le système conserve-t-il et pendant combien de temps ?
• Comment de nouveaux appareils sont-ils ajoutés et authentifiés ?
• Les sauvegardes bénéficient-elles de la même protection ou d’une protection différente ?

Les réponses peuvent varier selon les services, les fonctionnalités et les configurations. C’est pourquoi il est préférable de consulter une documentation technique spécifique plutôt que d’extrapoler la garantie d’une fonctionnalité à l’ensemble de l’application.

Le chiffrement de bout en bout n’élimine pas la nécessité de veiller aux mots de passe, aux mises à jour, aux appareils et aux sauvegardes. Sa valeur est plus concrète et, précisément pour cette raison, plus solide : il réserve l’accès au contenu aux extrémités prévues et réduit le nombre de tiers capables de le lire. Comprendre où se trouvent les clés, quelles données restent exclues et ce qui se produit lors du déchiffrement permet d’utiliser cette protection sans la transformer en un faux sentiment d’invulnérabilité.