Basées sur Matrix
Non pas une messagerie mais un protocole fédéré et ouvert sur lequel reposent des messageries comme Element, Tchap ou Citadel. Le chiffrement de bout en bout n’est qu’une option et le « homeserver » de chacun reste un tiers de confiance incontournable.
En un coup d'œil
• Chiffrement de bout en bout — 🟠 Partiel
• Authentification de bout en bout — ❌ Mauvais
• Sécurité de bout en bout — ❌ Mauvais
• Pas de substitution d'identité — ❌ Mauvais
• Client open source — ✅ Bon
• Multi-appareil de bout en bout — ❌ Mauvais
• Données personnelles minimales — ❌ Mauvais
• Pas de découverte d'utilisateurs ni de spam — ❌ Mauvais
• Chiffrement post-quantique — ❌ Mauvais
Matrix n’est pas une messagerie, mais un protocole : une spécification ouverte de communication fédérée, sur laquelle sont bâties plusieurs messageries, dont Elementarchivé (le client de référence), Tchaparchivé (déployée par l’administration française) ou Citadelarchivé. La spécification est publique, les principaux clients et plusieurs implémentations serveur sont open source, et l’architecture fédérée permet à chaque organisation d’opérer son propre serveur (« homeserver ») tout en restant connectée au reste du réseau : autant de propriétés vérifiables, qui vont dans le sens de la souveraineté que nous défendons par ailleurs.
Cette pluralité impose une règle de lecture : nous évaluons ici ce que le protocole garantit à travers l’ensemble de ses déploiements, autrement dit ce qu’un utilisateur peut tenir pour acquis quelle que soit la messagerie basée sur Matrix qu’il utilise. Notre réserve porte sur un point de conception fondamental : Matrix a d’abord été pensé comme un système de salons de discussion répliqués entre serveurs, où le chiffrement de bout en bout est arrivé ensuite, comme une extension (c’est aujourd’hui encore un module optionnelarchivé de la spécification). Matrix est lancé en septembre 2014 sans chiffrement de bout en bout ; ce chiffrement (Olm/Megolm) arrive en bêta fin 2016archivé ; et il ne devient activé par défaut pour les nouvelles conversations privées qu’en mai 2020archivé.
Cette histoire se lit encore dans l’architecture : le compte, les appareils et les clés d’un utilisateur restent ancrés à son homeserver, qui demeure un tiers de confiance ; et la fédération — la technologie permettant à des utilisateurs sur des serveurs différents de communiquer — telle que Matrix la réalise, réplique les données des salons sur les serveurs de tous les participants. Il en résulte un modèle où la sécurité effective d’une conversation dépend d’opérateurs que l’utilisateur n’a pas choisis.
Points notables
Séparation entre éditeur et opérateur
La plupart des applications présentées dans ce comparatif sont éditées et opérées par la même entité : l’éditeur du logiciel est également l’opérateur des serveurs de relais et d’annuaire. Sur ce point, Matrix fait exception, et l’application Element officielle peut être utilisée sur des serveurs opérés par des tiers, par exemple sur les serveurs de Tchap opérés par l’État français.
Comme nous le soulignons à propos de l’ouverture du code du serveur, si la sécurité garantie par l’application est réellement de bout en bout, alors le serveur ne joue pas de rôle dans la sécurité et l’opérateur des serveurs et leur localisation n’ont pas d’importance. Cependant, Matrix ne peut pas garantir une sécurité complète de bout en bout, et il est donc indispensable que l’opérateur des serveurs soit de confiance. Il faut ainsi faire confiance à la fois à l’éditeur de l’application et à l’opérateur des serveurs.
Cette dualité existe aussi pour Telegram avec de nombreuses applications non-officielles (dont certaines pour lesquelles il est difficile d’avoir un niveau de confiance élevé !), ou pour SimpleX qui propose d’héberger son propre serveur de relaisarchivé.
La fédération, et le nivellement par le bas
La fédération, qui permet de créer un réseau regroupant plusieurs serveurs, est l’argument central de Matrix, et elle est à double tranchant. La promesse de souveraineté est réelle : choisir son serveur, c’est choisir qui héberge son compte, sous quelle juridiction. Nous souscrivons à cet objectif. Mais la fédération à la manière de Matrix a un revers, que l’on peut résumer ainsi : dans un système fédéré et interopérable, la sécurité effective tend à s’aligner sur le maillon le plus faible.
Ce nivellement par le bas opère à trois niveaux.
- Au niveau du protocole d’abord : pour que des serveurs et des clients hétérogènes interopèrent, les garanties fortes ne peuvent être qu’optionnelles ; le chiffrement n’est pas imposé, le cross-signing non plus, et chaque déploiement choisit son niveau d’exigence.
- Au niveau du salon ensuite : les données d’un salon étant répliquées sur les homeservers de tous les participants, il suffit d’un seul membre inscrit sur un serveur mal administré, ou malveillant, pour que l’historique des événements et les métadonnées du salon y soient durablement stockés ; chacun choisit son serveur, mais personne ne choisit les serveurs des autres.
- Au niveau des usages enfin : les passerelles vers des systèmes non chiffrés, encouragées par la culture d’interopérabilité de l’écosystème, réintroduisent silencieusement des points de déchiffrement.
Le problème n’est pas de fédérer, il est de fédérer des serveurs qui jouent un rôle dans la sécurité. Quand le serveur détient le compte, déclare les appareils et conserve l’historique, chaque serveur ajouté au système est un tiers de confiance ajouté, et la fédération multiplie les points de défaillance au lieu de les supprimer. C’est l’inverse d’une architecture où les serveurs, réduits au rôle de relais sans aucune fonction de sécurité, peuvent se multiplier sans que la sécurité en dépende : dans ce second modèle, fédérer n’affaiblit rien, car il n’y a rien chez le serveur à affaiblir.
Chiffrement de bout en bout 🟠 Partiel
Matrix dispose d’un chiffrement de bout en bout (Olm/Megolm, dérivé du Double Ratchet de Signal), et les principaux clients l’activent par défaut pour les conversations privées. Mais il n’est pas systématique au sens de notre critère : le protocole ne l’impose pas, les salons publics ne sont pas chiffrés, l’activation dépend du client et de la configuration du serveur, et une messagerie basée sur Matrix peut parfaitement ne pas le proposer. S’y ajoutent les passerelles (« bridgesarchivé ») vers d’autres systèmes (IRC, Slack, etc.), très utilisées dans l’écosystème : un salon ponté de cette façon est déchiffré par la passerelle, par construction. Le chiffrement existe donc, mais son périmètre réel varie d’un déploiement à l’autre.
Authentification de bout en bout ❌ Mauvais
L’identité d’un utilisateur Matrix est son compte (@utilisateur:serveur), détenu par son homeserver, qui distribue aux autres la liste de ses appareils et de leurs clés. Une vérification manuelle existe (comparaison d’une courte séquence d’émojis, un protocole de type SAS), ainsi qu’un mécanisme de cross-signing qui permet de valider tous les appareils d’un utilisateur en une fois. Si la vérification de ses propres appareils est en passe de devenir obligatoirearchivé dans l’écosystème, celle du correspondant reste optionnelle, et rien n’empêche de converser sans l’avoir jamais effectuée. On retrouve le modèle de l’annuaire, décliné en version fédérée : la confiance repose sur le homeserver du correspondant, qui distribue sa clé d’identité.
Sécurité de bout en bout ❌ Mauvais
Chiffrement non systématique, authentification déléguée au serveur : aucune des deux composantes n’atteint le niveau requis.
Pas de substitution d'identité ❌ Mauvais
Le compte Matrix se récupère comme n’importe quel compte en ligne, par mot de passe ou réinitialisation par email, selon la politique du homeserver. Les clés de cross-signing peuvent être réinitialisées, et les correspondants voient alors leurs vérifications antérieures invalidéesarchivé, avec une alerte qu’il suffit d’ignorer. L’identité est le compte, pas la clé : tout ce que décrit le critère s’applique, l’autorité sur le compte étant simplement déplacée du numéro de téléphone vers le homeserver et l’email de récupération.
Client open source ✅ Bon
La spécification du protocole est publique, les clients principaux sont open source (Element, le client de référence, est publié sous AGPLv3archivé), et plusieurs implémentations serveur le sont égalementarchivé. La cryptographie a par ailleurs fait l’objet d’audits indépendantsarchivé.
Multi-appareil de bout en bout ❌ Mauvais
Le protocole prévoit un mécanisme efficace (le cross-signing : une clé de certification unique signe tous les appareils de l’utilisateur), mais ne l’a longtemps pas imposéarchivé : selon le client et sa configuration, la vérification pouvait ne pas être activée, et le homeserver redevenait alors, de fait, l’autorité déclarant quels appareils appartiennent à l’utilisateur, avec le risque d’ajout d’appareil fantôme décrit dans le critère. L’écosystème est en train de corriger ce point : à la suite d’une évolution de la spécification annoncée fin 2025, Element rendra la vérification des appareils obligatoirearchivé : les appareils non vérifiés ne pourront plus ni envoyer ni lire de messages chiffrés, à une date qui n’est pas encore fixée (l’échéance initiale d’avril 2026 a été repoussée). En septembre 2026, cette garantie n’est donc ni effective, ni imposée à l’ensemble des déploiements ; il s’agira de réexaminer ce critère quand elle le sera.
Données personnelles minimales ❌ Mauvais
L’inscription dépend du homeserver, et les déploiements réels exigent le plus souvent un email (c’est le principe même de Tchap, réservée aux adresses professionnelles de l’administrationarchivé). Mais le véritable problème est que le homeserver conserve un historique complet des événements des salons de ses utilisateurs, et cet historique est répliqué chez les homeservers de tous les participantsarchivé. Les métadonnées (qui est membre de quel salon, qui a écrit quand) sont ainsi non seulement collectées, mais disséminées.
Pas de découverte d'utilisateurs ni de spam ❌ Mauvais
Les utilisateurs sont découvrables via l’annuaire de leur serveur et la fédération, et n’importe qui peut inviter n’importe qui dans un salon. Le contenu des messages n’est généralement remis qu’après acceptation de l’invitation, mais la sollicitation a déjà eu lieu, et elle transporte du texte librement choisi par son émetteur : le sujet du salon s’affiche chez le destinataire avant toute acceptation. Le spam d’invitations est un phénomène documentéarchivé sur les serveurs publics.
Chiffrement post-quantique ❌ Mauvais
Aucun chiffrement post-quantique : Olm et Megolm reposent sur une cryptographie classique. L’intégration de PQXDH dans vodozemac, la bibliothèque cryptographique de référence, a été entamée en 2024, mais l’équipe de Matrix indiquait encore en 2025 que ce chantier n’était pas prioritairearchivé.