Le chiffrement dans les outils de transcription, décrypter les promesses

La plupart des affirmations sur le chiffrement dans le marketing de la transcription décrivent deux protections qui s'appliquent à tout service cloud respectable : TLS en transit et AES-256 au repos. Comprendre ce que chacune couvre réellement, et où les deux s'arrêtent, vous permet d'évaluer les fournisseurs honnêtement et d'éviter de gaspiller vos efforts sur les mauvaises questions.

Deux couches, deux modèles de menace

Pour tout service de transcription cloud, le chiffrement opère à deux points distincts du parcours des données.

Le chiffrement en transit protège l'audio pendant son déplacement de votre appareil vers les serveurs du fournisseur. Le protocole est TLS (Transport Layer Security). TLS 1.3 est désormais la norme actuelle, avec environ 75 % d'adoption parmi les grands sites web selon le suivi SSL Pulse à mi-2025. TLS 1.2 reste cryptographiquement acceptable. TLS 1.0 et 1.1 sont obsolètes et ne devraient apparaître nulle part.

Le chiffrement au repos protège l'audio et les transcriptions pendant leur stockage sur les disques du fournisseur. La norme est AES-256 (Advanced Encryption Standard avec des clés de 256 bits). Cloudflare R2, que CATT utilise, implémente AES-256-GCM avec des clés gérées en interne par Cloudflare. AWS S3, utilisé par Otter.ai et d'autres, fournit le même algorithme via un chiffrement côté serveur.

Ces deux protections résolvent des problèmes différents. Le chiffrement en transit neutralise les espions réseau sur le WiFi public, les FAI et les routeurs intermédiaires. Le chiffrement au repos neutralise quiconque vole un disque physique ou obtient un accès non autorisé à l'infrastructure de stockage.

Ce qu'aucune de ces protections ne couvre : l'application propre du fournisseur, qui déchiffre les données de manière transparente pour les traiter. C'est la limite que la plupart des supports marketing contournent discrètement.

Ce que TLS en transit garantit réellement

Lorsque vous téléversez un fichier, TLS crée un tunnel chiffré entre votre navigateur ou application et le serveur du fournisseur. Même sur un réseau non fiable, un observateur passif ne voit que du charabia chiffré.

TLS garantit spécifiquement trois choses :

• Confidentialité : le contenu est illisible pour des tiers sur le réseau
• Intégrité : les données n'ont pas été modifiées en transit
• Authentification : le serveur auquel vous vous connectez est bien celui que le certificat déclare

Vous pouvez vérifier vous-même la qualité TLS de n'importe quel fournisseur sur ssllabs.com/ssltest. L'outil note la configuration complète, y compris les versions de protocole prises en charge et les suites de chiffrement actives. Visez une note A ou A+, et signalez tout ce qui prend encore en charge TLS 1.0 ou 1.1.

TLS 1.2 est-il encore acceptable pour un service de transcription en 2026 ?

Oui, TLS 1.2 reste cryptographiquement acceptable, même si TLS 1.3 est désormais la norme préférée. Ce que TLS ne protège pas : un attaquant qui a déjà compromis votre appareil, un serveur compromis, ou le fournisseur qui lit vos données après leur arrivée. TLS s'arrête au serveur. Ensuite, les données sont en clair dans l'application.

Ce que garantit réellement le chiffrement AES-256 au repos

AES-256 au repos signifie que la couche de stockage chiffre vos données sur le disque. La documentation de Cloudflare pour R2 le décrit explicitement : tous les objets et leurs métadonnées sont chiffrés avec AES-256-GCM. Amazon S3 utilise AES-256 via SSE (chiffrement côté serveur), dont Otter.ai, Descript et plusieurs autres services de transcription héritent de leur couche de stockage AWS.

Le chiffrement AES-256 signifie-t-il qu'un fournisseur de transcription ne peut pas lire mes fichiers ?

Non. Le chiffrement au repos protège spécifiquement contre le vol physique de disques dans un centre de données, le matériel décommissionné qui n'a pas été correctement effacé, et l'accès inter-locataires au niveau de l'infrastructure dans les environnements cloud multi-locataires.

