Choisir une messagerie sécurisée : 12 questions utiles

Une messagerie peut afficher un cadenas, se présenter comme privée et laisser pourtant des questions importantes sans réponse.

Quelles conversations sont chiffrées ? Les pièces jointes sont-elles protégées ? Où les clés sont-elles stockées ? Que conserve le serveur ? Que se passe-t-il si vous perdez un appareil ? Les clés peuvent-elles changer sans avertissement ?

Ces détails permettent d’identifier les protections utiles et les preuves qui manquent encore. Aucune liste de vérification ne certifie, à elle seule, la sécurité d’un produit.

Ce guide propose 12 questions pratiques à poser avant de confier à une messagerie chiffrée vos conversations personnelles, vos fichiers confidentiels ou votre travail sensible.

Qu’est-ce qu’une messagerie sécurisée ?

Une messagerie sécurisée est un service de communication conçu pour protéger les conversations contre les accès non autorisés, l’interception, la compromission des comptes et l’exposition involontaire des données.

Une application sérieuse devrait au minimum utiliser un transport réseau sécurisé, une authentification robuste, des contrôles d’accès rigoureux et des pratiques de traitement des données clairement expliquées.

Pour les conversations très confidentielles, elle devrait aussi proposer le chiffrement de bout en bout.

Le chiffrement de bout en bout, ou E2EE, protège les contenus pris en charge en les chiffrant sur l’appareil de l’expéditeur et en les déchiffrant sur un appareil autorisé du destinataire. Le service peut acheminer les données chiffrées sans avoir besoin du corps du message lisible.

Le chiffrement n’est toutefois qu’une partie de la sécurité d’une messagerie.

Une évaluation complète doit aussi examiner :

• Les conversations qui sont chiffrées
• La protection des photos et des fichiers
• L’emplacement des clés privées
• Les possibilités de vérification des clés entre contacts
• Les métadonnées qui restent visibles
• Le fonctionnement de la récupération du compte et des clés
• Les conséquences de la compromission d’un appareil
• La manière dont le service documente ses limites

Pour approfondir ces bases, consultez notre explication du chiffrement de bout en bout.

Pourquoi le mot « chiffré » ne suffit pas

Presque toutes les messageries modernes chiffrent le trafic réseau avec HTTPS, TLS ou un autre transport protégé.

Cette protection compte, mais elle ne signifie pas nécessairement que la conversation est chiffrée de bout en bout.

Avec le chiffrement du transport, les données sont protégées entre votre appareil et le service. Celui-ci peut encore recevoir le contenu lisible avant de l’acheminer par une autre connexion protégée.

Avec l’E2EE, le contenu pris en charge est chiffré à l’intention des participants avant d’atteindre le service de messagerie.

Cette différence détermine qui peut techniquement accéder au corps du message.

C’est pourquoi il faut poser des questions précises plutôt que se satisfaire d’une étiquette générale « chiffré ».

Affirmation	Question à poser
« Vos conversations sont chiffrées »	Uniquement pendant le transport, ou de bout en bout ?
« Vos données sont sécurisées »	Quelles données, contre quelles menaces et pendant combien de temps ?
« Nous ne pouvons pas lire vos messages »	Cela couvre-t-il les discussions individuelles, groupes, médias, appels et sauvegardes ?
« Privé dès la conception »	Quelles métadonnées et informations de fonctionnement restent accessibles ?
« Récupération sécurisée »	Qui peut restaurer les clés, et quel secret est nécessaire ?

1. Quelles conversations sont chiffrées de bout en bout ?

Ne supposez pas qu’une affirmation sur le chiffrement s’applique à toutes les parties d’une application.

Un service peut offrir des protections différentes pour :

• Les conversations individuelles
• Les groupes privés
• Les groupes publics
• Les canaux de diffusion
• Les appels audio et vidéo
• Les stories ou publications temporaires
• Les bots et comptes automatisés
• L’historique synchronisé

Demandez au fournisseur d’indiquer précisément le périmètre.

Voici un exemple de réponse précise :

