Chiffrement on Arpokrat

Comparatif des messageries chiffrées 2026 : le chiffrement ne suffit plus

Thu, 10 Sep 2026 00:00:00 +0000

Ouvrez WhatsApp, Telegram, Signal, Messenger, Google Messages. Toutes ces applications affichent aujourd’hui la même promesse quelque part dans leur interface : chiffrement de bout en bout. La formule est devenue un argument commercial standard, au même titre que « sans engagement » chez un opérateur mobile. Elle ne départage plus rien, précisément parce qu’elle est devenue vraie presque partout.

Et pourtant ces applications ne se ressemblent en rien. L’une exige votre numéro de téléphone et remet à la justice la liste des personnes qui vous ont dans leur répertoire. L’autre ne sait littéralement rien de vous, pas même qu’un compte existe. Entre les deux, une quinzaine de projets font des arbitrages très différents, et aucun ne les explique clairement sur sa page d’accueil.

Le chiffrement de bout en bout signifie que le contenu de vos messages est illisible pour l’intermédiaire qui les transporte. C’est un acquis important, et il serait absurde de le minimiser. Mais il ne dit rien de ce que ce même intermédiaire apprend en dehors du contenu : que vous avez écrit, à qui, à quelle heure, depuis quelle adresse IP, à quelle fréquence, dans quels groupes, avec quel numéro de téléphone attaché à votre identité civile.

Le chiffrement protège ce que vous dites. Il ne protège pas le fait que vous l’ayez dit, ni à qui, ni quand, ni depuis où.

Cet article n’établit pas de classement. Il n’existe pas de meilleure messagerie dans l’absolu, parce qu’il n’existe pas d’adversaire générique. Ce que propose ce dossier, c’est d’abord une grille de sept critères qui permet de juger n’importe quelle application, y compris celles qui n’existent pas encore, puis une fiche honnête pour chacune des quatorze applications retenues, et enfin des recommandations selon le profil de menace. Chaque fiche comporte une rubrique consacrée à ce que l’application ne protège pas, sans exception, y compris la nôtre.

Sommaire

Les sept critères qui remplacent le chiffrement

Cette section est la plus importante de l’article. Si vous n’en lisez qu’une, lisez celle-ci : elle vous permettra de juger vous-même n’importe quelle messagerie, y compris celles qui sortiront après la publication de ce texte.

Le chiffrement de bout en bout, un acquis qui ne départage plus

Le protocole Signal, publié en 2013 et formellement analysé par des chercheurs en cryptographie depuis, est devenu le standard de facto. WhatsApp l’utilise depuis 2016, Google Messages l’utilise, Messenger l’utilise. Le débat cryptographique est largement clos pour le contenu des conversations un contre un.

Les questions qui restent utiles ne portent plus sur la présence du chiffrement mais sur ses modalités. Est-il activé par défaut ou faut-il le demander ? Couvre-t-il les groupes ou seulement les échanges à deux ? Couvre-t-il les sauvegardes, ou celles-ci partent-elles en clair chez Google et Apple ? Existe-t-il une confidentialité persistante, c’est-à-dire une rotation régulière des clés qui garantit que la compromission d’une clé aujourd’hui ne donne pas accès aux messages d’hier ?

Ces questions départagent encore. La présence du mot « chiffré » sur une page marketing, non.

Les métadonnées, ce que le service sait sans lire vos messages

En mai 2014, lors d’un débat public à l’université Johns Hopkins face au juriste David Cole, l’ancien directeur de la NSA et de la CIA Michael Hayden a prononcé une phrase devenue célèbre. Cole venait de citer l’ancien conseiller juridique de la NSA Stewart Baker, selon qui « les métadonnées vous disent absolument tout de la vie de quelqu’un, et si vous en avez assez, vous n’avez pas vraiment besoin du contenu ». Hayden a répondu, en approuvant : « Nous tuons des gens sur la base de métadonnées. » Il a aussitôt ajouté que ce n’était pas ce que faisaient les programmes de collecte domestique américains, précision qu’il faut restituer pour être honnête. Elle ne change rien à l’essentiel : le plus haut responsable du renseignement américain a confirmé publiquement que les métadonnées suffisent à des décisions létales.

Une métadonnée, dans une messagerie, c’est tout ce qui n’est pas le contenu : qui écrit à qui, à quelle heure, depuis quelle adresse IP, avec quelle fréquence, dans quels groupes, avec quelle taille de fichier. Reconstituer un lien entre un journaliste et une source ne demande pas de lire leurs échanges. Il suffit de constater qu’ils ont commencé à s’écrire trois jours avant la publication d’une enquête. Le même raisonnement vaut pour un avocat et son client, un médecin et son patient, un salarié et un syndicat, deux personnes qui n’ont pas envie que leur relation soit connue.

Un service peut donc être irréprochable sur le chiffrement du contenu et parfaitement transparent sur le reste. C’est même la situation la plus courante. Nous avons détaillé ailleurs comment ce même raisonnement s’applique à d’autres signaux passifs du quotidien, notamment dans notre article sur la géolocalisation permanente du téléphone et dans notre analyse du système SignalTrace de Leonardo, qui reconstitue des trajets et des relations à partir des seuls identifiants Bluetooth captés au passage.

Bonne question à poser à n’importe quel éditeur : que reste-t-il sur vos serveurs si un juge vous les saisit demain matin ?

L’identifiant exigé, un numéro, une adresse ou rien

C’est le critère le plus concret et le plus sous-estimé. Trois modèles coexistent.

Le numéro de téléphone. Dans la plupart des pays, il est rattaché à une pièce d’identité. Il est unique, durable, et il est déjà présent dans le répertoire de centaines de personnes. Exiger un numéro, c’est lier chaque compte à une identité civile et rendre triviale la découverte du graphe social : il suffit de comparer les répertoires. Le numéro est aussi le point faible bien connu de l’authentification, comme nous l’avons montré dans notre article sur le 2FA par SMS : un SIM swap réussi ne vole pas seulement un code, il vole une identité de messagerie.

L’adresse e-mail ou un identifiant aléatoire. Meilleur, parce qu’une adresse jetable coûte quelques secondes et qu’un identifiant aléatoire ne dit rien. Il reste cependant un identifiant durable côté serveur, donc un point d’accroche pour corréler des sessions dans le temps.

Aucun identifiant. C’est le modèle le plus récent et le plus rare. Il n’y a pas de compte du tout, pas d’annuaire, pas d’adresse permanente. Vous existez comme un jeu de clés cryptographiques sur votre appareil, et l’on vous joint par un lien d’invitation à usage unique. Rien à saisir, rien à fuiter, rien à corréler.

Open source et audit indépendant, deux notions à cesser de confondre

Ce sont deux choses différentes et il faut arrêter de les présenter ensemble.

Open source signifie que le code est lisible. C’est une condition nécessaire de la confiance, pas une preuve de sécurité. Personne ne lit le code, sauf accident. Des failles graves ont survécu des années dans des projets libres très regardés.

Audit indépendant signifie qu’un tiers payé pour chercher des failles en a cherché, et a publié ce qu’il a trouvé. C’est infiniment plus fort, et c’est infiniment plus rare, parce que cela coûte cher.

Il faut ensuite distinguer deux natures d’audit. Une revue de conception cryptographique examine si le protocole est bien pensé sur le papier. Un audit d’implémentation examine si le code fait bien ce que le protocole prétend. Les deux sont utiles, ils ne prouvent pas la même chose, et un projet peut avoir le premier sans le second.

Le cas de Threema illustre parfaitement l’intérêt de la démarche. En 2022, trois chercheurs de l’ETH Zurich ont trouvé sept attaques contre son protocole, sur trois modèles de menace différents, et les ont communiquées à l’éditeur. Threema a répondu par un nouveau protocole, Ibex, publié fin novembre 2022. Une application fermée et non auditée n’aurait jamais connu cet épisode, ce qui n’aurait pas voulu dire qu’elle était plus sûre.

La juridiction et le CLOUD Act

Le lieu d’établissement d’une entreprise détermine quels gouvernements peuvent la contraindre. C’est un critère juridique, pas technique, et il est décisif.

Le CLOUD Act, voté aux États-Unis en 2018, tranche une question posée par l’affaire Microsoft Ireland : une entreprise américaine peut-elle refuser de livrer des courriels stockés sur un serveur irlandais ? La réponse du législateur est non. Le texte impose aux fournisseurs sous juridiction américaine de communiquer les données qu’ils contrôlent, indépendamment du lieu de stockage. Un serveur à Francfort exploité par une société américaine reste atteignable par une réquisition américaine. Le fournisseur peut objecter si la demande entre en conflit avec le droit étranger, mais l’objection est une procédure, pas un bouclier.

La conséquence pratique est simple : héberger en Europe ne suffit pas si l’hébergeur, la société mère ou la holding relèvent du droit américain. La question à poser n’est pas « où sont vos serveurs » mais « qui peut légalement vous obliger, et sur quelle base ».

