RGPD & callbots : enregistrer, transcrire, résumer sans se piéger

La vérité simple : un callbot traite plus que des mots

Un callbot, c’est une conversation téléphonique.

Sauf qu’en 2026, une conversation téléphonique, c’est souvent :

• un flux audio (parfois enregistré),
• une transcription (parfois en streaming),
• un résumé (souvent généré),
• des événements (barge-in, transferts, silences),
• des métadonnées (numéro appelant, durée, file d’attente, agent transféré),
• et parfois des actions (création de ticket, consultation CRM).

Autrement dit : ce n’est pas un traitement, c’est une chaîne de traitements.

Si vous cherchez d’abord à comprendre le fonctionnement général d’un callbot (pipeline STT→LLM→TTS vs Speech-to-Speech), commencez par notre guide : Callbot IA : le guide complet. Ici, on parle gouvernance et conformité : ce qu’on oublie en démo… et qu’on découvre en audit.

Le RGPD en callbot : ce que vous devez cadrer dès le début

Les discussions RGPD autour des callbots tournent souvent autour de “peut-on enregistrer ?”.

La bonne question est plutôt :

“Qu’est-ce que je collecte exactement, pourquoi, pendant combien de temps, avec quelles garanties, et avec quels droits pour les personnes ?”

Les types de données typiques d’un callbot

Enregistrement d’appels : informer clairement (et ne pas faire semblant)

En France, la CNIL rappelle des principes de base : si vous enregistrez, vous devez informer les personnes (et pas en police taille 6 dans un PDF enterré). La CNIL répond explicitement à des questions du type “ai-je le droit d’enregistrer des conversations téléphoniques ?” et détaille les conditions d’information et les bonnes pratiques selon les finalités.¹

L’enregistrement, ce n’est pas “un bouton”. C’est une finalité.

Quelques finalités courantes (et non exclusives) :

• preuve de consentement / preuve contractuelle,
• amélioration qualité / formation,
• conformité (ex. obligations spécifiques selon secteur),
• lutte contre fraude,
• gestion de litiges.

La CNIL distingue notamment l’enregistrement à fin de preuve (ex. formation d’un contrat) et rappelle des exigences (dont durée de conservation, accès restreints, etc.).²

Le piège : enregistrer “parce qu’on peut”

Techniquement, tout est enregistrable.

Mais en pratique, plus vous enregistrez :

• plus vous stockez des données sensibles,
• plus vous augmentez la surface d’attaque,
• plus vous augmentez la charge opérationnelle (droits d’accès, suppression, etc.),
• plus vos sous-traitants deviennent un sujet (contrats, audits, transferts).

Autrement dit : l’enregistrement doit être justifié et gouverné, pas “activé”.

1

Lister les finalités

Écrivez pourquoi vous enregistrez (preuve, qualité, fraude...). Une finalité = un besoin = un périmètre.

2

Décider ce qui est stocké

Audio brut ? Transcription ? Résumé ? Événements ? Choisissez le minimum nécessaire.

3

Établir la rétention

Définissez des durées (et des règles) par finalité. Sans ça, vous stockez “au cas où”.

4

Encadrer les accès

Qui peut écouter ? Lire ? Exporter ? Réutiliser ? Les droits doivent être stricts et auditables.

5

Préparer les droits RGPD

Accès, rectification, effacement, opposition : qui répond, comment, sous quel délai.

Transcription et résumés : l’audio devient du texte… et les risques changent

Un point contre-intuitif : transcrire réduit parfois certains risques (on manipule moins d’audio), mais en crée d’autres.

Parce que le texte :

• est plus facile à chercher,
• plus facile à copier,
• plus facile à partager,
• et plus facile à “rejouer” dans un LLM.

Résumés LLM : l’outil utile qui peut devenir dangereux

Un résumé d’appel est une arme de productivité :

• meilleure reprise par un agent,
• meilleure création de ticket,
• meilleur suivi.

Mais un résumé LLM peut aussi introduire :

• des erreurs (résumé incomplet),
• des interprétations (“le client est agressif”),
• et des “faits” inventés si vous ne contrôlez pas l’ancrage (hallucinations).

Si vous n’avez pas encore cadré les garde-fous et la sécurité LLM, lisez : Sécurité callbot : prompt injection & spoofing et Observabilité callbot.

La recommandation pragmatique : séparer “résumé conversationnel” et “données factuelles”

Dans un callbot, vous avez deux classes d’informations :

