Politique de confidentialité

Dernière mise à jour : 23 septembre 2026.

1. Qui est responsable de vos données

Vous pouvez nous écrire pour toute question de confidentialité à angel@engravitysigns.com.

Le service est exploité par cette même entité depuis un serveur qui lui appartient, et l'application s'appelle T-kall (identifiant com.bitali.tkall).

2. L'essentiel, dans un tableau

Le chiffrement de bout en bout signifie que le contenu est chiffré sur votre appareil et n'est déchiffré que sur celui de l'autre personne. Nous ne transportons que des enveloppes scellées. La garantie complète est assurée par l'application installée ; dans le navigateur, le programme qui chiffre se télécharge de notre serveur à chaque chargement (voir Sécurité). Mais tout ne tient pas dans l'enveloppe, et c'est ce que presque aucune politique de confidentialité ne raconte :

3. Quelles données sont collectées exactement

3.1. Données du compte

• Votre adresse e-mail principale (c'est votre identifiant de connexion).
• Le nom sous lequel les autres vous voient.
• Un hachage Argon2id de votre mot de passe. Le mot de passe en clair n'est jamais conservé.
• L'organisation à laquelle vous appartenez et la date de création du compte.

3.2. Données de profil demandées à l'inscription

• Date de naissance et âge (l'application exige d'avoir 13 ans révolus).
• Une localisation approximative du type « ville, pays », facultative.

Ces trois champs sont conservés chiffrés dans la base de données (AES-256-GCM). Il faut bien comprendre ce que cela protège et ce que cela ne protège pas : cela protège contre une fuite de la base de données, car quiconque l'emporte ne verra qu'un texte opaque. Cela ne protège pas contre nous : la clé se trouve sur le serveur et nous pouvons les déchiffrer. C'est différent du chiffrement des messages, dont nous n'avons pas la clé.

La localisation n'est pas du GPS. L'application ne demande pas la permission de localisation. Ce qu'elle fait, c'est vous suggérer un texte à partir du fuseau horaire et de la langue déjà configurés sur le téléphone ; ce calcul se fait sur votre appareil et vous pouvez le corriger ou le laisser vide.

3.3. Votre identité étendue

• Jusqu'à trois adresses e-mail et deux numéros de téléphone associés au compte.
• Si chacun est le principal, s'il est vérifié et à quel de vos profils il se rattache (« Personnel », « Travail »…).
• Lorsque vous demandez à vérifier une adresse e-mail, un hachage du code que nous vous envoyons (il se colle dans l'application et expire au bout de 30 minutes) et sa date d'expiration. Le code lui-même n'est pas conservé.
• Si vous demandez à réinitialiser le mot de passe, un hachage du jeton contenu dans le lien, son expiration (une heure) et la date à laquelle il a cessé d'être valable, que ce soit parce que vous l'avez utilisé ou parce que vous en avez demandé un nouveau (chaque demande annule les précédents). Le jeton lui-même n'est pas conservé ; et un jeton annulé n'est pas supprimé, il est marqué, pour pouvoir vous dire « il ne fonctionne plus » sans révéler s'il a existé.

Les adresses e-mail et les numéros de téléphone ne sont pas chiffrés, et ce n'est pas un oubli : c'est le moyen par lequel une autre personne vous trouve. S'ils étaient chiffrés, personne ne pourrait vous rechercher par ce biais.

3.4. Vos appareils

• Le nom que vous donnez à chacun (« Pixel 10 », « Chrome sous Windows »).
• Leurs clés publiques de chiffrement et de signature. Les clés privées ne quittent jamais l'appareil et nous ne les avons pas.
• L'identifiant de notifications (le « token » Firebase), si vous activez les notifications.
• Dates de création, d'approbation, de révocation et de dernière connexion.

3.5. Vos conversations

• L'enveloppe chiffrée de chaque message. C'est un bloc opaque : nous ne pouvons pas en lire le contenu, ni y faire de recherche, ni le remettre lisible à qui que ce soit.
• Les métadonnées de chaque message : dans quelle conversation il se trouve, qui l'a écrit, quand, s'il répond à un autre et s'il a été modifié ou supprimé.
• Un identifiant aléatoire que votre propre téléphone invente pour chaque message, afin qu'un renvoi après une coupure réseau ne le duplique pas. Il est différent pour chaque message et n'identifie pas l'appareil.
• Le repère indiquant jusqu'où vous avez lu dans chaque conversation.
• Les vidéos et les fichiers que vous joignez (documents, PDF, archives compressées…), qui par leur taille ne tiennent pas dans le message. Ils sont chiffrés sur votre appareil et téléversés vers un stockage de fichiers du même serveur, comme un bloc d'octets sans nom. La clé pour l'ouvrir voyage à l'intérieur du message chiffré, de sorte que nous ne pouvons pas le voir. Du fichier, nous ne conservons pas qui l'a téléversé, ni pour qui il est, ni son nom, ni son type : seulement sa taille et la date. La seule chose consignée par compte, c'est combien d'octets vous avez téléversés sur une fenêtre de 24 heures, pour freiner les abus : un compteur distinct de la base de données (dans Redis, qui écrit bel et bien sur le disque), conservé uniquement avec l'identifiant interne du compte et qui expire tout seul 24 heures après le premier téléversement de cette fenêtre.

Les images et les notes vocales que vous envoyez voyagent à l'intérieur du message chiffré lui-même ; celles-là ne sont téléversées vers aucun stockage à part. Les vidéos et les autres fichiers joints, si, pour la raison ci-dessus, et le fichier est supprimé tout seul lors du balayage quotidien qui suit l'échéance des 30 jours depuis son téléversement —entre 30 et 31 jours—, que vous l'ayez supprimé avant ou non. La copie que l'autre personne a déjà téléchargée sur son téléphone lui appartient et nous n'y touchons pas.

3.6. Vos rendez-vous

• Le type (appel, appel vidéo ou message programmé), l'heure en UTC et la durée.
• Qui vous avez invité (l'adresse e-mail ou le numéro) et s'il a accepté.
• Le titre et les notes, chiffrés sur votre appareil (seuls les invités les ouvrent ; nous n'avons pas la clé), ainsi que les clés enveloppées pour chaque appareil invité.
• Un hachage du lien d'accès au rendez-vous, jamais le lien en clair.
• Si le rendez-vous est un appel vidéo, l'identifiant de la salle vidéo créée pour lui au moment de le programmer (point 3.11). Cet appel vidéo passe par le serveur de salles (point 6.2) même si vous n'êtes que deux, et une fois le rendez-vous annulé plus personne ne peut entrer dans sa salle (qui s'y trouvait déjà n'en est pas expulsé). Le titre du rendez-vous n'est pas envoyé à ce serveur : il reste chiffré.

3.7. Votre carnet de contacts

• Le nom que vous donnez à chaque contact et les notes que vous écrivez à son sujet.
• Les adresses e-mail et numéros de téléphone que vous notez pour cette personne, qui peut ne pas avoir de compte T-kall.
• Les demandes de contact envoyées et reçues, avec leur statut et leurs dates.

Les notes sont conservées chiffrées dans la base de données (AES-256-GCM), comme les données de profil du point 3.2 et avec les deux mêmes faces : elles protègent contre une fuite de la base, mais pas contre nous, car la clé se trouve sur le serveur et le serveur les déchiffre chaque fois que vous ouvrez le carnet de contacts. Ce n'est pas le chiffrement sur votre appareil dont bénéficient les messages ni les notes d'un rendez-vous.

Le reste —le nom que vous donnez à chaque contact, ses adresses e-mail et numéros de téléphone, et les demandes— est conservé en clair sur le serveur. Et attention à ce que cela implique : en notant quelqu'un dans votre carnet de contacts, vous nous donnez ses coordonnées. Ne notez que des personnes qui pourraient raisonnablement s'attendre à y figurer.

L'application ne lit pas le carnet d'adresses du téléphone. Elle ne demande pas cette permission à Android et ne téléverse aucune liste de contacts : chaque contact, c'est vous qui le saisissez à la main.

3.8. Équipes, canaux et organisations

• Les équipes, canaux et organisations auxquels vous appartenez et avec quel rôle.
• Les codes d'invitation émis et combien de fois ils ont été utilisés.

3.9. Modération

• Qui vous avez bloqué et qui vous a bloqué.
• Les signalements que vous déposez ou que vous recevez, avec le motif que vous écrivez. Ce motif est conservé chiffré dans la base de données avec une clé qui nous appartient, comme les notes de votre carnet de contacts (point 3.7) : il protège contre une fuite, pas contre nous, car c'est une requête qui nous est adressée et un opérateur la déchiffre pour l'examiner. De chaque signalement, nous conservons aussi son statut, s'il a été marqué comme prioritaire, qui l'a traité, quand et avec quelle décision. Si un compte est sanctionné, il est consigné depuis quand, jusqu'à quand, avec quelle portée, avec un code de motif et à quel signalement cela se rattache. Il n'y a pas de panneau à l'intérieur de l'application : c'est une personne ayant accès au serveur qui l'examine. Cela n'inclut pas le contenu des messages signalés, qui reste illisible pour nous. Et une précision qui compte : ces fiches ne sont pas supprimées avec le compte (point 8), afin que se désinscrire ne soit pas le moyen d'échapper à un examen.

3.10. Données techniques

• Votre adresse IP, tant que vous êtes connecté. Elle sert à la limitation du débit de requêtes (éviter les attaques par force brute et les abus) et est consignée dans les journaux du serveur web.
• Votre session : nous conservons le hachage du jeton de renouvellement (jamais le jeton) et, pour chaque appareil ayant une session ouverte, la clé publique avec laquelle cet appareil signe ses requêtes et son empreinte, une étiquette du navigateur ou du système (« Chrome sous Android »), dans quel type de stockage vit sa clé privée (logiciel ou matériel de l'appareil), à quel appareil de votre identité de chiffrement et à quel jeton de renouvellement elle est liée, ainsi que les dates de création, de dernière utilisation, d'expiration (30 jours depuis la dernière utilisation), de fermeture et, si la clé a été renouvelée, quand.
• Journaux de fonctionnement du serveur. Ils sont écrits pour ne pas contenir d'adresses e-mail complètes (elles sont masquées en j***@ejemplo.com) ni d'identifiants de conversation.

Conservation de ces journaux : ils ne sont pas archivés. Chaque service du serveur principal conserve au plus 50 Mo de journal —cinq fichiers de 10 Mo— et le plus ancien est écarté tout seul à mesure qu'arrive le nouveau. Il n'y a ni copie ni archive historique en dehors de cette rotation. La durée que couvre cette fenêtre dépend du trafic, donc nous ne vous donnons pas un nombre de jours : il serait inventé. Le serveur de salles, qui est une autre machine (point 6.2), tient ses propres journaux et n'entre pas dans cette rotation : leur durée de conservation est au point 8.

3.11. Réunions par lien et salles des rendez-vous vidéo

• Chaque fois que vous créez une réunion avec « Réunion instantanée » ou que vous programmez un rendez-vous vidéo, une fiche de cette salle est conservée avec : qui l'a créée (l'identifiant interne de votre compte) ; un hachage du lien, jamais le lien en clair (pour un rendez-vous, le lien ne sert même pas : on en génère un au hasard et on le jette) ; quand elle a été créée ; quand elle expire —au bout de 30 jours pour « Réunion instantanée » ; pour un rendez-vous, deux heures après l'heure à laquelle il se termine— ; et, si elle a été fermée avant, quand : parce que l'hôte a révoqué le lien ou parce que le rendez-vous a été annulé.
• La base de données ne conserve ni qui est entré ni quand (les journaux du serveur de salles peuvent l'avoir : point 8), ni le nom que vous donnez à la réunion : ce nom ne passe que par le serveur de salles (point 6.2). Qui attend dans la salle d'attente est tenu dans la mémoire du serveur le temps de l'attente, et qui l'hôte a expulsé, jusqu'à ce que le lien soit révoqué, que le rendez-vous soit annulé ou que le serveur redémarre ; rien de tout cela n'est écrit dans la base de données.

Ces fiches, aujourd'hui, ne sont pas supprimées, pas même à la suppression du compte : la durée de conservation est au point 8.

4. Ce que nous ne collectons PAS

• Il n'y a pas de publicité ni de profilage publicitaire.
• Il n'y a pas d'analytique : ni Google Analytics, ni Firebase Analytics, ni Crashlytics, ni aucun SDK de mesure à l'intérieur de l'application.
• Nous n'utilisons pas l'identifiant publicitaire d'Android.
• Nous ne lisons pas le carnet de contacts du téléphone.
• Nous ne demandons pas la permission de localisation ni ne collectons votre position GPS.
• Nous ne vendons, ne louons ni ne cédons de données à des tiers à des fins commerciales.
• Ce site web n'a ni cookies ni analytique. La page d'accueil charge ses polices de caractères depuis Google Fonts, de sorte qu'en l'ouvrant, votre navigateur demande ces fichiers à Google, qui voit votre adresse IP ; cette page, Sécurité et Supprimer le compte ne chargent rien depuis d'autres domaines.

5. À quoi elles servent

• Fournir le service : remettre les messages, établir les appels, avertir des rendez-vous, gérer les équipes.
• Vous identifier : vous connecter et permettre que vous trouvent ceux qui ont votre adresse e-mail ou votre numéro.
• Sécurité : limitation du débit de requêtes, détection de vol de sessions, approbation des nouveaux appareils.
• Modération : traiter les signalements et les blocages.
• Obligations légales, lorsqu'elles existent.

Nous n'utilisons pas vos données pour entraîner des modèles, ni pour la publicité, ni pour aucune finalité autre que faire fonctionner l'application.

6. Avec qui elles sont partagées

Voici tous les tiers qui interviennent aujourd'hui. Si un jour il y en a un de plus, il apparaîtra dans cette liste avant d'être activé.

6.1. Google — notifications push (Firebase Cloud Messaging)

C'est ce qui permet à l'application de vous avertir écran éteint. Firebase n'est pas une enveloppe scellée : Google voit ce qu'on lui envoie. C'est pourquoi la notification que nous lui remettons provient d'une liste fermée et courte de textes fixes, dont aucun ne nomme qui que ce soit.

Google reçoit :

• l'identifiant de notification de votre appareil (l'adresse de l'enveloppe) ;
• l'instant de l'envoi ;
• la catégorie de notification, parmi une liste fermée de six valeurs (message, rendez-vous, invitation à un rendez-vous, réponse à un rendez-vous, ajout de contact, appel) ;
• le texte qui va vous être montré, qui est l'un de sept textes fixes et sans rien d'interpolé à l'intérieur : « Vous avez un nouveau message », « Vous avez une invitation à un rendez-vous », « On a répondu à votre invitation à un rendez-vous », « Quelqu'un de votre carnet de contacts est déjà sur T-kall » et, pour le rappel d'un rendez-vous, « Votre rendez-vous commence tout de suite », « … dans moins de 10 min » ou « … bientôt ». Le titre est toujours « T-kall ». Pour un appel, aucun texte ne circule : Google reçoit seulement « c'est un appel » et l'avis « Appel entrant », c'est votre propre téléphone qui l'écrit ;
• si la notification est urgente ou non (les appels sont marqués urgents pour qu'ils sonnent même si le mobile est en veille) ;
• l'adresse IP avec laquelle votre téléphone communique avec les serveurs de Google.

Google ne reçoit pas :

• le contenu d'aucun message (nous ne l'avons pas nous-mêmes) ;
• le nom ni l'identifiant de qui vous écrit ou vous appelle ;
• l'identifiant de la conversation, de l'appel ni du rendez-vous ;
• le titre du rendez-vous ;
• l'heure exacte du rendez-vous : le rappel indique la tranche en gros et non les minutes qui restent, précisément pour que deux notifications de la même minute ne trahissent pas que deux personnes vont au même rendez-vous.

Sur l'écran de verrouillage, vous voyez l'un de ces sept textes —ou « Appel entrant », que compose votre téléphone— ; qui vous a écrit n'apparaît qu'à l'ouverture de l'application, une fois déchiffré.

Si vous ne voulez pas de notifications, Google ne sait pas que vous existez. Tant que vous n'acceptez pas les notifications, l'application n'enregistre pas votre téléphone auprès de Firebase : le composant de Google est fourni à l'intérieur de l'application et se charge avec elle, mais il démarre éteint et ne va pas jusqu'à demander un identifiant ni à se connecter. Il ne s'allume —et Google ne reçoit qu'alors un identifiant d'installation de l'application et l'adresse IP depuis laquelle elle se connecte— qu'au moment exact où vous acceptez de recevoir des notifications.

Si vous les refusez puis changez d'avis, il s'allume à ce moment-là. Et si vous vous déconnectez, il s'éteint de nouveau et l'identifiant est supprimé sur les serveurs de Google, pas seulement sur les nôtres.

Une précision honnête, parce que la différence compte : si vous aviez déjà accepté les notifications avant cette version, votre téléphone est déjà enregistré et le restera —c'est justement ce qui fait que les notifications continuent de vous parvenir sans avoir à accepter quoi que ce soit à nouveau—. Pour défaire cela, déconnectez-vous dans l'application : le plus souvent, cela suffit. Nous disons « le plus souvent » car il y a une faille réelle : si vous vous déconnectez sans que l'application ait eu le temps de mettre en marche les notifications après une mise à jour —par exemple, si vous l'avez ouverte hors connexion—, la radiation chez Google peut ne pas se faire. Se reconnecter avec les notifications en état de marche puis se déconnecter à nouveau règle le problème.

6.2. Serveurs d'appels (STUN, TURN et salles), qui nous appartiennent

Pour établir un appel, chaque appareil doit découvrir sa propre adresse publique sur internet, et pour cela il interroge un serveur STUN. Ce serveur est le nôtre. Jusqu'en juillet 2026, on utilisait le serveur public de Google, qui voyait l'adresse IP de votre appareil à chaque appel ; il a été changé précisément pour que cela cesse de se produire.

Lorsque les deux réseaux ne permettent pas une connexion directe, l'appel passe en plus par un serveur de relais (TURN), lui aussi le nôtre, qui relaie le trafic déjà chiffré : il déplace des paquets qu'il ne peut pas déchiffrer. Il voit les adresses IP des deux extrémités et la durée du relais.

Ce que ce changement ne résout pas, et qu'il faut savoir : votre appareil doit résoudre par DNS le nom de notre serveur d'appels, de sorte que celui qui vous fournit le DNS —votre opérateur, en général— peut déduire que vous allez appeler, mais pas avec qui. Et les notifications continuent de trahir le moment d'un appel par l'autre porte (point 6.1).

Le serveur de salles. Quand un appel ne va pas d'un appareil à l'autre, c'est un serveur de salles, lui aussi le nôtre, qui le rassemble et le redistribue (le programme est LiveKit, à code source ouvert). Passent par lui les appels de groupe d'un canal, le bouton d'appel de groupe d'une discussion, les réunions lancées avec « Réunion instantanée » et les rendez-vous vidéo ; ces deux derniers, toujours, même si vous n'êtes que deux dans la réunion. Les appels à deux passés avec les boutons d'appel et d'appel vidéo d'une discussion ne passent pas par lui. Et une différence qui compte : le serveur de salles est une autre machine, distincte de celle du reste du service, et elle se trouve aux États-Unis (points 6.3 et 7).

Ce que ce serveur voit de chaque appel qui passe par lui :

• qui vous êtes dans la salle : l'identifiant interne de votre compte et votre nom affiché ;
• votre adresse IP et celle de chaque participant ;
• dans quelle salle vous entrez, par son nom technique : l'identifiant du canal ou de la réunion, pas le nom du canal ;
• quand chacun entre et quand il sort ;
• ce que chacun publie —micro, caméra ou partage d'écran— et s'il l'a coupé (quand l'hôte d'une réunion coupe le micro de quelqu'un, il le fait par l'intermédiaire de ce serveur) ;
• des données techniques sur votre connexion : la version du logiciel d'appel qu'utilise l'application, le navigateur ou le système depuis lequel vous vous connectez —ce que votre navigateur dit à n'importe quel serveur web— et, si l'appareil l'indique, le type de réseau (wifi ou données mobiles) ;
• si la version de l'application de chaque appareil sait chiffrer l'appel sur l'appareil (chaque appareil l'annonce pour que la salle sache si elle peut être chiffrée), et les avis techniques « je n'arrive pas à te déchiffrer » que les appareils s'envoient entre eux ;
• le nom de la réunion, si l'hôte lui en donne un en la créant avec « Réunion instantanée ». Ce nom est distribué aux autres par le canal de données de la salle, qui n'est pas chiffré sur votre appareil —seuls l'audio et la vidéo le sont—, de sorte que le serveur de salles peut le lire. Nous ne le conservons pas dans la base de données. Si le nom est délicat, ne le mettez pas.

Ce qu'il ne voit pas, ce sont l'audio et la vidéo, qui sont chiffrés sur votre appareil (SFrame) tant que tous les présents utilisent une version qui le prend en charge. Si quelqu'un entre avec une version ancienne, cet appel bascule vers un chiffrement jusqu'au serveur tant que cette personne est présente —l'application le signale dans la salle—, et pendant ce temps le serveur de salles pourrait bel et bien les voir et les entendre. Aucun appel n'est enregistré : ni l'application ni notre serveur ne demandent jamais d'enregistrement —ils n'ont pas cette fonction—, et la permission avec laquelle on entre dans une salle ne l'inclut pas.

Notre serveur principal a un avis du serveur de salles tout prêt pour remettre dehors, d'une réunion par lien, quiconque l'hôte a expulsé, mais aujourd'hui cet avis n'est pas activé. S'il est activé, ce sera écrit ici avant. Et il vaut mieux savoir dès maintenant comment il fonctionnerait : le serveur de salles signalerait ce qui se passe dans toutes les salles —qui entre et qui sort, et dans laquelle, y compris celles d'un canal—, et notre serveur ne s'en servirait que pour remettre dehors une personne expulsée ; il écarterait le reste sans le conserver.

Une correction qu'il faut dire telle quelle : jusqu'au 23 septembre 2026, cette page nommait le serveur de salles, mais ne disait pas que c'est une autre machine, ni qu'elle se trouve aux États-Unis, ni ce qu'elle voit ; et le point 7 affirmait que tout se trouvait sur une seule machine, ce qui n'était pas vrai.

6.3. Hébergement

• Ce site web est hébergé chez Hostinger. Il sert des fichiers statiques ; ses journaux d'accès incluent des adresses IP, comme tout serveur web.
• Le serveur de l'application tourne sur un serveur privé (VPS) souscrit chez Hostinger, dans un centre de données de Francfort (Allemagne). C'est là que vivent la base de données et les enveloppes chiffrées. Il n'y a aucun service cloud tiers par le milieu : ni analytique, ni stockage externe, ni intermédiaires qui verraient le trafic.
• Le serveur de salles des appels de groupe, des réunions et des rendez-vous vidéo (point 6.2) tourne sur un autre VPS, lui aussi souscrit chez Hostinger, dans un centre de données de Boston (États-Unis).

6.4. E-mail — Resend

Depuis le 26 août 2026, T-kall envoie des e-mails via Resend (resend.com), depuis no-responder@send.t-kall.com. Resend reçoit l'adresse à laquelle on écrit et le contenu du message, qui ne peut être que l'un de trois : le code pour vérifier une adresse e-mail (il se colle dans l'application ; expire au bout de 30 minutes), le lien pour réinitialiser le mot de passe (expire au bout d'une heure) ou un avis indiquant que quelqu'un a tenté d'ajouter votre adresse à un autre compte. Aucun ne contient de contenu de conversations, et nous ne vous demanderons jamais un mot de passe par e-mail. Le domaine principal t-kall.com continue de n'envoyer ni recevoir de courrier —il déclare qu'aucun serveur n'est autorisé à le faire en son nom— ; l'envoi part de ce sous-domaine dédié.

Une correction qu'il faut dire telle quelle : cette section a annoncé Resend comme « en attente d'être souscrit » jusqu'au 8 septembre 2026, alors qu'il était actif depuis le 26 août. La règle du point 6 —apparaître ici avant d'être activé— n'a pas été respectée cette fois-ci.

6.5. Google Play

Si vous installez l'application depuis Google Play, Google sait que vous l'avez installée, selon ses propres conditions et non les nôtres. Si vous préférez l'éviter, vous pourrez télécharger l'APK directement depuis ce site dès que le téléchargement sera disponible.

6.6. Autorités

Si nous recevons une réquisition légale valable, nous ne pouvons remettre que ce que nous avons : données de compte et métadonnées. Nous ne pouvons pas remettre le contenu des messages ni des appels : aucun appel n'est enregistré, et nous n'avons pas les clés de ce qui est chiffré sur votre appareil. L'exception est celle du point 6.2 : tant qu'un appel de groupe est redescendu d'un niveau, le serveur de salles pourrait le voir et l'entendre, et il peut toujours lire le nom donné à une réunion. Et qu'il soit clair que ne pas pouvoir remettre le contenu ne nous empêche pas de remettre les métadonnées, qui dans bien des cas sont tout aussi révélatrices.

7. Où elles sont conservées

Sur deux machines, toutes deux souscrites chez Hostinger (point 6.3) :

• Le serveur principal, en Allemagne (un centre de données de Francfort). C'est là que se trouvent la base de données, le stockage de fichiers où vont les vidéos et les autres pièces jointes (point 3.5) et les serveurs STUN et TURN des appels à deux (point 6.2).
• Le serveur de salles, aux États-Unis (un centre de données de Boston). Par lui passent les appels de groupe, les réunions « Réunion instantanée » et les rendez-vous vidéo. Il ne conserve ni messages ni fichiers, mais ce qu'il voit de chacun de ces appels (point 6.2) —l'identifiant de votre compte et votre nom affiché, votre adresse IP, dans quelle salle vous entrez, quand vous entrez et sortez, ce que vous publiez et si vous l'avez coupé, les données techniques de votre connexion, et le nom de la réunion, si elle en a un— sort de l'Espace économique européen et est traité aux États-Unis. Les appels à deux passés avec les boutons d'appel et d'appel vidéo d'une discussion ne passent pas par lui.

Les notifications push traversent l'infrastructure de Google, qui est mondiale —ce qui y voyage, c'est la notification, pas le contenu du message, qui est chiffré—.

8. Combien de temps elles sont conservées

• Les messages, 90 jours sur le serveur. Passé ce délai, le serveur les supprime tout seul, que vous les ayez lus ou non. Et une précision que nous disions auparavant à l'envers : depuis le 28 août 2026, l'application conserve bel et bien sur chaque appareil les messages qu'elle a déjà déchiffrés —elle les déchiffre la première fois qu'elle les affiche et, à partir de là, les lit depuis ce stockage, comme le font Signal ou WhatsApp—, enveloppés avec une clé locale que l'application elle-même ne peut pas exporter (une faille de la partie web ne l'emporte pas, même si elle pourrait s'en servir depuis l'intérieur de l'application ; quiconque copie le stockage de l'appareil, oui : voir Sécurité, points 2 et 6), et elle les élague toute seule au démarrage lorsqu'ils sont conservés depuis plus de 400 jours sur cet appareil ou dépassent 20 000 messages. Conséquence : un message que le serveur a déjà supprimé peut subsister sur les appareils qui l'ont affiché jusqu'à cet élagage ; il n'apparaît pas dans l'application, mais il est dans ce stockage. Si quelque chose compte pour vous, conservez-le hors de T-kall : aujourd'hui, l'application ne permet pas d'exporter l'historique.
• Ce qui reste sur votre propre appareil. Se déconnecter ne supprime pas ce stockage ni les clés de chiffrement : ils restent exprès, pour qu'en vous reconnectant vous retrouviez vos messages. Supprimer le compte, lui, l'efface —clés, messages déchiffrés, réglages— sur l'appareil depuis lequel vous le supprimez et dès que le serveur confirme la suppression ; le détail et ses limites sont dans Supprimer votre compte. Sur un ordinateur partagé, la différence compte.
• Les vidéos et les fichiers joints, 30 jours à compter de leur téléversement (point 3.5), supprimés lors du balayage quotidien suivant —entre 30 et 31 jours—. Ce sont des fichiers chiffrés que seul peut ouvrir celui qui a la clé, laquelle voyage à l'intérieur du message. Celui qui l'a reçu et ouvert a déjà sa copie ; passé le délai, ce qui est supprimé, c'est le fichier du serveur.
• Ce que vous ne voyez déjà plus, encore bien moins. Un message que vous supprimez cesse de s'afficher sur-le-champ et son contenu est effacé du serveur sous 7 jours ; de même pour les rendez-vous que vous annulez. Ce que l'appareil de celui qui l'a reçu avait déjà déchiffré reste dans son stockage local jusqu'à l'élagage ci-dessus : supprimer un message le retire de la vue et du serveur, pas des appareils d'autrui. D'une session fermée ou expirée, le jeton de renouvellement est supprimé au bout de 7 jours ; sa fiche (clé publique, étiquette et dates, point 3.10) conserve la date de fermeture —ou, si elle a simplement expiré, celle de l'expiration échue— et est conservée jusqu'à ce que vous supprimiez le compte. De même pour un jeton de récupération de mot de passe utilisé, annulé ou expiré : il est marqué, pas supprimé, jusqu'à ce que vous supprimiez le compte.
• Les rendez-vous passés, 90 jours, comme les messages : le carnet vous laisse les consulter jusque-là.
• Lors de la suppression du compte, l'effacement est immédiat et en une seule opération. Les vidéos et fichiers que vous auriez téléversés sont des fichiers à part et disparaissent du serveur au plus tard au bout de 31 jours ; comme les clés pour les ouvrir se trouvaient dans des messages qui n'existent plus, entre-temps ils ne sont lisibles par personne, pas non plus par nous. Les signalements où vous figurez (point 3.9) sont conservés sans votre compte : ils n'ont aujourd'hui aucun délai de suppression automatique, et une obligation légale peut exiger de les garder au moins un an. Les fiches des réunions et des salles vidéo que vous auriez créées (point 3.11) restent elles aussi, et les journaux du serveur de salles suivent leur propre chemin ; les deux sont expliqués juste en dessous. Plus de détails sur ce qui est supprimé et ce qui ne l'est pas dans Supprimer votre compte.
• Les fiches des réunions par lien et des salles des rendez-vous vidéo (point 3.11) : aujourd'hui, elles ne sont pas supprimées. Elles cessent de servir quand elles expirent, quand elles sont révoquées ou quand le rendez-vous est annulé, mais la fiche —qui l'a créée, le hachage du lien et ses dates— reste dans la base de données, y compris si vous supprimez le compte, parce qu'elle n'y est pas rattachée : elle reste avec l'identifiant d'un compte qui n'existe plus. Ce qui part bien avec le rendez-vous, c'est l'identifiant de sa salle (au bout de 90 jours, ou de 7 s'il a été annulé).
• Les journaux du serveur de salles. Cette machine tient ses propres journaux, qui peuvent contenir ce qu'elle voit de chaque appel (point 6.2) : l'identifiant de votre compte, dans quelle salle vous entrez, votre adresse IP et les heures. Aujourd'hui, aucune durée n'est fixée par configuration pour ces journaux, donc nous ne pouvons pas vous en donner une, et ils ne sont pas supprimés quand vous supprimez votre compte. Quand une durée sera fixée, elle sera écrite ici. D'enregistrements d'appels, il n'y en a pas : aucun appel n'est enregistré.
• Sauvegardes : une copie quotidienne de la base de données, chiffrée avant même de toucher le disque —jamais une copie en clair n'est écrite, pas même temporaire— et supprimée automatiquement au bout de 14 jours. C'est l'un des endroits où vos données peuvent survivre à une suppression de compte —avec ce qu'énumère Supprimer votre compte : les signalements, le registre de transparence des clés, les fichiers joints jusqu'à 30 jours, quelques notes internes qui expirent au plus tard sous 24 heures et les journaux techniques du serveur principal jusqu'à leur rotation ; et avec ce qui est expliqué plus haut : les fiches des réunions et des salles vidéo et les journaux du serveur de salles—, et c'est pourquoi on le dit ici.
• Journaux techniques du serveur principal : ils ne sont pas archivés ; ils tournent par taille, comme expliqué au point 3.10. Ceux du serveur de salles, plus haut.

9. Comment elles sont protégées

• Chiffrement sur votre appareil du contenu des messages et des détails des rendez-vous : le serveur n'a pas les clés.
• TLS obligatoire sur tout le transit ; l'application ne peut pas se connecter sans chiffrer.
• Mots de passe hachés avec Argon2id.
• Données de profil (date de naissance, âge, localisation) et notes du carnet de contacts, chiffrées dans la base de données.
• Sessions à jetons rotatifs : si l'un est réutilisé, toute la famille est révoquée.
• Un nouvel appareil a besoin de l'approbation d'un appareil déjà autorisé avant de recevoir quoi que ce soit.
• La sauvegarde d'Android est désactivée pour que ni les clés ni les messages déjà déchiffrés ne quittent l'appareil.

Les limites de tout cela sont expliquées sans fard dans Sécurité. Lisez-le : cela fait partie de cette politique autant que ce qui précède.

10. Mineurs

T-kall ne s'adresse pas aux moins de 13 ans, et l'inscription rejette les dates de naissance qui donnent un âge inférieur. Si nous détectons le compte d'une personne en dessous de cet âge, il est supprimé.

11. Vos droits

Selon l'endroit où vous vivez, vous pouvez avoir le droit d'accéder à vos données, de les rectifier, de les porter, de les supprimer, d'en limiter le traitement ou de vous y opposer.

• Accès et rectification : la plupart de vos données, vous les voyez et les modifiez dans l'application elle-même (profil, adresses e-mail, numéros de téléphone, appareils, carnet de contacts).
• Suppression : voir Supprimer votre compte, qui inclut la voie pour le demander sans installer l'application.
• Le reste : écrivez-nous à angel@engravitysigns.com.

Vous pouvez aussi réclamer auprès de l'autorité de protection des données compétente pour votre pays de résidence. Si vous nous écrivez d'abord, nous vous disons laquelle c'est et ne vous faisons pas la chercher.

12. Modifications de cette politique

Si nous changeons quelque chose d'important —un nouveau tiers, une nouvelle donnée, quelque chose que l'application se met à conserver—, la date du début est mise à jour. L'application n'a pas de seconde politique : son écran de confidentialité est un résumé qui renvoie à cette même page et qui, s'il diverge en quoi que ce soit, cède devant ce texte. La règle interne que nous suivons est l'inverse de l'habituelle : d'abord on l'écrit ici, ensuite on l'active. Quand cela échoue —le stockage local du 28 août 2026 est resté dix jours sans être déclaré ici, et le serveur de salles aux États-Unis n'a été déclaré comme tel que le 23 septembre 2026 (point 6.2)— on corrige et on le raconte, au lieu de faire comme si de rien n'était.

13. Contact

angel@engravitysigns.com