Il ne protège pas contre :

• Le serveur applicatif qui lit les données via des chemins de code normaux (il détient les clés de déchiffrement et les utilise automatiquement)
• Les employés du fournisseur disposant d'un accès au niveau applicatif
• Un système de gestion des clés compromis
• Des contrôles d'accès mal configurés qui exposent publiquement un bucket de stockage (ce qui contournerait entièrement le chiffrement)

Le fournisseur a accès. Ce n'est pas une faille dans son implémentation. C'est ainsi que fonctionne le chiffrement côté serveur, par conception.

Pourquoi un véritable chiffrement de bout en bout est impossible pour la reconnaissance vocale cloud

Que signifie « chiffré de bout en bout » quand un outil de transcription le revendique ?

Le chiffrement de bout en bout (E2EE), au sens où l'entend Signal, signifie que le fournisseur est verrouillé cryptographiquement : il ne peut pas déchiffrer vos données, même sous contrainte. La clé privée ne quitte jamais votre appareil.

Ce n'est pas réalisable pour la reconnaissance vocale cloud, et tout fournisseur qui prétend le contraire mérite un examen minutieux. Le modèle d'IA doit traiter l'audio en clair pour produire une transcription. Vous ne pouvez pas transcrire un audio qui reste chiffré au niveau de la couche de traitement.

Quand les fournisseurs de transcription utilisent l'expression « chiffré de bout en bout », ils veulent généralement dire l'une de ces deux choses plus faibles :

Chiffrement côté client avant le téléversement. L'appareil de l'utilisateur chiffre l'audio avant de l'envoyer au serveur. Le serveur le déchiffre, exécute le modèle, rechiffre la transcription et la renvoie. Le fournisseur a accès au texte en clair pendant la fenêtre de transcription. Cela limite la durée d'exposition, mais ne l'élimine pas.

Enclaves de calcul confidentiel. Le traitement côté serveur s’effectue dans une enclave isolée matériellement (Intel SGX, AMD SEV, Intel TDX), où les opérateurs du fournisseur ne peuvent pas inspecter la mémoire, même si le code du fournisseur s’exécute. Azure propose la transcription Whisper dans des conteneurs confidentiels utilisant AMD SEV-SNP. Cela réduit considérablement la surface d’exposition, mais exige toujours que le modèle accède au texte en clair dans l’enclave. La garantie repose sur l’isolation matérielle, pas sur un verrouillage cryptographique.

La recherche sur le chiffrement homomorphe pour l’audio, où le calcul s’effectue sur le texte chiffré sans déchiffrement, est active mais pas encore prête pour la production. Un article de 2025 sur le traitement approximatif du signal quantifié a obtenu le premier pipeline audio brut sécurisé utilisant le chiffrement entièrement homomorphe. Le repère : calculer une fenêtre audio de 64 millisecondes en FHE a pris 12 970 secondes sur un Apple M2. En clair, cela prenait 0,004 seconde. C’est une direction de recherche, pas une fonctionnalité commerciale.

La seule voie vers une transcription réellement inaccessible au fournisseur aujourd’hui, c’est l’auto-hébergement. Faites tourner Whisper sur votre propre matériel, et il n’y a plus de fournisseur pour exposer votre audio.

Ce que les principaux services de transcription divulguent réellement

Voici ce que les principaux fournisseurs publient sur leur posture de chiffrement, vérifié dans leur documentation :

Sources : pages de sécurité des fournisseurs et documentation publique, vérifiées en juillet 2026. La disponibilité du BAA exige souvent des contrats d'entreprise. Vérifiez les conditions actuelles auprès de chaque fournisseur.

Si un fournisseur ne publie aucun de ces détails, considérez cela comme un signal : soit il n'a pas mis en place de standards de base, soit il n'a pas investi dans une documentation destinée aux clients soucieux de la sécurité.

Clés de chiffrement gérées par le client : quand elles comptent

Les déploiements standards utilisent des clés gérées par le fournisseur : le système du vendeur chiffre vos données et détient les clés. Vous n'avez aucun moyen de révoquer l'accès en faisant tourner une clé de votre côté.

