Expertise
What I can do and how I work.
Data science
In short
Since 2019 I have been turning data into decisions for large energy and telecom companies: forecasts, classification, text analysis, models that go into production. I work in Python and R, from the first exploration to the pipeline that runs every morning.
Time series
Forecasting is at the heart of my work. I deal with what makes real-world series hard:
- Trend changes, seasonality and the influence of external factors.
- Outlier detection, so that a single abnormal period does not distort the whole model.
- Models and frameworks: Prophet, Chronos, AutoGluon and TimesFM.
- Evaluation: MAE, MAPE, MSE and RMSE, plus custom metrics built around the problem at hand, because over-forecasting and under-forecasting rarely cost the same.
Machine learning and deep learning
The models I use, chosen for the problem rather than out of habit:
- Libraries: scikit-learn, PyTorch, TensorFlow, LightGBM, CatBoost and XGBoost.
- Classification on tabular data: logistic regression, random forest, gradient boosting (LightGBM, CatBoost, XGBoost) and NGBoost for probabilistic predictions.
- Deep learning: dense networks (MLP), TabNet, recurrent networks (RNN, LSTM), Transformers and attention, entity embeddings, and CNNs for computer vision (classification, object detection, segmentation).
- Learning to rank: LambdaRank, YetiRank and XGBRanker, when candidates must be ordered against each other rather than judged one by one.
- Probabilistic ranking models: Plackett-Luce and Harville to turn scores into finishing-order probabilities, Elo and TrueSkill ratings.
- Reliable probabilities: calibration (isotonic, beta), conformal intervals (MAPIE) and out-of-distribution detection.
- Tuning and interpretation: Optuna for hyperparameters, SHAP to explain predictions.
Other modelling areas
- Classification and scoring: calibrated probabilities, metrics chosen from the real cost of each kind of error.
- NLP: text classification, information extraction, automatic email processing.
- Reinforcement learning: sequential decisions where an agent learns from the consequences of its actions.
- Econometrics and finance: causal questions, panel data, market data. Backtests without look-ahead, with costs modelled and an out-of-sample period kept untouched until the end.
Data exploration and preparation
Before any model, understanding the data and what it says:
- Understanding the business: where the data comes from, how it is produced and what teams expect from it, by talking to the people who know it best.
- Exploratory data analysis (EDA): distributions, missing values, correlations, breaks and anomalies, with visualisations that expose problems before they distort a model.
- Cleaning: incomplete or heterogeneous data, duplicates, domain-specific edge cases, missing values imputed without using future information.
- Interpretation: linking each finding to its context and reporting it clearly, so that the analysis supports a decision.
- Preparing for modelling: feature engineering from history and context, stable feature selection, always limited to the information available at decision time.
Deployment
- Cloud: putting models into production on GCP and AWS.
- Servers: deployment on Linux servers, containerised with Docker.
- Pipelines: scheduled, automated processing and continuous integration.
- Datamarts: ready-to-use analytical tables for business teams.
Applications
Web applications that put models and analyses in the hands of people who do not code:
- R Shiny in R.
- Dash and Streamlit in Python.
Toolbox
- Languages
- Python
- R
- SQL
- Data
- pandas
- Polars
- NumPy
- Machine learning
- scikit-learn
- PyTorch
- TensorFlow
- LightGBM
- CatBoost
- XGBoost
- Optuna
- SHAP
- Time series
- Prophet
- Chronos
- AutoGluon
- TimesFM
- Data platforms
- Oracle
- Hive
- PySpark
- PostgreSQL
- Deployment
- GCP
- AWS
- Docker
- Linux
- Git
- CI
- Applications
- R Shiny
- Dash
- Streamlit
- Foundations
- Mathematics
- Statistics
- Econometrics
- Computer science
- Finance
AI agents & LLMs
In short
I design, build and deploy tools based on language models: agents that carry out multi-step tasks, assistants connected to internal data, automations that save hours every week. I use them daily in my own work, with the safeguards that make them reliable.
What I build
- Agent-based tools: agents that plan, call tools and check their own results, deployed for real users rather than left as demos.
- LLM applications: integrations with the Claude API using tool use, structured outputs, prompt caching and retrieval over internal documents.
- Skills, tools and MCP servers: packaging domain knowledge as agent skills, and writing tools and Model Context Protocol servers that connect agents to databases, APIs and files.
- Private setups: open-weight models running on a laptop (Ollama, MLX) when data must stay in-house.
RAG
Assistants that answer from a document collection (PDFs, articles) and cite their sources:
- Ingestion: extraction, cleaning, semantic chunking, metadata and embeddings.
- Retrieval: semantic and hybrid search, reranking.
- Evaluation: retrieval relevance, answer faithfulness, answer quality.
- Tools: LangChain, BGE-M3 embeddings and the Qdrant vector database.
Agentic development frameworks
Spec-driven development methods I use with Claude Code and Codex:
- Superpowers: agent skills and a complete development methodology, from design to review.
- BMAD Method: agile development driven by specialised agents.
- GSD (Get Shit Done): meta-prompting, context engineering and spec-driven development.
- Spec Kit: GitHub’s toolkit for spec-driven development.
How I keep agents reliable
- Design before code: the agent starts from a written design and a step-by-step plan that I review.
- Guardrails: tests, type checkers, linters and pre-commit hooks run on every change, so mistakes are caught automatically.
- Verification: no result is accepted without the command that produced it. Numbers are measured, not guessed by the model.
- Explicit rules: project instructions state what the agent must never do, such as using future data in a backtest.
- Evaluation: labelled test sets, comparison with a classical baseline, error analysis. A model that sounds right is not the same as a model that is right.
Toolbox
- Models and platforms
- Claude API
- Claude Code
- Codex
- Gemini
- DeepSeek
- Ollama
- MLX
- Building blocks
- Tool use
- MCP
- Skills
- Structured outputs
- Evaluation
- RAG
- LangChain
- BGE-M3
- Qdrant
- Frameworks
- Superpowers
- BMAD Method
- GSD
- Spec Kit
Anthropic certifications
How I work
In short
I like hard, quantitative problems, and I like explaining them simply. Consulting, teaching and competing have taught me to stay precise under pressure and to get the best out of a team.
Analysis and problem solving
I start from the question, not from the tool. Before choosing a model, I look for the simplest approach that could work and for the evidence that would prove it wrong. Curiosity does the rest: economics, finance, sports science, language models.
Making complex ideas clear
Leading macroeconomics tutorials at the Toulouse School of Economics and training colleagues in R taught me to adapt the message to the audience. I present results to technical teams and to decision-makers alike, and I can explain a confidence interval without a single equation.
Under pressure, as a team
Consulting missions for large companies come with deadlines and demanding stakeholders. I work well in a team: I ask for reviews, I give them, and I flag problems early rather than late.
Attention to detail
Tests, reproducible pipelines, results that can be traced back to the code that produced them. Quality is not a final step; it is part of every step.
Athletic background
In short
I compete in athletics at national level in the javelin. Sport has shaped the way I work: discipline, patience and the habit of measuring progress honestly. I also apply data to training: workload, recovery and performance.
On the field
- Javelin at national level, with handball, swimming, boxing and strength training on the side.
- Competing teaches things no course does: preparing for the one throw that counts, accepting a bad day and coming back the following week.
- It is also where I learned that progress is rarely linear, which is a useful reminder when a model stops improving.
Data at the service of training
- Training load: session RPE, volume and intensity, acute and chronic workload, monotony and strain.
- Recovery: heart rate variability, resting heart rate and sleep, read against the training load rather than in isolation.
- Progress: performance tests treated as measurements with their own noise, so a real improvement is not confused with a good day.
- Planning: periodisation and tapering choices grounded in published research.
Small samples, differences between individuals and the quality of wearable data call for caution: a trend is reported as a trend, never as a diagnosis.