Ask questions during interviews


I’ve been conducting interviews at the Canadian Digital Service for software and site reliability engineers these last few months. My most important advice to candidates would be to ask questions during interviews when offered the opportunity to do so. Not just 2 random things popping up on your mind when you’re given the opportunity. I believe that asking questions will help you a long way towards being hired.

Asking questions will help you in the following ways:

  • stand out as a candidate: if you’ve got more questions and if those are well thought, you will stand up compared to others
  • confirm if you want to work here: if you ask questions, answers will comfort you (or not) when you’ll need to decide if you want to work here or not. I’m sure you heard that interviews should be “two-way” and questions play an important part in that.
  • get a better position/offer/benefits: if you show interest in the mission, communication skills, transparency, management or leadership on top of your core skills, you’ll likely get better grades which may help you land a better position, a better offer or more benefits. Salary negotiation is not the last step in the journey, it starts at the beginning.

Preparing questions

You should prepare a list of questions before your interview. Start a new document (or pick a piece of paper if that’s your style), read everything you can find online about where you applied (website, social media, Wikipedia, newspapers) and Google around. Tailored questions will grant you bonus points. You’ve done the research, time to show it.

Examples of questions

Here are some examples of questions I asked or I wrote down before interviews in the past. Feel free to reuse those!

  • What are your current challenges?
  • What’s your latest success?
  • What do you want to do better?
  • I’ve noticed you often emphasize on accessibility/diversity/inclusion. Can you share examples of this?
  • Do you inspire others? How so? Who inspires you?
  • Do you speak at/host technical events (meetups, conferences etc.)?
  • Can you explain what this team is doing? What’s the difference with <other team>?
  • I notice you don’t have a lot of people working on <this team>. Can you explain why?
  • How am I graded during interviews? How are you evaluated as an employee?
  • How do you know that your product meets user needs?
  • Can you share some data about a recent employee survey you conducted?
  • What are your company values? Do you think those are met?
  • What was your latest production incident?
  • What are some of your recurring meetings?

You will find an endless list of questions online. You can look at those to get some inspirations but a few tailored questions will go a long way. If you feel like you didn’t get enough time to ask questions, follow up by email afterwards or ask to schedule another chat to go through those.

Good luck!

Time to production


If I’m a user of your product and I’m reporting a simple bug by contacting you, how much time does it take to deploy a fix to production?

As the current Tech Lead of, a government platform, I can reasonably say that it should take us less than a business day. This number is “business as usual”, we can go to as low as 15-20 minutes for urgent fixes. And I’m pretty proud of this number. Being able to deploy a quick fix (say less than 20 minutes of work for a developer) to production in a matter of hours speaks a lot about your organisation, your infrastructure, tools and your processes.

To be able to achieve this in a matter of hours, you should:

  • have a team working full time on your product. If your product is in maintenance mode and you have to fill in documents, fax it to another department and have lunch with another director to get your budget approved, your timeframe is in weeks (months, anyone?), not hours.
  • be user-centric. The non-bullshit version of it. Writing that you care about your clients on your corporate website isn’t going to be enough this time. You have to have product people looking at support requests coming in, or a close feedback loop between your support team and your product managers/developers.
  • have reliable automated tests. Are you ready to risk shipping stuff without tests you can trust to please someone? You’re a fool. Are you still doing it but have no fears? Great, you have an automated test suite you can trust. You rely on it every day to deliver value to your users quickly while minimizing tedious work to make sure features work as intended and there are no regressions.
  • leverage continuous integration and continuous deployment. Turns out DevOps are not just costly developers who don’t like CSS after all! Seems like they took the time to put in place tools and processes enabling you to do changes in a staging environment and then to production, without downtime, without fears and without humans plugging in USB sticks in a server room. And if it doesn’t work as intended, you can roll back in minutes without any fuss, right?
  • Have a streamlined approval process. Everybody agrees that this change makes sense but yeah, sorry add it to the list of things we’ll get our board to review and approve for the next trimester. Why? Another developer approved a pull request, this change had tests and a product manager could even take a quick look at a review application that was created automatically to check that it works. Why should it be more complicated?