1. les faits (numéro client, date de naissance, montant, action effectuée),
2. la narration (le client explique, nuance, conteste, hésite).

Un bon design consiste à :

• stocker les faits dans des champs structurés (après confirmation),
• stocker la narration dans un résumé court,
• et garder la transcription (si nécessaire) en accès restreint.

Enregistrement et consentement : un exemple de script “propre”

Vous avez probablement déjà entendu :

“Votre appel est susceptible d’être enregistré à des fins d’amélioration.”

Cette phrase est une tradition orale. Elle n’est pas toujours suffisante.

La CNIL rappelle que l’information doit être claire et compréhensible, et adaptée à votre finalité.¹

Un script de callbot qui vise la clarté (exemple fictif) :

“Bonjour, je suis l’assistant vocal de [Entreprise]. Pour traiter votre demande, je vais transcrire ce que vous dites. Cet appel peut être enregistré pour [finalité]. Vous pouvez demander à parler à un conseiller à tout moment.”

Vous pouvez l’adapter, mais gardez l’esprit :

• dire ce que vous faites (transcrire, enregistrer),
• dire pourquoi (finalité),
• dire quelles options existent (conseiller, opposition selon cas).

Et surtout : ce script doit refléter la réalité technique. Dire “susceptible” quand vous enregistrez toujours, c’est une mauvaise habitude.

La biométrie vocale : cas à part (et souvent hors scope “callbot”)

Il y a un point que beaucoup d’équipes découvrent trop tard :

la voix peut être une donnée biométrique.

La CNIL définit les données biométriques et rappelle que leur traitement est “à encadrer strictement”, avec des exigences spécifiques et une analyse de conformité renforcée selon les cas d’usage.³

Traduction callbot :

• faire parler un callbot, ce n’est pas de la biométrie,
• identifier une personne par sa voix peut devenir un traitement biométrique,
• et ça change la nature du projet.

Pour l’authentification sans biométrie, lisez aussi : Authentification callbot : KBA, OTP, biométrie vocale.

Les droits des personnes : préparez-les avant le go-live (sinon vous improviserez)

Le RGPD, ce n’est pas seulement “de la paperasse”. C’est un ensemble de droits concrets :

• demander l’accès,
• demander l’effacement,
• contester,
• s’opposer,
• obtenir des informations.

En callbot, un problème classique :

“On a l’audio quelque part… mais on ne sait pas le retrouver.”

Ou :

“On a la transcription… mais elle est dans les logs d’un prestataire.”

Ou, pire :

“On a entraîné un modèle sur des données… et on ne sait plus quoi supprimer.”

La bonne pratique : vous devez savoir répondre à ces questions :

• Où sont stockées les données (audio, texte, résumés) ?
• Qui est responsable ? Qui est sous-traitant ?
• Combien de temps ? Et comment purge-t-on ?
• Quel est le process de réponse à une demande ?

Les sous-traitants (STT/TTS/LLM) : ce que vous devez cadrer contractuellement

Quand vous utilisez des APIs STT/TTS/LLM, vous impliquez des sous-traitants.

Vous devez cadrer :

• les responsabilités,
• les durées de conservation chez eux,
• les usages secondaires (ex. amélioration de modèles),
• la localisation / transferts éventuels,
• la sécurité et l’auditabilité.

Et, côté produit, vous devez être capable de changer de fournisseur si nécessaire.

Ce n’est pas seulement une stratégie de prix. C’est une stratégie de conformité.

Un point qui revient souvent en pratique : les sous-traitants “voix + IA” ont parfois des chaînes de sous-traitance (hébergement, analytics, support). Demandez la liste des sous-traitants ultérieurs, les options de rétention, et les engagements sur l’usage des données (ex. pas d’entraînement sur vos données sans accord explicite). Et gardez une règle simple : si vous ne pouvez pas expliquer où passent vos transcriptions et combien de temps elles vivent, vous n’êtes pas prêt pour l’échelle.

DPIA (AIPD) : quand la faire (et pourquoi vous devriez y penser tôt)

Dans les projets callbot, la question “doit-on faire une AIPD/DPIA ?” revient vite.

Pourquoi ? Parce qu’un callbot peut cocher plusieurs cases “risque” :

• collecte audio + transcription,
• automatisation à grande échelle,
• analyse (résumés, catégorisation, éventuellement scoring),
• et parfois des données sensibles (santé, finance, litiges).