Le corps des messages directs et leurs médias sont chiffrés sur les appareils participants. Les groupes privés compatibles sont chiffrés de bout en bout avec LGS1, avec rotation automatique des clés d’expéditeur lors des changements de membres. Les canaux utilisent une architecture distincte, lisible par le serveur, et ne sont pas présentés comme E2EE.

Une réponse peu utile serait :

Vos communications bénéficient d’un chiffrement de qualité militaire.

La première donne des informations évaluables. La seconde emploie une formule impressionnante sans définir le contenu protégé ni le modèle de menace.

2. Les photos, vidéos et pièces jointes sont-elles aussi chiffrées ?

Une application peut chiffrer le texte et traiter les médias envoyés par un autre système.

Une question importante se pose alors : la photo est-elle chiffrée côté client avant l’envoi, ou seulement protégée par des autorisations serveur et le chiffrement du transport ?

Renseignez-vous sur :

• Les photos et les vidéos
• Les documents
• Les messages vocaux
• Les aperçus de liens
• Les miniatures
• Les fichiers temporaires d’envoi
• Les médias en cache
• L’autorisation de téléchargement

La protection des médias devrait être décrite séparément, plutôt que noyée dans une affirmation générale sur les « messages ».

Distinguez l’accès aux octets chiffrés de l’accès à la clé de déchiffrement. Certaines conceptions distribuent les pièces jointes chiffrées depuis un stockage moins restreint ; cela ne constitue pas automatiquement une exposition en clair. La question essentielle est de savoir si un acteur non autorisé peut obtenir le média lisible ou sa clé, et quelles métadonnées le circuit de stockage révèle.

3. Où les clés de chiffrement sont-elles créées et stockées ?

La confiance dans le chiffrement dépend de la gestion des clés.

Pour l’E2EE côté client, les éléments de clé privée devraient rester sous le contrôle des appareils participants. Les clés publiques peuvent être partagées pour établir une communication chiffrée, mais les clés privées exigent une protection renforcée.

Cherchez des réponses claires :

• La clé privée est-elle créée sur l’appareil ?
• Est-elle parfois envoyée sans chiffrement ?
• Le fournisseur peut-il la dériver ou la remplacer ?
• Un autre appareil connecté peut-il l’obtenir automatiquement ?
• Son stockage local est-il protégé ?
• Que se passe-t-il après une réinitialisation de clé ?
• La réinstallation de l’application crée-t-elle une nouvelle clé d’identité ?

La documentation n’a pas besoin d’exposer tous les détails techniques. Elle devrait néanmoins expliquer qui contrôle les clés privées et leur cycle de vie.

4. Les contacts peuvent-ils vérifier leurs clés respectives ?

Le chiffrement de bout en bout protège la conversation attendue seulement si les clés appartiennent aux participants visés.

De nombreuses messageries représentent une clé publique par une empreinte, un numéro de sécurité, un QR code ou une autre valeur de vérification.

Deux contacts peuvent comparer cette valeur par un moyen de confiance, par exemple :

• Une rencontre en personne
• Un appel vocal dont l’interlocuteur a été vérifié
• Un compte précédemment authentifié
• Un annuaire d’entreprise fiable

La vérification renforce la confiance dans l’utilisation des clés attendues ; elle ne prouve pas, à elle seule, l’identité d’une personne. Certains produits proposent aussi des contrôles de transparence des clés, comme la vérification automatique de Signal. Vérifiez les conditions de compte et de version prises en charge au lieu d’exiger une procédure exclusivement manuelle pour tous les produits.

Demandez également ce qui se passe lorsqu’une empreinte change.

Ce changement peut avoir une explication légitime : réinitialisation, remplacement d’un appareil ou récupération. Il devrait cependant être visible. Un remplacement silencieux rend plus difficile la détection d’un changement inattendu de clé d’identité.

5. Quelles métadonnées le service conserve-t-il ?

Le contenu des messages et leurs métadonnées sont deux catégories distinctes.

Un service peut être incapable de lire le corps d’un message E2EE tout en traitant des informations nécessaires à l’acheminement, à la synchronisation et à l’affichage de la conversation.

Selon le système, cela peut comprendre :

