RGPD et callbot : enregistrement, consentement, hébergement

Ce qui constitue une donnée personnelle dans un appel avec un callbot

Le RGPD définit une donnée personnelle comme toute information se rapportant à une personne physique identifiée ou identifiable (article 4 du RGPD). La voix entre directement dans ce périmètre : dès 1982, la justice française la qualifiait d'« attribut de la personnalité, une sorte d'image sonore », avec une protection proche du droit à l'image — un rappel que fait le laboratoire d'innovation de la CNIL dans ses travaux sur la voix comme donnée. Concrètement, tout ce qui transite dans un appel avec un callbot relève du RGPD dès la première seconde : l'audio, sa transcription, les métadonnées (numéro, horodatage, durée), et le contenu de ce que dit l'appelant — y compris, potentiellement, des informations sensibles données spontanément.

Une distinction change ensuite le régime applicable : un enregistrement vocal brut n'est pas automatiquement une « donnée biométrique » au sens du RGPD. L'article 4 réserve cette qualification aux données résultant d'un traitement technique spécifique, relatives aux caractéristiques physiques ou comportementales d'une personne, qui permettent ou confirment son identification unique. L'article 9, qui classe la biométrie parmi les catégories particulières de données — au même titre que la santé —, vise spécifiquement les données biométriques traitées aux fins d'identifier une personne physique de manière unique.

Deux situations doivent donc être distinguées. Un callbot qui transcrit ce que dit l'appelant pour comprendre sa demande et y répondre — la quasi-totalité des déploiements en service client — traite une donnée personnelle ordinaire : la voix sert de vecteur au contenu, pas d'identifiant. À l'inverse, un système qui extrait de la voix une empreinte vocale pour reconnaître qui appelle bascule dans le régime de l'article 9, nettement plus contraignant. La CNIL a par exemple autorisé, dès 2017 et à titre expérimental, des banques à tester une authentification vocale biométrique, sous réserve d'un consentement préalable et de garanties de confidentialité strictes, en précisant que ces conditions d'expérimentation ne préjugeaient pas de celles exigées pour un déploiement pérenne. La plupart des callbots commerciaux n'utilisent pas la biométrie vocale et n'ont donc pas à s'imposer ce régime renforcé, mais le vérifier avec chaque fournisseur, plutôt que le présumer, reste nécessaire.

Enregistrer un appel : les conditions posées par la CNIL

Deux finalités différentes se cachent souvent derrière la même case cochée « enregistrer les appels ». La première est l'amélioration du service et le contrôle qualité. La seconde est la preuve : conserver la trace d'un appel pour établir, en cas de litige, qu'un contrat a bien été conclu. La CNIL indique que, dans ce second cas, l'enregistrement peut être traité sur le fondement de l'exécution du contrat (article 6, paragraphe 1, point b) — mais seulement si l'organisme démontre qu'il ne dispose pas d'un autre moyen de preuve, l'enregistrement systématique n'étant pas justifié par principe. Pour un usage de qualité, à défaut d'obligation légale spécifique, c'est le plus souvent l'intérêt légitime (article 6, paragraphe 1, point f) qui sert de fondement, à condition de démontrer que cet intérêt ne prime pas sur les droits de l'appelant et de lui offrir un moyen réel de s'y opposer (article 21).

La CNIL insiste sur deux principes valables quelle que soit la finalité. La nécessité d'abord : « sauf dispositions légales le permettant, les enregistrements ne peuvent être ni permanents ni systématiques ». La minimisation ensuite : pour les contenus sensibles évoqués pendant l'appel, la CNIL recommande, dans sa doctrine sur les chatbots transposable à la voix, une mise en garde invitant à ne pas les communiquer, et une purge rapide si cela arrive malgré tout. Un point sous-estimé en comité : le traitement RGPD ne commence pas à l'archivage, mais dès que la voix est captée et transmise au moteur de reconnaissance vocale, même sans conservation ultérieure — qu'il s'agisse d'un appel entrant ou sortant ne change rien, seules la finalité et la base légale diffèrent.

Information et consentement : ce qui est réellement exigé

