Catégorie Archives: Blog

D’où viennent les données essentielles de la commande publique ?

Le schéma ci-dessous illustre le chemin parcouru par les données essentielles de la commande publique (DECP) avant d’être consolidées et publiées sur data.gouv.fr. Les données du Bulletin officiel des annonces de marchés publics (BOAMP) c’est une toute autre histoire, elles ne sont pas traitées ici.

En début de chaîne, il y a un agent public qui entre les données dans un outil de gestion de marchés ou de gestion financière. Puis les données transitent par le profil d’acheteur choisi par l’organisme public, ou par le service Hélios de la DGFiP (parfois les deux), pour arriver, par divers moyens, sur data.gouv.fr. Enfin, l’équipe de l’administrateur des données du Ministère de l’économie et des finances (MINEF) traite ces données (détails techniques), les consolide et les publie sur data.gouv.fr. Ces données consolidées sont la source primaire de decp.info, après transformation.

Les données des principaux portails de marchés publics remontent aujourd’hui pour être intégrées aux données consolidées, mais il reste encore beaucoup de données à récupérer chez certains acteurs privés (Xmarchés, Klekoon, etc.), et sur de nombreux portails régionaux ou spécifiques (marchespublics596280.fr, alsacemarchespublics.eu, marches.cnes.fr, etc.)

Vous pouvez également consulter la documentation officielle sur https://139bercy.github.io/decp-docs/.

La liste des sources de données actuellement traitées et consolidées est ici.

S’il y a des points que j’ai oubliés ou que vous souhaiteriez voir davantage développer, vous pouvez m’envoyer un message ou répondre à ce tweet.

Précision : j’ai travaillé pendant 5 ans avec la mission Etalab puis avec le Ministère des Finances à la modélisation, au traitement et à la publication des DECP. Cette collaboration s’est terminée en janvier 2021, le Ministère des Finances étant à présent autonome sur ces sujets.

Cliquez sur le schéma pour l’ouvrir en grand dans un nouvel onglet .

Schéma de remontée des DECP vers data.gouv.fr

Pourquoi avons-nous choisi les formats JSON et XML pour les données essentielles de marchés publics, et non le CSV ?

J’ai souvent entendu cette question de la part de personnes souhaitant ardemment voir ces données être davantage réutilisées. Le format CSV est effectivement simple à utiliser, principalement en raison du fait qu’il peut être édité et lu dans un logiciel de tableur.

Cependant, la simplicité d’utilisation va avec la simplicité de la structure des données qu’il est possible d’y ajouter. Prenons les données de marchés publics. Le décret impose que les données suivantes (entre autres) soient représentées :

  • identifiant de marché
  • montant
  • procédure utilisée
  • titulaires
    • identifiant (SIRET) du titulaire
    • nom du titulaire
  • modifications
    • de montant
    • de titulaires
      • identifiant (SIRET) du titulaire
      • nom du titulaire

Dans un fichier CSV, les données sont stockées en ligne et colonnes (exemple avec les bornes de recharge). Chaque ligne est un truc qui a des caractéristiques. On parle d’objet et de propriétés en informatique. Donc dans un fichier CSV de marchés publics, on aurait, idéalement, une ligne par marché. On aurait donc les colonnes identifiant, montant, procedure, titulaires….

Comment stocker plusieurs titulaires et leurs propriétés dans une case ? On pourrait avoir les colonnes siretTitulaire1, siretTitulaire2, etc. mais il n’y a en théorie pas de nombre maximum de titulaires dans un marché. Et comme il s’agit d’un format standard, tous les acheteurs publics devraient se coltiner un fichier avec 20 colonnes dédiées aux titulaires. Donc non.

Et je ne parle même pas des modifications de titulaires, sachant qu’un marché peut avoir une infinité de modifications, qui elles mêmes peuvent avoir une infinité de titulaires !

Tableau vs. arbre

Heureusement, il existe des formats de fichiers qui ne sont pas en lignes, mais en arbre, comme XML et JSON. Un exemple commenté vaut mieux qu’un long discours, avec un marché fictif au format JSON (les objets sont délimités pas des { }, les listes par des [ ]) :

La structure du fichier est en arbre, car des « branches » peuvent pousser d’autres « branches » : la propriété modifications peut avoir une infinité d’enfants (ici 1), et la propriété titulaires en a 2.

Je sais que ce format n’est pas utilisable directement sans outil dédié. En revanche, JSON étant le format de données standard des applications Web, il est très facile de concevoir des applications qui permettent de visualiser ces données (j’ai fait ça, et le développement Web n’est pas ma spécialité : sireneLD).

En fait, il est possible de reproduire ces données en CSV. On pourrait avoir un CSV pour les données simples du marché (id, montant, procedure, etc.), un CSV pour les titulaires, et un CSV pour les modifications. Les CSV seraient liés entre eux grâce à l’identifiant de marché. Je réfléchis à proposer ce CSV, mais il ne serait pas non plus facilement utilisable par des non-informaticien·nes.

