Faux questionnaire de sécurité : pas de négligence grave du client (TJ Lyon, 23 juin 2026, n° 25/01406)

Tribunal judiciaire de Lyon, 4e chambre, 23 juin 2026, n° RG 25/01406

Que s’est-il passé dans cette affaire de fraude au faux questionnaire de sécurité ?

Les faits jugés par le tribunal judiciaire de Lyon illustrent une variante redoutable du hameçonnage : celle qui se déploie non pas dans la boîte mail de la victime, mais au cœur même de son environnement bancaire numérique.

Comment l’escroquerie s’est-elle déroulée ?

Mi-février 2024, le titulaire d’un compte ouvert dans les livres de la Banque Populaire Auvergne Rhône Alpes gère ses comptes sur son application bancaire lorsqu’il reçoit une notification présentée comme émanant de sa banque. Le message lui reproche de ne pas avoir répondu à un questionnaire portant sur la sécurité de sa carte bancaire. En confiance — il est alors connecté à son espace personnel avec ses codes —, le client remplit le questionnaire, qui lui demande notamment les numéros de sa carte. Il reçoit ensuite un courriel l’avisant du blocage de sa carte pour 72 heures.

En réalité, le questionnaire était un leurre. L’escroc, ayant récupéré les données du client, fait ensuite valider une demande au libellé sibyllin — « j’autorise cette connexion » ou « je n’autorise pas cette connexion » — qui masquait en réalité l’enrôlement d’un nouveau téléphone comme appareil de réception des codes SECUR’PASS, le dispositif d’authentification forte de la banque. Le fraudeur détient dès lors la clé du coffre.

Le 20 février 2024, en soirée, le client reçoit par SMS un avis de virement instantané de 4 700 €. Il réagit sans attendre : il conteste l’opération par courriel adressé à son conseiller dès 22 h 31, soit trente-huit minutes après en avoir été informé selon les motifs du jugement. Le compte est bloqué par la banque le 21 février à 0 h 30. Trop tard : le lendemain matin, le client découvre que deux nouveaux virements de 4 950 € et 5 000 € ont été débités. Il dépose plainte le 23 février 2024. Les 26 et 27 février, deux paiements par carte bancaire de 6 650 € et 41,98 € sont encore réalisés — la carte n’avait pas été mise en opposition —, ce qui conduit le client à effectuer un signalement en ligne via la plateforme PERCEVAL.

Comment la banque a-t-elle justifié son refus de rembourser ?

La Banque Populaire a refusé toute prise en charge au motif que les opérations avaient été validées par la saisie du code SECUR’PASS, dispositif d’authentification forte conforme, selon elle, à la deuxième directive sur les services de paiement (DSP2). Devant le tribunal, elle soutenait que les opérations avaient été authentifiées, enregistrées et comptabilisées sans la moindre déficience technique, que toute opération passée en la forme convenue est présumée autorisée, et que son devoir de vigilance ne l’obligeait qu’à détecter les anomalies flagrantes.

Surtout, la banque plaidait la négligence grave du client : il aurait ouvert une page de hameçonnage en croyant répondre à un questionnaire de sécurité, il n’aurait pas dû valider l’enrôlement d’un nouveau téléphone alors qu’il n’avait pas changé d’appareil, et il aurait tardé à signaler la fraude. Autant d’arguments que le tribunal va méthodiquement écarter.

Que dit la loi sur le remboursement des opérations non autorisées ?

Le tribunal commence par rappeler un principe désormais solidement établi : dès lors que la responsabilité d’un prestataire de services de paiement est recherchée en raison d’une opération non autorisée ou mal exécutée, seul est applicable le régime spécifique de responsabilité défini par le Code monétaire et financier, à l’exclusion du droit commun.

Qui doit prouver quoi en matière de fraude aux moyens de paiement ?

