Partage en équipe chiffré de bout en bout : clés, arrivées, départs

Le partage en équipe chiffré de bout en bout repose sur une seule idée : le contenu est verrouillé par des clés que seuls les appareils de l’équipe détiennent, et le rôle du serveur est de remettre des copies scellées de ces clés aux bonnes personnes sans pouvoir les ouvrir. Tout le reste — inviter quelqu’un, retirer quelqu’un, récupérer un mot de passe perdu — revient à savoir qui scelle une nouvelle copie de quelle clé, et pour qui.

La réponse courte à la question que la plupart des gens se posent vraiment : quand un membre est ajouté, quelqu’un qui possède déjà la clé de canal en scelle une copie pour le nouveau venu. Quand un membre est retiré, le serveur supprime sa copie, et l’appli d’un membre restant génère une nouvelle version de la clé que la personne retirée ne reçoit jamais. Cette seconde étape, appelée rotation des clés, est ce qui distingue un retrait cryptographique du simple masquage d’un dossier dans l’interface.

Cet article présente les concepts au niveau dont a besoin un responsable d’équipe ou un auditeur sécurité. Il prend Speak-Y Teams comme exemple concret, parce que c’est la conception que nous pouvons décrire avec précision, et le compare à d’autres conceptions publiées là où elles diffèrent.

Trois niveaux de clés, et pourquoi trois

Une transcription de réunion partagée dans un espace d’équipe chiffré de bout en bout est protégée par une chaîne de clés plutôt que par un seul mot de passe :

Ces niveaux existent pour que les opérations courantes restent peu coûteuses. Partager un nouvel enregistrement ne touche qu’une clé d’élément. Ajouter un membre revient à sceller une clé de canal pour une personne de plus, sans rechiffrer chaque transcription. Faire tourner une clé de canal après un retrait change une seule clé et réenveloppe les petites clés d’élément situées en dessous, tandis que le volumineux contenu chiffré reste tel quel.

Dans Speak-Y, la paire de clés de membre est dérivée du mot de passe de chiffrement du compte : le même mot de passe produit donc les mêmes clés sur chaque appareil. Les briques de base sont des « sealed boxes » à clé publique standard et du chiffrement authentifié, pas une cryptographie maison.

Schéma des trois niveaux de clés dans Speak-Y Teams : clé d’élément, clé de canal et paire de clés de membre
La clé d’élément est verrouillée avec la clé de canal ; la clé de canal est scellée pour chaque membre avec sa clé publique.

Ce que le serveur stocke et ce qu’il ne peut pas voir

Le serveur est une boîte aux lettres pour du texte chiffré. Il conserve les éléments chiffrés, les copies scellées des clés de canal adressées à chaque membre, et juste assez de structure pour les acheminer.

Il peut voir la structure de l’équipe : combien d’espaces de travail et de canaux existent, qui est membre de quoi, si un canal est public ou privé, quand une clé a été émise ou révoquée, et des métadonnées de base sur chaque élément — taille, durée et horodatage. Il ne peut pas voir le contenu des transcriptions et des comptes rendus, et dans Speak-Y il ne voit pas non plus les noms des espaces de travail et des canaux, qui sont chiffrés avec les mêmes clés que le contenu. Un canal nommé « Acquisition — Projet Faucon » est en soi une information.

Être précis sur les métadonnées fait partie d’une promesse de bout en bout honnête. L’entrée du glossaire sur l’E2EE explique pourquoi aucune conception ne masque tout.

Espace de travail Speak-Y Teams avec le nom de l’espace, un canal public et un canal privé mis en évidence
1 — le nom de l’espace de travail, 2 — un canal public, 3 — un canal privé. Le serveur sait qu’ils existent et qui en est membre ; les noms et le contenu sont chiffrés.

Ce qui se passe quand quelqu’un arrive

La difficulté, quand on ajoute un membre, est que le serveur ne peut pas transmettre une clé qu’il ne peut pas lire. Seul un client qui détient déjà la clé peut en sceller une copie pour la clé publique du nouveau venu, et cette clé publique n’existe qu’une fois l’invitation acceptée.

Il existe deux façons de contourner ce problème. La première consiste à attendre qu’un membre de l’équipe ouvre l’appli et scelle les clés pour le nouveau membre, ce qui fonctionne mais laisse un trou si la personne qui a invité est en vacances. Speak-Y affiche ce trou comme un état à part entière, En attente de la clé du canal, et non comme une erreur réseau.

