Étiquette : Systèmes d’information publics

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 ?
• L’internalisation du calcul des cotisations sociales
• Généraliser et unifier les dispositifs existants
• Urbaniser le SI en cohérence avec l’État plateforme
• Quelle valeur ? Quelles limites ?

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.

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. 😉

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 ?

Pour rappel, Louvois est le calculateur inter-armées initié dans le cadre du programme SOURCE qui visait à centraliser le calcul de la solde auparavant dévolu aux différents SIRH du ministère de la défense. Il devait constituer un point d’étape vers l’ONP. Le calculateur n’étant pas suffisamment éprouvé face à la complexité du système indemnitaire de solde, il génère de nombreuses erreurs de paiement depuis trois ans. Les trop versés continuent de s’accumuler en 2014 : 14 millions dans la Marine, 14 au service de santé des armées, plus une partie des 200 millions cumulés sur 2013/2014 pour l’armée de Terre.

Comme l’indique cet article, Accenture/CGI, Atos/Steria et Sopra viennent de réaliser un démonstration du calculateur qui remplacera l’outil actuel. Le dialogue compétitif de Louvois 2, débuté en début 2014, devrait aboutir à une mise en production courant 2015 pour une bascule complète au plus tôt en 2017. Entre les deux est sensée intervenir une période de paye en double… enfin il faudrait plutôt dire en triple car comparer les pré-liquidations de Louvois 2 à Louvois 1 ne sera pas suffisant. Il faudra faire une passe manuelle étant donné qu’il n’y aura pas de système de référence fiable.

Il faudra également composer avec la fusion concomitante des SI de chaque armée au travers du programme Source (Louvois n’est « que » le calculateur de solde).

Hasard du calendrier, cette démonstration intervient quelques jours après la bascule de la première vague de population dans le nouveau SIRH (SIRHEN) de l’éducation nationale. Après deux phases d’homologation par la DGFiP au printemps (pas totalement dépourvue d’erreurs), la subdivision de la première population migrée en deux sous-vagues et le report d’une montée de version au printemps prochain… l’année probatoire du programme (audit Neoxia/Deloitte) sera-t-elle validée ? SIRHEN sera-il le prochain programme jeté dans l’abîme ?

Et les transformations informatiques sur le plan RH ne sont pas terminées ! Au programme des prochaines années : la conversion iso-fonctionnelle de PAY (conversion semi-automatisée du code COBOL/Pacbase en Java avec BluAge), l’intégration des populations payées dans ETR (agents en poste à l’étranger) dans PAY, l’enrichissement des fichiers retour post-liquidation, la prise en compte du noyau RH-FPE v5, la création d’une base décisionnelle des trois fonctions publiques, le passage à la DSN fonction publique, l’alimentation du RGCU par le service des retraites de l’État…

MAJ 08/12/2014 : comme l’indique l’article Wikipedia relatif à Louvois, ce qui est appelé Louvois 1 ci-dessus est en fait la troisième version de la trajectoire Louvois. Plus de détails sur le programme.

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.

Dans la série « volet dépense de la loi de finances 2015 », l’assemblée a doublé le budget prévu pour la DISIC grâce à un amendement proposé au dernier moment par Bercy. Il s’agit de donner les moyens à la DISIC de piloter la transformation vers l’État plateforme passant notamment pas :

* l’orientation WS des nouveaux projets et l’encapsulation des SI legacy dans des API ouvertes qui permet notamment le lancement de « Marchés publics simplifiés », « Aides publiques simplifiées » (les deux premières mesures phares du programme « Dites-le nous une fois » du Choc de Simplification)

* la refonte, extension et décentralisation de la fédération d’identité de MonServicePublic avec la plateforme FranceConnect. Cela permettra aussi la traçabilité des échanges inter-administrations. Quarante ans plus tard, on peut y voir une preuve de bonne fois pour attendrir les détracteurs du projet SAFARI. On pourrait même imaginer offrir un mode dégradé à ceux qui souhaiteraient bloquer ces inter-échanges automatiques (peut-être usine à gaz mais avec des sujets politiques tout devient possible).

La DISIC a également compétence pour chapoter les projets SI importants au niveau de l’État ou de composantes de la sécurité sociale. Elle pilote le plan de raccordement au réseau interministériel de l’État ainsi que la mutualisation des infrastructures.

Chez Octo on doit être en train de sabrer le champagne : les cordons de la bourse s’ouvrent en grand pour eux !

Les pouvoirs publics font de la dématérialisation un des fers de lance de la modernisation du pays, et ils ont bien raison. En permettant aux citoyens, entreprises et agents publics de ne plus utiliser de papier, on peut potentiellement dégager du temps et de l’argent pour ceux qui ont le plus besoin d’attention.

La difficulté réside pour le moment dans la fourniture de pièces justificatives. Trois solutions s’offrent classiquement :

