Messagerie chiffrée 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 Bombe à Retardement : Collecter maintenant, déchiffrer plus tard et l'Impératif Zero-Knowledge

Tue, 26 May 2026 00:00:00 +0000

La dépendance des gouvernements européens aux infrastructures cloud américaines ne pose pas seulement un problème d’interception immédiate. La grande révélation, la menace la plus dévastatrice pour les décennies à venir, est ce que les spécialistes du renseignement appellent la stratégie HNDL : « Harvest Now, Decrypt Later » (Collecter maintenant, déchiffrer plus tard).

Il ne s’agit pas d’une intrusion frontale, mais d’un vol silencieux. Les agences de renseignement et les adversaires étatiques interceptent et stockent aujourd’hui d’immenses quantités de données chiffrées, simplement parce que le coût du stockage est devenu dérisoire.

Ils attendent patiemment le moment où les bonds technologiques et l’évolution imprévisible de la puissance de calcul rendront les clés cryptographiques actuelles obsolètes. Ce qui constitue un secret d’État protégé en 2026 pourrait devenir un livre ouvert dans quinze ou vingt ans.

La Responsabilité Rétroactive et le Risque Temporel

Le modèle HNDL introduit une notion inédite : le préjudice juridique différé. Traditionnellement, une violation du secret est un événement statique. Avec la collecte massive de données en vue d’un déchiffrement futur, la confidentialité devient une variable dépendante du temps.

Pour quantifier ce risque, le modèle scientifique HNDL définit que la confidentialité échoue inévitablement lorsque la durée de vie nécessaire du secret dépasse l’horizon de déchiffrement de l’adversaire. Les secteurs d’exposition critique — comme le renseignement d’État, le secret industriel et les dossiers médicaux dont la conservation dépasse souvent 30 ans — se trouvent aujourd’hui dans un état de vulnérabilité latente.

Si un État ou une organisation ne garantit pas la souveraineté absolue de son infrastructure matérielle, il est, en pratique, en train de signer une renonciation à la confidentialité à long terme de ses citoyens et de ses institutions.

L’interception d’aujourd’hui est la compromission de demain. Transformer la dépendance au cloud en une dette de sécurité nationale est un pari impossible à rembourser.

L’Antithèse Arpokrat : L’Impossibilité Juridique par le Code

Face à cette vulnérabilité, l’industrie répond par la création d’écosystèmes de souveraineté numérique radicaux. Le modèle Arpokrat apparaît comme l’antithèse parfaite des messageries centralisées : au lieu de « maquiller » la sécurité sur des serveurs étrangers soumis au CLOUD Act, cette architecture fonctionne sur un réseau décentralisé, protégé par la très stricte Loi fédérale sur la protection des données (nLPD / FADP) en Suisse.

La logique centrale est celle d’une Privacy by Design absolue. En supprimant la nécessité de fournir un numéro de téléphone ou un e-mail, l’utilisateur devient une simple clé cryptographique, dénuée d’identité physique.

Sur le plan juridique, cela modifie drastiquement les règles du jeu. Un tribunal américain peut ordonner la remise de données à une entreprise relevant de sa juridiction, mais si l’architecture est fondamentalement Zero-Knowledge et non-custodiale, l’entreprise se retrouve face à une impossibilité technique d’exécution.

Il ne s’agit pas de désobéissance civile face aux lois extraterritoriales, mais d’une sauvegarde mathématique et juridique imparable : ce que l’on ne détient pas ne peut pas être divulgué.

Au-delà du Chiffrement : Dévaluer la Donnée Cible

Face à l’imprévisibilité des avancées technologiques des prochaines décennies, prétendre au “risque zéro” est une illusion. La véritable réponse, intégrée nativement dans l’application de messagerie Arpokrat, ne consiste pas à parier sur des mathématiques éternelles, mais à dévaluer la donnée elle-même.

Si un adversaire parvient un jour à briser les algorithmes grâce à une puissance de calcul inédite, notre architecture garantit qu’il ne trouvera qu’un réseau de communications anonymes. Sans métadonnées centrales, sans numéros de téléphone et sans historiques d’adresses IP pour relier un message à un individu physique, le contenu chiffré perd sa valeur stratégique car il devient inattribuable.

Cependant, le logiciel seul ne peut rien si le matériel le trahit en amont.

