Mois : février 2016

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 ?