I build the front door. Then I help everyone use it.
Today, I'm Tech Lead IAM & Cloud Security at . With my team, we designed
the IDM/IDP platform at the core of Lectra Cloud and we run and evolve it. It secures
100+ highly available microservices across R&D.
Beyond the architecture itself, I act as a technical referent for identity and access management.
I guide customers and R&D teams through the OAuth2 and OIDC flows they rely on every day, and translate IAM
stakes into value that non-technical stakeholders can act on.
Teaching the mental model before the flows (audience, delegation) helps teams understand
what they're doing and make the right design choices.
Side note — Primer
What is a digital identity?
Online, you are never who you are. You are what a system is willing to believe about you.
That trust is built from fragments: an account here, a sign-in there, a badge issued by your employer,
a token handed from one service to the next. A digital identity is the thread that ties those fragments
together, and the rules that decide who may vouch for it, who may rely on it, and for how long.
A digital identity isn't a person, it's a representation: a stable identifier, attributes attached
to it (name, email, role, organization), and credentials that bind you to that record: a password,
a passkey, a second factor. Each application only ever sees a projection of it, and one person holds
many: employee, customer, administrator.
02 · Stakes
When identity breaks, everything behind it breaks too.
Security
Identity is the primary attack surface. Phishing, credential stuffing and session hijacking go for the front door, not the walls.
Privacy
Share only what's needed: minimal claims, explicit consent, GDPR by design.
Continuity
When the identity provider is down, everything is down.
Experience
One account, one sign-in, everywhere, without trading away security.
03 · OAuth2
Delegate access. Never hand over the keys.
OAuth2 answers one precise question: how can an application act on your behalf without ever knowing
your password? Instead of a secret, the authorization server issues a token that is scoped, short-lived
and bound to an audience. OAuth2 authorizes; OpenID Connect adds the layer that authenticates.
In the platforms I build
Authorization Code + PKCE
Users signing in to web and mobile apps
Client Credentials
Service-to-service calls across 100+ microservices
Device Flow
Connected devices without a keyboard
Token Exchange
Propagating identity between services without widening privileges
RBAC / TBAC
Authorization stays in the business domain, not in the vendor
Keeping DevOps a genuine culture of collaboration, not a label on a job title.
AI at Scale
AI makes every developer faster. My job is making sure they all speed up in the same direction.
AI multiplies team velocity. Without a unified, robust architectural vision, it multiplies divergence too:
conflicting patterns, security reinvented team by team, compounding debt. Developer support and enablement
become the bottleneck, and they no longer scale through people alone. The answer is self-service: skills,
MCP servers and tooled golden paths that encode expertise, so every developer, and every agent, applies
the right standards without waiting for an expert.
01
Vision
One reference architecture, explicit and enforceable.
02
Self-service
Experts step out of the critical path.
03
Skills & MCP
Expertise encoded, consumable by humans and agents alike.
And every one of those agents needs an identity...
Favorite Stacks
No stack loyalty. Pragmatism over dogma, and the right tool for the right job.
Where I've Been
Eighteen years, five chapters.
2016 → Now9 yrs 11 mos
Senior Cloud Engineer, Tech Lead IAM & Cloud CyberSecurity
Cestas, France
Tech Lead Backend IAM & CyberSecurity within Lectra Cloud R&D. I design and continuously
evolve the IDM/IDP platform securing 100+ highly available microservices,
and I support R&D teams on OAuth2/OIDC.
IAM architecture design for the authentication & authorization platform
AI agent & MCP server authentication via Token Exchange (RFC 8693 / OBO)
Cloud back-offices for account & RBAC access management
Bordeaux, Nouvelle-Aquitaine, France. Remote / hybrid friendly.
English works, though French is my strongest language.
Industry 4.0 · Cestas & Paris, France
Lectra SA
The world leader in its field: a French industrial-tech company building the software and the
cutting machines that turn a design into cut material, for fashion, automotive interiors and furniture.
founded
1973
hq
Paris · R&D Cestas
listed
Euronext Paris
sector
Industry 4.0
Lectra sells an integrated chain: CAD/PLM software, cloud services, and connected cutting hardware.
Its Lectra Cloud platform is where that chain became a distributed system, and where
every customer, machine and internal service needs an identity before it can do anything at all.
My chapter
Two stints. First as a J2EE performance engineer on the FIP integration platform behind the PLM
(2013 → 2015), then, since 2016, designing and still leading the IDM/IDP platform that
secures 100+ microservices across Lectra Cloud.
Authentication & authorization architecture for the whole cloud platform
OAuth2/OIDC referent for R&D teams
Token Exchange (RFC 8693) to give AI agents and MCP servers a real identity
France's incumbent telecom operator: fixed, mobile, enterprise. Behind the consumer brand sits one
of the country's largest software organizations, with its own methods, its own forges, its own rules.
founded
1988 · France Télécom
renamed
2013 · Orange SA
hq
Issy-les-Moulineaux
sector
Telecom
At that scale, software quality stops being a team habit and becomes an institution: working groups,
shared tooling, audits, an internal market for build and analysis infrastructure. That institution is
where I spent fifteen months.
My chapter
Software Quality Architect in the transverse methods & tools unit at Orange France, Pessac,
as a Néo-Soft consultant. My job wasn't to ship a product. It was to make other teams' delivery
faster and safer, one project team at a time.
Built the "Forges as a Service" admin portal provisioning Jenkins + SonarQube
Reliability & robustness audits, then the training that made them stick
Where DevOps stopped being a tooling question for me and became a cultural one
The bank that came out of La Poste in 2006, built on the financial services the post office had been
running for decades, with a public-service mandate written into its charter.
founded
2006
parent
Groupe La Poste
hq
Paris
sector
Retail banking
Its financial-services IT sits in Gradignan, near Bordeaux, in a shared development centre
(CDM EPA) whose job title says it all: entretien du patrimoine applicatif, maintaining
the estate. Applications older than the bank itself, still serving millions of accounts.
My chapter
Hired as an experienced designer/developer, and widened within months to technical leadership and
application piloting: the intermediary between the business side and the ATOS delivery centre,
translating in both directions.
Technical migrations on a long-lived estate: JDK, DISFE framework, WebSphere 6.1 → 7
Requirements, feasibility, estimation, and the documentation that outlives the project
My first real lesson in legacy: the hard constraint is almost never the code
One of the regional mutual banks that together make up Crédit Agricole: cooperative, locally
governed, and large enough to run its own customer-facing banking platform.
model
Cooperative
group
Crédit Agricole
hq
Bordeaux
sector
Retail banking
The software itself came from AtlantiCA, the in-house publisher serving the
Atlantic-facing regional banks from Gradignan. That is where I sat, in a team of ten, on the portal
customers actually logged into.
My chapter
My first job: junior developer → technical referent →
project lead in three years, on BAM, the online banking portal for account overview and everyday
banking operations.
New account overview and full redesign of the customer portal
Screen hardening and application certification: security as a non-negotiable, for the first time
RIB → SEPA migration, on accounts that could not be wrong for a single day
A French IT services firm headquartered in Rennes, with regional offices across the west of the
country, including the Bordeaux agency that placed me on two consecutive missions.
founded
1998
hq
Rennes
sector
IT services
My chapter
Four years under their banner, in two very different contexts: J2EE performance R&D at Lectra,
then software quality architecture at Orange. The second mission is what pushed me from writing
applications to building the tooling other teams ship with.
A Bordeaux-area IT consultancy, the kind of small structure where the people who place you are also
the people who know the client's technical stack first-hand.
My chapter
Two years on a single assignment: designer/developer in La Banque Postale's shared development
centre in Gradignan, a role that grew into technical leadership and application piloting.
2011 → 2013 · La Banque Postale
Engineering consultancy · France
Ausy
A French engineering and IT consultancy, historically focused on high-technology sectors. It was
acquired by Randstad in 2017 and now operates within Randstad Digital.
founded
1989
acquired
2017 · Randstad
sector
Engineering & IT
My chapter
My way in. Ausy placed me at AtlantiCA, the Crédit Agricole software publisher in Gradignan, for
the first three years of my career, long enough to go from junior developer to project lead
without changing desks.
2008 → 2011 · Crédit Agricole / AtlantiCA
Higher education · Bordeaux
Université Victor Segalen Bordeaux 2
Bordeaux's life-and-health-sciences university: medicine, biology, pharmacy, and the computing
that grew alongside them. It no longer exists under that name: it was folded back into the
Université de Bordeaux in 2014.
founded
1971
merged
2014 · Université de Bordeaux
named after
Victor Segalen
field
Life & health sciences
Because computer science sat next to biology rather than next to engineering, its curriculum pointed
straight at bio-informatics: genome data, sequence algorithms, and problems where the messy domain
always won the argument against the elegant model.
My chapter
Five years, two directions. A bachelor's in cell biology and physiology first, then a master's in
computer science specialized in bio-informatics, the bridge that turned a biologist's curiosity
into a software career.
Bachelor's in Cell Biology & Physiology (2002 → 2005)
Master's in Computer Science, bio-informatics track (2005 → 2007)
The lasting habit: model the system you actually have, not the one that would be convenient
The organisation that Ken Schwaber, co-author of Scrum, founded to keep the framework's definition and
its assessments in one place. PSM I tests the Scrum Guide itself: the empirical reasoning behind the
roles, events and artifacts, not a project-management recipe.
founded
2009
founder
Ken Schwaber
exam
PSM I · open assessment
validity
No renewal
There's no mandatory course and no expiry date, which is the honest part of the model. It certifies
that you know what the framework actually says, and makes no claim about whether you can make a team
work.
My chapter
I took it after years of already working in agile teams, not before. It mostly corrected things I
thought I knew: how much of Scrum is about the feedback loop, and how little of it is about
ceremonies.
An identity platform has no acceptable maintenance window. If it is down, nothing else in the cloud
is up, so every design decision gets made with the outage in mind, not the happy path.
Ran persistence migrations in production with zero downtime. Never a big-bang cutover
Traded schema purity for availability more than once; a denormalized read path that survives a database failover beats an elegant one that doesn't
Today I'd invest earlier in failure rehearsal: the architectures that held up were the ones whose failure modes we had actually triggered on purpose
Focus / 02
Production Operations
Designing the platform and being on the hook when it misbehaves are the same job. Owning production
is what keeps an architecture honest: you stop shipping decisions you wouldn't want to debug at 3am.
Instrumented the IAM platform end to end (Prometheus, Grafana, Instana, Splunk) so an incident starts with a signal, not a guess
Chose alerting on user-visible symptoms over component metrics: fewer alerts, later, but none of them ignorable
What I'd change: write the runbook while designing the feature. Written after the first incident, it's already a postmortem
Focus / 03
OAuth2 & Beyond
The spec is short; the failure modes are not. Most of the value I add is in the questions around it:
who is the subject, what is the audience, what happens when the token outlives the reason it was issued.
Put the full range into production: PKCE, Client Credentials, Device Flow, Token Exchange, SSO, MFA, OIDC federation and account linking, RBAC and TBAC
Kept the identity provider as a provider and the authorization model in our own domain. Vendor features are tempting, but authorization rules are business rules
What I'd do differently: teach the mental model before the flows. Teams that understand audience and delegation pick the right grant on their own; teams given a recipe copy it into the wrong context
Focus / 04
API Design
An API is a contract you'll be honouring for years with consumers you'll never meet. The design work
is mostly about what you refuse to expose, and about leaving room for the version you can't foresee.
Built a highly available Partners GraphQL API serving critical cloud reference data, federated across subgraphs with Apollo Federation and Yoga
Went further than HTTP where it paid: GraphQL over AMQP for internal consumers, so back-pressure and retries were the transport's problem, not every client's
What I'd change: federate later. Splitting a graph before the domain boundaries are settled buys you distributed coupling, and the schema review meetings that come with it
Focus / 05
AI-Augmented Engineering
The interesting problem isn't whether AI writes decent code. It does. It's what happens when an
agent needs to act on a user's behalf, and identity has to answer a question it was never asked before.
Designing agent & MCP server authentication on Token Exchange (RFC 8693, on-behalf-of): an agent gets a real, scoped, auditable identity instead of borrowing someone's session
Pushed team-wide adoption from individual usage to tooled collective practice: shared conventions beat twenty private workflows, even good ones
What I'd do differently: treat context as the deliverable. The gap between a useful agent and a plausible one is almost never the model
Focus / 06
Fast Feedback Loops
Delivery speed is a design property, not a management target. Every hour between writing a line and
learning it was wrong compounds into bigger batches, longer reviews, and riskier releases.
Moved the team to trunk-based development with semantic-release: small commits, continuous integration, versioning that nobody has to think about
Accepted feature flags and the cleanup debt they create, in exchange for never running a long-lived branch again, a trade I'd make every time
What I watch now: DORA metrics as a diagnostic, never as a scoreboard. The moment lead time becomes a target, someone optimizes the number instead of the loop
Focus / 07
Developer Experience
Most of a developer's day is spent not developing: waiting for a build, locating an owner, guessing a
convention. That friction is a design surface like any other, and it compounds across a whole R&D org.
Turborepo monorepo with a remote cache, DDD boundaries, conventional commits, Renovate and Syncpack keeping dependencies from drifting apart
Chose a monorepo knowing exactly what it costs (tooling ownership, CI complexity) because the alternative was version skew across dozens of services
What I'd do differently: automate the convention instead of documenting it. A rule that isn't enforced by a pipeline is a rule that lasts until the next deadline
Focus / 08
DevOps as Culture
Somewhere along the way DevOps became a job title, which is precisely the outcome it was invented to
prevent. It was never a role to hire. It's a refusal to let a wall exist between building and running.
At Orange, spent fifteen months inside the software-quality unit doing exactly this: CI/CD working groups, reliability audits, Jenkins and SonarQube training across project teams
Learned that tooling is the easy half: a "Forges as a Service" portal only changes anything if the teams behind it want the feedback the forge gives them
What I'd do differently: start from a problem a team already feels, not from the practice I want to spread. Adoption follows relief, never argument
Language
JS / TypeScript
JavaScript is the runtime everyone already has. TypeScript is the type layer bolted on top of it,
and it compiles away entirely: the types cost nothing at runtime and everything at review time.
Its typing is structural, so a value fits a shape if it looks right, not if it inherits from the
right class. That matches how JavaScript objects are actually passed around.
The oldest programmable interface on any Unix machine: a language whose primitives are processes,
pipes and files. bash and zsh are the two dialects most people actually type into.
Everything composes through text streams, which is why a pipeline written in 1985 still runs today,
and why every tool that respects stdin and stdout joins the ecosystem for free.
The minimal HTTP framework for Node.js, and for over a decade the default one. Routing, middleware,
and almost nothing else: everything beyond that comes from the ecosystem built around it.
Its middleware signature became a de facto standard, to the point that other frameworks still
implement a compatibility layer for it.
A Node.js HTTP framework built on one observation: serialisation and validation are the real
bottleneck. Declare them as JSON Schema up front and they compile down to fast, specialised functions.
Plugins get an encapsulated scope of their own, so a badly behaved one cannot leak its decorators
into the rest of the application.
A query language and type system where the client states exactly which fields it wants and receives
that shape back. One endpoint, one schema, and no versioning ritual.
The schema is the contract, and it is introspectable, so documentation, tooling and client code
generation all fall out of it instead of being maintained separately.
A batteries-included GraphQL server built on the standard Request and Response objects rather than
on one specific Node framework. It runs anywhere that speaks Fetch: Node, Bun, Deno, edge workers.
Subscriptions, file uploads, CORS, GraphiQL and the error masking you want in production are all on
by default, configured rather than assembled.
A specification for composing several independently deployed GraphQL services into a single graph.
Each subgraph owns its slice of the schema, and a router plans each query across them.
Entities are the mechanism: a type declared with a key in one subgraph can be extended with new
fields by another, without either team touching the other's code.
A TypeScript ORM that generates its client from a schema file rather than from decorated classes.
The result is a query API whose return type changes with the fields you select.
Migrations are generated from that same schema, so the database and the types cannot drift apart
silently between two deployments.
A message broker built around AMQP. Producers publish to exchanges, bindings route messages into
queues, and consumers acknowledge them, which is what makes real delivery guarantees possible.
Routing lives in the broker topology rather than in application code, so changing who receives what
becomes a configuration change instead of a deployment.
The relational database that kept adding capability without ever trading away correctness: MVCC,
transactional DDL, JSONB, full-text search, window functions, and an extension system.
That extension model is why a single Postgres instance can credibly act as a document store, a job
queue or a vector database before you need to run anything else.
A document database storing BSON records in collections, with no schema enforced by default and a
query language that is itself expressed as documents.
Its aggregation pipeline is the real engine: a sequence of stages transforming documents server
side, where a relational database would reach for joins and subqueries.
An in-memory data structure server, and not merely a cache: strings, hashes, sorted sets, streams
and bitmaps, each manipulated through atomic commands.
The core command loop is single-threaded on purpose, which is precisely why every operation is
atomic without any locking on the caller's side.
A hosted identity provider, now part of Okta, implementing OAuth2 and OpenID Connect as a service:
login, sessions, MFA, social and enterprise federation, token issuance.
Its extensibility model matters more than the feature list. Actions run custom code inside the login
pipeline, which is where the requirements no vendor anticipated end up living.
The kernel running nearly every server, container and cloud instance in existence. Processes,
namespaces, cgroups and the filesystem interface are the primitives everything above it assumes.
Containers are less a single Linux feature than a combination of several: namespaces for isolation,
cgroups for limits, union filesystems for images.
The tool that made Linux containers usable: a build format, a registry protocol and a runtime,
wrapped in a handful of commands a developer can actually remember.
Images are layered and content-addressed, so a shared base layer is pulled once and a rebuild only
rewrites the layers whose inputs changed.
A container orchestrator built on a control loop. You declare the state you want, and controllers
work continuously to make reality match it.
Nearly everything is an object in one uniform API, and custom resources let you extend that API with
your own kinds, which is why the ecosystem around it grew the way it did.
Microsoft's cloud: compute, managed databases, networking, and the identity layer (Entra ID,
formerly Azure AD) that most large organisations already run their employees on.
Its strongest argument is rarely one standout service. It is the continuity with an estate that
already exists: directory, tenants, licensing, compliance.
Agentless automation. It connects over SSH, runs modules on the target machine, and describes the
intended result in YAML playbooks. Nothing to install on the hosts it manages.
Modules are written to be idempotent, so running the same playbook a second time converges on the
same state instead of duplicating its effects.
A content-addressable object store with a version control interface on top. Commits point to trees,
trees to blobs, and every object is named by the hash of its own content.
Branches are just movable pointers to a commit, which is why creating one is instant and why an
entire collaboration culture grew around them.
A Node package manager that stores each package version once in a global content-addressable store
and hard-links it into projects. Installs are fast and disk usage stops scaling with repository count.
Its node_modules layout is strict: a package can only import what it actually declared, so phantom
dependencies fail immediately rather than months later on someone else's machine.
A build orchestrator for JavaScript monorepos. It reads the dependency graph between packages, runs
tasks in the right order, and caches every task output against a hash of its inputs.
A cache hit replays stored output instead of rebuilding, so a task whose inputs have not changed
costs essentially nothing, locally or in CI.
An open-source implementation of Turborepo's remote cache API, self-hostable on your own storage.
The cache stops being per-machine: CI and every developer share the same artifacts.
It speaks the same protocol as the hosted service, so adopting it or moving away from it is a change
of URL and token, not a change of workflow.
A bot that watches your manifests and opens pull requests when dependencies move. It covers dozens
of ecosystems rather than just npm, and pulls release notes into the pull request body.
Grouping, scheduling and automerge rules are all configuration, so the flow of updates can be tuned
to whatever a given team is able to absorb.
A linter for the dependency versions declared across a monorepo's package.json files. It finds the
ranges that disagree with each other and can rewrite them to a single source of truth.
Version policies are declared once and then enforced in CI like any other lint rule, instead of
being a convention people remember with varying success.
The vendor behind Jira and Confluence: issue tracking and a team wiki which, between them, hold most
of the written memory of a software organisation.
Jira's real substance is the workflow engine and the query language underneath the board.
Confluence's is not the editor but the fact that a decision stays findable years later.
GitHub's coding assistant, embedded directly in the editor. It completes from the surrounding file
and the open tabs, which makes it strongest on the repetitive middle of a function.
Its suggestions track how much relevant context is already on screen, so it behaves less like a
knowledge base and more like a very fast pair of hands.
Anthropic's family of language models, reachable through the API, the apps, or Claude Code in the
terminal. Long context windows and tool use are what let it work on real codebases rather than snippets.
MCP, the Model Context Protocol, standardises how it reaches external tools and data, so an
integration written once works across every client that speaks it.