L’architecture probatoire du Code monétaire et financier est entièrement construite en faveur du payeur. L’article L. 133-23 dispose que lorsque l’utilisateur nie avoir autorisé une opération, il incombe à la banque de prouver que l’opération a été authentifiée, dûment enregistrée et comptabilisée, et qu’elle n’a pas été affectée par une déficience technique ou autre. Le même texte précise — et c’est décisif — que l’utilisation de l’instrument de paiement telle qu’enregistrée par le prestataire ne suffit pas nécessairement en tant que telle à prouver que l’opération a été autorisée par le payeur, ni que celui-ci a commis une négligence grave.

L’article L. 133-19 II ajoute que la responsabilité du payeur n’est pas engagée si l’opération non autorisée a été effectuée en détournant, à son insu, l’instrument de paiement ou les données qui lui sont liées. Le IV du même article ne fait supporter les pertes au payeur que si elles résultent d’un agissement frauduleux de sa part ou d’un manquement intentionnel ou par négligence grave à ses obligations de préservation de ses données de sécurité personnalisées (article L. 133-16).

Le tribunal synthétise cette lecture combinée : lorsque le titulaire du compte soutient qu’une opération n’a pas été autorisée, c’est à la banque de prouver l’authentification, l’enregistrement, la comptabilisation et l’absence de déficience technique, sauf à démontrer une négligence grave du titulaire. Deux preuves cumulatives, donc, dont la banque supporte seule le fardeau.

Pourquoi un phishing reçu sur l’application bancaire révèle-t-il une défaillance technique de la banque ?

C’est l’apport le plus marquant du jugement. Le client exposait, sans être démenti par la banque, que la notification piégée provenait directement de son espace personnel bancaire : il était déjà connecté avec ses codes lorsqu’elle est apparue. Le tribunal en tire une conséquence radicale : « Le fait que Monsieur [Z] a reçu sur son application en ligne un tel message, quand bien même il s’agissait d’un lien vers un site de hameçonnage, démontre une défaillance technique du système de sécurité de la banque, et exclut toute négligence grave de sa part. »

Le raisonnement est d’une grande force logique. L’espace personnel authentifié d’un client est censé être un environnement sécurisé, maîtrisé de bout en bout par l’établissement. Si un contenu frauduleux parvient à s’y afficher — quelle qu’en soit la mécanique technique —, c’est que le périmètre de sécurité de la banque a été percé. La défaillance n’est plus à rechercher chez le client crédule, mais dans le dispositif de l’établissement lui-même. Et cette même circonstance neutralise le grief de négligence grave : on ne peut pas reprocher à un client de faire confiance à ce qui s’affiche dans l’environnement que sa banque lui présente comme sûr.

Voici, schématiquement, l’enchaînement de la fraude tel qu’il ressort du jugement :

La banque tentait de déplacer le débat : le client aurait « cru discuter sur son espace personnel » alors qu’il avait en réalité ouvert un message frauduleux. Mais cette explication, loin de la disculper, enfonce le clou : si la frontière entre l’espace authentifié et le piège est indiscernable pour l’utilisateur, c’est bien que la sécurité mise en place par la banque était défaillante.

Pourquoi le client n’a-t-il commis aucune négligence grave ?

Le tribunal examine un à un les reproches formulés par la banque et les écarte tous, dans une motivation qui mérite d’être méditée par tous les établissements tentés d’opposer un refus de principe aux victimes de hameçonnage.

Donner son numéro de carte bancaire est-il une négligence grave ?

Non, répond le tribunal, en tout cas pas dans ce contexte. La communication du numéro de carte « ne peut constituer une négligence grave dès lors qu’il est requis pour tout paiement en ligne et compte tenu du contexte de la demande reçue sur l’application bancaire ». Le numéro de carte n’est pas un code secret au sens strict : chacun le communique à chaque achat en ligne. Le divulguer en réponse à une demande apparaissant dans son propre espace bancaire ne saurait caractériser le manquement d’une particulière gravité qu’exige la loi. Le client soutenait au surplus ne pas avoir saisi ses codes confidentiels à cette occasion.