So I’m asking you this question: how much time does it take to release a straightforward fix to your production environment? Are you proud of it?

Astreintes au gouvernement du Canada


En tant que développeurs, il est parfois nécessaire d’être disponible en dehors des heures de bureau, la nuit ou le week-end pour intervenir en cas de problème urgent. On parle d’astreintes ou d’être on-call. Comment ces astreintes sont-elles rémunérées au gouvernement du Canada ? Ceci est défini dans la convention collective des employés du groupe “Systèmes d’ordinateurs”.

Quand un employé ne travaille pas mais est à la disposition de l’employeur et se tient prêt à travailler si nécessaire, il est compensé à raison de 30 minutes par période de 4 heures d’astreinte. Si un employé doit intervenir, il est payé en heures supplémentaires avec un minimum de 3 heures par interruption. Les heures supplémentaires sont payées x1,5 pour les premières 7,5 heures puis x2 ensuite.

Les astreintes sont généralement d’une durée d’une semaine entière, par exemple du lundi 9h au lundi 9h de la semaine suivante. Une telle semaine correspond à 130 heures d’astreinte et 37,5 heures travaillées, soit une rémunération supplémentaire de 16,5 heures si l’employé n’est pas appelé durant son astreinte. Ces heures peuvent être payées ou donner lieu à des congés supplémentaires, au choix de l’employé.

La convention collective prévoit également des compensations s’il est nécessaire de se déplacer et de rembourser des repas si l’employé travaille plusieurs heures d’affilée.

Au revoir chère administration française


C’est ma dernière semaine de travail pour l’administration française. Voilà un peu plus de 2 ans et demi que je suis passé de l’autre côté, du privé au public. Une première année à travailler aux affaires maritimes pour améliorer le sauvetage en mer, et le reste du temps à Etalab, en charge de la politique des données en France. Voici plusieurs choses qui m’ont marqué.

Un meilleur citoyen

La première chose que je retiens est qu’avoir été un agent public a fait de moi un meilleur citoyen. J’ai l’impression d’avoir beaucoup grandi en comprenant en profondeur le rôle des institutions, la séparation des pouvoirs, les sources de revenus et les dépenses de l’État, la gestion des politiques publiques. C’est un milieu extrêmement complexe mais je l’appréhende désormais bien mieux qu’il y a quelques années. Je ne pense pas que la lecture d’un livre ou mes anciens cours d’éducation civique aient pu remplacer l’expérience de travailler dans la fonction publique d’État pendant plusieurs années. J’ai aussi eu l’immense plaisir de visiter quelques bâtiments qui marquent l’histoire de l’administration française : l’Assemblée nationale, la Cour des comptes, le Mobilier National et plusieurs hôtels particuliers et ministères. Un patrimoine immobilier qui fait la fierté de la France, emplis de moments forts.

Une grande famille

J’ai eu le privilège d’échanger avec des métiers que je ne côtoyais pas, des métiers marquants, au service des citoyens. J’ai beaucoup retiré des échanges, aussi courts soit-il, que j’ai eu avec des pompiers, militaires, marins, pilotes d’hélicoptères, magistrats, juristes, personnalités politiques et élus. En tant qu’ingénieur en informatique, ces métiers sont très éloignés de mes collègues ordinaires, j’en ai donc tiré une richesse particulière.

J’ai eu l’impression d’appartenir à une grande famille, celle de la fonction publique. J’avais 5,65 millions de collègues, et je me suis souvent senti bien peu utile par rapport à d’autres. J’ai eu des périodes où j’avais du mal à me convaincre que mon travail été aussi nécessaire que des salariés de l’éducation nationale, des hôpitaux, de la recherche ou des secours. J’ai parfois eu honte de mon très bon salaire comparé au salaire des autres, contraint, figé, exerçant leurs métiers dans des conditions de pénibilité bien loin des miennes. Dans tous ces moments, je me suis rappelé que le premier mandat était d’aider les citoyens et j’ai souvent dédié du temps et de l’énergie à faire en sorte que d’autres agents puissent réaliser cette tâche dans de meilleures conditions. Ça n’a pas pour autant répondu à tous mes questionnements.

