ACHAT INNOVANT MON DASHBOARD ENTREPRISEExpression des besoins

0) Présentation synthétique du service “Mon Dashboard Entreprise”1) Contexte, enjeux, historique

ContexteEnjeuxHistorique du projet

2) Pourquoi un achat innovant pour le projet Mon Dashboard Entreprise3) Environnement technologique

ExistantContexte technologiqueArchitecture générale du projet

Client et interface utilisateurIntégration des services et donnéesFranceConnect et fournisseurs d’identitésEtat plateforme : Fournisseurs de services et fournisseurs de donnéesCouche d’interconnexion des donnéesServices API partenairesCommun des données :

Résiliance architecturale du projet4) Existant et orientations techniques

Description de l’existantOutils, langages de programmation, format de donnée

5) Structure par couches servicielles APIsées, rôle de l’AMOA, des répondants à l’ achat innovant et la communauté d’innovation ouverte.

Structure par couches servicielles APIséesRôle de l’AMOARôle des répondants au marchéRôle de la communauté d’innovation ouverte.

0) Présentation synthétique du service “Mon Dashboard Entreprise”

Le projet “Mon Dashboard entreprise” se positionne sur la simplification de la relation entreprises-administration et la fourniture d’informations personnalisées à chaque entreprise.Le projet se décline en 3 groupes de fonctionnalités majeurs : 1- Vision 360 des données détenues par l'administration : l'entrepreneur dispose de toutes les informations que détient l'administration et peut décider de les partager à des tiers (autres

1

administrations, services privés partenaires du Dashboard. Ce service permet de constituer le “profil de données” de l’entreprise.

2- Services personnalisés de l'administration : ensemble des informations, services, outils mis à disposition par l'administration pour la simplification de la relation entreprise – administration. Ces éléments sont personnalisés en fonction du “profil de données” de l’entreprise. Ainsi un boulanger n’aura pas les mêmes informations affichées qu’une entreprise du BTP

3- Services partenaires : ensemble des informations, services, outils personnalisés mis à disposition sous un modèle de type "freemium" par les partenaires privés pour les utilisateurs du Dashboard via un partage sécurisé respecteux de la vie privée de certaines informations du "profil de données entreprise”.

Le schéma suivant présente les différents services mis en place dans le cadre du prototype actuel du dashboard et leur regroupement en groupes de fonctionnalités.

Le schéma suivant fait le lien entre les groupes de fonctionnalité et les différentes couches de données du commun des données dashboard (détaillé plus loin).

2

Le paragraphe suivant présente le contexte dans lequel ce projet s’inscrit ainsi que les enjeux afférents et l’historique de sa génèse.

1) Contexte, enjeux, historique

Contexte

L’Etat cherche à promouvoir l’innovation dans le développement du numérique.La Dila veut se positionner sur cet objectif et tente de développer des outils plus adaptés à la politique d’ouverture des données ainsi qu’à la création de nouveaux services plus simples d’utilisation et donc plus adaptés aux besoins des entreprises. Ces initiatives s’inscrivent dans le cadre de la stratégie de L’Etat plateforme, de l’ouverture des données publiques, et de la mise en cohérence de l’information administrative aux entreprises.

Plus de 847 sites d’information publique aux entreprises ont été recensés par le SGMAP. Des focus groupes ont permis d’identifier 3 besoins complémentaires pour répondre à cette complexité :

- gain de temps dans l’accès- confiance dans l’identification des sites d’information- lisibilité de l’information et des démarches

3

Enjeux

Le projet Mon Dashboard Entreprise vise à développer un service web pour la simplification, la performance, et l’efficience administrative des entreprises. L’application fournira des informations personnalisées aux entreprises à partir de données ouvertes et enrichies, en fonction de leur profil et de leur activité, sur les formalités et réglementations liées à l’emploi, aux ressources humaines, à la fiscalité, aux aides, aux marchés publics… Le service s’adresse en priorité aux TPE/PMEL'application reposera sur et participera à la création et à l’alimentation d’un commun des données entreprises (programme "open entreprise") qui regroupera toutes les données sur et pour les entreprises issues de l'administration et des partenaires privés ou associatifs.Par son infrastructure centrée sur les communs et sa gouvernance ouverte, le projet dashboard entreprise souhaite mettre en place un espace de collaboration et d’innovation public / privé / société civile novateur où chaque acteur participe à l’amélioration du service rendu aux entreprises et à la fourniture de données et d’algorithmes en open-data et open-source pour la communauté d’innovateurs publiques et privés.D’autre part, ce projet s’inscrit pleinement dans le cadre architectural de l’Etat plateforme et souhaite y contribuer par la mise en place de nouveaux fournisseurs de données ou de service mais aussi en réutilisant et challengeant les initiatives actuellement en cours au sein des services SI de l’état (FranceConnect, APIEntreprise,...)