Il faut ajouter deux nuances. D’abord, une juridiction protectrice ne sert à rien si le service détient malgré tout des données exploitables : la meilleure défense reste de ne rien avoir à livrer. Ensuite, une juridiction hostile ne condamne pas un service qui, structurellement, ne sait rien. Signal est américain et n’a jamais pu livrer autre chose que deux horodatages.

La pérennité du projet, le critère que personne ne regarde

Une messagerie très bien conçue qui disparaît dans dix-huit mois vous laisse avec un carnet d’adresses inutilisable et, souvent, un historique perdu. Ce critère n’apparaît jamais dans les comparatifs. L’année 2026 l’a rendu incontournable.

En avril 2026, la Session Technology Foundation a annoncé publiquement qu’elle n’avait réuni qu’environ 65 000 dollars de dons, qu’elle avait besoin d’à peu près un million de dollars par an pour fonctionner, et que sa trésorerie ne tiendrait pas au-delà de juillet. Tous les salariés ont été remerciés et le développement s’est arrêté. Session compte plus d’un million d’utilisateurs actifs mensuels. En juin, la fondation a annoncé que le projet était sauvé par des dons de milliers d’utilisateurs, pour la plupart de petits montants, et qu’il repartait avec une équipe de trois développeurs conduite par l’architecte logiciel Jason Rhinelander.

Trois semaines plus tard, le 9 juillet 2026, le projet Briar publiait un message comparable : après avoir envisagé l’arrêt, il passe en mode maintenance, c’est-à-dire correctifs de sécurité et de bugs uniquement, sans développement de nouvelles fonctionnalités, faute de financement pérenne.

Deux projets emblématiques, deux modèles économiques différents, la même année, la même impasse. La question à se poser avant d’adopter une messagerie est donc devenue : qui paie, combien, et pendant combien de temps ? Une fondation qui vit de dons, une entreprise qui vend des licences, un projet universitaire subventionné et un logiciel communautaire bénévole n’ont pas la même espérance de vie, et cela n’a rien à voir avec la qualité de leur cryptographie.

Le côté pratique, un critère de sécurité à part entière

Ce dernier critère est souvent traité avec mépris par les puristes. C’est une erreur.

Une messagerie que vos interlocuteurs refusent d’installer ne protège personne, parce que la conversation aura lieu ailleurs, en clair. Une messagerie dont les notifications n’arrivent pas pousse ses utilisateurs à revenir sur WhatsApp pour les échanges urgents. Une messagerie qui exige que les deux personnes soient connectées au même instant ne convient pas à une correspondance ordinaire entre deux fuseaux horaires.

La sécurité réelle d’un système est celle de son usage réel, pas celle de sa fiche technique. Un modèle un peu moins pur que vos contacts utilisent effectivement protège davantage qu’un modèle parfait que vous êtes seul à utiliser.

Les messageries grand public

WhatsApp est la messagerie la plus utilisée au monde. Elle appartient à Meta, elle est gratuite, et son modèle économique repose sur l’écosystème publicitaire du groupe et sur les services aux entreprises.

Ce qu’elle protège réellement. Le contenu des messages, avec le protocole Signal, depuis 2016. Cette implémentation est sérieuse et il faut le dire clairement : le contenu de vos conversations WhatsApp n’est pas lisible par Meta. Les sauvegardes chiffrées de bout en bout existent et méritent d’être activées, car elles ne le sont pas par défaut. L’application est extrêmement fiable, disponible partout, et vos contacts l’ont déjà.

Ce qu’elle ne protège pas. Tout le reste. Sur réquisition simple, Meta communique les données d’abonné : nom du compte, date de création, dernière connexion, adresse IP, adresse e-mail. Sur mandat de perquisition, l’entreprise fournit le carnet d’adresses de la personne visée, et aussi la liste des autres utilisateurs de WhatsApp qui ont cette personne dans leur répertoire. Autrement dit, le graphe social est livrable dans les deux sens. Les métadonnées conservées incluent les horodatages, les identifiants d’expéditeur et de destinataire, les statuts de remise, la composition des groupes et ses modifications. Selon un document du FBI rendu public, WhatsApp est capable de produire certaines métadonnées d’un utilisateur ciblé toutes les quinze minutes dans le cadre d’une surveillance en temps réel. Enfin, le numéro de téléphone est obligatoire, et Meta relève du CLOUD Act.

Pour qui elle est faite. Pour tout le monde, en tant que canal de communication ordinaire dont on accepte que le graphe relationnel soit connu de Meta et communicable à une autorité judiciaire.

Telegram est souvent rangée parmi les messageries sécurisées. C’est un malentendu qu’il faut lever sans agressivité, parce que Telegram est excellente dans ce qu’elle fait vraiment.

Ce qu’elle protège réellement. Rien de plus qu’un service en ligne classique, pour l’usage courant. Les conversations ordinaires, appelées chats cloud, sont chiffrées entre le client et le serveur, puis stockées chiffrées côté Telegram, qui détient les moyens de les lire. Le chiffrement de bout en bout n’est disponible que dans les chats secrets, qui ne sont pas activés par défaut, sont limités aux échanges un contre un, restent liés à l’appareil d’origine et ne se synchronisent pas. Ce que Telegram fait excellemment, en revanche, c’est le groupe massif, la chaîne de diffusion, le partage de fichiers volumineux et la présence multi-appareils. C’est un formidable réseau de publication, et c’est ainsi qu’il faut le juger.

Ce qu’elle ne protège pas. Le contenu des conversations ordinaires face à l’éditeur, le numéro de téléphone, l’adresse IP. La position de l’entreprise a changé en septembre 2024, après l’arrestation de Pavel Durov en France : Telegram communique désormais les numéros et adresses IP des utilisateurs signalés, en réponse à des demandes légales valides, alors que l’engagement précédent limitait ces transmissions aux affaires de terrorisme. Les chiffres publiés pour 2024 traduisent le changement d’échelle : environ 900 demandes satisfaites aux États-Unis pour 2 253 utilisateurs, 14 641 en Inde pour 23 535 utilisateurs, 142 au Royaume-Uni. Le groupe est par ailleurs immatriculé aux Îles Vierges britanniques et dirigé depuis Dubaï, une structure dont l’opacité est en elle-même une donnée d’analyse.

Pour qui elle est faite. Pour la diffusion publique, les communautés larges, la veille. Pas pour une conversation qui doit rester confidentielle face à l’éditeur.

Le standard de fait

Signal

Signal est la référence, et cet article la traite comme telle. Elle est éditée par la Signal Foundation, une organisation à but non lucratif américaine financée par des dons et par une dotation initiale de Brian Acton.

Ce qu’elle protège réellement. Le contenu, avec le protocole qu’elle a inventé et qui sert de référence à l’industrie. Mais surtout, et c’est ce qui la distingue, le reste : découverte de contacts confidentielle, expéditeur scellé, minimisation systématique des données conservées. La preuve n’est pas déclarative, elle est judiciaire. Signal publie ses réponses aux réquisitions sur une page dédiée, et ces réponses se ressemblent toutes : l’organisation ne peut fournir que l’horodatage de création du compte et la date de dernière connexion. Dans une affaire portée devant le tribunal du District de Columbia, la justice a demandé les informations d’abonné pour trente-sept numéros de téléphone. La réponse a été la même. C’est le seul historique public de résistance aux réquisitions de cette qualité dans tout ce comparatif, et il vaut davantage que n’importe quelle promesse marketing.

Ce qu’elle ne protège pas. Le numéro de téléphone reste obligatoire à l’inscription en 2026. Les noms d’utilisateur, introduits en 2024, permettent de ne plus communiquer son numéro à ses contacts, ce qui est un vrai progrès, mais ils ne suppriment pas l’exigence à la création du compte. Des travaux publics indiquent que Signal étudie une inscription sans numéro, possiblement adossée à un paiement unique pour limiter les abus, mais au moment d’écrire ces lignes elle n’est pas disponible. Signal relève par ailleurs du droit américain, donc du CLOUD Act : la protection ne vient pas de la juridiction, elle vient du fait qu’il n’y a rien à livrer. Enfin, l’infrastructure est centralisée et l’écosystème est fermé aux clients tiers, point sur lequel nous revenons plus loin.

Pour qui elle est faite. Pour à peu près tout le monde. C’est le meilleur rapport entre protection et adoption réelle sur le marché, et c’est la recommandation par défaut quand le numéro de téléphone n’est pas un problème dans votre modèle de menace.

Molly

Molly est un fork durci de Signal pour Android. Il ne change ni le protocole, ni le réseau, ni le modèle d’identifiant : il durcit le client.

Ce qu’il protège réellement. Ce que Signal ne protège pas côté appareil. Molly chiffre la base de données locale derrière une phrase secrète, ce qui verrouille l’application entière, et efface la mémoire vive avec des données aléatoires au verrouillage, pour résister à une analyse forensique après saisie. Il permet aussi de router le trafic à travers un proxy SOCKS ou Tor. Une variante Molly-FOSS supprime les composants propriétaires de Google. Autant de choses que le client officiel ne fait pas.

