Politique de confidentialité

Ce que Messagr ne vous demande pas, ce que le service ne peut pas lire, et ce que le serveur voit malgré tout.

Version du 26 septembre 2026

Cette version s'est appliquée jusqu'au 30 septembre 2026, où la version en vigueur l'a remplacée.

Qui traite vos données

Messagr est exploité par RV Myriagone Holding, dont le siège est au 22 rue de la Garenne, 78130 Chapet, société à responsabilité limitée à associé unique au capital de 5 087 000 euros, immatriculée au registre du commerce et des sociétés de Versailles sous le numéro 894 754 548, représentée par son gérant Michel-Marie Maudet.

RV Myriagone Holding est le responsable de ce traitement au sens du règlement (UE) 2016/679. Point de contact : conformite@messagr.eu.

Ce que Messagr ne vous demande pas

Un compte Messagr ne porte aucune donnée d'identification que vous auriez fournie, parce qu'aucune ne vous est demandée :

pas de numéro de téléphone ;
pas d'adresse électronique ;
pas de nom sur votre compte, réel ou déclaré ;
pas de carnet d'adresses, ni de contacts lus sur votre appareil.

L'identifiant de votre compte est tiré au hasard au moment où vous entrez. Il n'est rattaché à rien d'autre que lui-même.

Une invitation peut porter un nom, et c'est le seul qui quitte votre téléphone. La personne qui vous invite peut choisir de se présenter par un nom, librement et sans y être tenue. Ce nom voyage dans le lien lui-même, dans la partie qu'un navigateur ne transmet jamais : nos serveurs ne le reçoivent pas, ne l'enregistrent pas et ne peuvent pas le lire. Il n'est attaché à aucun compte, et Messagr ne l'enregistre nulle part, ni sur nos serveurs ni sur votre téléphone : il reste seulement, avec le lien, dans le message qui l'a apporté. L'écran qui le montre dit « Se présente comme » : c'est le nom que la personne se donne, pas un nom que Messagr connaît.

Demander une invitation depuis ce site ne demande rien non plus : ni adresse, ni nom, ni message. La page vous rend un code, vous le gardez, et c'est avec lui que vous revenez chercher la réponse. Rien d'autre ne vous y identifie, et la personne qui répond ne sait pas qui a demandé. Ces demandes sont effacées au bout de trente jours.

Ce que le service ne peut pas lire

Le contenu de vos conversations est chiffré de bout en bout : il est chiffré sur l'appareil qui l'écrit et déchiffré sur celui qui le lit. Les clés ne quittent jamais les appareils.

Ce n'est pas une promesse de notre part, c'est une propriété du chiffrement. Le serveur ne détient pas les clés : il ne peut pas lire vos messages, pas davantage sur réquisition que de sa propre initiative, et nous ne pourrions pas les produire si on nous les demandait.

Ce que le serveur voit malgré tout

Le chiffrement protège le contenu, pas son existence. Faire circuler un message suppose de savoir où l'envoyer, et le serveur conserve donc :

les identifiants pseudonymes des comptes ;
l'appartenance aux conversations — donc qui échange avec qui ;
la date et l'heure de chaque événement ;
la liste des appareils d'un compte et leurs clés publiques ;
la taille approximative de ce qui transite ;
quand un compte est en appel : pour chaque appel, l'application demande au serveur l'accès au relais qui achemine le son et l'image ; ce relais voit l'adresse IP des téléphones qui s'en servent, jamais le contenu de l'appel ;
les adresses IP au moment des requêtes, dans les journaux techniques.

Ces métadonnées sont nécessaires au fonctionnement d'une messagerie. Nous ne les enrichissons pas, nous ne les croisons avec rien, et elles ne servent à aucun autre usage que l'acheminement.

Ce qui reste sur votre appareil

vos clés cryptographiques, dans un magasin chiffré par une phrase de passe aléatoire tirée sur l'appareil et gardée dans le trousseau du système d'exploitation ;
votre session, dans ce même trousseau ;
quelques lignes dans le journal du système de l'appareil, limitées aux appels, aux réveils par notification, à l'enregistrement des notifications, à l'offre de sauvegarde et aux sauvegardes qui n'ont pas pu être activées. Elles ne portent ni contenu ni identifiant, et l'application ne les envoie nulle part ;
rien d'autre. Les messages déchiffrés ne sont pas écrits sur le disque : la conversation est reconstruite à chaque ouverture depuis le chiffré, puis oubliée.

