Un cas d’usage des virements bancaires : freins et proposition

Ajout du 1/10/2018 : Le conseil européen des paiements a construit une spécification QR Code dédié aux virements. Initiée par l’Autriche en 2012, elle s’est répandue en Finlande (2015), en Allemagne (2015), aux Pays-Bas (2016) et en Belgique (2016). Voir cet article et ce site.

Le cas d’usage

Un de mes amis fête son anniversaire. L’heure est donc venue pour moi de collecter des € (et des idées) pour lui offrir un beau cadeau. Le cas d’usage est plutôt simple et courant, mais pourtant compliqué à gérer avec les moyens de paiement scripturaux « classiques » proposés par nos vénérables institutions bancaires.

Le problème

Moi qui suis particulièrement adepte du virement SEPA (gratuit et bientôt instantané), je dois bien reconnaitre que :

  • la plupart des membres du groupe sont encore chez des banques « old school » où les RIB mettent entre 2 et 5 jours à être utilisables après saisie
  • les autres peuvent l’utiliser immédiatement, mais au prix d’une complexité de sécurisation de la saisie importante
  • Ceux qui n’ont pas les contraintes ci-dessous sont malgré tout contraints de taper à la main l’IBAN, ce qui est quelque peu pénible.

Au final, je vais devoir gérer du liquide (bête noire du gouvernement), ou bien créer un énième compte auprès d’une énième start-up spécialisée à qui je donnerai une commission importante, et qui obligera tout de même les membres du groupe à saisir leur numéro de carte, voire même qui m’obligerait à la mémoriser dans sa base de donnée !

La communauté bancaire européenne travaille à différentes options de transmission de créances :

  • la plupart sont réservées aux professionnels (SEPAMail, Rubis, etc.)
  • certaines ne permettent pas le paiement entre particuliers (Paylib)
  • d’autres ne sont pas implémentées par toutes les banques (feu Kwixo par exemple)

Le transfert des fonds d’un compte bancaire SEPA à un autre sera bientôt instantané. À cette occasion, les banques devraient mettre en place un annuaire permettant d’obtenir l’IBAN à partir du numéro de téléphone. Cela est très prometteur, mais réclame des développements centralisés, et donc potentiellement des délais importants de mise en place. D’autre part, ce système ne permettra ni de transmette de libellé de la transaction, ni le montant.

Une piste de solution

La problématique est donc la suivante : comment transmettre facilement mon IBAN, le libellé de l’opération voire le montant souhaité (optionnel) à tous mes correspondants facilement ? Il s’agit ici de fournir un moyen de paiement entre particuliers à moindre frais, puisque capitalisant au maximum sur l’infrastructure SEPA déjà en place.

Une possibilité serait de créer une norme de code-barre en deux dimensions (QRCode ou DataMatrix) stockant simplement ces trois informations. Le débiteur n’aurait qu’à scanner le code-barre depuis l’application de sa banque pour obtenir un formulaire de virement pré-rempli (possiblement modifiable) prêt à être validé. De son côté, le créancier aurait bien plus de chance d’obtenir des libellés normalisés !

La transposition de cette technique à la norme NFC serait possible dans un second temps, mais d’un usage plus limité (proximité physique nécessaire, impossible de le générer la créance sur mon espace Web sur PC pour l’envoyer par mail), et apporterait peu de gains en proximité. Un peu blong-bling en somme. Si transposition au NFC il devait y avoir, il serait nécessaire de prévoir un chiffrement lié au passage au sans fil, pour l’aberration de la première version du protocole NFC Eurocard-Visa-Mastercard.

Comment faire ?

L’avantage majeur de ce procédé est qu’il n’est pas nécessaire de modifier les complexes back-offices des banques, juste d’ajouter un point de menu aux applications mobiles (et/ou sites web). Tout l’enjeu est de normaliser la structure en quelques pages, et de l’implémenter dans une masse critique d’applications bancaires.

Vue la simplicité technique du processus, un ou deux hackathons des 4 grands groupes bancaires français (ou européen !) devraient pouvoir suffire à lancer le mouvement ! L’important étant la diffusion massive sur les appli bancaires en peu de temps.

  • Prendre une équipe agile dans chacune du top dix des banques de détail
  • 1/2 journée pour caler le cas d’usage et questionner (basiquement) la sécurité
  • 1/2 journée pour cadrer en deux pages la norme du code-barre 2D (sur ce modèle par exemple)
  • 1/2 journée de développement pour générer le code-barre (ajout des bibliothèques 2D à l’appli mobile, du point de menu, du formulaire, de la fonction de génération, des fonctions de partage standards, etc.)
  • 1/2 journée de développement pour gérer la lecture du code-barre (ajout des bibliothèques 2D à l’appli mobile, du point de menu, du formulaire, de la fonction de génération, des fonctions de partage standards, etc.)