Ce qu’il ne protège pas. Tout ce qui relève du serveur. Molly utilise les serveurs de Signal, exige donc un numéro de téléphone et hérite exactement du même profil de métadonnées et de la même juridiction. Il n’existe que sur Android. Et il fonctionne sur le réseau de Signal avec la tolérance de la fondation, pas avec son autorisation formelle, ce qui est resté sans incident depuis des années.

Pour qui il est fait. Pour un utilisateur de Signal sous Android dont le modèle de menace inclut la saisie physique du téléphone : journaliste en déplacement, militant, avocat qui passe une frontière.

Les messageries sans numéro de téléphone

Session

Session a fait un pari radical : supprimer le numéro et l’e-mail. À l’inscription, l’application génère un identifiant de compte aléatoire, et rien d’autre n’est demandé. Le projet est porté par la Session Technology Foundation, une fondation de droit suisse.

Ce qu’elle protège réellement. L’identité à l’inscription, et l’adresse IP. Les messages transitent par un réseau décentralisé de nœuds en routage en oignon, de sorte qu’aucun serveur ne connaît à la fois l’origine et la destination. Le code des clients Android, iOS et desktop a fait l’objet d’un audit publié par la société française Quarkslab, qui a relevé sept problèmes sur Android, sept sur iOS et deux sur le client desktop, pour la plupart corrigés depuis. L’application est disponible sur toutes les plateformes et ressemble à une messagerie ordinaire, ce qui n’est pas rien dans cette catégorie.

Ce qu’elle ne protège pas. Session a retiré la confidentialité persistante en 2021, en invoquant des problèmes de stabilité avec son architecture décentralisée. Concrètement, la compromission d’une clé longue durée expose les messages passés. La fondation a annoncé en décembre 2025 un protocole V2 réintroduisant la confidentialité persistante et ajoutant un échange de clés post-quantique fondé sur ML-KEM, mais ce protocole n’était pas finalisé au moment d’écrire. Et surtout, le critère de pérennité pèse lourd ici : le projet est passé à quelques semaines de l’arrêt en 2026 et fonctionne désormais avec trois développeurs pour plus d’un million d’utilisateurs.

Pour qui elle est faite. Pour qui veut se passer de numéro de téléphone sans changer ses habitudes d’usage, et qui accepte l’absence actuelle de confidentialité persistante.

Threema

Threema est une entreprise suisse qui vend son application. C’est le seul acteur payant de ce comparatif, et c’est précisément ce qui rend son modèle lisible.

Ce qu’elle protège réellement. L’identité et la juridiction. À l’installation, l’application génère un Threema ID aléatoire. Le numéro de téléphone et l’adresse e-mail sont facultatifs et ne servent qu’à être retrouvé par ses contacts, ce que rien n’oblige à activer. Les serveurs appartiennent à l’entreprise et se trouvent dans un centre de données certifié ISO 27001 à Zurich, sous le droit suisse, hors CLOUD Act. Le code source est publié et les compilations reproductibles sont disponibles sur Android, ce qui permet de vérifier que l’application distribuée correspond au code. Threema a fait auditer ses applications mobiles par Cure53 en octobre 2020, puis son application de bureau en janvier 2024. Le protocole Ibex, adopté fin 2022, a fait l’objet d’une preuve de sécurité formelle publiée par des chercheurs allemands en 2023.

Ce qu’elle ne protège pas. Le prix, environ six euros en achat unique, est un obstacle réel à l’adoption par vos proches, et c’est le principal frein pratique. L’épisode ETH Zurich de 2022 rappelle par ailleurs que même un acteur sérieux peut avoir un protocole vulnérable pendant des années : sept attaques trouvées, un protocole entièrement refait. Enfin, l’identifiant Threema reste un identifiant durable côté serveur, ce qui n’est pas le modèle sans identifiant du tout.

Pour qui elle est faite. Pour une entreprise européenne, un cabinet, une administration, ou un particulier qui préfère payer un produit plutôt que dépendre de dons, et qui veut une juridiction suisse claire.

Wire

Wire a beaucoup changé de nature. Née comme messagerie grand public, elle s’est repositionnée sur les organisations, les entreprises et le secteur public.

Ce qu’elle protège réellement. Le contenu, avec le protocole Proteus puis avec MLS, le standard de messagerie de groupe de l’IETF dont Wire a été un des premiers implémenteurs sérieux. L’inscription se fait par e-mail, ce qui évite le numéro de téléphone. Les audits sont publics : Kudelski Security et X41 D-Sec ont publié une revue de l’implémentation du protocole en 2017, puis des audits applicatifs des clients iOS, Android et web en 2018.

Ce qu’elle ne protège pas. Les métadonnées, que Wire conserve en clair côté serveur, un point que l’éditeur n’a jamais dissimulé et qui a été régulièrement critiqué. La structure juridique est également complexe : les opérations relèvent de Wire Swiss GmbH en Suisse, la holding du groupe est établie à Berlin et l’éditeur affirme que plus de 90 % du capital est détenu par des investisseurs institutionnels européens, mais une entité américaine a été créée dans le Delaware en 2019. Cette complexité mérite d’être comprise avant de retenir Wire pour un usage sensible.

Pour qui elle est faite. Pour une organisation qui a besoin de collaboration chiffrée conforme, avec un support commercial et une administration centralisée, plus que pour un individu recherchant l’anonymat.

Element et le protocole Matrix

Element est le client principal de Matrix, un protocole ouvert et fédéré. Le modèle est différent de tous les autres de ce comparatif : n’importe qui peut héberger son propre serveur, et les serveurs communiquent entre eux comme le font les serveurs de courrier électronique.

Ce qu’il protège réellement. L’autonomie. Une organisation peut héberger son serveur, contrôler son infrastructure, ne dépendre d’aucun éditeur et rester joignable depuis le reste du réseau. C’est le seul modèle de ce comparatif qui offre cette combinaison, et c’est la raison pour laquelle plusieurs administrations européennes l’ont retenu. Le chiffrement de bout en bout des messages est en place.

Ce qu’il ne protège pas. Les métadonnées, et c’est structurel. L’administrateur de votre serveur voit qui parle à qui, quand, et dans quels salons. Les métadonnées de salon, nom, sujet et autres événements d’état, sont stockées en clair sur le serveur. Element travaille sur le chiffrement de ces événements d’état, mais la fonctionnalité était encore expérimentale et réservée aux options de laboratoire en septembre 2025. La fédération aggrave le problème : l’historique d’un salon est répliqué chez les serveurs participants, qui le conservent. L’éditeur commercialise d’ailleurs une passerelle destinée à filtrer la fédération pour limiter ces fuites, ce qui est un aveu utile.

Pour qui il est fait. Pour une organisation qui veut la souveraineté sur son infrastructure et dont l’adversaire n’est pas son propre administrateur système. Pas pour un individu qui cherche à dissimuler ses relations.

Les messageries sans aucun identifiant

C’est la catégorie la plus récente. Le principe n’est pas de cacher un identifiant mais de ne pas en créer.

SimpleX Chat

SimpleX Chat est le premier réseau de messagerie sans identifiant d’utilisateur, y compris aléatoire. C’est une avancée conceptuelle réelle et il faut la présenter comme telle.

Ce qu’il protège réellement. Le graphe social, par construction. Il n’y a pas de compte, pas d’annuaire, pas d’adresse permanente. Chaque conversation repose sur des files d’attente unidirectionnelles hébergées sur des relais différents : ce que vous envoyez passe par une file sur un relais, les réponses reviennent par une autre file sur un autre relais, de sorte qu’aucun relais ne voit les deux extrémités. Les relais sont aveugles, ils ne connaissent ni le déposant ni le destinataire. Le projet a publié deux audits indépendants réalisés par Trail of Bits : une évaluation de sécurité de l’implémentation en novembre 2022, puis une revue de la conception cryptographique des protocoles en octobre 2024, incluant une vérification formelle du protocole de négociation des files et concluant à trois problèmes de gravité moyenne et un de gravité faible, tous d’exploitation difficile. Le protocole ajoute une couche post-quantique au double cliquet. Les relais sont auto-hébergeables, les clients existent sur Android, iOS et bureau, et l’éditeur, SimpleX Chat Ltd, est une société britannique immatriculée depuis octobre 2021.

Ce qu’il ne protège pas. Deux choses méritent d’être dites. D’abord l’hébergement par défaut : les relais opérés par le projet tournent chez un seul fournisseur, Linode, filiale de l’américain Akamai, dans ses centres européens de Londres, Francfort et Stockholm. Un utilisateur qui n’active pas Tor et ne change pas de relais dépend donc d’une infrastructure exploitée par une société américaine, ce qui replace le CLOUD Act dans le tableau. Le sujet est documenté publiquement dans le dépôt du projet. Ensuite, l’expérience utilisateur reste exigeante : établir une connexion demande un échange de lien ou de QR code, la fiabilité des notifications sur iOS a longtemps été un point faible et le passage à l’échelle des grands groupes est encore un chantier. Le financement, enfin, repose désormais sur un financement participatif en capital lancé en août 2026.