• Les identifiants de compte de l’expéditeur et du destinataire
• Les membres de la conversation
• Les horodatages des messages
• Les accusés de livraison et de lecture
• La taille des messages
• Les événements de réaction et de modification
• Les sessions des appareils
• Les curseurs de synchronisation
• Les éléments de clé publique
• Les jetons de notification push
• Les journaux de sécurité et de prévention des abus

L’existence de métadonnées de fonctionnement ne rend pas automatiquement un service dangereux.

Les questions importantes sont :

• Qu’est-ce qui est collecté ?
• Pourquoi est-ce nécessaire ?
• Combien de temps ces données sont-elles conservées ?
• Qui peut y accéder ?
• L’utilisateur peut-il les exporter ou les supprimer ?
• Servent-elles à la publicité ou à un profilage sans rapport avec le service ?

Soyez prudent lorsqu’un fournisseur prétend ne conserver « aucune métadonnée » sans définir ce qu’il entend par ce terme.

6. Comment votre compte est-il authentifié ?

Un chiffrement robuste ne compense pas une sécurité de compte faible.

Un attaquant qui prend le contrôle d’un compte peut usurper l’utilisateur, enregistrer une nouvelle clé, accéder à du contenu lisible par le serveur ou perturber la récupération.

Examinez les protections proposées, notamment :

• La gestion sécurisée des mots de passe
• La limitation du nombre de tentatives
• La révocation des sessions
• Une gestion claire des appareils et des sessions
• La protection contre le rejeu d’identifiants d’authentification
• Des procédures sûres de réinitialisation de mot de passe
• L’authentification multifacteur lorsque cela convient
• Les notifications de changements importants du compte

Distinguez aussi l’authentification du compte du chiffrement des messages.

La connexion prouve la possession d’un moyen d’authentification du compte. Elle ne prouve pas nécessairement que l’appareil possède la clé privée de chiffrement d’origine.

7. Comment fonctionne la récupération chiffrée ?

La récupération pose l’un des compromis les plus difficiles en messagerie privée.

Les utilisateurs souhaitent légitimement retrouver leur historique après avoir remplacé un appareil. Mais si le fournisseur peut restaurer silencieusement toutes les clés privées, il peut disposer de capacités de déchiffrement plus importantes que prévu.

Une récupération protégée peut chiffrer une sauvegarde sur l’appareil et exiger un secret de récupération, une clé d’accès ou l’approbation d’un appareil de confiance. Commencez par identifier le contenu de la sauvegarde : identité du compte, contacts et historique des messages sont des choses différentes.

Demandez :

• La sauvegarde est-elle chiffrée avant son envoi ?
• Le mot de passe du compte suffit-il à la restaurer ?
• Le fournisseur connaît-il le secret de récupération ?
• L’assistance peut-elle réinitialiser ce secret ?
• Que se passe-t-il s’il est perdu ?
• La restauration conserve-t-elle la même empreinte de clé publique ?
• Peut-on désactiver la récupération ?

Une réponse digne de confiance peut comporter une limite inconfortable : perdre à la fois la clé privée et le secret de récupération peut rendre l’ancien contenu chiffré irrécupérable.

Cette conséquence peut témoigner d’une véritable limite d’accès, plutôt que d’un défaut du produit.

8. Que se passe-t-il lorsque la connexion se coupe ?

Sécurité et fiabilité doivent fonctionner ensemble.

Les connexions mobiles disparaissent. Les navigateurs se mettent en veille. Les appareils changent de réseau. Une messagerie bien conçue devrait gérer ces interruptions sans dupliquer les messages, perdre leur ordre ou affaiblir le chiffrement.

Cherchez un modèle hors ligne et de synchronisation capable de :

1. Préparer localement une action sortante.
2. Lui attribuer un identifiant stable.
3. Réessayer de manière sûre après reconnexion.
4. Éviter les envois en double.
5. Prendre en compte la confirmation du serveur.
6. Récupérer les changements manqués pendant la déconnexion.

Demandez séparément comment l’application protège les données réseau et sa file d’attente locale. L’E2EE ne prouve pas automatiquement que cette file est chiffrée au repos.

Une nouvelle tentative réseau ne devrait pas exiger de remettre au service d’acheminement une copie en clair d’un message normalement chiffré de bout en bout.

9. Comment les envois et les objets stockés sont-ils autorisés ?