Historique du projet

4

Entre juillet 2014 et septembre 2015, la direction de l’information légale et administrative (DILA), services du Premier ministre, a procédé à l’ouverture de son patrimoine informationnel. Afin de compenser la perte de recette liée à l’abandon des redevances de réutilisation de ses données publiques, la DILA a développé une stratégie d’innovation ouverte visant à accompagner et à encourager la réutilisation de ses données publiques.

Cette démarche de gouvernement ouvert a contribué à l’émergence d’une communauté de l’innovation OPEN LAW * le DROIT OUVERT.

Les différents programmes d’innovation collaborative portés par cette communauté de l’innovation numérique juridique ont permis à l’administration d’expérimenter la co-conception du service public numérique avec les utilisateurs finaux

Au cours d’un premier programme d’innovation ouverte qui s’est déroulé du 30 octobre 2014 au 17 décembre 2014, la DILA s’est attachée à valoriser la récente ouverture des données juridiques françaises et à encourager leur réutilisation, comme le rappelait M. Bertrand Munch, directeur de la DILA, dans sa préface de présentation du premier programme d’innovation dédié à l’accès au droit ( septembre à décembre 2014) :“La DILA est dans un processus volontariste d’ouverture des données publiques juridiques. Son enjeu principal est d'encourager l'émergence d'un écosystème autour de ces données, en favorisant la création de nouveaux produits et services innovants entre les acteurs de l'open data et les professionnels publics et privés de l'édition juridique.

5

Dans ce contexte, nous souhaiterions profiter de ces initiatives pour créer à moindre coût de nouveaux services de diffusion de données juridiques performantes, utiles et accessibles à tous, en nous inscrivant durablement dans les courants prometteurs de la démocratie numérique et d’un ''gouvernement ouvert''. Pour le moment, cela constitue une expérimentation. Nous en ferons un premier bilan en avril prochain.’’

Pour mettre en oeuvre ce programme et définir un cadre juridique à ce partenariat d’innovation ouverte, la DILA a créé un prix ‘’DILA le Droit Ouvert’’ 1. C’est dans ce cadre que le projet ‘’Mon Dashboard Entreprise’’ a été déposé et présenté à la DILA en décembre 2014.

Il n’était pas a priori envisageable de prolonger un programme d’innovation collaborative entre le secteur public et privé à partir des données publiques ouvertes par la DILA pour permettre une industrialisation des innovations dans le service public numérique.

Pour définir les projets issus du concours de l’innovation de la DILA susceptible d’être repris dans le cadre de dépôt de dossier à l’appel à projets ‘’transition numérique de l’Etat’’ du programme d’investissement d’avenir2, l’équipe d’innovation de la DILA a ainsi organisé début 2015 plusieurs evenements pour mettre en relation les porteurs de projets, des utilisateurs des services publics numériques et des agents publics souhaitant profiter de ce premier appel à projet pour développer l’innovation publique3.C’est suite à ces evènements que le présent projet a été retenu et déposé en mars à l’appel à projet du programme d’investissement d’avenir. Sur le fondement juridique de l’article 3-6° du code des marchés publics, des conventions de R&D ont été conclues par les entités publiques porteuses de ce projet au PIA avec la start-up OOFFEE qui en était à l’origine.Ce cadre partenarial a ainsi effectivement permis de poursuivre la dynamique et d’inclure le porteur de ce projet d’innovation au consortium des co-déposants du projet Mon Dashboard Entreprise au PIA ( juridiquement, ces conventions de R&D constituaient des ‘’apports’’ des administrations porteuses).En juin 2015, le projet déposé a été lauréat de ce premier appel à projet du PIA ‘’transition numérique de l’Etat’’.

La convention de R&D préparatoire au présent partenariat d’innovation a permis de lancer l’expérimentation du projet “Mon Dashboard Entreprise”, visant à fournir aux entreprises une information personnalisée en fonction de leur secteur d’activité (code NAF), de leur localisation, de leur taille ou de leur SIRET. Ces premiers travaux ont porté sur:

● un premier recensement des données qui pourraient être utilisées pour Mon Dashboard Entreprise

