La plupart des applications de messagerie semblent simples à utiliser. Vous ouvrez une conversation, sélectionnez une personne et envoyez un message. Pourtant, derrière cette simplicité, les messageries peuvent reposer sur des architectures très différentes.

Certaines fonctionnent comme des environnements contrôlés, dans lesquels les communications restent au sein d'un seul système. D'autres permettent à des serveurs exploités de manière indépendante, à des bots externes, à des applications tierces, à des clients développés par des tiers ou même à d'autres services de messagerie de se connecter.

Ces connexions peuvent apporter des fonctionnalités utiles. Elles peuvent permettre l'automatisation, les applications personnalisées, les outils professionnels et la communication entre différentes plateformes. Mais chaque nouvelle connexion crée aussi une nouvelle voie d'accès au système de communication, qu'il faut à son tour protéger.

Dans notre article précédent, nous avons examiné comment une recherche limitée des utilisateurs les protège des contacts indésirables. Ici, nous abordons un autre aspect de la confidentialité : les systèmes extérieurs qu'une messagerie autorise à se connecter.

Qu'est-ce qu'une messagerie à architecture ouverte ?

Dans cet article, nous entendons par « messagerie à architecture ouverte » une messagerie qui permet à des systèmes externes de se connecter à son environnement de communication.

• Selon la plateforme, cela peut inclure :
• des serveurs exploités par d'autres organisations ;
• des bots créés par des développeurs externes ;
• des applications de messagerie personnalisées ou tierces ;
• des passerelles reliant différentes plateformes ;
• des outils professionnels et des services automatisés ;
• la communication directe avec d'autres messageries.

Toutes les messageries ouvertes ne proposent pas l'ensemble de ces fonctionnalités. Chaque plateforme décide quelles parties de son système ouvrir et ce que les développeurs ou services externes sont autorisés à faire.

Une messagerie à architecture fermée adopte une autre approche. Les communications essentielles restent dans un écosystème contrôlé, au moyen d'applications approuvées et d'un même ensemble de règles de communication. La différence tient au contrôle.

Dans un environnement ouvert, une partie du processus de communication peut dépendre de logiciels, de serveurs, de développeurs ou d'entreprises qui échappent au contrôle direct du fournisseur de la messagerie. Dans un environnement fermé, moins d'acteurs extérieurs peuvent intervenir dans ce processus.

Chaque connexion supplémentaire ouvre une nouvelle porte

Toute messagerie en ligne a besoin d'une connexion contrôlée entre son application officielle et son système de communication. Sans elle, les utilisateurs ne pourraient ni se connecter à leur compte, ni envoyer des messages, ni partager des fichiers, ni passer des appels.

La question de sécurité est donc de savoir combien de portes publiques supplémentaires la messagerie ouvre aux systèmes extérieurs. L'une de ces portes les plus courantes est l'interface de programmation d'application (API). Une API est un ensemble de règles permettant à un logiciel de communiquer avec un autre.

Une messagerie peut proposer une API pour permettre à un développeur externe de créer un bot, de concevoir une application personnalisée, de connecter un système d'assistance client ou d'automatiser certaines actions.

Une API n'est pas automatiquement une faille de sécurité. Mais elle constitue un point d'entrée supplémentaire qui nécessite :

• des identifiants d'accès sécurisés ;
• des limites d'autorisation clairement définies ;
• une protection contre les abus automatisés ;
• une surveillance des activités suspectes ;
• des mises à jour de sécurité régulières ;
• un moyen de révoquer rapidement les accès.

Les professionnels de la cybersécurité appellent « surface d'attaque » l'ensemble des points par lesquels une personne peut interagir avec un système. Plus un système possède de points de connexion publics, plus les attaquants disposent d'endroits où rechercher des contrôles d'accès insuffisants, des erreurs de programmation, des identifiants volés ou des autorisations mal configurées. (NIST Computer Security Resource Center)

La porte en elle-même n'est pas l'exploitation d'une faille.

La serrure défectueuse est la vulnérabilité. La méthode employée pour la forcer ou la contourner est l'exploit.

