Rejoindre le secteur public en tant que professionnel du numérique


Récemment dans le cadre de mon travail j’ai eu la chance d’organiser un sondage à destination des professionnels du numérique qui sont intéressés pour rejoindre le service public à un moment dans le carrière. La fonction publique est souvent décriée par ces professionnels : méthodes waterfall, processus longs, métiers non compris, salaires peu attractifs, peu de télétravail. C’est le prix à payer pour un métier servant l’intérêt général et qui donne du sens à son travail. Ben Balter a écrit à ce sujet un article de blog très pertinent : 19 reasons why technologists don’t want to work at your government agency.

Des réflexions sont menées en interne dans l’administration pour attirer les talents nécessaires. Les anciens professionnels venant du privé rappellent régulièrement les points sur lesquels il faut s’attarder. Ce sondage était l’occasion de montrer que ce sujet d’actualité est traité et que l’administration est à l’écoute des premiers concernés : les professionnels qui veulent rejoindre le service public un jour ou l’autre. Vous pouvez retrouver ce sondage, les principaux résultats de celui-ci et les données brutes des soumissions reçues dans un article de blog sur Etalab.

Using GitHub Actions to run tests for Python packages


GitHub recently launched GitHub Actions, a way to automate software workflows and to run continuous integration or continuous delivery with a deep integration with the GitHub platform. It’s currently in beta and the general availability is planned for November 2019. Like CircleCI, jobs are free for public repositories, a chance for open source projects. Workflows are expressed in YAML.

GitHub develops some actions you can reuse and you can build yours. GitHub provides suggestions for common workflow needs: running tests on a Node package, pushing a Docker image to Docker hub when creating a tag etc. The Actions Marketplace has an interesting list of actions to help you get started in various tasks: linting, security, publishing, building, notifications, code reviews etc.

I decided to give it a spin with a Python package. My goal was to run unit tests on various Python versions. GitHub Actions has the concept of build matrix, something coming from Travis CI, which allows you to run a job in different environments (OS, Python version, architecture etc.). It makes it a breeze to test your code in various environments, something you could not easily do locally. You can find the YAML code I wrote to install dependencies and run tests on various Python versions.

You can head to the GitHub Actions documentation for a complete tour of the available features.

Writing tests for your static website: Jekyll, Hugo


Static site generators like Jekyll or Hugo are awesome to quickly publish a website online. Thanks to GitHub and Netlify, you can leverage powerful collaboration tools and free hosting to have a website up and running quickly. You’ll be able to deploy and update your website in minutes without worrying about hosting. This is super powerful.

One thing I’ve not seen a lot for static websites which is present in traditional software is tests: software you write to prove or make sure that your code does what you expect it to do. Sure, static websites have way less code than libraries or backends, but still: you can quickly have tens of posts and hundreds of lines of YAML in data files. It makes sense to write quick tests to ensure things like required keys are present for posts or foreign key consistency in data files. Tests ensure you have a high quality content on your website and can avoid broken layout which you would detect after browsing your static website.

Writing tests for Jekyll

How would you write tests for a Jekyll website? At the end of the day, static websites are composed of data files (usually in YAML) and content files in Markdown. Standard programming languages (Python, Ruby, PHP) can easily parse these files and you can write assertions about the content of them. These tests should be executed after every git push to perform continuous integration. You can use a platform like CircleCI or GitHub Actions to do this.

Jekyll tests code sample

Here is a sample code to run tests on CircleCI for Markdown posts: making sure required keys are there, tags are present and come from a predefined list, images and Twitter usernames have an expected format. These tests are written using Python 3.6 but you can use whatever programming language you like. You can also write tests for data files in YAML. It gets powerful when you write tests combining data files and content files in Markdown.

These tests run in less than 10 seconds on CircleCI after pushing your code and can quickly catch small mistakes. This is a straightforward way to improve the quality of your static website.

My open source contributions: first semester of 2019


It’s the end of June and I want to take a step back and reflect on my open source contributions since the beginning of the year. I’ve made 770 public commits on GitHub in the first semester.

