Les messageries privées

Vous souvenez-vous de Caramail ou bien plus encore de MSN Messenger ? Ça, c'est pour les très anciens, les vieux de la vieille 🙂

Tellement ancien, que les jeunes aujourd'hui ne connaissent pas ces noms... Mais toutes les messageries actuelles (en commençant par les plus connues : WhatsApp & Co) sont des descendantes de ces messageries instantanées.

Les messageries ont une sacrée histoire ; d'abord implémentées sous UNIX puis DOS (avec la commande NET SEND), elles connaissent une première avancée grâce au Minitel (eh oui encore lui !), avec une application appelée Gretel qui permettait de communiquer de pair à pair. Puis IRC a été créé et standardisé vers la fin des années 80. Cela dit, celles-ci n'étaient pas encore tout à fait des messageries dites 'instantanées', car très peu de notions d'authentification ou de détection de présence...

Une première explosion des messageries instantanées a lieu vers la fin des années 90 lorsque AOL promeut ICQ, puis Yahoo son propre outil Yahoo! Messenger et enfin MSN avec MSN Messenger en 1999 (avec l'histoire qu'on lui connaît, racheté par Microsoft puis transition vers Skype, etc.).

En parallèle, un autre service a fait parler de lui : le SMS, dont les débuts sont, à priori, situés en 1992. Ce n'est pas à l'origine à proprement parler un concurrent, car le SMS avait été créé initialement pour que les FAI puissent simplement communiquer avec leurs clients et uniquement ça. Rien ne le prédestinait à autre chose... Mais au vu de la simplicité d'utilisation, l'interopérabilité de la technologie et parce que l'infrastructure téléphonique des opérateurs était déjà bien déployée le SMS a finalement percé à l'époque pour devenir ce que l'on connaît aujourd'hui (le SMS utilisant le réseau GSM, les messageries... le réseau internet qui, à l'époque, n'était pas aussi répandu qu'aujourd'hui et encore moins sur téléphone mobile !).

L'explosion d'internet vers le milieu des années 2000 aura vu poindre de nouveaux outils de messagerie bien plus performants : la naissance, par exemple, de Jabber/XMPP en 2004/2005 et surtout celle d'une messagerie bien connue aujourd'hui, WhatsApp, en 2009. Avec l'avènement des ordiphones et de l'utilisation intensive du réseau internet, rien ne pouvait résister à la mort lente des SMS ; même si de nos jours les organismes tentent de leur donner un second souffle avec des nouveaux standards (MMS ou RCS par exemple), il est vraisemblable que celui-ci soit amené à disparaître petit à petit...

Mais nous sommes là dans la spéculation ! Revenons-en à nos moutons : les messageries.

La collecte des données

Dans notre voyage, afin de regagner un peu de contrôle sur nos données et donc renforcer notre vie privée, il est essentiel de savoir quelle est l'étendue du désastre sur la collecte des données personnelles nous concernant.

Voici un aperçu simple de 5 messageries-type en ce qui concerne la collecte de vos données personnelles :

Premier constat : la majorité des messageries les plus connues aujourd'hui sont détenues par les GAFAM ou leur code source est propriétaire ou privateur. Ce qu'il faut retenir de l'infographie ci-dessus est :

• Sachant leur politique de collecte de données (qui semble être la même partout sur toutes les messageries propriétaires), nous devrions être plus attentifs.
• Sachant également que, bien qu'ils nous assurent que les données collectées ne le sont pas à des fins commerciales ou sont bien protégées, nous n'avons aucun moyen de savoir si tout cela est véridique car le code source est fermé, et les agissements de ces entreprises sont bien entendu opaques.

Cela comprend exhaustivement :

➡️ ❌ Whatsapp
➡️ ❌ Meta/Facebook Messenger
➡️ ❌ Instagram
➡️ ❌ Snapchat
➡️ ❌ Google avec tous leurs outils de messagerie : Gmail, Hangouts, Messages, Chat, Duo, Google+...
➡️ ❌ Amazon WickrMe
➡️ ❌ Microsoft Skype (Service arrếté en 2025)
➡️ ❌ Zoom
➡️ ❌ Cisco Webex
➡️ ❌ Microsoft Teams
➡️ ❌ Apple iMessages
➡️ ❌ Yahoo messagerie
➡️ ❌ Discord
➡️ ❌ Twitter
➡️ ❌ Slack
➡️ ❌ WeChat
➡️ ❌ Viber
➡️ ❌ Line
➡️ ❌ Bip
➡️ ❌ Les potentielles messageries de votre/vos FAI : Orange, Bouygues, SFR, Free et autres MVNO.
➡️ ❌ Toute autre messagerie à sources fermées.

