Fraude à la carte bancaire « avec le code » : pourquoi la banque doit prouver bien plus (et souvent rembourser)

« Mon code a été utilisé » : la banque peut-elle vraiment refuser de rembourser ?

La réponse tient en une phrase : non, pas sur ce seul fondement. Le point de départ de tout litige d’opération non autorisée est l’article L.133-23 du Code monétaire et financier. Son économie est limpide : dès lors que le client nie avoir autorisé une opération, ce n’est pas à lui de prouver qu’il n’a rien fait, c’est à la banque de prouver qu’il a autorisé — ou qu’il a gravement manqué à ses obligations.

Le texte mérite d’être lu mot à mot, car il anticipe précisément l’argument bancaire :

Tout est dans la phrase soulignée. Le législateur a expressément prévu que le simple fait, pour la banque, d’avoir enregistré dans ses systèmes l’usage de la carte et la composition du code ne suffit pas à établir l’autorisation. Le journal interne de la banque n’est pas une vérité révélée : c’est un élément de preuve, soumis à l’appréciation du juge, et qui peut être contredit.

Le reste du dispositif en découle logiquement. L’article L.133-18 impose à la banque, lorsqu’une opération non autorisée lui est signalée à temps, de rembourser immédiatement le montant débité et de rétablir le compte dans l’état où il se serait trouvé si l’opération n’avait pas eu lieu. La banque ne peut échapper à cette obligation qu’en rapportant la preuve — c’est toujours elle qui la supporte — soit d’une autorisation, soit, pour écarter le remboursement, d’une négligence grave ou d’une fraude du titulaire (art. L.133-19, IV).

Deux dispositions de l’article L.133-19, souvent négligées, visent précisément les scénarios de fraude technique. D’abord le II : la responsabilité du payeur n’est pas engagée lorsque l’opération a été effectuée en détournant, à son insu, l’instrument de paiement ou les données qui lui sont liées, ni en cas de contrefaçon de l’instrument si le payeur était, au moment de l’opération, en possession de sa carte. Le législateur a donc expressément envisagé le clonage et le détournement de données — et en a fait peser les conséquences sur la banque, non sur la victime. Ensuite le V : sauf fraude du payeur lui-même, celui-ci ne supporte aucune conséquence financière si l’opération a été réalisée sans que la banque ait exigé une authentification forte (renvoi à l’article L.133-44).

La Cour de cassation veille à ce que ces règles ne soient pas vidées de leur sens. Dans un arrêt publié au Bulletin, la chambre commerciale juge que la preuve, par la banque, d’une fraude ou d’une négligence grave du client « ne peut se déduire du seul fait que l’instrument de paiement ou les données personnelles qui lui sont liées ont été effectivement utilisés » (Cass. com., 18 janvier 2017, n° 15-18.102). Rendu à propos d’un paiement en ligne détourné par hameçonnage, cet arrêt énonce une règle générale, valable pour tout moyen de paiement. Autrement dit : « le code a été composé » n’est pas un raisonnement, c’est une pétition de principe.

Le « Magic DAB » existe-t-il ? La carte à puce est-elle inviolable ?

Face à un client qui conteste un retrait ou un paiement, certains défenseurs des banques avancent un argument devenu un véritable slogan de prétoire : le « Magic DAB » — comprendre, un dispositif qui permettrait de retirer ou de payer sans la véritable carte et son code — n’existerait pas. De cette prémisse, ils tirent une conclusion radicale : la carte à puce serait inviolable, donc, dès lors qu’une opération est passée « avec le code », c’est nécessairement la victime qui a fauté — code noté quelque part, carte mal surveillée, voire complicité.

Ce raisonnement repose tout entier sur un présupposé technique : l’inviolabilité de la carte. Or ce présupposé est faux. Il l’est juridiquement, puisque la loi refuse précisément d’ériger l’usage du code en preuve d’autorisation. Il l’est surtout techniquement, comme le démontre, depuis 2010, une littérature scientifique abondante et convergente.

Comment une carte peut-elle être utilisée sans le vrai code ?