La seconde consiste à faire porter à l’invitation ce dont le nouveau venu a besoin. Un lien d’invitation Speak-Y contient la clé de l’espace de travail dans le fragment, la partie de l’URL après #, qui n’est jamais envoyée au serveur. Les canaux conservent une copie de leur clé verrouillée sous la clé de l’espace de travail, si bien qu’un nouveau membre peut ouvrir les canaux de l’espace de travail dès qu’il accepte, sans que personne d’autre soit en ligne. La contrepartie est que le lien lui-même donne accès : c’est pourquoi les invitations sont à usage unique, expirent, et doivent être transmises comme on transmettrait un mot de passe.

Les canaux privés ajoutent une règle : la clé de l’espace de travail ne les ouvre pas. Un membre du canal privé y ajoute quelqu’un en scellant directement la clé de ce canal pour cette personne.

Ce qui se passe quand quelqu’un est retiré

C’est là que les conceptions divergent le plus, et que la question « est-ce vraiment de bout en bout ? » reçoit une réponse concrète.

La révocation d’accès signifie que le serveur cesse de fournir des données à la personne retirée. Elle est appliquée par la politique du serveur, et les clés ne changent pas. Le livre blanc sur la sécurité de 1Password décrit ainsi son propre partage, en indiquant clairement que le retrait d’une personne d’un coffre, d’un groupe ou d’une équipe n’est pas appliqué de manière cryptographique et que les clés ne sont pas changées. C’est un compromis documenté et délibéré ; une personne qui aurait conservé la clé auparavant pourrait encore lire des données du coffre obtenues plus tard.

La rotation des clés signifie que la clé de la personne retirée cesse de fonctionner. Dans Speak-Y, quand un membre est retiré d’un espace de travail :

  1. Le serveur supprime immédiatement les copies scellées des clés de cette personne.
  2. L’appli du membre qui effectue le retrait génère de nouvelles versions des clés de canal et de la clé de l’espace de travail, et les scelle uniquement pour les personnes qui restent, ainsi que pour le Recovery Kit de l’espace de travail.
  3. Les noms des canaux et de l’espace de travail sont rechiffrés sous les nouvelles versions.
  4. Les copies des clés de canal verrouillées sous l’ancienne clé de l’espace de travail sont reverrouillées sous la nouvelle, si bien qu’un ancien lien d’invitation n’ouvre plus rien.
  5. Les éléments existants sont réenveloppés vers la nouvelle version de clé en arrière-plan.

Retirer quelqu’un d’un seul canal privé fait tourner la clé de ce canal de la même manière.

Les protocoles de messagerie suivent le même principe. La présentation du chiffrement de WhatsApp (édition de février 2026) indique que, chaque fois qu’un membre quitte un groupe, tous les participants effacent leur clé de groupe et repartent de zéro. La norme Messaging Layer Security de l’IETF, RFC 9420, publiée en juillet 2023, fait passer un groupe à une nouvelle époque lors d’un retrait, avec un nouveau matériel de clé que le membre retiré ne connaît pas.

Comparaison entre la révocation d’accès et la rotation des clés quand un membre de l’équipe est retiré
La révocation est une politique du serveur, les clés ne changent pas ; la rotation émet de nouvelles versions de clé que la personne retirée ne reçoit jamais.

Ce que la rotation ne peut pas reprendre

La rotation protège l’avenir, pas le passé. Tout ce que la personne retirée a déjà ouvert, téléchargé ou copié sur son propre appareil lui reste — aucun schéma de chiffrement ne peut aller fouiller la mémoire de quelqu’un ou son disque. Ce que la rotation garantit est plus restreint, mais reste précieux : les nouveaux enregistrements partagés après le retrait lui sont illisibles, et l’ancienne clé n’ouvre rien de ce qu’elle pourrait récupérer plus tard sur le serveur.

Deux conséquences pour le fonctionnement d’une équipe :

Le guide sur la base de connaissances d’équipe explique comment décider de ce qui va dans quel canal.

Quand quelqu’un oublie son mot de passe

Dans un système où le prestataire ne détient aucune clé, le « mot de passe oublié » ne peut pas être résolu par le support — c’est tout l’intérêt. Il doit être résolu par quelqu’un de l’équipe.

Speak-Y s’en charge avec un Recovery Kit : à la création d’un espace de travail, le propriétaire enregistre un fichier contenant une clé de récupération, et chaque clé de canal est également scellée pour elle. Si un membre perd son mot de passe et en définit un nouveau, le détenteur du Kit peut réémettre les clés de canal vers sa nouvelle paire de clés. Le Kit restaure uniquement l’accès aux canaux d’équipe ; il ne couvre jamais les enregistrements personnels de qui que ce soit. C’est aussi le fichier le plus sensible dont dispose l’équipe, et il doit être rangé là où l’équipe conserve ses autres secrets critiques.