La sécurité des médias ne se limite pas au chiffrement.

Un service peut gérer des avatars, des pièces jointes, des fonds d’écran, des stories, des envois temporaires et des miniatures générées. Chaque objet exige une politique d’accès.

Vérifiez si l’application :

• Exige une authentification pour récupérer les médias privés
• Vérifie l’appartenance du compte demandeur à la conversation concernée
• Sépare les ressources publiques des objets de messages privés
• Nettoie les fichiers envoyés mais non rattachés
• Supprime les objets temporaires expirés
• Empêche les accès croisés entre comptes par le cache
• Utilise des identifiants imprévisibles sans confondre imprévisibilité et autorisation

Un fichier privé en clair ne doit pas devenir lisible simplement parce que quelqu’un devine son URL. Pour les objets chiffrés, examinez la distribution et la révocation des clés et des droits d’accès. Les recommandations d’OWASP sur les autorisations préconisent l’application cohérente des décisions d’accès, y compris aux ressources statiques. Un identifiant imprévisible ne constitue pas, à lui seul, une politique d’autorisation complète.

10. Les groupes sont-ils protégés différemment ?

Le chiffrement des groupes et les contrôles d’appartenance posent des questions différentes du chiffrement des conversations individuelles.

Les changements de membres, les appareils multiples, l’historique, les rôles d’administrateur, les invitations, les exclusions et la rotation des clés ajoutent des exigences de conception.

Certains services proposent l’E2EE pour les conversations individuelles et les groupes. D’autres le réservent aux échanges individuels et protègent les groupes avec TLS, un stockage soumis à authentification et des contrôles d’accès côté serveur.

Le second modèle peut offrir une sécurité réelle, mais son périmètre de confiance est différent.

Demandez si le serveur peut traiter le contenu des groupes et si la protection change lorsque :

• Un membre rejoint le groupe
• Un membre le quitte
• Un administrateur exclut quelqu’un
• Un message est modifié
• L’historique est synchronisé sur un nouvel appareil
• Un bot ou une intégration rejoint le groupe

Ne supposez jamais qu’un cadenas affiché dans un type de conversation s’applique automatiquement aux autres.

11. Quels réglages de confidentialité l’utilisateur possède-t-il ?

La confidentialité concerne aussi le contrôle des informations après leur arrivée au service.

Cherchez des fonctions pratiques comme :

• L’export des données du compte
• La suppression du compte
• La révocation des sessions
• L’effacement de l’historique local ou synchronisé
• La suppression des messages envoyés lorsque c’est autorisé
• La gestion des accusés de lecture
• Le contrôle de la visibilité du profil
• Le blocage des contacts indésirables
• La gestion des aperçus de notifications
• La désactivation ou la suppression des sauvegardes de clés

Le fournisseur devrait expliquer si la suppression retire uniquement votre copie, celle de tous les participants ou l’enregistrement sur le serveur.

Un destinataire peut déjà avoir téléchargé, copié, transféré ou photographié un message. Aucune fonction de suppression ne peut garantir son effacement sur tous les appareils.

12. Les affirmations de sécurité sont-elles précises et vérifiables ?

Une documentation de sécurité solide définit des limites.

Cherchez des déclarations précises sur :

• Les algorithmes et les tailles de clés
• Les opérations côté client et côté serveur
• Les types de conversations couverts par l’E2EE
• Le chiffrement des médias
• Les informations stockées
• L’authentification
• La récupération
• Les changements de clés
• Les contrôles d’accès
• Les limites connues
• La date de dernière mise à jour de la documentation

Prenez avec prudence les formules vagues :

• Chiffrement inviolable
• Confidentialité absolue
• Sécurité de qualité militaire
• Anonymat complet
• Zéro métadonnée
• Impossible à pirater
• Chiffrement à l’épreuve du futur

Aucun système de communication complexe ne devrait être évalué sur un slogan seulement.

Les audits indépendants, les documents techniques publics, les applications clientes reproductibles, les analyses professionnelles et les rapports de sécurité au périmètre clair peuvent renforcer la confiance. Ils n’apportent pas tous le même niveau de preuve, mais sont plus utiles que des superlatifs sans fondement.