• transmettre les pièces justificatives au format papier en joignant un récépissé contenant le numéro de la procédure commencée en ligne
• demander à l’utilisateur scanner les pièces ou de fournir des documents déjà disponibles au format électronique (factures par exemple) et joindre au dossier en ligne
• mettre en place un système de transmission des pièces entre les différentes institutions produisant les pièces et l’administration destinatrice

Les deux premières solutions le document est non-structuré. Cela impose une validation manuelle des pièces par un agent ; il n’est donc pas question d’instruire automatiquement le dossier. La troisième solution impose de mettre en place des normes et des dispositifs lourds dans un nombre pré-défini d’institutions. D’autre part, dans un contexte de méfiance face aux interconnexions abusives de données des gouvernements, une part croissante de la population renoue avec les inquiétudes nées du projet Safari(provoquant la création de la CNIL) dans les années 1970.

Une alternative très intéressante réside dans la norme ouverte 2D-DOC (créée par la société AriadNEXT puis publiée sur le site de l’ANTS). L’idée consiste à inclure un code-barre 2D (au format data-matrix) sur les documents récapitulant les données du document et contenant le hash de la signature électronique de l’entité émettrice. Ainsi, l’on dispose d’une sécurisation électronique transposable sur support papier. Contrairement à des fichiers structurés signés électroniquement (factures EDIFACT ou ebXML par exmple), le contenu reste toujours « human readable ». Les personnes technophobes pourraient instruire leur dossier avec une facture d’électricité papier (pièce déjà scannée par les services courrier) et les plus technophiles directement avec une facture PDF de leur opérateur télécom par exemple. Cela permet donc de passer progressivement vers une instruction automatisée des dossiers administratifs dans les cas relativement standards. On limite ainsi tout risque d’amplification de la fracture générationnelle ou numérique. Pourrait-on imaginer à terme une instructions totalement automatique de 80% des dossiers de bourse CROUS par exemple ?

L’autre avantage indéniable est la non centralisation du processus. La mise en place de la transmission des actes d’états civil par COMEDEC est une démarche lourde : écrire une norme spécifique au besoin, créer une plateforme centrale, signer des conventions avec les mairies et les notaires… Ce genre de démarche se justifie probablement pour des choses hautement sensibles et régaliennes comme l’état civil mais parait difficilement généralisable pour des justificatifs de domicile par exemple. Là est toute la beauté de 2D-DOC. Le contexte politique est à un troisième acte de décentralisation. Les collectivités territoriales auront donc probablement de plus en plus de procédures propres. L’ouverture et la souplesse de 2D-DOC permet à toute structure de se lancer dans la dématérialisation à son rythme… tout en repoussant la menace de Big-brother. Les structures les plus innovantes montreront la voie aux autres. Rien n’empêche à posteriori de créer des plateforme type COMEDEC pour des besoins spécifiques ou des démarche très pénibles pour les citoyens. Entre temps, administrations (et entreprises !) et utilisateurs auront gagné du temps et de l’argent.

Techniquement deux petits détails me dérangent dans 2D-DOC :

• la taille d’un code barre étant limitées, les certificats électroniques (la clé publique permettant de vérifier l’authenticité d’une signature) sont déportés sur internet. Cependant, ceux-ci semblent actuellement disponible dans un répertoire centralisé. La résilience est donc limitée.
• la liste des documents « encodables » est ancrée en dur dans la norme. Ajouter un nouveau type de document (attestation d’assurance responsabilité civile par exemple) nécessite donc de réunir un nouveau comité de normalisation et de repasser toutes les étapes de validation. Un champ permettant d’indiquer l’URL d’extensions pourrait assouplir la norme.

Avec le déploiement de projets comme COMEDEC, ACTES, HELIOS ou CASSIOPEE, les agents publics disposeront tous bientôt d’une carte professionnelle contenant un certificat 3 étoiles conforme au RGS permettant de signer électroniquement un document avec une valeur légale identique à la signature manuscrite. Les faibles pré-requis d’infrastructure pour généraliser 2D-DOC sont donc réunis.

Outre l’ajout d’un champ contenant une URL d’extension de la norme, l’enrichissement de celle-ci devrait rapidement porter sur les documents suivants, couramment demandés :

• certificats de scolarité
• attestation d’assurance (au moins habitation, responsabilité civile et auto/moto)
• certificats médicaux d’aptitude
• prescriptions médicales (doublon avec le projet de dématérialisation des ordonnances de l’ordre des pharmaciens ?)

Ajouter le support de 2D-DOC aux factures acceptées sur Chorus-factures ferait également sens.

La dernière chose pour permettre aux collectivités de commencer à utiliser 2D-DOC serait de modifier par la voie règlementaire (ordonnance, décret…) ou à défaut législative(peut-être dans le PLF 2015) les codes régissant les grands secteurs règlementés produisant ces pièces justificatives (compagnies d’assurance, de télécom, distributeurs d’électricité ou de gaz, établissement scolaire…) pour les obliger à inclure 2D-DOC dans leur chaîne d’éditique. Les modifications étant raisonnables, on pourrait imaginer une entrée en vigueur très rapide à l’échelle de l’administration, d’ici 12 ou 24 mois. Ensuite, à chacun d’utiliser ou non la capacité de vérification automatique de ces documents dans ce nouveau cadre d’innovation ouverte.

