From design to deployment, I handle it all.

A deployment done by hand is a deployment the team dreads, so it gets postponed. It eventually goes out on a Friday evening carrying three weeks of accumulated change, and nobody can tell which one broke production.

I build a chain that turns a release back into a non-event: a merge, a green pipeline, it's live. The image validated on staging is the one that ships, and the rollback is ready before anyone needs it.

An infrastructure that is slow and expensive rarely has a single culprit. The reflex is to add machines, which treats the symptom at full price and hides the real bottleneck until the next spike.

I measure under realistic load first, then touch only what actually weighs. Elasticity is then wired to the metric that genuinely describes load, and sizing comes back down on everything that was idling.

A system nobody measures is a system whose outage gets reported by its users. And when probes finally go in under pressure, they arrive piecemeal: every service its own format, every team its own tool, and nobody able to tie a slow page back to its cause.

I lay the whole chain, traces, metrics and logs, across the services that matter, behind one collection point that keeps applications independent of the storage. The work stops when an incident shows up on a screen before a user writes in.

"It works on my machine" is the symptom of an environment nobody ever wrote down. While it lives in one person's head and in a server's shell history, every new machine and every new joiner restarts the same investigation.

Containerising writes that environment down once and for all; orchestrating decides in advance what happens when an instance dies at three in the morning. I do both, with the cutover documented.

Secrets almost never leak through a sophisticated attack. They leak through a committed .env, a password pasted into a Slack channel, a former colleague who left six months ago and still has access.

I close those paths one by one. Secrets leave the repository and the images to live in a vault, services read them at start-up, and revoking access becomes a one-minute job.

An application online with no barrier is a public database with a user interface. And a barrier placed only in the front end gives the same result while suggesting the opposite: calling the API directly walks straight past it.

I put the check where it holds, on the server, on every request. Credentials go through the identity provider already in place, sessions stay short and revocable, and every sensitive access leaves a trace.

A database thrown together holds up until the day it has to change or be restored. Both days always come, often in the same month, and that is when the nightly backup turns out never to have been read back.

I put the schema back in order, make changes replayable by versioning the migrations, and verify the backup by actually restoring it.

As soon as volumes become regular or the data is sensitive, sending every request to an external provider gets expensive and questionable. The price tracks usage with no ceiling, and the documents end up with a third party.

I run an open model on hardware we control, sized honestly for the real load, behind a private API. The data never leaves the perimeter, the whole thing is hostable in France, and the cost becomes predictable again.

An AI feature is judged on what it produces, not on the size of the model behind it. Always reaching for the biggest available model means a bill that climbs for quality that is often identical, and with no test set nobody can say whether a change improved anything.

I split the need into tasks and give each one the smallest model that holds it. Calls stay serverless while the volume does not warrant infrastructure, spending is capped, and every change is measured against real cases.

Past two providers, every application starts carrying its own keys, its own call format and its own error handling. Switching model then takes a redeployment, and nobody can say which team is consuming what.

I bring all of it back to a single point. Applications speak one format, routing lives in configuration, and each team gets its own key, quota and cost line.

Data handed to an American service stays subject to foreign law, even when it sits in a European region. And the question never comes alone: there is the hosting, but also the backups, the logs, the tracking tools and the AI models, which often go elsewhere without anyone having decided it.

I stand the whole chain up on French providers, Scaleway, OVH or IONOS, and check that nothing slips out through a side door. It becomes possible to say where every piece of data lives, who can reach it, and to prove it.

A product delivered without its deployment chain or its documentation is not finished: it is sitting on a machine. Whoever picks it up next starts from scratch, and the smallest fix begins with working out how the thing went live.

I build the product and its chain at the same time. Deployment, observability and backups exist before go-live, and the code stays legible for whoever picks it up next.

A badly scoped MVP turns into a full product delivered half-built: too long to make to learn quickly, too incomplete to convince anyone. And with nothing measured once it is live, the test settles nothing.

I start from the hypothesis to validate and cut everything that does not answer it. The rest is written down but not built, v1 ships with its telemetry, and the review comes with numbers.

A dashboard is only worth something if somebody changes a decision after looking at it. The hard part isn't drawing curves: it's that two departments compute the same indicator two different ways, and nobody knows which one counts.

I have each number defined by the people who use it, then write that definition next to the number. Views are built by use, and the refresh is monitored so a dashboard never lies quietly.

A cloud bill that climbs without explanation is nearly always a bill nobody can break down. Until every euro is attached to a service, no optimisation can be arbitrated and the discussion ends in impressions.

I tag the resources so the breakdown becomes possible, then surface cost in the same dashboards as load. Every optimisation is then comparable, and verifiable on the following month's bill.