Analyser des données et mettre à disposition des autres

J’ai eu l’honneur de travailler avec des données d’exception. Des données produites par l’administration, réservées à son usage car contenant des secrets, ou qui devraient être mises à disposition de tous. J’ai mesuré la responsabilité que je portais : analyser de manière adéquate ces données afin de faire évoluer des politiques publiques et faire le nécessaire pour que ces données soient mises à disposition de tous sans contraintes, dès que possible.


Le recrutement est un sujet qui me tient à coeur. J’ai participé au programme Entrepreneurs d’intérêt général dont le but est d’ouvrir l’administration à des talents du numérique. J’ai organisé un sondage pour mieux connaître les attentes de professionnels qui envisagent de rejoindre l’administration. Je pense que l’administration française a une marge de progression importante concernant le recrutement de contractuels, pour les métiers du numérique. Sur la forme des contrats (le recrutement en CDI ou la transformation d’un CDD en CDI est quasi inexistante), la rémunération (aléatoire d’une structure à l’autre, parfois déconnectée de la réalité du marché) et la possibilité de faire du télétravail (un décret fixe un maximum de 3 jours par semaine pour le moment).

Il existe également la possibilité de travailler en freelance, pour s’affranchir du plafond d’emploi d’une structure (le plafond d’emploi fixe un nombre maximum de personnes employées, toutefois on peut utiliser du budget pour rémunérer des prestataires). Dans cette situation, j’ai l’impression que l’argent public n’est pas utilisé à bon escient à payer un développeur prestataire entre 600 et 800 € HT / jour. Quand ce n’est plus, lorsque la personne est portée par une structure intermédiaire. Il me manque sûrement des connaissances dans les finances et les marchés publics pour comprendre ce scénario.

J’ai eu le désir d’inviter des connaissances à rejoindre un temps la fonction publique. Pour participer à des missions intéressantes, améliorer la société, s’ouvrir l’esprit. J’ai eu un mal fou à les diriger vers des offres pertinentes (trouver des offres tout court ! Je connais la PEP, oui), les rassurer sur la forme du contrat qu’ils pourraient avoir ou le salaire qui serait proposé. C’était pour moi une source de frustration et je regrette de ne pas avoir compris complètement la justification de cette situation. Mais surtout, ce qui me chagrine c’est de trop rarement avoir la possibilité de faire des produits utiles au sein de l’administration, en recrutant des personnes compétentes et motivées.


Merci pour l’opportunité. Merci de m’avoir donné la possibilité de progresser dans mon métier et d’en apprendre tant sur le rôle de la fonction publique. Merci à toutes les personnes rencontrées, les nouveaux amis, les agents dévoués. Merci d’assurer la continuité du service public.

Je sais dorénavant à quoi servent mes impôts, à quel point l’administration c’est compliqué, mais à quel point c’est utile et tout ce qu’on peut encore améliorer.

Collecting and storing data without infrastructure


Over the last few months, I’ve used multiple times a pattern to collect data and store it, without infrastructure. It comes handy when you need to build a dataset by running a script on a regular basis and saving things to a file. Often, I need to scrape data from a 3rd-party website (webpage, API etc.) on a regular basis (up to multiple times per hour) and store the resulting data over time in a tabular file.

If you’ve already infrastructure in place, typically a workflow management platform like Apache Airflow, I recommend using it instead. But if your need is relatively simple and isolated, you should consider this approach.

My pattern is to leverage Git and a continuous integration platform. The cloud version of this pattern is to use GitHub and GitHub Actions. The Git repository will hold your script to fetch and store the data, and you’ll also version your tabular file (fancy name for a CSV) in it. You’ll then schedule jobs on your favourite continuous integration platform to run this script, which will take care of computing data and storing it. After this, all you need to do is to git commit and git push to version your data over time in the Git repository.

From here, you have:

  • your code to compute data and store it;
  • a continuous integration configuration file to run your code on a regular basis;
  • a log of your continuous integration runs;
  • a trail of tabular files, with the latest version always up to date on your master branch.