Le gouvernement, sur conseil de la DISIC, vient d’acter l' »abandon » du projet d’opérateur national de paie (plus de détails ici).

Actuellement les fonctionnaires sont payés par transfert de fichiers de paie entre les ministères (et services décentralisés) et les SLR (services liaisons-rémunérations) locaux de la DGFiP. À la DGFiP c’est l’application PAY qui assure depuis 40 ans le traitement de ces fichiers et l’envoi des ordres de virement. Les technologies supportant PAY n’étant plus maintenues et l’architecture de celle-ci étant obsolète, ONP ou pas il va bien falloir la remplacer.

Quelques caractéristiques un peu particulières du système actuel auxquelles devait remédier le SI de l’ONP :

• la paye du mois précédent est prise par défaut. Ne pas apparaitre dans le fichier de mouvements équivaut à être payés comme la paie précédente
• les fichiers ministériels envoyés avant le 20 du mois n correspondent à la paie qui sera versée à la fin du mois n+1
• le ministère de la fonction publique ne dispose d’aucun info-centre précis sur sa masse salariale (concernant les trois fonctions publiques)

Outre le remplacement de cette application cruciale en fin de vie,  le projet ONP ciblait de nombreuses avancées. Il prévoyait une normalisation des processus de paie sans pour autant contraindre de trop les ministères : ceux-ci concevait un SIRH indépendant mais fortement interfacé (au travers du noyau FPE). Ainsi lorsque les SIRH actuels transferts des sommes à PAY, seuls des évènements de gestion (naissance d’un enfant, changement d’échelon…) auraient été transférés entre le SIRH est l’ONP. D’autre part, et au moins aussi important, l’organisation des services de paies évoluait en voyant la création de services spécialisés (un peu comme les services facturiers mis en place dans la foulée de Chorus) : les PESE (pôles d’expertise et de services). Il était donc prévu une mise en place de « bonnes pratiques » au niveau organisationnel ; ce qui fait le plus souvent défaut aux projets informatiques (comme Louvois et le programme SOURCE).

Si l’arrêt de ce chantier peut nous éviter une dérive budgétaire énorme ou des problèmes de rémunération comme Louvois pourquoi pas. Cependant il est à nuancer car les paies des militaires paraissent bien plus complexes que celles des fonctionnaires non-militaires. D’autre part, les statistiques officielles du mastodonte Chorus nous indiquent si le dépassement initial du budget a été conséquent, les coûts de maintenance annuels sont en dessous des prévisions. D’un point de vu budgétaire maintenir PAY en fonctionnement est également coûteux voire techniquement dangereux.

D’autre part, des dizaines de projets gravitent autour du raccordement à l’ONP(via l’intégration du référentiel de paie de l’État, le noyau FPE). Les crédits déjà consommés purement et simplement jetés à la poubelle sont donc plus important qu’annoncés. Dans le contexte politique actuel, on peut également douter de l’opportunisme de l’exécutif face à l’engagement de trouver 50 milliards d’économies dans les prochaines années… économies qui devaient être au départ structurelles et non conjoncturelles ou contre l’investissement.

Va-t-on jeter le bébé avec l’eau du bain : la réorganisation des services, l’urbanisation des SI ministériels (et des opérateurs prévus en paye à façon) ?

Louvois, SI paye, la prochaine victime ne serait-elle pas SIRHEN ? L’audit du cabinet Neoxia/Deloitte met en effet à l’épreuve ce programme du secrétariat général de l’éducation (MEN, MESR…) sur 2014. Les projets RH semblent confrontés à la complexité incommensurable des systèmes de paie des agents publics. Une réforme structurelle profonde de la fonction publique (la fusion en corps interministériels par exemple) semble un prérequis au prochain changement de système ; dans une vingtaine d’années. À noter que la simplification du système de primes et leur moindre recourt serait aussi bénéfique pour rendre comparables les systèmes de retraite privé/public et réformer de manière égalitaire et juste.

Je suis curieux de voir comment va évoluer la situation car quoiqu’il en soit… PAY doit mourir.

MAJ : une version isofonctionnelle de PAY en Java serait à priori re-développée en interne à la DGFiP (détails).

MAJ du 7 avril 2014 : quelques précisions sur les points développé si dessus début mars dans l’article de silicon.fr du 4 avril 2014

MAJ du 24 avril : le rapport du directeur de la DISIC ayant mené à la fin du programme est disponible Rapport-jmarzin-pdf

MAJ du 22 mai : un nouveau décompte incluant les SIRH ministériels. Il est malgré tout impossible de connaître le surcoût induit par l’intégration du noyau FPE lors de leur refonte, nécessaire en soit. Article du silicon.fr du 21 mai 2014