Le présupposé de la banque — « si le terminal indique que le code a été vérifié, c’est que le porteur l’a saisi » — est démenti par la recherche depuis 2010. Le maillon faible n’est pas le secret du code lui-même ; c’est le fait que, dans plusieurs scénarios documentés et testés, le terminal enregistre une vérification du porteur qui n’a jamais réellement eu lieu. Passons en revue les principaux travaux.

2010 : peut-on faire accepter un faux code ? (l’attaque « no-PIN »)

Dès 2010, l’équipe de Steven J. Murdoch et Ross Anderson (université de Cambridge), dans un article au titre éloquent — « Chip and PIN is Broken », présenté à la conférence IEEE Security & Privacy — a décrit une attaque de type man-in-the-middle. Un petit dispositif intercalé entre la carte et le terminal intercepte la demande de vérification du code et répond lui-même au terminal que le code est « correct », sans avoir jamais eu besoin de le connaître. La faille de fond : la réponse de la carte à la demande de vérification du code n’est pas authentifiée. Le terminal — et donc le journal de la banque — enregistre alors une transaction « par code » pour une carte volée dont le voleur ignore tout du code. Cette attaque est créditée d’une fraude d’environ 600 000 € commise en France et en Belgique en 2010-2011.

2012 : un clonage peut-il être invisible dans les relevés ? (l’attaque « pre-play »)

En 2012, la même équipe (Bond, Choudary, Murdoch, Skorobogatov, Anderson), dans « Chip and Skim : cloning EMV cards with the pre-play attack », a mis au jour une faiblesse plus insidieuse encore. La sécurité de chaque transaction repose sur un « nombre imprévisible » censé garantir sa fraîcheur, c’est-à-dire empêcher qu’une réponse de carte capturée puisse être rejouée plus tard. Or de nombreux distributeurs et terminaux généraient ce nombre avec de simples compteurs ou horodatages — donc parfaitement prévisibles. Un fraudeur disposant un instant de la carte (par exemple dans un commerce complice) peut alors précalculer les codes d’autorisation pour une transaction future.

La conséquence est décisive sur le plan probatoire : l’attaque est indiscernable d’un clonage du point de vue des journaux dont dispose la banque émettrice. Les chercheurs relient explicitement leur découverte aux dossiers dans lesquels des victimes se voyaient refuser tout remboursement au motif qu’« une carte EMV ne peut pas être clonée » — argument que leurs travaux ruinent. Ils relèvent aussi un point que tout praticien rencontre : certaines banques refusent de produire les journaux de transaction, voire les effacent pendant le litige, laissant le client argumenter sur des généralités.

2020-2021 : le sans contact rend-il le code inutile ?

Les travaux les plus retentissants sont ceux de David Basin, Ralf Sasse et Jorge Toro-Pozo (ETH Zurich). Dans « The EMV Standard : Break, Fix, Verify » (IEEE Security & Privacy, 2021), ils formalisent l’intégralité du protocole EMV à l’aide d’un outil de vérification automatique et démontrent que, en sans contact Visa, la méthode de vérification du porteur n’est ni authentifiée ni protégée contre la modification. Leur application Android, agissant en man-in-the-middle, fait croire au terminal que « la vérification du porteur a été réalisée sur l’appareil » (un téléphone) — de sorte qu’aucun code n’est demandé, y compris au-dessus du plafond qui devrait l’exiger. Les auteurs ont validé l’attaque sur de vrais terminaux en magasin, par exemple pour un paiement d’environ 190 dollars. Leur conclusion est sans détour : « le code est inutile dans les transactions Visa sans contact ».

La même équipe a étendu l’attaque à Mastercard dans « Card Brand Mixup Attack » (USENIX Security, 2021) : en faisant passer, du point de vue du terminal, une carte Mastercard pour une carte Visa, ils contournent le code y compris sur des cartes jusque-là réputées protégées, avec une transaction de plus de 400 dollars sur une carte de débit Maestro. Ils ont prolongé ces résultats en 2023 (« Inducing Authentication Failures to Bypass Credit Card PINs », USENIX Security).

S’agit-il de cas isolés ou d’un problème structurel ?

Ces résultats ne sont pas des curiosités de laboratoire. Ils s’inscrivent dans plus de quinze ans de publications concordantes, issues des meilleures conférences mondiales de sécurité informatique et passées par une évaluation par les pairs. Cette convergence est, en elle-même, un fait probant. On peut notamment citer :