Les formats de données ne sont pas une question de goût, et ne sont pas interchangeables. Compte tenu de la structure des données à représenter, le format CSV ne convenait pas, et nous avons indiqué dans l’arrêté que les formats des données seraient XML et JSON (au choix de l’acheteur public). Le format CSV convient très bien pour les subventions, les bornes de recharge, mais pas pour des données plus complexes comme les marchés publics. L’avantage d’une structure plus complexe, c’est qu’elle permet de représenter le réel plus fidèlement, et donc de poser des questions plus complexes aux données.

Voilà, j’espère que c’est clair ! N’hésitez pas à poser vos questions et vos commentaires ci-dessous ou sur Twitter.

eDelivery, le protocole européen d’échange de documents

Dans le cadre de ma mission de conseil auprès de la mission Etalab sur la publication des données essentielles des marchés publics, je me suis intéressé aux standards proposés par la Commission européenne pour la transmission d’informations inter-administrations, et plus particulièrement à eDelivery. Voyant qu’aucune documentation n’était disponible en français, je me suis dit qu’il pourrait être utile que je rassemble mes notes et les partage.

En bref

eDelivery est un composant issu du règlement européen Connecting Europe Facility (CEF) et un réseau fondé sur un protocole de transport de données sécurisé afin de faciliter l’échange de données et de documents entre des administrations publiques et la société civile. En général, chaque nœud de ce réseau est consacré à un seul projet impliquant des administrations de plusieurs États membres (ex : e-justice, e-administation, commande publique électronique, etc.). Ces nœuds peuvent être liés à des administrations nationales, régionales ou locales.

Les autres composants de CEF :

Le règlement CEF prévoit également le financement des infrastructures nécessaires au déploiement de ces composants.

Un réseau européen entre l’administration et la société civile

L’échange de données et de documents peut être initié entre administrations publiques (A2A), mais également entre une administration publique et une entreprise (B2A / A2B), comme l’a démontré l’implémentation PEPPOL du protocole eDelivery dans le domaine de la commande publique électronique (eProcurement).

Les administrations qui développent des portails Web peuvent utiliser eDelivery pour échanger des données et des documents avec les citoyens (A2C / C2A). Par exemple, un portail de justice en ligne à destinations des citoyens peut communiquer avec d’autres systèmes d’information.

Enfin, eDelivery peut être utilisé indifféremment pour échanger au niveau local, national, ou européen.

Un protocole standard

eDelivery utilise le protocole de messagerie AS4 (Applicability Statement 4) développé par l’OASIS, et suit les recommandations définies par les États membres dans le cadre du projet pilote e-SENS (Electronic Simple European Networked Services) qui s’est terminé en mars 2017 et a rendu ses conclusions.

Chaque administration rejoignant le réseau eDelivery peut soit installer un point d’accès, soit faire appel à un fournisseur de service et ainsi partager des données et des documents via le protocole AS4.

L’utilisation d’un protocole standard commun au niveau européen assure un échange de données simplifié et donc plus efficace et sécurisé. De nos jours, les fuites de données étant devenues un risque majeur, de cette sécurité découle une plus grande confiance dans l’échange d’information, notamment pour les documents confidentiels.

La Commission européenne détaille les avantage d’eDelivery sur [cette page]https://ec.europa.eu/cefdigital/wiki/pages/viewpage.action?pageId=46992275).

Comment ça marche ?

Le protocole eDelivery utilise une topologie de réseau de type « 4 coins » (4-corner topology). Cela signifie que chaque système d’information du réseau eDelivery, et par extension chaque administration, communique avec les autres membres via un point d’accès (access point) qui lui est propre, sans passé par un point d’accès central. Cette topologie se distingue par un haut niveau de décentralisation mais impose un haut niveau de conformité au standard et de sécurité. Cette topologie est également appelée un « réseau maillé » (mesh network).

Topologie à 4 coins

]14 La topologie à 4 coins (C1, C2, C3, C4)

Dans cette configuration :

  • le système d’information émetteur est le coin 1
  • le point d’accès émetteur est le coin 2
  • le point d’accès récepteur est le coin 3
  • le système d’information récepteur est le coin 4

La Commission européenne a regroupé les informations générales sur la mise en place d’eDelivery dans une présentation au format PDF.

Le message

Le protocole eDelivery se base sur le standard AS4 Profile of ebMS 3.0 Version 1.0 de l’OASIS et est compatible avec SOAP 1.1 ou 1.2. Le résultat est le protocole eDelivery AS4 1.13 du 30 mai 2018. C’est ce protocole qui encadre la communication entre les points d’accès.