Si vous avez néanmoins besoin de plus d'informations pour vous en convaincre, voyez par vous-même : Apple et iCloud, plus récemment WhatsApp et son ultimatum, ou encore la "modération" sur WhatsApp, ou les remords du co-fondateur de WhatsApp qui nous permettent de tirer un bilan noir.

Il est également intéressant de voir que le FBI a créé un document qui liste les données qu'il peut extraire (légalement bien sûr 😉 !) de la plupart des messageries sur le marché :

Nous retrouvons toutes les messageries mentionnées ci-dessus, tout en notant que Signal est la messagerie au travers de laquelle il est le plus difficile d'obtenir des informations... Nous y reviendrons !

État des lieux du marché

Maintenant que nous avons une idée de l'étendue des dégâts, passons aux choix qui se présentent à nous. Vous avez sûrement tous entrevu ces infographies, faisant état de la majorité des messageries actuellement disponibles comparées aux messageries propriétaires :

Deuxième constat : il est difficile de savoir quelle application utiliser dans cette jungle des messageries, simplement en visualisant des infographies... En effet, ces outils sont en plein essor, notamment du côté des solutions à sources ouvertes. Le marché n'est pas encore consolidé et nous avons aujourd'hui la possibilité d'utiliser des outils basés sur des mécanismes assez complexes et comprendre, surtout, lorsque les aspects de "chiffrement" ne sont pas les mêmes partout !

Sur la figure suivante sont schématisés les 5 "statuts logiciel" des messageries actuelles que vous pourrez retrouver sur le marché.

Quelques explications : cette infographie classe les messageries selon deux axes souvent confondus :

1. Le statut du logiciel (client et serveur libres ou non),
2. L’architecture réseau (centralisée, fédérée, décentralisée, pair-à-pair) que nous définirons juste après.

1. Client + serveur non libres, centralisation

C'est le cas typique des solutions propriétaires que nous avons énoncées plus haut : on ne peut ni vérifier le code, ni auditer précisément ce qui se fait côté serveur. Le service est opaque par nature.

Le fournisseur de cette application contrôle l’infrastructure et le logiciel. Les métadonnées sont généralement très riches (qui parle avec qui, quand, combien, depuis où, fréquence...) et vous êtes totalement verrouillé sur leur réseau.

2. Client libre, serveur non libre, centralisation (ex. Telegram)

Le client est auditable, mais le cœur du système (les serveurs) reste opaque.

Ici la confiance reste concentrée sur l'opérateur de l'application, les parties les plus critiques (le routage, le stockage, modération, la journalisation, etc.) ne sont pas vérifiables.

La centralisation des échanges passe par l'infrastructure du fournisseur de service, et même si le client est bon, les serveurs restent les mêmes derrière et peuvent collecter et corréler beaucoup de métadonnées (ici l'exemple des clients Telegram).

3. Client + serveur libres, centralisation (ex. Signal, Wire)

Ici, le code est publiquement auditable mais l’architecture reste centralisée.

La transparence technique permet un meilleur audit et une opacité plus faible, du moins sur les logiciels (il faudrait également s'assurer que ce sont ces logiciels audités qui tournent bien sur les serveurs ; mais ici, c'est rarement vérifiable).

La confiance est donc toujours concentrée sur un acteur, celui qui relaie vos communications. Même si le risque "boite noire" diminue, la centralisation conserve ses points d'achoppement et ses inconvénients (pannes, blocages, pressions légales, corrélation de métadonnées).

4. Client + serveur libres, fédération (ex. Matrix/Element, XMPP)

Ici l'idée est simple : nous pouvons choisir où héberger notre serveur, et les serveurs se parlent entre eux, c'est ce qu'on appelle la fédération.

La confiance est "distribuée" et nous réduisons ainsi la dépendance à un fournisseur unique. L'interopérabilité est possible, c'est un avantage majeur, mais en contrepartie, cela augmente d'autant la complexité et la façon de sécuriser les échanges.