● la mise en place d’une infrastructure pour accueillir ces données● une réflexion sur l’alignement des référentiels afin de fournir une information

personnalisée en fonction du secteur d’activité, de la localisation, de la taille ou du SIRET des entreprises

1 Arrêté du 31 octobre 2014 relatif à la création et à la dotation du prix de la direction de l'information légale et administrative « DILA - Le droit ouvert » ELI: http://www.legifrance.gouv.fr/eli/arrete/2014/10/31/PRMX1425905A/jo/texte 2 Convention du 12 décembre 2014 entre l'Etat et la Caisse des dépôts et consignations relative au programme d'investissement d'avenir (action : « Transition numérique de l'Etat et modernisation de l'action publique ») http://www.legifrance.gouv.fr/eli/convention/2014/12/12/PRMI1424723X/jo/texte 3 Convention du 12 décembre 2014 entre l'Etat et la Caisse des dépôts et consignations relative au programme d'investissement d'avenir (action : « Transition numérique de l'Etat et modernisation de l'action publique ») http://www.legifrance.gouv.fr/eli/convention/2014/12/12/PRMI1424723X/jo/texte

6

● un premier prototype de recherche et développement afin de préfigurer de nouveaux produits et services innovants

Dans le cadre de cette convention de R&D, à partir de septembre 2015, le projet a fait l’objet de nouveaux développements dans le cadre d’un programme d’innovation OPEN LAW EUROPA ouverte porté par l’équipe d’innovation de la DILA.

L’objectif de ce programme était notamment de s’appuyer sur les travaux récents lancés par l’Office des Publications de l’Union Européenne, visant à définir deux standards du web sémantique européen : ELI pour l’identification des ressources législatives et ECLI pour l’identification de la jurisprudence

A partir de l’exploitation de ces identifiants, l’objectif était de développer l’innovation collaborative pour créer des démonstrateurs de services innovants visant à stimuler l’interopérabilité des droits européens et nationaux.

L’objectif était également de préparer le présent partenariat d’innovation, notamment pour constituer un socle technique à mutualiser entre les futurs partenaires et développer l’interopérabilité des données publiques ouvertes.

Par rapport au présent partenariat d’innovation, cette phase a permis : ● de développer concrètement le ‘’communs des données Dashboard’’ ● une première version de l’infrastructure technique, logicielle et servicielle nécessaire

pour supporter ces communs ( à partir de l’infrastructure matérielle Teralab apportée par le partenaire Institut des Mines Telecom)

● de tester les futures modalités de gouvernance ouverte du projet et d’expérimenter le concept des partenariats publics-communs4 appliqué aux ‘’biens communs numériques’’ dans le domaine de l’information juridique

● d’évaluer la faisabilité de consommation de ces identifiants dans le cadre du projet et de tester la possibilité d’étendre le périmètre d’exploitation des données au niveau européen

Le programme d’innovation ouverte et collaborative OPEN LAW EUROPA a permis le développement de cinq ressources communes consubstantielles aux six projets d’innovation.

Le programme Open Law Europa s’est achevé le 17 décembre avec la livraison des ‘’communs numériques’’ sur www.lab.openlaw.fr Ces communs numériques constituent le socle technique et informationnel ouvert et collaboratif pour le développement du présent partenariat d’innovation.

Dans le cadre du programme OPEN LAW EUROPA, 6 projets ont été développés à partir de ces ‘’communs numériques’’ et présentés publiquement le 17 décembre 2015 à la DILA. Parmi ces projets, deux impliquent directement les porteurs du projet Mon Dashboard Entreprise:

4 http://scinfolex.com/2016/01/25/open-law-un-modele-exemplaire-de-partenariat-public-prive-communs/

7

- la DILA s’est associée au projet RIPSA. Il a permis de développer un prototype expérimental offrant un filtrage personnalisée des procédures ‘’silence vaut accord’’ ( exemple: fournir à un un boulanger une information juridique personnalisée sur les SVA différente de celle à fournir à l’entrepreneur du BTP). Ce service se base sur l’alignement des référentiels et le crowdsourcing de données expérimentés dans le cadre du programme

- Pôle Emploi s’est associé au projet KALI. Il a permis d’expérimenter un service de fourniture d’information personnalisée et d’aide à la décision en matière de convention collective applicable à un professionnel du cinéma et/ ou de l’informatique. Ce service se base sur l’analyse fine et sémantique des textes constituant les textes des conventions expérimentées.

