skip to content

Tchap : ce qu'une fuite via compte compromis révèle sur le chiffrement de bout en bout

Une revendication de fuite vise Tchap, la messagerie souveraine de l'État. L'enseignement n'est pas cryptographique : c'est un compte authentifié, compromis par ingénierie sociale, qui aurait ouvert l'accès aux salons publics interministériels. Décryptage d'un modèle de sécurité mal compris.

Nicolas Verlhiac : photo de l'auteur de l'article
Nicolas Verlhiac
6 min de lecture

Le week-end des 6 et 7 juin 2026, un cybercriminel a revendiqué sur un forum spécialisé l’accès à Tchap, la messagerie instantanée de l’État français. Les chiffres avancés sont spectaculaires : plus de 73 000 comptes d’agents, 643 000 messages, près de 59 000 fichiers pour 13,51 Go de données, sur une période qui remonterait à juin 2023. De quoi alimenter un titre anxiogène : la messagerie « sécurisée » de l’État aurait été percée.

Sauf que la réalité technique est plus nuancée, et bien plus instructive. Le 8 juin 2026, la DINUM a confirmé un incident de sécurité, mais elle est claire sur sa nature : il n’y a pas eu de faille du chiffrement de Tchap. L’accès a été obtenu via un compte légitime compromis, rattaché à l’Éducation nationale selon le pirate, puis utilisé pour parcourir des espaces de discussion ouverts. La distinction n’est pas un détail de spécialiste : elle est au cœur de la manière dont les organisations doivent penser leur sécurité.

Cet article ne rejoue pas le décompte des messages, revendiqué par l’attaquant mais non validé à ce jour par la DINUM (le suivi factuel est tenu à jour dans notre fiche de l’observatoire des fuites). Il répond à une question plus utile : pourquoi une messagerie chiffrée de bout en bout peut-elle laisser fuiter des contenus, et que faut-il en retenir concrètement ?

Ce que la DINUM confirme, et ce qui reste revendiqué

Il faut distinguer deux niveaux de certitude. Le 8 juin 2026, la DINUM a publié un communiqué qui confirme plusieurs points :

  • un incident de sécurité consécutif à l’usurpation d’un compte utilisateur ;
  • l’identification et le blocage rapide du compte compromis, avec l’ANSSI, pour mettre fin à l’accès de l’attaquant ;
  • des conversations privées non concernées : grâce au chiffrement de bout en bout, leur contenu et leur historique restent protégés ;
  • un impact limité aux salons publics, non chiffrés par conception ;
  • une notification à la CNIL pour les données personnelles susceptibles d’avoir été exposées dans ces salons ;
  • des investigations en cours sur les journaux d’événements pour déterminer précisément ce qui a été consulté.

En revanche, les volumes restent une revendication de l’attaquant (qui se présente sous le pseudonyme « misere »), non validée à ce jour : 73 467 comptes, 643 459 messages, 876 salons, 4 002 espaces, 59 386 fichiers (13,51 Go) et 90 occurrences de documents « Diffusion restreinte », sur une période courant de juin 2023 à juin 2026. De même, les modalités techniques qu’il décrit (annuaire utilisateur sans limitation de débit, endpoints de téléchargement de fichiers, énumération de comptes, scripts PowerShell contenant des identifiants) n’ont pas été confirmées indépendamment.

Le maillon qui a cédé n’est pas l’algorithme de chiffrement, mais l’identité d’un utilisateur. C’est une différence de nature, pas de degré.

Autrement dit : l’incident est confirmé, son ampleur ne l’est pas. C’est précisément pour cela qu’il mérite une lecture posée plutôt qu’un commentaire à chaud sur des chiffres invérifiables.

Tchap, une messagerie souveraine : comment elle est conçue

Pour comprendre ce qui a pu fuiter, il faut comprendre l’architecture.

Matrix, chiffrement de bout en bout et homologation

Tchap repose sur Matrix, un protocole ouvert de messagerie décentralisée. Les serveurs (les homeservers) sont hébergés en France, répartis par ministère, et la solution est homologuée par l’ANSSI. Pour les conversations privées, Tchap met en œuvre un chiffrement de bout en bout via les bibliothèques Olm et Megolm : seuls les terminaux des participants détiennent les clés, et le serveur ne voit jamais le contenu en clair.

Ce modèle est robuste sur ce qu’il protège : même un administrateur du serveur, même un attaquant ayant volé une session, ne peut pas lire le contenu d’un salon chiffré auquel il n’a pas été légitimement convié.

Tout n’est pas chiffré de la même manière

C’est ici que se loge l’angle mort. Sur ce type de plateforme collaborative, tous les espaces ne sont pas logés à la même enseigne :

  • les conversations privées et salons restreints sont chiffrés de bout en bout ;
  • les salons publics et espaces ouverts, conçus pour la collaboration large entre agents, sont par nature consultables par tout compte authentifié et n’offrent pas la même garantie de confidentialité.

Un agent qui se connecte légitimement peut donc parcourir un grand nombre de salons interministériels ouverts. Si son compte tombe entre de mauvaises mains, l’attaquant hérite exactement des mêmes droits de lecture. Le chiffrement de bout en bout n’a pas « failli » : il n’a tout simplement jamais eu vocation à protéger un salon public.

Le vrai vecteur : l’identité, pas la cryptographie

La revendication décrit un scénario classique et redoutablement efficace : un compte d’agent compromis, vraisemblablement par ingénierie sociale (hameçonnage, leurre, récupération d’identifiants), sert de point d’entrée. À partir de là, l’attaquant ne « casse » rien : il utilise la plateforme comme l’utiliserait l’agent légitime, en parcourant méthodiquement les espaces accessibles.