Pour qui il est fait. Pour qui veut le modèle sans identifiant avec le meilleur niveau de vérification externe disponible aujourd’hui, et qui accepte une prise en main plus technique.

Arpokrat Messenger

Arpokrat Messenger est notre produit, et cette fiche suit la même grille que les autres. Il faut commencer par le dire sans détour : Arpokrat Messenger est un fork de SimpleX. L’architecture décrite ci-dessus, absence d’identifiants, files unidirectionnelles, relais aveugles, n’est pas la nôtre, c’est celle de SimpleX. Nous ne prétendons pas l’avoir améliorée sur le plan cryptographique, nous la créditons, exactement comme notre page protocole le fait explicitement. C’est la même position que nous tenons pour ArpokratOS vis-à-vis de GrapheneOS.

Ce qu’il protège réellement. Ce que protège SimpleX, plus une série de choix d’exploitation et de produit. Les relais que nous opérons sont répartis dans cinq juridictions choisies pour leur droit, la Suisse, l’Islande, le Panama, la Malaisie et Maurice, aucune américaine, et l’infrastructure ne repose sur aucun hyperscaler américain, ni Amazon Web Services, ni Google Cloud, ni Microsoft Azure, ni Cloudflare. Les messages en attente ne vivent qu’en mémoire vive, le swap est désactivé, une coupure de courant efface tout, et les manifestes de publication sont signés sur une machine Qubes OS isolée du réseau. Tor s’active d’un seul bouton, sans application tierce, et reste désactivé par défaut. Le mode incognito attribue un profil différent par contact, nom d’affichage et relais compris, ce qui empêche de relier une vie professionnelle et une vie privée. Les relais sont auto-hébergeables par n’importe qui, le logiciel étant ouvert. Les clients sont publiés sous licence AGPLv3. Le portefeuille non custodial gère Bitcoin, Ethereum, Monero, Polygon, Solana et Tron, les clés ne quittant jamais l’appareil, et la prise en charge de Zcash est annoncée sans être disponible à ce jour. Le Swap intégré est un agrégateur qui compare les offres de fournisseurs indépendants en notant chacun de A à D selon le niveau de vérification d’identité exigé, de A pour aucun KYC à D pour KYC obligatoire, les fonds transitant directement entre l’utilisateur et le fournisseur choisi. À notre connaissance, aucune autre messagerie ne propose cette notation. L’éditeur est enfin une entité commerciale identifiable, Arpokrat GmbH, domiciliée à Zoug en Suisse, avec une adresse postale publique, un warrant canary signé en PGP, renouvelé selon une fenêtre de validité de soixante jours, et un engagement de réponse au support sous 24 heures. L’application est gratuite, sans publicité.

Ce qu’il ne protège pas. Et c’est ici qu’il faut être précis, parce que c’est le seul moyen d’être crédible sur le reste.

Arpokrat Messenger ne dispose à ce jour d’aucun audit cryptographique indépendant publié à son nom. SimpleX en a deux. Le protocole sous-jacent est donc audité, notre implémentation et notre exploitation ne le sont pas, et ce n’est pas la même chose, comme expliqué plus haut dans cet article.

Arpokrat n’a aucun historique public de résistance à des réquisitions judiciaires. Signal en a un, vérifiable, étalé sur des années. Un warrant canary est un engagement sérieux, ce n’est pas un précédent judiciaire.

L’application n’existe aujourd’hui que sur Android. Les versions iOS, Linux, macOS et Windows sont annoncées, pas disponibles. Pour qui échange avec des utilisateurs d’iPhone, c’est un obstacle immédiat et il n’y a pas de contournement.

Le réseau est enfin jeune et petit. Le nombre d’utilisateurs ne fait pas la sécurité, mais il fait la disponibilité de vos correspondants, et c’est un critère légitime que nous avons nous-mêmes défendu plus haut.

Pour qui il est fait. Pour qui veut une architecture sans identifiant sans renoncer à l’usage courant, et qui préfère une entité commerciale identifiable à un projet communautaire dont le financement peut s’interrompre. Le positionnement que nous défendons n’est pas « la plus privée », il est plus étroit et plus honnête : la plus utilisable parmi les architectures sans identifiant, avec un modèle asynchrone que les architectures pair à pair n’offrent pas, un écosystème et un support commercial.

Briar

Briar est probablement le projet le plus intransigeant de cette liste. Il n’y a pas de serveur du tout : les messages passent directement d’un appareil à l’autre à travers Tor, et à défaut de connexion, par Wi-Fi ou Bluetooth entre appareils proches.

Ce qu’il protège réellement. Tout ce qui dépend d’une infrastructure, puisqu’il n’y en a pas. Rien à saisir, rien à réquisitionner, aucun opérateur à contraindre. Le mode maillé hors ligne fonctionne réellement en cas de coupure Internet, ce qui fait de Briar l’outil de référence pour les blackouts et les manifestations. Le code a été audité par Cure53 en mars 2017, avec douze problèmes relevés et corrigés. Le projet est libre et sa conception fait autorité. Briar Mailbox, une application distincte à installer sur un appareil Android d’appoint laissé allumé, permet de recevoir des messages pendant que le téléphone principal est hors ligne, ce qui répond partiellement à la principale limite du modèle pair à pair.

Ce qu’il ne protège pas. Le confort d’usage, et désormais la trajectoire du projet. La consommation de batterie est élevée, le fonctionnement en tâche de fond sous Android est irrégulier, la sauvegarde de compte et les pièces jointes manquent, et l’ajout de contact est laborieux. Il n’existe pas de version iOS. La version desktop reste en bêta, la dernière étant la 0.6.5-beta publiée le 20 février 2026. Et surtout, l’annonce du 9 juillet 2026 place le projet en mode maintenance : correctifs de sécurité et de bugs, sans développement de fonctionnalités. Le projet précise que les rumeurs d’arrêt complet sont dépassées, mais l’ambition est clairement suspendue.

Pour qui il est fait. Pour une zone de coupure Internet, une manifestation, un contexte de censure, ou un groupe réduit qui accepte la contrainte en échange de l’absence totale d’infrastructure.

Cwtch

Cwtch est développé par l’Open Privacy Research Society, une association à but non lucratif canadienne établie à Vancouver. Le projet vise explicitement la messagerie de groupe résistante aux métadonnées.

Ce qu’il protège réellement. Les métadonnées, y compris en groupe, ce qui est le problème difficile. Les connexions passent par des services onion Tor v3, et les serveurs qui relaient les conversations de groupe sont conçus pour être non fiables par principe : ils ne doivent rien apprendre. La version 1.13, publiée en septembre 2023, a marqué la sortie de la longue phase alpha et bêta, et le projet a poursuivi jusqu’à la 1.15.

Ce qu’il ne protège pas. La pérennité, encore une fois. L’organisation vit essentiellement de dons individuels et l’a répété publiquement à plusieurs reprises. Il n’existe pas de version iOS. Le rythme de développement est celui d’une petite équipe, et l’écosystème d’utilisateurs est très restreint. Nous n’avons pas trouvé d’audit externe publié équivalent à ceux de SimpleX ou de Briar.

Pour qui il est fait. Pour un groupe militant ou de recherche qui a besoin de conversations collectives résistantes aux métadonnées et dont les membres sont techniquement à l’aise.

La convergence de 2026, la messagerie devient un portefeuille

Voici l’observation la plus intéressante de cette année, et à notre connaissance personne ne l’a encore formulée ainsi.

En 2026, trois forks de trois protocoles différents, développés par trois équipes sans lien entre elles, ont eu la même intuition au même moment : intégrer un portefeuille non custodial dans une messagerie chiffrée. Radar est un fork de Signal avec du Bitcoin sur Lightning. Zerion est un dérivé de Briar avec Bitcoin et Monero. Arpokrat Messenger est un fork de SimpleX avec un portefeuille multi-chaînes et un agrégateur de swap.

Trois bases techniques opposées, une même conclusion. Ce n’est pas un hasard, c’est le signe que deux besoins qui étaient traités séparément se rejoignent. Envoyer de l’argent et envoyer un message posent le même problème : un intermédiaire qui connaît les deux extrémités. La réponse construite pour les messages, chiffrement du contenu et minimisation des métadonnées, est exactement celle que cherchent les utilisateurs de crypto-monnaies. Et la messagerie est le seul endroit où l’on connaît déjà son destinataire.

Les trois approches sont pourtant très différentes, et la comparaison est instructive.

Radar

