En France, les codes sources sont considérés comme des documents administratifs qui sont communicables, publiables en ligne et réutilisables (article L300-2 du code des relations entre le public et l’administration). Ainsi, les administrations, collectivités territoriales, établissements publics et entreprises chargées d’une mission de service public publient les codes sources de leurs logiciels (avec toutefois des réserves comme lorsque ceci concerne la défense nationale, la sécurité, la monnaie etc. voir article L311-5). On peut donc retrouver de nombreux logiciels publiés par la fonction publique sur des plateformes comme GitHub ou Gitlab.

La DINSIC (direction interministérielle du numérique et du système d’information et de communication de l’État) publie par ailleurs une politique de contribution aux logiciels libres qui guide les administrations et les agents lorsqu’ils publient ou contribuent à des logiciels libres.

Je vous propose dans cet article de mettre en évidence quelques chiffres clés des logiciels publiés par la fonction publique en France.

Données utilisées

Obtenir une liste des organisations utilisées par la fonction publique française sur les plateformes de partage de code n’est pas une mince affaire. Je me base sur la liste des organisations que l’on retrouve sur un répertoire de la DINSIC consacré ainsi que la liste présente sur le site government.github.com pour la France. Pour des raisons de simplicité, je ne conserve que les organisations créées sur GitHub, cette plateforme représentant la quasi exclusivité des publications de dépôts de code des organismes publics français.

Ce travail de récupération des données (grâce à des appels à l’API de GitHub et du Python) et les données se trouvent dans un répertoire GitHub que j’ai publié : AntoineAugusti/data-codes-sources-fr. Les analyses se basent sur les données à la date du 12 janvier 2019.

On dénombre un total de 1531 répertoires dans 53 organisations. Attention, une administration peut avoir plusieurs organisations. C’est par exemple le cas de l’ANSSI (Agence nationale de la sécurité des systèmes d’information), pionnière de l’open source, qui compte 4 organisations (ANSSI-FR, clipos, clipos-archive, wookey-project).

Organisations les plus populaires

La popularité d’une organisation est difficile à évaluer. J’ai choisi arbitrairement de prendre la somme des stars, l’équivalent des favoris sur GitHub. Voici un tableau récapitulatif pour le top 20 des organisations.

La sécurité est à l’honneur ! En effet, le top 2 correspond à l’équipe sécurité informatique du CEA (Commissariat à l’énergie atomique et aux énergies alternatives) puis l’ANSSI (Agence nationale de la sécurité des systèmes d’information).

Langages les plus populaires

Alors, à votre avis, quels sont les langages principaux des répertoires des organismes français ? Cobol, Fortran ? Vous êtes bien moqueurs, et loin de la réalité.

Un tiers des répertoires publiés le sont en JavaScript ou en Python, ce qui correspond à la popularité de ces langages actuellement. 216 répertoires ont un langage inconnu. Pour avoir regardé quelques exemples, je constate souvent que ce sont des répertoires qui contiennent quasi exclusivement des fichiers textes (en Markdown, RST ou TXT), utilisés comme répertoires de documentation ou comme wiki.

Licences utilisées

Le top 1 n’est pas une bonne nouvelle. Point de méthode : la licence est détectée par GitHub, à l’aide de la librairie Ruby Licensee. J’ai tenté d’en savoir plus, voici ce qui explique ce triste résultat :

• un nombre important de projets ne comporte pas de fichier de licence (la bonne pratique est de mettre ceci dans un fichier LICENSE) ;
• certains projets mentionnent la licence dans le README ;
• d’autres projets utilisent les licences CeCILL ou la Licence Ouverte (licences introduites par la France), dans des fichiers nommées CeCILL.txt ou LO.md et qui ne sont donc pas reconnus.

Concernant les licences non détectées, la librairie utilisée par GitHub ne reconnait pas encore les licences CeCILL ou la Licence Ouverte, ce qui peut expliquer une part importante de licences classées dansOther.

Il faut noter que la liste des licences que peuvent utiliser les organismes publics français est restreinte et définie par décret. Ces licences sont listées sur une page de data.gouv.fr.

Je remarque qu’il faut donc progresser du côté des licences utilisées lors de la publication des répertoires. L’absence de licence ou une licence non adéquate empêche la réutilisation du logiciel.

Création des répertoires au cours du temps

Bon nombre de répertoires voient le jour tous les mois. Par exemple, en 2018, 45 répertoires ont été créés en moyenne par mois. Le pic de septembre 2018 s’explique par la publication du projet clipos-archive par l’ANSSI comportant 101 répertoires.

La suite

Cette courte analyse relève d’une initiative personnelle. Espérons qu’un des objectifs de l’année 2019 soit d’encourager et de faire la promotion des publications de codes sources des organismes publics français. L’idéal étant de pouvoir cataloguer plus d’organismes, augmenter la qualité de publication des répertoires et avoir régulièrement un retour sur la production de logiciels libres par la fonction publique française.

In this blog post, I’ll explain how to leverage Netlify and GitHub to create a REST API, serving JSON, without any infrastructure and for free. Netlify is amazing at deploying projects with continuous integration, a build step, static hosting behind a CDN and with automatic HTTPS support thanks to Let’s Encrypt. I’m using GitHub as my go-to hosted version control system, but you can use Gitlab or Bitbucket if you’d like.

Our project has some constraints:

• The REST API will only be able to serve content, not create, update or delete things (we only have static hosting and not a server-side language) ;
• You should have a reasonable amount of files to serve (a few hundreds);
• You should respect Netlify’s Terms of Service. Quotas for free accounts: 100 GB / month of bandwidth, 100 GB of storage.

Example: an API for bank holidays

I’ll use a real-world example to explain things: we’re going to build a REST API for bank holidays. Basically, for a given year, we’ll tell which days are bank holidays. Here is the final GitHub repository.

First, we need the raw data. In my case, I’ll use a CSV dataset for French bank holidays. During Netlify’s build step, we’ll create all the required files that will be served by our API. In our case, we want to create one JSON file per year, which will contain the bank holidays of that year. Netlify supports a handful of languages for the build phase, I’ve used Python 3.6 (the desired Python version is specified in the file runtime.txt). My build.py file downloads CSV files, convert them in JSON and store a file per year.

We now already have a working API, that exposes transformed JSON files. You could already access these files, by using a URL like /data/2019.json. Since we’re building a REST API, we want to expose meaningful URLs. To do this, we’ll leverage Netlify’s redirect rules. You can see my redirect rules in the _redirects file. Thanks to this, the final endpoint will be /api/2019, which is far better. Since our endpoints will most likely not change, I’ve used Netlify’s custom HTTP headers to set Cache-Control HTTP headers to instruct clients to cache the received data. You can see my rules in the _headers file.

Demo for French bank holidays in 2019: https://jours-feries-france.antoine-augusti.fr/api/2019

Takeaway

We’ve used the build step of Netlify to create our desired world for our API. Now Netlify takes care of hosting it with a custom domain, providing and renewing SSL certificates. All in 35 lines of Python. Not bad.

By default Netlify will rebuild your project every time you push a commit. You could perform builds more often by using webhooks.