Parce que l'appelant fournit ses données directement en parlant au système, c'est l'article 13 du RGPD qui s'applique — la collecte directe — et non l'article 14, réservé aux données obtenues indirectement. Il impose de porter à la connaissance de la personne : identité du responsable de traitement, finalités et base légale, destinataires, existence éventuelle d'un transfert hors UE, durée de conservation, et ses droits — accès, rectification, opposition, réclamation à la CNIL. Pour un appel téléphonique, la CNIL recommande une mention orale en début de conversation, assez claire pour que l'appelant comprenne qu'il est enregistré, avec un moyen concret de s'y opposer ou de poursuivre sans enregistrement lorsque c'est possible — une position exprimée dans sa doctrine sur l'écoute et l'enregistrement des appels. Par analogie, la même logique de transparence s'étend au caractère automatisé de l'échange : un appelant qui parle à un callbot doit pouvoir le comprendre dès le début de la conversation, pas seulement le découvrir au fil de l'échange ou une fois l'appel terminé.

Un malentendu fréquent mérite d'être corrigé : le consentement n'est pas la condition par défaut d'un projet de callbot. La CNIL le rappelle à propos du consentement : il n'est que l'une des six bases légales du RGPD, et un responsable de traitement peut s'appuyer sur l'exécution d'un contrat ou son intérêt légitime plutôt que sur un consentement explicite. Ce qui reste obligatoire dans tous les cas, c'est l'information — pas le recueil d'un « oui » actif. Le consentement explicite redevient quasiment incontournable dans un cas précis, la biométrie vocale, où les autres exceptions de l'article 9 (obligations de l'employeur, intérêt public, recherche...) ne correspondent pas à une relation commerciale ordinaire. Quand il est la base retenue, il doit remplir les conditions de l'article 7 : demande présentée de façon distincte, et retrait « aussi facile » que le don initial — une contrainte non triviale sur un canal vocal, où dire « oui » en début d'appel est simple, mais organiser un retrait tout aussi simple en cours d'appel l'est beaucoup moins.

Dernier point : pour les callbots qui n'informent pas seulement mais agissent — annuler une commande, refuser un remboursement —, l'article 22 du RGPD donne le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques ou affectant significativement la personne. La CNIL le formule explicitement pour les agents conversationnels : une conversation automatisée, sans intervention humaine, ne peut à elle seule aboutir à des décisions importantes — un sujet qui gagne en importance à mesure que les agents IA gagnent en autonomie d'action.

Durée de conservation : les repères publiés par la CNIL

Le RGPD pose un principe plutôt qu'un chiffre : les données ne doivent pas être conservées sous une forme identifiante au-delà de ce qui est nécessaire aux finalités poursuivies (article 5, paragraphe 1, point e). La CNIL a toutefois publié, pour les centres d'appels, des repères concrets transposables à un projet de callbot — à condition de ne pas les traiter comme un chiffre unique valable pour tout, la durée dépendant directement de la finalité.

Finalité de la conservation	Repère CNIL	Ce qu'il faut retenir
Qualité, formation, amélioration du callbot	6 mois maximum	Logique de l'« enregistrement tampon » : écouter, analyser, supprimer rapidement
Documents d'analyse issus d'un enregistrement	Jusqu'à 1 an	Distinct de l'enregistrement source lui-même
Preuve de la formation d'un contrat	De l'ordre de 5 ans	Aligné sur le délai de prescription civile applicable au litige

Aucun texte ne fixe à ce jour une durée spécifique aux callbots, mais la même logique de proportionnalité s'applique par transposition. En pratique, l'audio brut, une fois transcrit, n'a souvent plus besoin d'être conservé : garder le texte plutôt que le son réduit le volume de données sensibles stockées et la surface d'exposition en cas d'incident — un arbitrage qui a un coût réel, rarement visible dans une grille tarifaire standard mais qui pèse sur les coûts cachés d'un projet callbot. Si le dispositif sert aussi à évaluer des salariés, le code du travail ajoute une obligation distincte d'information et de consultation des représentants du personnel, à ne pas confondre avec l'information due à l'appelant externe.

Sous-traitants et hébergement : le point le plus souvent oublié en comité

Un callbot n'est presque jamais l'œuvre d'un seul fournisseur : reconnaissance vocale, modèle de langage, synthèse vocale et orchestration proviennent généralement d'éditeurs distincts, chacun recevant à un moment la voix ou le texte de l'appelant. Au sens du RGPD, chacun est, dans la quasi-totalité des cas, un sous-traitant agissant pour le compte du responsable de traitement — l'entreprise qui déploie le callbot. L'article 28 impose un contrat écrit, signé avant le début de la prestation, prévoyant que le sous-traitant agit uniquement sur instruction documentée, garantit la confidentialité de son personnel, applique des mesures de sécurité adaptées, encadre le recours à d'éventuels sous-traitants ultérieurs, assiste le responsable pour les demandes de droits des personnes, et supprime ou restitue les données en fin de contrat. La CNIL le formule sans détour : ne pas engager la prestation sans ce contrat signé.

Un point que la CNIL reconnaît elle-même non tranché mécaniquement : la qualification juridique exacte d'un fournisseur d'IA n'est pas toujours évidente. Un prestataire qui exécute une tâche précise sur instruction est clairement sous-traitant ; un fournisseur de modèle qui réutiliserait les échanges pour améliorer son propre système bascule au contraire, selon la doctrine CNIL, vers une qualification de responsable d'un traitement distinct pour cette réutilisation — la CNIL réserve la qualification de responsable conjoint aux cas où plusieurs parties déterminent ensemble les finalités et les moyens du traitement, ce qui n'est pas le cas d'un fournisseur qui décide seul de la manière dont il réutilise les données pour son propre modèle, signe que la réponse dépend du contrat réel, pas d'une règle uniforme pour tous les modèles du marché.

L'hébergement pose un piège fréquent : la localisation physique des serveurs en Europe ne suffit pas à elle seule à écarter un risque d'accès par une autorité étrangère. Si le fournisseur reste soumis au droit d'un pays tiers à portée extraterritoriale — le cas le plus cité étant le Cloud Act américain —, cette loi peut s'appliquer indépendamment de l'endroit où tourne le serveur. La CNIL a explicitement mis en garde sur ce point pour les traitements sensibles, et identifie la qualification SecNumCloud, délivrée par l'ANSSI, comme le marqueur qu'elle reconnaît pour une réelle immunité. La question à poser n'est donc pas seulement où sont hébergées les données, mais à la loi de quel pays le fournisseur est soumis.

Transferts hors UE : ce qu'il faut vérifier avant de signer

La reconnaissance vocale, les grands modèles de langage et la synthèse vocale les plus utilisés restent majoritairement fournis par des sociétés américaines. Cela ne rend pas un projet non conforme par principe, mais déclenche systématiquement les règles du chapitre V du RGPD dès qu'une donnée est envoyée à un destinataire établi hors UE — l'article 44 pose que ces règles doivent garantir que le niveau de protection du règlement n'est pas compromis, quelle que soit la brièveté technique du transfert.

Trois outils permettent de l'encadrer, selon la CNIL. D'abord la décision d'adéquation (article 45) : la Commission reconnaît qu'un pays, ou un mécanisme de certification pour certaines de ses sociétés, offre une protection suffisante — c'est le cas du cadre UE-États-Unis (Data Privacy Framework), dont dépendent de nombreux fournisseurs d'IA américains. Il reste valide à la date de publication de cet article : le Tribunal de l'UE a rejeté en septembre 2025 un recours en annulation, mais ce jugement fait l'objet d'un pourvoi accepté par la Cour de justice (affaire C-703/25 P), à l'issue encore inconnue — un rappel que le mécanisme précédent, le Privacy Shield, avait lui aussi été invalidé après coup, en 2020. À défaut d'adéquation, l'outil le plus courant reste les clauses contractuelles types de la Commission (article 46), utilisables uniquement dans leur version du 4 juin 2021 depuis le 27 décembre 2022, structurées en quatre modules selon la relation entre parties — pour un fournisseur d'IA sous-traitant, c'est le module 2 qui doit figurer au contrat. Depuis l'arrêt Schrems II, les signer ne suffit plus : il faut aussi évaluer si le droit du pays destinataire permet réellement de les respecter, et ajouter des mesures supplémentaires (chiffrement, restriction d'accès) sinon. Les règles internes d'entreprise (article 47) concernent surtout les grands groupes transférant entre filiales ; les dérogations de l'article 49 existent aussi, mais restent, par construction, pensées pour des situations ponctuelles plutôt que pour un flux permanent comme celui d'un callbot en production.