Suite aux résultats ce ce projet et à leurs présentation à la Chambre de COmmerce et d’Industrie de l’Ile de France, celle-ci a décidé de rejoindre le projet et de s’associer au consortium déjà en place.

Le présent partenariat d’innovation s’inscrit donc dans la continuité des expérimentations menées sur le projet tout au long de l’année 2015. Il vise à poursuivre la recherche et le développement amorcés précédemment, par l’expérimentation de services innovants sous la forme de démonstrateurs et le cas échéant, à industrialiser le service.

Il vise à constituer un consortium privé pour mettre en place un dispositif de co-création publique-privée et une gouvernance de projet à partir du socle commun ouvert et intéropérable développé au cours de l’année 2015.

2) Pourquoi un achat innovant pour le projet Mon Dashboard EntrepriseAfin de passer d’une convention de R&D à une industrialisation par le secteur public, le dossier ‘’Mon Dashboard Entreprise’’, lauréat du PIA, prévoit l’utilisation de la procédure concurentielle avec négociation ( art 25-II-2° du décret 2016-360 du 25.03.2016). L’utilisation de cette nouvelle procédure est prévue ''lorsque le besoin consiste en une solution innovante''.

Selon cet article du Code des marchés publics, “Sont innovants les travaux, fournitures ou services nouveaux ou sensiblement améliorés. Le caractère innovant peut consister dans la mise en œuvre de nouveaux procédés de production ou de construction, d'une nouvelle méthode de commercialisation ou d'une nouvelle méthode organisationnelle dans les pratiques, l'organisation du lieu de travail ou les relations extérieures de l'entreprise”.

En partenariat avec ses partenaires publics, il vise à confier à des partenaires privés la conduite du projet.

Si le concept est prouvé et que le service proposé au terme de l’expérimentation ( phase d’amorçage) répond aux attentes des utilisateurs cibles, les différentes fonctionnalités développées et décrites ci-dessous feront l’objet d’une phase d’industrialisation par l’un des partenaires publics du projet.

8

3) Environnement technologique

Existant

Dans le cadre du programme OpenLaw Europa, une première version de l’infrastructure cible des communs du Dashboard Entreprise a été mise en place.Les services utilisateurs issus de cette infrastructure sont pour l’essentiel disponible sur la page du lab d’Open Law : http://lab.openlaw.fr

Cette première version repose sur l’infrastructure matérielle big-data fournie par Teralab (Mines Télécom) et est composée de différentes machines virtuelles contenant différents services fournis par des logiciels Open-source et des logiciels installés par les partenaires du programme OpenLaw Europa.

Parmi les services et technologies principales installés sur la plateforme, on peut citer :

● Un triplestore Blazegraph qui contient toutes les données ELI/ECLI de Légifrance au format RDF

● La solution WebLab de Airbus Defence and Space qui offre des fonctionnalités avancées dans le traitement de l’information

● Les solutions DataLift et Wikidata qui permettent de transformer des données en RDF et de saisir collaborativement des données structurées

● La solution OpenCollector de Doctrine - basée sur PMB - qui collecte et donne accès à un catalogue de doctrine grâce au protocole OAI

● Le produit RIPSA qui permet de faire de l’annotation collaborative des procédures dites de Silence Vaut Accord et de faire une présentation et des recherches intelligente à l’intérieur de ces procédures

La solution Discourse a aussi été installée afin de permettre à la communauté de se structurer et d’échanger sur les différents sujets liés à OpenLaw et au Dashboard tout en conservant et partageant les connaissances acquises.Un autre service annexe pour le dépôt des code sources open-source de la communauté a été mis en place sur la plateforme Git de Framasoft : https://git.framasoft.org/groups/OpenLawFr

Cette première base est vouée à évoluer et s’améliorer dans le cadre de cet achat innovant tout en gardant son caractère ouvert et collaboratif pour profiter de la communauté et des usages en cours

Contexte technologique

Ce projet s’inscrit dans une démarche de co-innovation publique, privée, société civile dans le contexte d’un projet d’innovation porté par la DILA dans le cadre du programme OPEN LAW EUROPA et du Partenariat pour le Gouvernement Ouvert. Après la constitution d’un consortium public lors du dépôt de ce projet au programme d’investissement d’avenir et son développement en mode ouvert dans le cadre d’OPEN LAW EUROPA, la DILA et ses partenaires souhaitent à

9

