10 ans d’entreprise individuelle

Standard

Il y a 10 ans aujourd’hui, je créais mon entreprise individuelle. J’ai fait 7 années en tant que micro-entrepreneur en activité annexe et 3 années en tant qu’activité principale.

Voici le bilan que j’en tire.

Flexibilité

Le statut de l’entreprise individuelle et de la micro-entreprise offre une grande flexibilité. Elle m’a permis de facturer de 300 € HT par an à plus de 150 000 € HT. J’ai pu exercer cette activité comme un complément de revenus ou en activité principale. J’ai travaillé avec des particuliers, des associations, des entreprises et des administrations. J’ai réalisé de multiples prestations : formations, assistance, maintenance, développement personnalisé, hébergement de systèmes, analyse de données et rédaction de rapports. J’ai apprécié pouvoir travailler avec plusieurs clients de manière simultanée avec des temporalités et des tâches différentes.

J’apprécie cette flexibilité. Je suis heureux de constater que la prise d’initiatives, l’implication dans son travail et l’expérience accumulée paient de manière plus claire que quand j’étais salarié.

Formalités administratives

Les formalités administratives sont très simples initialement et se complexifient au fur et à mesure que l’activité devient plus importante. J’ai constaté la simplification de la réglementation et des démarches entre 2014 et 2024. Il existe désormais de nombreux articles et tutoriels répondant aux questions les plus classiques provenant de sources officielles ou de personnes passionnées.

Protection sociale

J’ai beaucoup appris au sujet de la protection sociale. J’ai effectué de longues recherches pour comprendre le fonctionnement du système de retraite français, ses règles de calcul et des cotisations afférentes. J’ai pris les mesures nécessaires pour me protéger ainsi que mes proches des risques de la vie : maladie, invalidité, décés. Avec mes nouvelles connaissances et les mesures prises, je comprends et je maîtrise mes risques et mon avenir financier. Je me sens en confiance.

Tout ce que je n’ai pas fait

Je n’ai pas fait beaucoup de choses et je n’aurais pas l’audace de revendiquer 10 années d’expérience en tant qu’indépendant ou « entrepreneur ». Je n’ai pas développé ou vendu un produit, je n’ai pas recruté, je n’ai pas de local professionnel ou un matériel coûteux, je n’ai pas de prêt professionnel, je n’ai pas eu de grandes difficultés à trouver mes clients, je n’ai pas besoin d’avoir un grand nombre de clients.

Tout ceci fait que j’estime avoir eu une expérience simplifiée. Que j’ai eu de la chance.

Il y a encore beaucoup de défis à relever dans les années à venir. À dans 10 ans ?

Obligation de réutiliser des données de transport

Standard

Le décret n° 2022-1119 du 3 août 2022 instaure de nouvelles obligations pour les services numériques d’assistance aux déplacements, c’est-à-dire les calculateurs d’itinéraires comme Google Maps, Waze, Mappy, SNCF Connect, Transit etc.

Parmis ces nouvelles obligations, une mesure retient particulièrement mon attention.

Au plus tard le 1er décembre 2022, veiller à intégrer l’ensemble des données sur les services de transport réguliers, et à la demande, mises à disposition sur le point d’accès national 

Au plus tard le 1er décembre 2023, veiller à intégrer l’ensemble des données sur les services de partage de véhicules, de cycles, de cyclomobiles légers, d’engins de déplacement personnels, ou sur les déplacements à pied

Art. D. 1115-19

Cette mesure entend favoriser l’intégration de données de transport en commun dans les calculateurs d’itinéraires. Je pense que vous avez constaté que votre application préférée avait connaissance des lignes de bus ou de métros lorsque vous vous déplacez dans Paris, c’est plus incertain dans d’autres métropoles ou villes moyennes.

Et pourtant, les collectivités réalisent de copieux efforts : elles réfléchissent aux solutions de mobilités à mettre en place, dessinent un réseau, instaurent des fréquences de passages, achètent du matériel, s’assurent que le personnel est recruté et formé etc. L’absence de production et de diffusion de données décrivant l’offre de transport ou son intégration nuit à la fréquentation du réseau.

Ainsi, il est habituel de constater qu’un réseau de transport en commun existe, que des véhicules circulent, mais qu’il soit difficile d’emprunter une telle solution de mobilité, tant l’information est pénible d’accès. On découvre son existence en se rendant à un arrêt de bus et en lisant une feuille imprimée derrière un plexiglas. Trop tard, vous avez déjà pris vos dispositions pour vous assurer de pouvoir vous déplacer.