Ajoutez de quelques jours de tests utilisateurs et de complétude de la documentation, et vous obtenez un PoC utile et plus largement diffusable.

Les freins stratégiques/économiques

Tous les employés technophiles de ces banques ont déjà dû penser à cette transmission par code-barre 2D. Ça n’a rien d’innovant en soi. La démarche a peut-être déjà été menée… En tous cas, elle n’a jamais été généralisée.

Reste la question de l’adhésion des groupes bancaires à une telle norme commune sans intervention du régulateur. Vaste question. Cela dit, vue la pression des FinTech, d’AppelPay / GoogleWallet, pourquoi ne pas tenter le coup ? De mon point de vue de simple citoyen, le coût d’investissement me parait minime.

La DSP2 imposant une gratuité des virements SEPA, cette technologie ne rapportera pas un centime aux banques. Cependant cela ne leur coutera rien non plus. Est-ce préférable d’attendre de se faire désintermédier ? Ou de proposer des produits payants, donc peu diffusés alors que les banques limitent en même temps leurs coûts de gestion de pièces/billets ? Arrêtons d’avoir les yeux plus gros que le ventre !

Les freins technologiques

En termes de sécurité, je n’ai pas l’impression que ce procédé de saisie ne soit plus ou moins risqué qu’une saisie manuelle sur un formulaire de virement, qui nécessitera dans tous les cas la validation du débiteur. Quelques parades seraient néanmoins possibles pour limiter les risques liés au manque de vigilance du débiteur :

  • Indiquer au débiteur par un pictogramme qu’il n’a jamais fait de virement sur ce compte, afin de limiter les risques d’hameçonnage
  • signer le code-barre par la banque du créancier et vérifier que cette banque est dans une liste de tiers de confiance, bien que cela restreigne un peu les cas d’usage (impossibilité de générer mon code-barre dans une application tierce)

Réflexion sur l’identité numérique : de l’importance de conserver FranceConnect

Le gouvernement a récemment lancé une réflexion sur l’identité numérique. J’ai depuis lu plusieurs articles sur la question, et notamment une interview de Mounir Mahjoubi, Secrétaire d’État au numérique dans l’Usine Digitale. Il est très positif que le gouvernent souhaite simplifier et inclure par le numérique. Cependant, quelques détails de cette tribune, comme l’intervention du Secrétaire d’État sur LCI me posent questions. Peut-être que ce sont des questions bêtes qui pourront rapidement trouver réponses…

Cette article doit être vu comme un questionnement citoyen ouvert ; un point de départ. Si vous avez des réponses, dites-le moi. Je serai heureux d’ajuster mon discours à la lumière de nouveaux éléments !

Sommaire :

 

Mes questionnements principaux partent du paragraphe suivant de l’Usine Nouvelle, concernant la question de « l’identité numérique » :

Où en êtes-vous ?

M. M. – On a lancé le groupe de configuration Ministère de l’intérieur/Dinsic. Ils ont commencé. Je leur ai demandé de travailler jusqu’au mois de février sur plusieurs scénarios : celui de la carte physique avec une puce, qui est le choix estonien ; et celui du 100% virtuel, comme ce que font la plupart des banques. Entre les deux, il y a d’autres dispositifs possibles. L’objectif est que face à chacun de ces scénarios, on puisse faire des tests avec des utilisateurs, faire l’analyse économique du coût pour l’État, de voir comment on peut le généraliser et à quelle vitesse. Nous devons être capables de décider avant fin 2018. Et déployer. Tant que ce n’est pas prêt, il y a FranceConnect. En parallèle, on déploie les autres briques.

Carte ou pas carte ?

Nota bene : cette question me semble plus accessoire que les suivantes. Elle est assez technique et n’apporte pas de repère conceptuel et architectural majeur. Si vous êtes pressé, je vous inviter à passer directement à la question suivante.