• Murdoch, Drimer, Anderson, Bond, « Chip and PIN is Broken » (IEEE S&P 2010) — la démonstration fondatrice de l’attaque « no-PIN ».
• Emms, Arief, Freitas, Hannon, van Moorsel (université de Newcastle), « Harvesting High Value Foreign Currency Transactions from EMV Contactless Credit Cards Without the PIN » (ACM CCS 2014) — des paiements sans contact en devises étrangères réalisables au-delà du plafond, sans code.
• Chothia, Garcia, de Ruiter et al. (université de Birmingham), « Relay Cost Bounding for Contactless EMV Payments » (Financial Cryptography 2015) — l’analyse des attaques par relais, où le terminal dialogue à distance avec une carte qui n’est pas présente.
• Galloway et Yunusov (Positive Technologies), « First Contact : New Vulnerabilities in Contactless Payments » (Black Hat Europe 2019) — le contournement du plafond sans contact validé sur les cartes Visa de cinq grandes banques.
• « SoK : Security of EMV Contactless Payment Systems » (université de Warwick, 2024) et « SoK : Attacks on Modern Card Payments » (2025) — deux synthèses récentes qui recensent et rejouent ces attaques.

La synthèse de 2025 change la nature même du débat. Plutôt que de décrire une faille de plus, elle propose un cadre d’analyse systématique du paiement par carte moderne (puce et sans contact, y compris le paiement mobile) : elle définit les propriétés de sécurité que le système est censé garantir, les modèles d’attaquant réalistes, puis recense et classe l’ensemble des défauts de conception du protocole. Son apport décisif est de montrer que ces défauts ne sont pas des accidents isolés : ils se combinent. Différents sous-ensembles de failles, assemblés, produisent des attaques nouvelles — ce qui explique pourquoi, en quinze ans, les correctifs ponctuels n’ont jamais tari le flux des vulnérabilités. Les auteurs s’attachent d’ailleurs aux causes profondes de cette accumulation : la complexité du standard, la multiplicité des variantes et la rétrocompatibilité, qui entretiennent des angles morts durables.

Pour le juriste, l’enseignement est double. D’une part, le caractère structurel et persistant de ces faiblesses interdit de traiter la fraude « avec code » comme une hypothèse marginale ou théorique : c’est un risque documenté, actuel, sur les cartes et terminaux en circulation, alors même que le sans contact représente désormais l’essentiel des paiements par carte. D’autre part, le fait que les attaques résultent de combinaisons de failles rend d’autant plus illusoire l’idée qu’un simple journal « carte + code » suffirait à établir l’autorisation par le titulaire.

Que l’authentification forte (SCA) et le RTS imposent-ils à la banque ?

Depuis la deuxième directive sur les services de paiement (DSP2), transposée à l’article L.133-44 du Code monétaire et financier, la banque doit appliquer une authentification forte du client. Cette obligation n’est pas un slogan commercial : elle a un contenu technique précis, et son inobservation a des conséquences civiles directes.

Le Code reprend lui-même l’exigence centrale : pour les paiements électroniques à distance, l’authentification forte doit comporter des éléments établissant un lien dynamique entre l’opération, le montant et le bénéficiaire (art. L.133-44, II). Le contenu technique concret de cette obligation est fixé par un standard réglementaire européen, le RTS.

Trois exigences du RTS intéressent directement le débat probatoire. D’abord, deux facteurs indépendants (art. 4) : le seul fait qu’un « code » figure dans les journaux ne dit rien de la réalité de ce double facteur. Ensuite, le lien dynamique (art. 5) : le code d’authentification doit être cryptographiquement lié au montant exact et au bénéficiaire précis, toute modification devant l’invalider — c’est exactement le point que les attaques d’ETH Zurich mettent en échec, la méthode de vérification du porteur n’étant pas protégée contre la modification. Enfin, l’indépendance des éléments (art. 9) : la compromission d’un facteur ne doit pas compromettre les autres, alors que les travaux précités montrent des chaînes d’attaque où la maîtrise d’un seul maillon suffit à faire accepter l’opération.