Réutilisation obligatoire de données en open data

C’est dans ce genre de situations que cette mesure révèle son utilité : elle met en place une obligation de réutilisation de données publiées en open data. C’est quelque chose d’assez rare pour être remarqué. L’open data est souvent vu comme un moyen d’assurer une transparence démocratique (en particulier pour l’accès et la publication de documents administratifs) ou un engagement de l’administration de fournir des données de qualité, avec le service public de la donnée.

Ici, l’usage est novateur et s’apparente à une logique de régulation, visant à assurer une couverture territoriale optimale. Dès lors qu’une autorité organisatrice de la mobilité publie des données de transports sous licence ouverte d’une qualité suffisante et régulièrement mise à jour, les calculateurs d’itinéraires auront l’obligation d’intégrer ces données. On est loin des mécanismes habituels où les publications open data sont effectuées pour être en conformité, répondre à une demande ou par posture idéologique.

C’est un levier efficace pour faire connaître son réseau de transport. Si un plus grand nombre de réseaux de transports en commun sont intégrés dans des calculateurs d’itinéraires, on pourra plus facilement planifier des déplacements liant plusieurs modes de transport et empruntant différents réseaux. Fini la suggestion d’emprunter un train, d’arriver à une gare et ensuite de se débrouiller pour parcourir les 15km restants.

Une responsabilité partagée

Pour arriver à cette vision, l’implication de nombreux acteurs est nécessaire :

  • Les autorités organisatrices de mobilité : doivent publier des données décrivant les offres de mobilité qu’elles ont mis en place sur leurs territoires. Ces données doivent être d’une qualité suffisante et mises à jour régulièrement. En échange de ce travail, le potentiel de réutilisation et d’impact est notable : leurs données seront intégrées et affichées aux utilisateurs qui cherchent à se déplacer sur leurs territoires.
  • Le point d’accès national aux données de transport : doit informer les différents acteurs de ces changements réglementaires, aider l’écosystème à respecter ces obligations et mettre en place des mécanismes permettant d’évaluer que des données sont d’une qualité suffisante et mises à jour de manière pertinente (tel qu’indiqué dans l’arrêté accompagnant le décret).
  • Les calculateurs d’itinéraires : doivent être en mesure d’intégrer plus de données qu’actuellement, pour des territoires moins peuplés et avec un niveau de qualité et de mise à jour hétérogènes.

Un beau défi à relever dans les mois à venir !

Compter du carbone

Standard

La voiture s’arrête dans l’allée. Le petit écran du tableau de bord défile : 17h45, 22 degrés, 6,2 litres/100km, 9h30, 180kgCO2e, France Info. Ça fait un pincement au coeur d’être de retour à Paris. Une semaine à Nice, c’était bien mérité.


Si vous relisez toutes les unités présentes dans le paragraphe précédent, est-ce que vous vous représentez tout ? Chaud/froid, petit/grand, abordable/hors de prix, lent/rapide. Tout ça, vous connaissez bien. Quand on en parle, ça se matérialise.

Et maintenant, 180kgCO2e, vous en pensez quoi ? Ça a l’air barbare, voire barbant. Est-ce que ça représente beaucoup d’émissions ? Est-ce que vous pouvez émettre ceci avec votre corps humain en quelques minutes ? Est-ce que vous pouvez vous débarrasser de ce problème pour 10 € ? Pas facile de savoir tout ça. C’est même relativement déroutant d’avoir tant de difficultés à l’associer à d’autres choses.

Et pourtant, vous le savez : l’écologie c’est important. Tendance. Certains essaient de changer vos habitudes en utilisant ce mot. C’est une chose de plus à prendre en compte. C’est un élément qui déterminera les modes de vie dans le futur, l’équité sociale, la fréquence de catastrophes naturelles, la sécurité publique, le vivre ensemble.

Alors, on s’y intéresse ? Heureusement qu’il y a des outils pour avoir des équivalences. 180kgCO2e c’est 25 repas avec du boeuf, 933 km (de Paris à Nice) en voiture thermique, 10 jours de chauffage au gaz ou 100 000km en TGV en France. Là, on commence à comprendre. On commence à compter ?


Cet article est inspiré des discussions avec Maël Thomas et en particulier de ses réflexions récentes sur la représentation des chiffres climat.

Ask questions during interviews

Standard

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

Standard

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 notification.canada.ca, 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

Standard

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

Standard

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.

Recruter

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

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

Standard

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

Standard

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, data.gouv.fr.

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.

Documentation

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

Standard

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.

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

Cons/goals

  • 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!