présent constituer un consortium privé pour poursuivre le projet dans le cadre d’un achat innovant.Plus largement, ce projet s’inscrit dans le cadre architectural de l’Etat Plateforme initié par la DSI de l’Etat.Cet Etat-plateforme5 définit des grandes fonctions et typologies pour les briques logicielles développées :

● fournisseur de données● fournisseur de service● fournisseur d’identité● hub de service ● hub de données

Ce cadre architectural élève aussi le principe d’API comme un des piliers de la communication et l’intéropérabilité entre les différentes briques du SI.

Le Dashboard Entreprise souhaite s’inscrire parfaitement dans ce cadre général et profiter au maximum des services et API déjà existants ainsi que de ceux en cours de développement.

4) Architecture générale du projet

Le Dashboard Entreprise s’inscrit dans le principe d’architecture dit de client-serveur “pur” où la partie client est de type “one page webapp” et le serveur est designé suivant le principe “d’API first”. La mise en oeuvre de ce principe permet de disposer d’une application cliente totalement indépendante du serveur, pouvant fonctionner sur n’importe quel device et ne nécessitant pas d’infrastructure d’hébergement lourde. L’intégration coté client de nouveaux services et API est aussi facilitée car aucune modification coté serveur n’est nécessaire.

Coté serveur, mettre en oeuvre le principe “d’API First” permet de s’assurer que les fonctionnalités et services mis en place seront disponibles de manière standard et uniforme pour tous les clients potentiel. Dans ce cadre, par “client” on entend bien sûr en premier lieu le dashboard, mais potentiellement tous projets ou administrations ayant besoin d’un service développé dans le cadre du dashboard, qui pourront alors y faire appel via l’API mise en place.

Le graphique ci-dessous présente l’architecture générale du dashboard et son intégration avec l’environnement serviciel existant dans l’administration.

5 http://etatplateforme.modernisation.gouv.fr/

10

Les paragraphes suivants décrivent plus en détail les différents éléments de cette architecture.

Client et interface utilisateur

Cette brique “Dashboard” est celle qui permettra le développement et la mise à disposition de l’interface utilisateur.L’objectif ici est le développement et la mise en œuvre d’un framework innovant “client pur” permettant l’intégration standardisée de modules utilisateurs issus du secteur public comme privé.Ce framework sera composé d’un ensemble de librairies de type SDK offrant aux développeurs un ensemble de fonctionnalités permettant un accès simple et sécurisé à l’ensemble des API et services mis en place dans le cadre des développements serveur coté Dashboard.En plus de cette partie intégration avec le back-end, le framework proposera un ensemble de templates et de bonnes pratiques pour la mise en place d’un design uniformisé et cohérent pour l’ensemble des fonctionnalités pouvant être offertes par les administrations et les partenaires.

11

Afin de répondre au mieux à l’ensemble des besoins, ce framework devra faire l’objet d’un travail important de co-design avec l’ensemble des partenaires sélectionnés.

Intégration des services et données

Cette couche fonctionnelle a pour objectif de mettre en cohérence et en lien les différentes API, données, services qui seront développés dans le cadre du Dashboard et de fournir l’ensemble des fonctionnalités de partage des données grises des entreprises auprès des partenaires pour la fourniture de services personnalisés aux utilisateurs.

Cette couche remplit donc un premier objectif d’interface stable et standardisée entre les différents éléments mis en place côté serveur et les librairies de gestion de l’interface utilisateur.C’est donc un moyen de découplage entre les développements réalisés coté serveur et ceux réalisés coté client : par exemple, des jeux de données “bouchon” pourraient être mis en place dans la couche d’intégration en attendant le développement effectif du service et permettre ainsi à la partie interface d’être développée en utilisant ces données bouchon.

Les deuxième objectif de ce composant est de mettre à disposition des développeurs l’ensemble des fonctionnalités nécessaires à la gestion des partages des données grises d’une entreprises auprès de partenaires fournissant des services personnalisés.Les notions de granularités des informations partagées (exemple : une seule ligne d’un document comptable), de format (exemple : format machine et non pdf) ainsi que la gestion des droits de réutilisation de ces données devront être des éléments gérés de manière simple et transparente pour les développeurs voulant intégrer leur services au Dashboard. Dans cet ensemble, la brique FranceConnect devra pouvoir s’intégrer et être le fournisseur d’authentification référent dans le composant mis en place.

FranceConnect et fournisseurs d’identités

