De Staff Engineer à Engineering Manager chez OpenClassrooms

Lors de mon passage au management, j'ai travaillé avec les RH pour définir le poste et le processus de recrutement de bout en bout. J'ai mené les entretiens manager, organisé les entretiens techniques et cultural fit, consolidé les retours, contribué aux décisions et animé les salary workshops.

Pour les candidats recalés que j'avais rencontrés, je prenais moi-même le temps de leur téléphoner directement pour expliquer notre décision de ne pas poursuivre : ils nous avaient consacré du temps, c'était la moindre des choses de leur expliquer de vive voix les raisons de notre refus.

Concernant l'entretien technique, j'ai largement participé à son élaboration. Vous pouvez en savoir plus dans mon article Passer un entretien front-end chez OpenClassrooms ↗.

Une fois le recrutement validé, j'ai préparé un plan d'onboarding sur trois mois avec des objectifs clairs, afin que la nouvelle recrue sache exactement ce qu'on attend d'elle et qu'elle puisse aborder sa période d'essai sans aucune surprise.

Ma squad travaille notamment sur la mise en relation entre recruteurs et talents, ce qui représente une partie critique du business d'OpenClassrooms. Juste avant Noël, nous avons malheureusement dû faire face à des prises de contact malveillantes sur la plateforme. Entre une roadmap chargée et les congés imminents, notre capacité à réagir à de nouveaux abus était limitée. Il fallait agir vite, mais avec pragmatisme.

J'ai alors fait une suggestion un peu osée : fermer temporairement le canal de contact direct pendant les fêtes. Cela revenait simplement à « couper le business ». Ma justification était que l'activité de recrutement est bien plus faible à cette période : le coût business temporaire me semblait inférieur au risque de laisser la porte ouverte sans capacité suffisante de réaction.

Après quelques discussions, ma proposition a été acceptée à condition de mettre en place une solution durable à la rentrée. J'ai alors proposé un mécanisme de shadowban, inspiré de mon ancienne expérience chez Meetic. Cette solution a pu être implémentée en environ un sprint.

La solution temporaire de bloquer tout le monde n'était pas idéale, mais elle nous a permis de réfléchir sereinement à une solution durable et efficace, sur laquelle OpenClassrooms peut toujours capitaliser aujourd'hui.

Les équipes commerciales d'OpenClassrooms ont besoin de consulter et de gérer les organisations, les recruteurs, les offres d'emploi et les candidatures. Pour ce faire, elles ont accès à un CRM très personnalisé, qui porte une part importante de la logique métier.

Chaque nouvelle fonctionnalité implique donc une synchronisation malvenue : la plateforme OpenClassrooms doit transmettre beaucoup d'informations au CRM, ce qui nécessite de se coordonner avec l'équipe technique en charge de ce dernier et allonge les délais de livraison.

Lorsqu'on nous a demandé d'ajouter des informations sur les candidatures, je suis revenu au besoin réel : les équipes commerciales devaient certes accéder à ces informations, mais sans nécessairement devoir les retrouver dans le CRM en lui-même. J'avais auparavant développé un système d'administration générique que nous pouvions enrichir pour ces objets métier. Appuyé par mon équipe, j'ai proposé de capitaliser sur cette admin, afin de supprimer cette dépendance inter-équipe qui minait nos performances.

Sans cette décision, il aurait fallu envoyer différents types d'événements au CRM, qui aurait ensuite dû les prendre en compte : nous estimions cette approche à environ un mois de travail au total. Avec la nouvelle approche, nous avons pu livrer toute la gestion des candidatures par les équipes commerciales en environ un sprint.

Ce travail sur l'admin a aussi permis d'élargir les responsabilités au sein de l'équipe. J'ai encouragé une personne de mon équipe, dont le travail était jusque-là centré sur le backend, à participer plus tôt aux discussions produit. Cette implication l'a particulièrement intéressée, si bien qu'elle a envisagé une évolution professionnelle davantage orientée « produit ».