Quant aux métadonnées, elles peuvent être réparties entre plusieurs serveurs afin de réduire ce côté "centralisation" ; l'inconvénient est qu'elles peuvent être plus nombreuses si des ponts sont créés, ce qui multiplie les points d'observation.

5. Client libre, pair-à-pair (ex. Briar, Tox, Jami selon modes)

Ici, les appareils communiquent directement (ou via des relais limités selon la technologie) : il n'y a pas d'intermédiaire, pas de fournisseur central. Cela réduit drastiquement le verrouillage à un fournisseur de services et par extension certains risques structurels.

Nous décrivons ce principe plus loin.

La sécurité des messageries

Nous ne pouvons pas, bien entendu, comparer des messageries sans discuter de la sécurité des échanges : c'est un peu un passage obligé pour pouvoir décider quel outil vous allez utiliser. Nous allons tenter de faire ça simplement.

Le piège classique est ici encore de mélanger les choses, notamment deux sujets bien distincts :

1. L’architecture (centralisée, fédérée, pair-à-pair, etc.) que nous avons traitée juste avant,
2. Le modèle de chiffrement (qui peut lire le contenu ?) que nous traitons dans cette section.

Pour rester simple, il y a 2 mécanismes de protection à connaître.

Chiffrement client–serveur

Aussi appelé "chiffrement en transit". Dans ce modèle, le service chiffre la connexion jusqu'au serveur (comme HTTPS pour un site web), comme suit :

• Le client négocie et établit un canal chiffré vers le serveur
• Vous envoyez le message à travers ce canal chiffré
• Le serveur peut déchiffrer le contenu
• Puis le serveur envoie le message au destinataire, bien souvent heureusement, via un autre canal chiffré.

Conséquence directe : le serveur est en position de lire le contenu des messages, même s’il promet de ne pas le faire ! Ici l'on se rend bien compte du problème, en terme de respect de la vie privée :

• Si le serveur est compromis,
• Si le fournisseur du service conserve des journaux,
• Si une obligation légale impose une interception ou une remise de données.

Ce modèle protège surtout contre les attaques "réseau" (Wi-Fi public, FAI, etc.), mais il ne protège pas contre le fournisseur du service lui-même (directement ou indirectement).

Chiffrement de bout en bout

Dans un chiffrement de bout en bout (ou E2EE), le message est chiffré sur l’appareil de l’émetteur et ne peut être déchiffré que sur l’appareil du destinataire. Le serveur (qu’il existe ou non) n’est alors censé voir que des données chiffrées.

Point important : "bout en bout" ne veut pas dire sans serveur !

La plupart des messageries E2EE utilisent quand même des serveurs pour :

• Acheminer les messages,
• Stocker temporairement des messages quand quelqu’un est hors-ligne,
• Gérer des fonctionnalités (groupes, recherche, pièces jointes, etc.).

La vraie différence dans ce modèle réside donc sur ce point précis : qui possède la capacité technique de déchiffrer le contenu ?

Le vrai nerf de la guerre : les clés

Chiffrer, c’est gérer des clés cryptographiques (ou clés de sécurité, jetez un coup d’œil à l'article sur le chiffrement pour bien comprendre l'aspect des clés de sécurité). Ici, nous devons distinguer plusieurs choses :

• Qui génère les clés ?
• Où sont-elles stockées ?
• Qui peut y accéder ?

Dans un E2EE bien conçu, les clés "privées" qui permettent de déchiffrer restent sur les machines qui les ont générées. Le serveur ne devrait pas pouvoir les stocker ou gérer (sinon ce n’est plus du bout en bout, ou alors c’est du faux-E2EE, "fragilisé" par un mécanisme de récupération). En pratique cela donne :

• Messageries centralisées (Signal, etc.) : le routage est centralisé, mais les clés de déchiffrement sont censées rester sur les appareils. La confiance se déplace : elle repose moins sur la confidentialité du contenu et plus sur la solidité du protocole utilisé, la gestion des identités et la surface d'attaque des serveurs.
• Messageries fédérées / décentralisées / pair-à-pair : les clés restent aussi côté appareils, mais l’architecture peut réduire certains points de défaillances uniques et parfois, selon l'architecture réduire la corrélation de métadonnées. Cela ne rend pas tout "ultra sécurité de la mort qui tue" 😄 automatiquement : cela change surtout où la confiance se concentre.

