Evolving frontend engineering at OpenClassrooms

Our React codebase was initially written in JavaScript. Moving to TypeScript meant supporting a gradual change while teams continued to develop the product.

I worked on the migration strategy, tooling and standards, as well as helping teams adopt them. Around 70% of the React codebase was migrated. The language mattered, but so did making its adoption practical in everyday work.

This also led me to propose and write the Découvrez TypeScript course, in French ↗. Teaching was part of the same work.

I built a JavaScript SDK to communicate with an OAuth2 API, then worked on data-access layers. The goal was to give applications shared foundations for communicating with the backend.

These foundations evolved towards a strongly typed API layer generated from backend OpenAPI definitions. API contracts could become part of frontend developers' tools, instead of relying only on their reading of the documentation.

I led the frontend testing strategy, using React Testing Library and Playwright for integration tests. The API is mocked in these tests, so the application's behaviour can be checked in controlled situations.

Real end-to-end tests on essential user journeys, the golden paths, remain the responsibility of Quality Engineering. This distinction makes it clear what frontend tests cover and what they cannot guarantee on their own.

The frontend chapter brought together up to 12 engineers. I helped run it and supported teams across standards, code reviews and tooling.

A tool or convention has little value if people cannot make use of it. This part of my work connected technical decisions with how teams actually applied them.

We used Phrase for translations. Over time, its cost and fit with our needs led us to look for another solution.

I built an internal tool with substantial help from GitHub Copilot. It was used on web and iOS, saving more than €20k each year. The useful outcome was meeting our needs without keeping a cost that had become hard to justify.

I helped reassess a micro-frontends strategy and took part in evaluating and adopting Next.js. Web performance was among the motivations: using Lighthouse to understand the situation, reducing shipped JavaScript, and optimising or caching API requests.

I also contributed to UI foundations and later helped replace a solution that had become less suitable. Building a foundation does not mean defending it forever. It needs to be reassessed as the product and teams change.

This journey taught me to look at both together. A migration, testing strategy or API layer is not only about code. Each changes everyday work for the people building the product.

That is a connection I continue to work on today as an Engineering Manager.