Cette question semble donc complètement ouverte pour le groupe de travail inter-ministériel. Celle-ci appelle d’autres sous-questions :

  • Le texte de Carte Nationale d’Identité dite électronique, dont les décrets ont été promulgués dans les dernières semaines du quinquennat de Nicolas Sarkozy a été censuré par le Conseil Constitutionnel, qui n’acceptait pas l’usage de la puce du dispositif pour signer des documents électroniquement.
    • Est-ce raisonnable de modifier la constitution pour surpasser ce point de blocage ?
    • Quels ajustements techniques permettraient de surpasser ce problème, sachant que le projet de loi prévoyait déjà à l’époque deux compartiments distincts pour cette carte (une pour les usages régaliens, l’autre pour la vie quotidienne).
    • Serait-il toujours intéressant de fournir une telle carte à puce si le citoyen ne peut que prouver son identité (s’identifier et s’authentifier) et non pas signer électroniquement des documents ?
  • Une puce électronique avait été intégrée aux premiers permis de conduire au format européen par l’ANTS. Cette puce, qui permettait de vérifier l’authenticité du titre présenté, a été supprimée au bout d’un an pour des raisons budgétaires.
    • Quel surcoût induiraient la fabrication et la distribution de telles cartes ?
    • Quels risques et quels surcoûts pourrait induire la découverte a posteriori d’une faille de sécurité dans les titres émis (exemple du cas Estonien en 2017) ?
    • Certaines villes, comme Angers, mettent à disposition une carte « de vie quotidienne » disposant de plusieurs compartiments étanches permettant de stocker des informations liées à plusieurs types d’usage. Quel est le coût de ces technologies ? Quelle est leur évolutivité ? Quel est le retour d’expérience de ces agglomérations ?
  • Une carte physique « à tout faire » est-il réellement porteur de simplification ?
    • Sur le plan logiciel, les cas d’usages d’une telle carte passent en grande partie par la saisie d’informations sur un navigateur web. Il n’existe à l’heure actuelle aucun standard stable et implémenté permettant d’utiliser facilement un dispositif de signature physique (telle une carte à puce) via un navigateur web. Il est nécessaire d’installer de complexes logiciels (middleware), hors de porté de nombreux citoyens, et d’autant plus complexe à utiliser dans un environnement mobile.
    • Les pays ayant distribué de telles cartes depuis une dizaine d’années (Espagne, Belgique, etc.) observent-ils le développement d’usages réels au-delà de quelques cas d’usages marginaux ?
    • L’achat d’un lecteur de carte nécessitera-t-il un dispositif de subvention sur condition de ressource complexe et couteux à gérer ?
  • La fonction de signature électronique ne pourrait-elle pas être fournie par un autre moyen ?
    • Ne serait-il pas possible d’adjoindre à l’État plateforme un composant de signature, permettant une gestion transparente des clés à la place du citoyen une fois celui-ci authentifié via FranceConnect ?
    • Au-delà de fournir le moyen d’authentification au citoyen, cette brique ne pourrait-elle pas faciliter, via une API simple, l’intégration de la signature au sein des administrations et organismes publics (ou non) ?
    • Pour les usages réclamant un plus fort niveau de sécurité (niveau eIDAS 2), ne pourrait-on pas mobiliser l’usage de la carte vitale ?
    • Serait-il moins couteux d’ajuster le processus de délivrance de cette carte Vitale que d’en produire une nouvelle, pour atteindre une même valeur probante (niveau eIDAS 3) ? De même, d’autres possibilités techniques existe pour avoir une authentification de niveau 3 : l’usage du de la SIM mobile (Orange est déjà fournisseur d’identité FranceConnect) ou la reconnaissance faciale (cf expérimentation ANTS).

Réduire l’identification à un seul vecteur est-il souhaitable ?

L’interview de Mounir Mahjoubi dans L’usine digitale sous-entend, via la phrase « Tant que ce n’est pas prêt, il y a France Connect« , que cette future identité numérique sera unique et remplacera l’architecture FranceConnect. L’approche qui me semble proposée par le gouvernement est de résumer l’authentification à un seule et unique vecteur d’identification/authentification.

Dans un article précédent, j’ai expliqué pourquoi créer une base de données centralisatrice unique ne me paraissait ni pérenne, ni architecturalement pertinent pour simplifier durablement la vie des usagers. En effet, il est nécessaire que les administrations communiquent, dès lors que le citoyen l’accepte explicitement, les informations nécessaires à la réalisation des démarches administratives déjà connues. Cependant, une base centralisatrice ultime est une chimère étant donnée la vitesse d’évolution des organisations et des systèmes d’information. En revanche, apprendre aux organismes publics à concevoir des SI nativement ouverts sera beaucoup plus pérenne et évolutif.

L’absence de base de données unique n’interdit en aucun cas la création d’un portail agrégateur d’API se connectant en temps réel aux systèmes d’information des divers organismes (tel www.mesdroitssociaux.gouv.fr). Telle la base chimérique évoquée plus haut, le portail ne sera par nature jamais 100% complet. Cependant, avec cette architecture inter-opérable et décentralisée, l’incomplétude du portail « phare » ne limitera pas le développement de services complémentaires utilisant les API d’autres SI publics.