Radar a été lancé le 7 juillet 2026 par l’équipe de Cake Wallet, sous une entité distincte, Radar Chat, Inc., dirigée par son fondateur Vikrant Sharma. C’est un fork de Signal, gratuit, open source, disponible sur iOS et Android. Le portefeuille est non custodial, avec une phrase de récupération de douze mots et des sauvegardes chiffrées. La couche de paiement mérite une précision, parce que les sources ne disent pas la même chose. Le site de Radar décrit un portefeuille Bitcoin adossé au réseau Lightning, attribue une adresse Lightning à chaque compte, et ne mentionne rien d’autre. Plusieurs articles parus en juillet 2026 indiquent en revanche que la mécanique sous-jacente repose sur Spark, un réseau Bitcoin de couche 2 intégré via le SDK Breez, un transfert entre deux utilisateurs de Radar se réglant alors de Spark à Spark en moins d’une seconde. Les deux versions ne s’excluent pas, puisque la documentation de Breez décrit un SDK qui prend en charge Spark et Lightning ensemble, adresses Lightning et factures bolt11 comprises. Faute de confirmation publique par l’éditeur lui-même, nous retenons ce qui est vérifiable sur son propre site : des paiements Bitcoin non custodial joignables par le réseau Lightning.

Le choix le plus marquant est ailleurs. Radar n’est pas un réseau séparé : on s’y connecte avec son compte Signal existant, et les contacts, conversations, groupes et nom d’utilisateur suivent. C’est l’avantage concurrentiel de Radar, et c’est aussi sa principale question ouverte.

Cette interopérabilité implique en effet que Radar hérite intégralement du modèle de Signal : le numéro de téléphone reste l’identifiant, le code PIN Signal commande la récupération du compte et donc, par défaut, l’accès aux clés du portefeuille que Radar chiffre dans le compte Signal, et l’infrastructure sollicitée est celle de la Signal Foundation, sous juridiction américaine.

Il faut ensuite poser la question de la pérennité de ce montage, sans l’affirmer comme un fait. Signal a historiquement refusé que des clients tiers utilisent ses serveurs : en 2016, le projet LibreSignal a été abandonné après que Moxie Marlinspike a fait savoir qu’il ne voulait ni que le nom ni que les serveurs de Signal soient utilisés par un fork, et il a par ailleurs exclu toute fédération future. La fondation garde la capacité technique de bloquer un client tiers par sa signature. À ce jour elle ne l’a pas fait, et Molly utilise le réseau depuis des années sans incident, précédent dont l’équipe de Radar se réclame explicitement. Radar verse par ailleurs une contribution mensuelle à la Signal Foundation et prévoit de l’augmenter avec sa croissance. Rien n’indique donc que Radar sera bloqué. Mais un produit dont l’accès au réseau dépend de la tolérance continue d’un tiers porte un risque structurel que ni SimpleX ni Briar ne portent, et l’utilisateur mérite de le savoir avant d’y placer des fonds.

Zerion

Zerion est un dérivé de Briar, construit sur le protocole de transport Bramble, publié sous GPL v3, et le projet indique clairement qu’il n’est ni affilié ni approuvé par le projet Briar. Il n’existe que sur Android.

Il faut lui rendre justice, car il fait plusieurs choses remarquablement bien. Tout le trafic passe par Tor, sans exception : votre appareil construit un circuit à trois sauts, celui de votre correspondant en construit un autre, et les deux se rencontrent à un relais de rendez-vous, soit six sauts au total et aucune exposition d’adresse IP. Chaque message est protégé par un échange de clés post-quantique fondé sur ML-KEM-768. La version 3.0 a ajouté un maillage hors ligne par Bluetooth qui relaie messages individuels et de groupe par les téléphones voisins, chaque relais ne transportant que du chiffré, ainsi qu’un transport I2P optionnel. Un mode durci refuse de démarrer sur un appareil compromis, sous débogueur ou avec des frameworks de détournement. Depuis la version 3.0.4, un coffre chiffré peut contenir des portefeuilles Bitcoin et Monero non custodial, dont les clés sont générées sur l’appareil, protégées par leur propre mot de passe, avec des compilations reproductibles à partir de sources figées et des empreintes publiées.

La limite est structurelle et le projet ne la cache pas : sa documentation indique noir sur blanc qu’un message n’est délivré que lorsque les deux appareils sont en ligne et connectés à Tor, et qu’aucun serveur ne le conserve entre-temps pour de longues périodes hors ligne. Autrement dit, il n’existe pas d’équivalent de Briar Mailbox. C’est le point technique décisif, et c’est ce qui sépare un modèle pair à pair d’un modèle store and forward dans lequel un relais aveugle conserve le message chiffré jusqu’à ce que le destinataire vienne le chercher. Pour une correspondance ordinaire entre deux personnes qui ne sont pas connectées en même temps, la différence n’est pas théorique, elle décide de l’usage.

Une seconde question reste ouverte, et nous la formulons comme une question puisque nous n’avons trouvé aucune mesure publique : quelle est la qualité réelle des appels audio et vidéo pair à pair sur une architecture à six sauts Tor ? Les choix techniques annoncés sont sérieux, Opus, H.264, chiffrement AES-256-GCM et trames rembourrées, et les appels sont désactivés par défaut. Mais Tor n’est pas conçu pour la latence faible, et en l’absence de mesures publiées, ni l’éditeur ni nous ne pouvons affirmer que l’expérience est comparable à un appel classique.

Enfin, nous n’avons pas trouvé d’audit indépendant publié pour Zerion.

Comparées, les trois approches dessinent trois arbitrages nets. Radar choisit l’adoption immédiate au prix d’une dépendance à un tiers et du maintien du numéro de téléphone. Zerion choisit le maximum de résistance réseau au prix de la délivrabilité et de la disponibilité sur iPhone. Arpokrat choisit le modèle asynchrone et la répartition juridictionnelle au prix d’un historique et d’un audit qui n’existent pas encore. Aucun de ces trois arbitrages n’est absurde, et aucun n’est gratuit.

Tableau de synthèse

Application	Identifiant exigé	Juridiction et hébergement	Métadonnées côté serveur	Audit externe publié	Livraison hors ligne	Code
WhatsApp	Numéro de téléphone	États-Unis (Meta), CLOUD Act	Étendues, graphe de contacts livrable sur mandat	Non pour le service	Oui	Client fermé
Telegram	Numéro de téléphone	Îles Vierges britanniques, direction à Dubaï	Étendues, chats cloud lisibles par l’éditeur	Non	Oui	Client ouvert, serveur fermé
Signal	Numéro de téléphone	États-Unis, CLOUD Act	Deux horodatages, historique judiciaire public	Protocole formellement analysé	Oui	Ouvert
Molly	Numéro (compte Signal)	Serveurs Signal, États-Unis	Identiques à Signal	Hérité de Signal	Oui	Ouvert
Session	Aucun, identifiant aléatoire	Suisse, réseau de nœuds décentralisé	Minimales, pas de confidentialité persistante à ce jour	Oui, Quarkslab	Oui	Ouvert
Threema	Aucun, Threema ID	Suisse, serveurs à Zurich	Minimales	Oui, Cure53 et ETH Zurich	Oui	Ouvert, payant
Wire	E-mail ou numéro	Suisse et Allemagne, entité américaine au Delaware	Conservées en clair	Oui, Kudelski et X41	Oui	Ouvert
Element / Matrix	Selon le serveur, souvent e-mail	Celle de votre hébergeur	Visibles du serveur, état des salons en clair	Audits publiés sur le protocole	Oui	Ouvert
SimpleX Chat	Aucun, pas d’identifiant	Royaume-Uni, relais par défaut chez Linode et Akamai	Aucune corrélation possible par un relais unique	Oui, deux audits Trail of Bits	Oui	Ouvert
Arpokrat Messenger	Aucun, pas d’identifiant	Suisse (Zoug), relais dans cinq juridictions hors États-Unis	Relais aveugles, mémoire vive uniquement	Non à ce jour	Oui	Ouvert, AGPLv3
Briar	Aucun, pas d’identifiant	Aucune, pas de serveur	Aucune, rien à saisir	Oui, Cure53 en 2017	Via Briar Mailbox	Ouvert
Cwtch	Aucun, pas d’identifiant	Canada pour l’association, serveurs non fiables par conception	Résistance aux métadonnées de groupe	Non identifié	Partielle	Ouvert
Radar	Numéro (compte Signal)	Serveurs Signal, États-Unis	Identiques à Signal	Non identifié	Oui	Ouvert
Zerion	Aucun, pas d’identifiant	Aucune, pas de serveur	Aucune, tout passe par Tor	Non identifié	Non, les deux appareils doivent être en ligne	Ouvert, GPL v3

Quelle messagerie pour quel profil

Il n’y a pas de gagnant, il y a des situations.

Pour la famille et les proches. Signal, sans hésitation. C’est le seul choix qui combine une protection sérieuse et une chance réelle que vos interlocuteurs l’installent. Si le numéro de téléphone vous gêne, activez un nom d’utilisateur pour ne pas le communiquer. Si vos proches refusent absolument de bouger, activez au moins les sauvegardes chiffrées de bout en bout sur WhatsApp : ce n’est pas la même protection, mais c’est un progrès réel et gratuit.

