1. Une fois n’est pas coutume. Par tradition, nous choisissons de commenter seulement la jurisprudence des cours suprêmes (CJUE, Cour de cassation, Conseil d’État le cas échéant), a fortiori lorsqu’elle est d’une telle profusion qu’il devient presque impossible de la suivre, ou de la rapporter ; à l’exemple, précisément, du droit des opérations de paiement. La dernière fois que nous y avons fait exception, c’était pour critiquer la « fausse promesse » du chargeback2, prenant appui sur un arrêt de la Cour d’appel d’Amiens3. Or le même auteur que précédemment, M. Jérôme Lasserre Capdeville, signale, sur le réseau social LinkedIn cette fois, une « décision notable concernant la fraude via Apple Pay » : l’arrêt de la Cour d’appel de Rennes du 26 mai 2026, que l’on retrouve sans peine dans la base Judilibre de la Cour de cassation, ce qui nous conforte...
Notable, peut-être, la décision l’est-elle, bien qu’une parmi manifestement des dizaines, nées du contentieux nécessairement florissant des paiements réalisés à partir du « portefeuille mobile d’Apple », pour reprendre les termes de la Commission européenne4 ; un wallet (Apple Wallet App), donc, qui embarque le service de paiement mobile (cashless payment service) Apple Pay5, encore que l’on ne sache trop qui, d’Apple ou de l’émetteur de la carte de paiement préenregistrée, est le prestataire de services de paiement (PSP)6.
Notable, sans doute, l’arrêt rendu par la Cour d’appel de Rennes l’est-il au regard de sa motivation, mais qui brille davantage par sa approximation que par le résultat auquel elle conduit : la confirmation du jugement attaqué en ce qu’il a condamné la banque poursuivie à rembourser à un particulier la somme de 6 667,56 euros correspondant au montant total des onze débits frauduleux réalisés à partir de son compte bancaire les 13, 14 et 17 janvier 2022.
2. En cause d’appel. La banque, appelante, fait grief au jugement de première instance d’« avoir retenu qu’elle ne justifiait pas que les paiements avaient été réalisés sur la base d’une authentification forte en faisant valoir que les paiements avaient été réalisés au moyen de l’application Apple Pay et alors que Mme [F] avait activé le service au moyen de son numéro de téléphone et d’un code à usage unique de sorte que les paiements ont été effectués après authentification forte », ajoutant qu’« elle considère qu’il ne saurait lui être reproché de ne pas avoir mis en œuvre, pour chaque paiement réalisé par l’application mobile Apple Pay, un tel processus d’authentification puisqu’il est assuré ab initio, au moment de l’activation du service et garantit ainsi la sécurité des paiements ultérieurs, sauf négligence grave du titulaire de la carte bancaire enrôlée qu’elle considère comme établie par sa cliente qui a communiqué ses codes et numéros de carte bancaire ».
À quoi l’intimée fait valoir que « l’activation du service Apple Pay au moyen d’un SMS n’est pas un code d’activation de paiement au sens de l’article L. 133-23 du code monétaire et financier mais de service et qu’elle n’a reçu aucune alerte sur le fait que l’enregistrement dans le service emportait l’absence d’autorisation ultérieure ».
La motivation de l’arrêt confirmatif est en la forme du syllogisme suivant :
– « Il résulte des articles L. 133-18, L. 133-19, L. 133-16 et L. 133-23 du code monétaire et financier que, lorsqu’un utilisateur de services de paiement conteste avoir autorisé une opération de paiement, il appartient au prestataire de services de paiement de rapporter la preuve que l’opération litigieuse 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 » ;
– or « la société BforBank se prévaut de ce que les opérations contestées par Mme [F] réalisées le 12 janvier 2022 auraient été validées par une authentification forte qui résulterait de ce que Mme [F] a validé le 9 janvier 2022 précédent l’enrôlement de sa carte bancaire sur le service Apple Pay d’un autre téléphone ce qui n’a pu intervenir qu’après confirmation de Mme [F] donnée par SMS » ;
– mais « au vu des textes susvisés, l’authentification forte s’entend d’une authentification de chacune des opérations en cause et non de la validation d’un moyen de paiement de sorte que c’est vainement que la banque se prévaut de ce que Mme [F] a validé son inscription au service de paiement le 9 janvier 2022 pour établir l’authentification de chacune des opérations réalisées le 12 janvier suivant ».
Il y a là une ambiguité certaine entre les deux « emplois » de l’authentification en droit des opérations de paiement.
3. De l’authentification de l’opération et du payeur. Il a récemment été montré, avec brio, que l’authentification ne doit pas être confondue avec l’autorisation (i. e. le consentement à) de l’opération de paiement7. Mais ce n’est pas tout, car l’authentification est elle-même ambivalente : tantôt elle l’est de l’« opération » de paiement per se, tantôt elle porte sur la « personne » du payeur et, dans cette seule dernière hypothèse, on parlera d’« authentification forte ».
Ainsi, l’authentification qu’évoque en premier lieu la décision rapportée du 26 mai 2026 est bien celle qui porte sur l’opération ; celle qui vise à « vérifier l’identité d’un utilisateur de services de paiement » (« ou la validité de l’utilisation d’un instrument de paiement spécifique, y compris l’utilisation des données de sécurité personnalisées de l’utilisateur »)8 et fait dire à l’alinéa 1er de l’article L. 133-23 du CMF9 que « lorsqu’un utilisateur de services de paiement nie avoir autorisé une opération de paiement qui a été exécutée, ou affirme que l’opération de paiement n’a pas été exécutée correctement, il incombe à son prestataire de services de paiement de prouver que l’opération en question 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 »10.
Mais la Cour d’appel de Rennes glisse ensuite à cette « autre » authentification qu’est l’« authentification forte » du payeur (de sa « personne »11), innovation phare de la DSP 2 (article 97) qui, reprise à l’article L. 133-44 du CMF, commande qu’une telle mesure ultime de sécurité soit mise en œuvre lorsque le payeur « accède à son compte de paiement en ligne », « initie une opération de paiement électronique » ou « exécute une opération par le biais d’un moyen de communication à distance, susceptible de comporter un risque de fraude en matière de paiement ou de toute autre utilisation frauduleuse ». À défaut de quoi, fulmine le V de l’article L. 133-19, « sauf agissement frauduleux de sa part, le payeur ne supporte aucune conséquence financière [de] l’opération de paiement non autorisée »12.
4. Sur l’authentification de l’opération de paiement. Beaucoup a été dit, peut-être trop, au sujet de l’authentification forte et de ses si fameuses RTS on SCA and CSC under PSD2, comme « surexposées » au sens photographique du terme13, faisant oublier le déficit de valeur normative de telles règles techniques14. Quoi qu’il en soit, le « couperet » du V de l’article L. 133-19 du CMF (« Sauf agissement frauduleux de sa part, le payeur ne supporte aucune conséquence financière si l’opération de paiement non autorisée a été effectuée sans que le prestataire de services de paiement du payeur n’exige une authentification forte du payeur prévue à l’article ») est bel est bien une réalité, comme l’a illustré avec vigueur l’important arrêt de la Cour de cassation rendu le 30 août 2023 : n’a pas donné de base légale à sa décision, au regard de l’article L. 133-19, V, et de l’article L. 133-44, qui oblige le PSP à appliquer l’authentification forte dans certains cas, le tribunal qui retient qu’un utilisateur de services de paiement (USP) a commis une négligence grave en faisant confiance à une personne qu’il ne connaissait pas et qui lui racontait une histoire assez peu crédible (communication à un tiers prétendant être un employé de banque de son code à six chiffres « 3D Secure »), alors qu’il aurait dû rechercher « si l’opération de paiement litigieuse avait été exécutée sans que la banque exige l’authentification forte du payeur »15. Quand le défaut d’authentification forte d’une opération de paiement non autorisée, initiée par un instrument de paiement doté de données de sécurité personnalisées, « chasse » jusqu’à la négligence grave...
Demeure en revanche passablement mystérieuse cette sorte de « contre-obligation » du PSP qui, face à la contestation d’une opération de paiement non autorisée ou mal exécutée, doit « prouver que l’opération en question 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 » (CMF, art. L. 133-23, al. 1er, précit.). Il ne s’agit, à l’évidence, pas de la même authentification ; pas de l’authentification forte de la « personne » du payeur mais, immédiatement, de l’« opération » elle-même, de l’« opération en question » dit d’ailleurs le texte. De même que cette procédure d’authentification ne ressortit pas du « cas particulier des instruments de paiement dotés de données de sécurité personnalisées » (intitulé de la sous-section portant articles L. 133-19 et L. 133-20 du CMF), mais des « modalités pratiques et délais en cas d’opérations de paiement non autorisées ou mal exécutées » (articles L. 133-23 à L. 133-24 du CMF).
En sorte qu’aux termes d’une autre décision remarquable de la Cour de cassation, du 20 novembre 2024, un USP peut bien, à nouveau, avoir commis des négligences graves qui ont permis les paiements litigieux (en l’espèce, rien moins que la remise de son relevé d’identité bancaire, puis sa carte de paiement et ses codes « cyber » à un inconnu rencontré sur Instagram), encore fallait-il, pour le condamner à partager les pertes avec sa banque, s’assurer que « les opérations litigieuses avaient été authentifiées, dûment enregistrées et comptabilisées et qu’elles n’avaient pas été affectées par une déficience technique ou autre » ; car, nous enseigne cet arrêt (de cassation), « il résulte des articles L. 133-19, IV, et L. 133-23, alinéa 1, du code monétaire et financier, que s’il entend faire supporter à l’utilisateur d’un instrument de paiement doté d’un dispositif de sécurité personnalisé les pertes occasionnées par une opération de paiement non autorisée rendue possible par un manquement de cet utilisateur, intentionnel ou par négligence grave, aux obligations mentionnées aux articles L. 133-16 et L. 133-17 de ce code, le prestataire de services de paiement doit, au préalable, prouver que l’opération en cause 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 »16.
Doit de même être cassé, selon une motivation strictement identique, l’arrêt qui, pour rejeter la demande en restitution des sommes litigieuses, retient qu’il est acquis que l’USP « a fait preuve de négligence grave en cliquant sur le courriel, ayant permis l’ajout d’un bénéficiaire, puis les ordres de virements émis grâce à ses identifiants via le site internet de la banque, lui ayant été adressé comme provenant de celle-ci, lequel comportait des incohérences facilement décelables et ayant été précédé d’une première tentative d’escroquerie portée à sa connaissance par le conseiller clientèle peu de jours auparavant »17.
5. Revenons à l’arrêt commenté. Si l’on relit les trois passages précités, il apparaît clairement :
– que l’appelante (BforBank) n’était pas fondée, pour rapporter la preuve que l’opération litigieuse avait été authentifiée, dûment enregistrée et comptabilisée et qu’elle n’avait pas été affectée par une déficience technique ou autre, à se prévaloir « de ce que les opérations contestées par Mme [F] réalisées le 12 janvier 2022 auraient été validées par une authentification forte qui résulterait de ce que Mme [F] a validé le 9 janvier 2022 précédent l’enrôlement de sa carte bancaire sur le service Apple Pay d’un autre téléphone ce qui n’a pu intervenir qu’après confirmation de Mme [F] donnée par SMS » ;
– non pas pour la raison, avancée par les juges du fond, que « l’authentification forte s’entend d’une authentification de chacune des opérations en cause et non de la validation d’un moyen de paiement de sorte que c’est vainement que la banque se prévaut de ce que Mme [F] a validé son inscription au service de paiement le 9 janvier 2022 pour établir l’authentification de chacune des opérations réalisées le 12 janvier suivant » ;
– mais parce que, tout simplement, la preuve de l’authentification de l’opération, requise par l’article L. 133-23, alinéa 1er, du CMF, n’a rien à faire avec la mise en œuvre de l’authentification forte du payeur dans les cas prévus à l’article L. 133-44, telle que sanctionnée au V de l’article L. 133-19.
Autrement dit, au cas d’espèce, était indifférent que le payeur ait été fortement authentifié ou non lors de l’enrôlement de sa carte sur Apple Pay ; cela pouvait certes dire sur sa « personne » à ce moment sensible (« Cet enrôlement, considéré comme une opération sensible au sens de la réglementation, nécessite une authentification forte de la part de l’utilisateur (ABE, recueil réglementaire unique : Single Rulebook Question and Answer – Q&A – 2021_6141) »18), mais rien sur les opérations de paiement ultérieures.
Mais de là en tirer, comme la CJUE l’a fait, que « l’obligation d’authentification d’une opération de paiement pesant sur un prestataire de services de paiement a pour objet de vérifier l’utilisation de l’instrument de paiement en vue d’établir que l’utilisateur de ces services a donné son consentement à l’exécution de cette opération de paiement qui, partant, peut être réputée autorisée »19, cela mériterait... une étude à part entière. n
Achevé de rédiger le 1er juillet 2026.
