Faire évoluer l'ingénierie frontend chez OpenClassrooms

Notre codebase React était initialement écrite en JavaScript. Passer à TypeScript était une évolution à accompagner dans la durée, avec du code existant et des équipes qui continuaient à développer le produit.

J'ai travaillé sur la stratégie de migration, le tooling et les standards, mais aussi sur l'accompagnement des équipes. Environ 70 % de la codebase React a été migrée. Le langage comptait, bien sûr, mais il fallait aussi rendre son adoption praticable au quotidien.

Ce travail m'a également amené à proposer puis écrire le cours Découvrez TypeScript ↗. Transmettre faisait partie du même sujet.

J'ai développé un SDK JavaScript pour communiquer avec une API OAuth2, puis travaillé sur les couches d'accès aux données. L'enjeu était de donner aux applications des fondations communes pour dialoguer avec le backend.

Ces fondations ont évolué vers une couche API fortement typée, générée à partir des définitions OpenAPI du backend. Les contrats d'API pouvaient ainsi se retrouver dans les outils des développeurs frontend, plutôt que reposer uniquement sur leur lecture de la documentation.

J'ai piloté la stratégie de tests frontend, avec React Testing Library et Playwright pour les tests d'intégration. Dans ces tests, l'API est mockée : on vérifie le comportement de l'application dans des situations maîtrisées.

Les tests E2E réels sur les parcours essentiels, les golden paths, restent sous la responsabilité de l'équipe Quality Engineering. Cette distinction permet d'expliciter ce que les tests frontend couvrent et ce qu'ils ne peuvent pas garantir seuls.

Le chapter frontend a réuni jusqu'à 12 ingénieurs. J'ai participé à son animation et à l'accompagnement transverse autour des standards, des code reviews et du tooling.

Un outil ou une convention n'a pas beaucoup de valeur si personne ne peut se l'approprier. Cette partie de mon travail reliait les choix techniques à la manière dont les équipes les utilisaient réellement.

Nous utilisions Phrase pour les traductions. Avec le temps, son coût et son adéquation à nos besoins nous ont conduits à chercher une autre solution.

J'ai créé un outil interne en utilisant largement GitHub Copilot. Il a été utilisé sur le web et sur iOS, avec une économie supérieure à 20 k€ par an. Le résultat utile n'était pas d'avoir un outil de plus : c'était de répondre à nos besoins sans conserver un coût devenu difficile à justifier.

J'ai participé à la remise en question d'une stratégie de micro-frontends, puis à l'évaluation et à l'adoption de Next.js. La performance web faisait partie des motivations, avec Lighthouse comme outil d'observation, la réduction du JavaScript envoyé et l'optimisation ou la mise en cache des appels API.

J'ai aussi contribué aux fondations UI, puis participé au remplacement d'une solution devenue moins adaptée. Construire une fondation ne veut pas dire la défendre indéfiniment. Il faut pouvoir la réévaluer à mesure que le produit et les équipes évoluent.

Ce parcours m'a appris à regarder les deux ensemble. Une migration, une stratégie de tests ou une couche API ne sont pas seulement des sujets de code. Ce sont aussi des décisions qui changent le quotidien des personnes qui construisent le produit.

C'est ce lien que je continue à travailler aujourd'hui comme Engineering Manager.