Des métadonnées supplémentaires peuvent être ajoutées à un message via un payload standard SBDH (Standard Business Document Header), pour davantage d’opérabilité. Pour plus d’informations, vous pouvez également consulter la foire aux questions consacrée à SBDH.

Enfin, le contenu d’un message eDelivery peut être signé grâce à la technologie ASiC (Associated Signature Containers) afin de garantir l’authenticité du contenu tout au long de sa transmission. C’est donc une alternative à la sécurité fournie par le protocole SOAP. Une foire aux questions est également disponible.

Les points d’accès et le système d’information

Le point d’accès est la brique logicielle qui permet au système d’information d’une administration d’envoyer et de recevoir des messages sur le réseau européen eDelivery. La Commission européenne publie une liste de solutions de point d’accès, dont une, Domibus, est l’implémentation de référence et open source (code source).

La communication entre un système d’information et le point d’accès associé relève du choix de l’administration. Des connecteurs sont disponibles, mais il est également possible de concevoir une connexion directe entre le système d’information et le point d’accès, sans passer par un connecteur. Enfin, un connecteur peut être partagé par plusieurs systèmes d’information.

Découverte des autres points d’accès : statique ou dynamique

eDelivery définit deux méthodes pour déterminer l’adresse IP du point d’accès d’un message et pour récupérer ses métadonnées : l’acquisition statique (static discovery) et l’acquisition dynamique (dynamic discovery).

L’acquisition statique repose sur le protocole DNS, le même protocole utilisé pour le Web, qui permet de déterminer une adresse IP à partir d’un nom de domaine associé. L’inconvénient est que la mise à jour des enregistrements DNS peut prendre quelques heures en cas de changement d’adresse IP du point d’accès.

L’acquisition dynamique repose sur un service de publication des métadonnées (Service Metadata Publisher, SMP) combiné à un service de localisation (Service Metadata Locator, SML) partagé. Les administrations participant au réseau eDelivery sont invitées à publier les données de leurs points d’accès via un service SMP. Elles reçoivent alors un identifiant qui facilite sa découverte, améliore la visibilité des capacités des points d’accès du réseau et diminue la dépendance au protocole DNS.

L'enregistrement d'un point d'accès auprès d'un SML via un SMP

]26 L’enregistrement d’un point d’accès auprès d’un SML via un SMP

Lien avec TOOP

Le TOOP, « The Once-Only Principle » (le principe « une seule fois »), est un projet lancé par la Commission européenne le 1er janvier 2017. Appliqué au service public, ce principe signifie que les entreprises et les particuliers n’aient à fournir un même justificatif qu’une seule fois.

Le projet TOOP est coordonné par la Tallinn University of Technology, et repose sur eDelivery pour le partage d’informations entre administrations publiques.

En France, ce principe est matérialisé par le programme « Dites le nous une fois ».

Questions en suspens

  • Quel est la différence entre le protocole PEPPOL utilisé par OpenPEPPOL pour la commande publique électronique, et e-SENS, poussé par la réglementation CEF et déjà utilisé par e-CODEX ? Les deux se basent sur le standard OASIS AS4.
  • Sur la page de la spécification d’e-SENS AS4 1.12, il est indiqué que cette spécification est dépréciée par eDelivery AS4 1.13. Pourquoi ce renommage ? eDelivery remplace e-SENS ?

csvtool manual page

I just discovered csvtool, a command line utility that I found in default Xubuntu package repository, as I was looking for other utilities (namely csvsort, csvstat, csvcut and co.). I wanted to scream my joy but couldn’t find the manual online. Only when running csvtool --help. It’s not on Ubuntu website.

Read more

From datasets to linked datasets in open government data

Helping the machines to understand what the data means, so that they can help us search and cross the data published by our governments.

Initially published on Medium on September 14th, 2014. I’ve replaced some links with more accessible sources (i.e. not hardcore standard specifications) and I’ve also rephrased the last sections to make them more accessible.


Summary (tl;dr;): Publishing open government data dissipates the mist around the business of the State and its tentacles, and enriches the dialogue between the administration and the citizens. However, today, this data is usually not described with machine-readable semantics, which makes it hard to perform large scale search and create value by crossing datasets together.

The Semantic Web technologies come to the rescue: they enable the creation of worldwide identifiers for concepts (the URIs), definitions with machine-readable semantics and data storage and querying as a graph. The result is a standard and semantics-driven open data platform.

Read more

cURL examples to query Wikidata

The SPARQL endpoint is http://wdqs-beta.wmflabs.org/bigdata/namespace/wdq/sparql and it has a Web form to fire queries. However http://www.wikidata.org/prop/direct/P31 (« instance of ») tells you what the entity is.

The repository doesn’t have named graphs, or at least the SPARQL endpoint rejects graph queries. The classes of entities (rdf:type) are not described in the repository.

Read more