If you’re using GitHub and are okay about exposing your code and data, you can have all this for free! You’ve got access to compute and storage without thinking about infrastructure. If you don’t want to expose your code or your data, you can run this on a private repository or your own infrastructure.

Now that you have your data in a Git repository, nothing prevents you from publishing it over HTTPS or building a simple read-only API based on your files. The most simple way to do this is to leverage GitHub Pages or you can use Netlify to serve a more advanced JSON API as I’ve written before.

Example repository

If you’re interested in this pattern and want to look at how to get this running, I’ve made recently a repository doing exactly this. A Python script fetches data from a JSON endpoint and appends the data in a CSV file. What’s valuable is the resulting time series, if you run it often and for multiple weeks. Take a look at the repository, especially the GitHub Actions workflow and the Python script.

PS: Git may need be your best choice when storing large data files. In that case, take a look at DVC – Data Version Control.

High-quality open data: the making of the French sea rescue operations dataset


In 2018, I was working at the French maritime affairs, part of the Ministry of Ecology. France has the second largest sea territory in the world. It carries out 13,000 missions / year, saving ~5,600 people and assisting 14,500 more people. Sea search and rescue as well as assistance missions led to the engagement of 10,500 vessels and 1,500 helicopters or planes.

The SNSM (national society for sea rescue) and Marine Nationale out at sea

One of our goals was to improve knowledge and the collaboration among the numerous actors involved in the sea rescue process. One of the first proposition to achieve that goal was to open the sea search and rescue data. The goal was to make raw data for everyone to use, without constraints. We published more than 250,000 sea rescue operations carried out since 1985 in July 2018 on the French’s official open data platform,

To me this dataset can be considered a “high quality open dataset”. I will now explain in further details how it was made.

Raw data

Even on a politically sensitive subject like sea rescue, we chose to publish raw data about the alert, ships involved, weather details, precise localisation, ships, vehicles or helicopters engaged, as well as what happened to the various people involved. One row per operation, in 4 tables, totalling 120 columns. It gives enough information, even for professionals and agencies, while taking into account national security and data privacy.

Designing for reusers

The original database schema was made of close to 30 tables. Acquiring the data from various actors involved in sea rescue was challenging because of the differences in technical vocabularies. We needed to build a simple schema to merge the information that everyone could easily understand

We ended up with just 4 tables, without loosing crucial information. Out of the 4 tables, 3 are raw data, as filled by agents during and after operations. The last table uses data already available in other tables and makes it more convenient to use: we perform common aggregates, filters or add convenience columns: splitting dates, converting units, adding bank holidays, sunset times etc.

As publishers, we used this dataset a lot for our own analysis. The same dataset is used internally to prepare reports, investigate new regulations and prepare prevention actions. We matured the documentation and schema by training people to perform queries on this dataset. People asked clarifications, suggested new columns or reported unclear documentation. Working in close collaboration with the sea rescue experts helped us a lot to improve the dataset quality.

Open source processes

Our data is made available online, with an open licence in the end. But what about the code written for extraction and transformation? We thought it was important to make this code open source, so that people can see how we build the dataset, can report bugs or suggest improvements. The code is published on GitHub. We benefited from this choice: people got in touch with us through this medium and knowing it was made available publicly, we felt more accountable.

In this repository, we publish the code written to extract the original data from an Oracle database, transform it, add columns, join with other datasets and prepare final files, which will end on the open data platform.


Good open data comes up with a documentation. Right? We tried to follow this principle and went a bit further. In the web documentation, we explained how sea rescue works in France, how people are asked to fill forms when the situation is unclear, changes to the dataset are linked to the relevant code commits, schemas, tables, unique values in key columns, sample queries etc.

We felt all these pages were important and useful to deal with the complexity of the data, reflecting the reality of sea rescue operations.

UML schema describing how tables fit together

Software engineering and open data