L’EDPB (ex-G29) traite des assistants vocaux et insiste sur la nécessité d’évaluer correctement les risques, notamment quand on combine collecte vocale et traitements avancés (profilage, stockage, etc.).⁴

Et côté CNIL, l’AIPD est précisément l’outil de référence pour analyser les risques d’un traitement susceptible d’engendrer des risques élevés, et documenter vos mesures de réduction de risques.⁷

Comment penser une DPIA “callbot” (sans en faire un roman)

Une DPIA utile répond à des questions simples :

• Quelles données, exactement ? (audio, transcript, résumé, métadonnées)
• Quelles finalités ? (service, preuve, qualité, fraude)
• Quels sous-traitants ? (téléphonie, STT, LLM, TTS)
• Quels accès ? (agents, QA, data team)
• Quelles durées ? (rétention/purge)
• Quels risques ? (fuite, erreur, mauvaise attribution, biais)
• Quelles mesures ? (minimisation, chiffrement, RBAC, redaction, logs)

Le piège est de faire une DPIA “administrative”.

Une bonne DPIA callbot est un document qui vous aide à :

• décider quoi enregistrer et quoi éviter,
• cadrer les résumés LLM (et leurs limites),
• formaliser des règles de purge,
• et expliquer le système en cas d’audit.

Le playbook “callbot conforme” (pratique et actionnable)

Voici une checklist que vous pouvez citer, imprimer, et coller au mur.

A) Cadrage

• Finalités documentées (enregistrement, transcription, résumé, QA, preuve...).
• Données collectées listées (audio, transcript, événements, métriques).
• Minimisation : le strict nécessaire.

B) Expérience utilisateur

• Message d’information clair (callbot + IVR si besoin).
• Option “parler à un conseiller”.
• Gestion des données sensibles (ex. éviter de dicter un IBAN à l’oral si canal alternatif).

C) Technique & sécurité

• Séparation des environnements (prod / test).
• Chiffrement en transit et au repos.
• Accès restreints (RBAC), audit logs.
• Masquage/redaction de PII dans les logs quand possible.

D) Rétention

• Durées par type de données (audio, transcript, résumé).
• Purge automatique vérifiée (pas “à la main”).
• Archivage justifié si nécessaire (preuve).

E) Gouvernance

• Process de demandes RGPD (accès/suppression).
• Contrats sous-traitants (STT/TTS/LLM/telephony) vérifiés.
• Registre des traitements + DPIA si requis (selon risques).

FAQ

Questions frequentes

Puis-je enregistrer tous les appels de mon callbot 'pour améliorer l’IA' ?+

La CNIL rappelle que l’enregistrement doit être justifié par une finalité claire, que l’information des personnes est nécessaire, et que la durée de conservation doit être limitée. Plus vous élargissez la finalité (“améliorer l’IA” est large), plus la gouvernance et la minimisation deviennent critiques.¹

Transcrire sans enregistrer l’audio : est-ce 'plus simple' ?+

Ça réduit certains risques (moins d’audio stocké), mais le texte reste une donnée personnelle (souvent plus facile à copier/rechercher). L’important est de minimiser, sécuriser, limiter la rétention et cadrer les accès.

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

Pas automatiquement. La CNIL définit la biométrie comme un traitement visant à identifier une personne de manière unique via des caractéristiques physiques/comportementales. L’usage de la voix pour authentifier/identifier peut entrer dans ce cadre et requiert une vigilance renforcée.³

Et si je fais des résumés LLM : dois-je informer ?+

Oui, si vous traitez les données (transcription/résumé) pour fournir le service, l’information doit être claire sur ce que vous faites (transcrire, analyser, éventuellement enregistrer), et sur les finalités. Une bonne pratique produit est d’expliquer simplement au téléphone (et dans vos mentions) ce que fait le callbot.

Sources et references

1. [1]CNIL, “AI-je le droit d’enregistrer des conversations téléphoniques ?”
2. [2]CNIL, “Enregistrer les conversations téléphoniques pour prouver la formation d’un contrat”.
3. [3]CNIL, “Biométrie : de quoi parle-t-on ?”.
4. [4]EDPB, “Guidelines 02/2021 on virtual voice assistants” (version 2.0).
5. [5]Microsoft Learn, “Privacy guidelines for call recording” (Dynamics 365).
6. [6]CNIL, recommandation MFA / authentification multifacteur.
7. [7]CNIL, “Analyse d’impact relative à la protection des données (AIPD/DPIA)”.