Pour un journaliste avec des sources. Le problème n’est pas le contenu, c’est le lien. Une architecture sans identifiant est ici la seule réponse cohérente : SimpleX Chat ou Arpokrat Messenger, avec Tor activé et un profil différent par source. Si votre source utilise déjà Signal et refuse d’installer autre chose, utilisez Signal plutôt que rien, avec un numéro dédié qui ne vous identifie pas, et Molly sur Android pour protéger l’appareil lui-même en cas de saisie.

Pour un dirigeant ou un conseil juridique. Le critère dominant est la juridiction, pas l’anonymat. Threema pour un cabinet ou une petite structure, avec une facturation claire et des serveurs suisses. Element auto-hébergé pour une organisation qui a une équipe technique et veut la souveraineté sur son infrastructure, en gardant à l’esprit que l’administrateur du serveur voit les métadonnées. Wire pour une organisation qui veut un produit commercial de collaboration, après avoir examiné sa structure capitalistique.

Pour une zone de coupure Internet ou de censure. Briar, parce que le mode maillé Bluetooth et Wi-Fi fonctionne sans infrastructure du tout, et Zerion pour les mêmes raisons avec un maillage hors ligne plus récent. Ce sont les deux seules réponses réelles quand le réseau lui-même est l’adversaire. Prévoyez Briar Mailbox si votre correspondance doit survivre à des périodes hors ligne prolongées.

Pour qui manipule de la crypto au quotidien. C’est le seul profil où la convergence de 2026 change quelque chose. Radar si votre usage est le Bitcoin et que votre réseau est déjà sur Signal, en acceptant la dépendance à l’infrastructure Signal et le numéro de téléphone. Zerion si vous voulez du Bitcoin et du Monero avec le maximum de résistance réseau, et que vos correspondants sont sous Android et souvent en ligne. Arpokrat Messenger si vous voulez plusieurs chaînes, la disponibilité asynchrone et la possibilité de comparer les fournisseurs de swap selon leur exigence de KYC.

Pour qui veut le maximum sans compromis d’usage. Cette catégorie n’existe pas, et c’est la conclusion honnête de ce comparatif. Le maximum théorique, c’est Briar ou Zerion, et il se paie en délivrabilité, en batterie et en absence d’iPhone. Le compromis le plus favorable aujourd’hui, si vos correspondants sont sous Android, c’est une architecture sans identifiant en mode store and forward, SimpleX Chat ou Arpokrat Messenger, avec Tor activé. Si vous devez inclure des utilisateurs d’iPhone, SimpleX Chat est aujourd’hui le seul de cette famille à couvrir les deux plateformes. Arpokrat Messenger, disponible sur Android, est en cours de développement pour iOS et pour les plateformes de bureau, sans date de disponibilité annoncée.

Ce que nous avons choisi chez Arpokrat et pourquoi

Cette section n’est pas un argumentaire, c’est une explication d’arbitrages, y compris de ceux que nous n’avons pas faits.

Nous sommes partis de SimpleX plutôt que d’écrire un protocole. La raison est simple : un protocole de messagerie sécurisée n’a de valeur que quand il a été inspecté, et un protocole neuf n’a par définition aucune inspection derrière lui. SimpleX a une spécification publique, un code public et deux audits de Trail of Bits. Inventer notre cryptographie nous aurait permis de faire une meilleure page marketing et une moins bonne messagerie.

Nous avons choisi le modèle store and forward plutôt que le pair à pair. C’est un arbitrage explicite contre le maximum théorique. Un relais aveugle qui conserve un message chiffré jusqu’à sa collecte est une pièce d’infrastructure de plus, donc une surface de plus. En échange, un message part quand vous l’écrivez et arrive quand votre correspondant se connecte, ce qui est la condition d’une correspondance normale. Le critère du côté pratique, défendu au début de cet article, n’est pas une clause de style : nous l’avons appliqué à nous-mêmes.

Nous avons réparti les relais dans cinq juridictions hors des États-Unis et exclu les hyperscalers américains, non par posture mais parce que le CLOUD Act fonctionne en contraignant un fournisseur américain sur les données qu’il contrôle. Un relais aveugle qui ne conserve rien sur disque a peu à livrer ; un relais aveugle qu’aucune injonction américaine ne peut atteindre en a encore moins. Les deux mesures se cumulent, aucune ne remplace l’autre.

Nous avons intégré un portefeuille et un agrégateur de swap parce que la même personne qui refuse qu’un intermédiaire connaisse ses interlocuteurs refuse généralement qu’un intermédiaire connaisse ses transactions. La notation de A à D des fournisseurs de swap selon leur exigence de vérification d’identité vient de la même logique : nous ne décidons pas à la place de l’utilisateur du niveau de confidentialité qu’il veut payer, nous lui donnons l’information pour arbitrer.

Ce que nous n’avons pas encore fait, enfin, mérite d’être dit dans la même section. Nous n’avons pas d’audit indépendant publié à notre nom. Nous n’avons pas d’historique de réquisitions judiciaires publiées, seulement un warrant canary. Nous ne sommes pas encore sur iOS. Ces trois lacunes sont réelles, elles sont documentées dans notre fiche plus haut, et aucune ne se comble avec un communiqué.

Conclusion

La bonne question n’est pas « quelle est la meilleure messagerie ». Elle n’a pas de réponse, parce qu’elle est mal posée. La bonne question est : contre qui vous protégez-vous ?

Contre un annonceur qui veut profiler vos centres d’intérêt, à peu près toutes les applications de ce comparatif conviennent. Contre un conjoint violent qui a accès à votre téléphone, la question est le verrouillage local et l’effacement mémoire, et Molly répond mieux que Threema. Contre une réquisition judiciaire dans votre pays, la question est la juridiction et ce que le service détient. Contre un adversaire qui cherche à établir que vous avez parlé à quelqu’un, la seule réponse est une architecture qui ne crée pas cette information. Et contre un adversaire capable de couper le réseau, la seule réponse est de ne pas en dépendre.

Aucune application ne répond à toutes ces menaces à la fois, et celles qui le prétendent méritent votre méfiance en premier. Ce que 2026 a démontré, c’est que le chiffrement est devenu la partie facile. Ce qui reste difficile, ce sont les métadonnées, la juridiction, et la capacité d’un projet à exister encore dans deux ans. Session est passé à quelques semaines de disparaître, Briar a réduit ses ambitions, et ces deux événements en disent plus long sur l’état réel du secteur que n’importe quelle comparaison de primitives cryptographiques.

Choisissez donc en fonction de votre adversaire, pas en fonction d’un classement. Et gardez à l’esprit que le meilleur outil du monde ne vaut rien si la conversation finit ailleurs parce que votre interlocuteur n’a pas voulu l’installer.

Sources

La fin de la confidentialité ? Backdoors, Online Safety Act et la réponse des écosystèmes souverains

Wed, 10 Jun 2026 00:00:00 +0000

Londres est devenue l’épicentre d’une bataille mondiale pour l’avenir de la vie privée numérique. Avec l’adoption de l’Online Safety Act 2023 (OSA) et les récentes propositions de révision de l’Investigatory Powers Act (IPA) — surnommé par ses détracteurs la « Charte des espions » —, le gouvernement britannique s’arroge le droit d’imposer des obligations de surveillance au cœur même des communications privées. Le point de rupture est le pouvoir conféré au régulateur OFCOM pour exiger que les plateformes déploient une « technologie accréditée » afin de détecter les contenus d’abus sexuels sur mineurs (CSEA) ou de terrorisme, y compris dans les communications chiffrées de bout en bout.

Pour les grandes plateformes numériques, le message de Westminster est sans ambiguïté : soit elles ménagent un accès étatique à leurs infrastructures, soit elles s’exposent à des amendes pouvant atteindre 10 % de leur chiffre d’affaires mondial. La réponse a été immédiate : des services comme Signal et WhatsApp ont publiquement menacé de se retirer du marché britannique, refusant de compromettre la sécurité de leurs utilisateurs pour satisfaire une seule juridiction. L’argument technique est difficilement contestable : il n’existe pas de clé maîtresse réservée aux seuls acteurs légitimes. Une porte ouverte pour les forces de l’ordre est, par construction, une porte ouverte pour les cybercriminels et les services de renseignement étrangers.

Le modèle économique des grandes plateformes : un obstacle structurel au Zero-Knowledge

La résistance des grandes plateformes à l’adoption du chiffrement de type Zero-Knowledge ne s’explique pas par une incapacité technique, mais par une incompatibilité économique fondamentale. Des entreprises comme Alphabet et Meta reposent sur des modèles de monétisation fondés sur la collecte systématique de données comportementales. Ce modèle est d’ailleurs implicitement reconnu par le Règlement sur les marchés numériques (DMA) de l’Union européenne, qui qualifie ces « contrôleurs d’accès » (gatekeepers) d’entités dont la position dominante est précisément alimentée par l’accumulation de données à une échelle sans équivalent. Pour ces acteurs, adopter une architecture Zero-Knowledge reviendrait à priver leurs systèmes publicitaires de l’identification continue des utilisateurs qui en constitue le carburant. Il ne s’agit donc pas d’un choix technique, mais d’un arbitrage entre la confidentialité des utilisateurs et la viabilité de leur modèle d’affaires.