We tried to use modern software engineering practices for our open data principles. For us, it means: version control, pull-requests with reviews, tests, pipelines, monitoring, continuous integration, data quality checks. For example, tests make it impossible to have an extra column without documentation or without an end-to-end extraction/transformation test in place. Before publishing new data, we also perform general quality tests to prevent serious regressions.

One of the transformation pipelines, using Apache Airflow

Thanks to this, we are able to publish with confidence this dataset daily, just the day after a mission happened.

We believe it is quite unique to publish an accidentology open dataset on a daily basis, without human interaction needed, at a country level.

Interactive map

Not everyone is comfortable using CSV files with hundreds of thousands of lines. Most people want to apply some filters (specific operation types, people involved, date, zone) and see common stats. As sea rescue operations are geographic data, it made sense to offer an interactive map. We decided to make this interactive map available on the Internet, without restrictions.

Interactive map of French sea rescue operations

It makes it much easier for people to give a quick look at the data. People can apply filters, explore and then download the unique dataset they see on their screen for further investigations.

As with the raw data, the map is open source, a documentation is available. When people export from this app, the schema is the same than the open data dataset.


Moving to Canada


I’m moving to Montréal, Canada ??!

It’s quite a change after living for the last 4 years in Paris. We decided to move Manon and me, for multiple reasons:

  • We both wanted to live outside of France for at least a few years. I already lived in the UK, Manon in the USA, now was our chance to live elsewhere together
  • Manon got her PhD in late 2019 and needed to work in another country for her research career

But why Montréal? We didn’t want to stay in Europe, it was too close to France and we wanted to live further away. We went on holiday in the Québec province in 2017 during 3 weeks and we liked it a lot. It’s also an important city for machine learning. Finally, it has a vibrant international community and the Québec province is very close in term of culture and social benefits to France.

Moving to another countries involves a lot of planning and changes. I’ve tried to draft a list of pros/cons and goals.


  • Discovering another country and culture. Fitting in. I’m very happy to discover in depth a non-european culture. As a public servant, I’m also looking forward to understand how Canada works in terms of government, politics and policies.
  • Speaking English. Bilingualism is important to Canadians, and this is something I’m attached to as well. Most canadians are native English, I’m native French so for me it’ll be a chance to get better at speaking English. And speaking québecois as well!
  • Traveling in America. While living in Europe, we’ve explored mostly european countries, while going once or twice to America or Asia. I’m looking forward to traveling in America, there is much to do!
  • Different weather, as Canada is known for its cold winters. For now, I find it really enjoyable: Montréal under the snow is beautiful and it’s sunny and dry!
  • Discovering new food.


  • Moving to another flat, filling administrative forms. I don’t find packing stuff, moving out, looking for a flat, ordering furnitures really enjoyable. We also had a ton of administrative things to take care of (immigration, health insurance, banks etc). It has been often long and stressful.
  • Staying connected to family and friends
  • Meeting new people, making new friends
  • Having enough time off to travel

I’m looking forward to being a proud canadian resident and enjoying our time here!

Asynchronous weekly retrospectives


In 2019, I worked on a team where we had to keep an eye and help 15 projects, carried out by 2 or 3 people each, each one in a different government department, spread out in Paris. We were 3 doing this job, and these projects were part of the same cohort.

It was important for us to know what was going on, at least on a weekly basis, and everyone wanted to know what the others were up to. In corporate land, this need is called reporting, and it’s usually very cumbersome, ineffective and boring. We tried to do it differently and came up with a new process: we imagined and built a specific tool for this.

It’s called Bulletins.

What is it

Bulletins is a weekly retrospective tool for multiple projects or teams. It lets people reflect on their past week with 4 questions which can be answered super quickly:

  • What’s the team mood?
  • What were the main goals this week?
  • What worked great and what was harder?
  • Do we need help?

It’s asynchronous and transparent at its heart. All teams can fill their retrospective when they want through a simple web interface, as long as it’s before Friday 3 PM. On Fridays at 3 PM, everyone gets a weekly recap email with all filled retrospectives. The web interface lets everyone browse through previous retrospectives by week or by team. It comes with email and Slack integrations.

What does it look like

Filling out the weekly form

Browsing through previous bulletins by team