L’ensemble des développements réalisés devront être compatible avec le SSO FranceConnect.Les fournisseurs de données et de services nécessitant une authentification doivent être compatibles avec le protocole Oauth2 et la norme eIDAS.Les fournisseurs de données et de services devant disposer de données appartenant à l’utilisateur et nécessitant sa validation doivent eux aussi être compatible avec le protocole //// tel que mis en oeuvre dans le cadre de France Connect.

12

Etat plateforme : Fournisseurs de services et fournisseurs de données

Les fournisseurs de services et de données de l’état plateforme sont une source importante pour la mise en œuvre des couches fonctionnelles du dashboard.Les répondants devront donc utiliser au maximum les fournisseurs déjà à disposition dans l’état plateforme ou les initiatives portées par l’administration (APIEntreprise, API OpenEntreprise,...).Dans le cas où certains éléments ne seraient pas immédiatement disponible au sein du SI de l’état, les répondants mettrons en place avec l’AMOA du projet une stratégie de demande d’évolution auprès de la DINSIC et/ou une stratégie de contournement en fonction des délais associés à la mise en place du fournisseur au sein de l’état.

Couche d’interconnexion des données

Cette couche a pour objectif de permettre une communication des informations entre les fournisseurs de données de l’Etat Plateforme et le commun des données Dashboard Entreprise.En effet, certaines données disponibles dans le SI de l’état seront utiles pour l’amélioration, le traitement et/ou l’alignement des données dans le commun. Aussi, certains services de l’Etat plateforme pourraient vouloir utiliser les données disponible dans le commun du Dashboard, cette couche d’interconnexion leur permettra d’y accéder via les API mises en place dans le cadre des développements.L’objectif de ce composant et de permettre l’alignement des données entre des différents fournisseurs de données de l’état plateforme et ceux du dashboard.En fonction des API développées dans le cadre des 3 couches fonctionnelles du dashboard pourront être affectés dans cette couche :

● des connecteurs de récupération des données des fournisseurs de données ou de service de l’Etat plateforme lorsque ces fournisseurs exposent des API trop complexes ou des données non formatées pour les besoin du dashboard. La couche d’interconnexion intervient alors comme un facilitateur pour l’utilisation des fournisseurs de l’état plateforme par les services Dashboard

● des interface de présentation des données et des services adaptés au besoin des utilisateur coté administration lorsque les API coté dashboard fournissent trop (API de réduction) ou pas assez de données (API d’aggrégation). Cette couche d’interconnexion agit alors comme un “proxy” entre les différents besoins en données de l’administration et du dashboard entreprise.

Cette couche transverse ne fera pas directement l’objet d’un appel à réponse. Certains éléments mise en place au cours du projet seront mutualisés dans cette couche en fonction des opportunités identifiées et de l’évolution architecturale du projet.

13

Services API partenaires

Ce bloc fonctionnel représente les services pouvant être mis à disposition des entrepreneurs dans la partie “services tiers”.Pour permettre à ces services de réaliser au mieux leur objectifs certains nécessiteront le partage de données de l’entreprise et une communication avec des données du “secure data” auxquelles le client donne accès.Ces services API devront exposer une API HTTP REST documentée via Swagger.Les répondants souhaitant mettre à disposition un service partenaire aux entrepreneurs devront l’indiquer dans leur réponse.

Commun des données :

Le “commun des données” est un ensemble de briques fonctionnelles permettant d’implémenter les fonctions d’alignement, de traitement et de partage des données publiques et privées pour la fourniture de services personnalisés..

14

Ces services sont basés sur 3 niveaux de données : - Secure Data: données détenues par l’administration, qui peuvent être partagées entre

administrations ( en lien avec l’administrateur général des données) - Partnership data: données publiques, enrichies par des acteurs privés et publics, grâce

à des partenariats public / privé ( dont le présent achat innovant)- Open Data: données publiques ouvertes et librement réutilisables sur www.data.gouv.fr

Et une “interface de partage” permettant d’assurer le partage des données personnelles de l’entreprise, tout en assurant un contrôle total sur ces partages (périmètre, services utilisateurs, temporalité).

Les démonstrateurs pourront s’intégrer dans un ou plusieurs des trois niveaux de services du Dashboard.

Certains démonstrateurs pourront être portés et financés en partenariat avec des partenaires publics de la DILA, qui prendront la forme de groupement de commande ad hoc sur la base de l’article 7 du code des marchés publics, dont la constitution aura été antérieure à la mise en concurrence relative à l’ achat innovant.

Ce commun est composé de 3 “couches” fonctionnelles aux accès et finalités différentes :