Aucune mesure d'audience

L'application ne contient aucun outil de mesure, aucun traceur, aucune bibliothèque tierce d'analyse, aucune publicité. Rien n'est envoyé à un tiers pour observer votre usage.

Elle contient une bibliothèque tierce, et elle ne sert qu'à une chose : recevoir le signal qui réveille votre téléphone quand un message arrive. La section suivante dit exactement ce qui traverse.

Il n'y a ni profilage ni décision automatisée. Les décisions de modération sont prises par des personnes, comme l'expliquent les conditions générales.

Les notifications, et ce que Google en apprend

Pour qu'un message vous parvienne quand l'application est fermée, votre téléphone doit être réveillé par le système de notifications de son fabricant. Sur Android c'est Firebase Cloud Messaging, de Google. Aucune application ne peut s'en passer sur cette plateforme.

Ce qui traverse Google ne contient ni expéditeur, ni conversation, ni message. Le signal envoyé porte l'identifiant technique de votre appareil, une priorité de remise, et un nombre tiré au hasard. Pas d'identifiant de salon, pas d'aperçu, pas de compteur, pas de nom. C'est une passerelle écrite pour cela, et le contenu est déchiffré par votre appareil, chez vous, après le réveil.

Le nombre tiré au hasard mérite une phrase, parce qu'il occupe un champ dont le nom prête à confusion. Le système de notification refuse d'acheminer un signal entièrement vide : il lui faut au moins un identifiant. Nous lui en donnons donc un, tiré au hasard à chaque envoi, sans aucun rapport avec le message. Il ne désigne rien, votre appareil l'ignore, et deux envois n'ont jamais le même.

Ce que Google détient donc, c'est un jeton d'appareil et le fait que quelque chose est arrivé à un moment donné. Le jeton est un identifiant d'installation, renouvelé par Google, conservé tant que l'application est installée.

Le réveil d'un iPhone passe par Apple, et Google reçoit tout de même un jeton. La notification part de notre serveur vers celui d'Apple, directement. Mais l'application embarque la bibliothèque de Firebase, la même que sur Android, et cette bibliothèque s'enregistre d'elle-même : à la première ouverture, elle envoie à Google un identifiant d'installation et le jeton qu'Apple vient de donner à votre téléphone. Nous ne le lui demandons pas et nous n'en faisons rien ; elle le fait parce qu'elle est là.

Cette page disait auparavant que sur iOS ce rôle était tenu par le service de notifications d'Apple, sans plus. C'était incomplet. La correction ne change rien à ce que fait l'application : elle décrit ce qu'elle faisait déjà. Retirer cette bibliothèque du paquet iPhone, où elle ne sert qu'à demander le jeton d'Apple, est en cours.

Sur iPhone, une phrase en plus, et toujours la même. Apple ne garantit pas qu'un réveil silencieux arrive : il peut être différé, ou abandonné, et votre téléphone n'afficherait alors rien du tout. Le signal envoyé à Apple porte donc une phrase écrite d'avance, « Quelque chose est arrivé. », pour qu'il reste quelque chose à voir quand le réveil n'a pas eu lieu. Elle ne nomme ni votre correspondant, ni votre conversation, ni vous, et elle n'est pas écrite d'après votre message : c'est la même pour tout le monde, à chaque envoi.

Cette phrase existe dans les sept langues de l'application, et c'est votre téléphone qui dit laquelle il lit, une fois, en s'enregistrant. Apple voit donc laquelle des sept vous est envoyée, c'est-à-dire la langue que vous lisez — qu'un appareil Apple lui a apprise bien avant nous. C'est la même valeur à chaque envoi, jamais liée à un message ni à un correspondant. Sur Android, rien de tout cela ne traverse Google : le réveil silencieux y fonctionne, et c'est votre téléphone qui écrit la notification, après l'avoir déchiffrée.