Les clés de chiffrement gérées par le client (CMEK) inversent ce schéma. Vous apportez vos propres clés via un service de gestion des clés (AWS KMS, Google Cloud KMS), et le stockage du fournisseur ne peut pas déchiffrer vos données sans que votre infrastructure de clés ne réponde. Vous pouvez révoquer l'accès en désactivant la clé. Vous disposez d'une piste d'audit pour chaque utilisation de clé.

AWS Transcribe prend en charge les clés gérées par KMS pour le chiffrement des sorties. Google Cloud Speech-to-Text v2 prend en charge la CMEK pour toutes les ressources et les tâches de transcription par lots. Les deux sont documentés dans leurs références développeurs respectives.

CATT ne propose pas de CMEK. Les fichiers sont hébergés sur Cloudflare R2 avec des clés gérées par Cloudflare. Pour les clients dont les exigences de sécurité incluent la propriété des clés et leur révocabilité, AWS Transcribe ou Google Cloud STT v2 sont les options adaptées, via la comparaison des tarifs des API de transcription vocale.

Ce que le chiffrement ne résout pas

C'est aussi important que ce qu'il résout.

Accès du fournisseur. TLS et AES-256 n'empêchent pas l'application du fournisseur lui-même d'accéder à vos données. Les contrôles d'accès internes, les politiques de moindre privilège et la journalisation des audits sont les protections pertinentes ici. Demandez si les employés peuvent accéder aux enregistrements audio des clients, dans quelles circonstances, et si cet accès est journalisé.

Comptes compromis. Si vos identifiants de connexion sont volés, l'attaquant s'authentifie comme vous et accède aux données via les chemins d'application normaux. Le chiffrement n'offre aucune protection dans ce cas. L'authentification multifacteur sur votre compte compte plus que l'algorithme de chiffrement.

Point de terminaison compromis. Si votre ordinateur portable est compromis avant le téléversement, l'audio est lisible sur votre appareil avant même d'entrer dans un canal chiffré. La sécurité du point de terminaison est un domaine distinct du chiffrement en transit et au repos.

Contrôles d'accès mal configurés. Un bucket de stockage réglé en lecture publique expose vos données, peu importe AES-256. Une configuration correcte des politiques d'accès est nécessaire en plus du chiffrement. Demandez si les fournisseurs ont déjà connu des incidents d'exposition publique.

Données d'entraînement IA. Si le fournisseur utilise les enregistrements clients pour entraîner ou améliorer ses modèles, le chiffrement protège les données au repos mais ne résout pas ce qui se passe lorsque le modèle les traite. Demandez explicitement si l'audio est utilisé pour l'entraînement, et faites-le figurer dans le contrat. Fireflies.ai, par exemple, publie une politique de conservation des données de 0 jour avec ses fournisseurs de transcription, ce qui répond précisément à cette préoccupation.

Une posture de sécurité complète superpose le chiffrement à des contrôles d'accès, une authentification, une journalisation d'audit, une gestion des fournisseurs et des politiques claires d'utilisation des données. Le chiffrement n'est qu'une couche, pas la réponse globale.

Voir la transcription IA est-elle privée pour une vue d'ensemble du traitement des données, et la transcription conforme au RGPD pour le cadre réglementaire dans les contextes européens.

Quoi demander à un fournisseur avant de s'engager

Pour la plupart des cas d'usage professionnels, ces cinq questions couvrent l'essentiel :

1. Quelles versions de TLS et suites de chiffrement prenez-vous en charge ? (Un score A/A+ sur SSL Labs est la référence)
2. Les données sont-elles chiffrées au repos, et avec quel algorithme ?
3. Qui détient les clés de chiffrement, et puis-je apporter les miennes ?
4. Les sauvegardes et les journaux sont-ils également chiffrés ?
5. Utilisez-vous l'audio client pour entraîner ou améliorer vos modèles ?

Quelles options de chiffrement existent pour les secteurs réglementés comme la santé ?