C’est le principe de l’account takeover : la sécurité périmétrique la plus avancée ne sert à rien si l’identité d’un utilisateur autorisé est détournée. Le système se comporte alors normalement, parce que, de son point de vue, c’est un usage normal.

L’auteur revendique en outre avoir amplifié cet accès en exploitant des faiblesses fonctionnelles : un annuaire utilisateur interrogeable sans limitation de débit, des endpoints de téléchargement de fichiers insuffisamment protégés et des mécanismes permettant d’énumérer les comptes. Ces points ne sont pas confirmés à ce stade, mais ils décrivent un schéma classique : une fois à l’intérieur, l’attaquant industrialise la collecte là où le contrôle d’accès est trop permissif. Le moissonnage massif n’est possible que parce que le périmètre interne fait trop confiance à un compte authentifié.

Deux conséquences en découlent :

  1. Le contrôle d’accès devient le vrai périmètre. Dans un environnement collaboratif, ce qui protège l’information n’est pas seulement le chiffrement, mais la discipline d’accès : qui peut entrer dans quel salon, et avec quelles garanties d’authentification.
  2. Le contenu mal placé devient le point faible. Si des éléments sensibles (y compris des documents estampillés « Diffusion restreinte ») circulent dans des salons trop ouverts, ils héritent du niveau de protection le plus faible de l’espace où ils ont été déposés, pas du niveau qu’ils mériteraient.

La leçon pour les organisations

Au-delà du cas Tchap, l’incident illustre une vérité valable pour toute messagerie d’entreprise, souveraine ou non, chiffrée ou non : Slack, Teams, Mattermost, Element et les autres partagent le même modèle de risque. Le chiffrement protège le transport et le stockage, pas l’usage d’un compte légitime détourné, ni le contenu déposé au mauvais endroit.

La bonne question n’est donc pas « ma messagerie est-elle chiffrée ? », mais « qui peut lire quoi, et que se passe-t-il si l’un de ces comptes est compromis ? ».

Actions concrètes pour les décideurs IT et RSSI

Les priorités à court terme :

  • Renforcer l’authentification avec un facteur résistant à l’hameçonnage (clés FIDO2/passkeys plutôt que codes SMS ou OTP, contournables par ingénierie sociale).
  • Appliquer le moindre privilège aux salons : limiter le nombre d’espaces réellement « ouverts », cloisonner par périmètre métier, et auditer régulièrement qui a accès à quoi.
  • Classer et router l’information : interdire le dépôt de données sensibles ou classifiées dans des salons collaboratifs ouverts, et prévoir des canaux dédiés, restreints et chiffrés pour ces contenus.
  • Détecter les usages anormaux : journaliser les accès, surveiller les comportements atypiques (consultation massive de salons, export de fichiers, connexion depuis un terminal ou une géographie inhabituelle) et savoir désactiver un compte rapidement, comme cela aurait été fait ici.
  • Sensibiliser les agents : la porte d’entrée reste l’humain. Des campagnes régulières contre l’hameçonnage et un réflexe de signalement réduisent fortement la probabilité d’un compte compromis.

À moyen terme, intégrer ces principes dans la gouvernance : politique de classification des données, revue périodique des accès, plan de réponse aux compromissions de comptes et exercices de crise. La technologie souveraine est un atout, mais elle ne dispense pas d’une hygiène d’accès rigoureuse.

En résumé

La fuite revendiquée sur Tchap, si elle se confirme dans son ampleur, ne sera pas l’histoire d’un chiffrement vaincu, mais celle d’un compte de confiance détourné dans un environnement où trop d’information sensible circulait, peut-être, dans des espaces trop ouverts. C’est une leçon transposable à toutes les organisations : la sécurité d’une messagerie ne vaut que celle de ses comptes et de sa discipline d’accès. Le chiffrement est nécessaire ; il n’est jamais suffisant.

Concepts & Notions

Notions essentielles abordées

Chiffrement de bout en bout (E2EE)

Technique où seuls les terminaux des participants détiennent les clés de déchiffrement. Le serveur ne voit jamais le contenu en clair, mais ne protège que les échanges réellement chiffrés, pas les salons publics.

Matrix

Protocole ouvert de messagerie décentralisée sur lequel repose Tchap. Les serveurs (homeservers) peuvent être hébergés en propre, ici en France et par ministère.

Olm / Megolm

Bibliothèques cryptographiques de l'écosystème Matrix assurant le chiffrement de bout en bout des conversations, respectivement en tête-à-tête et en groupe.

Usurpation de compte (account takeover)

Prise de contrôle d'un compte légitime par un attaquant. Le système se comporte normalement, car il ne distingue pas l'usurpateur de l'utilisateur autorisé.

Ingénierie sociale

Manipulation d'une personne pour lui soutirer des identifiants ou un accès. Vecteur d'entrée présumé de l'incident Tchap, via un hameçonnage ou un leurre.

Hameçonnage (phishing)

Tentative de tromper une cible pour récupérer ses identifiants ou l'inciter à une action. Première cause de compromission de comptes en entreprise.

Lire l'article →

Homologation ANSSI

Validation par l'agence nationale de la sécurité des systèmes d'information du niveau de sécurité d'un outil pour un usage donné. Tchap est homologuée pour les agents publics.

Diffusion restreinte

Mention de protection française pour des informations sensibles mais non classifiées. Leur présence dans des salons ouverts illustre le risque d'une information mal cloisonnée.

Moindre privilège

Principe consistant à n'accorder à chaque compte que les accès strictement nécessaires, afin de limiter l'impact d'une compromission.

MFA résistant à l'hameçonnage

Authentification multifacteur fondée sur des clés FIDO2 ou passkeys, non contournables par un faux site, contrairement aux codes SMS ou OTP.

📚 Sources et références