What tool is this

We imagined and built it. It’s a simple Laravel application, available as an open source software, released under the GNU Affero General Public License v3.0 (AGPL v3.0). The interface is translated in English and French.

There is an extensive documentation online, going through the various features, deployment, configuration and more details. It runs on a very light container: 50 Mo of RAM is enough.

For you

I think this tool can be helpful for you. Weekly retrospectives are very common. If you’re interested by asynchronous workflows, owning your data, archiving it, sharing it with others, Bulletins is here for you.

I’d be happy to know if you’re using it. You can also get in touch with me if you’d like to deploy it at work and you’d like some help.

Grèves à la SNCF et à la RATP : modalités de remboursement


La France subit un mouvement de grève interprofessionnelle depuis le 5 décembre 2019. Les transports ferrés sont particulièrement affectés en conséquence des absences de personnel à la SNCF et à la RATP. Que prévoit le contrat des transports collectifs en Île-de-France en cas de grève ? Quelles sont les modalités de remboursement ?

Inutile de faire des réclamations

Les transports ferrés en Île-de-France sont assurés par la SNCF ou la RATP pour les métros, trams, RER et Transilien. C’est Île-de-France Mobilités qui organise les transports dans la région Île-de-France et qui stipule les modalités de mise en oeuvre dans divers contrats (plan de transport, information voyageurs, travaux, situations dégradées). La SNCF et la RATP ne vont pas au-delà des clauses des contrats auxquelles elles sont soumises : les contrats spécifient les modalités de remboursement en cas de grèves. Ainsi, il est peu utile de chercher à obtenir un remboursement en effectuant une réclamation à titre individuel.

Engagement de service en cas de grève

Je me suis intéressé au contrat liant Île-de-France Mobilités et la RATP pour la période 2016-2020, que l’on retrouve en intégralité en ligne. Le contrat liant Île-de-France Mobilités et la SNCF est similaire et vous pouvez le retrouver en ligne également.


En cas de grève, l’article 25 reporte la responsabilité des grèves du personnel sur la RATP.

Les grèves du personnel RATP sont de l’entière responsabilité de la RATP, qui en assume les conséquences en termes de production d’offre et en termes financiers.

Niveau de service

Lorsque la RATP n’est pas en mesure d’assurer le plan de transport prévu en conséquence de grèves du personnel, le contrat donne priorité au maintien du service sur les heures de pointe sur chacun des sous-réseaux (comprendre des différentes lignes).

en cas de perturbations significatives résultant d’un préavis de grève pour un jour donné, lorsque le service prévisible est inférieur ou égal à 75% du service contractuel de référence sur un ou plusieurs sous-réseaux, la RATP s’engage à maintenir un niveau de service d’au moins 50% du service normal pour chacun des sous-réseaux aux heures de pointes.

Le plan de transport proposé par la RATP est approuvé par le STIF.

Ceci est spécifié dans l’article 26 du contrat.


Nous abordons maintenant l’enjeu de toutes les interrogations : le remboursement. Vous n’avez pas pu vous déplacer, l’absence de transport vous a causé beaucoup de tracas, vous souhaitez obtenir réparation. L’article 27 pose les principes.

la RATP s’engage à rembourser les voyageurs en cas de défaut d’exécution du plan de transport adapté ou du plan d’information lorsque la RATP est directement responsable de ce défaut d’exécution. Ce remboursement est à la charge de l’entreprise.

Le contrat renvoie à l’annexe I-C-2 pour les modalités de remboursement. Il prévoit un remboursement partiel ou total lorsqu’un client n’aura pas pu utiliser son titre de transport en raison de l’exécution d’un plan de transport non satisfaisant. L’inexécution du plan de transport sera appréciée par sous-réseau.

Les clients sont remboursés en fonction des titres dont ils disposent. Il y a deux cas :

  • les abonnements : ils sont remboursés au prorata du nombre de jours d’inexécution. Pour les abonnements mensuels, c’est une fraction du nombre de jours dans le mois, à l’année une fraction du nombre de jours sur 365 jours. Pour les forfaits mois et semaine, il est prévu une réduction des prix des abonnements en vente dans les périodes suivant la grève. Pour les abonnés annuels, il est prévu une réduction des mensualités.
  • les billets : le contrat ne prévoit pas de remboursement car les billets sont valables sur une longue période.