I’m working at Etalab, the French government administration in charge of data policy and I’m involved in the Public Interest Entrepreneurs program (hiring talents to work in the administration). 95% of the code I work on is open source. This is a huge privilege and I love it. I get to talk about my work, collaborate with people and help other open source enthusiasts.

Main projects

Here are the main projects I’ve been contributing to (in term of commits):

Overall I’ve contributed to more than 50 public repositories.

Data extraction

I extracted this data thanks to Google BigQuery, which provides a public dataset storing GitHub events. This was the best way I found to extract my public activity on GitHub. Unfortunately GitHub doesn’t provide a way to get this through the API (at the people level) or through a personal export. Here is the SQL request used to extract only my public commits:

  count(1) as nb
WHERE actor.login = 'AntoineAugusti'
  and type = 'PushEvent'


These open source contributions have been a great opportunity to work with others. Open source lets public administrations interact with other administrations, companies, nonprofits and other governments on a daily basis. It’s been a privilege to answer questions, explain how things work and inspire others. Of course I’ve relied on many open source projects and have been helped a lot by other contributors.

Thanks to all the community, see you online for the next semester!

Discovering content caching with NGINX with proxy_cache


Lately, I’ve had the chance to discover how to leverage the caching of HTTP responses from proxied servers using NGINX and the proxy_cache configuration directives. The web application I’m talking about is dedicated to show sales of properties in France, recently made available in open data. This represents 15 million sales of real estate (houses, flats, lands, forests etc.) in 5 years. The application, realised by Etalab, gets a national press coverage because it’s hosted on an official government domain and was introduced by the Minister of Public Action and Accounts of France.

The web application is composed of a Python backend, talking to a PostgreSQL database with a standard geographical interface with filters and various zoom levels. You can see a demo of the first version of the application in video and browse the code created by Marion Paclot. Regarding traffic, NGINX handles a traffic of 2500 requests/minute during the day with peaks up to 5000-6000 requests/minute, the analytics are available publicly. Knowing people mainly browse their neighbourhood, it’s important to keep areas with a high population density in cache.

The goal was to keep up with this load with a single server of 8 cores and 32 Go of RAM. NGINX delivers this thanks to its proxy cache. We can serve the application with a load average of a 1-3 and an average RAM usage of 3 Go and 8 Go of proxy cache size. You’ll find the commented NGINX configuration below

# Define a cache of up to 10 Go, with files up to 10 Mo. Files that have
# been created more than 2 days ago will be deleted.
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=dvf:10m max_size=10g inactive=2d use_temp_path=off;
# Default key example: md5(
proxy_cache_key "$request_method$host$request_uri";

# Rate limiting by IP, up to 50 Mo of storage and limited to 10 requests per second
limit_req_zone $binary_remote_addr zone=hit_per_ip:50m rate=10r/s;

