Candidature n° MG-2026-07 · Mentor Goal
Sept ans de React et TypeScript en production. Les deux dernières, j'ai proposé, cadré et mené la réécriture d'un front legacy sans un seul test : architecture hexagonale, use cases en TDD, migration livrée sans interruption de service. Avant ça, j'ai fait deux ans et demi de formation professionnelle, des promotions entières initiée à React. Ce site est ma démonstration, mes 90 premiers jours compris.
fig. 1 : plan masse, architecture hexagonale · détails : PL-03
Mentor Goal n'est pas un site d'offres. C'est l'endroit où un étudiant joue son premier emploi et où une école pilote l'insertion de ses promotions. Un parcours confus y coûte une candidature ; un chiffre faux y coûte une décision. Vu de l'extérieur, trois enjeux se détachent.
je n'ai ni utilisé le produit ni lu votre code : ce sont des hypothèses de lecteur, pas un diagnostic.
L'étudiant ouvre l'application quelques semaines par an, sous pression, souvent depuis son téléphone. L'école y travaille tous les jours, comme dans un outil de métier. Un même design system doit servir un usager occasionnel et anxieux, et un utilisateur expert et pressé : deux ergonomies opposées, une seule base de code.
Une école présente ses taux d'insertion, un étudiant lit le statut de sa candidature : ces chiffres sortent de votre interface et engagent celui qui les montre. Un chiffre faux une fois est un chiffre douteux pour toujours. Une interface de données se joue là : états de chargement, cas limites, fuseaux horaires, et l'honnêteté d'un tableau vide.
Vos utilisateurs ne sont pas des utilisateurs de logiciel par choix : ils cherchent un stage, ils suivent une promotion. Chaque fonctionnalité ajoutée est de la complexité que quelqu'un d'autre ne doit pas sentir. Faire qu'un système complexe reste simple à l'usage est le travail front le plus difficile, et il ne se voit jamais dans un diff.
Si j'ai mal compris l'un de ces points, j'aimerais beaucoup que vous me disiez pourquoi.
Ces quatre chantiers ont un point commun : à chaque fois, il fallait faire monter le niveau sans arrêter ce qui tournait déjà.
Être référent qualité, c'est répondre d'un code qu'on n'a pas écrit. Une CI sait le refuser ; elle ne sait pas expliquer le refus à celui qui l'a écrit. C'est ce que j'ai fait pendant deux ans et demi.
Un module de métrologie énergie & confort : rendu serveur, JS/JQuery, zéro test, réécrit en React + TypeScript sur une architecture hexagonale. Le back n'a pas bougé, les features ont migré une à une, et la plus grosse est passée en dernier, le temps que les features autour d'elle soient réécrites et sûres. La migration en détail : PL-03.
JobTrack : React 19, TypeScript strict, architecture hexagonale, TDD. Avec un test qui casse le build si le domaine importe quoi que ce soit de technique. La règle ne dort pas dans un README, elle s'exécute. Ouvrir la démo, lire le code, ou cloner et lancer pnpm test.
Formateur professionnel chez Dawan puis Konexio : Java, React, TypeScript, Python, Git. Décomposer un concept, le faire pratiquer, vérifier qu'il est passé, recommencer autrement quand il ne l'est pas. C'était mon métier à plein temps.
Co-fondateur d'iDem Agency avec un associé commercial : j'étais le seul développeur. J'ai chiffré, choisi l'architecture, codé, déployé, puis réparé. Quand la même personne estime et livre, une estimation optimiste se paie de sa poche : c'est là que j'ai appris à décider en connaissant le prix.
Toute la différence entre une intention d'architecture et une architecture. La première se dessine. La seconde se rend obligatoire, tourne en CI, et refuse un import. Les trois pièces qui suivent font le trajet de l'une à l'autre.
D-01 est l'intention. D-02 est la contrainte. D-03 est ce qu'il en reste une fois en production.
// ce que chaque couche n'a PAS le droit d'importer
const FORBIDDEN_TARGETS = {
domain: ['application', 'infrastructure', 'ui', 'design-system', 'external'],
application: ['infrastructure', 'ui', 'design-system'],
infrastructure: ['ui', 'design-system'],
ui: ['infrastructure'],
'design-system': ['domain', 'application', 'infrastructure', 'ui'],
};$ pnpm vitest run src/architecture.unit.test.ts
✓ has no forbidden cross-layer or cross-slice import
✓ keeps the domain free of I/O (no fetch)
✓ keeps use cases free of direct I/O (no fetch outside infra)
✓ uses relative imports within a module and @/ across modules
Test Files 1 passed (1)
Tests 4 passed (4)
Duration 142ms
Le domaine n'a le droit d'importer rien du tout, pas même une bibliothèque externe. Cette règle ne dort pas dans un README où elle se périme en trois sprints : elle tourne en CI, et un import interdit casse le build. Le test lit les sources, résout les imports (y compris les dynamiques, qui contourneraient la règle) et rend la liste des violations.
Le cas réel : un module de métrologie énergie & confort réécrit feature par feature, dans l'ordre des numéros, le back intact sous l'ensemble. La plus grosse est aussi la plus sensible, donc la dernière : chaque feature réécrite autour d'elle est une prise sûre de plus, et le jour où on l'ouvre, on ne l'ouvre plus depuis le legacy.
Trois fils rouges structurent mon parcours : réécrire, transmettre et prendre des responsabilités.
Il se déploie ici en strates.
Plateformes web de suivi énergétique temps réel : graphiques, tableaux, données capteurs, pour la transition énergétique des bâtiments. Et la réécriture hexagonale du détail D-03 : le module de métrologie. React, Django, dataviz.
Formation professionnelle au développement, par groupes de 10 à 20 personnes : Java, Python, React (composants, props/état, hooks, routage, React Hook Form, gestion d'état, introduction à la sécurité), TypeScript, Git complet, jQuery/DOM/AJAX. Deux ans et demi à mener des débutants jusqu'à une application qui tourne.
Co-fondateur & responsable technique : React/Next.js, back Python, CI/CD, standards de qualité, IA intégrée au flux de production. La responsabilité de bout en bout, du cadrage à la mise en production.
déc. 2025
à mai 2026
avr. 2023
à juil. 2025
sept. 2022
à mars 2023
févr.
à mars 2022
sept. 2021
à févr. 2022
avr. 2019
à sept. 2021
juil. 2016
« Un bon projet, c'est un projet maintenable, testable et évolutif, pensé pour durer et s'adapter. »
Toute candidature sérieuse soulève des objections. Voici les cinq que je m'attends à entendre, et mes réponses, honnêtes, y compris quand la réponse est « pas encore ».
chaque réponse renvoie à la section du dossier qui la porte.
R-01 « Côté back, nous sommes Symfony/PHP ; vous venez de Python. »
Votre annonce demande d'être à l'aise pour s'y plonger, pas d'être expert. L'architecture hexagonale a cette vertu : un use case, un port, un adapter se lisent pareil en PHP et en Python. Et j'ai commencé par C (42) et Java (Dawan) : changer de langage ne m'a jamais arrêté.
R-02 « TanStack Query et Table : vous ne les avez jamais mis en production. »
TanStack Query formalise un problème que j’ai déjà résolu moi-même : le cache de l’état serveur, découplé du reste de l’application. Dans une architecture ports-adapters, son adoption consiste principalement à remplacer l’adapter, pas à redéfinir la frontière, le modèle ou les responsabilités. Je dois apprendre l'outil mais pas le problème.
R-03 « Vous n'avez pas d'expérience officielle en tant que Tech Lead»
Le titre ne change pas ma façon de travailler.
J'ai déjà assuré la transmission des connaissances en tant que formateur professionnel pendant deux ans et demi, puis la responsabilité technique complète des projets en tant que cofondateur.
Devenir Tech Lead, c'est simplement formaliser ce que je fais déjà : définir un niveau d'exigence, prendre les décisions techniques, garantir la qualité du code produit par l'équipe et assumer ces décisions lorsqu'elles sont difficiles.
R-04 « Pourquoi Mentor Goal, sincèrement ? »
Parce que j'ai été des deux côtés de votre produit. Pendant deux ans et demi, j'ai formé des groupes de dix à vingt personnes en formation professionnelle, chez Dawan puis Konexio : j'ai vu ce que c'est qu'un premier emploi qui ne vient pas, et j'ai travaillé dans l'organisme qui doit ensuite rendre des comptes sur ce que devient sa promotion. Vos deux utilisateurs, l'étudiant sous pression et l'école qui pilote son insertion, je les ai eus l'un et l'autre en face de moi. Sept ans que j'écris du React ; c'est la première fois que je peux le faire sur un métier que je connais de l'intérieur.
R-05 « Vous produisez beaucoup avec l'IA : qui répond de ce qui part en production ? »
Moi, et vous pouvez le vérifier sans me croire sur parole. JobTrack est écrit avec mon harness Claude Code : 76 tests, un test d'architecture qui fait échouer le build si le domaine importe la moindre dépendance technique, 98,37 % de score de mutation. Les règles, les corrections & la review sont effectués par moi-même.
C'est ma méthode de prise de poste, pas un engagement sur un code que je n'ai pas encore vu. Le détail des priorités s'ajustera à la réalité du terrain et à ce que l'équipe m'apprendra ; la démarche, elle, reste la même.
le calendrier s'ajuste, les livrables restent dus.
Livrer en production dès la première semaine, même une correction minuscule : un bug corrigé vaut mieux qu'un modèle mental parfait. Lire le code avant de le juger. Carte des zones de douleur du legacy : couplages, tests manquants, composants dupliqués. Observer le flux réel des MR. Pairing avec chaque dev. Passer du temps dans les tickets du support et les retours utilisateurs : l'interface ne prend son sens que par les yeux de ceux qui s'en servent. Comprendre le harness Claude Code existant.
Livrable un premier correctif en production, et une carte du legacy et des risques partagée à l'équipe.
Conventions co-écrites : definition of done, stratégie de test, frontières entre couches. Premier refactoring ciblé, en Mikado, sur une douleur réelle et bornée. Vérifier ce que la couverture protège réellement, en premier lieu les use cases.
Livrable un refactoring livré en production, des standards écrits et adoptés.
Rituel de review pédagogique. Design system : absorber dans Storybook les composants les plus dupliqués. Étendre le harness IA d'un skill ou d'un hook utile à une tâche répétitive de l'équipe.
Livrable des standards que l'équipe tient sans moi dans la pièce.
Je n'ai pas encore vu votre code : rien ici n'est donc une recommandation. Six hypothèses : chacune tient en une phrase et se termine par « à vérifier ».
une hypothèse ne préjuge de rien : elle dit seulement où regarder d'abord.
Le coverage ratchet protège-t-il ce qui casse vraiment (les use cases) ou additionne-t-il du volume ? Un cliquet ciblé par couche mesurerait mieux.
à vérifierLes contrats front ↔ back pourraient-ils être générés depuis API Platform (OpenAPI → types TS) plutôt qu'écrits à la main ? À confronter à vos gateways.
à vérifierLes frontières de couches (UI / use cases / gateways) pourraient être encodées en règles d'import Biome : la vigilance des reviewers en serait libérée.
à vérifierCapacitor : que coûte réellement la couche hybride aux Web Vitals mobiles ? Mesurer avant d'optimiser quoi que ce soit.
à vérifierLes checklists implicites de vos reviews pourraient devenir des hooks et skills du harness Claude Code, pour réserver la review humaine à ce qui s'enseigne.
à vérifierSpec-driven development : vos specs pourraient-elles devenir des tests d'acceptation exécutables ? À essayer sur une feature moyenne.
à vérifierVous cherchez un senior qui livre des interfaces de données complexes, qui sait entrer dans du code qu'il ne connaît pas, et qui traite l'IA comme un outil dont il connaît les limites. Je cherche une équipe dont le produit mérite les cinq prochaines années de mon meilleur travail.
30 minutes pour savoir si ces deux recherches s'arrêtent ici ? J'apporte des réponses honnêtes à vos questions les plus dures, des avis tranchés sur les tableaux de bord, et mes propres questions sur le vôtre. Entretien, revue de code ou pairing, au format qui vous arrange.