Questions à Jean-Paul Delevoye

La réforme des retraites est un enjeu majeur de société. Nous avons l’opportunité de poser la question de l’efficience et de la justice du système sans être contraints par l’urgence budgétaire immédiate qui a caractérisé les dernières réformes, et notamment la fusion de l’AGIRC et de l’ARRCO.

La création d’un système unique de valorisation des carrières et de calcul des droits va indéniablement dans le bon sens. Cependant, comme souvent, le diable se cache dans les détails, et dans la trajectoire. J’ai regardé avec attention la première vague d’annonces du début de la semaine. Entre vulgarisations à outrance des organes de presse et flou des discours du politique et du monde syndical, j’aurais quelques questions à poser.

De nombreux articles parlent de « fusion des 42 régimes de base » ou de « régime unique ». Où se situe l’unicité ?

  • Est-ce un régime unique, au sens régime juridique précisant les cotisations, la valorisation et le calcul des droits ?
  • L’État restera-t-il en auto-assurance pour le risque vieillesse ?
  • Est-ce un organisme gestionnaire unique ? Quel est l’intérêt de garder des structures différentes si les règles de gestion sont rigoureusement identiques ? Les trois fonctions publiques délégueront-elles la gestion de ses pensionnés au régime général comme il peut le faire pour l’assurance chômage en lieu et place du SRE ?
  • Les deux ?

Un aspect majeur de la réforme est l’alignement progressif des régimes spéciaux (sous-entendu, tous les régimes de bases hors régime général). Le mot d’ordre est « Tout euro cotisé ouvrira les mêmes droits ». Principe louable. Cependant, il convient de préciser ce principe :

  • Est-ce que cela concerne les euros cotisés uniquement par le salarié, ou également les euros cotisés par l’employeur ?
  • Dans le second cas, les proportions entre la part salariale et la part employeur ont-elles vocation à être harmonisées entre tous les employeurs ? Les employeurs de régimes spéciaux déficitaires cotisent bien plus que les employeurs du régime général. Dans ce cas, le principe « tout euro cotisé ouvre les mêmes droits » ne règlerait pas l’injustice : les employeurs de régimes spéciaux – donc des organismes publics, continuerait sur-contribuer au montant de la pension des salariés de ces régimes. À défaut, le régime permettra-t-il à des employeurs privés de sur-cotiser volontairement pour leurs salariés, en lieu et place des supplémentaires privées ?

En ce qui concerne la fonction publique, le haut commissaire annonce intégrer les primes au calcul. Très bonne nouvelle, cela rendra enfin les choses comparables. Certes, les droits acquis pourraient être mis de côté avec un calcul de la pension à date de la réforme et création d’une soulte. Cependant, en pratique, je n’arrive pas encore à percevoir comment cela va s’opérer :

  • Intégrer les primes implique de payer des cotisations sur ces primes et donc d’avoir des droits sur ces primes.
  • L’État va-t-il compenser cette augmentation de l’assiette soumise à la part salariale par une augmentation mécanique du traitement de base ? Cela aurait des conséquences importantes sur le budget de l’État, et ferait porter la charge de la réforme induite par une petite partie de la population sur l’ensemble des contribuables. Cela ne reviendrait, du moins en transition, qu’à déplacer l’injustice.  D’autant plus que cette hausse compensatoire des traitements pourrait être revendiquée par les nouveaux entrants à terme, ce qui ne ferait que dégrader durablement et mécaniquement la masse salariale des trois fonctions publiques.
  • L’État va-t-il baisser le taux de cotisation sur la part salariale ? Cela induirait une moindre cotisation et annulerait donc en partie l’élargissement de l’assiette en termes « d’euros cotisés » et induirait donc une baisse des pensions/du taux de remplacement.
  • L’État va-t-il baisser le taux de cotisation sur la part salariale en augmentant celui de la part employeur ? Cela reviendrait à augmenter durablement la masse salariale des trois fonctions publiques, et de faire porter ce maintient de pension sur l’ensemble des contribuables. Le raisonnement est ici similaire à la question du paragraphe précédent.
  • L’État va-t-il laisser le régime actuel ouvert pour les agents publics en poste lors de la mise en place de la réforme ? Cela conduirait à une fermeture extrêmement lente de l’ancien régime, de l’ordre de 80 ans jusqu’au décès du dernier assuré. Cela ne parait guère compatible avec la temporalité politique et conduirait à complexifier la lisibilité du système en conservant deux modes de calcul en parallèle.
  • L’État va-t-il simplement soumettre ces primes aux cotisations salariales et patronales sans aucune forme de compensation ? Cela serait le plus logique à long terme, mais représenterait une baisse sur le traitement net significative. Les nouveaux entrants dans la fonction publique choisiraient en connaissance de cause, en revanche, la position est plus délicate à tenir pour les fonctionnaires déjà en poste.
  • La solution viendra-t-elle de la temporalité de la trajectoire, où l’intégration des primes se ferait progressivement sur une dizaine d’années au cours desquelles les compensations sur traitement brut par le budget de l’État pourraient être vues comme une monnaie d’échange contre le maintien du gel du point d’indice ?

Le principe « Tout euro cotisé donne les mêmes droits » n’induit pas que des droits seront ouverts sans avoir été cotisés. Ces avantages non contributifs constituent le cœur de la solidarité de notre système de retraite et ne doivent pas être négligés.

  • Cependant, là aussi, les règles de calcul seront-elles alignées ?
  • Comment seront-ils financés ? Par le système assuranciel lui-même ou sur le budget de l’État ?

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.

La mutualisation du calcul des cotisations sociales plus prioritaire que le prélèvement à la source ?

Mise à jour du 12 juin 2017 : cet article a été publié il y a presque un an (19 juin 2016). L’esprit reste valide, à savoir que le prélèvement à la source est une bonne réforme mais n’était pas prioritaire lorsque le gouvernement l’a initiée au printemps 2015. Cependant, des investissements importants ont été réalisés par les collecteurs, notamment de la sphère publique ou sociale au cours des douze derniers mois. Dans ce contexte, la décision du Premier Ministre de maintenir le projet mais de temporiser sa mise en œuvre pour sécuriser le dispositif me semble appropriée.

