Votre agent vocal IA vient de recueillir le numéro de carte bancaire d'un client. Êtes-vous certain d'être en conformité PCI DSS ?
La plupart des équipes tech qui déploient un agent vocal IA savent qu'elles doivent respecter le RGPD. Beaucoup moins savent que dès que l'agent traite un paiement par téléphone - même en transmettant simplement les données à un prestataire externe - elles entrent dans le périmètre de la norme PCI DSS (Payment Card Industry Data Security Standard).
PCI DSS v4.0, obligatoire depuis avril 2024 avec des exigences renforcées applicables depuis mars 2025, durcit les règles sur les environnements automatisés, les logs d'inférence IA et la gestion des accès. Dans un callbot, le risque est triple : le LLM peut "voir" les données cartes si l'architecture est mal conçue, l'enregistrement de l'appel peut capturer le numéro vocal, et les logs applicatifs peuvent en stocker une trace.
Ce guide s'adresse aux CTOs, DSIs, responsables sécurité et équipes d'ingénierie qui déploient ou maintiennent des agents vocaux IA traitant des paiements. Il couvre les risques réels, les techniques de mitigation (DTMF masking, tokenisation, pause-reprise d'enregistrement), le déscoping PCI DSS, et une checklist de conformité actionnable.
PCI DSS v4.0 : scope et obligations pour un agent vocal IA
Tout système qui traite, stocke ou transmet des données de titulaire de carte (CHD - Cardholder Data) entre dans le périmètre PCI DSS. Un agent vocal IA qui demande un numéro de carte est immédiatement concerné.
PCI DSS est un standard de sécurité élaboré par le PCI SSC (Security Standards Council), fondé par Visa, Mastercard, American Express, Discover et JCB. Il s'impose contractuellement à toute organisation qui accepte, traite, stocke ou transmet des données de carte bancaire.
Les données concernées sont : le numéro de carte (PAN - Primary Account Number), le nom du titulaire, la date d'expiration, le code CVV/CVC, les données de piste magnétique et le PIN. Dans un contexte vocal, chacune de ces données peut transiter sous forme audio (prononcées par le client), sous forme DTMF (saisies au clavier du téléphone) ou sous forme de texte (transcrits par le STT puis traités par le LLM).
Les trois vecteurs de non-conformité spécifiques aux agents vocaux IA
1. Le LLM voit les données cartes dans la transcription STT. Si le client prononce son numéro de carte à voix haute et que le STT (Speech-to-Text) transcrit cette séquence avant de l'envoyer au LLM, les données PAN transitent en clair dans le prompt du modèle, dans les logs d'inférence, et potentiellement dans l'historique de conversation stocké en base. C'est une violation directe des exigences de stockage et de transmission PCI DSS.
2. L'enregistrement de l'appel capture les données de carte. Si l'appel est enregistré pendant la phase de saisie des données bancaires, l'enregistrement stocke en clair les sons DTMF ou la voix du client. PCI DSS interdit explicitement le stockage des données d'authentification sensibles après autorisation (exigence 3.3).
3. Les logs applicatifs conservent une trace des données. Les logs de débogage, les traces LangSmith/Langfuse, les journaux de la couche téléphonie peuvent enregistrer des fragments de transcription ou de flux DTMF incluant des données cartes si le système n'est pas conçu pour les exclure.
DTMF masking : comment protéger les données cartes dans le flux vocal IA
Le DTMF masking est la technique fondamentale qui permet à un agent vocal IA de traiter des paiements sans que le LLM, les enregistrements ou les logs ne voient jamais les données de carte bancaire.
DTMF (Dual-Tone Multi-Frequency) désigne les tonalités générées par les touches du téléphone. Chaque chiffre produit une combinaison de deux fréquences sonores distincte et reconnaissable. Sans protection, ces tonalités transitent dans le flux audio de l'appel - où elles peuvent être enregistrées, transcrites par le STT et transmises au LLM.
Comment fonctionne le DTMF masking
Le DTMF masking opère au niveau de la couche téléphonie (SIP, PSTN), avant que l'audio ne soit transmis aux systèmes applicatifs :
Étape 1 - Annonce de la phase sécurisée. L'agent vocal annonce que le client va entrer ses données de carte. Le LLM "sort" du flux actif : il ne génère plus de réponse et n'écoute plus la transcription STT.
Étape 2 - Capture DTMF à la couche téléphonie. La couche SIP/PSTN capture les tonalités DTMF directement depuis le signal téléphonique brut, avant tout traitement audio.
Étape 3 - Substitution (masquage). Dans le flux audio transmis aux autres systèmes (enregistreur, STT), les tonalités DTMF réelles sont remplacées par un son neutre uniforme (un bip unique ou du silence). Résultat : ni l'enregistrement ni le STT ne voient les vrais chiffres.
Étape 4 - Transmission directe au PSP. Les chiffres capturés par la couche téléphonie sont transmis directement au prestataire de paiement (PSP) certifié PCI DSS via un canal chiffré TLS. Le numéro de carte n'entre jamais dans les systèmes applicatifs de l'entreprise.
Étape 5 - Reprise conversationnelle. Le PSP retourne un statut (succès/échec/fraud) et un token de transaction. L'agent vocal reprend le flux conversationnel avec uniquement cette information : "Votre paiement de 89 € a bien été validé."
| Composant | Sans DTMF masking | Avec DTMF masking |
|---|---|---|
| LLM (prompt / contexte) | Voit le PAN transcrit | Ne voit jamais le PAN |
| Enregistrement appel | Contient les tonalités DTMF | Contient des bips neutres |
| Logs STT | Transcription du PAN oral | Aucune transcription de PAN |
| CRM / historique conversation | Risque de stockage du PAN | Stocke uniquement le token |
| Périmètre PCI DSS | Toute l'infrastructure IA | Uniquement la couche téléphonie + PSP |
Tokenisation des données de carte : principe et mise en œuvre
La tokenisation est complémentaire au DTMF masking. Elle s'applique après la collecte sécurisée des données : le PSP remplace le numéro de carte (PAN) par un token - un identifiant aléatoire, non réversible, propre à un marchand ou à une transaction.
Ce token peut ensuite être stocké librement dans le CRM, l'historique client ou les logs de l'agent vocal, sans risque PCI DSS : même volé, il est inexploitable sans la clé de déchiffrement du PSP, stockée dans un vault isolé que seul le PSP contrôle.
Cas d'usage concrets pour un agent vocal IA
Abonnement récurrent. Le client autorise une première fois le débit via l'agent vocal. Le PSP génère un token persistant pour ce client/marchand. Toutes les facturations suivantes utilisent ce token - sans jamais redemander le numéro de carte, sans jamais exposer le PAN dans l'infrastructure.
Remboursement post-appel. Un agent vocal qui initie un remboursement n'a besoin que du token de la transaction originale, stocké dans le CRM. Aucune donnée carte ne transite.
Vérification d'identité par carte. Certains scénarios d'authentification téléphonique utilisent les 4 derniers chiffres de la carte comme facteur de vérification. Avec la tokenisation, l'agent compare une référence masquée sans jamais stocker le PAN complet.
PSP compatibles avec les agents vocaux IA
Les PSP certifiés PCI DSS de niveau 1 compatibles avec une intégration en DTMF masking pour callcenter IA incluent Stripe (avec Stripe Terminal et DTMF customization), Adyen (Adyen for Platforms + telephony integration), Braintree (PayPal group), Worldpay et Ingenico. Vérifiez que le PSP propose une API de collecte DTMF en mode IVR et la génération de tokens persistants.
Pause et reprise automatique de l'enregistrement : obligation, pas option
L'exigence PCI DSS 3.3 interdit le stockage des données d'authentification sensibles après autorisation. Concrètement pour un callcenter IA : l'enregistrement de l'appel doit être suspendu automatiquement avant la saisie des données de carte et reprendre automatiquement après la confirmation du paiement.
Automatique, pas manuel. Dans un agent vocal IA, la pause d'enregistrement doit être déclenchée programmatiquement par l'agent au moment où il initie la phase de saisie sécurisée - pas laissée à l'appréciation d'un opérateur humain. L'automatisation est à la fois une nécessité de conformité et une protection opérationnelle : un agent humain peut oublier, un agent IA ne le peut pas si le code est correct.
Journalisation de la pause. Chaque événement de pause et de reprise doit être journalisé avec un horodatage précis, l'identifiant de l'appel et le motif (PCI DSS payment). Ces logs constituent la preuve d'audit en cas de contrôle.
Gestion des erreurs. Si le PSP retourne une erreur et que le client doit ressaisir ses données, la pause d'enregistrement doit rester active pendant toute la durée des tentatives. Un test de régression spécifique doit vérifier ce scénario.
Déscoping PCI DSS : sortir l'infrastructure IA du périmètre d'audit
Le déscoping PCI DSS est l'objectif architectural cible pour tout agent vocal IA traitant des paiements. Il consiste à construire le système de façon à ce que les composants IA (LLM, STT, TTS, CRM, enregistreur) ne soient jamais en contact avec des données de carte bancaire - et sortent donc du périmètre d'audit PCI DSS.
Avec une architecture déscoped correctement, seules deux couches restent dans le périmètre : la couche téléphonie qui capture les DTMF (typiquement un composant SIP dédié) et le PSP certifié. Tout le reste de l'infrastructure - serveurs LLM, bases de données CRM, enregistreur d'appels, dashboards - est hors scope.
Les bénéfices concrets du déscoping
Le réduction de la surface d'audit est le bénéfice principal : au lieu d'auditer l'intégralité de l'infrastructure IA, le QSA (Qualified Security Assessor) n'évalue que les deux composants dans le périmètre. Cela réduit le coût d'audit PCI DSS de 60 à 80 % et simplifie considérablement la maintenance de la conformité.
Le niveau de SAQ (Self-Assessment Questionnaire) cible devient SAQ A - le moins contraignant (22 exigences contre plus de 150 pour SAQ D), applicable quand les paiements sont entièrement externalisés à un PSP certifié et que les systèmes internes ne touchent jamais les données cartes.
| Architecture | SAQ applicable | Exigences | Coût audit estimé |
|---|---|---|---|
| LLM voit le PAN, enregistrement actif | SAQ D | Plus de 300 | 50 000 – 200 000 €/an |
| DTMF capturé en interne, PSP externe | SAQ B+ | Plus de 150 | 20 000 – 60 000 €/an |
| DTMF masking + déscoping total + PSP certifié | SAQ A | 22 | 2 000 – 8 000 €/an |
Checklist PCI DSS pour un agent vocal IA : 12 points critiques
| Point de contrôle | Exigence PCI DSS v4.0 | Statut à vérifier |
|---|---|---|
| DTMF masking activé pour toutes les saisies de carte | Req. 3.3, 4.2 | Configurer dans la couche SIP |
| LLM exclu du flux pendant la saisie | Req. 3.3, 3.4 | Test de régression dédié |
| Pause d'enregistrement automatique avant saisie | Req. 3.3.2 | Journalisation horodatée obligatoire |
| Aucune transcription STT des données PAN | Req. 3.3, 3.4 | Audit des logs STT |
| PSP certifié PCI DSS niveau 1 | Req. 12.8 | Vérifier le certificat AOC (Attestation of Compliance) |
| Tokenisation du PAN - stockage token uniquement dans CRM | Req. 3.5 | Audit base de données CRM |
| Transmission PSP via TLS 1.2 minimum | Req. 4.2.1 | Scan de configuration TLS |
| Logs applicatifs purgés de tout fragment PAN | Req. 3.3.1 | Grep automatique en CI/CD |
| Contrôle d'accès aux composants dans le périmètre PCI | Req. 7, 8 | Principe du moindre privilège |
| Surveillance et alerting sur les accès aux composants PCI | Req. 10 | SIEM ou équivalent |
| Tests de pénétration annuels sur la couche de collecte DTMF | Req. 11.4 | Prestataire certifié QSA ou ASV |
| Plan de réponse aux incidents incluant le scénario de fuite de données carte | Req. 12.10 | Exercice de simulation annuel |
TALKR : des agents vocaux IA natifs PCI DSS
La plateforme TALKR intègre nativement le DTMF masking, la pause-reprise automatique d'enregistrement et l'intégration avec les PSP certifiés PCI DSS niveau 1. Vos agents vocaux IA peuvent traiter des paiements par téléphone sans que votre infrastructure IA n'entre dans le périmètre d'audit.
Notre équipe technique peut auditer votre architecture de paiement vocal actuelle et identifier les écarts de conformité avant votre prochain audit PCI DSS.
Demander un audit conformité paiementQuestions fréquentes - PCI DSS et agent vocal IA
PCI DSS s'applique-t-il à un agent vocal IA qui collecte des paiements par téléphone ?
Oui, sans exception. Dès qu'un système traite, stocke ou transmet des données de titulaire de carte (numéro PAN, CVV, date d'expiration, nom), il entre dans le périmètre PCI DSS. Un agent vocal IA qui recueille un numéro de carte bancaire par téléphone est soumis aux mêmes exigences qu'un système de paiement classique. PCI DSS v4.0, applicable depuis avril 2024, renforce même les exigences d'authentification et de surveillance des environnements automatisés.
Qu'est-ce que le DTMF masking et pourquoi est-ce essentiel pour un callbot IA ?
Le DTMF masking substitue les sons DTMF générés par les touches du téléphone par un son neutre uniforme avant qu'ils atteignent le flux audio traité par le LLM et les systèmes d'enregistrement. Résultat : les chiffres de la carte ne transitent jamais en clair dans le flux vocal. La saisie est capturée directement par la couche téléphonie et redirigée vers le PSP certifié PCI DSS - sans que le LLM, les logs ou l'enregistrement ne voient jamais les données sensibles.
Peut-on enregistrer un appel pendant la saisie d'un paiement ?
Non. La norme PCI DSS interdit d'enregistrer les données d'authentification sensibles après autorisation. L'enregistrement doit être mis en pause automatiquement dès que le client entre ses données de carte, et reprendre uniquement après la confirmation de paiement. Cette pause doit être déclenchée par l'agent vocal IA de façon automatique et journalisée pour les audits.
Qu'est-ce que le déscoping PCI DSS pour un callcenter IA ?
Le déscoping consiste à architecturer le système de façon à ce que les données de carte ne transitent jamais par les composants non certifiés (LLM, enregistreur, CRM). Avec DTMF masking + tokenisation + pause d'enregistrement automatique, l'agent vocal IA et son infrastructure sortent du périmètre PCI DSS. Seule la couche de collecte DTMF et le PSP restent en scope - réduisant la surface d'audit et les obligations de conformité de plus de 80 %.
Qu'est-ce que la tokenisation et comment protège-t-elle les données de carte dans un agent vocal IA ?
La tokenisation remplace le numéro de carte (PAN) par un identifiant aléatoire non réversible (le token) dès la saisie. Ce token est utilisé pour toutes les opérations ultérieures sans que le PAN réel ne soit jamais stocké dans les systèmes de l'entreprise. Seul le PSP certifié détient la correspondance token/PAN. Même en cas de fuite de données du CRM ou des logs de l'agent, les données bancaires sont inexploitables.
Quelles sont les sanctions en cas de non-conformité PCI DSS pour un agent vocal IA ?
Les sanctions sont contractuelles : les réseaux de cartes peuvent infliger des amendes de 5 000 à 100 000 € par mois à la banque acquéreuse, répercutées sur le commerçant. En cas de violation avérée, des pénalités de 50 à 90 $ par carte compromise s'ajoutent. À cela s'ajoutent les risques RGPD (les données bancaires sont des données personnelles) avec des amendes CNIL pouvant atteindre 4 % du CA mondial, et la perte de l'autorisation d'accepter les cartes bancaires.
Le LLM d'un agent vocal peut-il voir les données de carte bancaire pendant un paiement ?
Non, avec une architecture conforme. La séquence correcte est : l'agent annonce la phase sécurisée, la couche téléphonie capture les DTMF directement, le flux audio envoyé au LLM contient des bips neutres, le PSP valide et retourne un statut, puis le LLM reprend la conversation avec uniquement le résultat. Le LLM, les logs d'inférence et l'historique de conversation ne contiennent à aucun moment de données PAN.
Quelle différence entre PCI DSS SAQ A et SAQ D pour un callcenter avec agent vocal IA ?
SAQ A (22 exigences) s'applique quand les paiements sont entièrement externalisés à un PSP certifié et que les systèmes internes ne traitent jamais de données cartes - c'est le cas avec une architecture DTMF masking + déscoping complet. SAQ D (plus de 300 exigences) couvre les systèmes qui stockent ou traitent des données PAN en interne. Viser SAQ A est l'objectif optimal pour un agent vocal IA : moins coûteux à auditer, plus simple à maintenir.