QCM & Entretien

Mon approche consiste à poser une architecture qui sépare:

• le domaine métier
• la logique applicative
• la couche d'accès aux données
• le design system / UI layer

Je privilégie une organisation architecture vertical slice, avec des frontières par domaine fonctionnel, pour éviter un front monolithique difficile à faire évoluer. L'objectif est que chaque feature puisse évoluer sans créer de couplage excessif avec le reste de l'application. Je fais aussi très attention à la distinction entre :

• server state : données issues du backend, cycle de vie réseau, cache, invalidation
• client state : préférences UI, état local, navigation, formulaires
• état dérivé : données calculées à ne pas stocker inutilement

Pour moi, une bonne architecture front, c'est une architecture qui permet de livrer vite aujourd'hui sans compromettre demain. Elle doit être :

• modulaire, pour isoler les évolutions
• lisible, pour faciliter l'onboarding
• testable, pour limiter les régressions
• et évolutive, pour absorber les changements métier

Je fais aussi très attention à la séparation des responsabilités : UI, logique métier, et accès aux données. L'objectif, ce n'est pas d'avoir une architecture parfaite, mais une architecture adaptée au contexte et capable d'évoluer.

Je commence toujours par le contexte :

• taille de l'équipe
• complexité métier(je parle du niveau de logique, de règles, de cas particuliers et d'interactions nécessaires pour implémenter une fonctionnalité. Plus il y a de règles, de variations et de dépendances, plus la complexité métier est élevée.)
• contraintes de performance
• horizon du projet

Ensuite, je compare plusieurs options et j'analyse les trade-offs :

• complexité
• maintenabilité
• coût d'évolution

Et surtout, je distingue les décisions réversibles des décisions structurantes. Je préfère souvent une solution simple au départ, quitte à la faire évoluer, plutôt qu'une sur-architecture trop tôt.

Pour éviter la dégradation de l'architecture, c'est une question de gouvernance.

Je mets en place :

• des règles de structure
• des conventions
• des revues régulières

Et je traite la dette technique de manière continue.

Une architecture ne se dégrade pas d'un coup, elle dérive progressivement si on ne la maintient pas.

Je mets des garde-fous automatiques et des standards d'équipe.

Pourquoi

Sur plusieurs applications, la qualité ne peut pas dépendre uniquement de la bonne volonté des développeurs.

Comment

• TypeScript strict ;
• ESLint ;
• Prettier ;
• tests unitaires ;
• tests composants ;
• tests E2E sur parcours critique ;
• CI GitLab ;
• règles d'import ;
• revue de code ;
• Storybook.

Exemple: Une MR qui modifie une règle métier doit lancer :

• typecheck
• lint
• tests rules
• tests composants
• build storybook
• E2E parcours souscription

On découpe par type technique: components/ hooks/ services/ store/ utils/

Pourquoi

Au début, c'est facile à comprendre : tous les composants sont ensemble, tous les services sont ensemble.

Limite

Quand le projet grossit, une feature est dispersée partout. Exemple : pour modifier la souscription, je dois toucher : components/ hooks/ services/ store/ utils/

Donc c'est plus difficile à maintenir.

On découpe par domaine métier.

Pourquoi

Parce que toute la logique d'une feature est au même endroit.

Comment Pour un parcours de souscription

Exemple

Si je dois modifier la règle "offre premium \= justificatif obligatoire", je vais directement dans : features/subscription/rules/[documents.rules.ts](http://documents.rules.ts)

Pas besoin de chercher partout.

L'architecture horizontale organise le code par technique, la verticale l'organise par capacité métier.

Je structure le code autour des capacités métier, pas autour des types techniques uniquement. Typiquement, je distingue :

• un socle app/core pour le bootstrap, routing, providers, configuration transverse
• des modules features par domaine métier
• des éléments shared uniquement quand ils sont réellement mutualisables
• une couche ui/design-system séparée du métier
• une couche api/services pour les contrats et échanges backend

Je suis vigilant sur un point : beaucoup de projets ont un dossier shared ou common qui devient un fourre-tout. le mieux de mettre des règles de gouvernance pour éviter:

• ownership explicite
• conventions d'import
• contrôle des dépendances entre modules
• lint rules

Je cherche à préserver :

• la lisibilité
• l'isolabilité des features
• la testabilité
• la capacité à onboarder rapidement de nouveaux développeurs

Je distingue les composants UI purs, les composants de pattern(un composant qui encapsule une logique réutilisable ou une structure d'interaction, afin d'éviter de répéter du code et d'uniformiser les comportements dans l'application) et les composants métier.

Pourquoi Tous les composants ne doivent pas vivre au même niveau. Sinon le design system devient un fourre-tout.

Comment

• design-system(Button, Input, Modal, Select)

• patterns(FormSection, Stepper, ErrorSummary)

• features/subscription/IdentityStep DocumentsStep/SubscriptionSummary

Button est générique, donc design system. Stepper peut être un pattern réutilisable. IdentityStep reste métier, donc dans subscription.

Pour moi, la bonne maîtrise ne se limite pas aux hooks standards. Elle se mesure à la capacité à utiliser React et TypeScript pour réduire la complexité, pas pour la déplacer.

Sur React, j'attends une vraie maîtrise de (je maitrise) :

• la composition de composants
• les hooks custom
• le contrôle des re-renders
• la séparation container / presentational quand elle a du sens
• les patterns de rendu conditionnel robustes

Sur TypeScript, j'attends (je maitrise) :

• un mode strict assumé
• des types métier explicites
• des unions discriminées pour gérer les états applicatifs
• des generics utiles et lisibles
• un typage fiable des contrats d'API
• l'élimination progressive des zones non typées

Un design system n'est pas une bibliothèque de composants. C'est un produit transverse qui sert à industrialiser la cohérence visuelle, fonctionnelle et technique. Je le vois comme un ensemble de couches :

• design tokens : couleurs, spacing, typo, radius, motion
• fondations : grille, iconographie, responsive, accessibilité
• composants primitifs : bouton, input, modal, tooltip, etc.
• composants composites : patterns métier ou d'usage
• documentation : règles d'usage, do/don't, exemples
• gouvernance : versioning, roadmap, ownership, contribution model

Oui, j'ai eu l'occasion de travailler sur la mise en place et l'évolution d'un design system, notamment chez OUIGO. Au départ, on avait surtout une collection de composants, mais pas un vrai design system structuré. L'enjeu a été de passer d'une logique de composants isolés à un système cohérent et industrialisé. On a commencé par poser des bases claires :

• des design tokens (couleurs, spacing, typographie)
• une séparation entre composants UI génériques et composants métier
• une logique de composants réutilisables et composables

L'objectif était d'éviter la duplication et d'avoir une cohérence visuelle sur toute l'application. On a mis en place Storybook comme source de vérité. Chaque composant était :

• documenté
• testé visuellement

Ça a vraiment aidé à aligner les équipes dev, QA et design.

Storybook est pour moi un outil d'industrialisation, pas juste une vitrine.

Je l'utilise pour :

• documenter les composants
• exposer leurs variantes
• rendre visible le contrat d'usage
• intégrer des tests visuels et d'accessibilité
• faciliter l'alignement entre design, QA et développement

Dans un cadre mature, Storybook devient un point central pour :

• la revue de composants
• la validation des états edge cases
• la diffusion des bonnes pratiques
• la réduction des régressions UI

Je veille aussi à ce que les stories reflètent la réalité produit :

• états loading / error / empty
• données réalistes
• variantes d'accessibilité
• responsive
• thème clair / sombre si nécessaire

j'ai utilisé Storybook principalement comme un outil d'industrialisation du design system, pas juste comme une documentation de composants. Chez OUIGO, je suis intervenu dans sa mise en place et son adoption.

1- Structuration

J'ai contribué à organiser les composants dans Storybook :

• composants UI génériques (boutons, inputs, modals…)
• composants plus complexes(exemple formulaire complexe, recheche/filtre)
• séparation claire entre UI et logique métier

L'idée était d'avoir une vision claire et navigable du système de composants.

2. Documentation

• J'ai documenté chaque composant avec :
• ses props typées (TypeScript)
• ses différents états (loading, disabled, error…)
• des exemples d'usage

Ça permet aux devs et aux QA de comprendre rapidement comment utiliser les composants sans aller lire le code.

Je pars toujours de la nature du problème, pas de la mode technique. Ma règle principale est la suivante :

• React Query / SWR pour le server state
• Redux Toolkit pour les logiques globales complexes, traçables et structurées
• Zustand pour des besoins plus locaux ou transverses simples, quand on veut de la légèreté

Cette séparation de responsabilité, ça permet d'éviter d'utiliser un store global pour stocker des données serveur qui devraient être gérées par un moteur de cache spécialisé.

Redux Toolkit reste pertinent quand il y a :

• workflows complexes
• orchestration métier
• besoin de prédictibilité
• debugging fin
• historique des transitions d'état

Mais je m'assure toujours que son usage reste justifié, car une mauvaise utilisation de Redux rigidifie rapidement l'application.

Je traite la performance comme un sujet d'architecture et de mesure, pas comme une série de micro-optimisations.

Je travaille à trois niveaux :

1. Performance de chargement

• découpage du bundle
• lazy loading par route et par feature
• réduction du JavaScript inutile
• optimisation des dépendances
• stratégie de préchargement raisonnée

2. Performance de rendu

• limitation des re-renders
• memoization ciblée
• normalisation éventuelle des données
• virtualisation des longues listes
• composants contrôlés avec discipline

3. Performance perçue

• skeletons cohérents
• priorisation du contenu critique
• gestion fine des transitions

Je m'appuie sur des indicateurs concrets :

• Core Web Vitals(evitez)
• Lighthouse
• Web Vitals en production
• bundle analysis
• profilage React

Je fais attention à ne pas "optimiser au hasard". Je cherche d'abord les vrais goulets :

• sur-rendu
• requêtes redondantes
• surcoût de librairies
• hydration ou routing coûteux
• composants trop génériques ou trop connectés au store

Je les traite comme des indicateurs de qualité de service. Les seuils "bons" généralement visés sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1. Je regarde en priorité :

• LCP(Largest Contentful Paint) pour la vitesse d'affichage de l'élément principal
• CLS(Interaction to Next Paint) pour la stabilité visuelle
• INP(Cumulative Layout Shift) pour la réactivité de l'interface

Mais surtout, je ne me limite pas aux mesures de labo. Je veux de la donnée terrain, segmentée si possible par :

• device
• navigateur
• type de parcours
• contexte réseau

Comment je les utilise

Ma démarche est toujours en trois temps : mesurer, diagnostiquer, corriger."

D'abord, je regarde la métrique qui dégrade le parcours. Pour ça, je combine généralement plusieurs sources :

• terrain / field data quand c'est disponible, parce que c'est ce qui reflète la vraie expérience utilisateur ;
• mesures locales pour reproduire le problème ;
• puis trace DevTools pour identifier la cause racine. Les outils Chrome récents mettent justement en avant les métriques CWV directement dans le panneau Performance, avec une vue live puis une analyse détaillée via les traces.

Ensuite, je ne traite pas tous les problèmes de la même façon :

• si le sujet est LCP, je regarde surtout le poids des ressources critiques, l'ordre de chargement, les images, le JS bloquant, ou parfois le backend si la réponse initiale est lente ;
• si le sujet est INP, je vais plutôt chercher du JavaScript lourd, des handlers trop coûteux, des re-renders inutiles, ou des interactions qui déclenchent trop de travail côté UI ;
• si le sujet est CLS, je cherche les décalages de layout : images sans dimensions, contenu injecté tardivement, composants qui changent de taille après rendu.

Ce que j'ai fait concrètement

"Chez OUIGO, sur des pages critiques de parcours, j'ai utilisé cette logique pour cibler les problèmes de performance plutôt que d'optimiser à l'aveugle."

Sur un cas de page de résultats ou de parcours sensible, la première étape a été d'identifier ce qui pénalisait réellement l'expérience :

• appels API redondants,
• composants non critiques chargés trop tôt,
• et re-renders inutiles côté React.

À partir de là, j'ai mis en place des actions ciblées :

• meilleure gestion du cache et du refetch avec un outil de server state,
• lazy loading sur les blocs secondaires,
• code splitting sur certaines parties du parcours,
• réduction des re-renders avec une meilleure maîtrise de la composition et des dépendances des hooks,
• et stabilisation de certains composants pour éviter les sauts visuels.

"L'idée n'était pas de 'faire plaisir à Lighthouse', mais d'améliorer un parcours business critique, notamment sur mobile.

Je travaille sur trois axes :

• sémantique : structure HTML correcte, rôles natifs privilégiés
• interaction : navigation clavier, focus management, pièges à focus maîtrisés
• perception : contrastes, feedback, libellés, erreurs compréhensibles

Je cherche à rendre les composants accessibles par défaut, au niveau du design system, pour éviter de redécouvrir les mêmes problèmes feature par feature.

Je distingue toujours :

• la dette utile et assumée, prise pour livrer un besoin
• la dette subie, qui dégrade durablement la capacité de delivery

Je pilote la dette avec une logique de risque :

• impact business
• fréquence de friction
• coût de maintenance
• risque de régression
• blocage pour les futures évolutions

Je formalise les sujets via backlog technique, critères de priorisation et parfois ADR. Je cherche surtout à rendre la dette visible et objectivable, pour sortir du débat subjectif.

Dans une taskforce, je ne me contente pas de corriger localement : je cherche les causes systémiques :

• conventions absentes
• architecture floue
• tests insuffisants
• ownership faible
• dépendances mal maîtrisées

Je vois l'IA comme un accélérateur de productivité, mais pas comme un substitut à l'ingénierie. Elle est très efficace pour augmenter la vitesse d'exécution, mais la responsabilité de la qualité, de l'architecture et de la cohérence reste clairement côté développeur."

Dans mon cas, je l'utilise de manière assez ciblée.

Sur mes projets personnels, j'utilise Claude Code, surtout pour :

• générer des premiers drafts de code ou de composants
• explorer rapidement des options d'implémentation
• challenger certaines approches techniques
• gagner du temps sur des tâches répétitives

Esprit critique (très apprécié en entretien)

J'ai aussi conscience des limites :

• elle peut proposer du code non optimal ou obsolète
• elle ne comprend pas toujours le contexte métier
• elle peut introduire de la dette technique si elle est mal utilisée

Donc en pratique, je fais toujours :

• une relecture critique
• une adaptation au contexte projet
• et une validation via tests

Je pense que l'IA va surtout changer la manière de travailler : moins de temps sur le code "mécanique", plus de temps sur la conception, la qualité et les décisions d'architecture.

Pour moi, un bon développeur en 2026, ce n'est plus seulement quelqu'un qui sait coder.

C'est quelqu'un qui a un vrai mindset d'architecte, capable de prendre du recul et de penser le système dans son ensemble.

Il sait abstraire un problème, transformer un besoin métier en spécifications claires, et concevoir des solutions robustes, maintenables et évolutives.

Il accorde beaucoup d'importance à la qualité du code : un code lisible, testable, facile à faire évoluer. Et il a une vraie rigueur sur les tests, parce qu'il sait que la qualité ne se rajoute pas après.

Mais au-delà de la technique, il comprend le besoin utilisateur, il est capable de le challenger, et de proposer des solutions pertinentes, pas juste d'exécuter.Il sait aussi travailler en équipe : communiquer ses idées, aligner les choix techniques,

Et enfin, il développe de manière itérative, en livrant de la valeur régulièrement, plutôt que de chercher la solution parfaite dès le départ

La complexité, je la traite surtout par la structure et la discipline.

Je fais en sorte que :

• chaque module ait une responsabilité claire
• les dépendances soient maîtrisées
• les abstractions soient utiles, pas inutiles

Et j'évite de sur-abstraire trop tôt.

Je préfère une complexité visible et contrôlée plutôt qu'une complexité cachée dans des couches trop génériques.

Je pense la scalabilité à deux niveaux :

Technique :

• modularité
• découplage
• performance

Organisationnel :

• autonomie des équipes
• conventions communes
• design system partagé

Parce qu'une application ne devient pas complexe uniquement à cause du code, mais aussi à cause du nombre de personnes qui travaillent dessus.

Je considère que le front doit être représenté très tôt dans les arbitrages, sinon on hérite de contrats sous-optimaux.

Je contribue sur :

• la définition des payloads
• la granularité des endpoints
• la gestion des erreurs
• la cohérence des statuts
• les besoins de pagination, filtrage, tri
• les contraintes de performance
• les impacts UX des choix backend

Mon rôle est aussi de faire le lien entre :

• intention produit
• faisabilité UX
• cohérence technique
• coût long terme

Un front ne doit pas seulement "consommer" l'API : il doit participer à la rendre exploitable efficacement.

Pour moi, la collaboration avec les équipes UI/UX est essentielle, surtout sur des produits à fort enjeu comme ceux que j'ai pu avoir chez OUIGO.

Je vois ça comme une collaboration continue, pas juste un passage de maquette à implémentation.

Implication en amont: J'essaie d'intervenir le plus tôt possible dans la phase de conception.

Quand les designers travaillent sur une feature, je participe aux discussions pour :

• challenger la faisabilité technique
• anticiper les impacts (performance, accessibilité, complexité)
• proposer des alternatives si nécessaire

Ça évite de découvrir des problèmes trop tard.

Travail avec le design system: On s'appuie beaucoup sur le design system pour aligner design et développement.

Avec Storybook, on a un référentiel commun :

• les composants existants
• leurs limites
• leurs variantes

Ça évite de redéfinir des composants à chaque fois.

Feedback continu: "Pendant le développement, je fais des points réguliers avec les designers :

• validation des écrans
• ajustements
• gestion des edge cases

On évite l'effet 'livraison finale surprise'."

Oui, systématiquement. Sur la plupart de mes missions, j'ai travaillé en collaboration étroite avec les équipes produit, notamment chez OUIGO ou encore chez La Poste.

Pour moi, le développeur ne doit pas être seulement un exécutant, mais un vrai partenaire du produit.

Compréhension du besoin: "Je commence toujours par bien comprendre le besoin métier :

• quel problème utilisateur on cherche à résoudre
• quels sont les objectifs
• quelles sont les contraintes

Ça me permet de proposer des solutions plus pertinentes, pas juste de coder une spécification."

Challenge des besoins: "Je challenge régulièrement les demandes quand c'est nécessaire.

Par exemple :

• simplifier une feature trop complexe
• proposer une alternative plus rapide à implémenter
• anticiper des cas non couverts

Toujours dans une logique d'apporter de la valeur.

Oui, j'utilise le Definition of Ready et le Definition of Done comme des garde-fous pour sécuriser le delivery et éviter les incompréhensions. Je les ai utilisés notamment sur mes projets chez OUIGO et La Poste

"Le DoR, pour moi, c'est ce qui garantit qu'une user story est prête à être développée. Concrètement, je vérifie que :

• le besoin est clair et compris
• les critères d'acceptation sont définis
• les cas limites sont identifiés
• les dépendances sont connues
• et qu'il n'y a pas de zone d'ambiguïté

Pendant les refinements, je challenge beaucoup sur ces points. Si une story n'est pas 'ready', je préfère la repousser plutôt que de commencer avec des incertitudes."

Utilisation au quotidien 💬 "Au quotidien, ça me sert surtout à :

• éviter les allers-retours
• améliorer la qualité dès le départ
• aligner toutes les équipes (dev, QA, produit)

C'est aussi un outil de communication, pas juste une checklist."

💬 "Le DoD, c'est ce qui garantit que la feature est réellement terminée, pas juste développée. Dans mes projets, ça inclut généralement :

• code développé et relu
• tests unitaires passés
• intégration validée
• respect des standards (lint, typage)
• accessibilité vérifiée
• validation fonctionnelle
• et déploiement sur un environnement de test

Parfois, on ajoute aussi :

• documentation
• mise à jour Storybook si nécessaire"

Pour moi, l'agilité est surtout un cadre qui permet de mieux collaborer et de livrer de la valeur rapidement, mais ce n'est pas une fin en soi.

Ce que j'apprécie vraiment :

• la collaboration transverse: Pouvoir travailler étroitement avec le produit, le design et le backend, ça permet d'aligner rapidement les décisions et d'éviter les silos.

• la livraison incrémentale: Découper les features pour livrer régulièrement, avoir du feedback rapide, et ajuster en fonction — ça réduit beaucoup les risques.

• la flexibilité: On peut s'adapter aux changements de priorités sans remettre tout le projet en cause.

Ce que j'aime moins: Ce que j'aime moins, c'est quand l'agilité devient trop 'ritualisée' ou dogmatique.

Par exemple :

• trop de cérémonies sans vraie valeur
• des sprints remplis mais sans vraie priorisation
• ou des user stories mal définies

Dans ces cas-là, on perd l'objectif principal qui est de livrer de la valeur."

Oui et Non, j'ai déjà travaillé dans des contextes proches d'une taskforce, chez OUIGO et sur des projets critiques chez La Poste.

Même si ce n'était pas appelé officiellement 'taskforce', on était clairement dans des situations avec :

• des délais courts
• des enjeux forts
• et une nécessité de débloquer rapidement

Comprendre rapidement la situation

"Ma première étape, c'est toujours de comprendre :

• où sont les blocages
• quelles sont les priorités réelles et quels sont les risques

Je fais souvent un état des lieux rapide :

• code
• architecture
• organisation

Pour éviter d'agir à l'aveugle."

Prioriser l'impact "Dans une taskforce, on ne peut pas tout faire.

Je me concentre sur :

• les points bloquants
• les quick wins
• ce qui apporte le plus de valeur rapidement

L'objectif, c'est de débloquer la situation le plus vite possible."

Simplifier

"J'essaie aussi de simplifier :

• réduire le scope
• éviter la sur-architecture
• proposer des solutions pragmatiques

Dans ce contexte, la perfection n'est pas l'objectif, la livraison l'est.

Communication

"La communication est clé.

Je fais des points réguliers avec :

• le produit
• les équipes techniques
• les parties prenantes

Pour aligner tout le monde et éviter les malentendus.

Les deux termes sont proches, mais ils n'ont pas du tout le même périmètre.

System Design: Le system design concerne la conception globale d'un système.

On parle de :

• architecture
• scalabilité
• performance
• communication entre services
• gestion des données

Par exemple :

• comment structurer une application front
• comment elle communique avec le backend
• comment gérer la montée en charge

C'est une vision macro, orientée architecture."

Design System: "Le design system, lui, est centré sur l'interface utilisateur et l'expérience.

Il regroupe :

• les composants UI
• les design tokens (couleurs, typo…)
• les règles d'usage
• la documentation

L'objectif est d'assurer la cohérence visuelle et fonctionnelle."

Différence clé Donc :

• le system design → comment le système fonctionne
• le design system → comment l'interface est construite et présentée

Les deux sont complémentaires, mais à des niveaux différents."

Le system design est une problématique d'architecture, alors que le design system est une problématique d'interface et de cohérence UI.

Je vois les micro-frontends comme une solution organisationnelle, pas technique.Le Le frontend est découpé en plusieurs applications indépendantes, souvent par domaine métier ou par équipe.

C'est utile quand :

• plusieurs équipes doivent travailler de manière indépendante
• les cycles de release doivent être découplés

Mais ça introduit aussi de la complexité :

• duplication
• performance
• cohérence UI

Donc je ne les utilise que si le besoin est réel.

Sinon, un monolithe modulaire est souvent plus simple et efficace.

Comment l'implémenter

On peut utiliser :

• Module Federation ;
• single-spa ;
• Web Components ;
• intégration par routes ;
• shell applicatif.

Exemple:

Une équipe gère le parcours de souscription, une autre le paiement. Chaque équipe déploie son frontend indépendamment, mais le shell gère la navigation, l'authentification et le layout global.

Les micro-frontends sont une réponse à un problème d'organisation, pas une solution à appliquer par défaut.

Une seule application frontend contient tous les domaines : souscription, profil, paiement, dashboard, etc.

Le monolithe, pour moi, n'est pas un mauvais mot. Un monolithe bien structuré, modulaire, peut être très efficace, surtout quand on veut aller vite, garder une forte cohérence et éviter une complexité distribuée trop tôt.

Je le trouve souvent pertinent au démarrage d'un produit, ou quand les équipes ne sont pas encore suffisamment découplées pour justifier une architecture plus distribuée.

Les microservices deviennent intéressants quand on a de vrais besoins d'autonomie entre domaines ou entre équipes, des cycles de livraison différents, ou des contraintes de scalabilité spécifiques.

Mais je reste prudent, parce que ça introduit beaucoup de complexité :

• gestion du réseau
• observabilité
• contrats inter-services
• versioning
• résilience
• et gouvernance globale

Donc je ne recommande jamais les microservices par principe. Je les vois comme une réponse à un problème d'échelle organisationnelle et technique, pas comme un standard par défaut.

Le monorepo, je le trouve très pertinent quand plusieurs applications ou packages doivent partager :

• des composants
• des utilitaires
• des standards
• ou un design system

Ça facilite la cohérence, la réutilisation, et la mise en place de règles communes.

En revanche, il faut bien le gouverner, sinon ça peut devenir compliqué :

• builds plus lourds
• dépendances mal maîtrisées
• frontières floues entre modules

Donc pour moi, le monorepo est très puissant, mais il a besoin de discipline.

Le BFF, je le trouve très utile côté front, surtout quand plusieurs clients ont des besoins différents, par exemple web et mobile.

L'intérêt, c'est de rapprocher la logique d'orchestration du besoin UI :

• agrégation de données
• adaptation des payloads
• simplification des appels côté front
• meilleure maîtrise de l'expérience utilisateur

Ça permet d'éviter que le front devienne une couche d'assemblage trop complexe.

Par contre, il faut éviter d'y mettre trop de logique métier, sinon on déplace juste la complexité ailleurs.

Pour moi, la prise de décision doit être à la fois collaborative et structurée

Bien cadrer le problème: Je commence toujours par clarifier :

• le contexte
• le besoin
• les contraintes

Proposer des options Ensuite, je propose généralement plusieurs options, avec leurs trade-offs :

• simplicité vs scalabilité
• rapidité vs qualité
• court terme vs long terme

Ça permet d'avoir une discussion constructive plutôt qu'un débat d'opinions.

Je structure la décision : je clarifie le problème, je propose des options avec leurs trade-offs, j'implique l'équipe, puis on décide rapidement et on documente.

Ça m'arrive, et pour moi ce n'est pas un problème en soi. Mon objectif, ce n'est pas que mon idée soit retenue, c'est que l'équipe prenne la meilleure décision possible.

Comprendre pourquoi: Je commence par comprendre pourquoi elle est refusée :

• contraintes que je n'avais pas vues
• priorités différentes
• risques identifiés par d'autres

Ça m'aide à ajuster ma vision."

Accepter et s'aligner: Si la décision est prise collectivement, je m'aligne. Même si ce n'était pas mon choix initial, je m'engage à faire en sorte que la solution retenue fonctionne bien."

Apprendre: Je garde aussi un retour d'expérience. Si plus tard on voit que certains points posent problème, ça permet de réévaluer de manière factuelle."

Je pense qu'à ce niveau, il faut être capable de défendre une idée, mais aussi de savoir lâcher prise quand une autre solution est choisie. L'important, c'est le résultat collectif

Je pense que ma valeur ajoutée, c'est surtout ma capacité à aller au-delà du développement pur. Je ne me limite pas à implémenter des fonctionnalités, je travaille sur la cohérence globale du produit et sa capacité à évoluer.

Vision globale: J'ai une approche orientée architecture : Je fais attention à la structuration, à la maintenabilité, et à la qualité long terme.Mon objectif, c'est que ce qu'on construit aujourd'hui reste exploitable demain.

Impact concret: Je suis aussi très orienté impact :

• amélioration de la performance
• mise en place de bonnes pratiques
• structuration du code
• réduction de la dette technique

Je cherche toujours à apporter de la valeur, pas juste à livrer du code.

Collaboration: Je travaille beaucoup en collaboration avec :

• le produit
• les designers
• le backend

Je challenge les besoins quand c'est nécessaire, et je propose des solutions adaptées.

Donc, je peux vous aider à livrer, mais aussi à améliorer durablement la qualité et la structuration de votre front.

Je peux apporter de la valeur à deux niveaux : livraison et structuration.

Pourquoi Votre enjeu n'est pas uniquement de produire du code, mais de réduire durablement le coût de maintenance.

Comment

• identifier la duplication ;
• structurer les composants ;
• isoler les règles métier ;
• standardiser les validations ;
• améliorer les tests ;
• contribuer aux choix d'architecture ;
• collaborer avec produit, UX et backend.

Exemple concret Si aujourd'hui une évolution de validation prend plusieurs jours parce qu'il faut modifier 16 applications, mon objectif serait de faire évoluer ça vers un changement centralisé, testé et propagé proprement."

Phrase finale :

"Ma valeur ajoutée, c'est de ne pas seulement livrer des features, mais de rendre le système plus simple à faire évoluer."

Même si l'équipe possède déjà ces compétences, je pense que je peux apporter de la valeur par mon expérience terrain et ma manière de travailler.

Mon objectif n'est pas de "réinventer" ce qui existe déjà, mais de renforcer l'équipe et contribuer rapidement sur des sujets complexes.

Par exemple, sur mes expériences chez [OUIGO](https://www.ouigo.com?utm_source=chatgpt.com), La Poste ou Nexity, j'ai travaillé dans des environnements où :

• les exigences qualité étaient déjà élevées,
• les équipes étaient déjà expérimentées,
• les pratiques étaient déjà bien installées.

Pourtant, il y avait toujours de la valeur à apporter :

• améliorer certains parcours,
• optimiser des performances,
• réduire de la dette technique,
• fluidifier les échanges entre équipes,
• améliorer la maintenabilité,
• renforcer certains standards de développement.

Je pense aussi qu'une équipe forte devient encore meilleure quand les profils se complètent.

J'apporte notamment :

• une vision orientée produit et utilisateur,
• une expérience web + mobile,
• une forte sensibilité qualité,
• et une capacité à m'adapter rapidement à un contexte existant.

Et surtout, je suis quelqu'un qui aime collaborer et faire progresser le collectif :

• partager des bonnes pratiques,
• challenger techniquement de manière constructive,
• aider sur les sujets complexes,
• et contribuer à une dynamique technique positive dans l'équipe.

Dans 5 ans, je me vois continuer à évoluer vers un rôle avec plus d'impact, pas forcément en management direct, mais davantage sur la structuration technique et l'architecture."

Évolution naturelle: J'aimerais renforcer mon rôle sur :

• les décisions d'architecture
• la structuration des projets
• l'accompagnement des équipes

Avec une vision plus transverse.

Impact technique: Je me vois intervenir sur des sujets plus globaux :

• scalabilité
• performance
• design system
• qualité globale du front

Et contribuer à des choix structurants.

Oui, de ce que j'ai compris, vous recherchez un développeur front-end senior React pour intervenir dans une taskforce technique, avec un vrai enjeu de structuration et d'amélioration du front pour le parcours de la soucription.

Ce n'est pas juste un besoin de développement classique. Vous cherchez quelqu'un capable de :

• construire et faire évoluer des SPA robustes
• améliorer la qualité globale
• et intervenir sur des sujets structurants

Les enjeux techniques

Plusieurs axes tels que:

• mise en place ou évolution d'un design system (Storybook, composants réutilisables)
• gestion d'état avancée (Redux, React Query…)
• optimisation des performances (Core Web Vitals, lazy loading…)

J'ai aussi compris que vous attendez un profil capable de :

• contribuer aux choix d'architecture
• définir des bonnes pratiques
• et collaborer avec des équipes

Pourquoi ce poste vous intéresse ?

Ce qui m'intéresse dans ce poste, c'est qu'il ne s'agit pas seulement de développement, mais d'un rôle avec un vrai impact sur la qualité et la structuration du front

Le fait d'intervenir dans une taskforce technique est particulièrement intéressant pour moi, parce que ça implique :

• analyser un existant
• identifier des axes d'amélioration
• et apporter des solutions concrètes rapidement"

Alignement technique

Je retrouve aussi beaucoup de sujets sur lesquels j'ai déjà travaillé :

• design system et composants réutilisables
• performance front
• accessibilité
• qualité avec tests et CI/CD
• gestion d'état avancée
• Donc je me sens aligné techniquement avec vos enjeux.

Donc ce qui m'intéresse, c'est à la fois le challenge technique, l'impact sur le produit, et la possibilité d'intervenir sur des sujets structurants.

De ce que j'ai compris, vous avez un enjeu d'industrialisation du parcours de souscription. Aujourd'hui, il existe plusieurs applications ou parcours indépendants, avec probablement de la duplication, des règles métier dispersées, des validations pas toujours homogènes et un coût de maintenance élevé.

Pour moi, le sujet n'est donc pas seulement de développer de nouvelles features React. Le vrai enjeu est de construire un socle plus robuste, mutualisable et maintenable, afin de réduire le temps de delivery et le risque d'erreur.

Pourquoi c'est important :

Parce que si on continue à maintenir chaque parcours séparément, chaque évolution devient coûteuse et risquée.

Comment je ferais :

Je commencerais par cartographier les parcours existants, identifier les étapes communes, isoler les règles métier, mutualiser les composants, standardiser les validations et sécuriser le tout avec des tests.

Exemple concret :

"Si 16 applications ont toutes une étape d'identité client avec nom, prénom, email, téléphone, je ne veux pas maintenir 16 formulaires différents. Je crée une étape IdentityStep configurable, avec un schéma de validation commun, puis chaque application l'adapte via configuration."

J'industrialiserais le parcours en passant d'une logique de duplication à une logique de briques réutilisables."

Pourquoi :

Un parcours de souscription est critique : il contient des formulaires, des règles métier, des appels API, des validations, des erreurs et souvent une forte exigence UX. Si chaque application réimplémente ça différemment, on augmente mécaniquement les bugs et le temps de maintenance.

Comment :

• D'abord, je découpe le parcours en étapes fonctionnelles :IdentityStep, ContactStep, OfferStep, DocumentsStep, SummaryStep, ConfirmationStep
• Ensuite, je définis pour chaque étape :
• Puis je compose le parcours par configuration

Une application peut avoir l'étape documents, une autre non. Au lieu de créer deux parcours séparés, j'utilise le même moteur de parcours et je configure les étapes activées.

Je fais une cartographie fonctionnelle et technique."

Pourquoi : Avant de mutualiser, il faut savoir ce qui est vraiment commun et ce qui est spécifique. Sinon, on risque soit de sur-généraliser, soit de créer une abstraction inutilisable.

Comment :

- Pour chaque application, je documente :

• étapes du parcours
• champs demandés
• validations
• règles métier
• composants utilisés
• appels API
• erreurs possibles
• cas spécifiques

-Ensuite, je construis une matrice

Si je vois que 14 applications sur 16 utilisent une étape Documents, mais avec des variantes, je crée un DocumentsStep commun avec une configuration des types de documents demandés.

Je ne me base pas uniquement sur le nom des écrans, mais sur leur rôle fonctionnel.

Pourquoi :

Deux applications peuvent appeler une étape différemment : "Profil client", "Identité", "Informations personnelles", mais fonctionnellement, c'est la même chose.

Comment :

• Je regroupe les étapes par intention : Infos personnelles / Identité / Profil client \=> par IdentityStep
• Puis je définis un socle commun :

Si toutes les applications demandent nom/prénom/email, mais seulement certaines demandent le téléphone, je garde téléphone comme champ configurable, pas comme raison de dupliquer tout l'écran.

Je sors les règles métier des composants React pour les mettre dans des modules dédiés, testables et réutilisables.

Pourquoi :

Si une règle est dans le JSX ou dans plusieurs composants, elle devient difficile à retrouver, difficile à tester et facile à dupliquer.

Comment :

• Je crée un module métier
• Puis j'extrais la règle

Je teste les règles métier comme des fonctions pures.

Pourquoi Les règles métier sont critiques. Si elles changent, on doit savoir immédiatement quel comportement est impacté.

Quand le métier change une règle documentaire, je modifie la règle centrale, puis les tests me garantissent que je n'ai pas cassé les cas existants.

Je mets en place des schémas de validation partagés, avec des extensions pour les cas spécifiques.

Pourquoi : Si chaque application valide différemment, l'utilisateur peut avoir des comportements incohérents et l'équipe multiplie les bugs.

Comment :

• Avec Zod :
• Pour une app spécifique, on va étendre le schéma sans dupliquer toute la validation.

Le front valide pour améliorer l'expérience utilisateur, mais le backend reste la source de vérité finale.

Je différencie erreurs techniques et métier.

Pourquoi

Sinon UX mauvaise.

Comment

• Error Boundary → erreurs React
• mapping erreurs API → messages user
• fallback UI

Séparer UI et logique métier

Pourquoi: Sinon les composants deviennent trop gros et difficiles à tester. Les composants affichent, les règles métier décident.

Centraliser les appels API

Pour éviter les fetch dispersés partout

Tester les règles critiques

Les règles métier changent souvent et peuvent casser un parcours.

Éviter la sur-abstraction

Une abstraction créée trop tôt devient souvent plus difficile à maintenir que la duplication initiale. Je préfère une duplication temporaire claire à une abstraction prématurée floue.

Mettre l'état au bon endroit

• state local pour UI simple ;
• React Hook Form pour formulaires ;
• React Query pour server state ;
• Redux/Zustand pour état global complexe.

Patterns frontend

• Container / Presentational: Séparer logique et affichage
• Custom Hooks: Extraire la logique réutilisable.
• Compound Components: Créer des composants flexibles.
• Provider Pattern: Partager un contexte limité à une zone.
• Strategy Pattern: Changer un comportement selon le contexte.exemple validation différente selon type d'offre
• Adapter Pattern: Adapter une API backend à un modèle frontend propre.

C'est une fonctionnalité de Webpack qui permet de charger du code d'une autre app à runtime. Une app peut exposer des composants et une autre peut les consommer

Comment ça marche

Tu as :

• une app "remote" (ex: subscription)
• une app "host" (ex: shell)

Exemple

• équipe A → développe subscription-app
• équipe B → développe payment-app
• shell → assemble tout

Chaque équipe déploie indépendamment

Pourquoi utiliser

• indépendance des équipes
• déploiement séparé
• partage de composants dynamiquement

Attention

• gestion des versions React
• duplication des dépendances
• debugging plus complexe

Module Federation permet de charger dynamiquement du code distant sans rebuild global.

single-spa est un framework pour orchestrer plusieurs apps frontend dans une seule page.

Comment ça marche ?

Tu as une app principale qui décide. Selon la route → une app est montée ou démontée

Exemple

• /subscription → charge app subscription
• /payment → charge app payment

Single-spa agit comme un orchestrateur qui monte/démonte des micro-frontends selon la navigation.

Une app principale (shell) qui :

• gère layout
• auth
• navigation
• state global

Et charge les micro-frontends.

Comment ça marche ?

Le shell peut charger :

• Module Federation
• single-spa
• iframe
• dynamic import

Le shell agit comme la colonne vertébrale de l'application.

Dans une architecture avec plusieurs applications indépendantes, je ne veux surtout pas que chaque application gère sa propre authentification de manière isolée. Je centralise l'authentification, puis chaque application consomme une session commune et applique ses contrôles d'autorisation.

Authentification centralisée

Pour éviter que les 16 applications aient 16 gestions différentes du login, des tokens, des expirations et des refresh.

Je mets en place un fournisseur d'identité commun :

• SSO / OAuth2 / OpenID Connect ;
• Keycloak, Azure AD, Auth0, etc. ;
• redirection vers un login centralisé ;
• retour vers l'application avec une session valide.

Exemple

• Utilisateur → App A
• App A → redirige vers Identity Provider
• Identity Provider → authentifie
• Utilisateur → revient sur App A avec session active

Session partagée entre applications

L'utilisateur ne doit pas se reconnecter quand il passe de l'application A à l'application B.

Comment ?

Si les applications sont sur le même domaine ou sous-domaines, on peut utiliser un cookie sécurisé partagé

Le cookie HttpOnly n'est pas accessible en JavaScript, ce qui réduit le risque XSS.

Autorisation par rôle

On distingue :

• authentification : "qui es-tu ?"
• autorisation : "qu'as-tu le droit de faire ?"

Les rôles peuvent venir du token ou d'une API /me. Le front peut adapter l'interface selon les rôles, mais il ne doit jamais être la source de vérité de l'autorisation."

Entre applications indépendantes

Quand l'utilisateur passe d'une app à l'autre : appA -> app B

App B doit :

• vérifier que la session existe ;
• récupérer l'utilisateur courant ;
• charger ses rôles/permissions ;
• appliquer les guards de routes ;
• refuser l'accès si nécessaire.

Conclusion Je centralise l'authentification via un Identity Provider commun, puis je partage la session entre applications avec des cookies sécurisés ou un mécanisme SSO. Chaque application récupère l'utilisateur courant et ses permissions, applique des guards côté front pour l'UX, mais toutes les autorisations critiques sont revérifiées côté backend. Le front adapte l'interface, le backend garantit la sécurité.

L'authentification peut être partagée entre applications, mais l'autorisation doit toujours être vérifiée à chaque action sensible.

Question

-Sur ce parcours, qu'est-ce qui est déjà en place aujourd'hui et qu'est-ce qui reste à construire pour la mise en production dans 2 mois ?

-Avez-vous déjà défini un MVP clair pour la mise en production, ou le scope est encore en cours d'ajustement ?

-Est-ce que ce parcours s'appuie déjà sur un design system structuré, ou est-ce encore en construction ?

Comment est gérée l'authentification et la session entre les applications ?

Comment se fait la navigation entre les applications aujourd'hui ?(full reload 🔴iframe 🔴/routing partagé 🟢)

Aujourd'hui, les ralentissements viennent plutôt du chargement des applications ou des appels API ?(Est-ce que vous avez des métriques type Core Web Vitals ou Lighthouse sur ce parcours ?)

"Quelle est ton expérience sur React Native et les applications hybrides ?"

---

J'ai travaillé plusieurs années sur des applications hybrides React Native, notamment chez Nexity et aujourd'hui chez OUIGO.

Chez Nexity, nous avions une application mobile connectée à des APIs GraphQL avec Apollo, et nous utilisions Expo pour accélérer le développement et simplifier les déploiements.

Chez OUIGO, je travaille dans un contexte plus exigeant en termes de trafic et de qualité utilisateur. L'un des enjeux importants était d'assurer une cohérence entre web et mobile tout en gardant une bonne maintenabilité du code.

Concrètement, j'ai travaillé sur :

• des composants partagés,
• la gestion d'état avec Redux,
• les performances de rendu,
• les tests,
• l'accessibilité,
• et la stabilité des releases.

J'ai aussi participé à la mise en place de bonnes pratiques autour du découpage des composants, de la réutilisabilité et des conventions de développement pour limiter la dette technique.

---

"Qu'est-ce que ça veut dire pour toi une approche mobile-first ?"

---

Pour moi, le mobile-first ne veut pas seulement dire "adapter le responsive".

C'est penser l'expérience utilisateur d'abord pour les contraintes mobiles :

• performance réseau,
• temps de chargement,
• ergonomie tactile,
• lisibilité,
• stabilité,
• consommation mémoire,
• cycles de release plus longs.

Par exemple chez OUIGO, nous faisons particulièrement attention :

• au poids des composants,
• au lazy loading,
• à l'optimisation des appels API,
• et aux comportements offline ou réseau dégradé.

Sur mobile, une mauvaise expérience est très vite sanctionnée par les utilisateurs. Donc il faut être beaucoup plus rigoureux sur :

• la fluidité,
• les régressions,
• les crashs,
• et l'observabilité.

C'est aussi pour ça que j'accorde beaucoup d'importance aux tests automatisés et au monitoring.

---

"Quelle est ton approche des tests ?"

---

Je vois les tests comme un outil de sécurisation du delivery, surtout dans des applications utilisées à grande échelle.

Je privilégie généralement une pyramide de tests équilibrée :

• tests unitaires pour la logique métier,
• tests d'intégration pour sécuriser les flux critiques,
• et quelques tests end-to-end sur les parcours essentiels.

Chez OUIGO et Junior\&Cie, j'ai participé à la mise en place de tests Jest et de tests d'intégration intégrés dans la CI/CD GitLab.

Je fais attention à ne pas sur-tester l'implémentation mais plutôt les comportements métier.

Par exemple :

• validation de formulaires,
• gestion des erreurs API,
• affichage conditionnel,
• navigation utilisateur,
• gestion des états de chargement.

Sur mobile, les tests sont particulièrement importants parce que les cycles de validation sur stores sont plus coûteux en temps.

---

"Comment tu arbitres entre vitesse et qualité ?"

---

Je pense qu'il faut être pragmatique.

Toutes les fonctionnalités ne nécessitent pas le même niveau d'investissement technique.

Mon approche est généralement :

• identifier les zones critiques du produit,
• évaluer le coût futur de la dette,
• puis adapter le niveau de qualité attendu.

Par exemple, sur des composants stratégiques ou très réutilisés, je vais investir davantage :

• architecture claire,
• tests,
• documentation,
• Storybook,
• accessibilité.

À l'inverse, sur un MVP ou une feature exploratoire, je peux accepter un compromis temporaire si la dette est connue et maîtrisée.

L'important pour moi est que la dette technique soit consciente, documentée et priorisée, pas subie.

---

"Comment tu gères un incident en production mobile ?"

---

La première étape est de sécuriser les utilisateurs et mesurer l'impact :

• combien d'utilisateurs sont touchés,
• crash ou simple dégradation,
• Android/iOS,
• version concernée.

Ensuite :

• reproduction du problème,
• analyse des logs,
• vérification des dernières releases,
• rollback ou hotfix si nécessaire.

Chez OUIGO, la stabilité est très importante, donc nous faisons attention à :

• la CI/CD,
• les tests avant release,
• les environnements de validation,
• et la surveillance post-déploiement.

Après résolution, je considère qu'il est important de faire un retour d'expérience :

• cause racine,
• actions correctives,
• amélioration du process,
• ajout éventuel de tests pour éviter la régression.

---

"Quelle est ton expérience avec Expo ?"

---

J'ai utilisé Expo notamment chez Nexity dans le cadre d'une application React Native hybride.

J'apprécie Expo pour plusieurs raisons :

• rapidité de setup,
• simplification du tooling mobile,
• gestion des builds,
• OTA updates,
• et amélioration de la DX.

Je pense que c'est particulièrement pertinent pour des équipes sans équipe mobile native dédiée, comme chez Epsor.

Mais je connais aussi ses limites :

• dépendance à certaines APIs,
• contraintes natives spécifiques,
• gestion des performances dans certains cas.

Donc je vois Expo comme un excellent accélérateur lorsqu'il est utilisé dans le bon contexte produit.

---

"Comment travailles-tu avec les PM et Designers ?"

---

J'aime travailler très tôt avec le produit et le design.

Pendant les refinements, j'essaie de challenger :

• les parcours utilisateurs,
• les cas limites,
• les impacts techniques,
• la cohérence mobile/web,
• et la faisabilité.

Le fait d'échanger tôt évite beaucoup de problèmes plus tard.

Avec les designers, je fais particulièrement attention :

• à la cohérence des composants,
• à l'accessibilité,
• aux comportements responsive/mobile,
• et aux états d'erreur ou de chargement souvent oubliés dans les maquettes.

Je préfère une logique de collaboration continue plutôt qu'un simple passage de ticket.

---

Ne jamais critiquer.

---

Je suis très reconnaissant de mon expérience chez OUIGO, où j'ai beaucoup appris sur les produits à fort trafic et les enjeux de qualité.

Aujourd'hui, j'ai envie d'un environnement où je peux avoir encore plus d'impact sur les décisions Front et mobile, avec davantage d'ownership technique et de proximité produit.

Le contexte d'Epsor correspond bien à cette recherche, notamment avec :

• le mobile-first,
• la structuration des pratiques Front,
• et le rôle transverse attendu sur les applications.

Le CTO d'Epsor cherchera probablement quelqu'un qui :

• rassure techniquement
• structure naturellement
• communique bien
• sait prendre des décisions
• est pragmatique
• comprend les enjeux produit

J'aime travailler très tôt avec les Product Managers, avant même la phase de développement.

Chez OUIGO par exemple, pendant les refinements et grooming, nous challengions souvent ensemble :

• les parcours utilisateurs,
• les cas limites,
• les impacts mobiles,
• les dépendances backend,
• et les priorités de delivery.

Sur les parcours de réservation ou d'après-vente, il y avait beaucoup d'enjeux business et UX. Donc mon rôle n'était pas seulement de développer la feature, mais aussi d'aider à identifier :

• les risques techniques,
• les impacts performance,
• les comportements réseau,
• ou les complexités inutiles.

Par exemple, sur certaines fonctionnalités mobile, nous avons simplifié des parcours pour réduire le nombre d'étapes utilisateur et limiter les abandons.

J'essaie toujours d'apporter une vision pragmatique :

• ce qui apporte réellement de la valeur,
• ce qui peut être livré rapidement,
• et ce qu'il vaut mieux repousser ou simplifier.

---

Oui, régulièrement, mais toujours de manière constructive.

Chez Nexity par exemple, sur certains parcours mobiles, nous avions des écrans avec beaucoup d'informations et d'actions utilisateurs.

En travaillant avec le Product Manager et le Designer, j'ai remonté plusieurs points :

• surcharge cognitive,
• impacts performance sur mobile,
• complexité technique inutile,
• et risques de maintenance.

Nous avons finalement simplifié le flux :

• moins d'étapes,
• composants plus réutilisables,
• meilleure lisibilité mobile,
• et moins d'appels API.

Le résultat était meilleur à la fois :

• pour l'utilisateur,
• pour le delivery,
• et pour la maintenabilité.

Je pense qu'un développeur senior doit challenger quand c'est pertinent, mais toujours avec une logique de collaboration et de recherche de solution.

---

Je travaille de manière très proche avec les Designers, surtout sur les sujets mobile-first.

Chez OUIGO et Nexity, nous faisions régulièrement des échanges avant même le développement pour valider :

• les comportements responsive,
• les états de chargement,
• les cas d'erreur,
• les animations,
• et les contraintes techniques mobile.

J'aime aussi anticiper les problèmes d'accessibilité très tôt :

• contrastes,
• navigation clavier,
• tailles tactiles,
• feedback utilisateur,
• lisibilité mobile.

Sur plusieurs projets, Storybook nous aidait beaucoup dans cette collaboration parce qu'il permettait :

• de partager les composants,
• valider les comportements UI,
• et aligner rapidement design et développement.

Je préfère une logique de co-construction plutôt qu'un simple passage de maquettes.

---

J'essaie de participer aux décisions produit avec une approche orientée utilisateur et faisabilité.

Par exemple chez OUIGO, certaines fonctionnalités pouvaient sembler simples côté métier mais avoir :

• un fort impact performance,
• des risques mobiles,
• ou des dépendances backend importantes.

Mon rôle était alors :

• d'expliquer les contraintes,
• proposer des alternatives,
• estimer les impacts,
• et aider à prioriser.

Je pense qu'un développeur senior doit aider le produit à prendre des décisions éclairées, pas uniquement exécuter les demandes.

Et inversement, j'essaie aussi de comprendre les enjeux business :

• acquisition,
• conversion,
• satisfaction utilisateur,
• contraintes de temps,
• ou objectifs métier.

---

Quand je ne suis pas aligné avec une décision produit, j'essaie d'abord de comprendre les contraintes business derrière la demande.

Ensuite, j'explique mes préoccupations de manière factuelle :

• dette technique,
• performance,
• UX mobile,
• stabilité,
• ou coût futur.

J'évite les débats purement théoriques. Je préfère proposer :

• des alternatives,
• un MVP,
• un découpage,
• ou une approche progressive.

Chez La Poste par exemple, certains sujets avaient des contraintes fortes de planning et de réglementation. Donc il fallait trouver un équilibre entre :

• qualité,
• rapidité,
• et maintenabilité.

Je pense qu'un bon fonctionnement Produit/Tech repose surtout sur :

• la confiance,
• la transparence,
• et la capacité à prendre des décisions pragmatiques ensemble.

---

J'essaie toujours de garder l'utilisateur final en tête pendant le développement.

Chez OUIGO, les utilisateurs sont très variés :

• mobile,
• réseau parfois faible,
• usage rapide,
• moments de stress pendant les réservations.

Donc nous faisions très attention :

• au temps de chargement,
• à la simplicité des parcours,
• à la lisibilité mobile,
• et aux erreurs utilisateurs.

Sur mobile, quelques secondes de friction peuvent suffire à faire abandonner un parcours.

Cela influence beaucoup mes choix techniques :

• performance,
• gestion des erreurs,
• simplicité UI,
• et stabilité des releases.

---

7. "As-tu déjà travaillé dans un contexte de forte collaboration transverse ?"

Oui, particulièrement chez OUIGO et La Poste.

Chez OUIGO, nous travaillions quotidiennement avec :

• Product Managers,
• UX/UI,
• backend,
• QA,
• équipes métier,
• et parfois marketing ou contenu via Drupal.

Comme les applications sont fortement utilisées, beaucoup de décisions impliquaient plusieurs équipes.

Par exemple, lors de certaines évolutions des parcours de vente, il fallait coordonner :

• le Front,
• les APIs,
• les contenus,
• le tracking analytics,
• et les contraintes métier.

Cela m'a appris à :

• communiquer clairement,
• anticiper les dépendances,
• et garder une vision globale du produit.

---

Pour moi, un développeur senior apporte plus que du développement.

Il aide à :

• sécuriser les décisions,
• anticiper les risques,
• simplifier les solutions,
• améliorer l'expérience utilisateur,
• et maintenir un bon équilibre entre vitesse et qualité.

J'aime contribuer sur :

• la vision technique,
• la cohérence produit,
• les performances,
• et la maintenabilité long terme.

Je pense qu'un senior doit aussi aider l'équipe à mieux collaborer :

• avec le produit,
• le design,
• et les autres développeurs.

---

Parce qu'un bon produit ne vient pas uniquement d'une bonne idée ou d'une bonne implémentation technique.

Les meilleures solutions viennent généralement d'une collaboration forte entre :

• produit,
• design,
• et engineering.

Quand les développeurs sont impliqués tôt :

• on identifie mieux les risques,
• on simplifie certains parcours,
• on évite des coûts inutiles,
• et on améliore souvent l'expérience utilisateur.

Et inversement, comprendre les enjeux business aide aussi les développeurs à prendre de meilleures décisions techniques.

Je vois Expo comme un très bon accélérateur pour React Native, surtout dans une équipe sans équipe mobile native dédiée.

Expo apporte beaucoup de valeur sur :

• le setup projet
• les builds
• les mises à jour OTA
• la gestion des assets
• les permissions
• la developer experience
• la standardisation du tooling

Dans un contexte comme Epsor, avec une Universal App et une volonté mobile-first, Expo peut être très pertinent.

Mais je reste pragmatique :

• il faut vérifier les besoins natifs
• les performances
• les contraintes stores
• les dépendances Expo
• et la stratégie de release

Chez Nexity, Expo nous avait permis d'accélérer le développement mobile tout en gardant une bonne cohérence avec l'écosystème React.

---

Pour garantir la cohérence web/mobile, je distingue ce qui doit être partagé et ce qui doit rester spécifique.

Je partage volontiers :

• logique métier
• validation
• types TypeScript
• hooks
• clients API
• design tokens
• conventions UX

Mais je garde spécifique :

• certains composants UI
• navigation
• interactions tactiles
• permissions natives
• comportements liés au cycle de vie mobile

L'objectif n'est pas d'avoir 100 % de code partagé. L'objectif est d'avoir une expérience cohérente, maintenable et adaptée à chaque plateforme.

Chez OUIGO, cette approche était importante parce qu'il fallait garder une cohérence entre portail web, mobile et parcours utilisateur.

Comment vous gérez la publication sur l'App Store et le Play Store ?"

Sur mobile, la publication store est plus cadrée qu'un déploiement web, parce qu'on ne maîtrise pas entièrement le délai de validation ni la vitesse d'adoption par les utilisateurs.

Dans mes expériences React Native / Expo, le process était généralement le suivant :

• Préparation de la release On définit le périmètre : features, bugfixes, version applicative, changelog et risques éventuels.
• Génération du build On génère un build iOS et Android via la CI/CD ou via Expo EAS Build selon le projet.
• Validation interne Le build est testé sur un environnement de staging ou préproduction, avec validation QA / Product Owner sur devices réels ou BrowserStack.
• Distribution de test Pour iOS, on passe par TestFlight. Pour Android, on utilise une piste interne ou fermée Google Play.
• Validation finale On vérifie les parcours critiques : login, navigation, formulaires, affichage des données, erreurs réseau, performance et tracking.
• Soumission store Une fois validé, on soumet la version à l'App Store et au Play Store, avec les release notes, screenshots ou metadata si nécessaire.
• Déploiement progressif Quand c'est possible, on fait un rollout progressif, surtout sur Android, pour limiter le risque.
• Monitoring post-release Après publication, on surveille les crashs, erreurs API, analytics, retours utilisateurs et avis store.

Pour moi, un développeur senior ne se limite pas à produire des composants React.

Il doit être capable de prendre du recul sur l'architecture, la performance, la maintenabilité et l'expérience utilisateur. Next.js est un framework très complet, donc les mauvais choix peuvent avoir un impact important : trop de composants clients, mauvaise stratégie de cache, mauvais découpage des pages, ou surconsommation d'API.

Un senior doit aussi accompagner l'équipe. Cela passe par les revues de code, la documentation, les bonnes pratiques, mais aussi par la capacité à expliquer pourquoi on choisit une solution plutôt qu'une autre.

Enfin, il doit comprendre le produit.

Dans votre contexte, ce qui m'intéresse beaucoup, c'est justement le lien entre technique, Datadog, UX et métriques utilisateurs. Pour moi, la qualité technique n'est pas seulement interne à l'équipe. Elle doit se traduire par une application plus rapide, plus stable, plus accessible et plus agréable à utiliser.

Dans mon projet actuel, nous avons surtout une logique React avec des parcours métiers assez riches côté client. Donc je n'ai pas systématiquement utilisé les Server Components partout comme sur un nouveau projet Next.js App Router.

Par contre, quand je travaille sur une architecture Next.js moderne, j'utilise les Server Components pour tout ce qui concerne le rendu initial de données : pages de contenu, pages détail, listes, blocs peu interactifs, récupération de données côté serveur.

L'idée est simple : si un composant n'a pas besoin d'état local, de useEffect, de localStorage ou d'événement utilisateur, je préfère le garder côté serveur. Cela évite d'envoyer trop de JavaScript au navigateur.

Par exemple, sur une page de souscription ou une page récapitulative, je peux garder côté serveur les blocs qui affichent les informations du contrat, les données du client ou les contenus réglementaires. Ensuite, j'isole côté client uniquement les parties interactives : formulaire, bouton de validation, modale, sélection d'option, upload de document.

L'intérêt est double. D'abord, on améliore la performance parce que le navigateur hydrate moins de composants. Ensuite, on garde une architecture plus claire : le serveur prépare les données et le rendu statique, tandis que le client gère uniquement l'interaction utilisateur.

Donc ma logique est : server-first par défaut, client uniquement quand il y a une vraie interaction navigateur.

Une décision dont je suis particulièrement fier concerne un sujet que on a rencontré sur des parcours de souscription.

On a des pages de plus en plus complexes avec beaucoup de règles métiers, de validations et de comportements différents selon le contexte.

Au départ, chaque nouvelle règle était ajoutée directement dans les composants React. Progressivement, le code devenait difficile à comprendre et à maintenir.

J'ai proposé de séparer davantage la logique métier de l'interface utilisateur.

L'idée était que React ne fasse principalement que de l'affichage tandis que les règles métiers soient regroupées dans des services ou des modules dédiés.

Cette décision n'a pas apporté de valeur visible immédiatement pour l'utilisateur final, mais quelques mois plus tard on a constaté que les évolutions étaient beaucoup plus rapides à développer, les bugs plus faciles à corriger et les nouveaux développeurs montaient plus rapidement en compétence.

Cette expérience m'a conforté dans l'idée qu'une bonne architecture doit avant tout faciliter l'évolution du produit.

J'ai appris avec l'expérience qu'une architecture dégradée se remarque souvent dans la vitesse de livraison avant même qu'elle ne soit visible dans le code.

Par exemple lorsque plusieurs développeurs hésitent régulièrement sur l'endroit où implémenter une fonctionnalité, lorsque les revues de code deviennent compliquées ou lorsqu'une simple évolution nécessite des modifications dans de nombreux fichiers.

J'observe également les indicateurs techniques.

Une augmentation du temps de build, des tests instables, une difficulté croissante à refactoriser ou encore des dépendances circulaires sont souvent des symptômes d'un problème plus profond.

Je considère la dette technique comme un investissement, pas comme une erreur.

Comme une dette financière, elle peut être utile lorsqu'elle est maîtrisée.

Par exemple, lorsqu'un produit démarre, il peut être pertinent de privilégier la rapidité d'exécution pour valider un besoin métier.

En revanche, la dette devient dangereuse lorsqu'elle n'est plus visible ou lorsqu'elle ralentit durablement l'équipe.

Dans plusieurs missions, j'ai toujours essayé d'intégrer le remboursement de la dette dans les développements courants plutôt que de demander plusieurs mois de refonte.

Je préfère améliorer progressivement les zones sur lesquelles nous travaillons déjà plutôt que lancer un grand chantier dont le retour sur investissement est souvent difficile à démontrer.

Pour moi, une revue de code ne consiste pas uniquement à vérifier si le code fonctionne. Je regarde plusieurs dimensions. Je vérifie d'abord que la solution répond bien au besoin métier. Ensuite je m'intéresse à la lisibilité du code.

Je me pose souvent la question suivante :

si un développeur rejoint l'équipe dans six mois, comprendra-t-il rapidement ce code ?

Je regarde également les impacts potentiels sur la performance, la sécurité, les tests et l'accessibilité.

Enfin, je fais attention à la manière dont je formule mes retours.

L'objectif n'est pas de critiquer le développeur mais d'améliorer collectivement la qualité du produit.

J'essaie d'éviter les débats basés sur les préférences personnelles.

• Je préfère revenir aux faits.
• Quels sont les objectifs ?
• Quelles sont les contraintes ?
• Quels sont les impacts à court et long terme ?

Par exemple, si deux solutions sont proposées, je vais comparer leur coût de maintenance, leur complexité, leur impact sur les performances et leur facilité d'évolution.

Lorsque c'est possible, je privilégie également les expérimentations.

Un petit prototype ou une preuve de concept permet souvent de prendre une décision plus sereinement qu'un long débat théorique.

Je pars toujours d'un indicateur métier. Par exemple chez OUIGO :

si une page de paiement passe de 4 secondes à 2 secondes, techniquement c'est intéressant.

Mais la vraie question est : est-ce que le taux de conversion augmente ?

Pour répondre à cela je compare : avant optimisation :

• temps de chargement
• taux d'abandon
• taux de conversion

après optimisation :

• mêmes indicateurs

Je pense qu'un développeur doit relier la technique aux métriques métier.

Un gain de 500 ms qui ne change rien aux usages a moins de valeur qu'une amélioration qui réduit l'abandon de panier.

Anomalie complexe que vous avez résolue récemment.

Un exemple récent concerne le parcours IRS chez OUIGO.

Lors de la recherche d'un établissement scolaire via le champ "Code postal ou commune", certaines communes comme Paris ou Cergy ne retournaient aucun établissement.

Au début cela ressemblait à un problème API.

J'ai commencé par analyser :

• données envoyées par le front
• payload réseau
• comportement API

J'ai découvert que pour certaines communes possédant plusieurs codes postaux, nous envoyions le code postal à la place du code INSEE.

Exemple :

Cergy :

• code postal : 95000
• code INSEE : 95127

L'API attendait :

townInseeCode=95127

mais nous envoyions :

townInseeCode=95000

Le résultat était une liste vide.

j'ai corrigé la construction de l'objet commune pour toujours conserver le code INSEE.

Cette correction a résolu l'ensemble des communes concernées.

Ce que j'aime dans cet exemple c'est qu'il fallait comprendre :

• le métier
• la donnée
• l'API
• le front

et pas uniquement corriger une ligne de code.

Trois raisons principales.

La première est la forte culture produit.

J'apprécie particulièrement le fait que les développeurs participent à la réflexion UX et s'appuient sur les données réelles utilisateurs pour prendre des décisions.

La deuxième est l'importance accordée à l'accessibilité.

Dans mes expériences chez OUIGO, Junior & Cie et Nexity, j'ai souvent travaillé sur ces sujets et je considère que l'accessibilité fait partie intégrante de la qualité logicielle.

Enfin, le poste correspond parfaitement à mon expertise.

Depuis plusieurs années je travaille quotidiennement avec React, Next.js, GraphQL, TypeScript, CI/CD, tests automatisés et amélioration continue de la qualité.

Je pense pouvoir apporter autant sur la partie technique que sur la réflexion produit et la performance utilisateur.

Je ne commence pas par réécrire le projet.

Je mesure d'abord :

• taille bundle
• LCP
• INP
• temps d'hydratation

Ensuite j'identifie les composants réellement interactifs.

Puis je migre progressivement : client -> server -> client

L'objectif n'est pas d'avoir 100% de Server Components.

L'objectif est d'envoyer le moins de JavaScript possible pour offrir la meilleure expérience utilisateur.

C'est exactement l'approche que j'adopterais sur votre projet, en m'appuyant sur les métriques réelles issues de Datadog RUM pour mesurer l'impact de chaque optimisation.

Le projet dont je suis le plus fier est probablement Junior & Cie chez SNCF.

La raison n'est pas uniquement technique. Ce projet m'a permis d'intervenir sur plusieurs dimensions : architecture, qualité, accessibilité, SEO et expérience utilisateur.

Le contexte était une refonte de l'application en Next.js 14 et Node.js. L'objectif était de moderniser l'application, réduire la dette technique et améliorer les performances tout en conservant les règles métier complexes liées au transport de mineurs.

J'ai participé à la conception de l'architecture front, à la mise en place de Storybook, à la stratégie de tests, à l'amélioration de l'accessibilité et aux choix autour du SSR et de l'ISR.

Ce qui me rend particulièrement fier, c'est que nous n'avons pas seulement livré des fonctionnalités. Nous avons construit une base technique plus robuste qui permet aujourd'hui de faire évoluer le produit plus rapidement.