Le prélèvement à la source s’annonce comme LA réforme technocratique et politicienne du quinquennat. Est-ce réellement une priorité pour l’intérêt général ? N’y a-t-il pas des réformes de fond, plus progressives, moins coûteuses et plus simplificatrices à mettre en œuvre ? Je propose une alternative. À débattre !

Sommaire

Le prélèvement à la source : plan de com’ pré-électoral ?

Le prélèvement à la source de l’impôt sur le revenu sera, sauf trébuchement constitutionnel, mis en oeuvre dès janvier 2018. C’est une réforme à forte visibilité, supposée simplificatrice, à un an du renouvellement de notre monarque républicain. La chose sera suffisamment avancée pour apparaître comme acte de modernisation du pays à l’actif du bilan du sortant mais pas suffisamment pour être déjà entachée de potentiels problèmes techniques. Bien pratique donc !

À défaut de grande réforme fiscale de fond politiquement compliquée(fusion IR/CSG, renforcement de la progressivité du barème, TVA sociale, taxe écologique…), le gouvernement pourra afficher une mesurette sur le plan politique… qui pourrait malgré tout poser des problèmes opérationnels. Sans compter que l’opposition parlementaire jurera la main sur le cœur de l’abroger ; même si elle envisageait elle-même la mesure il y a peu. Elle risquerait de balayer les importants investissements techniques réalisés entre temps si elle arrivait au pouvoir lors des prochaines élections.

À mon sens, cette réforme apporte assez peu de simplification et constitue plutôt une avance de trésorerie faite par les salariés qui provisionnaient jusqu’ici eux-même leur impôt sur le revenu. Pis : le vecteur de déclaration automatisé (la DSN) n’étant pas encore adopté par de nombreuses entreprises (et même pas planifié pour le secteur public).

Ne jetons pas le bébé avec l’eau du bain : le prélèvement à la source va dans le sens de l’Histoire. La France  rejoindra ainsi pas mal de nos partenaires à l’heure où l’harmonisation fiscale est perçue comme un nouvel élan pour la construction européenne. Cela suffit-il à faire du prélèvement à la source une priorité servant l’intérêt général pour autant, c’est une autre question…

L’internalisation du calcul des cotisations sociales

Comme déjà évoqué il y a un an, la Déclaration Sociale Nominative confirme son rôle de levier de simplification pour les employeurs, les organismes de protection sociale et les éditeurs. Je pense justement qu’il aurait été plus intéressant d’aller plus loin dans le développement de la DSN avant de se lancer dans le prélèvement à la source.

La philosophie générale de la DSN est de demander aux entreprises un minimum d’informations à un niveau de granularité fin et de laisser l’administration générer les agrégats dont elle a besoin. Cependant, dans le modèle actuel, les entreprises doivent continuer à calculer elles-mêmes les nombreuses cotisations dûes aux différents collecteurs de notre système de protection sociale. Pis : les entreprises agricoles, qui n’avaient pas à les calculer jusqu’ici, ont du s’aligner sur les processus du régime général. Dans les faits, elles font appel à un tiers-déclarant (cabinet d’expertise comptable ou organisme de gestion) ou investissent dans de coûteux logiciels de paie complexes à maintenir en cohérence avec la législation. Chaque bulletin de salaire coûte en moyenne 20€ à un employeur.

Dispenser de ces calculs de cotisations les entreprises qui le souhaitent me parait plus intéressant que le prélèvement à la source de l’IR.

Généraliser et unifier les dispositifs existants

Internaliser le calcul des cotisations sociales dans les organismes recouvreurs n’est pas une idée nouvelle. Les TPE et les particuliers employeurs disposent d’ores et déjà de services permettant de simplifier l’embauche la gestion du salarié. Ces services permettent :

  • la saisie des données individuelles du salarié
  • la saisie des données hautes du bulletin de salaire
  • le calcul des cotisations
  • le recouvrement automatisé des cotisations
  • l’édition d’un document assimilable à un bulletin de salaire
  • l’émission des déclarations sociales

Conscient de l’intérêt pour les entreprises, le gouvernement a élargi le dispositif aux entreprises de 20 salariés. Le dispositif reste cependant incomplet et exclut de facto de nombreuses entreprises. De plus ces dispositifs ne sont pas du tout inter-opérables avec le SI de l’entreprise.


Urbaniser le SI en cohérence avec l’État plateforme

Le SI des URSSAF, le SNV2, ne permettant pas pour le moment la gestion des cotisations à la maille individuelle. Peut-être qu’il serait possible d’étendre et de génériser et de modulariser de tels calculateurs. Ce nouveau système de « Titre emploi Service Unifié » (TESU) pourrait être utilisé par les entreprises volontaires afin de gérer, de manière plus ou moins complète, la paye leurs salariés.

Quelques propriétés fonctionnelles d’un tel système :

  • Les règles de calcul des contributions s’organisent sous forme arborescente : les règles du RG peuvent être complétées, le cas échéant, par les règles des régimes. Ce référentiel de règles de calcul est public, opposable et peut-être téléchargé par tous : entreprises, éditeurs, chercheurs, organismes…
  • Chaque régime est responsable de la mise à jour de ses règles spécifiques, en cohérence avec les textes législatifs et règlementaires en vigueur.
  • Le système permet à minima de :
    • Gérer complètement sa paie
    • Calculer les cotisations individuelles et agrégats établissement d’une DSN à partir d’un squelette DSN (établi à partir d’un logiciel gérant uniquement la partie haute du bulletin de salaire au format DSN).
    • Simuler une paie à une date antérieure ou postérieure à condition que les règles en vigueur à cette date soient déjà connues.
  • Le système permet d’éditer la fiche de paie sous forme PDF et de récupérer les données sous forme structurée (XML, JSON…) via l’IHM salariés et un webservice REST