Partager avec quelqu’un d’extérieur à l’équipe

Il arrive qu’une transcription doive parvenir à un client ou à un collègue sans compte. Un lien de partage public Speak-Y chiffre une copie distincte de l’élément avec sa propre clé toute neuve et place cette clé dans le fragment de l’URL. Quiconque possède le lien complet peut lire l’élément dans un navigateur ; le serveur ne détient que du texte chiffré. Révoquer le lien le supprime du serveur. Comme pour une invitation, le secret, c’est le lien, et une copie déjà ouverte par quelqu’un ne peut pas être rappelée.

Quatre questions à poser à tout éditeur

  1. Que deviennent les clés quand un membre est retiré ? « L’accès est révoqué » est une réponse de politique ; « la clé est renouvelée » est une réponse cryptographique.
  2. Le serveur peut-il lire les noms des canaux et des espaces de travail ? Les noms en disent souvent autant que le contenu.
  3. Si un membre oublie son mot de passe, qui peut restaurer l’accès ? Si la réponse est l’éditeur, c’est que l’éditeur détient une clé.
  4. Un lien d’invitation ou de partage contient-il du matériel de clé, et expire-t-il ? Les deux réponses peuvent convenir, pourvu que l’éditeur sache laquelle est la sienne.
Quatre questions à poser à un éditeur sur le partage en équipe chiffré de bout en bout
Les clés au retrait d’un membre, les noms sur le serveur, la récupération du mot de passe, et ce que contient un lien d’invitation.

Dans Speak-Y, le partage en équipe est disponible dans l’application macOS. La création d’un espace de travail commence avec l’offre Pro, et les coéquipiers rejoignent gratuitement, quelle que soit leur offre. La page Speak-Y Teams montre à quoi ressemblent les canaux partagés au quotidien, et pourquoi les notes de réunion ont besoin du chiffrement de bout en bout explique pourquoi la transcription doit se faire sur votre appareil pour que tout cela soit possible.

FAQ

Comment une équipe peut-elle partager des fichiers chiffrés de bout en bout si le serveur ne peut pas les lire ?

Chaque élément partagé est chiffré avec sa propre clé aléatoire, et cette clé est verrouillée par une clé de canal. La clé de canal est ensuite scellée séparément pour chaque membre avec la clé publique de ce membre. Le serveur ne stocke que ces copies scellées : il peut les remettre aux bonnes personnes, mais ne peut en ouvrir aucune.

Que deviennent les clés de chiffrement quand quelqu’un est retiré d’un canal d’équipe ?

Dans une conception qui applique le retrait de manière cryptographique, le serveur supprime la copie de la clé de canal de la personne retirée, et l’appli d’un membre restant génère une nouvelle version de la clé qu’elle scelle uniquement pour les personnes qui restent. Les éléments plus anciens sont ensuite reverrouillés sous la nouvelle version. Speak-Y Teams fonctionne ainsi ; certains produits connus se contentent de révoquer l’accès au serveur et conservent les mêmes clés.

Un membre retiré de l’équipe peut-il encore lire ce qui a été partagé avant ?

Tout ce que la personne a déjà ouvert, téléchargé ou copié lui reste. Aucun schéma de chiffrement ne peut reprendre un texte en clair qui s’est déjà affiché sur l’écran de quelqu’un. La rotation des clés protège ce qui est partagé après le retrait et empêche l’ancienne clé d’ouvrir un contenu récupéré plus tard sur le serveur.

Que se passe-t-il si un membre oublie son mot de passe dans un espace de travail chiffré de bout en bout ?

Le prestataire ne peut pas restaurer l’accès, car il n’a jamais détenu les clés. Speak-Y règle ce cas avec un Recovery Kit : un fichier que le propriétaire de l’espace de travail enregistre à sa création, et qui permet de réémettre les clés de canal pour un membre ayant défini un nouveau mot de passe. Le Kit ne couvre les enregistrements personnels de personne.

Un lien d’invitation vers un espace de travail chiffré est-il sensible ?

Il peut l’être. Dans Speak-Y, le lien d’invitation contient la clé de l’espace de travail dans la partie de l’URL située après le #, que les navigateurs et les applis n’envoient jamais au serveur. Les invitations sont à usage unique et expirent, et le retrait d’un membre entraîne la rotation de la clé de l’espace de travail, mais tant qu’il n’a pas servi, le lien doit être traité comme un mot de passe.