Il en découle un principe simple : impossible de crocheter la serrure d'une porte publique qui n'existe pas.

Chaque connexion facultative qui n'est pas créée supprime un ensemble supplémentaire d'identifiants, d'autorisations, de logiciels externes et de règles de sécurité auxquels il aurait autrement fallu faire confiance et qu'il aurait fallu protéger.

Fédération : lorsque des serveurs externes se connectent

La fédération permet à des serveurs exploités indépendamment les uns des autres de communiquer entre eux. Le courrier électronique en est un exemple familier. Un utilisateur de Gmail peut envoyer un e-mail à un utilisateur d'Outlook, même si Google et Microsoft exploitent des systèmes différents.

Une messagerie fédérée peut fonctionner de la même manière. Une organisation exploite son propre serveur de discussion, une autre exploite un serveur différent, et les deux échangent des messages grâce à un système technique commun.

Cela offre davantage d'indépendance aux organisations. Elles peuvent exploiter leurs propres serveurs tout en communiquant avec un réseau plus large. Mais cela signifie également que chaque serveur connecté doit traiter des informations provenant de systèmes qu'il ne contrôle pas.

Ces serveurs externes peuvent utiliser des logiciels obsolètes, appliquer les mises à jour tardivement, disposer de paramètres de sécurité moins rigoureux ou traiter les informations différemment. Un serveur peut aussi être compromis ou exploité par une personne cherchant délibérément à nuire à d'autres parties du réseau.

Ce qui s'est passé sur Matrix

Matrix est un réseau de messagerie ouvert qui permet aux particuliers et aux organisations d'exploiter des serveurs de discussion distincts, tout en communiquant avec des utilisateurs hébergés sur d'autres serveurs Matrix.

En 2025, une vulnérabilité grave a été découverte dans Synapse, un logiciel serveur largement utilisé sur Matrix. Un serveur connecté malveillant pouvait envoyer des données spécialement conçues pour empêcher un serveur vulnérable de communiquer correctement avec le reste du réseau.

L'avis officiel de sécurité a confirmé que cette vulnérabilité avait été exploitée lors d'attaques réelles. Il précisait également que les systèmes sans fédération publique, ainsi que les fédérations fermées composées uniquement de serveurs de confiance, n'étaient pas concernés.

La faiblesse était directement liée à la fédération. Le serveur vulnérable devait accepter et traiter des données provenant d'un autre serveur contrôlé de manière indépendante. Sans cette connexion publique entre serveurs, cette voie d'attaque particulière n'aurait pas existé.

API et bots : lorsque des logiciels externes interviennent

Les API permettent à des logiciels externes d'effectuer certaines actions au sein d'une messagerie. Les bots en sont un exemple courant : il s'agit de comptes automatisés contrôlés par des logiciels. Ils peuvent répondre aux questions, assurer une assistance client, envoyer des rappels, traiter des paiements, gérer des groupes ou diffuser des informations.

Mais chaque bot fait également intervenir un opérateur externe et, dans bien des cas, un serveur externe. La messagerie doit alors avoir confiance dans le fait que :

• le développeur du bot protège ses identifiants d'accès ;
• le bot ne demande que les autorisations dont il a besoin ;
• le serveur du développeur est sécurisé ;
• le bot ne collecte pas d'informations de manière irresponsable ;
• l'automatisation n'est pas utilisée pour le spam ou la fraude.

Si le jeton d'accès d'un bot est volé, un attaquant peut être en mesure de le contrôler. Si le serveur du développeur est compromis, l'attaquant peut récupérer la connexion légitime du bot à la messagerie. L'automatisation peut aussi amplifier les abus. Une personne peut envoyer des messages malveillants un par un. Un logiciel peut en générer et en diffuser en continu.

Applications de messagerie tierces

Certaines plateformes autorisent également des développeurs externes à créer leurs propres applications connectées à la messagerie. Ces applications peuvent se connecter au véritable réseau de messagerie, mais elles restent des logiciels développés par des personnes extérieures au fournisseur principal.