Enfin, certains modèles (surtout pair-à-pair) peuvent exiger une présence simultanée ou imposer des contraintes de disponibilité. C’est parfois un avantage (moins de stockage tiers, plus de confidentialité) mais bien souvent une contrainte à l'usage (surtout quotidien).

Pour plus de détails sur les définitions, rendez vous sur le glossaire.

Ce qu’il faut retenir (pour la suite)

• Architecture : dit où passent les messages et qui contrôle l’infrastructure.
• Chiffrement : dit qui peut lire le contenu.

Donc une messagerie peut être :

• centralisée + E2EE (contenu protégé, mais métadonnées et points uniques de défaillances restent importants),
• fédérée mais sans E2EE par défaut (interopérable mais contenu potentiellement exposé selon les paramètres utilisés),
• pair-à-pair (moins d’opérateur mais contraintes pratiques à l'usage).

Simple ! 😄
Faites une pause, vous l'avez bien mérité...

Analyse des forces en présence

Passons maintenant au concret.

CENTRALISE : Signal

La messagerie, vue comme la "plus sécurisée", est la plus connue à ce jour dans ce genre d'outil de communication, en tout cas au sein de M. et Mme Toutlemonde.

Petit point sur les controverses...

Signal, tout comme beaucoup d'applications aujourd'hui, fait l'objet de beaucoup de théories et de fantasmes. La plus répandue étant celle qui lie Signal à l'agence bien connue à 3 lettres des USA. Voici en gros l'argumentaire répandu par certains :

Entre 2013 et 2016, les développeurs ont reçu 3M de dollars du fond Open Technology Fund (OTF). L'OTF était à l'origine un programme de Radio Free Asia sous la coupe de l'US Agency Global Media (USAGM). L'USAGM est "une organisation indépendante" du gouvernement US en charge de promouvoir les intérêts américains à l'international et serait directement financée et gérée par le gouvernement US. Par ricochet, l'USAGM/Radio Free Asia étant gérés par le gouvernement US, qui ont financé l'OTF, qui a financé le développement de l'application Signal, la CIA aurait donc créé Signal !

Tentons d'y voir plus clair : l'USAGM (et tous ses projets dont OTF et Radio Free Asia...) promeut effectivement les intérêts US (en utilisant des capacités disruptives ou déstabilisantes), surtout dans des pays où les gouvernements ont des liens très complexes avec les gouvernements US... Donc, en plus de soutenir des médias indépendants dans ces pays, cela implique également le soutien du gouvernement US à des outils capables de contourner la censure et permettre à des personnes de résister à des régimes pointés comme autoritaires.

De plus, le soutien financier de l'OTF à divers projets est du domaine public.

Bien évidemment du fait de la facilité d'obtenir cette information et de vouloir faire sensation, le buzz, quelques journaux ont publié des articles concernant la messagerie, remplis de sous entendus ; ce qui, de fait, a contribué à créer cette théorie. Maintenant, examinons les faits :

• Signal est open-source ¹ (y compris leur protocole de chiffrement, dérivation de clés, gestion de la confidentialité permanente, PFS etc.), ce qui implique que le code est auditable à n'importe quel moment par des experts ou développeurs (n'oublions pas que cette messagerie est très connue)

¹ ⚠️ C'est confirmé depuis fin 2021 (fil lemmy), et après de nombreuses demandes des développeurs et utilisateurs, Signal confirme qu'il ferme une petite partie de son code source, côté serveur : il s'agit d'un "composant serveur séparé, dédié à la détection et la perturbation des campagnes de spam/abus". ⚠️
Le reste du code source, notamment relatif au protocole reste quant à lui bien sûr open-source.

• Même si la justification est a priori recevable pour la majorité des libristes, cela constitue donc un relatif danger pour certains utilisateurs... Car en terme de surveillance de masse, il est plus simple et plus intéressant pour les institutions d'utiliser des outils à code source fermé (ex. : le scandale des backdoors sur les routeurs Cisco qui n'est qu'un exemple).
• Nous ne sommes pas en train de dire que c'est le cas pour Signal, mais de préciser qu'à priori personne ne pourra le prouver puisqu'une partie du code est fermé !
• Cela dit, il est aussi bien plus simple d'installer un petit spyware sur des téléphones (cf. le scandale PRISM, ou encore ce scandale au Canada), donc relativisons !
• Une multitude de projets open source sont financés par des entités similaires. L'OTF a par exemple financé beaucoup d'autres projets dont nous discutons dans tous nos articles : Tor Project, K9-Mail, F-Droid, Certbot, et même Tails OS. Et bien d'autres projets open source sont financés en partie par des agences ou des organismes qui peuvent avoir quelques liens avec des gouvernements ; d'ailleurs, les messageries mentionnées dans notre article peuvent avoir reçu des fonds de gouvernements : par exemple, Element aux UK et Session en Australie....

