Aller au contenu principal
Quel Support Client

Données et gouvernance

Numéros de carte dans le support

Pour qui : Marchand dont les clients envoient parfois leur numéro de carte dans un e-mail ou un chat.

FAQ PCI SSC, dont une d'octobre 2012 sur la réception non prévue et une d'août 2025, et CNIL, lues par extraction automatique le 3 novembre 2026. Texte de la norme non lu. Ceci n'est pas un conseil de conformité.

Notre avis

Écrivez une consigne et une macro, puis préparez une réaction. Le PCI SSC est clair : un numéro de carte non protégé ne doit pas passer par e-mail, messagerie, SMS ou chat. Il n'interdit pas de les recevoir par ces canaux, mais le canal entre alors dans le périmètre PCI DSS, avec toutes les exigences applicables. Si un numéro arrive sans que ce canal soit prévu pour cela, retirez-le immédiatement ou sécurisez-le, et ne répondez pas en le reprenant. Le cryptogramme, lui, ne doit jamais rester.

Dans l’ordre

  1. Ne pas les recevoir
  2. Masquer si un numéro arrive
  3. Ne pas répondre en le reprenant

Pourquoi

  • Un canal qui reçoit un PAN entre dans le périmètre
  • Le coût de protéger un canal entier dépasse vite celui d'une macro

Ce qui change le choix

Paiement par agent très encadré, dans un canal protégé pour cela : ce n'est plus un sujet de ticket.

Ce que disent les textes lus

FAQ du PCI SSC et CNIL. La norme PCI DSS elle-même n'a pas été lue.
PointSourceConséquence pour le support
PAN non protégés par e-mail, messagerie, SMS, chatPCI SSC : non (exigences 4.2.1 et 4.2.2)Vous ne devez pas en envoyer
Recevoir par ces canauxPCI SSC : pas interdit, si le canal est protégé selon toutes les exigences ; il entre dans le périmètreVotre helpdesk et ses systèmes peuvent entrer dans le périmètre
Réception non prévuePCI SSC : retirer immédiatement ou sécuriser, sécuriser ou fermer le canal, éviter de répondre en reprenant les donnéesUne procédure, pas un réflexe
Données d'authentification, dont le cryptogrammePCI SSC 3.3.1 : interdites après autorisation, même chiffrées ; CNIL, vente à distance à un consommateur : cryptogramme interdit après la première transactionÀ retirer sans discussion
Copie de carteCNIL, vente à distance à un consommateur : non demandable ; masquage ou tokenisationRetirez ce réflexe de vos macros

La procédure

  1. Si un numéro arrive. Retirez-le du ticket si l'outil le permet, ou signalez-le à la personne qui le peut. Consignez ce qui a été fait, sans recopier le numéro, puis sécurisez ce canal ou bloquez son usage pour les données de carte.
  2. La réponse au client. « Pour votre sécurité, nous avons retiré le numéro de votre demande. Ne l'envoyez plus par ce canal : voici le lien de paiement. » Ne citez aucun chiffre.
  3. En amont. Formulaire avec un avertissement, macro de paiement avec un lien, formation courte de l'équipe.
  4. Si l'agent IA lit les tickets. Vérifiez qu'un numéro n'alimente ni ses réponses, ni ses journaux, ni ses sous-traitants.

Notre conseil, et sa limite

La fonction de masquage d'un éditeur est utile, mais elle intervient après coup et rien ne dit qu'elle voit tout : pièces jointes, captures d'écran, notes internes. Nous n'avons pas établi ces fonctions par éditeur. Faites-vous donc écrire ce qui est masqué et sur quel plan. Ne pas recevoir est un avis de notre part, pas une règle citée. Si votre activité exige un paiement avec un agent, c'est un projet à part, à cadrer avec votre prestataire de paiement, et non une fonction de helpdesk.

Limites

FAQ du PCI SSC, pas la norme. Position CNIL sur la réception dans un ticket non trouvée. Fonctions de masquage par éditeur non établies. Rien de ceci n'évalue votre conformité : votre acquéreur ou un évaluateur qualifié peut seul le faire.

Prochaine action

Cherchez de longues suites de chiffres, sans vous limiter à seize, dans vos derniers tickets avec votre outil, écrivez la macro de réponse, et demandez à votre éditeur ce qu'il masque.

Preuves et sources

Ce qui relève d’un fait lu, d’une déclaration, de notre calcul, de notre méthode ou de notre avis. Notre méthode