Le risque stratégique : la menace « Harvest Now, Decrypt Later »

Au-delà du débat sur la vie privée, l’affaiblissement du chiffrement soulève une question de sécurité nationale d’une tout autre portée. La stratégie dite Harvest Now, Decrypt Later (HNDL) consiste, pour des adversaires étatiques, à intercepter et stocker aujourd’hui des volumes massifs de communications chiffrées, dans l’attente de capacités de déchiffrement quantique futures. En fragilisant les standards de chiffrement actuels, le cadre législatif britannique facilite objectivement ce type d’opérations contre des communications gouvernementales, diplomatiques ou industrielles.

C’est précisément dans ce contexte de déficit de confiance que des écosystèmes comme celui d’Arpokrat acquièrent une pertinence opérationnelle. En opérant sous le régime de la Loi fédérale sur la protection des données (LPD/FADP) suisse, avec une architecture ne collectant aucun identifiant civil, Arpokrat offre une rupture technique d’avec les infrastructures soumises à la juridiction britannique — garantissant que le système reste inaudible face aux injonctions prévues par l’OSA.

Le conflit de normes : OSA et IPA contre le droit européen

L’analyse juridique des nouvelles prérogatives étatiques britanniques révèle une collision directe avec les fondements du droit européen à la protection des données et à la confidentialité des communications.

OSA contre l’interdiction de surveillance généralisée

L’article 121 de l’OSA introduit la possibilité pour OFCOM d’émettre des injonctions contraignant les plateformes à mettre en œuvre un balayage côté client (client-side scanning). Cette mesure contrevient frontalement au principe, issu du droit européen et repris dans la jurisprudence de la CJUE, interdisant les obligations générales de surveillance. En imposant une « vulnérabilité par conception », elle place également les entreprises dans une situation de double contrainte : en affaiblissant leur sécurité pour se conformer à un mandat étatique, elles manquent à leur obligation de garantir un niveau de sécurité approprié au traitement, consacrée par l’article 32 du RGPD.

La Directive ePrivacy et la confidentialité des communications

Le balayage des messages privés entre en contradiction directe avec l’article 5, paragraphe 1, de la Directive 2002/58/CE (ePrivacy), qui oblige les États membres à garantir la confidentialité des communications électroniques et interdit toute forme d’interception ou de surveillance sans le consentement explicite des utilisateurs concernés.

Les Technical Capability Notices et le blocage des mises à jour de sécurité

Sous le régime de l’IPA 2016, le gouvernement britannique entend désormais utiliser les Technical Capability Notices (TCN) pour s’opposer à des mises à jour de sécurité avant leur déploiement. Ce mécanisme crée un conflit insoluble avec l’obligation, posée par l’article 32 du RGPD, d’assurer en continu la sécurité des systèmes de traitement — une obligation qui exige précisément la capacité d’appliquer des correctifs sans délai ni interférence extérieure.

Risques de conformité pour les entreprises opérant en Europe

Les révisions de l’IPA visent à contraindre les entreprises à notifier le gouvernement britannique de toute modification technique affectant la sécurité, avant sa mise en œuvre, lui conférant ainsi un droit de veto sur l’évolution des produits. Cette ingérence crée une insécurité juridique considérable pour les fournisseurs opérant sur le marché européen : l’adéquation britannique au droit européen — déjà fragile — pourrait être remise en cause si le Royaume-Uni ne garantit plus une protection substantiellement équivalente à celle du RGPD. Les transferts de données vers le Royaume-Uni dans ce nouveau cadre seraient dès lors susceptibles d’exposer les entreprises à des sanctions au titre du RGPD.

La défense par l’impossibilité technique : le principe Zero-Knowledge comme bouclier juridique

La jurisprudence internationale, consolidée par les arrêts Schrems I et Schrems II de la CJUE, a établi un principe déterminant : la seule sauvegarde robuste contre une surveillance disproportionnée est l’impossibilité technique d’y accéder. Des architectures Zero-Knowledge déclinent ce principe en trois couches de protection :

Absence de garde : la plateforme ne détenant pas les clés de déchiffrement, toute injonction de balayage des messages est techniquement inopérante ;
Souveraineté du système d’exploitation : le contrôle d’ArpokratOS supprime la télémétrie qui alimente la collecte de renseignements au niveau du terminal ;
Ancrage juridictionnel suisse : en hébergeant son infrastructure en Suisse, Arpokrat opère sous un régime légal exigeant des demandes d’entraide judiciaire individualisées et motivées, neutralisant l’exécution automatisée des balayages de masse prévus par l’OSA.

Conclusion

Les dispositions de l’OSA et les révisions de l’IPA ne constituent pas seulement une menace pour la vie privée des individus : elles représentent une rupture de la sécurité juridique pour l’ensemble des données européennes transitant par des infrastructures soumises à la juridiction britannique. En légitimant la fragilisation du chiffrement au nom de la sécurité publique, Londres expose paradoxalement ses alliés et partenaires commerciaux à des risques d’espionnage industriel et étatique que les architectures Zero-Knowledge sont précisément conçues pour prévenir.

L’intégrité des communications professionnelles et institutionnelles exige désormais une réponse structurelle : la migration vers des écosystèmes décentralisés garantissant la souveraineté numérique, du niveau du code jusqu’à l’ancrage juridictionnel.

Mot de passe et Entropie : La science derrière votre sécurité

Wed, 03 Jun 2026 00:00:00 +0000

« Votre mot de passe doit contenir 8 caractères, une majuscule, une minuscule, un chiffre et un caractère spécial. »

Nous connaissons tous cette règle. Et pourtant, en cybersécurité, c’est ce que l’on appelle du “théâtre de sécurité”. Un mot de passe comme P@ssw0rd1! respecte toutes ces règles. Mais c’est un mot courant avec des substitutions prévisibles, exactement ce que les outils de cassage essaient en premier.

La véritable sécurité ne repose pas sur des règles visuelles arbitraires, mais sur une réalité mathématique implacable : l’entropie.

L’Entropie selon Claude Shannon

Pour comprendre la force d’un mot de passe, il faut se tourner vers Claude Shannon, le père de la théorie de l’information. L’entropie mesure le degré d’incertitude ou d’imprévisibilité d’une information.

Appliquée aux mots de passe, l’entropie se calcule en bits. Plus le nombre de bits est élevé, plus le mot de passe est imprévisible pour un ordinateur. La formule simplifiée de l’entropie (E) d’un mot de passe généré aléatoirement est :

E = L × log2(R)

L est la longueur du mot de passe.
R est la taille du répertoire (26 pour les minuscules, 62 avec les majuscules et chiffres, 94 avec tous les symboles imprimables). Les quatre jeux de caractères de notre générateur en donnent 91, car son jeu de symboles compte 29 caractères.

Augmenter la taille du répertoire (ajouter des symboles) augmente l’entropie, mais augmenter la longueur (ajouter des caractères) l’augmente de façon beaucoup plus drastique. Cependant, la longueur ne bat la complexité qu’à une seule condition : que le mot de passe soit généré aléatoirement.

Force brute vs Attaque par dictionnaire

Si vous utilisez des mots ou des structures prévisibles, la règle de la longueur pure s’effondre.

Les logiciels de piratage n’essaient pas toutes les combinaisons de lettres une par une (ce qu’on appelle la Force Brute). Ils utilisent de vastes listes de mots de passe réels issus de fuites de données passées, ainsi que des mots et phrases courants. C’est l’Attaque par Dictionnaire.

Si votre mot de passe est long, mais composé de mots du dictionnaire ou de substitutions prévisibles, son entropie réelle est dramatiquement plus faible que son entropie mathématique théorique.

Le tableau ci-dessous suit une seule règle : 100 milliards d’essais par seconde, le rythme que la page de notre générateur suppose pour une attaque hors ligne contre un hachage rapide. Les durées sont des moyennes (la moitié de toutes les possibilités), arrondies vers le bas avec la même formule que cette page. Le chemin le plus rapide pour chaque mot de passe est en gras :

Mot de passe	Entropie si chaque caractère était aléatoire	Force brute (moyenne)	Attaque par dictionnaire (notre estimation)
`password123`	56 bits (11 caractères, minuscules et chiffres)	7 jours	Moins d’une seconde
`S3cr3t!99`	58 bits (9 caractères, les quatre jeux)	24 jours	Moins d’une seconde
`correct horse battery staple`	133 bits (28 caractères, minuscules et espace)	Plus de 1 billion d’années	1 minute
`gL7!pQ9z#vX2`	78 bits (12 caractères, les quatre jeux)	51 mille ans	Aucun raccourci