Messagerie sécurisée : signes encourageants et signaux d’alerte

Signe encourageant	Signal d’alerte
Le fournisseur nomme les conversations E2EE	Toutes les fonctions sont simplement dites « chiffrées »
Le contrôle des clés privées est expliqué	La gestion des clés n’est jamais abordée
Les changements de clés sont visibles	Les clés peuvent changer silencieusement
Les limites de récupération sont documentées	L’assistance peut tout restaurer sans expliquer comment
Les catégories de métadonnées sont listées	Le fournisseur annonce « zéro métadonnée » sans définition
La protection des médias est décrite séparément	Seuls les messages texte sont mentionnés
Les groupes ont un périmètre de confiance défini	Les affirmations sur les discussions individuelles semblent englober les groupes
Les pages de sécurité décrivent la mise en œuvre actuelle	Le discours commercial contredit la documentation technique
Les limites sont explicites	Le service promet une protection absolue ou inviolable

Appliquer ces questions aux affirmations publiques de Livara

La page de sécurité de Livara fournit une documentation produit, pas une certification indépendante. Les limites actuellement décrites distinguent :

• Les messages directs : LVR1 utilise un accord de clés hybride P-256 et ML-KEM-768 et un chiffrement authentifié pour les contenus pris en charge.
• Les groupes privés compatibles : protection par clés d’expéditeur LGS1. Les membres et les rôles restent un périmètre distinct placé sous l’autorité du serveur. Les anciens groupes incompatibles ne devraient pas recevoir l’étiquette E2EE.
• Les canaux publics : contenu lisible par le serveur, sans E2EE.
• La récupération : les éléments d’identité sont chiffrés avant envoi ; leur restauration ne restaure pas l’historique des discussions.
• Les métadonnées et les appareils : les traces d’acheminement et les appareils compromis restent hors de la promesse de chiffrement du contenu.

Confrontez ces affirmations à votre version installée et au modèle de menace. Une spécification de protocole, un vecteur de test local, un audit d’une version précise et l’observation du service réel sont des formes de preuve différentes. Ne remplacez pas une preuve manquante par une supposition de sécurité parfaite ou de vulnérabilité démontrée.

Une liste de vérification en 60 secondes

Avant de créer un compte, vérifiez si vous pouvez répondre à chaque question :

• Quels types de conversations sont chiffrés de bout en bout ?
• Les images, vidéos, documents et messages vocaux sont-ils couverts ?
• Les clés privées sont-elles créées et conservées sur les appareils participants ?
• Les contacts peuvent-ils comparer les empreintes ou les numéros de sécurité ?
• Les changements de clés sont-ils visibles ?
• La politique de confidentialité identifie-t-elle les métadonnées stockées ?
• L’authentification du compte est-elle expliquée ?
• La récupération des clés est-elle distincte de la connexion ordinaire ?
• Les demandes de médias privés sont-elles authentifiées et autorisées ?
• Le chiffrement reste-t-il actif pendant la mise en attente hors ligne ?
• Les groupes et les canaux ont-ils un périmètre de sécurité précis ?
• Les limites sont-elles documentées sans promesses exagérées ?

Notez « inconnu » pour les réponses manquantes, pas automatiquement « sûr » ou « dangereux ». Un fournisseur n’a pas besoin d’utiliser la même architecture que tous ses concurrents.

Il doit néanmoins fournir des réponses assez précises pour que les utilisateurs comprennent à quoi ils accordent leur confiance.

Le choix le plus sûr dépend de votre modèle de menace

Aucune messagerie n’est automatiquement la meilleure pour toutes les personnes et toutes les situations.

Un groupe familial, une entreprise, un journaliste et sa source, une équipe de soins ou une communauté publique peuvent avoir besoin de combinaisons différentes de :

• Confidentialité
• Vérification d’identité
• Anonymat
• Administration de groupes
• Conservation des messages
• Conformité réglementaire
• Récupération
• Prise en charge de plusieurs appareils
• Code source ouvert
• Audit indépendant
• Facilité d’utilisation

Commencez par demander ce que vous protégez et contre qui.

