About me

As AI coding agents became part of daily work, their rapid adoption exposed inconsistent quality, duplicated effort, and the absence of shared standards. In response, I led the creation of a common framework for the team.

I authored a governance model that settles the essential questions: who owns a skill, how contributions are reviewed, how each one is tested independently and released in preview first, how skills compose, how activation rules keep two of them from competing for the same request, and what quality thresholds are expected before anything is shared. To make evaluation repeatable and objective, I designed a weighted scoring rubric and implemented a deterministic Python tool that scores skills and workflows, flags critical issues, and ranks improvements by impact.

I also built reusable agent skills the team could compose — Jira issue management, GitLab pipelines and merge requests, local Git operations, feature-environment resolution, automated quality evaluation, and Kubernetes diagnostics restricted to read-only investigation, so an agent can help diagnose a cluster without being able to change it. Two orchestration workflows combine those skills into structured troubleshooting and evaluation processes, each with an explicit contract, declared dependencies, safety guardrails, and defined failure handling.

The framework is used across the team. I still review contributions, help colleagues build and debug their own workflows, unblock them when an agent or a tool integration misbehaves, and adjust the model as feedback comes in.

Company-wide Single Sign-On was the next step for a multi-tenant healthcare SaaS platform used in several countries. I designed and implemented the enterprise identity-provider integration end to end. The decision that shaped everything else was to delegate authentication while keeping roles, permissions, and organizational access under the platform's control, and without removing the existing username-and-password login.

I owned the architecture, the security model, the Java/Quarkus implementation, the coordination with stakeholders, and the technical documentation. The integration uses the OIDC Authorization Code Flow with PKCE and Pushed Authorization Requests, with state and nonce validation.

Most of the difficulty was in what happens after the login. I designed server-side management of authentication state and external tokens, including refresh and cleanup tied to the session lifecycle, and a provider-agnostic identity-mapping model that refuses ambiguous account matches. I also solved callback routing for dynamic test environments without weakening redirect validation.

The integration is now in production and actively used by healthcare professionals, providing secure federated authentication while preserving internal authorization boundaries.

Third-party integrations did not all use the same connection settings: endpoints varied by deployment environment and by user profile, and the configuration was scattered across files and application code. Routing a test or pilot user to a non-production endpoint, while healthcare professionals kept using the production one, usually meant a code change and a redeployment — with no simple way to make an exception for a single user.

I took ownership of replacing that with a three-tier resolution model, evaluated for each user and each integration: a value set for a specific user wins over the integration's own strategy, which in turn wins over the database-managed default. Endpoint routing was only the trigger, though — I designed the service around the general case, defining any configuration whose value depends on who the user is: their attributes, their profile, or whatever criterion a given integration needs.

I designed the JPA data model, implemented the Java/Quarkus service and its API, and documented the architecture in a formal design document (an RFC) with technical diagrams. Strategy and Factory patterns keep each integration's rules in its own place, so adding one does not mean touching the resolution flow.

Endpoint changes and individual exceptions are now configuration rather than deployments. The system runs in production today.

Every clinical document on the platform passes through a single storage service, originally backed by self-hosted MinIO and one of the services I had helped build. When the company moved the platform to Azure, a colleague and I took on the storage workstream. Doctors use the product during their consultation hours, so there was no maintenance window long enough to move every document at once. The migration had to run with the platform live, and without losing a single file.

Rather than a single cutover, we made the service talk to both backends at once and moved the routing decision into the database: each MinIO tenant record pointed to the Azure tenant replacing it, and each clinic's bucket pointed to whichever tenant physically held it. Migrating a bucket became a database update instead of a deployment, and a feature toggle could send all traffic back to MinIO instantly, since nothing had been deleted there — precisely to preserve backward compatibility.

I wrote the Python migration tooling, run as a Kubernetes job: parallel copying, a bookkeeping table that made every run resumable, and object counts compared on both sides before any routing record was repointed — copy, verify, then switch. We ran it outside consultation hours, migrating a set of buckets, stopping, and later picking up where we had left off. I also wrote the backward-compatible read and write paths that let the two backends coexist while buckets moved across one by one.

The workstream ran for about nine months, from design through to the final cutover, with no downtime and no data loss. Once production had been stable on Azure, I owned the cleanup that removed the old implementation, its toggle, provisioning scripts, and dependencies.

CGM products in several countries needed to reuse selected platform services on behalf of users who were already authenticated, without asking them to sign in again — and without the platform having to understand several external token formats. I designed and implemented an OAuth 2.0 Token Exchange capability end to end to bridge that gap.

I built it on the OAuth 2.0 Token Exchange standard (RFC 8693) and owned the full lifecycle: protocol architecture, security design, the Java/Quarkus implementation, the OpenAPI contract, and the documentation consumers rely on. Each partner's token validation sits behind the same interface, so the platform can accept several external issuers while the exchange flow itself stays unaware of any of them.

Requested scopes are constrained by the partner's own permissions before a uniform internal token is issued, so a partner product can only reach the services it is registered for — least privilege, enforced at the boundary rather than in each downstream service.

The capability is used in production by CGM products, giving cross-product service access a single, auditable security boundary.

French healthcare smart cards and the DMP — the national shared medical record — opened an entirely new integration surface for the platform: physical card readers, software running on the practitioner's workstation, real-time card events, regulated transactions, and healthcare protocols nobody on the team had worked with before.