Il nous semble évident que ceci est un débat sans fin... Il est toujours intéressant et très utile d'avoir un regard critique et de se poser des questions sur les financements, mais nous ne devrions pas, de notre point de vue, établir des raccourcis simplistes simplement car ils correspondent à des croyances. Signal a été financé par d'autres entités et mécènes : récemment le co-fondateur de WhatsApp a octroyé 50M$ en prêt à 0% aux développeurs de Signal, devenant également CEO de la Signal Foundation !

... Revenons sur terre

Signal est donc cette messagerie dite "sécurisée" dont ses développeurs ont créé leur propre protocole de communication, repris d'ailleurs par beaucoup d'autres messageries (WhatsApp par exemple), suite à l'ouverture des sources de ce protocole. Protocole audité en profondeur dès 2016 puis pratiquement chaque année depuis, qui aujourd'hui confirme sa robustesse à une bonne partie des attaques. Les développeurs sont d'ailleurs très réactifs lorsqu'il s'agit de corriger certaines failles de sécurité. C'est un projet très bien maintenu et très bien géré.

Néanmoins, comme évoqué plus haut, tout n'est pas si rose : En dehors du fait qu'une partie du code source côté serveur est maintenant fermé, voici les points techniques sujets à débat :

DECENTRALISE

Ici nous avons 2 types d'outils, aux objectifs différents :