Quelques propriétés techniques :

  • Conforme aux principes de l’État plateforme, ce système serait ouvert et disponible par API. Des acteurs tiers pourront interfacer directement leurs outils métiers (gestion des temps par exemple).
  • Des IHM reposant sur ces API permettraient aux entreprises les moins outillées de saisir manuellement les données de leurs salariés
  • Chacun des composants techniques serait faiblement couplé afin de permettre une réutilisation indépendante de chaque bloc par les déclarants ou les éditeurs. Un orchestrateur permet d’organiser les appels aux modules techniques afin d’apporter un service métier à l’usager.
  • Les instances des moteurs de calcul ne peuvent pas directement être appelées de l’extérieur. Les moteurs de calcul sont cependant open-source (et s’appuient sur un socle technologique open-source) et peuvent donc être instanciés sur une infrastructure privée (éditeur, entreprise) à moindre coût.
  • L’usager peut choisir le support de stockage qu’il souhaite pour l’export de ses fichiers (fiches de paie…) parmi ceux compatibles « état plateforme ».

Quelle valeur ? Quelles limites ?

Ce projet, au premier abord technique, rebat une partie des cartes et permet :

  • de simplifier le travail des entreprises réalisant leur paye elle-même et de donner un levier de négociation des prix de celles passants par un tiers-déclarant
  • d’homogénéiser les pratiques des régimes et de constituer un référentiel commun des règles de calcul des contributions, résultats d’une veille réglementaire mutualisée. Notons que la création de code de cotisations dits pivots sur lesquels reposeraient les cotisations des régimes spéciaux est déjà un objectif du Comité National de Normalisation des Données Sociales. Cela a d’ailleurs été implémenté par le réseau des URSSAF pour le régime spécial de l’Aslace-Moselle.
  • de disposer d’une vision globale de la législation relative au recouvrement pour appréhender plus facilement les simplifications potentielles des textes ou au contraire les contraintes administratives induites par de nouvelles mesures.
  • de fiabiliser le calcul des contributions et cotisations sociales
  • d’urbaniser le SI au service des usages en d’offrant une plateforme ouverte, inter-opérable et porteuse de valeur pour de nombreux acteurs économiques (et notamment de petites start-up innovantes) en diminuant le poids des mastodontes historiques.
  • de n’implémenter les changements de législation qu’une seule fois et non pas au sein de chaque dispositif de titre simplifié
  • limiter le pouvoir des corps intermédiaires et recentrer les cabinets d’expertise comptable sur le conseil juridique et de gestion. Ceux-ci n’oublieront pas de rappeler que les calculs de cotisations des pouvoirs publics sont parfois synonymes de difficultés sur le terrain.
  • augmenter la concurrence dans le secteur des logiciels de paye et potentiellement infléchir les prix des logiciels de paie. Afin de limiter la levée de boucliers des éditeurs ou de la DGCCRF, on pourrait imaginer  que certaines fonctionnalités soient payantes à partir d’un certain nombre de salariés, du moins dans un premier temps.

La performance globale de la plateforme pourrait poser problème : si l’on lance 16 millions de payes (soit une seule par salarié français, ce qui est sous-estimé) au même moment, l’architecture nécessaire pour tenir la charge serait potentiellement importante. Une ouverture maîtrisée et progressive du service serait donc nécessaire. Cette conception architecturale permet néanmoins une réutilisation maximale de chacun des composants, open-source, qui deviennent des biens communs. Ils peuvent être instanciés chez les déclarants, éditeurs ou tiers-déclarants, ce qui soulage d’autant l’infrastructure du service.

Let’s Encrypt : sécurité pour tous ou passoire pour tous ?

Let’s encrypt vient de sortir de sa version béta. Ça m’inspire une petite réflexion à deux balles du dimanche soir.

Chaîne de confiance et authentification des sites web

Les concepteurs de certains sites web choisissent parfois de chiffrer la connexion entre votre navigateur internet et le serveur sur lequel est hébergé le site web. Cela peut avoir plusieurs finalité : éviter qu’un des intermédiaires entre votre navigateur et le dit serveur n’obtiennent des informations confidentielles (mots de passe, informations de paiement) ou puissent connaitre les pages que vous avez consultées sur ce site (page wikipedia traitant de droits de l’homme dans une dictature par exemple). Pour faire simple, lorsque vous vous connectez, un échange de clés intervient afin que chacun puisse chiffrer les données envoyées. Le chiffrement de ce flux d’octets entre vos deux machines se matérialise par le fameux « cadenas » dans votre navigateur.

Au delà d’une écoute passive, les nombreux réseaux que traversent ces octets pourraient décider de se faire passer pour ledit site web. Il est donc nécessaire que le serveur répondant à la requête de l’utilisateur prouve qu’il est bien celui qu’il prétend être. Pour cela sa clé publique (ie son certificat) est signé par une autorité de confiance. Lors de la connexion de votre navigateur web, celui-ci vérifie que le certificat envoyé par le serveur correspond au domaine demandé. Il  utilise ensuite à la clé publique de l’autorité de confiance qui a signée ce certificat (ou le certificat d’autorités intermédiaires) pour vérifier l’authenticité du certificat transmis. Cette clé est stockée localement au sein du navigateur. Les navigateurs du marché sont donc distribués avec les clé publiques d’un nombre limité d’organisations reconnues pour être des tiers de confiance.

NB : L’architecture présentée ici ne fonctionnent bien évidement pas qu’avec le web mais cet exemple est particulièrement pédagogique.

Pourquoi Let’s encrypt ?

Lorsque j’ai installé dumaine.me sur un vieil ordinateur portable situé sous mon bureau, trois possibilités s’offraient à moi :

  • ne rien chiffrer, ce qui exposait le mot de passe ce blog par exemple
  • chiffrer en utilisant un certificat auto-signé : chaque visiteur souhaitant accéder à un contenu chiffré devait ajouter ce certificat à son navigateur. Je devais donc le transmettre par un canal « sûr » avant qu’il puisse se connecter : pas très pratique !
  • passer par une autorité de certification reconnue par la plupart des navigateurs du marché

Pour des questions pratiques, j’ai choisi cette troisième option. J’ai demandé à la seule autorité de certification (reconnue sur tous les OS par les navigateurs les plus utilisés) gratuite que je connaisse de signer mon certificat : StartSSL.