I led the initial technical investigation and built a working proof of concept covering the CPS professional card, the patient Carte Vitale, and the main DMP document workflows.

I mapped and tested the ecosystem end to end: reader sessions, practitioner and patient card access, asynchronous insertion and removal events, and the document exchanges the DMP requires. I produced reproducible Postman examples and technical documentation, and helped define an architecture that separates frontend event handling from backend transactional operations.

My role was to make the integration path actionable, not to build the final production feature. I delivered working examples, architecture diagrams, live demonstrations, knowledge-transfer sessions, and implementation support to the delivery teams, who built on it to complete the capability doctors use heavily today.

A single healthcare codebase had to vary services, interface components, and business behavior by country, region, practitioner type, and specialization — without turning into a maze of conditional branches. I helped investigate and implement the classification system built to solve that.

A colleague and I led the initial technology spike. I evaluated Apache AGE against the previously proposed Neo4j, reproducing the critical taxonomy and graph-traversal queries in both. Apache AGE kept the same Cypher-based graph modeling, but ran inside the PostgreSQL infrastructure the platform already operated — so the team got the graph capabilities it needed without adding a second database to deploy, monitor, and back up.

Once the decision was approved, I contributed substantially to the shared Java/Quarkus implementation, and to the documentation, developer guidelines, demonstrations, and onboarding that made it usable by other teams.

The production system combines graph-based resolution and Redis caching that lets a service declare which variant it needs instead of branching on context. It runs across the platform today, supporting several countries from one codebase while keeping variation logic in one place.

KimiaPay wanted to validate a digital salary-advance product for employees with limited access to traditional credit, where partner employers would take part in approving requests and guaranteeing repayment. I was the sole technical owner within a startup team, during my final-year engineering internship.

The central challenge was architectural: turning a financial product with several actors, approval stages, security requirements, and room to grow into a coherent system that one developer could deliver in four months.

I designed a service-oriented architecture that includes a cross-platform mobile application for borrowers, a web back office for administrators and employer representatives, backend business services, and a centralized data layer connected through REST/JSON APIs. I then carried that architecture through implementation, testing, and deployment.

The product covered token-based authentication, identity and employment-data collection, role-based access, multi-level approval, loan tracking, and the full lifecycle of a request from submission through repayment or dispute. I selected AppGyver and Backendless to accelerate delivery under the project's constraints, and wrote custom JavaScript where needed. The finished product was deployed, ready for a pilot phase.

Amadeus wanted to know whether migrating a flight-search application server from Spring/JBoss to Quarkus was technically feasible and worth the investment. My second-year engineering internship was that evaluation. The goal was not to change the application's business behavior, but to determine how it could run on Quarkus and document the implications for future migrations.

Embedded in an agile engineering team, I built the Quarkus version of the application and investigated the compatibility issues it surfaced: external dependencies, CDI, unsupported Spring annotations, and class loading. Depending on the constraint, I used CDI producers, adapted selected components, wrote Quarkus extensions, or ran both applications side by side in debug mode to find where they diverged. I also reported genuine framework limitations to the Quarkus community.

The migration was intentionally left incomplete once its scope exceeded the four-month placement. What I delivered instead was a decision-ready technical reference: the blockers encountered, the solutions found, the trade-offs made, and the migration costs to expect. Early measurements pointed to substantial startup improvements, whose limitations I documented clearly.

Amadeus was left with a reusable basis for evaluating future migrations, and I came away with a much better sense of framework compatibility and of what a migration really involves: how to assess one, plan it, and carry it out without taking unnecessary risks. Working entirely in English in an international team — daily collaboration, meetings, technical discussions, documentation — also strengthened my professional communication.

École Centrale de Lyon's intensive curriculum sometimes left students needing more time, and another way into difficult concepts. Because of my computer-science background, the school selected and paid me to run the computer-science reinforcement sessions.

I prepared lessons and exercises, re-explained the concepts that had not landed, reviewed assignments, ran practical workshops, and gave one-to-one support. The sessions covered algorithms through Python, UML and application design, and the broader computer-science ideas the curriculum assumed.

Teaching a concept twice the same way rarely works. Most of the job was finding where a student's understanding had broken, then explaining it in another way.

École Centrale de Lyon kept its computer rooms open at night so students could work after the regular staff had left. A team of paid student monitors supervised them, and I coordinated that team and acted as the administration's main contact.

I collected availability, built the schedules, covered last-minute absences, and balanced monthly hours so that work and pay stayed broadly even across the team. I also watched over how the rooms were used, handled incidents reported by students, passed on what I could not resolve, and kept the administration informed when something went wrong.

The job came down to keeping a schedule fair and the rooms open when plans changed at short notice, and to being the person both the team and the school could call.

SUITE was exploring a collaborative mobile application that would make niche and local know-how easier to share and find, through training content, help requests, service offers, and events online or in person. During my DUT internship, I was the sole developer of the mobile client.

I owned that work from requirements analysis through architecture and implementation. I modeled the user roles and the domain with UML, built the cross-platform application in React Native, and integrated it with an existing Django REST Framework API provided by the SUITE team. The client consumed REST/JSON endpoints and offered distinct features for visitors, learners, trainers, and administrators.

By the end of the internship I had implemented and presented the core screens and end-to-end flows — browsing training content, authentication, posting help requests, and publishing trainings, events, and offers. That was my first mobile product taken end to end: choosing the technology, modeling the domain, integrating an API I did not write, and demonstrating the result.