Introduction
Tchap, la messagerie instantanée développée par la Direction interministérielle du numérique (DINUM), reposait sur une promesse sérieuse : offrir aux agents publics français un canal de communication souverain, audité par l'ANSSI, fondé sur le protocole ouvert Matrix avec chiffrement de bout en bout. En septembre 2025, son déploiement avait été généralisé à l'ensemble de l'administration centrale. Pourtant, début juin 2026, un attaquant a exfiltré les données de 73 467 comptes — soit environ 9 % de la base utilisateurs — sans jamais avoir à toucher au chiffrement.
Le protocole sécurisé contourné sans être attaqué
L'attaquant n'a pas cherché à casser la cryptographie. Il a eu recours à l'ingénierie sociale pour compromettre un compte utilisateur légitime, obtenant ainsi un accès authentifié à la plateforme. Une fois à l'intérieur, le vol s'est opéré depuis les salons publics de Tchap, qui, contrairement aux conversations privées, ne bénéficient pas du chiffrement de bout en bout. Résultat : près de 650 000 messages, les noms, adresses e-mail, affiliations organisationnelles et métadonnées de 73 467 agents ont été exfiltrés, accompagnés de 13,5 Go de documents et fichiers partagés dans ces espaces ouverts.
L'incident révèle une vulnérabilité supplémentaire, indépendante de l'attaque initiale : des identifiants LDAP retrouvés en clair dans un script PowerShell partagé dans un salon public. Ces credentials, déposés apparemment par un responsable informatique d'un service régional, constituaient une porte d'entrée exploitable directement, sans aucune sophistication technique.
L'ANSSI a détecté l'intrusion le 7 juin. La DINUM a immédiatement bloqué le compte compromis et notifié la CNIL. Les conversations privées chiffrées sont restées inaccessibles à l'attaquant. Mais les dégâts sur les données publiques étaient consommés.
L'écart entre architecture sécurisée et déploiement réel
Tchap illustre un problème structurel bien connu des équipes de sécurité, mais encore trop souvent négligé lors des déploiements à grande échelle : la robustesse de l'architecture ne garantit pas la sécurité des usages. Les concepteurs avaient correctement fait leur travail — protocole ouvert et auditable, chiffrement fort pour les échanges privés, infrastructure hébergée sur cloud souverain. Mais la plateforme a été déployée auprès de populations très hétérogènes, sans que les comportements de sécurité soient homogènes : sensibilisation insuffisante au phishing et à la manipulation sociale, mauvaise gestion des secrets dans les scripts partagés, données sensibles déposées dans des salons publics non chiffrés faute de distinction claire entre les deux types d'espaces.
Confondre la certification d'un produit avec la sécurité de son déploiement est une erreur que ne font pas que les administrations publiques.
Trois leviers que l'incident Tchap remet en avant
Pour toute organisation déployant une messagerie collaborative — souveraine, SaaS ou on-premise — l'affaire Tchap pointe trois impératifs opérationnels :
- Sécurisation des comptes et des accès : un seul compte compromis a suffi à ouvrir la brèche. L'authentification multifacteur robuste et la détection comportementale des connexions anormales ne sont pas des options.
- Gestion rigoureuse des secrets : des identifiants dans un script partagé via un salon de messagerie constituent une faute de sécurité élémentaire. Les politiques de secrets management doivent couvrir tous les canaux internes, y compris les outils collaboratifs.
- Classification des espaces de communication : tous les canaux d'une même plateforme n'offrent pas les mêmes garanties de confidentialité. Sensibiliser les utilisateurs à cette distinction — et restreindre ce qui peut être partagé dans des salons publics — est indispensable dès le déploiement initial.
La souveraineté technique est une condition nécessaire, pas suffisante. Ce qui s'est produit avec Tchap peut frapper n'importe quelle organisation qui sous-estime le facteur humain face à une architecture pourtant bien conçue.