Ces organisations, la plupart à but lucratif, ont pour modèle économique de garantir différents niveaux de confiance, liés à différents niveaux de vérification, d’informations circulant sur internet, et principalement des certificats évoqués ci-dessus. StartSSL propose une gamme gratuite mais comportant certaines restrictions.

De nombreuses machinent hébergent des données personnelles sans chiffrer leur échanges car leur propriétaire n’a pas les moyens techniques et financiers de les sécuriser. Let’s encrypt tend à satisfaire ce besoin : il fournit une suite logicielle facilitant la configuration des serveurs web et propose de signer gratuitement les certificats produits via une autorité de certification reconnue (celle de Cisco en l’occurrence).

Quelles limites ?

Depuis son lancement à l’automne, la part des sites chiffrant leurs communications a augmentée significativement. Certains industriels incluent aujourd’hui les certificats Let’s encrypt dans des produits grands public (NAS, Freebox, domaines OVH, Gandi etc). De nombreuses données personnelles et/ou sensibles qui circulaient en clair il y a un an sont aujourd’hui chiffrées. Une victoire de plus pour Canard ? Ce n’est pas si simple…

Cette architecture de tiers de confiance constitue, avec le DNS et la hiérarchie des opérateurs (tiers 1 / tiers 2 / tiers 3), l’une des seules choses non horizontales, non distribuées (au mieux décentralisées) de l’architecture d’internet. Le fait que de nombreux utilisateurs passent par le même acteur pour chiffrer leurs communications peut potentiellement diminuer la résilience de l’ensemble. Cette autorité de certification devient un hony pot de plus en plus appétissant, que se soit en terme d’attaques ou de pressions politiques.

Le scandale Snowden a confirmé les craintes de la communauté informatique internationale : certains gouvernements espionnent massivement leur population. Let’s encrypt pourrait potentiellement leur faciliter le travail. L’épisode Lavabit confirme les pressions exercées sur des acteurs ciblés outre atlantique.

Dans la série « C’est quoi le pire ? » : se croire en sécurité lorsque ce n’est pas réellement le cas ou savoir que l’on est pas du tout en sécurité ? À partir de quand est-on « réellement » en sécurité ? Cette notion a-t-elle un sens indépendamment du contexte ?

Néanmoins, la formalisation d’un protocole (ACME) visant à simplifier la configuration et le renouvèlement de certificats, fussent-ils ou non distribués via l’autorité de certification Cisco, est une amélioration significative et aidera à la démocratisation de l’auto-hébergement.

Au delà de l’aspect technique, Let’s encrypt a une vertu indéniable : son buzz contribue à mieux faire connaitre des points fondamentaux de la sécurité informatique. Et qui sait, cela induira peut-être l’émergence d’une alternative réellement distribuée ? Des pistes sont actuellement explorées du côté de la blockchain…

#CodeImpots : premier bug ?

Mise à jour : si l’article posté était bien un poisson d’avril, le lien entre potentiels bugs et pratiques d’ouverture n’en reste pas moins intéressant.

Le code source de la calculatrice des impôts a été présenté ce matin. \o/ L’un des participants au hackathon #CodeImpots aurait découvert un bug d’arrondi qui pourrait engendrer des rappels si c’est réellement ce code qui est en production à la DGFiP.

Il va être intéressant de voir comment réagissent les autorités. Aux extrémités, je perçois deux postures :

  1.  « L’erreur est humaine, si nous avions partagé ce code plus tôt nous n’aurions peut-être pas poussé cette erreur en production. Le partage donne l’occasion à nos agents d’améliorer continuellement nos applications et nous leur en donnerons les moyens. Ce changement de culture se fera progressivement mais il faut prendre le pas tout de suite. Cette nouvelle pratique est la suite logique des démarches de mutualisation des SI. »
  2. « Ce coup de com’ était sympa mais revenons à nos pratiques ancestrales et à une opacité totale où l’on peut imaginer faire les choses parfaitement sans que ce soit vérifiable. Nous utiliserons à l’avenir l’exception de sécurité nationale de la loi pour une République Numérique pour bloquer toute nouvelle tentative d’accès par la CADA (article 1 bis du texte présenté au sénat). La volonté politique de changement n’est pas assez forte. »

Je croise les doigts pour que le premier cas l’emporte durablement !

Petite satisfaction personnelle pour terminer : la DGFiP a décidé d’utiliser Python pour développer son interpréteur. Mon langage préféré se diffuse donc au delà d’OpenFisca dans la sphère publique. 😉

WebUSB : un pas de plus vers l’omnipotence des navigateurs web

Oracle a récemment annoncé que les Applets Java seraient dépréciés à partir de la version 9 du JDK (à paraître en 2017). Une annonce de plus vers la fin des plugins au sein des navigateurs, entamée depuis longtemps par AdobeFlash pour diverses raisons.

Si les applets seraient fonctionnellement remplaçables par JavaWebStart, cette disparition devrait plutôt se faire au profit de l’éco-système HTML5. WebGL, web-socket, web-workers, webRTC/ORTC ou le contreversé Encrypted Media Exetensions : de plus en plus de standards du W3C (voire conjoints à l’IETF) tendent à rapprocher, à tord ou à raison, nos navigateurs web de machines virtuelles complètes. Il reste cependant des choses encore hors de leur portée, notamment en termes d’accès à nos périphériques.

Depuis quelques années, le W3C forme des groupes dédiés à la construction d’API haut niveau spécifiques à chaque catégorie de périphériques standards (webcam, micro…). D’une part cette approche exclut durablement tous les périphériques exotiques. Une startup ayant développé un nouveau gadget ne pourra pas proposer à un tiers de développer une application web l’utilisant sans installer des drivers sur la machine de l’utilisateur, machine pouvant être tout aussi exotique que le gadget à piloter.

D’autre part, même les périphériques « classiques » ne sont pas encore tous supportés. Un exemple : les dispositifs de signature électroniques à carte SIM (ou smartcard), tels que ceux utilisés en France pour signer les réponses à appels d’offres publics. Ni l’API WebCrypto ni l’API Key Discovery ne permettent de se passer du middleware, alors même qu’un standard USB (le CCID) est dédié à ce type de périphérique (voir ici ou là). Ce manque été abordé lors du workshop « Authentification, hardware tokens and beyonds » en 2014 mais l’implémentation de CCID dans les navigateurs ne semble pas à l’ordre du jour.