Cette personne a alors construit, avec une grande marge de manœuvre, une part importante des interfaces de l'admin aujourd'hui utilisées par les équipes commerciales, en gardant leurs besoins à l'esprit. Mon rôle a été de créer cette occasion et de soutenir son autonomie, en lui laissant la responsabilité de l'implémentation.

C'est ainsi que j'aborde l'accompagnement professionnel : ouvrir progressivement des occasions de comprendre les problèmes métier, de contribuer au produit et de prendre des responsabilités plus larges, puis adapter l'accompagnement aux envies de la personne.

Avec l'intelligence artificielle, j'accorde encore plus d'importance à la capacité des ingénieurs à comprendre un problème, à questionner les solutions proposées et à apporter leur expertise aux décisions produit. Aujourd'hui, la valeur ajoutée d'un ingénieur ne se limite plus à écrire du code.

Lorsque je suis arrivé à OpenClassrooms, l'architecture frontend n'était pas encore fixée, malgré une codebase déjà vieille de plusieurs années. Mon expérience chez Meetic m'a amené à proposer, puis à mettre en place, une architecture modulaire. J'ai raconté cette démarche dans l'article Construire une application JS depuis zéro ↗.

Notre codebase React était initialement écrite en JavaScript. J'ai poussé le passage à TypeScript pour avoir un code plus précis et exigeant. C'é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. Ceci m'a amené à proposer puis écrire le cours Découvrez TypeScript ↗ sur OpenClassrooms.

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 via TypeScript, générée à partir des définitions OpenAPI du backend. Ceci a permis une auto-complétion précise et un code plus robuste.

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.

Une nouvelle pratique à mettre en place ? Une librairie à mettre à jour ? Des changements dans nos pratiques d'architecture ? Mon rôle en tant que Staff Frontend Engineer était d'aligner tout le chapter pour que nous puissions tous avancer dans la même direction.

Pour assurer une cohésion avec les nouveaux membres du chapter frontend, j'ai participé à la définition du déroulement de l'entretien technique. Le but principal : faire en sorte que l'expérience soit la meilleure possible pour les candidats, en respectant leur temps personnel et en évitant de les mettre dans des situations de stress. Consultez mon article Passer un entretien front-end chez OpenClassrooms ↗ pour en savoir plus sur ces entretiens.

Lorsque je suis arrivé à OpenClassrooms, tous les textes étaient directement dans la codebase. La conséquence principale était que les développeurs en étaient responsables.

C'était une perte de temps énorme : environ 80 % des retours qualité concernaient les textes. J'ai donc demandé au CTO de revoir complètement le flow, et j'ai eu carte blanche.

En travaillant avec les Content Designers, j'ai imaginé un flow où les développeurs n'avaient plus à gérer les textes eux-mêmes, basé sur un outil externe : Phrase. J'ai raconté tout ce processus dans l'article Automatisation d'un système de traduction ↗.

Nous avons donc utilisé Phrase plusieurs années. Malheureusement, avec le temps, son coût et son adéquation à nos besoins nous ont conduits à chercher une autre solution.

J'ai donc créé un outil interne, basé sur GitHub. L'idée était qu'il réponde strictement à nos besoins, et rien de plus. Cela nous a permis de quitter Phrase, qui reste un très bon outil mais ne correspondait plus à nos besoins, et d'économiser environ 20 k€ par an.

J'ai participé à l'élaboration de la stratégie de tests frontend, avec React Testing Library et Playwright pour les tests d'intégration. J'ai défendu l'intérêt d'un coverage à 100 %, une mesure pourtant assez décriée. Pour comprendre ma position, vous pouvez lire mon article Le véritable intérêt de la couverture du code à 100 % ↗.

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.

Cette longue expérience en tant que lead technique m'a permis de réaliser ce qui me plaisait dans mon métier : faire en sorte que mes collègues aient toutes les clés en main pour faire correctement leur travail, tout en étant un point de référence technique.

Quand OpenClassrooms m'en a donné l'occasion, je me suis donc lancé dans la suite logique de ma carrière : devenir Engineering Manager.