Si vous lisez la page sécurité d’un preneur de notes IA, vous y trouverez un chiffrement AES-256 au repos et TLS en transit. Les deux sont réels, et aucun des deux n’est un chiffrement de bout en bout. Ils protègent les données contre celui qui vole un disque ou écoute sur le réseau. Ils ne les protègent pas du prestataire, puisque c’est lui qui détient la clé.
La réponse courte : au 17 août 2026, les principaux preneurs de notes cloud ne revendiquent pas de chiffrement de bout en bout pour le contenu des réunions, et ce n’est pas un oubli. Un service qui transcrit votre appel et en rédige le compte rendu doit lire cet appel. Les deux choses s’excluent par construction, et c’est pourquoi toutes les grandes plateformes de réunion coupent leurs fonctions IA dès que vous activez un vrai chiffrement de bout en bout.
Reste une décision qui mérite d’être prise délibérément plutôt que par défaut : quelle machine a le droit de voir le texte en clair. Cet article porte sur ce que coûte chaque réponse, et sur la façon de vérifier ce qu’un éditeur a réellement construit.
Trois exemples, tous vérifiés le 17 août 2026 sur les pages des éditeurs eux-mêmes.
Otter documente un chiffrement côté serveur en AES-256 sur AWS S3, et indique chiffrer la clé elle-même avec une clé racine qu’il fait tourner régulièrement. Sa page confidentialité et sécurité ne mentionne nulle part le chiffrement de bout en bout. Sur l’entraînement des modèles, il indique employer une méthode propriétaire pour dépersonnaliser les données utilisateur avant l’entraînement, et exclure entièrement de celui-ci les données importées par les clients.
Fireflies annonce un chiffrement AES 256 bits au repos pour les notes et les transcriptions de réunion, TLS pour les données en transit, ainsi que SOC 2 Type II, GDPR et — sur Enterprise, avec un BAA — HIPAA. Enterprise propose aussi Private Storage, qui permet à un client de conserver ses données de réunion dans un emplacement de son choix. La page sécurité ne revendique pas de chiffrement de bout en bout.
Granola déclare que les notes sont stockées dans son AWS Virtual Private Cloud hébergé aux États-Unis, chiffrées au repos et en transit, et qu’il ne conserve pas l’audio : la transcription se fait en temps réel sur macOS et Windows. Il n’autorise pas des tiers comme OpenAI ou Anthropic à s’entraîner sur les données clients, et le refus d’entraînement à l’échelle de l’organisation est un réglage Enterprise. Là non plus, aucune revendication de bout en bout.
Rien de tout cela n’est un reproche. Le chiffrement côté serveur, les audits SOC 2 et les options de refus d’entraînement sont des garde-fous réels, et un éditeur qui les documente précisément est plus honnête que celui qui écrit « sécurité de niveau bancaire » et s’arrête là. Le propos est plus étroit : ce sont des garde-fous sur ce que le prestataire choisit de faire de données qu’il peut lire. Le chiffrement de bout en bout, lui, porte sur ce qu’il peut faire.
Le chiffrement au repos est une propriété du stockage. Les données arrivent en clair sur l’infrastructure du prestataire, sont chiffrées avec une clé qu’il détient avant de toucher un disque, puis déchiffrées à chaque fois que le service en a besoin : pour afficher vos notes dans un navigateur, pour lancer une recherche, pour alimenter le modèle qui rédige le compte rendu. L’attaquant qu’il met en échec est celui qui repart avec le matériel ou le bucket de stockage, et rien d’autre.
Le chiffrement de bout en bout est une propriété de la clé. Le contenu est chiffré sur l’appareil qui l’a créé, avec une clé qui ne quitte jamais les appareils des personnes autorisées à le lire. Le serveur stocke un texte chiffré qu’il peut décrire — taille, horodatage, propriétaire — mais qu’il ne peut pas ouvrir. La conséquence pratique est une liste de choses qui cessent de fonctionner : pas de recherche plein texte côté serveur, pas d’« ouvrir dans le navigateur » sans matériel de clé, pas de technicien du support capable de regarder votre réunion pour comprendre pourquoi elle a échoué, et pas de réinitialisation de mot de passe qui récupère le contenu.
Ce dernier point est le test le moins coûteux qui soit, et il est détaillé plus bas.
Non pas une liste d’accusations, mais la liste des parties que l’architecture met à portée :
Les transcriptions de réunion sont une cible particulièrement riche pour ces cinq cas : discussions salariales, post-mortems d’incident, noms de clients, projets non annoncés, et les phrases que les gens prononcent avant de réaliser qu’ils sont enregistrés.
C’est la partie qui tranche le débat, et elle vient directement de la documentation des plateformes elles-mêmes.
Zoom. Activer le chiffrement de bout en bout désactive les fonctions AI Companion, l’enregistrement dans le cloud, la transcription en direct, le chat de réunion avant et après la réunion, la diffusion en direct, les sondages et enquêtes, les Zoom Apps, Zoom Notes et Zoom Whiteboard. L’explication de Zoom est le mécanisme lui-même : les clés de chaque réunion sont générées par les machines des participants, pas par les serveurs de Zoom.
Google Meet. Avec le client-side encryption (chiffrement côté client) activé, les enregistrements, les transcriptions, les sous-titres, « Take notes for me » et « Ask Gemini » sont tous indisponibles, tout comme l’audio par téléphone, les sous-groupes et les diffusions en direct. La formulation de Google est explicite : les médias sont chiffrés par le navigateur de chaque participant avec des clés mises à disposition des seuls participants, et restent illisibles pour les serveurs de Google.
Microsoft Teams. Le chiffrement de bout en bout couvre les appels VoIP en tête-à-tête éligibles, et les réunions planifiées avec une licence Teams Premium. L’enregistrement, la transcription et le récapitulatif IA ne sont pas disponibles tant qu’il est actif, et les organisations soumises à l’enregistrement de conformité ne peuvent pas l’utiliser du tout.
La règle commune aux trois : la machine qui produit la transcription doit voir l’audio en clair. Aucun protocole astucieux n’y échappe. La question de conception n’est donc pas « est-ce chiffré » mais « où se trouve cette machine » : dans le cloud de l’éditeur, ou sur le bureau de quelqu’un qui assistait de toute façon à la réunion.
Si la transcription se fait sur votre propre ordinateur, l’arbitrage disparaît. Le texte en clair existe sur une machine qui avait déjà l’audio, rien n’a besoin d’être téléversé pour que le compte rendu soit rédigé, et tout ce qui part ensuite peut être chiffré de bout en bout, puisque aucun serveur n’a besoin de le lire.
C’est la forme dans laquelle Speak-Y est construit. Les appels sont enregistrés en local sans qu’un bot rejoigne la réunion — une différence visible par tous les autres participants, et que nous avons traitée à part dans enregistrer une réunion sans bot. Les transcriptions restent sur l’appareil par défaut, l’audio est supprimé après traitement, et la synchronisation entre vos propres appareils est chiffrée de bout en bout. Le partage vers une base de connaissances d’équipe fonctionne de la même façon : les clés de canal n’existent que sur les appareils de l’équipe, et retirer un membre les fait tourner immédiatement. Quand un assistant IA lit vos réunions via le serveur MCP intégré, il les lit depuis la bibliothèque présente sur votre machine et non depuis une copie dans le cloud. Le détail du traitement des données figure dans la politique de confidentialité.
Le coût honnête de ce modèle est l’image inversée de celui du cloud. La recherche tourne sur vos appareils, pas sur un serveur qui a tout indexé. On ne peut pas redonner à un collègue l’accès à un canal dont il a été retiré en réactivant un simple réglage. Et un appareil perdu est un appareil qui contient du texte en clair, raison pour laquelle le chiffrement du disque sur le poste cesse d’être facultatif.
Les éditeurs qui ont réellement construit un chiffrement de bout en bout répondent vite, parce que les réponses découlent de la conception. Ceux qui ne l’ont pas fait ont tendance à répondre par des certifications, qui répondent à une autre question.
Il ne vous protège pas des autres personnes présentes. Quiconque détient la clé peut lire, copier et transmettre le contenu ; partager une transcription dans un canal d’équipe, c’est la donner à l’équipe. Il ne protège pas un poste compromis, puisque le texte en clair s’y trouve. Il ne masque pas les métadonnées : qui a enregistré quoi, quand, et quelle taille cela faisait.
Et il ne dit rien sur le fait que vous aviez ou non le droit d’enregistrer. C’est une question de consentement, tranchée par la juridiction et par les participants : certains endroits exigent le consentement d’une seule partie, d’autres celui de toutes. Elle est en cours de jugement — une action collective consolidée contre Otter au sujet des pratiques d’enregistrement de son preneur de notes a été plaidée sur une requête en rejet en mai 2026, et aucun tribunal ne s’est encore prononcé sur la licéité de la pratique. Le chiffrement n’y est pas une défense, et l’annonce que vous faites au début de l’appel ne devient pas facultative parce que votre stockage est chiffré. (Information générale, et non conseil juridique.)
Si vous choisissez un outil, traitez « chiffré au repos » comme un plancher et non comme la réponse, et demandez où se fait la transcription. Ce seul fait détermine tout le reste — y compris si le chiffrement de bout en bout vous est réellement accessible, ou s’il n’est qu’une formule sur une page. Le guide base de connaissances d’équipe détaille à quoi ressemblent des notes de réunion partagées et chiffrées dans l’usage quotidien.
Presque jamais. Les pages sécurité des principaux preneurs de notes IA décrivent un chiffrement AES-256 au repos et TLS en transit, ce qui signifie que le prestataire détient les clés et que ses systèmes peuvent lire vos transcriptions. Le chiffrement de bout en bout suppose que les clés n’existent que sur les appareils des participants — vérifié le 17 août 2026, Otter, Fireflies et Granola ne le revendiquent pas pour le contenu des réunions.
Le chiffrement au repos protège les données sur les disques du prestataire : si un disque ou un bucket de stockage est volé, le contenu est illisible. Le prestataire détient toujours la clé et déchiffre vos données chaque fois qu’il affiche une page, lance une recherche ou génère un compte rendu. Le chiffrement de bout en bout retire le prestataire de la boucle : il stocke un texte chiffré qu’il ne peut pas déchiffrer, parce que la clé ne quitte jamais vos appareils.
Parce que la machine qui rédige le compte rendu doit lire l’audio en clair. Zoom désactive AI Companion, l’enregistrement dans le cloud et la transcription en direct dans les réunions E2EE ; Google Meet supprime les enregistrements, les transcriptions, les sous-titres et « Take notes for me » sous client-side encryption ; Microsoft Teams coupe l’enregistrement, la transcription et le récapitulatif intelligent pour les appels chiffrés de bout en bout. Le seul moyen d’avoir les deux est de faire la transcription sur votre propre appareil.
Demandez ce qui se passe si vous oubliez votre mot de passe. Si le support peut restaurer vos transcriptions, le prestataire détient une clé et le système n’est pas chiffré de bout en bout. Le même test vaut pour la recherche plein texte côté serveur, l’accès web aux notes sans aucun matériel de clé sur l’appareil, et le personnel du support capable d’ouvrir votre réunion pour la déboguer.
Non. Le chiffrement décide qui peut lire un enregistrement ; le droit applicable décide si vous aviez le droit de le réaliser. Les règles de consentement varient selon la juridiction — certaines exigent une seule partie, d’autres toutes les parties — et elles s’appliquent de la même façon à une transcription chiffrée. Ceci est une information générale et non un conseil juridique.