Avant de signer, la vérification est toujours la même : identifier chaque société qui traite la voix ou le texte de l'appelant, son pays d'établissement, le droit dont elle dépend, et le mécanisme du chapitre V qui couvre ce transfert — clause par clause dans le contrat, pas affirmé sur une plaquette commerciale. C'est un exercice que notre méthodologie de test intègre systématiquement, au même titre que la latence ou la qualité de la voix. Elle se fait normalement avant la signature, pas après une réclamation — un audit de ce type peut être engagé en amont via une demande de devis.

Questions fréquentes

Un callbot doit-il obligatoirement demander le consentement de l'appelant avant de commencer l'appel ?

Non, pas systématiquement : le consentement n'est que l'une des six bases légales prévues par le RGPD, et la plupart des callbots s'appuient sur l'exécution du contrat ou l'intérêt légitime. Ce qui reste obligatoire dans tous les cas, quelle que soit la base légale retenue, c'est d'informer clairement l'appelant dès le début de l'échange sur l'objectif poursuivi, l'éventuel enregistrement et le moyen de s'y opposer ou de parler à un humain. Le consentement explicite ne devient une quasi-obligation que dans un cas précis : si le système utilise la voix pour identifier ou authentifier la personne, pas pour simplement comprendre ce qu'elle dit.

