Dictée vocale et RGPD : le guide

Vous êtes avocat, médecin, professionnel des ressources humaines ou expert-comptable, et vous dictez vos comptes rendus de consultation, vos notes de dossier ou vos lettres de mission à voix haute plutôt que de les taper. La question arrive vite : une fois que vous avez fini de parler, où va cette voix ? Pour la plupart des outils de dictée grand public, la réponse est un serveur cloud — souvent situé hors de l'Union européenne. Et cette réponse a des conséquences RGPD très concrètes : l'éditeur du logiciel devient un sous-traitant au sens de l'article 28 du RGPD, et si ses serveurs sont hors UE, chaque phrase dictée engage un transfert de données encadré par le chapitre V du texte. Rien de tout cela n'est illégal en soi. Mais rien n'est anodin non plus — et la plupart des professionnels qui dictent des données clients ou patients n'y ont jamais pensé.

Pourquoi la dictée vocale cloud est un sujet RGPD ?

Premier point, souvent ignoré : la voix elle-même est une donnée personnelle. La CNIL le rappelle explicitement dans sa définition de la donnée personnelle, en citant la voix comme exemple d'identifiant indirect, au même titre qu'un numéro de téléphone ou une adresse e-mail. Dans son livre blanc consacré aux assistants vocaux, l'autorité est encore plus directe : « la voix est incontestablement une donnée personnelle ». Ce n'est donc pas une hypothèse d'école — c'est le point de départ de toute analyse RGPD sur un outil de dictée.

Deuxième point : ce que vous dictez peut être bien plus sensible que la voix elle-même. Un diagnostic médical, une stratégie de dossier, une situation de handicap ou d'orientation syndicale évoquée dans un compte rendu RH — ce contenu peut relever des catégories particulières de données de l'article 9 du RGPD, qui encadre strictement le traitement des données de santé, des opinions politiques ou de l'appartenance syndicale.

Troisième point, le plus souvent oublié : dès qu'un outil tiers traite cet audio pour votre compte, il devient un sous-traitant au sens de l'article 28 du RGPD — même s'il ne s'agit « que » d'une API de transcription. Cet article impose un contrat encadrant ce que le sous-traitant a le droit de faire des données, et si ses serveurs sont situés hors de l'UE (le cas de la majorité des moteurs de reconnaissance vocale grand public), le chapitre V du RGPD s'applique : le transfert doit reposer sur une décision d'adéquation, des clauses contractuelles types ou un autre mécanisme prévu à l'article 44 et suivants. Depuis l'arrêt Schrems II de la CJUE (16 juillet 2020), qui a invalidé le Privacy Shield, la CNIL rappelle que ces transferts vers des pays comme les États-Unis exigent une analyse au cas par cas, pas une simple case cochée dans les conditions d'utilisation.

La voix est-elle une donnée biométrique ?