La colonne dictionnaire est une estimation. Elle suppose que les essais de l’attaquant suivent la structure de chaque mot de passe, et que chaque mot de base fait partie des 1 000 mots les plus courants :

password123 : un mot courant et trois chiffres. Cela fait 1 000 × 1 000, soit environ un million d’essais.
S3cr3t!99 : un mot courant, avec ou sans majuscule, chaque “e” remplacé ou non par “3”, puis n’importe quel suffixe de trois caractères. Cela fait environ 7 milliards d’essais.
correct horse battery staple : quatre mots courants. La bande dessinée xkcd qui a rendu cette phrase célèbre compte 44 bits pour quatre mots tirés d’une liste de 2 048. Au même rythme, cela fait 88 secondes en moyenne, arrondies vers le bas à 1 minute.
gL7!pQ9z#vX2 : aucun mot et aucun motif, donc la force brute est le chemin le plus rapide.

Ces estimations traitent chaque mot de passe comme inconnu de l’attaquant. Tous les mots de passe de cet article sont désormais publics, donc chacun a sa place dans un dictionnaire. Un mot de passe publié est un mot de passe grillé.

L’illusion du Leetspeak et les règles de mutation

Prenons l’exemple de S3cr3t!99. Visuellement, il semble complexe et robuste. Pourtant, il s’agit simplement du mot du dictionnaire “secret”, où les ’e’ ont été remplacés par des ‘3’, auquel on a ajouté un suffixe très courant (!99). C’est ce qu’on appelle le leetspeak.

Face à une attaque par dictionnaire, ce mot de passe tient moins d’une seconde, et non les 24 jours que sa longueur laisserait croire. Les logiciels de craquage modernes (comme Hashcat) ne se contentent pas de tester des listes de mots figées ; ils appliquent automatiquement des règles de mutation. Ils vont prendre chaque mot de leur dictionnaire, tester toutes les combinaisons de leetspeak possibles, inverser les majuscules, et y accoler des années ou des symboles. Le leetspeak offre un faux sentiment de sécurité.

L’astuce du changement de clavier (Keyboard Shift)

Pour complexifier une phrase mémorisable, certains utilisent l’astuce du décalage de disposition de clavier. Par exemple, vous mémorisez une phrase comme mon-chat. Mais au moment de la taper, vous posez vos doigts sur un clavier physique AZERTY (français) tout en ayant configuré votre système d’exploitation en QWERTY (anglais).

Le mot pensé : mon-chat
Le résultat tapé : ;on-chqt (La touche ’m’ devient ‘;’ et le ‘a’ devient ‘q’).

Est-ce une bonne idée en OPSEC ? Non, cette méthode n’est pas suffisante si elle est utilisée seule. Tout comme le leetspeak, un changement de disposition est une substitution fixe : un attaquant qui la soupçonne applique la même correspondance à chaque essai. En OPSEC, c’est de la sécurité par l’obscurité : cela retarde un attaquant amateur, mais ne l’arrête pas face à une attaque ciblée et équipée.

Couplée à un mot de passe déjà fort (comme une longue phrase secrète aléatoire), elle apporte peu. Même si un attaquant essaie mille paires de dispositions, cela ajoute moins de 10 bits, puisque log2(1 000) ≈ 9,97. La force vient toujours de la phrase secrète en dessous.

Construire un mot de passe maître (~250 bits)

Si les listes de mots, le leetspeak et les astuces de frappe ont leurs limites, comment construire un mot de passe maître qui dure ? Notre générateur classe déjà 80 bits “Fort” et 100 bits “Très Fort”. Pour un mot de passe maître censé tenir des décennies, cet article vise bien plus haut : environ 250 bits d’entropie. La section quantique ci-dessous explique pourquoi, et ce que cette marge n’apporte pas.

Il existe deux manières d’y parvenir selon vos besoins :

1. Des caractères aléatoires (pour un gestionnaire de mots de passe)

Une chaîne de caractères générée entièrement au hasard, sans motif qu’une machine puisse exploiter : 8}8,_$-p)M&n,XvUCT0o+.5hDE6P^w6b@U-evS0 39 caractères tirés au hasard parmi les 91 de notre générateur : ≈ 253 bits. Elle a été tirée pour cet article, elle est donc désormais publique. Ne l’utilisez jamais.

2. Une phrase secrète aléatoire (pour un mot de passe que vous retenez)

Des mots aléatoires sont plus faciles à retenir que des caractères aléatoires. Chaque mot tiré de la liste EFF de 7 776 mots ajoute environ 12,9 bits : c’est donc le nombre de mots qui donne l’entropie. Douze mots donnent ≈ 155 bits, bien au-delà du seuil “Très Fort” de notre générateur. Des mots seuls ne dépassent 250 bits qu’à partir de 20 mots.

Notre générateur s’arrête à 12 mots. Pour dépasser 250 bits avec moins de mots, cochez “Chiffre aléatoire après chaque mot” et choisissez “Chiffre + Symbole” comme séparateur. Onze mots donnent alors ≈ 260 bits : depletion78$sporting14~overlap11>macaw86>paced95,paramedic41}blot41$flagstone07;uncanny92/broadways77#say2 Tirée au hasard pour cet article, avec exactement ces réglages. Un mot de passe publié est un mot de passe grillé : n’utilisez jamais celle-ci, ni aucun exemple que vous lisez. Seul ce qui est tiré au hasard compte. Mettre une majuscule à chaque mot n’ajoute rien, et des mots que vous choisissez vous-même sont bien plus faibles que des mots aléatoires.

La menace quantique : L’algorithme de Grover

Pourquoi viser 250 bits alors que 128 bits bloquent déjà les supercalculateurs d’aujourd’hui ? La réponse réside dans la perspective de grands ordinateurs quantiques.

En cryptographie, l’algorithme de Grover permet à un ordinateur quantique de chercher dans une base de données non triée de manière beaucoup plus rapide qu’un ordinateur classique. Concrètement, Grover réduit de moitié le niveau de sécurité effectif d’une clé symétrique ou d’un mot de passe.

Face à un ordinateur quantique exécutant l’algorithme de Grover, un mot de passe avec une entropie de 128 bits n’offrirait, en théorie, qu’une résistance équivalente à 64 bits. C’est une marge bien plus mince.

Doubler l’entropie préserve la marge : environ 256 bits laisseraient encore environ 128 bits face à Grover. C’est de là que vient l’objectif de 250 bits de cet article. C’est une précaution que cet article choisit, pas un chiffre tiré d’une norme.

Cette marge a ses limites. L’accélération de Grover est quadratique, pas illimitée. Chacune de ses étapes doit encore calculer le hachage du mot de passe stocké par le site, sur un ordinateur quantique assez grand pour l’exécuter. À titre de comparaison, aux 100 milliards d’essais par seconde que suppose la page de notre générateur, une recherche moyenne sur 100 bits prend déjà au moins 200 milliards d’années.

La logique rappelle Harvest Now, Decrypt Later (HNDL) : une base de hachages de mots de passe volée peut être conservée aujourd’hui et attaquée plus tard, avec de meilleures machines. Une marge plus large relève le niveau d’exigence face à ce risque. Ce n’est pas une garantie permanente.

Arpokrat Password Generator : Créez le vôtre

Ne laissez pas la sécurité de vos accès au hasard. Notre générateur gratuit crée des mots de passe et des phrases secrètes aléatoires. Pour chacun, il affiche l’entropie en bits et le temps moyen que prendrait une recherche.

Il se contente de générer : il n’évalue pas un mot de passe que vous utilisez déjà. Pour l’objectif de 250 bits ci-dessus, choisissez un mot de passe de 39 caractères avec les quatre jeux de caractères. Le générateur l’affiche à “≈ 253 bits”.

👉 Arpokrat Password Generator

Il fonctionne dans votre navigateur. Ce qu’il génère n’est jamais envoyé ni enregistré.

Le maillon faible final : Recyclage et gestion des accès

L’entropie mathématique ne protège pas contre l’erreur humaine. Un mot de passe de 250 bits perd toute sa valeur dès qu’il fuite, s’il est réutilisé sur plusieurs sites (une attaque appelée Credential Stuffing) ou s’il n’est pas protégé par un second facteur d’authentification (2FA).

La règle d’or de l’hygiène numérique est de n’avoir à retenir qu’un seul mot de passe : votre mot de passe maître de 250 bits (une phrase secrète aléatoire, comme ci-dessus). Tous vos autres accès (banque, réseaux sociaux, serveurs) doivent utiliser des mots de passe aléatoires uniques, générés spécifiquement pour eux.

Pour stocker tous ces mots de passe que vous ne pouvez pas retenir, utilisez un gestionnaire de mots de passe. Choisissez-en un qui chiffre votre coffre-fort sur votre appareil avant de le synchroniser (ce qu’on appelle souvent zero-knowledge), idéalement open source et audité de manière indépendante.