La voix enregistrée par un callbot est-elle une donnée biométrique ?

Pas automatiquement. Un enregistrement vocal brut, utilisé pour transcrire ce que dit l'appelant et générer une réponse, reste une donnée personnelle ordinaire. Il ne devient une donnée biométrique au sens strict de l'article 9 du RGPD, avec son régime renforcé, que si un traitement technique spécifique en extrait une empreinte vocale utilisée pour identifier ou authentifier la personne de façon unique, comme dans un dispositif de reconnaissance du locuteur.

Combien de temps peut-on conserver l'enregistrement d'un appel avec un callbot ?

Il n'existe pas de durée unique fixée par la loi : le principe du RGPD est de ne pas conserver au-delà de ce qui est nécessaire à la finalité poursuivie. Pour des enregistrements utilisés à des fins de qualité, la CNIL retient un repère de six mois dans sa doctrine sur les centres d'appels ; pour un enregistrement conservé comme preuve de la formation d'un contrat, une durée alignée sur le délai de prescription civile, de l'ordre de cinq ans, est généralement admise. Ces deux finalités doivent être distinguées et ne pas être mélangées dans une même politique de conservation.

Les fournisseurs de reconnaissance vocale ou de modèle de langage utilisés par un callbot sont-ils forcément hors du champ du RGPD s'ils sont américains ?

Non, mais leur utilisation déclenche des obligations spécifiques du chapitre V du RGPD sur les transferts hors UE, à vérifier au cas par cas plutôt qu'à présumer réglées. Le mécanisme le plus courant aujourd'hui pour les entreprises américaines est le cadre d'adéquation UE-États-Unis, valide mais actuellement contesté devant la justice européenne ; à défaut, ce sont les clauses contractuelles types de la Commission européenne qui doivent être annexées au contrat. Le seul hébergement physique des serveurs en Europe ne suffit pas à écarter ce sujet si le fournisseur reste soumis à une loi étrangère à portée extraterritoriale.

En résumé

• La voix est une donnée personnelle dès le premier mot ; elle ne devient une donnée biométrique (article 9) que si elle sert à identifier ou authentifier la personne, pas pour simplement comprendre ce qu'elle dit.
• Enregistrer un appel exige une base légale précise (le plus souvent l'exécution du contrat ou l'intérêt légitime), un caractère non systématique, et une information donnée dès le début de l'échange.
• Le consentement explicite n'est une quasi-obligation que dans des cas particuliers, notamment la biométrie vocale ; ailleurs, l'obligation constante est l'information, pas le recueil d'un « oui » actif.
• La CNIL a publié des repères concrets de conservation pour les centres d'appels — de l'ordre de six mois pour un usage qualité, nettement plus long comme preuve contractuelle — transposables à un callbot.
• Les fournisseurs de STT, de LLM et de TTS sont, dans la quasi-totalité des cas, des sous-traitants au sens de l'article 28 : le contrat doit être signé avant le lancement, pas régularisé après coup.
• Le lieu d'hébergement des serveurs ne suffit pas : la loi dont dépend le fournisseur compte au moins autant, face à une législation étrangère à portée extraterritoriale.

Le RGPD ne rend pas un projet de callbot impossible ; il impose de documenter ces choix — base légale, durée de conservation, chaîne de sous-traitants, mécanisme de transfert — avant la mise en production, pas après une réclamation.