About

Background, working style, and technical focus across scientific software, regulated R&D, statistics, and internal product engineering.

How I got here

I did not start out planning to become a data scientist. I studied agronomy engineering at Institut Agro - Agrocampus Ouest in Rennes, which is fundamentally about applying science to complex living systems, and during my statistics courses I realised that the analytical side was what excited me most. Not just running models, but understanding why a method works, and what it can and cannot tell you about the real world.

After finishing both my engineering degree and a master's in applied mathematics and statistics in 2021, I joined Astek / IT&M Stats, a consultancy that places statisticians and data scientists inside large R&D organisations. That structure shaped how I work: missions ranging from a few months to nearly two years, each bringing a new domain, a new team, and a new set of constraints. It forces you to get good at context-switching, at earning trust quickly, and at building things that still work when you are not in the room to explain them.

My first mission was at L'Oréal R&I: two years of clinical biostatistics on ingredient efficacy and molecular safety studies. I covered hundreds of analyses, learned what a two-week turnaround really means under pressure, and built internal tooling that helped the team move faster. It was a good introduction to regulated science, the kind of work where you cannot hand-wave uncertainty.

Then Sanofi R&D, where I shifted from pure analysis to building. I designed and shipped a full R Shiny platform to predict and simulate manufacturing plant resource capacity across global sites, driving drug production planning and decision-making, while also taking on the Scrum Master role. That project taught me that useful software is harder to build than merely correct software, and that documentation, workshops, UAT, and handover are part of engineering rather than tasks that happen after it.

After Sanofi came Abolis, a microbiome biotech startup. Six months, full autonomy, multi-omics data pipelines, no hand-holding. Very different energy from a pharma company, and a useful reminder that speed only helps when the foundations are still clear.

Now I am at Chanel Parfums Beauté R&D, working on machine learning, R Shiny applications, and internal data products for fragrance and cosmetics development. Still on mission via Astek / IT&M Stats, but it is the most technically ambitious role so far: production models, app catalogs, platform tooling, and software that scientists depend on daily.

Outside work, I follow One Piece with unreasonable commitment, still make time for video games when I can, and have a lot of time for people who can say "I was wrong about that" and simply update their view.

What I care about at work

Working at the interface, not the edges. The most useful position is between the domain experts and the data and software systems. People who sit purely on one side often build the wrong things. My agronomy background helps here because I can read a protocol, understand an experimental design, and push back when the question being asked cannot be answered with the data available.

Tooling that disappears. The best internal tools are the ones that become invisible because people can just use them. A dashboard that requires a walkthrough every time is a failed tool. I spend a lot of time thinking about UX in scientific apps and internal platforms where it is usually ignored.

Documentation is part of the product. If a tool only works when its original developer is around, it is not finished. I like writing the things that make software survivable: runbooks, architecture notes, qualification-oriented checks, reusable templates, and onboarding material.

Rigor over speed, mostly. Working in pharma and cosmetics R&D means results matter in practical ways: regulatory submissions, manufacturing decisions, and product formulas. I have developed a healthy caution about overfitting, about p-values, and about claims that outrun the data.

Understanding models, not just using them. I am drawn to the mathematical and statistical machinery underneath the tools I use, because understanding assumptions, failure modes, and trade-offs makes the judgment calls better.

Teaching scales teams. I enjoy turning "this only exists in one person's head" into something a team can reuse through internal training, mentoring, and technical writing.

Explainability and the limits of black boxes. In regulated R&D, a model you cannot explain is often a model you cannot use. Beyond compliance, I am genuinely interested in interpretable ML and AI as a more honest representation of what we actually know.

Staying current without being credulous. I keep an active scientific watch across biostatistics, computational biology, and ML engineering. The field moves fast enough that distinguishing between durable tools and interesting experiments requires deliberate effort.

Open source tools and reproducible workflows. R, Python, Quarto, Git, Docker. Reproducibility is not just a preference; it is how you avoid the slow-motion failures that come from work nobody can reconstruct six months later.

Remote collaboration requires explicitness. I work well asynchronously, but I do not confuse remote work with silence. Clear writing, structured decisions, screen-sharing when useful, and explicit feedback loops matter a lot in distributed teams.

Get in touch

Content on this site is licensed under CC BY NC SA 4.0 unless stated otherwise.

Back to top