La modernisation du système d’information de l’Etat au service de la simplification des usages

Cet article est un compte-rendu de la conférence organisée le 14 novembre 2014 à la Cité de l’innovation publique (au 104) par la DISIC. Attention, j’ai parfois complété le discours par des informations issues d’autres sources ou des réflexions personnelles (FranceConnect en mode dégradé par exemple).

Je suis enthousiaste de la vision portée par la DISIC qui reprend un certain nombre d’idées que j’avais formulées de mon coté dans mes précédents travaux. Les deux plus importantes sont l’exposition systématique par API (seconde partie de mon rapport sur l’innovation et les politiques publiques) et la traçabilité des échanges entre SI publics ou le privacy by design (partie 3.3 de mon mémoire sur l’Évolution d’internet : confiance, identités, vie privée, statut des données et modèles économiques).

Présentation de la DISIC par Jacques Marzin

La DISIC (Direction interministérielle des systèmes d’information de l ‘État) est une structure légère d’une quarantaine de personne rattachée au SGMAP (secrétariat général à la modernisation de l’action publique) auprès du Premier Ministre.

Elle a pour mission de maîtriser la complexité organisationnelle et technique du SI de l’État en vue de rationnaliser ses composantes et d’aider les ministères à sécuriser les opérations de refonte. L’objectif en toile de fond est d’améliorer la relation entre administration et administrés (et notamment l’avènement du cross-canal). Bien que la DISIC n’ait statutairement à charge que le SI de l’État, elle est amenée à travailler avec les trois fonctions publiques, les OPS et autres opérateurs publics ou semi-publics. Il y a unicité juridique du SI de l’État depuis aout 2014.

Concrètement, la DISIC a lancé plusieurs chantiers :

  • Réunion mensuelle des DSI des ministères afin de suivre leurs projets respectifs et de visualiser les interactions entre les différents projets.
  • La mise à jour régulière (en théorie) des référentiels généraux d’accessibilité, de sécurité et d’interopérabilité qui s’imposent à toute structure publique
  • La construction du RIE (réseau interministériel de l’État) et le raccordement des administrations déconcentrées à celui-ci
  • Établir le plan d’occupation des sols du SI de l’État et opérer une rationalisation des infrastructures. L’objectif affiché est de passer de 120 à 20 datacenters d’ici dix ans. Il s’agit notamment de faire monter en puissance la virtualisation afin de construire un cloud pour l’administration.
  • Mutualiser les briques transversales telles que les outils collaboratifs (messagerie et agenda : projet Melanie2) : un ministère porte le service pour les autres. Le préalable est la création d’annuaires communs et de SSO.
  • Promouvoir l’utilisation du logiciel libre que ce soit coté client (Firefox, Thunderbird, LibreOffice…) ou serveur (PostgreSQL, Linux, Tomcat…). Les développements engagés sur fonds publics ont vocation à être reversés aux communautés. Une fraction des coûts de licences économisés devait également être reversée. Coté client, cela passe par une réduction des adhérences des différentes applications métiers au système d’exploitation et aux suites bureautiques par la généralisation des clients n-tiers de type web.
  • Deux projets concrets pour le grand public : Marchés publics simplifiés et Mes aides simplifiées dans le cadre du choc de simplification

Jacques Marzin a insisté sur le fait que la DISIC n’a pas vocation à se substituer aux DSI ministérielles mais de dégager des synergies et d’apporter une cohérence et une vision d’ensemble sur le long terme.

La richesse de l’État français contrairement à d’autres (UK ?) est d’avoir conservé ses 18000 informaticiens. Ceux-ci sont les gardiens de la donnée et des processus de l’État. Il se révèle cependant complexe de trouver une culture commune et de remettre en cause l’indépendance totale des DSI ministérielles.