15

1) La couche secure data : elle a pour objectif de conserver, traiter, mettre en cohérence les données privées (ou grises) des entreprises à destinations des administrations.

2) La couche partnership data : elle a pour objectif de mettre à disposition des partenaires Dashboard des données de qualité non encore mises à disposition du public ou ne pouvant être mises à leur disposition. Ces données pourront être de source administrative ou partenariale. Au délà des données, des algorithmes, services et infrastructures pourront aussi être mis à disposition pour le traitement des données présentes dans cette couche

3) La couche “Open Data” : elle met à disposition des données ouvertes, tout en proposant une api et des alignements et traitements sur ces données pour les rendre facilement interopérable et utilisables dans le cadre du Dashboard et d’autres projets. Cette couche pourrait être opérée par les autres projet autours des données menés dans le cadre des activités de la DILA.

Résiliance architecturale du projet

L’un des constituant de l’ achat innovant est la notion de R&D et d’innovation associé à la “mise en concurrence” de différents acteurs pour la résolution des challenges qui leur sont proposés.Dans ce cadre, et du fait de nombreuses inconnues inhérente à la R&D, certains répondants (et donc les réalisations associées) peuvent faire défaut et ne pas aboutir à la réalisation effective demandées (surtout au cours de la première phase du partenariat dite d’amorçage).Le choix architectural réalisé par le projet de 4 couches fonctionnelles inter-dépendantes permet de pallier à ce risque de défaut, par :

1) la présence d’une AMOA externe au partenariat permettant d’assurer la bonne marche du projet

2) Le découplage des 4 couches fonctionnelles par la définition d’API d’intéropérabilité claires entre ces différentes couches dont la charge de la définition revient à l’AMOA du projet.

La gouvernance et la définition des API des 4 couches fonctionnelles par l’AMOA du projet permet de contrer la défaillance potentielle d'un (ou plusieurs) répondant par la possibilité de définir des données "bouchons" simulant le fonctionnement des API “en défaut”.L’utilisation des API conjointes aux “données bouchon” permet donc de simuler le fonctionnement d’une couche qui serait en défaut de par son répondant et permettra donc aux autres répondants de continuer leur travaux de R&D et d’implémentation.

Cette résiliance architecturale est donc disponible dès la première phase de l’achat innovant, mais aussi pour les phases suivantes, car dans les phases 2 et 3 cette architecture permet aux acteurs impliqués de continuer travailler avec une couche différente pendant que l’implémentation concrète de celle-ci est en cours de remplacement ou d’optimisations (performance, fiabilité,...) pour respecter les contraintes relatives aux phases de développement et d’industrialisation. Sur l’ensemble des phases de vie du partenariat cette architecture permet d’assurer une agilité, une efficience dans la mise en œuvre et une facilitation du travail coopétitif dans le cadre multi-acteur du présent achat innovant.

16

4) Existant et orientations techniques

Description de l’existant

Comme vu précédemment, dans le cadre du programme OpenLaw Europa, une première version de l’infrastructure a été mise en place, et notamment l’infrastructure matérielle opérées par les Mines Télécom partenaires du projet Dashboard Entreprise.

Cette infrastructure matérielle, appelée TeraLab permet de mettre en place des environnements de travail et de traitement des données sécurisés et adaptés aux besoins. Il est par exemple possible de disposer d’un serveur ayant une capacité en mémoire vive de 15TO, ou une ferme de serveur en capacité de faire fonctionner Hadoop ou tout autre framework de traitement “Big Data”.

Les partenaires souhaitant travailler sur une brique fonctionnelle au niveau “commun des données”, devront préciser dans leur réponse les besoins en terme de framework de traitement et d’infrastructure “machine” nécessaires pour atteindre leurs objectifs.

Veuillez noter que le système d’exploitation de type Linux est préféré sur les infrastructures Teralab.

Dans le cadre du programme d’investissement d’avenir, la DILA a conclu une convention de partenariat avec l’Institut des Mines Telecom pour la mise à disposition et la maintenance de l’instance Teralab a minima pendant toute la durée de la phase d’amorçage et de développement du présent achat innovant.

Outils, langages de programmation, format de donnée

L’infrastructure de service du projet se découpe en 2 grands blocs principaux : le serveur et le client.