De la même manière, j’ai des doutes sur la pérennité d’une identité numérique unique. Créer une « nouvelle identité », qu’elle soit virtuelle ou matérialisée une carte physique, peut être une bonne chose. Cependant, je pense qu’elle devrait s’inscrire dans l’architecture de fédération d’identités FranceConnect actuelle permettant par nature la gestion de plusieurs vecteurs d’identification et d’authentification. Ainsi cette « nouvelle identité » serait un Fournisseur d’Identité FranceConnect supplémentaire, et ne remplacerait en aucun cas l’infrastructure FranceConnect en tant que telle :

  • Tous les usages ne nécessitent pas le même niveau d’authentification. Plus un procédé d’authentification est sécurisé, plus il est contraignant pour l’usager. Aussi, il me parait dommage de ne pas pouvoir adapter le niveau d’authentification demandé par un fournisseur de service à la sensibilité des services qu’il propose. Cette souplesse est aujourd’hui permise par FranceConnect.
  • Tous les usagers ne seront pas forcément éligibles à cette nouvelle identité, ou ne souhaiteront pas forcément y souscrire. De même, la perte de ce facteur d’authentification pourrait priver l’usager de services en ligne. Conserver une architecture telle que FranceConnect (reposant sur le standard OpenIDConnect) permettra à l’usager d’utiliser une autre identité en cas de perte du vecteur d’identité qu’il utilise habituellement.
  • Le règlement Européen eIDAS impose que chaque citoyen puisse s’authentifier sur les services publics des États de l’UE via un vecteur d’authentification émis par son pays d’origine. L’architecture FranceConnect permettra l’intégration de ces ressortissants communautaires de manière transparente pour les fournisseurs de service. Permettre un usage de la nouvelle identité numérique du gouvernement sans passer par FranceConnect conduira donc à traiter les ressortissants comme des populations de seconde zone, ce qui est contraire à l’esprit eIDAS.
  • FranceConnect a été créé suite à l’échec de l’identité unique mon.service-public.fr. Les chiffres de recrutement montraient que les citoyens préféraient utiliser les comptes qu’ils possédaient déjà auprès de tiers de confiance publics tels que l’Assurance Maladie ou la DGFiP que de créer un nouveau compte « à tout faire ».

L’architecture FranceConnect repose sur des standards du web techniquement simples à mettre en œuvre. La création de cette nouvelle identité numérique ne doit pas permettre aux entités publiques de s’affranchir de cette intégration, sans quoi cela reviendrait à tuer, de fait, le principe de fédération.

L’infrastructure pour décloisonner les administrations n’existe-t-elle pas déjà ?

Plus que l’unicité du vecteur d’authentification, ce qui importe pour l’usager est de ne pas avoir à fournir d’informations ou de pièces justificatives qui seraient déjà en possession d’un organisme public (ou privé réglementé), suivant le principe du Dites-le nous une fois. Le sujet n’est pas le stockage de la donnée, mais sa propension à circuler de manière rapide. Autre point majeur, rappelé par Mounir Mahjoubi à l’Usine Digitale, la protection des données personnelles des usagers. Celui-ci doit donc pouvoir :

  • Techniquement, autoriser explicitement une administration à fournir une autre administration une donnée le concernant, dans un but précis (correspondant à ce que la CNIL appelle la « finalité du traitement »). Il s’agit là de l’application du principe d’auto-détermination informationnelle soutenu par le Conseil National du Numérique en 2015.
  • Cette autorisation doit pouvoir être donnée en temps réel afin d’éviter les longs délais réglementaires préalables à l’établissement d’un flux d’échange bilatéral entre deux administrations.
  • De même, le citoyen doit pouvoir vérifier a posteriori la nature des données (pas forcément les données elles-mêmes) échangées entre deux administrations.

Bonne nouvelle, toutes ces contraintes sont déjà respectées par FranceConnect ! En effet, si la presse a préféré décrire FranceConnect comme un simple moyen d’authentification, ce composant est avant tout précieux, car il organise la transmission à la volée d’information de manière décentralisée !