L’enjeu est de passer d’une logique où il faut « apporter la preuve que la mutualisation est économique et bonne » à une logique où « l’on doit démonter que la mutualisation est anti-économique pour ne pas la faire ». De même, la DISIC souhaite généraliser le Agile first. Outre les réticences culturelles, la difficulté principale de la DISC est la continuité managériale dans le temps : un projet n’est viable que si sa gouvernance reste stable.

 

Présentation des SIDSIC par Eddy Babel

Eddy Babel est membre du SIDSIC (Service interministériel départemental des systèmes d’information et de communication) du Calvados. Son but est de décliner sur le terrain les projets portés par la DISIC.

Eddy Babel a présenté la raison d’être du RIE dans son département ainsi que les étapes de raccordement.

 

État plateforme et identité numérique par Guillaume Blot

Le concept d’État plateforme a été introduit par Nicolas Colin et et Henri Verdier (aujourd’hui CDO de l’État) dans leur livre l’Âge de la multitude où ils le décrivent l’appropriation par la puissance publique de la logique d’API ouvertes mise en œuvre par les géants du web et notamment Amazon. La DISIC considère la donnée publique comme un bien commun.

L’objectif est de concevoir les services publics autours des besoins et des situations des « clients » usagers (cross-canal). Favoriser l’émergence de véritables écosystèmes ouverts à tous les acteurs (publics, associatifs ou privés) pour aller vers un État collaboratif, préalable essentiel à une service public sans couture. Il s’agit également de co-constuire cet État plateforme en mettant en œuvre l’agilité typique des start-ups.

Un pré-requis à l’État plateforme est la capacité d’identifier/authentifier de manière univoque un citoyen et s’interconnecter avec des SI hétérogènes et âgés sans attendre une hypothétique CNIE. La DISIC a donc réuni les DSI des principaux acteurs publics afin de traiter cette question. Certains voulaient perdre 18 mois pour créer un standard franco-français alors que d’autres préféraient utiliser les standards  internationaux existants. Il a été décidé d’utiliser les standards du web tels que JSON, XML, REST/http. Cela permettra une intégration rapide (ordre d’idée : deux heures de développement pour intégrer FacebookConnect).

Cette identification permet a posteriori l’échange de données entre administrations. Ces travaux ont donné lieu à une spécification : FranceConnect.

FranceConnect n’est pas une identité numérique. C’est une architecture permettant de fédérer les identités entre les fournisseurs de services et les fournisseurs d’identité (extension de la spécification LibertyAlliance adaptée par l’ADAE en 2004, socle de mon.service-public.fr NDLR). À ces acteurs s’ajoutent des « hubs » visant à contextualiser l’information transmise par un fournisseur de données à un fournisseur de service. Contextualiser de l’information signifie délivrer au demandeur uniquement l’information dont il a besoin pour traiter son dossier.

Exemple fictif : un père de famille souhaite inscrire son fils en crèche. Il se rend sur le site web de sa mairie et peut se connecter avec n’importe lequel des fournisseurs d’identités implémentant FranceConnect fournissant un niveau d’identification suffisant (faible, moyen ou élevé) comme par exemple son compte CAF ou son compte fiscal. Il peut ensuite remplir sa demande de crèche en ligne et communiquer son numéro fiscal. La mairie pourra alors demander au hub APIkids le revenu du couple nécessaire au traitement de la demande.

Depuis les détournements des fichiers nominatifs sous l’occupation, les français sont attachés à l’indépendance des bases de données administratives. La France a mis en place plusieurs outils institutionnels limitant de telles interconnexions (création de la CNIL quatre ans après le scandale SAFARI) et doit régulièrement revoir ses dispositions d’échange de données (couplage fort des empreintes retoqué par le conseil constitutionnel lors de la création de la CNIE, suppression de champs de BaseElèves…). La réussite de ce projet d’État plateforme est donc politiquement conditionnée aux gages de bonnes fois apportés par cette nouvelle architecture conçue autour du Privacy by design. FranceConnect doit permettre l’échange fluide et dématérialisé des informations dont les organismes ont besoin pour mener à bien leur mission sans jamais leur en fournir d’avantage que ce qu’ils ont actuellement avec un traitement des pièces justificatives papier (ou non structurées).