Ces deux freins pourraient bientôt sauter : un draft W3C non officiel, mis à jour le 17 février 2016 par des employés de Google, spécifie l’accès bas niveau à l’USB depuis un navigateur web. D’après leur wiki, Firefox est également intéressée par WebUSB depuis 2011. Affaire à suivre…

À noter : le développement de l’accès bas niveau à l’USB n’est pas opposé à la création d’API haut niveau centrées sur un type de périphérique puisqu’elles permettent l’accès à tous les périphériques de ce type ; même s’ils ne sont pas connectés en USB.

FranceConnect, décollage imminent

Yeeeahaaa !

Éric Heijliger, membre de l’équipe FranceConnect à la DINSIC, a annoncé vendredi le planning mise à disposition du premier fournisseur de données de FranceConnect. À partir de septembre, tout fournisseur de service FranceConnect pourra, après autorisation explicite du citoyen, obtenir certaines informations fiscales auprès de la DGFiP et ainsi faciliter de nombreuses démarches en ligne. Une version de démonstration de l’API de la DGFiP sera disponible pour les développeurs dès le mois de mars.

Je vais essayer ici de faire le bilan de l’existant et de proposer quelques pistes. Cela n’est rien d’autre qu’une première réflexion publiée en mode best-effort qui induira peut-être des itérations postérieures et débat.

Retour sur les deux fonctions principales de FranceConnect

Jusqu’ici, FranceConnect était principalement décrit dans la presse comme un moyen de se connecter à plusieurs services publics en ligne en ne s’identifiant qu’une seule fois (un mécanisme de SigleSignOn). Cette fonctionnalité est intéressante dans la mesure où créer un énième compte est toujours rebutant, mais elle n’est pas nouvelle (mon.service-public.fr proposait un service du même type) et n’apporte pas de gain de productivité sensible.

Comme je l’ai déjà expliqué ici et là, la puissance de FranceConnect est de permettre le transfert de données structurées en temps réel entre administrations une fois que l’administré a donné son accord. Dès lors, une administration peut mettre à disposition de la communauté FranceConnect une interface logicielle (on parle d’Application ProgrammingInterface ou API) qui permettra aux fournisseurs de services (une mairie par exemple) d’obtenir des informations ciblées sur un administré et ainsi lui éviter de fournir des pièces justificatives.

Attention, cette possibilité de communication entre entités s’accompagne de certains gages de protection des données du citoyen :

  • Aucune donnée ne transitera par un point central, seule l’autorisation passera par FranceConnect : « Moi, Aurélien Dumaine, autorise la DGFiP à communiquer mon revenu fiscal à ma mairie pour inscrire mon enfant à la crêche. »
  • Cette autorisation n’est valable que quelques minutes, juste ce qu’il faut pour terminer ma démarche en ligne.
  • FranceConnect ne suppose en aucun cas la mise en place d’un numéro d’identification commun à plusieurs administrations. Il est même potentiellement plus protecteur que ce qu’il se passe actuellement lors du transfert de pièces justificatives papier : seules les informations nécessaires sont transmises.
  • Le citoyen a la possibilité de consulter a posteriori l’historique de tous les échanges qu’il a autorisés via FranceConnect : heure et type de données transmises (aussi appelés scopes dans le protocole OAuth)
  • La règlementation prévoit qu’une alternative à FranceConnect doit toujours perdurer. Le citoyen peut choisir ce canal (pas forcément dématérialisé) et éviter FranceConnect s’il le souhaite, c’est ce qui s’appelle l’autodétermination informationnelle.
  • L’architecture est souple et dénote un équilibre sain entre contrôle technologique a priori, capacité d’audit et potentielles représailles juridiques a posteriori en cas d’abus.

2016 : la montée en puissance

L’année 2016 sera donc synonyme de montée en puissance pour FranceConnect. Plusieurs challenges se dessinent.

Des challenges humains et politiques

  • les citoyens, mais surtout les administrations doivent comprendre FranceConnect et se l’approprier pour que l’utiliser devienne un réflexe collectif. En 2017, construire un nouveau téléservice sans implémenter FranceConnect devrait devenir une exception.
  • FranceConnect doit demeurer KISS : lire quatre schémas d’architecture, cinq requêtes HTTPS et deux jours de développement suffisent aujourd’hui à l’implémenter. Tout repose sur des protocoles ouverts, à l’état de l’art et de nombreux composants sont disponibles pour faciliter son intégration.
  • créer un esprit de communauté pour capitaliser sur les bonnes pratiques (notamment en termes de design d’API) et partager du code
  • insuffler une culture d’agilité et de best-effort permettant des délais de mise en production réduits
  • dessiner des scopes les plus atomiques possibles afin que seules les informations nécessaires soient transmises et convaincre les fournisseurs de service de ne pas abuser de cette facilité d’échange (demander tous les scopes nécessaires, mais uniquement les scopes nécessaires).
  • les fournisseurs de données ne doivent pas limiter l’accès à leur API selon le service demandeur. Cela aurait pour effet de faire perdurer des accords de partage bilatéraux, obstacle à tout nouvel échange, notamment auprès des collectivités territoriales.
  • les usagers doivent être sensibilisés à la sécurité (mot de passe complexe, phising reprenant la mire FranceConnect…)
  • (mise à jour du 15/03/2019) l’ensemble des ministères et de leurs opérateurs doivent jouer le jeu, et intégrer leur démarche API dans l’écosystème FranceConnect. Contre-exemple : d’après cette page du site de l’ANTS, l’agence semble avoir lancé des travaux d’interconnexion propriétaires avec les fournisseurs d’énergie.
  • (mise à jour du 05/04/2019) l’urbanisation du SI de l’état doit permettre d’éviter à de multiples acteurs de créer des plateformes différentes pour un même usage. Pour limiter ce risque, les outils de références doivent être à l’état de l’art et fonctionnellement poussés.Contre-exemple : l’AIFE a lancé son catalogue d’API PISTE, qui semble concurrencer fortement api.gouv.fr.
  • (mise à jour du 24/06/2019) la CNIe, nouvellement annoncée pour 2021 et portée par une mission du ministère de l’Intérieur distincte de la DINSIC, ne devra pas être utilisé comme vecteur d’identification/authentification sur un site web en dehors de l’écosystème FranceConnect (mon analyse ici)

Des challenges techniques

  • la mise en évidence de failles de sécurité ou de la non-scalabilité du système au cours des premiers mois, et notamment de la première campagne de déclaration d’impôt pourrait être fatal au concept ; d’autant plus que nous sommes à un an d’une potentielle alternance politique.
  • mettre en oeuvre la forge (partage de code informatique) ainsi que le « magasin d’API » prévus par le SGMAP. Ce dernier permettra à tous de connaitre quelles administrations exposent quelles données via FranceConnect, de gérer l’évolution de ces API (alerte email n mois avant décomissionnement par exemple) et monitorer l’usage de FranceConnect (historique de disponibilité, graph des flux…)
  • ré-intrégration de mon.service-public.fr dans le portail service.public.fr récemment refondu
  • localiser les données de références et faire qu’elles soient exposées via des API REST simples (article plus détaillé à venir) :
    • sources publiques nationales : fichier des comptes bancaires (FICOBA),  historique des données de salaire (données de la DSN), casier judiciaire, service national, fichier des immatribulations (SIV), permis de conduire (FAETON)…
    • hubs permettant d’accéder via des API unifiées à des données provenant de bases de données distribuées : APIEntreprise(CFE, chambres consulaires, assureurs de branche pro, sécu), APIsécu (4 branches, 37 régimes retraite, une quinzaine de régimes maladie, RNIAM, RGCU, RNCPS), APIuniversité(diplômes, inscriptions, présence), …
    • hubs d’accès à des données issues d’entreprises privées, notamment celles issues de professions règlementées : fournisseurs d’attestation d’assurance (habitation, automobile, responsabilité civile…) ou de domicile (d’eau, d’électricité, de télécom fixe) par exemple
    • … voire un jour des sources publiques étrangères
  • diversifier les fournisseurs d’identité :
    • étendre FranceConnect aux entreprises, aux associations et aux particuliers actuellement exclus du dispositif (les collégiens, lycéens et étudiants n’ont pas d’accès DGFiP, ni à la CNAMTS alors que ce sont parmi les plus exigeants en termes de service public numérique)
    • intégrer les agents publics dans une logique de mutualisation du SI de l’État (annuaires, SSO, cartes professionnelles…)
    • intégrer l’identification à double facteurs (utilisation de son smartphone ou de sa carte vitale en plus du couple identité/mot de passe) voire la certification « physique » (vérification d’identité par un agent public ou un postier) en accord avec les niveaux de sécurité 2 et 3 de la norme eIDAS
    • intégrer les fournisseurs d’identité étrangers conformes à la norme européenne eIDAS
  • de manière plus opérationnelle, si la signature d’un document quelconque est sur le chemin critique de partenariat (pour les fournisseurs de service ou de données) et que ce processus n’est pas dématérialisé, la montée en charge risque d’être ralentie (ministères, organismes de protection sociale, 37k collectivités locales, 1200 opérateurs, 2500 structures hospitalières potentiellement concernés). D’autre part, ça serait incongru pour un projet de dématérialisation (comme ce fut le cas pour Hélios, Comedec ou Actes).

Quelles extensions pour FranceConnect ?

Au-delà de ces deux fonctionnalités majeures, FranceConnect peut devenir le point de départ de nombreux services. Toute la difficulté consistera à garder les différentes briques les plus indépendantes possibles afin de conserver un système coeur aussi simple, souple et robuste que possible. Le risque étant de créer très vite des usines à gaz sans le vouloir… risque auquel je m’expose totalement par les propositions suivantes.

Ces différentes briques sur étagères constituent le coeur de l’État plateforme : chaque collectivité/ministère/organisme peut choisir d’intégrer les services qui lui sont utiles en toute souplesse avec un minimum d’effort. Voici quelques idées quand au développement de FranceConnect à moyens et longs termes.

Un composant de signature électronique

La signature électronique de documents est encore à l’heure actuelle quelque chose de techniquement complexe à l’usage (avez-vous déjà essayer de signer une réponse à appel d’offre public depuis un Mac ?), peu répandu et cher. Or le besoin est énorme et de nombreux acteurs seraient preneurs d’une brique mutualisée de signature électronique proposée par l’état plateforme à un tarif raisonnable suivant un process de ce genre :

  1. L’usager se connecte à la téléprocédure (de l’URSSAF par exemple) via FranceConnect (particulier ou pro) et suit les premières étapes de la procédure.
  2. En fin de procédure, l’URSSAF lui propose de signer électroniquement le document via le composant de signature de l’état plateforme (ou de l’imprimer et de le retourner par papier)
  3. L’URSSAF redirige l’usager vers cette IHM et communique à ce composant le contrat à signer.
  4. Lorsque l’usager clique sur le bouton « signer »
    1. Si l’usager n’a jamais signé un document via ce composant, celui-ci génère une paire de clés et les signe puis signe le document.
    2. Sinon, le composant de signature utilise le certificat déjà émis et stocké localement.
  5. L’usager est renvoyé vers l’URSSAF.

L’usager n’a pas à gérer son certificat. L’URSSAF n’a pas à gérer de PKI. Une tarification raisonnable peut être mise en place à l’usage.

Patterns d’API : gestion des flux retour et fiabilisation de la donnée

Lors d’une demande en ligne intégrant l’échange de données via FranceConnect, il peut arriver que l’usager constate une erreur au sein de ces données. Il serait intéressant d’intégrer un flux retour (du fournisseur de service vers le fournisseur de données) lorsque l’utilisateur indique une erreur et propose de nouvelles valeurs. Le fournisseur de données pourrait alors déclencher un processus de fiabilisation/vérification de ladite donnée et éviter de transmettre une nouvelle fois une information potentiellement erronée.

Cette fonctionnalité s’appuie là aussi sur un pattern d’API. C’est au fournisseur de données d’annoncer, au sein du magasin d’API si cette fonctionnalité est disponible et avec quel paramètre.