Enfin, lorsque Mounir Mahjoubi annonce sur LCI que cette nouvelle identité numérique permettra de se connecter sur le site de « la sécurité sociale », des impôts, de Pôle Emploi, de la CAF avec un seul mot de passe. Là aussi, FranceConnect le permet déjà techniquement. Le problème est ici politique. Les acteurs ne jouent pas complètement le jeu, et leurs tutelles ne les ont pas contraint jusqu’ici. Il est ainsi regrettable que le bouton FranceConnect ne soit présent sur ameli.fr, alors que ce site permet justement l’identification des citoyens via FranceConnect depuis d’autres sites (ce sont des Fournisseurs d’identité) ! Il est ainsi possible de s’authentifier sur se site de l’assurance-retraite avec son compte DGFiP ou Ameli, mais pas de se connecter à son compte Ameli à partir de son compte DGFiP ! Le bouton FranceConnect venant tout juste d’apparaitre sur impots.gouv.fr, gageons qu’il arrivera bientôt sur Ameli.fr

Peut-être que mon raisonnement fait fi d’un argument important justifiant une remise en cause de FranceConnect. Dites-le moi si c’est le cas !

Le plus important n’est-il pas d’encourager le raccordement des organismes publics à l’infrastructure d’échange existante plutôt que de casser la dynamique de montée en charge avec un chamboulement d’architecture ?

Les grosses organisations, publiques comme privées, ont une inertie qui nécessite de nombreux efforts et beaucoup de temps pour produire des résultats. Ainsi, une relative stabilité des protocoles et des standards me semble nécessaire pour que ceux-ci soient mis en œuvre dans les administrations et les territoires. Dans la mesure où FranceConnect mobilise des standards ouverts, les éditeurs de logiciel métier ont pu les intégrer relativement rapidement. Ainsi, le compte Twitter de la DINSIC (@_FranceConnect_) affiche depuis quelques semaines l’entrée en production d’un fournisseur de service chaque jour !

D’autre part, la marque FranceConnect est de plus en plus connue par les citoyens, qui l’utilisent sur les portails de grands opérateurs tels que le GIP Union-Retraite, la CNAV, ou encore l’ANTS.

La mayonnaise est donc en train de prendre. Il me semble nécessaire de poursuivre dans cette direction, mais d’accélérer les efforts de pédagogie auprès des fournisseurs de données et de services qui n’identifient pas encore suffisamment l’importance et l’urgence d’ouvrir leur SI via des API à l’état de l’art, en accès et modification, en temps réel et en aucun cas limité à des accords bilatéraux avec des consommateurs pré-définis.

Changer l’architecture maintenant apporterait peut-être en termes de communication au gouvernement, mais ne me parait pas judicieux. L’attentisme qui en découlera et l’énergie qui devra être mobilisée pour migrer retarderaient d’autant la vraie modernisation ; c’est à dire l’ouverture des SI sur tout le territoire.

Trois exemples d’accélérations à mener

Parmi les exemples les plus flagrants, FICOBA. À ma connaissance, ce ficher, regroupant l’ensemble des numéros de comptes bancaires ouverts auprès d’établissements français, n’est pas accessible via FranceConnect. Ainsi, l’accès à ces données est encore soumis à une liste de destinataires limitée par décrets, alors que FranceConnect permettrait à chacun d’autoriser (ou non) en temps réel l’accès à ces données par une administration tierce. De plus, les administrations n’ayant pas un accès temps réel à cette base de données, elles développent de complexes outillages pour sécuriser la modification en ligne des RIB/IBAN par leurs usagers. L’APIsation de FICOBA et son intégration à FranceConnect permettraient aux usagers de simplement sélectionner le compte bancaire voulu parmi la liste des comptes enregistrés dans FICOBA, sans ressaisie, sans risque d’erreur, et avec validation du statut du compte.

Autre exemple : il me semble indispensable d’ajouter à l’agrégateur APIparticulier une fonctionnalité de récupération des justificatifs, produits par des entreprises de secteurs réglementés (justificatif de domicile ou d’assurance par exemple).

Enfin, l’implémentation par tous les établissements d’enseignement supérieur d’une API permettant de vérifier les diplômes effectivement obtenus permettrait de limiter les fraudes et de fluidifier l’inscription aux concours de la fonction publique. L’implémentation de cette API par des acteurs tels que l’AMUE, l’Association Cocktail et le Ministère de l’Éducation Nationale permettrait dans un premier temps de couvrir une part significative des diplômés.

En somme, je pense que pour atteindre l’objectif de décloisonnement du gouvernement, il est avant tout nécessaire d’inciter, voire de contraindre, les administration à ouvrir leurs SI rapidement. Pour se faire, il est urgent de travailler avec elles à la construction des scopes de données FranceConnect et d’alimenter les hub d’API tels que APIParticulier ou APIEntreprise.

Pour de plus amples réflexions sur les extensions possibles de FranceConnect et de l’État plateforme, je vous propose de lire cet article.