Le rôle du « hub » est justement de transmettre uniquement les éléments nécessaires au traitement de la demande. Dans notre exemple, la mairie n’aura accès qu’au quotient familial et non plus l’intégralité de l’avis d’imposition. On pourrait également envisager que le hub consolide les données fournies par plusieurs organismes et ne renvoie que « oui » ou « non » à une question type.

FranceConnect renforcera également le droit d’accès à l’information établi par la loi de janvier 1978 puisque toutes les informations échangées seront tracées, traces facilement accessibles au citoyen. D’un point de vu fonctionnel, le citoyen pourra modifier, via une API les dites informations s’il constate qu’elles ne sont pas à jour.

La beauté de cette architecture est donc d’industrialiser les échanges tout en renforçant la qualité des données et fournissant un cadre structurant qui protège le citoyen et lui donne un gage de traçabilité. On pourrait aussi imaginer que les citoyens puissent soit bloquer (opt-out) ces inter-échanges, soit valider manuellement chaque échange ou bien les ralentir automatiquement (accord pour transmission sans action sous deux jours). Dans le premier cas, le citoyen devrait alors fournir la pièce justificative manquante par un mode dégradé et supporter le délai et la complexité associés. Ce mode dégradé pourrait notamment passer par le téléchargement de la pièce justificative au format PDF avec un tag 2D-DOC, reconnue automatiquement par le SI destinataire.

Une question demeure : aurons-nous un identifiant unique ? Si je m’identifie sur un site avec mon compte CAF, puis la fois suivante avec mon compte fiscal, comment le site pourra-t-il me reconnaitre ?

Dans une logique d’ouverture et de réutilisation, la DISIC favorise la publication de code source sur des forges ouvertes telle que celle de l’ADULLACT ou JoinUp (portée par l’UE). Publier sous licence libre constitue un changement conséquent pour les informaticiens de l’État.

Calendrier prévisionnel :

  • Publication de la spécification et appel à commentaires mi-novembre
  • Première implémentation au printemps 2015
  • Migration de mon.service-public.fr fin 2015
  • Intégration de la DGFiP pour la déclaration d’IR 2016

Henri Verdier sera à l’écoute des partenaires pour déterminer les données qu’ils peuvent ou non exposer et comment les exposer.

 

Questions

Aujourd’hui l’utilisation du NIR est très encadré, comment la CNAV être un fournisseur d’identité puisque le login est le NIR ?

Lorsque l’administré sélectionnera l’identification CNAV depuis le site de sa mairie, il sera rediriger vers la page d’identification de la CNAV qui renverra un token d’authentification (sans aucune sémantique), le niveau d’authentification au standard e-IDAS (faible, moyen, fort) et des informations de base sur l’individu (nom et prénom). Le NIR ne sera jamais transmis.

Qui de l’interopérabilité avec les autres pays européens ?

FranceConnect sera le point d’entrée de la fédération d’identité européenne e-DAS coté français. Les fournisseurs d’identité devront être conventionnés avec FranceConnect mais les consommateurs d’identités pourront facilement intégrer FranceConnect. On envisage de promouvoir la plateforme chez des e-commerçants ou des banques françaises. Ces organismes commerciaux n’auront aucun accès aux données privées des citoyens.

Un journaliste : Qui est le porteur de projet, de la gouvernance de FranceConnect ?

La DISIC.

Aurélien Dumaine : Vous parliez de mutualisation des infrastructures des ministères. Ne pourrait-on pas utiliser FranceConnect pour authentifier les agents aux backend des SI ministériels ? La personne physique étant la même, il pourrait y avoir une continuité du vecteur d’identification.

L’architecture pourra être instanciée pour permettre l’authentification des agents aux backends métier mais le vecteur d’authentification ne sera pas le même. Nous souhaitons conserver des fournisseurs d’identités professionnelles distincts.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *