# Données bancaires en service client : limiter ce qu’un dossier doit contenir Un exemple défensif de rédaction d’un dossier support sans copier des données bancaires complètes ni des transactions inutiles. - URL canonique: https://www.harmate.com/fr/blog/données-bancaires-en-service-client-limiter-ce-quun-dossier-doit-contenir - Auteur: Harmate Team - Publié le: 2026-11-15 - Mise à jour: 2026-11-15T01:49:45.557765+00:00 - Langue: fr ## Contenu # Données bancaires en service client : limiter ce qu’un dossier doit contenir Lorsqu’un client signale un paiement en double, une capture d’écran peut contenir bien plus que ce dont le conseiller a besoin. Une bonne note conserve les éléments utiles à la vérification et évite de recopier les informations bancaires complètes ou les transactions sans rapport. L’exercice ci-dessous est fictif : il propose un contrôle défensif de rédaction, pas une conclusion juridique ni une garantie de conformité. ## Partir de la décision à prendre Alex signale deux lignes de 42,80 € dans son application bancaire pour une commande donnée. Le message transmis au service client contient un numéro de carte complet, une date d’expiration et une capture où apparaissent aussi des achats personnels. Dans ce scénario, la politique interne fictive autorise le dossier support à conserver une référence de commande, un montant, une date, un statut de paiement et une référence de transaction. Elle exclut les identifiants de paiement complets et l’historique de transactions sans rapport. La question de travail est précise : le registre marchand comporte-t-il une ou deux opérations pour cette commande ? La note n’a pas besoin de raconter toute la situation financière du client pour permettre cette vérification. ## Réécrire la note de cas Une première version pourrait recopier la carte complète et décrire les autres achats visibles. Cette copie augmente la quantité d’information exposée sans aider à compter les événements du commerçant. Une version de travail plus limitée indique : > Dossier CS-2033. Le client signale deux lignes de 42,80 € pour la commande OR-2033, le 15 novembre. La vue de paiement marchand montre un encaissement, référence TX-990, vérifié à 10 h 26. La capture d’écran du client n’a pas été copiée dans le dossier. Vérifier auprès de l’équipe Paiements si la seconde ligne correspond à une opération distincte du marchand ou à une entrée en attente affichée par la banque. Propriétaire : équipe Paiements. Prochain point au client avant 16 h, selon le plan fictif de cette équipe. La note garde la référence de commande, le montant, la date, l’observation dans la source consultée et son heure. Elle retire le numéro complet, la date d’expiration et les transactions sans rapport. Le point de 16 h est une promesse propre au scénario ; une équipe réelle doit annoncer un délai qu’elle est autorisée et capable de tenir. ## Contrôle rapide avant enregistrement Avant d’enregistrer une note, demandez-vous : 1. Quelle décision l’équipe doit-elle prendre ? 2. Quels champs minimaux permettent de la prendre et d’identifier la source consultée ? 3. Une donnée bancaire complète, un code de sécurité, une image entière ou un achat sans rapport a-t-il été recopié sans nécessité démontrée ? 4. Quel rôle est autorisé à faire la vérification suivante ? 5. Quelle procédure approuvée s’applique au message ou à la pièce jointe déjà reçue ? Si l’équipe ne connaît pas la procédure pour traiter une pièce sensible, elle ne doit pas inventer une règle de suppression ou de conservation. Il faut arrêter sa recopie et demander au responsable désigné quelle voie approuvée utiliser. Une note réduite ne prouve pas que toutes les copies ont été supprimées des systèmes. ## Conserver une trace utile, pas une copie de tout Le but n’est pas de retirer les éléments nécessaires à l’enquête : une référence de transaction et le résultat vérifié dans le registre marchand peuvent être indispensables. Il s’agit de relier la note à la décision et à son propriétaire, tout en évitant de diffuser des données qui n’aident pas à répondre. Cet exemple illustre une seule situation avec des champs et une politique inventés. Il ne définit pas une liste universelle de données autorisées, ne garantit aucune protection et ne décrit aucune fonction Harmate. Avant d’adopter ces champs, vérifiez les consignes internes et les obligations applicables à votre organisation. Pour travailler sur le passage de cette note entre équipes, voyez le [cas de transfert à rédiger](https://www.harmate.com/fr/blog/tester-un-chatbot-sur-plusieurs-tours). Le [modèle de persona](https://www.harmate.com/fr/blog/mod%C3%A8le-de-persona-synth%C3%A9tique-une-fiche-minimale-pour-tester-un-assistant-ia) permet de répéter l’exercice avec des coordonnées entièrement fictives.