Coté serveur une préférence est faite pour les développement en Java, mais il s’agit bien d’une préférence, le langage d’implémentation n’est pas un pré-requis. Il est nécessaire que le service mis à disposition expose une interface de type API REST documentée grâce au format Swagger.Les formats de sortie et d’entrée des API devront être en Json à minima en Json-ld de préférence.Les format de stockage de données RDF est proposé, mais dans le cas où l’implémentation concrète nécessiterait un autre format de donnée, le système de base de donnée devra fournir une possibilité de requétage des données stockées au format RDF.Pour permettre leur réutilisation ultérieure dans le cadre de la constitution d’un socle commun pour l’Etat plateforme, les partenaires accompagneront la mise à disposition du code d’une documentation technique pour l’installation de l’environnement en développement.

Coté client, les développements doivent se baser sur les technologies HTML5, CSS3 et Javascript. Afin d’assurer une cohérence entre les différents développements et la mise en place de différentes librairies de simplifications pour les développements, le framework Angular.js sera utilisé comme base. Les travaux d’intégration au niveau de l’interface

17

Dashboard devront donc se baser sur ce framework et utiliser les templates d’application (ou boilerplate) fournit. Ces templates mettrons à disposition les outils et méhodes de base pour la création d’applications “Dashboard” tels que Grunt, Bower,...

5) Structure par couches servicielles APIsées, rôle de l’AMOA, des répondants à l’ achat innovant et la communauté d’innovation ouverte.

Structure par couches servicielles APIsées

Chacune des 4 couches du ‘’commun des données contributif’’ doit répondre aux contraintes générales suivantes :

● Exposer une API standard et documentée● Etre en capacité d’utiliser l’API des autres couches ● Ne pas dépendre des autres couches fonctionnelles autrement que par l’utilisation des

API.

Cette infrastructure en couches (ou services) independantes les unes des autres présente les avantages suivants :

- possibilité de parallélisassions des travaux entre les différentes couches : La définition des API de communication entre les différentes couches permet la mise en place rapide d’API “mock” (données de démonstration) qui permet aux autres couches fonctionnelles d’utiliser ces API mock et donc travailler à l’implémentation cible de sa couche.

- résilience à la défaillance d’un partenaire sur le développement d’une couche : La mise en place des “API mock” permet donc de ne pas bloquer les autres partenaires lors de la création de leurs services. Et donc aussi de continuer à travailler malgrès la défaillance potentielle d’un partenaires en charge de l’implémentation détaillée d’une couche.

- réutilisation par la communauté et les autres services de l’Etat plateforme : la création de couche fonctionnelle de type “API first” (définition en premier de l’API) permet de créer des services à fort potentiel de réutilisation dans des applications métiers spécifiques.

La définition, la maintenance et l’évolutivité de ces différentes API entre les différentes couches fonctionnelles sera une des missions principale de l’AMOA du projet.

Rôle de l’AMOA

Pour mener ce projet, une prestation d’AMOA accompagnera la DILA.Au delà des rôles “classiques” de gestion de projet, des acteurs, de spécification et de conception centrée utilisateur, l’AMOA au sein de ce projet aura la responsabilité de la définition de l’architecture générale du projet ( la gouvernance, la mise en œuvre et l’évolution des différentes API associées à chaque couche servicielle).

18

Rôle des répondants au marché

Les répondants au marché auront pour objectifs de réaliser les recherches et développement nécessaires associés à la couche fonctionnelle qui est leur charge.Ils devront aussi travailler en intelligence avec les autres partenaires et fournir des implémentations de qualités, correctement documentées et open-source.Ils devront s’appuyer sur les acquis pré-cités et s’impliquer pour le développement du socle technique mis en place au cours de la première année de travaux d’innovation collaborative sur lab.openlaw.fr. Au cours des évènements de dissémination organisés par l’AMOA les répondants devront être présents et participer aux ateliers dédiés et prendre en compte les remarques de la communauté pour l’amélioration et l’évolution des services fournis.Les répondants devront aussi mettre en place des interfaces utilisateurs s’intégrant dans l’interface finale du “Dashboard Entreprise” pour faire la démonstration de l’usage possible de leur services avec le client final.

Rôle de la communauté d’innovation ouverte.

Le rôle de la communauté d’innovation (OpenLaw en particulier) associée au projet sera de challenger les différents développements effectués par les répondants et l’AMOA tout en créant de nouveaux services avec les données et traitements mis à disposition par le projet.Il sera aussi un acteur de premier plan pour valoriser l’innovation produite au cours du projet et force de proposition pour l’usage des réalisations du projet dans d’autres contextes, pour la réponse à d’autres besoins.

19