Les notifications se désactivent dans les réglages de l'application. Le réglage retire l'enregistrement auprès du serveur : celui-ci n'a alors plus où envoyer, et plus rien ne part.

Où vos données sont traitées

Le serveur est hébergé par Hetzner Online GmbH, à Helsinki, en Finlande, au sein de l'Union européenne.

Une exception : le signal qui réveille votre téléphone, décrit plus haut, passe par Firebase Cloud Messaging (Google) sur Android et par le service de notifications d'Apple sur iOS. Ces services peuvent le traiter hors de l'Union. Il ne porte que l'identifiant technique de votre appareil, une priorité de remise et un nombre tiré au hasard — et, sur iPhone seulement, la phrase écrite d'avance décrite plus haut.

Sur quelle base

Le traitement repose sur l'exécution du contrat qui nous lie lorsque vous utilisez le service (article 6.1.b du règlement), et sur nos obligations légales pour ce qui touche à la modération et aux signalements.

Combien de temps

Les journaux techniques, douze mois. Cette durée n'est pas un choix : le décret n° 2021-1362 l'impose aux fournisseurs d'hébergement pour les données permettant d'identifier la source d'une connexion, dont les adresses IP. Passé ce délai, elles sont effacées. En revanche, le lien d'invitation n'y est pas écrit : quand vous ouvrez une invitation dans un navigateur, le serveur note la date, l'adresse IP, le résultat et le navigateur, et « /i/... » à la place du lien.

Les données d'identité civile, sans objet. La loi en prévoit la conservation pendant cinq ans. Messagr n'en collecte aucune, donc il n'y a rien à conserver.

Les métadonnées d'une conversation vivent aussi longtemps que le compte. À la suppression d'un compte, il est désactivé immédiatement et ses données sont purgées sous trente jours.

Le contenu chiffré vit aussi longtemps que la conversation. Le serveur ne peut pas le trier, puisqu'il ne peut pas le lire : il disparaît avec le salon qui le portait.

Le lien entre celui qui invite et celui qui entre est effacé trente jours après que l'invitation a été dépensée. Pendant ce délai, il permet de révoquer une branche d'invitation entière, capacité que les conditions générales annoncent ; passé ce délai, le lien n'existe plus et cette révocation n'est plus possible. Un lien gelé par un signalement en cours fait exception : il est conservé tant que l'examen dure. Une invitation non dépensée, elle, expire d'elle-même et ne vaut alors plus rien.

Ce que l'effacement peut, et ce qu'il ne peut pas

Une conversation Matrix ne s'efface pas comme un enregistrement dans une base. Le protocole ajoute des événements sans jamais en retirer. Supprimer un message le vide de son contenu et laisse une trace de son passage ; supprimer un compte le désactive et empêche toute réutilisation de son identifiant, mais les événements qu'il a produits restent des événements du salon.

Nous le disons parce que promettre un effacement que le protocole ne permet pas serait plus grave que de reconnaître cette limite. Elle vaut pour tous les services bâtis sur Matrix, et elle est le revers de la propriété qui protège vos messages : un serveur qui ne peut pas lire ne peut pas trier non plus.

Vos droits

Vous disposez des droits d'accès, de rectification, d'effacement, de limitation, d'opposition et de portabilité. Écrivez à conformite@messagr.eu.

Une limite qu'il faut connaître avant de nous écrire. Nous ne pouvons pas vous restituer le contenu de vos messages, parce que nous ne l'avons jamais eu en clair. Une demande d'accès ou de portabilité portera sur les métadonnées décrites plus haut, et sur elles seules. Le contenu, lui, est déjà chez vous.

Vous pouvez introduire une réclamation auprès de la Commission nationale de l'informatique et des libertés, cnil.fr.

Âge minimum

L'âge minimum est de quinze ans en France. Entre quinze ans et la majorité, l'usage relève des règles décrites dans les conditions générales.

Modifications

Toute modification de cette politique est publiée sur cette page, avec la date de version en tête. Nous ne modifions pas rétroactivement ce que le service fait de vos données : un changement est annoncé avant d'être appliqué.