Le document le plus important n'est pas la spécification de chiffrement, mais un accord d'associé commercial (BAA) signé par le fournisseur. Sans BAA, utiliser un service de transcription avec des informations de santé protégées (PHI) peut violer la HIPAA, indépendamment des affirmations sur l'AES-256. Rev, Otter.ai et Fireflies.ai (niveau entreprise) publient leur disponibilité de BAA. Pour un contrôle total des clés, AWS Transcribe et Google Cloud Speech-to-Text v2 prennent tous deux en charge les clés de chiffrement gérées par le client (CMEK) via leurs services KMS respectifs.

Pour les secteurs réglementés, ajoutez ces questions :

6. Avez-vous un accord d'associé commercial (BAA) signé pour la HIPAA ?
7. Avez-vous un accord de traitement des données (DPA) pour le RGPD ?
8. Êtes-vous audité SOC 2 Type II, et puis-je voir le rapport ?
9. Prenez-vous en charge les clés de chiffrement gérées par le client ?
10. Comment gérez-vous la rotation des clés et répondez-vous à une violation de données ?

Une note sur le langage de conformité. Dire qu'un outil « est conforme HIPAA » ou « est conforme GDPR » est imprécis. La conformité est une propriété du déploiement spécifique et des accords que vous avez conclus avec le fournisseur, pas un badge que l'outil porte de manière indépendante. Une BAA signée avec un prestataire disposant de contrôles techniques appropriés est ce qui compte pour la HIPAA. Une DPA signée avec des engagements de traitement des données appropriés est ce qui compte pour le GDPR. Demandez les documents, pas le badge.

Divulgation honnête pour CATT

Ce que fait CATT :

• TLS 1.2+ en transit, délivré via le réseau périphérique de Cloudflare
• AES-256-GCM au repos sur Cloudflare R2, avec des clés gérées par Cloudflare
• Sauvegardes chiffrées héritées de la protection par défaut de R2
• Contrôles d'accès basés sur les rôles dans l'application

Ce que CATT ne fait pas :

• Clés de chiffrement gérées par le client (CMEK)
• Intégration de module de sécurité matérielle (HSM)
• Gestion des clés certifiée FIPS 140-3 (note : les validations FIPS 140-2 expirent en septembre 2026)
• Environnements d'exécution confidentiels pour le traitement
• Vrai chiffrement côté client à l'upload

Pour la majorité des cas d'usage de transcription professionnelle et personnelle, la première liste est suffisante. Si vous avez besoin de la deuxième liste, vous évoluez dans un contexte d'entreprise ou d'industrie réglementée qui nécessite probablement un autre fournisseur, ou un auto-hébergement. Si vous avez besoin d'une transcription propre et rapide sans bot de réunion ni surcharge de conformité complexe, l'outil audio-texte de CATT s'en charge directement sans inscription.

Voir suppression automatique des fichiers de transcription pour des mesures pratiques visant à réduire votre empreinte de données après la transcription.

Sources

• Documentation sur la sécurité des données Cloudflare R2 : chiffrement AES-256-GCM au repos, TLS en transit, clés gérées par Cloudflare
• Page confidentialité et sécurité d'Otter.ai : AES-256 via AWS SSE, SOC 2 Type II
• Page sécurité de Descript : AES-256 au repos, TLS 1.2 en transit, SOC 2 Type II
• Page sécurité de Fireflies.ai : AES-256 au repos, TLS en transit, SOC 2 Type II, option entreprise HIPAA-BAA
• Documentation CMEK de Google Cloud Speech-to-Text : clés de chiffrement gérées par le client, API v2
• Documentation sur le chiffrement des données AWS Transcribe : intégration KMS pour le chiffrement des sorties
• Test serveur Qualys SSL Labs : outil de notation de configuration TLS
• Suivi de l'adoption de TLS 1.3 par SSL Pulse : 75 % d'adoption de TLS 1.3 parmi les grands sites web, mi-2025
• Traitement du signal approximatif quantifié pour l'audio FHE (prépublication 2025) : benchmarks de traitement audio par chiffrement homomorphe
• Page sécurité HIPAA de Rev.com : disponibilité de la BAA et détails du niveau HIPAA