En dernière analyse, la sécurité au XXIᵉ siècle exige l’indépendance de la machine elle-même. L’utilisation de systèmes d’exploitation dégooglisés — avec une protection blindée au niveau du noyau (kernel) et l’élimination totale de la télémétrie étrangère — ne relève plus du militantisme de niche. Déployer un OS souverain est devenu une exigence de survie absolue pour quiconque manipule des secrets professionnels, industriels ou étatiques.

L'Illusion de la Souveraineté : L'Affaire Olvid et le Piège du CLOUD Act

Thu, 21 May 2026 00:00:00 +0000

L’annonce a résonné comme un véritable « cri d’indépendance » dans les couloirs de Paris : la Première ministre a ordonné que le gouvernement français abandonne WhatsApp et Signal au profit d’Olvid, une application de messagerie présentée comme « native ». L’objectif affiché était clair : protéger les secrets d’État de la longue main des agences de renseignement étrangères.

Cependant, une ironie amère s’est rapidement imposée : le cœur d’Olvid — son infrastructure de serveurs — bat au sein d’Amazon Web Services (AWS), un géant américain.

Pour le grand public, cela semble n’être qu’une simple question technique d’hébergement. Mais pour les architectes de la cybersécurité souveraine et ceux qui suivent la géopolitique des données, il s’agit d’une vulnérabilité politique de tout premier ordre.

Extraterritorialité et Conflit de Souverainetés

En s’appuyant sur l’infrastructure d’Amazon, Olvid entre automatiquement dans l’orbite du CLOUD Act américain.

L’analyse juridique de cette affaire révèle un scénario d’insécurité juridictionnelle que la simple adoption d’une « application » nationale ne permet absolument pas de résoudre. Le point de bascule réside dans le concept de « contrôle » versus « localisation ».

Le CLOUD Act a radicalement modifié le paradigme juridique en stipulant que la localisation physique du serveur n’a aucune importance. L’obligation de coopération du fournisseur de services (ici, AWS) découle uniquement de son lien juridictionnel avec les États-Unis. Ainsi, Washington peut exiger des données auprès d’entreprises relevant de sa juridiction, même lorsque ces données sont physiquement stockées sur le sol européen.

Sur le plan légal, cela crée un conflit frontal avec le Règlement général sur la protection des données (RGPD). La Cour de justice de l’Union européenne (à travers les célèbres arrêts Schrems I et II) a d’ailleurs déjà établi que les lois de surveillance américaines n’offrent pas un niveau de protection équivalent à celui de l’Europe, car elles ne se limitent pas à ce qui est « strictement nécessaire ».

La souveraineté numérique n’est pas un attribut du logiciel, mais une propriété de l’intégrité de la chaîne de garde.

Le Spectre du FISA et la Fausse Promesse du Chiffrement

Pire encore, cette dépendance à l’infrastructure américaine place ces données sous l’ombre du Foreign Intelligence Surveillance Act (FISA), qui autorise la surveillance électronique à des fins de « renseignement étranger » visant des cibles situées hors des États-Unis.

Face à ces menaces, Olvid affirme que son chiffrement de bout en bout constitue un bouclier suffisant. Du point de vue de l’ingénierie de la vie privée, cette défense est dangereusement partielle.

Le récent rejet par l’Assemblée nationale française des backdoors (portes dérobées) témoigne d’une résistance législative face à la vulnérabilité par conception. Pourtant, même si le contenu d’un message est chiffré, l’infrastructure centralisée d’AWS expose les métadonnées. Savoir qui parle à qui, quand, à quelle fréquence et depuis où est souvent beaucoup plus précieux pour le renseignement étranger que le contenu du message lui-même.

Le chiffrement protège le texte, mais le serveur centralisé trahit le réseau de contacts.

Le Véritable Danger Reste à Venir

Tant que l’infrastructure européenne dépendra d’entités soumises à des statuts extraterritoriaux, la sécurité juridique de nos communications restera purement temporaire et illusoire.

La sécurité nationale au XXIᵉ siècle exige bien davantage que de bonnes intentions législatives ou des boucliers logiciels de façade : elle exige une indépendance totale de l’infrastructure et du matériel. Car si l’interception de ces métadonnées et de ces paquets chiffrés semble inoffensive aujourd’hui, elle nourrit en réalité la menace la plus dévastatrice de la prochaine décennie : la stratégie du “Collecter maintenant, déchiffrer plus tard”.

Un secret d’État intercepté aujourd’hui n’est qu’une bombe à retardement mathématique.

(Lisez la suite de notre analyse dans la Partie 2 : La Bombe à Retardement et l’Impératif Zero-Knowledge)