Attention néanmoins, cela impose une démarche pédagogique dans le cas où l’usager ne comprend pas pourquoi la valeur transmise était correcte.

Après la lecture par API, l’alimentation par API

D’autre part, l’accès en lecture par API aujourd’hui promu s’étendra peut-être demain à un accès total au service public numérique par API en sus des téléservices et IHM existants. La modification des données (ou réalisation de procédures) dans une application tierce offrant une expérience utilisateur différenciée sera rendue possible.

Jetons d’autorisation longue durée et propagation d’évènements

Dans le modèle actuel, l’autorisation de transfert de données n’est valable que quelques minutes. Laisser l’usager prolonger la durée de ces autorisations (de l’ordre de plusieurs mois) permettrait d’intégrer des échanges asynchrones entres organismes tout en donnant une meilleure visibilité au citoyen sur l’usage de ses données. D’autre part, un fournisseur de données pourrait proposer à un fournisseur de service de s’abonner à un scope : dès que la donnée change, le fournisseur de données envoie un évènement de mise à jour aux fournisseurs de services qui sont abonnés à ce scope pour cet usager (une fois avoir vérifié la validité de l’autorisation). En contrepartie, FranceConnect envoie un email à l’usager à chaque fois que l’autorisation sur ce scope est vérifiée et lui indique comment révoquer l’autorisation s’il le souhaite.