Nuance importante, à ne pas confondre avec ce qui précède : la voix n'est une donnée biométrique au sens strict du RGPD que dans un cas précis. L'article 9 vise « les données biométriques aux fins d'identifier une personne physique de manière unique » — c'est-à-dire un traitement qui construit un gabarit vocal pour reconnaître qui parle (authentification, contrôle d'accès), pas un traitement qui se contente de transcrire ce qui est dit.

La CNIL fait exactement cette distinction dans ses conseils aux concepteurs d'assistants vocaux : ce sont les fonctions de reconnaissance ou d'authentification du locuteur, reposant sur des « gabarits ou modèles de voix », qui sont « considérées comme des données sensibles au sens du RGPD ». Un logiciel de dictée qui transcrit vos mots sans chercher à vérifier qui vous êtes ne construit pas ce type de gabarit — il n'entre donc pas dans ce régime renforcé.

Ce que ça change concrètement : l'audio d'une dictée reste une donnée personnelle « classique » (article 4) tant qu'aucune reconnaissance du locuteur n'est en jeu. Mais le contenu que vous dictez, lui, peut rester une donnée sensible au sens de l'article 9 — indépendamment du canal vocal. Les deux analyses sont séparées.

La grille d'évaluation en 4 questions

Avant de dicter la moindre donnée client ou patiente dans un outil, quatre questions suffisent à cadrer le risque :

Où va l'audio ? Reste-t-il sur votre machine, ou est-il envoyé vers un serveur distant dès que vous parlez ?
Qui le traite ? S'il part vers un serveur, quel est l'éditeur exact — et avez-vous un contrat de sous-traitance (article 28) qui couvre cet usage précis ?
Où sont les serveurs ? Dans l'UE/EEE, ou dans un pays tiers ? Si c'est un pays tiers, quel mécanisme de l'article 44 et suivants encadre le transfert — décision d'adéquation, clauses contractuelles types, règles d'entreprise contraignantes ?
Combien de temps l'audio et la transcription sont-ils conservés ? Politique de rétention, suppression automatique, droit à l'effacement.

Un outil qui envoie l'audio par défaut et ne propose la suppression qu'en option n'est pas rare : nous l'avions documenté avec Wispr Flow, où la « rétention zéro » est un réglage à activer, pas le comportement par défaut. Aux États-Unis, la même question se pose sous un autre nom — HIPAA plutôt que RGPD — mais avec la même grille de lecture ; nous l'avions détaillée dans notre article sur la dictée et le secret médical.

Ce que change un traitement 100% local

Quand la transcription se fait entièrement sur votre poste — sans qu'aucun octet d'audio ne quitte la machine — les deux premières cases de la grille changent de nature pour cette opération précise : il n'y a pas de serveur distant qui reçoit l'audio, donc pas de sous-traitant à encadrer par contrat pour la transcription, et pas de transfert hors UE à justifier au titre du chapitre V, puisqu'il n'y a tout simplement pas de transfert.

Ce n'est pas une idée exotique : c'est la direction que la CNIL recommande elle-même. Dans ses conseils aux concepteurs d'assistants vocaux, elle préconise de « mettre en œuvre au maximum les principes de l'informatique en périphérie (edge computing) pour que ne soit transférées sur des serveurs centralisés que les données strictement nécessaires » (texte original de la CNIL). Le traitement local n'est pas un contournement du RGPD — c'est l'application de ce principe à sa limite : zéro donnée transférée.

Pour les professionnels de santé spécifiquement, un point mérite d'être précisé : quand un prestataire externe héberge des données de santé pour votre compte, il doit être un hébergeur de données de santé agréé ou certifié (HDS), une obligation posée par le décret n° 2018-137 du 26 février 2018 (Code de la santé publique). Si la transcription reste sur votre poste, il n'y a pas d'hébergement externe de l'audio à ce stade précis — donc pas de statut HDS à vérifier pour cette brique-là. Le reste de votre système (dossier patient informatisé, sauvegardes, messagerie) garde ses propres obligations, HDS y compris le cas échéant.

Les limites honnêtes

Le traitement local répond à une question précise — où va l'audio pendant la transcription — pas à toutes les questions RGPD de votre pratique. Quelques limites à garder en tête :

Le stockage local reste votre responsabilité. Un poste non chiffré, une session laissée ouverte, un ordinateur partagé sans compte séparé : le RGPD (article 32, sécurité du traitement) s'applique à vos données quel que soit l'outil de dictée utilisé.
Le reste de votre stack a ses propres obligations. Dossier patient informatisé, logiciel de gestion de cabinet, sauvegarde cloud, messagerie professionnelle : chacun de ces outils peut, lui, engager un sous-traitant et un transfert hors UE — la dictée locale ne résout qu'un maillon de la chaîne.
Les obligations générales du RGPD ne disparaissent pas. Minimisation (ne dictez que ce qui est nécessaire), durée de conservation définie, information des personnes concernées : ces principes s'appliquent indépendamment de l'architecture technique.
Aucun logiciel ne s'auto-certifie « conforme RGPD ». Il n'existe pas de label RGPD délivré par un tiers pour un produit ; la conformité se juge à l'échelle d'un traitement et d'une organisation, pas d'une case cochée sur un site web.

Sur ces points, la bonne pratique reste la même que pour n'importe quel autre outil : validez votre analyse avec votre délégué à la protection des données (DPO) ou votre conseil, en fonction de votre situation réelle.

Où se situe Inkvox dans cette grille ?

Inkvox transcrit la voix directement sur votre machine Windows, avec Whisper large-v3-turbo quantisé tournant sur votre propre GPU via Vulkan (NVIDIA, AMD ou Intel), et une bascule automatique sur CPU si nécessaire. Sur une RTX 3070, une phrase est transcrite en environ 0,3 à 0,4 seconde. Le modèle (~800 Mo) se télécharge une fois à l'installation ; ensuite, l'application fonctionne hors ligne, sans compte à créer. Audio envoyé vers un serveur : 0 octet. Inkvox prend en charge plus de 100 langues, dont le français.

En pratique, pour l'opération de transcription elle-même : aucun serveur tiers ne reçoit l'audio, donc pas de sous-traitant à encadrer par contrat pour cette brique, et pas de transfert hors UE à justifier au titre du chapitre V — puisqu'il n'y a pas de transfert. Ce constat est architectural, pas une auto-certification : le reste de votre système d'information (stockage, autres logiciels, accès au poste) garde ses propres obligations RGPD, à valider avec votre DPO. Inkvox est aujourd'hui en beta privée sur liste d'attente ; une version Pro, avec réécriture par un modèle de langage local, est en développement, et une version macOS est prévue.

Si votre pratique dicte des données clients ou patientes et que vous voulez retirer ce maillon-là de l'équation, rejoignez la liste d'attente.

Questions fréquentes

La dictée vocale est-elle interdite par le RGPD ?

Non. Le RGPD n'interdit pas la dictée vocale — il encadre la façon dont les données personnelles qu'elle traite (la voix, et le contenu dicté) doivent être collectées, sécurisées et conservées. La question n'est pas « ai-je le droit de dicter », mais « où va cet audio, qui le traite, et pendant combien de temps ».

Un outil de dictée cloud a-t-il toujours besoin d'un contrat de sous-traitance ?

Oui, dès qu'un tiers traite des données personnelles pour votre compte — y compris une simple API de reconnaissance vocale — l'article 28 du RGPD impose un contrat qui encadre cet usage. C'est vrai même si l'éditeur ne conserve l'audio que quelques secondes.

La voix est-elle une donnée biométrique au sens du RGPD ?

Seulement quand elle sert à identifier ou authentifier qui parle, via un gabarit vocal — c'est ce que précise l'article 9 du RGPD et ce que confirme la CNIL dans ses travaux sur les assistants vocaux. Un outil qui transcrit simplement ce que vous dites, sans chercher à reconnaître qui vous êtes, ne traite pas de donnée biométrique à ce titre. La voix reste néanmoins une donnée personnelle « classique » dans tous les cas.

Inkvox est-il conforme au RGPD ?

Il n'existe pas de certification « conforme RGPD » qu'un logiciel puisse s'attribuer seul — la conformité se juge à l'échelle d'un traitement complet, pas d'un produit isolé. Ce qu'on peut affirmer factuellement : la transcription se fait sur votre machine, avec 0 octet d'audio envoyé vers un serveur, donc sans sous-traitant ni transfert hors UE à gérer pour cette opération précise. Le reste de votre système d'information garde ses propres obligations RGPD, à valider avec votre DPO.

Dictée vocale et RGPD : ce que dit vraiment la loi