C'est important, car le chiffrement protège un message pendant son transport. L'application doit néanmoins accéder au message lisible sur l'appareil de l'utilisateur avant son chiffrement et après son déchiffrement. Un client tiers peut donc manipuler :

• les identifiants du compte ;
• les sessions de connexion ;
• les messages ;
• les fichiers téléchargés ;
• les coordonnées des contacts ;
• l'historique local des messages ;
• les clés de chiffrement ou d'autres données sensibles du compte.

Les utilisateurs ne font donc plus confiance uniquement à la messagerie. Ils doivent également faire confiance au développeur externe qui a créé l'application.

Même si le système de communication principal reste protégé, un client mal conçu ou malveillant peut exposer des informations directement sur l'appareil. Pour une messagerie axée sur la communication privée, contrôler les logiciels autorisés à se connecter est donc aussi important que protéger la connexion elle-même.

Interopérabilité : lorsque différentes messageries communiquent entre elles

L'interopérabilité permet aux utilisateurs de services de messagerie distincts de communiquer directement. Par exemple, une personne utilisant une messagerie peut envoyer un message à quelqu'un qui en utilise une autre, sans que l'une ou l'autre ait à changer d'application.

Du point de vue de l'utilisateur, cela peut ressembler à une conversation ordinaire. Sur le plan technique, deux systèmes différents interviennent pourtant. Les services doivent coordonner :

• les identités des utilisateurs ;
• la livraison des messages ;
• le chiffrement ;
• les fichiers et les contenus multimédias ;
• l'appartenance aux groupes ;
• le blocage ;
• les signalements de spam ;
• les messages éphémères ;
• les différences entre paramètres de confidentialité.

Chaque messagerie peut disposer de ses propres applications, serveurs, procédures de sécurité, calendriers de mise à jour et règles de traitement des données utilisateur. Aucun fournisseur ne contrôle donc plus l'intégralité du parcours de communication.

Pourquoi Zangi maintient les communications privées dans un environnement fermé

Chez Zangi, nous avons fait un choix architectural délibéré. Nous ne concevons pas notre messagerie privée principale comme une plateforme publique ouverte aux bots externes, aux clients de messagerie tiers, aux serveurs fédérés ou aux réseaux de messagerie extérieurs. Les utilisateurs de Zangi communiquent dans un environnement contrôlé, au moyen des applications officielles de Zangi. Nous maîtrisons les règles de communication, les logiciels pris en charge et la manière dont les informations circulent dans le système.

Cela supprime plusieurs dépendances extérieures de la communication privée. En l'absence de plateforme publique pour les bots, aucun jeton d'accès public de bot ne peut être volé puis utilisé dans des conversations privées.

En l'absence de plateforme ouverte aux clients tiers, les utilisateurs n'ont pas à faire confiance à un développeur externe pour traiter leurs messages lisibles, leurs sessions de compte ou leurs données de communication locales. Sans fédération publique, Zangi n'a pas à accepter d'instructions de communication ni de données serveur spécialement conçues provenant d'opérateurs inconnus. Sans interopérabilité entre messageries, aucune autre entreprise de messagerie ne participe aux conversations privées des utilisateurs de Zangi.

Cette architecture contrôlée s'inscrit dans le modèle de confidentialité plus large de Zangi. Les communications sont protégées par un chiffrement de bout en bout, les utilisateurs échangent grâce à leur Zangi Private Number et l'historique des communications reste sur leur appareil, au lieu de devenir un historique de conversations stocké durablement sur des serveurs. (Zangi) Certaines plateformes de messagerie sont conçues pour devenir de vastes écosystèmes destinés aux développeurs, aux bots, aux applications personnalisées et aux connexions avec d'autres réseaux.

Zangi est conçu dans un autre but : permettre une communication privée au sein d'une communauté contrôlée. Ce n'est pas une fonctionnalité manquante. C'est l'architecture qui fonctionne exactement comme prévu.

Chaque porte publique facultative que nous choisissons de ne pas ouvrir représente une porte de moins à verrouiller, une clé de moins susceptible d'être volée et un acteur extérieur de moins auquel les utilisateurs doivent faire confiance.