La conséquence juridique est nette. Affirmer « l’opération a été authentifiée » ne suffit pas : encore faut-il que la banque prouve que l’authentification mise en œuvre satisfaisait réellement les exigences du RTS. Lorsque l’authentification forte était requise et que la banque ne démontre pas l’avoir correctement appliquée, le payeur qui n’a pas agi frauduleusement ne doit, en principe, supporter aucune perte (art. L.133-19, V). Le RTS donne ainsi un contenu vérifiable à la charge de preuve de l’article L.133-23 : il transforme la question « la banque a-t-elle authentifié ? » en une grille de critères techniques que le journal de transaction, à lui seul, ne renseigne pas.

Que faut-il en conclure sur le plan juridique ?

De ces travaux, on ne tire pas que « les cartes ne fonctionnent pas ». On en tire une chose précise et juridiquement décisive : la mention « code vérifié » dans les systèmes de la banque est une donnée déclarative, produite par le terminal, et non la preuve que le titulaire a composé son code. Trois conséquences en découlent.

1. Authentifier n’est pas autoriser. Qu’une opération soit techniquement « authentifiée » au sens des journaux ne dit rien de son autorisation par le payeur. C’est exactement la distinction que pose l’article L.133-23. La recherche montre qu’il existe des chemins par lesquels l’authentification est obtenue sans le consentement, ni même la présence, du titulaire.

2. Le journal de la banque est une preuve à soi-même, donc discutable. Il est constitué par la partie qui s’en prévaut. Les attaques pre-play et man-in-the-middle démontrent qu’il peut indiquer « carte + code » dans des cas de fraude pure. Le juge ne peut donc pas s’en contenter pour tenir l’autorisation — ou la négligence grave — pour établies.

3. La négligence grave doit être prouvée concrètement. Puisque l’usage du code peut résulter d’une attaque, l’opposer au client comme preuve de sa négligence revient à inverser la charge que la loi met sur la banque. Celle-ci doit articuler des éléments propres au dossier — circonstances, comportement réel du client — et non une déduction tirée du fonctionnement supposé de la carte.

Que faire concrètement face à un refus de remboursement ?

Face à un refus motivé par l’« utilisation du code », plusieurs réflexes s’imposent. Signaler l’opération sans tarder dès sa découverte (art. L.133-17), puis adresser une contestation écrite à la banque. Le délai légal pour contester est de treize mois à compter du débit (art. L.133-24) ; les délais plus courts que la banque insère parfois dans ses conditions générales ne peuvent pas faire échec à ce droit.

Il faut ensuite exiger par écrit la communication des journaux techniques de l’opération : mode de vérification du porteur réellement enregistré, données d’authentification forte, horodatages et nombre dit imprévisible. Ce sont précisément ces pièces que les chercheurs invitent les victimes à réclamer, et leur absence ou leur incohérence se retourne contre la banque, sur qui pèse la charge de la preuve. Sur le terrain de la responsabilité, au-delà de l’opération non autorisée elle-même, les obligations de la banque au titre du RTS (authentification forte, surveillance des transactions, détection des anomalies) constituent un levier encore sous-utilisé lorsqu’elles n’ont pas été respectées.

Enfin, il ne faut jamais accepter comme une fatalité l’affirmation selon laquelle « une carte à puce ne peut pas être détournée sans le code ». Elle est juridiquement fausse au regard de la charge de la preuve, et techniquement fausse au regard de l’état de l’art.

Conclusion

La force d’un dossier d’opération bancaire contestée tient à l’alliance de deux registres : le texte — les articles L.133-18 à L.133-24 et L.133-44, et la jurisprudence qui refuse de déduire la négligence grave du seul usage du dispositif — et l’état de la recherche, qui prive l’argument bancaire de sa prémisse implicite. « Le code a été utilisé » ne répond pas à la seule question qui compte : la banque peut-elle prouver que le titulaire a autorisé l’opération ? Tant qu’elle ne le fait pas, le remboursement est dû. Le cabinet LE BOT Avocat accompagne les titulaires de cartes et de comptes dans la contestation des opérations non autorisées et des refus de remboursement : si une banque vous oppose une opération « réalisée avec votre code », cette motivation, à elle seule, ne suffit pas — elle peut être discutée.

FAQ — Questions fréquentes