Pour les échanges personnels ordinaires, les principaux risques peuvent être le vol de compte, un réseau non fiable, la perte d’un appareil ou une collecte excessive de données.

Pour les communications à risque plus élevé, il peut aussi falloir des identités vérifiées, des règles sur les messages éphémères, des appareils renforcés, des procédures opérationnelles strictes et une analyse indépendante de sécurité.

Le chiffrement ne répare pas un appareil compromis et n’empêche pas un destinataire de confiance de partager un message.

La confidentialité commence par des attentes justes

Une messagerie digne de confiance ne demande pas de croire que tous les risques ont disparu.

Elle explique :

• Ce qui est protégé
• Quels appareils détiennent les clés
• Ce que le serveur traite
• Quelles métadonnées subsistent
• Comment fonctionne la récupération
• Où commence et s’arrête l’E2EE
• Quelles protections ne sont pas encore mises en œuvre

Cette clarté permet des décisions éclairées.

Une documentation claire est nécessaire à l’évaluation, mais ne suffit pas à désigner l’application la plus sûre. La qualité de la mise en œuvre, les mises à jour rapides, les constats indépendants et les risques de votre usage réel comptent aussi. Le guide de l’EFF sur le choix des outils recommande également de partir des menaces et de considérer l’ouverture comme une possibilité d’examen plutôt qu’une garantie.

Pour passer à la pratique, faites un essai sans risque : vérifiez un contact, envoyez une pièce jointe d’exemple, examinez les appareils associés, le périmètre des sauvegardes et la capacité des deux participants à utiliser les réglages de manière fiable. Ne faites pas ces essais avec les informations confidentielles que vous cherchez à protéger.

Questions fréquentes

Qu’est-ce qui rend une messagerie sécurisée ?

Une messagerie sécurisée associe un transport réseau protégé, une authentification robuste, des contrôles d’accès rigoureux, une gestion sûre des clés, un traitement responsable des données et des limites de confidentialité clairement documentées. Pour le contenu privé des messages, l’E2EE apporte une protection supplémentaire importante.

Une messagerie chiffrée est-elle automatiquement privée ?

Non. Une application peut chiffrer le contenu tout en traitant des informations de compte, des horodatages, des membres, des accusés, des informations d’appareil ou d’autres métadonnées. La confidentialité dépend du chiffrement et de l’ensemble des pratiques du service.

Le chiffrement de bout en bout masque-t-il mes interlocuteurs ?

Pas nécessairement. L’E2EE protège avant tout les contenus pris en charge. Le service peut encore avoir besoin d’informations sur l’expéditeur, le destinataire, les membres, les horaires et l’acheminement pour livrer et synchroniser les conversations.

Le fournisseur peut-il récupérer des messages E2EE ?

Cela dépend de la conception des clés et des sauvegardes. Un fournisseur peut stocker un historique chiffré sans posséder la clé privée nécessaire à sa lecture. Un système de récupération peut ne restaurer cette clé que si l’utilisateur fournit un secret distinct.

Une messagerie sécurisée dans le navigateur est-elle sûre ?

Un navigateur peut effectuer un chiffrement robuste côté client. La sécurité dépend toutefois de la mise en œuvre de l’application, de l’intégrité du navigateur, de l’appareil, du stockage des clés, de la livraison du code par le serveur, des extensions et du système d’exploitation.

Les groupes sont-ils toujours chiffrés de bout en bout ?

Non. Certains services proposent l’E2EE pour les groupes, tandis que d’autres le réservent aux conversations individuelles. Consultez la documentation pour connaître le périmètre exact.

Que se passe-t-il si ma clé de chiffrement change ?

Le changement peut venir d’un nouvel appareil, d’une réinstallation, d’une réinitialisation de clé ou d’une récupération. Une messagerie sécurisée devrait le rendre visible et permettre aux contacts de vérifier la nouvelle empreinte.

L’E2EE suffit-il pour des communications très sensibles ?

L’E2EE protège le contenu entre les appareils pris en charge, mais ne protège pas un appareil infecté ou déverrouillé, ne garantit pas le comportement du destinataire et ne masque pas automatiquement les métadonnées. Les utilisateurs à risque élevé ont aussi besoin d’une sécurité robuste des appareils et de leurs pratiques.