Ainsi, pour un abonné Navigo annuel, on peut s’attendre à un remboursement de 2,27 € / jour (sur la base d’un prix annuel de 827,20 € pour les abonnements toutes zones). Pour un Navigo mensuel, la réduction sera aux alentours de 2,40 € / jour.

L’annexe précise enfin qu’il est possible de faire une réclamation directement auprès de la SNCF ou de la RATP, sans garantie de succès.

En cas de manquement marginal dans la mise en œuvre du plan de transport ou du plan d’information, le client pourra, s’il le désire, adresser une demande de remboursement.

Dernièrement, il est utile de préciser que Île-de-France Mobilités peut négocier avec les transporteurs pour mettre en place des mesures compensatoires qui vont au-delà des clauses du contrat.

Analyse des mouvements de grève à la SNCF depuis 1947


Plusieurs syndicats de la SNCF ont déposé un préavis de grève reconductible, à partir du 5 décembre 2019. À cette occasion, je me suis intéressé à l’évolution quantitative des mouvements sociaux à la SNCF depuis 1947. Les données des mouvements sociaux des 10 premières années de la SNCF (entre 1937 et 1947) ne sont pas disponibles actuellement. Cette analyse est basée sur le jeu de données « Journées perdues lors de mouvements sociaux chaque année depuis 1947 » mis à disposition par la SNCF en open data.

Une nette diminution des effectifs

Évolution des effectifs en équivalent temps plein à la SNCF entre 1947 et 2018

Le résultat est spectaculaire : l’effectif de la SNCF suit une nette tendance à la baisse depuis 1947 avec une diminution drastique des effectifs en équivalent temps plein. On dénombrait 471 325 ETP en 1948 contre 142 236 ETP en 2018 ; une division par 3,3 des effectifs en 70 ans.

Pour prendre en compte ce facteur dans les analyses, on s’intéressera donc au nombre de jours de grève par agent, résultat du rapport entre le nombre de jours de grève comptabilisé sur une période et l’effectif à disposition sur cette même période. Il permettra d’apprécier la manière dont les mouvements ont été suivis.

Chiffre clés sur les grèves à la SNCF

Entre 1947 et 2018, on dénombre :

  • un total de 29,7 millions de journées de travail en grève ;
  • une moyenne de 1,5 jours de grève par ETP et par an ;
  • 39 années (54 % de la période) où le nombre de jours de grève par agent est inférieur à 1 ;
  • 4 années de grèves marquées, où le nombre de jours de grève par agent était supérieur à 5 (les années 1947, 1953, 1968 et 1995).

Principaux mouvements sociaux

Les 5 années où les mouvements sociaux ont été les plus suivis sont les suivantes :

  • 1968 (grève générale française), avec 14,63 jours de grève par agent
  • 1953 (statut et retraite des fonctionnaires), avec 7,52 jours de grève par agent
  • 1947 (hausse des salaires et plan Marshall), avec 6,49 jours de grève par agent
  • 1995 (retraites et révision du statut), avec 5,82 jours de grève par agent
  • 2018 (disparition du statut de cheminot), avec 4,69 jours de grève par agent

En regardant les principaux mouvements sociaux, on constate que sur les 10 années les plus suivies, 5 se sont produites depuis 1995.

10 principales années de mouvements sociaux à la SNCF entre 1947 et 2018


Fait-on plus grève qu’autrefois ? J’ai tenté de répondre à cette question en m’intéressant au nombre de jours moyen de grève par agent par période de 5 ans. On obtient le graphique suivant.

Nombre de jours moyen de grève par agent par période de 5 ans entre 1947 et 2018

En se rappelant que la moyenne annuelle du nombre de jours de grève par agent est de 1,5, on constate que depuis 2005 on a tendance à avoir plus de mouvements sociaux suivis et plus réguliers.