• Element/Matrix met l'accent sur le côté temps-réel et interopérabilité, et constitue plus un réseau social qu'une messagerie (à l'instar de Telegram).
• Simple X et Session quant à eux restent concentrés sur la sécurisation des échanges de bout en bout et un certain niveau ce confidentialité.

Bien que ces solutions se reposent sur la décentralisation (à un certain niveau cela dit) et implémentent le chiffrement de bout en bout, il y a donc bien une grande différence entre les 2 types de messageries, qui ne seront pas destinées aux mêmes usages...

Element

Element est basé sur le protocole et le réseau Matrix. Ce réseau est un réseau fédéré et est surtout axé sur l'interopérabilité : c'est-à-dire la capacité de recevoir des communications d'autres messageries (WhatsApp, Telegram, Signal...) et d'autres protocoles de communication, via ce qu'ils appellent des "ponts". C'est la grande force de Matrix, même si cela vient avec des inconvénients, vous vous en doutez...

Côté sécurisation des échanges, Matrix permet le chiffrement de bout en bout et utilise les mêmes méthodes de chiffrement que Signal (le côté centralisation en moins) ; ce n'est pas l'objectif prioritaire de Matrix car il n'impose pas le chiffrement par défaut, ce qui peut rebuter certains, et nous le comprenons.

D'ailleurs certaines applications qui utilisent Matrix ne fournissent pas de chiffrement, par exemple : Nio ou Fractal, mais Element et ElementX l'implémentent et l'imposent.

Néanmoins, quelques cas de figure problématiques peuvent apparaître dans son utilisation :

Ressources d'intérêts :

• Audit de sécurité : Audit indépendant du protocole Matrix en 2016 et statuant sur des capacités correctes dans la sécurisation, si correction des divers bugs remontés (je vous rassure, depuis les divers bugs de sécurité sont corrigés !).

Session

Session est, quant à lui, un fork de Signal. La différence fondamentale est que, plutôt que de proposer une centralisation, Session propose de passer par un réseau décentralisé appelé Lokinet/Oxen (un équivalent de Tor) qui est implémenté sur une blockchain.

Alors rassurez-vous tout ceci est transparent pour les utilisateurs, et vous n'aurez pas non plus à acheter des cryptomonnaies 😄

L'idée derrière l'utilisation de ce réseau est d'apporter une confidentialité et un niveau d'anonymat accrus :

Ressources d'intérêts :

• Audit de sécurité : Audit de sécurité effectué en 2021 et concluant "The overall security level of this application is good and makes it usable for privacy-concerned people", ce qui donne en français : "le niveau de sécurité global de l'application est bon et le rend utilisable pour les personnes ayant un intérêt pour leur vie privée.
• Papier Blanc

SimpleX

SimpleX vise un objectif très proche de Session sur un point clé : réduire au maximum les métadonnées exploitables (communicants, identifiant, etc.). Mais il le fait avec une approche différente : SimpleX ne repose pas sur un annuaire d’utilisateurs, ni sur des comptes, ni même sur des identifiants (que ce soit numéro, e-mail, pseudo, clé publique, etc.).

L'idée est simple : pas d’ID utilisateur = pas de "graphe social" facile à reconstruire.

A l’inverse : vous obtenez l’équivalent d’une "adresse de réception", différente pour chaque contact, et ces "adresses" ne servent qu’au transport des messages, pas à vous identifier.

SimpleX implémente bien-sûr un chiffrement de bout en bout (type “Double Ratchet” comme Signal). L’idée, ici, n’est pas seulement de "chiffrer le contenu" mais aussi d'éviter de fabriquer des métadonnées inutiles comme des ID, annuaire, domaine... qui simplifient l’enquête ou la surveillance généralisée.

Comme toujours, il faut rester lucide : SimpleX ne rend pas "anonyme par magie" (nous ne le répéterons jamais assez). Si vous vous connectez directement aux serveurs relais, votre IP reste visible par le serveur que vous utilisez (cela dit, c’est vrai pour pratiquement toutes les messageries). La différence est que SimpleX est conçu pour que ce serveur ne puisse pas facilement relier vos conversations entre elles via un identifiant. Et si votre modèle de menace l’exige, SimpleX peut être utilisé derrière un réseau adapté comme notre ami Tor, ce qui permet de traiter le problème de l’IP.

PAIR-A-PAIR

Avant d’en venir aux outils, il nous semble essentiel de clarifier le vocabulaire, car souvent le modèle "pair-à-pair" (P2P) est mal compris.

Une communication de type pair-à-pair (P2P) cherche à réduire la dépendance à une infrastructure centrale : les appareils des utilisateurs participent activement à l’acheminement et/ou au stockage des échanges. Selon les applications, cela peut aller du direct (directement d'appareil à appareil) à des modèles où les pairs répliquent des messages et les resynchronisent plus tard, ou encore où certains services secondaires existent pour contourner les contraintes du réseau (proxy par exemple).

L'application Briar

Briar est une application open-source, développée par Briar Project, un ensemble de développeurs, hackers et activistes, principalement en Europe. L'application propose bien entendu des échanges P2P, mais l'objectif de Briar est également de permettre des communications si internet tombe : il est donc possible d'échanger directement avec des contacts via Wifi ou Bluetooth, votre interlocuteur devra en revanche être proche de vous. Briar permet également de créer un réseau à part entre différents utilisateurs de l'application, de sorte à acheminer les messages en passant par des contacts comme point de relais.

Son utilisation reste identique en mode chat ou groupe, à ceci près que chaque participant devra être en ligne. Cependant, il est important de bien comprendre son fonctionnement intrinsèque afin de cerner ses objectifs : oui Briar apporte une sécurité très importante dans les échanges, est très résistant à la collecte des métadonnées, mais en revanche Briar ne fournit pas d'anonymat ou en tout cas pas à un niveau très important : nous vous conseillons de bien lire ce que les développeurs ont ajouté sur leur wiki, notamment sur cette question d'anonymat (adresse Bluetooth, IP, etc.).

Toujours lire les manuels d'utilisation, les documentations ou les FAQ 😀 !

Ressources d'intérêts

• Audit de sécurité : Briar a fait l'objet d'un audit en 2017, puis plus récemment en 2023, et toutes les remarques remontées ont toutes été adressées à ce jour.

Les messageries non évoquées

Les controversées

Certains vont se demander pourquoi certaines messageries connues n'apparaissent pas ici. Voici les raisons :

• Threema : application suisse, très prisée dans le monde germanophone. Cette messagerie est payante et une partie de son code source n'est pas ouvert (côté serveur). Il est donc évident que nous ne recommanderons pas cette solution.
• Wire : également suisse, Wire a été créée par le fondateur de Skype. L'application est totalement open-source, et utilise les méthodes de chiffrement de Signal. Néanmoins, Wire a un modèle qui ne colle pas avec la philosophie du Libre, la société s'adressant plus particulièrement au monde professionnel qu'au grand public et donc possédant un modèle économique attirant les convoitises. Ici encore, nous ne recommandons pas forcément cette messagerie.

Le cas délicat d'Olvid

Oui nous ne recommandons pas, à ce jour, l'application française Olvid... Beaucoup ici trouveront cette idée farfelue, mais voici nos raisons :

• Bien que certifiée ANSSI et ayant fait l'objet d'un second audit de sécurité (2020), cette application n'est pas totalement à code source ouvert : seul le protocole de chiffrement et les clients Android/iOS le sont, l'objectif étant de faciliter les audits et bug bounty afin de perfectionner les algorithmes (qui ont été créés de zéro). Mais la partie serveur est à sources fermées ce qui empêche des experts indépendants de réellement les auditer.
• Les serveurs montés par les créateurs d'Olvid sont tous hébergés hors Europe (chez Amazon AWS), ce qui laisse songeur sur leur côté éthique et soumission aux règles américaines. Finalement un peu comme Signal, le côté éthique en un peu plus discutable.
• De plus, Olvid considère que l'adresse IP est plus une donnée technique qu'une donnée personnelle, ce qui dès lors devrait nous mettre la puce à l'oreille...

Les autres projets

D'autres solutions de messageries, moins connues ou plus récentes existent. Nous faisons état ci-dessous de quelques-unes qui méritent de s'y intéresser, bien que pour certaines trop "jeunes" pour être utilisées au quotidien. Cela doit rester à la discrétion des utilisateurs et de choisir de faire confiance ou non à ces outils :

• Jami : projet ambitieux et très intéressant, sur une architecture pair-à-pair décentralisée, intéressante pour l’autonomie. Mais les contreparties en terme de fiabilité (inhérent au réseau et aux mécanismes de connectivité) peuvent être un frein
• Molly : un fork de Signal, qui réduit encore les métadonnées
• Cwtch : un équivalent de Briar, et solution très intéressante, à regarder de près
• Berty : équivalent de Element, en cours d'audit

XMPP-Jabber

Eh oui, pour les fans de XMPP, nous n'avons pas encore parlé de ce beau protocole qui reste toute de même une valeur sûre dans l'éco-système des messageries. Les applications que nous recommandons :

• Conversations
• Snikket

A suivre

Plus confidentielles et pour des profils aux besoins d'anonymat et de sécurité avancés :

• Delta Chat une messagerie via e-mail
• Speek transit des échanges via Tor
  ▶️ Attention : le projet semble être à l'arrêt ; dernière version v1.7.0 au 31 juillet 2022.

Nous pouvons mentionner également :

• TinFoil Chat qui nécessite tout de même une infrastructure pour une utilisation complète (séparation de l'émetteur et du récepteur, etc.).
  ▶️ Pour des profils plutôt initiés ou à l'aise avec l'outil numérique.

Nos recommandations

Pour vous faciliter la prise de décision, nous vous présentons la liste des messageries que nous recommandons, discutés dans les précédents chapitres, suivant les usages que vous souhaitez en faire, qui sont :

• Pour un modèle de tous les jours, famille, connaissance - un whatsapp-like :

Signal Messenger: Speak Freely

Say “hello” to a different messaging experience. An unexpected focus on privacy, combined with all of the features you expect.

Signal Messenger

• Pour une messagerie basé sur Matrix, communautaire et décentralisée :

Element | Collaboration et messagerie sécurisées

Element est une application de messagerie chiffrée de bout en bout et de collaboration sécurisée basée sur Matrix. Il est décentralisé pour l’auto-hébergement numérique souverain ou via un service d’hébergement tel que Element Matrix Services. Element fonctionne sur le réseau Matrix ouvert pour assurer l’interopérabilité et faciliter les connexions.

HM Government logo

• Pour un modèle plus strict, volontairement confidentiel :

SimpleX Chat: private and secure messenger without any user IDs (not even random)

SimpleX Chat - a private and encrypted messenger without any user IDs (not even random ones)! Make a private connection via link / QR code to send messages and make calls.

logo

• Pour un modèle de défense des communications, ou l'utilisation stricte du P2P (aucun intermédiaire) :

Secure messaging, anywhere - Briar

Secure messaging, anywhere

Briar