Valider « j’autorise cette connexion » engage-t-il la responsabilité du client ?

C’est le second enseignement pratique majeur. La banque reprochait au client d’avoir validé l’enrôlement d’un nouveau téléphone alors qu’il n’avait pas changé d’appareil — signal, selon elle, d’une fraude évidente. Mais le tribunal relève que le libellé de la demande « n’est pas explicite puisqu’il est mentionné simplement « j’autorise cette connexion » ou « je n’autorise pas cette connexion », sans aucune précision ni référence à un nouvel équipement ». On ne peut reprocher au client d’avoir accepté une connexion alors qu’il pensait légitimement être encore sur son application bancaire.

La leçon vaut avertissement pour les banques : la sécurité par messages cryptiques ne protège personne. Un dispositif d’authentification forte dont les écrans de validation ne disent pas clairement ce que l’utilisateur autorise — ici, le rattachement d’un appareil inconnu à son compte — manque sa cible et ne peut fonder aucun grief contre le client.

Le client a-t-il tardé à signaler la fraude ?

La banque avançait enfin un signalement tardif. L’argument tombe devant la chronologie : informé du premier virement par SMS à 21 h 53, le client l’a contesté par courriel à 22 h 31 — trente-huit minutes plus tard, un soir de semaine — puis a contesté les opérations suivantes dès qu’il en a eu connaissance, déposé plainte trois jours après les faits et signalé les paiements par carte via la plateforme PERCEVAL. Difficile d’imaginer une réactivité plus exemplaire. Le blocage du compte, intervenu le 21 février à 0 h 30, n’a d’ailleurs pas empêché les paiements par carte des 26 et 27 février, faute de mise en opposition de la carte — une carence qui relève de la sphère de la banque, non du client.

Pourquoi les listings Excel de la banque ont-ils été écartés des débats ?

Restait à la banque une dernière ligne de défense : prouver que chaque opération avait été validée par la saisie du code SECUR’PASS. Pour ce faire, elle versait aux débats une quarantaine de pages imprimées recto verso, tirées d’un fichier Excel. Le tribunal ne mâche pas ses mots : ces pages « ne sont pas numérotées et sont totalement incompréhensibles et inexploitables pour le Tribunal, ne comportant que des numéros, dates et indications techniques, en dehors des mentions et commentaires ajoutés sur certaines lignes ». L’impression a découpé le tableau au point d’en rendre le déchiffrage impossible, sans indication d’assemblage ni d’ordre des pages.

Et le tribunal d’ajouter le coup de grâce : « En tout état de cause, nul ne peut se constituer une preuve à soi-même. » Les journaux techniques produits par la banque, générés par ses propres systèmes, commentés de sa propre main, ne sauraient suffire à établir que le client a lui-même utilisé les codes d’authentification forte.

Cette double motivation est précieuse pour les victimes. D’abord parce qu’elle rappelle une exigence de qualité de la preuve : la banque qui prétend démontrer l’authentification d’une opération doit produire des éléments lisibles, ordonnés, exploitables — pas un déversement brut de données techniques. Ensuite parce qu’elle mobilise le principe selon lequel les enregistrements internes de la banque, invérifiables par le client et par le juge, ne peuvent constituer à eux seuls la preuve exigée par l’article L. 133-23. La conclusion s’impose alors mécaniquement : la banque ne démontre ni l’absence de défaillance technique, ni la négligence grave — le remboursement est dû.

Quelles leçons pratiques tirer de ce jugement si vous êtes victime d’une fraude ?

Ce jugement fournit une feuille de route aux victimes de fraude aux moyens de paiement, qu’il s’agisse de hameçonnage classique, de fraude au faux conseiller ou, comme ici, de faux questionnaire de sécurité infiltré dans l’environnement bancaire.