server {
  root /srv/dvf/static;

  # Serve directly geojson files with a browser cache of 30 days
  location ~ ^/(cadastre|donneesgeo) {
    expires 30d;
    access_log off;
    add_header Cache-Control "public";

  # Cache static files (index.html / *.js) only 30s in the proxy
  # cache and browser cache of 1 minute to be able to deploy
  # quickly changes.
  location / {
    expires 1m;
    add_header Cache-Control "public";

    proxy_cache dvf;
    proxy_cache_valid 200 30s;
    # Change the default query to drop the query parameters. News sites
    # often add query parameters to the index we are not interested in
    # and could bust our cache
    proxy_cache_key "$request_method$host$request_filename";
    include includes/dvf_proxy.conf;

  # The API tells which sales happened for a specific geographic area
  # between 2 dates.
  # This where we need to talk to Python + PostgreSQL. Keep API responses
  # in cache for 1 day and set the browser cache to 12 hours.
  # Allow a burst of up to 50 requests / second, but requests will be
  # queued to respect the max of 10 requests / second.
  location /api {
    expires 12h;
    add_header Cache-Control "public";

    limit_req zone=hit_per_ip burst=50 nodelay;
    limit_req_status 429;

    proxy_cache dvf;
    proxy_cache_valid 200 1d;
    include includes/dvf_proxy.conf;

  listen 443 ssl http2; # managed by Certbot
  ssl_certificate /etc/letsencrypt/live/; # managed by Certbot
  ssl_certificate_key /etc/letsencrypt/live/; # managed by Certbot
  include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
  ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
server {
  if ($host = {
    return 301 https://$host$request_uri;
  } # managed by Certbot

  listen 80;
  return 404; # managed by Certbot

And the include/dvf_proxy.conf file, which proxies requests to Gunicorn, the Python server:

add_header X-Proxy-Cache $upstream_cache_status;
add_header X-Frame-Options SAMEORIGIN;
add_header Content-Security-Policy "frame-ancestors 'self'";
add_header X-Content-Security-Policy "frame-ancestors 'self'";

proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;

Analysing commits on GitHub by authors


This article is written in English but may be of particular interest to French civil servants. If you’ve got troubles understanding English, please email [email protected].

Lately, I wondered if it was possible to know about how people working for the French government produce, publish and contribute to open source code. Having a complete picture is nearly impossible, but I could start with something: analysing commits pushed on GitHub by people who used a @* email address.

Gaining knowledge about this subject enables a lot of things: knowing where code is published, meeting fellow developers, building a list of commonly used software, establishing a list of open source software the government contributes to and a lot more.


I used Gh Archive which provides a compressed log file for every hour since 2015-01-01 with GitHub events’ API. Each log file contains all public events (events for private repositories are not available there) which happened on GitHub during this hour. GitHub provides 20+ event types (opening a pull request, writing a comment on an issue, pushing a commit etc). These logs are quite huge: for example it was 500 GB (compressed) for 2015 and 1.07 TB (compressed) for 2018.

I downloaded and processed these log files from 2015-01-01 until 2019-03-31. The total number of rows was 1,523,732,038 (1.5 billion events). I only kept rows when a commit was pushed (the PushEvent event) and the main author committed with a @* e-mail address. This means that we have a row every time someone commits to a public GitHub repository with a @* email address between 2015-01-01 and 2019-03-31.


Getting a list of all commits done by people coding for the French government is incredibly hard, for a number of reasons:

  • A majority on contributions are not made on GitHub or are not even available on the Internet;
  • Some developers use their personal laptop with Git already configured with their personal email address and don’t switch to their government one when coding at work;
  • I know that civil servants don’t always have a @* e-mail address;
  • A very few amount of people commit using their @* e-mail address for now, even if it is recommended in the French government open-source contribution policy (it was recently published in February 2018).

With these important limits in mind, let’s look at the data.


Data: we have a row every time someone commits to a public GitHub repository with a @* e-mail address between 2015-01-01 and 2019-03-31. There is a total of 24,989 commits in the dataset (only).

First, let’s look at the number of commits by month since 2015.

Number of commits by month

Then, let’s look at the number of unique committers by month. I’m glad to notice an upward trend but it’s also very clear that the data is missing a lot of people. According to the data, only 66 people with a @* e-mail address did at least a commit in January 2019 which is way less than the reality.

Number of different people writing commits by month

When do people commit during the week? It was funny to spot a slight downward trend from Monday to Friday. Some people push commits during the weekend but 10x less than during the workweek.

Number of commits by day of week

What time of the day do people push commits? The hour is plotted in UTC but Metropolitan France is UTC+1 or UTC+2. I’m glad to notice a sharp drop at lunch time around noon / 1pm. Eating is super important in France ?.

Number of commits by hour (UTC timezone)

What’s the most common commit messages? I bet on something around wip / fix / Initial commit but I was a bit surprised. To spot people who’re doing a lot of commits, I added a second column with the unique number of authors. We can clearly see people who’re using GitHub’s UI to do a commit: Update or Add files via upload.

Most common commit messages and associated number of authors

Then, I’ve looked at commit repartition by domain name. I know, it’s far away from the reality but I still had to make a table. I kept only major email domains, defined by the total number of commits recorded.

Number of commits by domain by year

Last but not least, I’ve looked at the total number of commits done in a GitHub organisation and the number of unique committers who’ve contributed in this organisation. The first one is the blank organisation: when people contribute to their[username] or[someone] where username and someone are individual users, not organisations.

Organisations with highest number of commits

Finally, I’ve looked at contributions to open source projects which are not published by government. I was glad to found contributions to organisations like mozilla, opendnssec, sagemath, krb5, hibernate, legilibre, qgis, rstudio, TheHive-Project or openstack (in no particular order). The French government open-source contribution policy lets people contribute to open source code during work hours, with their own name and using their government email address. I hope it will be easier to collect these contributions in the future.

Doing the same

The code I wrote to extract the data and the dataset itself is available on GitHub and on with open source licences. I used standard UNIX programs (wget / gunzip / jq), Python and Metabase. If you feel like doing something like this yourself or using the data, feel free to do so! I’d love to hear about it.

What’s next

This is a personal project but I hope it’s just the beginning. I know how frustrating it is to have numbers so low to show for now and how far from the reality this is. I wrote in a previous article (in French) about how I built a list of repositories and organisations where the public administration publishes code. I’m very interested by these topics so I will continue to work on them and write about it.

In order to move forwards, a few things:

  • If you’re working for the French government, use your work email address when publishing or contributing to open source code. Learn how to set your email address in Git;
  • If you’re a public administration, register where you publish your code in this file;
  • If you’re writing or contributing to open source software, first thanks a lot, and please continue to do so;
  • If you’ve got comments, questions or ideas, send an email to [email protected].

I’d like to thank my colleagues Bastien Guerry and Laurent Joubert.

Analyse statistique des répertoires de code des organismes publics en France


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

Top 20 des organisations avec le plus grand nombre de stars

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

Langage principal détecté par GitHub et nombre de répertoires

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

Principales 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 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

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

Nombre de répertoires créés par mois

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.

Serving a JSON REST API without infrastructure thanks to Netlify


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 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:


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.

Assister aux audiences en tant que spectateur au Tribunal de Paris


En France, la justice est publique. Il est donc possible d’assister à un procès, au civil comme au pénal, sauf opposition du juge qui peut décider d’un huis clos dans le cas des affaires les plus sensibles. Auparavant, les audiences se tenaient au Palais de Justice sur l’Île de la Cité, au coeur de Paris. Depuis avril 2018, de nombreux tribunaux sont regroupés à la Cité Judiciaire de Paris, Porte de Clichy. Le bâtiment flambant neuf mesure 160 mètres de haut, comporte 38 étages et accueille 90 salles d’audience.

À l’intérieur du Tribunal de Paris

Assister aux comparutions immédiates

Pour découvrir une audience, rien de mieux que d’assister aux comparutions immédiates. La comparution immédiate est une procédure qui permet de faire juger rapidement quelqu’un à la suite de la garde à vue. Elle est utilisée pour des faits « simples et établis » où une enquête poussée n’est pas nécessaire.

La plupart des salles d’audience du Palais de Justice de Paris comportent deux audiences par jour : le matin à 9h et l’après-midi à 13h30. Au cours d’une même audience, plusieurs affaires peuvent être jugées. Ainsi, si vous assistez à des audiences de comparutions immédiates, vous pourrez suivre plusieurs affaires les unes après les autres.

Une affaire de comparution immédiate dure généralement entre 15 minutes et une heure. Vous êtes libres de rentrer et sortir de la salle quand bon vous semble. Il est interdit d’utiliser des appareils électroniques dans la salle d’audience ainsi que de boire et manger. Les affaires s’enchaînent, les jugements de l’ensemble des affaires d’une session (matin ou après-midi) sont rendus en toute fin de session : vers 12h pour la session du matin et 18h pour celle de l’après-midi.

Au Tribunal de Paris, ce sont les 23e et 24e chambre qui sont en charge des comparutions immédiates. Ceci se déroule dans les salles 2.04 et 2.05, au 2ème étage du bâtiment principal.

La salle d’audience 2.05 où sont jugées les comparutions immédiates

Informations pratiques

  • Adresse : Tribunal de Paris, Parvis du Tribunal de Paris, 75017 Paris
  • Transports en commun : Métro 13 (Porte de Clichy), Tram T3b (Porte de Clichy), RER C (Porte de Clichy), Bus 54, 74, 138, 173, 528, PC3.
  • Horaires : accueil du public du lundi au vendredi de 8h30 à 18h00
  • Sécurité : fouille à l’aide de portiques de sécurité à l’entrée

Plus d’informations sur le site web du Tribunal de Paris.

Collecter et constituer automatiquement et gratuitement un jeu de données open data


Il m’arrive de devoir constituer un jeu de données mais que les données brutes ne soient disponibles que via une API ou qui nécessite un traitement particulier, qu’il faut exécuter de manière régulière. On se retrouve alors à devoir écrire du code pour constituer ce jeu de données et avoir besoin d’exécuter cette logique de manière régulière. Ces besoins requièrent de l’infrastructure, une logique d’exécution périodique (via crontab par exemple) ainsi que du monitoring. Je propose dans cet article une technique permettant de collecter automatiquement et gratuitement des données sans mettre en place d’infrastructure.

Tirer parti de GitHub et CircleCI

L’idée principale est de tirer parti de 2 services clés : GitHub (qui permet l’hébergement de code en ligne avec Git) et CircleCI (outil d’intégration continue). Le code nécessaire à la collecte et à la mise en forme des données sera versionné sur Git et mis en ligne sur GitHub. Ce script de collecte et de nettoyage est ensuite exécuté automatiquement et périodiquement par CircleCI pour constituer un fichier plat (un CSV par exemple) contenant les données. GitHub et CircleCI sont des services qui demeurent gratuit dès que le code source n’est pas rendu privé et est consultable par tous.

Exemple : les tweets de la ligne RER B

Un exemple concret pour appuyer mes propos et s’inspirer du code existant. Mon but est de collecter les tweets du compte @rerb, la ligne RER B à Paris. La récupération de tweets se fait via l’API de Twitter mais l’API ne permet de récupérer que les 3000 et quelques tweets les plus récents. Si l’on souhaite pouvoir remonter avant, il faut alors commencer la collecte maintenant et ajouter les nouveaux tweets au fur et à mesure. Ce répertoire est disponible sur GitHub.

Le fichier Python responsable de la collecte et de la mise en forme des données est, il comporte 50 lignes. Les tweets sont ensuite stockés dans un fichier CSV. Un fichier de configuration YAML, destiné à CircleCI, assure une exécution toutes les heures sur l’infrastructure mise à disposition par CircleCI, garantissant ainsi une collecte dans le temps. Un historique des dernières exécutions est disponible sur CircleCI pour inspecter le bon déroulement des opérations. Le code de collecte utilise des variables d’environnement privées sur CircleCI, garantissant le secret des clés d’API. L’historique des commits permet de suivre la croissance du fichier CSV. Enfin, ce fichier des tweets est référencé sur pour que cette collecte bénéficie à ceux qui souhaitent analyser ces données.


Cette technique permet de collecter automatiquement des données sans infrastructure et gratuitement. Elle assure également la transparence du processus de collecte et de transformation car le code effectuant ce travail est inspectable. Les données ainsi constituées sont finalement disponibles sur le web, permettant une réutilisation immédiate et facile par téléchargement, référencement sur une plateforme ou utilisation par d’autres sites web. Le code source responsable du traitement étant disponible sur GitHub avec une license libre, il est possible de répondre à des questions extérieures ou d’accepter des contributions.

Il faut toutefois noter que dans mon exemple, je me repose sur GitHub et CircleCI, des plateformes SaaS privées. Il est possible d’utiliser des plateformes auto-hébergées et open source, comme par exemple Gitlab et Jenkins. Des alternatives libres sont présentes et fiables, l’idée reste la même.