Le code logiciel de ce mécanisme d’abonnement pourrait facilement être partagé librement sur la forge logicielle de la DINSIC et intégré par chaque fournisseur de données intéressé. Il serait également possible de mutualiser en hébergeant, de manière parallèle à FranceConnect, un serveur gestionnaire d’évènements interministériel indiquant que tel scope a été mis à jour (« le revenu fiscal 2015 d’Aurélien Dumaine a été modifié », sans préciser le contenu de cette mise à jour (« la nouvelle valeur du revenu fiscal 2016 d’Aurélien Dumaine est de x € »). Ne pas inclure le contenu de la mise à jour dans l’évènement permet de conserver le caractère ignorant du hub. Cela me parait très important, même si cela génèrera est coûteux en termes de performance : dès lors qu’un système recevra une notification de mise à jour, il consultera probablement la nouvelle valeur auprès du fournisseur de données, qui devra revérifier la validité de son autorisation auprès de FranceConnect.

Mutualisé ou distribué ?

Dans le cas précédent nous avons vu qu’il est possible de monter un système de propagation d’évènements soit distribué au sein de chaque fournisseur de données soit mutualisé.

Ce n’est probablement pas le seul cas où le choix entre mutualisation d’une fonctionnalité ou duplication du code chez les fournisseurs de données/services se pose. La centralisation apporte le même niveau de service simultanément pour tous alors que la distribution est plus favorable à une évolution graduelle et une meilleure résilience. Si architecture centrée permet parfois de limiter le nombre de liens (clique 1to1 vs broadcast one2many), elle a plutôt tendance à en créer beaucoup plus lorsque l’on souhaite découpler contenant (gestion centralisée) et contenu (paire à paire).

La question reste ouverte.

Patterns d’API : gestion par lots

La gestion massive par batch constitue parfois source de rupture au sein d’un processus qui pourrait être continu. FranceConnect contribue à diriger les SI vers le temps réel. Si le système d’abonnement présenté ci-dessus va dans ce sens, il est malheureusement probable que certains cas des traitements de masse perdurent encore quelques temps (vérification périodique avant versement d’allocation/pension/bourse par exemple). Afin d’obtenir des performances acceptables pour de tels traitements via FranceConnect, les concepteurs d’API pourraient systématiquement mettre à disposition leurs données selon deux modes : unitaire (adapté à l’exécution d’un téléservice) et batch.

En mode batch :

  1. le fournisseur de service appel l’API avec un paramètre batch-mode. Le corps de la requête contient la liste des identités pivot à interroger et les jetons d’autorisation longue durée préalablement obtenus auprès des usagers. Afin de se prémunir d’un temps d’exécution trop long, le fournisseur de service fournie une URL à laquelle la réponse lui sera transmise
  2. le fournisseur de données ordonnance cette requête et l’insert dans la file de traitements à passer dans les prochaines heures
  3. lors du dépilage de la requête, le fournisseur de données vérifie en un seul appel auprès de FranceConnect la validité de tous jetons d’autorisation longue durée
  4. le fournisseur de données exécute le traitement pour les jetons valides et retourne le résultat à l’URL fournie par le fournisseur de données

Ce dispositif n’est pas coûteux et permettrait au citoyen d’obtenir de la visibilité sur les échanges réalisés par batch. Cependant, est-ce une bonne idée de conforter l’usage de traitements batch datés en adaptant l’architecture de FranceConnect ?

Le paiement facilité par PayFip

La DGFiP a présenté lors du hackathon de juin 2015 un projet appuyé sur FranceConnect nommé PayFip. Une collectivité qui souhaite que ses administrés puissent payer des services de régie en ligne (cantine, transport…) doit aujourd’hui passer par le TIPI, qui induit le paiement de frais bancaires important pour la collectivité. PayFip permet aux collectivités d’utiliser très facilement le prélèvement SEPA, complètement gratuit.

Cependant, il est actuellement impossible de délivrer le bien (ou le service) acheté aussitôt puisque la bonne exécution de la transaction ne peut être vérifiée que le lendemain matin, une fois le batch inter-bancaire de compensation passé. La Banque Centrale Européenne a annoncé fin novembre que les prélèvements SEPA pourront être exécutés en temps réel d’ici novembre 2017. Cela lève la dernière limitation de ce service par rapport à la carte bancaire : l’asynchronie du paiement.

Des fournisseurs d’Espace Numérique

mon.service public.fr propose depuis son ouverture un espace de stockage personnel, appelé à tord « coffre-fort numérique ». Ce service sera repris d’ici juillet 2016 au sein de service-public.fr.

D’après la page 27 du manifeste de la stratégie de l’État plateforme, l’opérateur de cet espace de stockage pourrait être choisi par chacun. Cela crée donc un rôle de fournisseur d’espace numérique à l’image des trois rôles existants (fournisseur de service, d’identité et de données). L’usager pourra choisir son fournisseur d’espace de stockage, mais ses documents seront disponibles au travers d’une API unifiée appelable, quelque soit le fournisseur de stockage, par les fournisseurs de service FranceConnect. L’application du principe d’auto-détermination informationnel en sera donc renforcée.

Rappelons toutefois que stocker des pièces scannées non structurées ne permet pas de traitement automatisé contrairement à la manipulation de données structurées. Ce service ne constitue donc qu’un facilitateur de transition en attendant la généralisation des API fournies par les fournisseurs de données FranceConnect.

De fausses bonnes idées ?

J’y un temps pensé quelques autres idées. Après (courte) réflexion, je ne suis pas certain que le jeu en vaille réellement la chandelle : le gain pour l’administration et l’usager parait a priori faible au regard de la charge et de la complexité induites. Comme pour ce qui précède, ce ne sont là que des suppositions. Quelques exemples :

  • permettre à l’usager de sélectionner un sous-ensemble des scopes demandés par le fournisseur des service. Les autres pièces seraient transmises par un autre canal
  • la signature systématique des flux structuré, notamment des fournisseurs de données privés, assurerait la non-répudiation des données fournies
  • permettre une interrogation booléenne des API les plus sensibles : « Aurélien Dumaine a-t-il un revenu fiscal supérieur à x€ ? » au lieu de « quel est le revenu fiscal d’Aurélien Dumaine ? »
  • si l’on souhaite pouvoir transposer sur papier des données structurées, on pourrait encourager les constructeur d’API à implémenter le code barre 2D-DOC. L’obtention du QRCode signé nécessiterait uniquement un paramètre dédié lors de l’appel de ladite API. Malgré ses avantages, 2D-DOC a-t-il vraiment un avenir aux cotés de FranceConnect ?

Les barbares attaquent la régulation

Les vidéos sectorielles de la série « Les barbares attaquent » (le consulting, la protection sociale, l’assurance etc) éclairent depuis deux ans ma compréhension de l’impact du numérique sur notre société et notre économie. Nicolas Colin et ses acolytes de The Familly y parlent de modèles économiques et sociaux, de données, d’API… sur fond de réactivité de l’État.

Voici un numéro sur la régulation beaucoup plus transversal puisqu’il concerne les régulateurs comme les entreprises régulées. Le think tank réaffirme que la régulation est nécessaire mais doit être repensée. La place du producteur-consommateur de l’économie collaborative et de la multitude (et non plus seulement du consommateur final ou de la PME) est une des questions posées aux régulateurs.

Au programme : 45 minutes d’exposé de Nicolas Colin et une heure d’échange avec le régulateur des télécom (ARCEP), le régulateur des transports ferroviaires et routiers(ARAFER), le responsable des règles prudentielles de la banque de et l’assurance (ACPR) et l’autorité de la concurrence britannique (CMA).

Mister Robot

Une de mes amies m’a récemment recommandé de regarder une nouvelle série : Mister Robot. Et je dois avouer que le script kiddie caché sous mon costume de consultant a bien pris son pied. Ce n’est pas la série du siècle mais enfin un divertissement abordant la sécurité informatique d’un angle un peu plus crédible ! Les acteurs sont assez bons et la BO est sympa.

Si vous avez quelques heures à perdre je vous conseille de regarder la première saison. Elle compte dix épisodes. Attention : si vous appréciez les deux premiers épisodes, regardez la saison entière. Les épisodes 5 à 7 sont plus lents mais le dénouement en vaut la chandelle.

 

Spoiler alert : ne pas lire ce qui suit si vous comptez regarder la première saison

 

Une de mes scène préférées (pilote, 17min30s) est la rencontre du méchant (Tyrell Wellick) avec l’anti-héro (Elliot) : Elliot commence par trasher l’incompétence technique du CTO d’EvilCorp, avant que Tyrell ne se lance dans un monologue trollesque sur Gnome et KDE… manquerait plus que d’accoler « GNU » à « Linux » pour que ce soit 100% jouissif. Je me suis cru un instant de retour au Millibar de l’UTC à troller avec un pote, même si ce n’est pas sur le choix de notre clickodrôme qu’on aimait le plus débattre.

C’est cool de voir une série où le méchant virus n’apparait pas en plein milieu de l’écran avec une tête de mort ou comme un hydre représenté en 3D façon Opération espadon. Vous pouvez faire des arrêts sur image pour lire le terminal de Elliot ou Tyrell : on y voit des sessions SSH tout ce qu’il y a de plus réaliste, du John the ripper, du Metasploit… le RaspberryPi est même au coeur de l’action.  Le plus intéressant est le rapport au social engeneering. Elliot ne pénètre pas brutalement tous les systèmes assis derrière son bureau mais a parfois besoin d’un vecteur humain : le maillon faible.

L’autre force de cette série est qu’elle elle pousse le spectateur à s’interroger sur l’impact de la technologie sur notre quotidien et de manière plus général sur le système dans lequel nous évoluons. Ce n’est pas du niveau de BlackMirror mais quand même ! Je me demande même si le nom choisi pour la multinationale, EvilCorp ne fait pas allusion au « Don’t be evil » de Sergueï Brin et Larry Page…

Puis quel plaisir de revisiter certaines références : la moquerie de Tron, l’allusion à Stargate et PulpFiction, les Anonymous, le magasin d’informatique des années 1990, même le patronyme du protagoniste rappelle Matrix. Attention toutefois : si traquer les références est divertissant, subir le copier/coller de pans entiers du scénario l’est beaucoup moins. Elliot nous rejoue le coup de Fight Club, Tyrell Wellick et sa femme rappellent dangereusement les héros de Hosue of cards, idem pour la voix off etc. Au final ce sont des monuments rejoués par de bons acteurs donc c’est supportable, mais ça reste du réchauffé.

Autre petit bémol : on évite malheureusement pas le cliché du jeune asocial portant un sweet à capuche… un jour peut-être.

Quoiqu’il en soit, j’ai hâte de voir la saison deux. Rendez-vous l’été prochain.