La première leçon est chronologique : la réactivité de la victime a pesé lourd. Contestation écrite dans les quarante minutes suivant le SMS d’alerte, courriel au conseiller, dépôt de plainte rapide, signalement PERCEVAL pour les paiements par carte : chaque étape a construit le dossier. Signaler sans délai chaque opération contestée, par écrit et en conservant la preuve de l’envoi, est essentiel — l’article L. 133-24 enferme d’ailleurs le signalement dans un délai de treize mois pour les consommateurs.

La deuxième leçon porte sur le discours tenu à la banque et aux enquêteurs. Les déclarations faites dans la plainte ont ici servi le client : elles établissaient qu’il était connecté à son espace personnel lorsque le piège s’est refermé. Mais des déclarations maladroites peuvent, à l’inverse, être exploitées par la banque pour plaider la négligence grave. Avant de rédiger votre contestation ou votre plainte, lisez notre guide complet : Fraude bancaire : que dire et ne pas dire à sa banque et dans sa plainte.

La troisième leçon est probatoire : ne vous laissez pas impressionner par les affirmations techniques de la banque. « L’opération a été validée par authentification forte » n’est pas une preuve, c’est une allégation. Exigez la production des éléments, contestez leur lisibilité et leur valeur probante, rappelez que la seule utilisation de l’instrument de paiement telle qu’enregistrée ne suffit pas, et que les normes techniques de réglementation (RTS) complétant la DSP2 imposent aux banques des exigences précises en matière d’authentification forte et de surveillance des opérations — un angle encore sous-exploité dans ces contentieux.

Quelle est la portée de ce jugement pour les victimes de fraude bancaire ?

Ce jugement du tribunal judiciaire de Lyon s’inscrit dans un courant jurisprudentiel exigeant envers les banques quant à la double preuve de l’article L. 133-23, mais il y apporte deux pierres singulières.

D’une part, l’affirmation selon laquelle la réception d’un message de hameçonnage au sein de l’application bancaire caractérise une défaillance technique du système de sécurité de la banque est d’une portée considérable. Elle déplace le terrain du débat : au lieu de disséquer le comportement de la victime, le juge scrute l’étanchéité de l’environnement numérique que la banque met à disposition. Les établissements ne pourront plus se retrancher derrière la validation technique des opérations lorsque le point d’entrée de la fraude se situe dans leur propre écosystème applicatif.

D’autre part, le rejet des listings informatiques illisibles au double visa de leur inexploitabilité et de l’interdiction de se constituer une preuve à soi-même arme efficacement les victimes contre une pratique répandue : la production massive de données techniques brutes, censées faire office de démonstration. Le message est clair : la preuve de l’authentification doit être intelligible et vérifiable, faute de quoi elle ne prouve rien.

On notera enfin deux nuances. Le tribunal a rejeté la demande de dommages et intérêts complémentaires du client, faute de démonstration d’une mauvaise foi de la banque : le simple refus de rembourser, même injustifié, n’est pas en soi fautif en l’absence d’intention de nuire. Et les intérêts n’ont couru qu’au taux légal à compter du 5 mars 2024, comme demandé, le client n’ayant pas sollicité le bénéfice des dispositions spécifiques de l’article L. 133-18 — qui prévoit pourtant un remboursement immédiat avec remise du compte dans l’état où il se serait trouvé sans l’opération. Deux points de stratégie contentieuse à soigner dans les prochaines affaires.

En définitive, ce jugement rappelle une évidence que les victimes de fraude perdent parfois de vue face au refus catégorique de leur banque : la loi est de leur côté, la charge de la preuve aussi. Lorsque la fraude s’est infiltrée jusque dans l’application bancaire, c’est le système de la banque qui a failli — et c’est à elle d’en assumer les conséquences. Si votre banque vous oppose la validation par authentification forte ou votre prétendue négligence grave, ne renoncez pas : chaque dossier mérite une analyse précise de la chronologie, des messages reçus et des preuves réellement produites par l’établissement.

FAQ — Vos questions sur la fraude au faux questionnaire de sécurité