Sécurité : ce qu'elle protège et ce qu'elle ne protège pas
Dernière révision : 23 septembre 2026.
Une application qui dit « chiffrement de bout en bout » sans dire où s'arrête ce chiffrement vend une garantie qu'elle ne peut pas tenir. À commencer par ceci : la garantie complète, c'est l'application installée qui la donne ; dans le navigateur, le programme qui chiffre se télécharge de notre serveur à chaque chargement. Cette page existe pour que vous décidiez quoi raconter sur T-kall en sachant ce qu'il en est.
Ce qu'elle protège vraiment
- Le contenu de vos messages. Il est chiffré sur votre appareil et déchiffré sur celui de l'autre personne. Le serveur conserve des enveloppes scellées et n'a pas les clés pour les ouvrir.
- Le titre et les notes de vos rendez-vous. Un agenda en dit énormément sur une personne (« réunion avec l'avocat »), c'est pourquoi ils sont eux aussi chiffrés. Le prix : le rappel de 15 minutes ne peut pas vous dire de quel rendez-vous il s'agit.
- Les appels entre DEUX personnes. Ceux qui se passent avec les boutons d'appel et d'appel vidéo d'une discussion : l'audio et la vidéo circulent chiffrés (DTLS-SRTP) directement entre les deux appareils tant que le réseau le permet. Quand il ne le permet pas, un serveur de relais fait passer le trafic déjà chiffré : il relaie sans pouvoir écouter. Attention : un rendez-vous vidéo, une réunion lancée avec « Réunion instantanée » et le bouton d'appel de groupe d'une discussion passent toujours par le serveur de salles, même si vous n'êtes que deux : du point de vue de la sécurité, ce sont des appels de groupe. Les appels de groupe sont eux aussi chiffrés sur votre appareil depuis la version 0.4.0, avec une nuance et quelques données que ce serveur voit bel et bien, le tout dans sa propre section (point 8).
- Les mots de passe. Ils sont stockés sous forme de hachage Argon2id, jamais en clair. Nous ne pouvons pas les lire, nous non plus.
-
Le transit. Tout passe par TLS. L'application est compilée de façon à ne
pouvoir parler en
http://avec personne : si on la pointait vers un serveur sans chiffrement, elle cesserait de fonctionner au lieu d'envoyer les messages en clair sans prévenir. - Qu'on ne vous glisse pas un faux appareil. Chaque compte publie une liste signée de ses appareils, et ces listes entrent dans un registre où l'on peut seulement ajouter. Votre appareil exige la preuve que la liste de votre contact figure dans ce registre et surveille aussi la vôtre : si quelqu'un publiait une liste à votre nom que vous n'avez pas signée, votre propre téléphone le détecte. Les messages portent en eux quelle version du registre a vue celui qui écrit, si bien que deux personnes qui se parlent la comparent sans le vouloir. Depuis août 2026 ; la limite qui subsiste est au point 1 ci-dessous.
- Les clés privées ne sortent pas de l'appareil. La sauvegarde d'Android est désactivée à dessein, pour qu'elles ne finissent pas envoyées vers le cloud de Google.
Ce qu'elle ne protège pas (encore)
1. Le registre de clés, c'est nous qui le publions
Jusqu'en août 2026, on disait ici que le premier contact avec une nouvelle personne ne pouvait pas être vérifié, et que le régler était « un gros chantier ». Ce chantier est fait et ce qu'il apporte est raconté plus haut. Ce qui reste ouvert est plus petit, mais ce n'est pas zéro.
Ce registre n'empêche pas l'attaque : il la rend détectable. Un serveur malveillant peut publier une fausse clé ; ce qu'il ne peut plus faire, c'est le faire en secret, car cela l'oblige à publier deux versions incompatibles de la même histoire, et cela se voit. C'est le même marché qui soutient les certificats de tout le web depuis une décennie.
Et c'est notre propre serveur qui le publie. Tant que les racines du registre ne sont pas copiées dans un lieu indépendant, celui qui les vérifie et celui qui les émet sont la même maison. Détecter la contradiction continue de fonctionner entre deux personnes qui se parlent — cela ne dépend pas de nous —, mais la vérification par des tiers n'existe pas encore.
Ce qui le règle : publier les racines à l'extérieur, là où n'importe qui peut les auditer sans avoir de compte. En attendant, comparer le numéro de sécurité par un autre canal reste la vérification la plus solide qui existe, car c'est la seule qui ne repose pas sur notre infrastructure.
2. Les discussions changent de clé à chaque message ; se remettre d'un vol, pas encore
Chaque message de discussion circule avec sa propre clé, dérivée d'un nouvel accord par message (X3DH, le même premier pas qu'utilise Signal). Cela couvre une attaque précise, et il convient de dire exactement laquelle, et laquelle non :
- Chaque message a sa propre clé, et la précédente est détruite. Celui qui conserve aujourd'hui vos messages chiffrés — une copie de la base de données, un vidage de trafic — et obtient des mois plus tard la clé de votre appareil n'ouvre rien de ce qui précède avec cette clé (ce qu'il emporterait, en revanche, c'est ce qui reste dans le stockage local de l'appareil — le texte déjà déchiffré et un second cache avec la clé de chaque message, avec le même plafond — : c'est le point ci-dessous). Avec une nuance qu'il faut dire : cet effacement est immédiat tant qu'il reste des prekeys à usage unique, et si le lot s'épuise on retombe sur la prekey signée, où la protection n'arrive qu'à sa rotation — jusqu'à 37 jours plus tard.
Et ce qui reste non couvert, et qui compte tout autant :
- La conversation ne se soigne pas toute seule. Si quelqu'un parvient à voler la clé d'un appareil, elle lui sert encore : aucun échange propre ne vient l'invalider. Le double cliquet qui règle cela est programmé et l'application sait lire ce qu'il émet, mais il est éteint aujourd'hui : lorsqu'une session se désynchronisait, elle laissait des paires de messages illisibles pour toujours, et une perte de données permanente est pire que la fenêtre qu'il refermait. Il sera allumé quand la récupération de session sera faite et revue. Cette page a fini par dire que c'était déjà résolu : ce fut vrai quelques semaines d'août 2026 et a cessé de l'être quand on l'a éteint. On le corrige ici plutôt que de le laisser promis.
- Si on vous prend le téléphone, ce qui est récent reste exposé — et c'est désormais le texte. Depuis le 28 août 2026, l'application garde bel et bien sur le téléphone les messages déjà déchiffrés — déchiffrer la première fois qu'ils s'affichent et lire à partir de là, comme Signal ou WhatsApp — au lieu de redéchiffrer le fil entier chaque fois que vous ouvrez une discussion. C'est enveloppé dans une clé locale qui ne peut pas être exportée de l'appareil : qui copie le stockage sans la clé ne lit rien, et une faille de la partie web ne peut pas non plus copier la clé — ce que cette faille pourrait faire, en revanche, c'est l'utiliser depuis l'intérieur de l'application et lire le texte stocké, message par message. Cela reste limité à 400 jours ou 20 000 messages (comptés depuis que cet appareil l'a stocké, et élagués au démarrage) ; mais qui emporte l'appareil déverrouillé et vide son stockage emporte le texte, et pas seulement les clés pour l'obtenir. Un mot de passe local qui le chiffrerait au repos est en attente. Rien de tout cela ne protège de qui tient votre téléphone en main.
- Les rendez-vous, non. Le titre et les notes d'un rendez-vous restent sur l'ancien schéma : ils sont chiffrés aujourd'hui pour être livrés des semaines plus tard, et cette avance ne cadre pas avec un schéma qui change de clé à chaque pas. Traitez-les comme le maillon le plus faible.
- Seulement si les deux personnes ont mis à jour. Si celui qui écrit — ou l'un quelconque des appareils qui reçoivent — a une version antérieure, ce message circule avec l'ancienne protection. L'application le signale par un avertissement ambre (« Envoyé sans confidentialité persistante (format ancien) ») quand quelqu'un qui vous écrivait déjà avec la nouvelle protection recommence sans elle — y compris sur vos propres messages —, sauf si ce message porte déjà un avertissement rouge, qui prime ; si cette personne n'a jamais mis à jour, il n'y a rien à quoi comparer et aucun avertissement n'apparaît.
La moitié de cette section — que chaque message porte sa clé — est faite et en usage. L'autre moitié — que la conversation se remette d'un vol — exige le cliquet allumé, et l'allumer exige d'abord la récupération de session : c'est le plus gros chantier en attente de cette page. Et aucune des deux ne touche au point 1 — le premier contact — : elles servent à protéger une conversation, non à vous prouver avec qui vous l'avez.
3. Le serveur voit tout ce qui n'est pas chiffré
Ce qui suit ne voyage pas chiffré, et le serveur le voit en entier :
- qui parle avec qui, et quand ;
- à quelle heure a lieu chaque rendez-vous et combien de temps il dure, et qui est invité à quoi ;
- les e-mails et téléphones de tous les comptes (ce sont l'identité : ils doivent être en clair pour qu'on puisse vous trouver) ;
- l'appartenance aux équipes, canaux et organisations ;
- dans les appels de groupe, les réunions et les rendez-vous vidéo, qui entre dans chaque salle, quand il entre et sort, et le nom de la réunion si on lui en a donné un (le serveur de salles le voit : point 8) ;
- les adresses IP de chaque connexion.
Ce sont là les métadonnées, et pour beaucoup de gens elles sont plus révélatrices que le contenu : que deux personnes se parlent chaque jour à trois heures du matin en dit long sans lire un seul mot. Signal s'attaque à cela avec des techniques que nous n'avons pas encore.
4. Il n'y a pas de sauvegarde, à dessein
Les clés privées ne vivent que sur l'appareil et la sauvegarde d'Android est désactivée. Le prix, il faut le dire avant et non après : en changeant de téléphone ou en réinstallant, on perd l'historique et les clés. Il n'y a aucun moyen de le récupérer.
La bonne alternative, c'est une copie chiffrée avec une clé que vous seul détenez, comme la sauvegarde chiffrée de WhatsApp. Elle n'est pas faite.
5. L'application est un web dans un conteneur
T-kall s'exécute dans le WebView du système, ce n'est pas un client natif. La sécurité du chiffrement dépend donc de la sécurité de ce WebView, que met à jour Google et non nous. C'est atténué (pas de trafic en clair, pas de sauvegardes, avec une politique de contenus), mais c'est une surface d'attaque que Signal ou Threema n'ont pas, parce que leurs clients sont natifs.
6. Le verrouillage par empreinte protège moins qu'il n'y paraît
Le verrouillage biométrique empêche que quelqu'un qui prend votre téléphone déverrouillé ouvre l'application et lise. C'est ce qu'il fait, et c'est bien. Ce qu'il ne fait pas, c'est chiffrer quoi que ce soit : qui a accès au stockage de l'appareil (avec le root, avec un vidage forensique ou avec une faille d'Android) en tire les clés — et, depuis le 28 août 2026, le texte des messages allant jusqu'à 400 jours — sans passer par l'empreinte. C'est une porte, pas un coffre-fort.
8. Les appels de groupe, chiffrés sur votre appareil (avec une nuance)
Un appel entre deux personnes passé avec les boutons d'appel ou d'appel vidéo d'une discussion va directement d'un appareil à l'autre. Un appel de groupe a besoin d'un serveur qui rassemble et redistribue l'audio et la vidéo de tous, et par ce même serveur de salles passent aussi les rendez-vous vidéo et les réunions lancées avec « Réunion instantanée », même si vous n'y êtes que deux. Depuis la version 0.4.0, cet audio et cette vidéo sont chiffrés sur votre appareil (SFrame, avec la distribution des clés par le canal déjà chiffré) et notre serveur de salles se contente de les relayer, sans pouvoir les voir ni les entendre. Cela vaut aussi pour une réunion par lien, même si celui qui rejoint est d'une autre organisation : la clé n'est distribuée qu'entre ceux qui sont dans cette réunion.
La nuance. Un appel n'est chiffré ainsi que lorsque tous les présents utilisent une version récente. Si quelqu'un entre avec une version ancienne, cet appel redescend tout seul à un chiffrement jusqu'au serveur tant que cette personne est là — et l'application vous le dit, avec l'indicateur de la salle — pour ne laisser personne sans voir ni entendre. Tant que le parc se met à jour, cela arrivera souvent ; à mesure que tous mettront à jour, cela cessera d'arriver. Si ce que vous allez raconter ne peut pas passer par notre serveur dans ce cas, utilisez l'appel entre deux avec les boutons d'appel ou d'appel vidéo d'une discussion (celui d'appel de groupe passe par le serveur de salles).
Ce que le serveur de salles voit bel et bien, que l'appel soit chiffré ou non : qui entre (l'identifiant de son compte et son nom affiché), depuis quelle adresse IP, dans quelle salle —par son identifiant technique, pas par le nom du canal—, quand chacun entre et sort, ce que chacun publie (micro, caméra ou partage d'écran) et s'il l'a coupé, des données techniques sur la connexion (la version du logiciel d'appel et le navigateur ou le système depuis lequel il se connecte), si la version de chaque appareil sait chiffrer la salle, et les avis techniques « je n'arrive pas à te déchiffrer » que les appareils s'envoient entre eux. Et le nom de la réunion, si l'hôte lui en donne un dans « Réunion instantanée » : il est distribué par le canal de données de la salle, qui n'est pas chiffré sur l'appareil —seuls l'audio et la vidéo le sont—, de sorte que ce serveur peut le lire. Si le nom est délicat, ne le mettez pas. Le titre d'un rendez-vous vidéo ne passe pas par là : il reste chiffré. Et aucun appel n'est enregistré.
Et où il se trouve. Le serveur de salles est une autre machine, distincte de celle qui conserve les messages, souscrite chez Hostinger dans un centre de données aux États-Unis. Ce qu'il voit de chaque appel sort donc de l'Espace économique européen (Confidentialité, points 6.2 et 7).
9. Personne de l'extérieur ne l'a audité
Toute l'analyse de sécurité de T-kall, c'est nous qui l'avons faite. Signal, WhatsApp, Threema et Wire ont des audits externes publiés et des protocoles revus par le monde universitaire pendant des années. Une faille cryptographique ne se remarque pas à l'usage : l'application marche parfaitement et les messages se lisent pareil. C'est pourquoi une revue interne, aussi soigneuse soit-elle, ne remplace pas une revue externe.
Résumé
| Limite | Gravité aujourd'hui | Ce qui la refermerait |
|---|---|---|
| Le registre de clés est publié par notre serveur : personne de l'extérieur ne l'audite | Moyenne | Publier les racines dans un lieu indépendant |
| Sans récupération après une compromission : la clé volée d'un appareil sert encore | Moyenne | Allumer le double cliquet, qui exige d'abord la récupération de session |
| Les rendez-vous ne changent pas de clé à chaque envoi (les messages, si) | Moyenne | Refaire le chiffrement des rendez-vous, qui aujourd'hui s'anticipe de plusieurs semaines |
| Qui emporte l'appareil lit ce qui est récent, et depuis le 28-08-2026 c'est le texte déjà déchiffré, pas seulement les clés (400 jours / 20 000 messages) | Moyenne | Un mot de passe local qui chiffre le stockage au repos, ou réduire cette limite |
| Métadonnées en clair | Moyenne | Expéditeur scellé et contacts chiffrés |
| Sans sauvegarde | Moyenne (utilisabilité) | Sauvegarde chiffrée avec la clé de l'utilisateur |
| Le WebView comme frontière | Moyenne | Client natif |
| La biométrie n'est pas du chiffrement | Faible | Clés liées au stockage sécurisé du système |
| Un appel de groupe avec quelqu'un en version ancienne redescend à un chiffrement jusqu'au serveur (l'application prévient) | Moyenne | Mettre à jour tout le parc (OTA 0.4.0) pour qu'aucun appel n'ait à redescendre ; l'avertissement apparaît déjà |
| Le nom que l'hôte donne à une réunion est visible par le serveur de salles, qui se trouve aux États-Unis : le canal de données de la salle n'est pas chiffré sur l'appareil | Faible | Chiffrer ce nom avec la clé de la salle quand tout l'appel est chiffré sur l'appareil ; en attendant, ne pas lui donner de nom délicat |
| Sans audit externe | — | En commander un |
Ce que vous pouvez faire, vous
- Comparez le numéro de sécurité d'une nouvelle conversation par un autre canal avant de raconter quoi que ce soit de délicat. C'est la seule chose qui referme aujourd'hui le point 1.
- Comparez le code de l'appel à voix haute en commençant. Si vous lisez tous les deux le même, personne n'est au milieu.
- Passez en revue vos appareils de temps en temps et révoquez ceux que vous ne reconnaissez pas. Un nouvel appareil a besoin du feu vert d'un appareil déjà approuvé.
- Considérez l'historique comme perdu quand vous changez de téléphone : aujourd'hui il n'y a pas de restauration.
Si votre vie en dépend
Si vous êtes journaliste, militant ou toute personne ayant un adversaire capable et doté de moyens, utilisez une application avec des audits externes publiés. Signal est la recommandation honnête pour ce cas. Que, depuis août 2026, les discussions changent de clé à chaque message ne change pas cette recommandation, et le registre de clés d'août ne la change pas non plus. Et il convient de comprendre pourquoi : ce registre fait qu'une fausse clé laisse une trace, mais c'est notre propre serveur qui le publie et personne de l'extérieur ne l'audite, de sorte que la garantie continue de reposer sur nous. À cela s'ajoute que personne de l'extérieur n'a audité ce code : que l'algorithme soit le bon ne prouve pas qu'il soit bien implémenté, et cette différence est justement celle que paie un audit. Aucune de ces limites n'empêche d'utiliser T-kall ; toutes changent ce pour quoi il convient de l'utiliser.
Signaler une faille
Si vous trouvez un problème de sécurité, prévenez-nous avant de le rendre public et cela nous laisse le temps de le corriger : angel@engravitysigns.com. Écrivez « Faille de sécurité » dans l'objet.
Nous n'avons ni programme de récompenses ni accord de divulgation à vous offrir, et nous préférons le dire plutôt que de laisser entendre le contraire. Ce que nous faisons, en revanche : répondre, corriger, et vous donner le crédit que vous voulez — ou aucun, si vous le préférez ainsi.