Le paquet DSP3 / PSR est encore en cours de processus législatif européen : il n'est pas applicable en l'état, et aucune obligation nouvelle ne peut en être déduite aujourd'hui. Ce qui est en revanche lisible, c'est la direction prise : renforcement de la lutte antifraude, élargissement de la responsabilité des prestataires, et attention particulière portée à la fraude dite « autorisée », celle où la victime valide elle-même l'opération après avoir été manipulée. Pour une équipe qui décide aujourd'hui d'une architecture d'authentification appelée à durer plusieurs années, ce signal compte plus qu'une échéance.
Cet article propose une lecture opérationnelle et ne constitue pas un avis juridique. Le texte discuté peut encore évoluer sur le fond comme sur la forme ; aucune décision de conformité ne devrait être fondée sur son contenu actuel sans validation par vos conseils.
Où en est le paquet, et pourquoi il retient déjà l'attention
Les travaux en cours visent à faire évoluer le cadre européen des services de paiement, aujourd'hui porté par la DSP2 — directive (UE) 2015/2366. Trois orientations reviennent dans les discussions publiques : durcir les dispositifs de lutte contre la fraude, préciser la répartition des responsabilités entre acteurs de la chaîne de paiement, et traiter le cas des opérations que le client a lui-même validées sous l'effet d'une manipulation.
Rien de tout cela n'est arrêté, et les formulations finales détermineront la portée réelle des obligations. Mais la trajectoire est suffisamment stable pour qu'un choix d'architecture pris maintenant puisse être évalué à son aune, sous réserve du texte final.
De la preuve d'authentification à la preuve d'intention
C'est le point qui change le plus la manière de concevoir un dispositif. Tant que la responsabilité se règle sur la question « l'opération a-t-elle été authentifiée ? », un journal d'authentification solide suffit à défendre une position. Si la responsabilité s'étend aux opérations autorisées sous manipulation, la question devient tout autre : « peut-on établir que la personne a compris et voulu cette opération-là ? »
Les deux questions n'appellent pas la même architecture. La première se satisfait de la vérification d'un secret ou d'une possession. La seconde exige une preuve d'intention consciente et contextualisée : au moment de la validation, l'utilisateur doit avoir sous les yeux ce qu'il approuve, et le geste qu'il accomplit doit être difficile à produire pour quelqu'un qui agit sous dictée. Un code recopié depuis un message répond à la première question et pas du tout à la seconde. C'est exactement l'espace que cherche à couvrir le quatrième facteur « je sais faire » de l'authentification cognitive.
Ce que cela déplace concrètement
Trois éléments de conception sortent du domaine de l'ergonomie pour entrer dans celui de la preuve : le contenu affiché au moment de la validation, le canal dans lequel ce contenu est affiché, et la nature du geste demandé. Une architecture qui traite ces trois points comme des paramètres d'interface aura du mal à produire, plus tard, autre chose qu'un journal technique. C'est le raisonnement que suit l'authentification transactionnelle, qui déplace la preuve du niveau de la session vers celui de l'opération.
Paiements instantanés : la fenêtre de rattrapage se referme
La généralisation des virements exécutés en quelques secondes modifie l'équation sans qu'aucun texte n'ait à l'imposer. Les dispositifs antifraude construits sur une logique de détection différée — analyse a posteriori, rappel du client, blocage avant exécution — perdent le délai sur lequel ils reposaient. Quand l'exécution est immédiate et irrévocable, le seul moment où l'on peut encore agir est celui de la validation.
Cette contrainte technique et l'orientation réglementaire pointent dans la même direction : la qualité de la preuve recueillie au moment du geste devient déterminante, parce qu'il n'y a plus grand-chose après. Une organisation qui investit uniquement dans la détection en aval prépare mal les deux évolutions à la fois.
Décider aujourd'hui sans texte final : des critères qui tiennent
L'erreur serait d'attendre, l'erreur symétrique serait de se conformer à un texte qui n'existe pas encore. Une voie praticable consiste à retenir des critères d'architecture qui restent pertinents quel que soit l'atterrissage du paquet — parce qu'ils répondent à des risques déjà présents.
| Critère d'architecture | Ce qu'il apporte quel que soit l'atterrissage du texte | Signe qu'il manque aujourd'hui |
|---|---|---|
| Résistance au relais en temps réel | Neutralise l'interception de la validation, indépendamment du cadre juridique | Des méthodes reposant sur un code transmissible restent en usage sur des opérations sensibles |
| Lisibilité de l'opération au moment de la validation | Donne à l'utilisateur une chance de détecter une substitution | L'écran de confirmation ne mentionne pas le bénéficiaire |
| Geste non dictable à distance | Rend la validation difficile à obtenir par téléphone sous manipulation | Un tiers peut faire valider une opération en guidant la personne pas à pas |
| Traçabilité exploitable des mois plus tard | Permet de reconstituer le contexte d'une opération contestée | Les journaux prouvent l'authentification, pas ce qui était affiché |
| Réversibilité des choix techniques | Autorise un ajustement si le texte final diverge | Le dispositif est enchâssé dans un parcours unique, sans point de bascule |
Ces critères ont une propriété commune : ils réduisent un risque avéré aujourd'hui. Aucun ne suppose d'anticiper une obligation qui n'existe pas. C'est ce qui les rend défendables devant un comité d'investissement comme devant un auditeur.
Ce qu'il vaut mieux éviter
Trois réflexes desservent les équipes. Annoncer en interne une échéance de mise en conformité, alors qu'aucune date ne peut être avancée. Refondre l'ensemble des parcours au nom d'un texte en discussion, ce qui expose à devoir refaire le travail. Et à l'inverse, geler toute décision d'architecture en attendant une publication, alors que les paiements instantanés et la fraude par manipulation produisent déjà leurs effets. La position raisonnable consiste à traiter le paquet comme un signal de trajectoire, pas comme un plan de conformité.
FAQ
DSP3 est-elle applicable ?
Non. Le paquet est encore engagé dans le processus législatif européen et ne produit aucune obligation à ce jour. Toute communication interne qui laisserait entendre le contraire, ou qui avancerait une échéance, expose l'organisation à des arbitrages mal fondés.
Qu'appelle-t-on une fraude « autorisée » ?
Il s'agit d'une opération que la victime a elle-même validée, avec ses propres facteurs, après avoir été manipulée — typiquement par un faux conseiller ou un faux service technique. Du point de vue des systèmes, tout paraît normal : c'est précisément ce qui la rend difficile à traiter par des contrôles d'authentification classiques.
Faut-il attendre le texte final pour agir ?
Attendre n'est pas neutre, parce que les risques visés existent déjà et que les cycles de remplacement d'un dispositif d'authentification se comptent en années. La voie médiane consiste à avancer sur les critères qui réduisent un risque actuel, en préservant la capacité d'ajuster le dispositif lorsque le texte sera stabilisé.
Une SCA conforme protège-t-elle contre la fraude autorisée ?
Elle établit que la bonne personne a validé, pas qu'elle a compris ce qu'elle validait. C'est pourquoi la réflexion se déplace vers des mécanismes capables d'attester d'une intention, en rendant l'opération lisible et le geste de validation difficile à obtenir sous dictée.
Aller plus loin : DSP2 et les obligations d'authentification · prouver une intention humaine · panorama NIS2, DORA, DSP3 et CRA