Questions d'entretien développeur web, avec réponses

Mon stack principal est React côté front end avec TypeScript, couplé à Node.js et Express côté back end, et PostgreSQL pour la base de données. J'ai choisi React parce que le modèle de composants correspond bien à ma façon de concevoir une interface : des blocs isolés avec des entrées et des sorties définies. TypeScript a intercepté plusieurs catégories de bugs avant qu'ils n'atteignent la production, et j'ai fini par voir les annotations de types non plus comme une contrainte, mais comme une documentation que le compilateur vérifie. J'ai ajouté Node côté back end pour réduire le changement de contexte mental entre les couches. PostgreSQL convient aux données relationnelles avec lesquelles je travaille le plus souvent, et son support JSON gère les cas semi-structurés. Je ne suis pas dogmatique sur ce stack : je choisis les outils adaptés au problème, et j'ai livré des projets en Vue et Python/Django quand l'équipe ou les besoins le demandaient.

Je suis un petit nombre de sources à fort signal plutôt que d'essayer de tout lire. Le changelog de MDN Web Docs et les notes de version de React et TypeScript vont directement dans mon lecteur RSS. Je suis quelques newsletters (bytes.dev et JavaScript Weekly) que je parcours chaque semaine. Quand quelque chose retient mon attention, j'ouvre un petit projet ou un CodeSandbox pour l'essayer en isolation avant de l'utiliser en production. Je révise aussi les pull requests de collègues ayant des spécialités différentes des miennes : la revue de code est l'un des moyens les plus rapides d'absorber des patterns que je n'ai pas encore rencontrés. Je n'adopte pas chaque nouveau framework dès sa sortie. J'attends de voir s'il résout un vrai problème que j'ai, et je lis le suivi des issues avant de m'engager sur quoi que ce soit de nouveau en production.

Je traite les exigences floues comme un problème de découverte, pas comme un bloqueur. Ma première étape est de noter ce que je sais, ce que j'assume et ce que je ne sais vraiment pas, puis d'apporter cette liste à la personne qui est propriétaire de l'exigence. Cette conversation résout généralement 80 % de l'ambiguïté en 15 minutes. Pour les exigences véritablement mouvantes, je découpe le travail en unités les plus petites pouvant être livrées indépendamment, et je valide chaque unité avant de passer à la suivante. J'obtiens aussi un accord explicite sur ce que signifie « terminé » avant de commencer : un critère d'acceptation clair est beaucoup plus utile qu'une longue description. Si les exigences changent en cours de développement, je signale le coût du changement en temps et en reprise, non comme une plainte mais comme une information dont l'équipe a besoin pour décider.

Sur un projet, le designer et moi avions un conflit récurrent sur l'espacement des composants. Il livrait des fichiers Figma avec des marges pixel-perfect qui ne correspondaient pas à notre grille de 8 points, et je devais choisir entre respecter le design exactement ou maintenir la cohérence du système. Après la troisième occurrence, j'ai demandé une réunion de 30 minutes pour lui montrer le système de design tokens que nous utilisions et expliquer pourquoi les valeurs arbitraires créaient des problèmes de maintenance. J'ai pris un exemple concret : deux boutons identiques visuellement pour l'utilisateur mais avec des valeurs de marge différentes dans le code, ce qui signifiait deux tickets de mise à jour au lieu d'un. Cette conversation a changé notre façon de travailler. Nous avons convenu que je signalerais les écarts à la grille pendant la revue de design, avant qu'un fichier n'arrive en développement. Les trois derniers mois du projet ont eu presque zéro reprise liée aux incohérences de design.

Nous avions un déploiement en production un vendredi après-midi qui a cassé le processus de commande pour les utilisateurs Safari. Les commandes échouaient silencieusement et nous ne l'avons découvert que parce qu'un client a appelé. J'ai reproduit le problème en local en 10 minutes avec les outils de développement Safari. La cause était une propriété CSS Grid que Chrome gérait bien mais pas Safari : une fonctionnalité subgrid que j'avais utilisée sans vérifier le tableau de compatibilité Safari. J'ai corrigé avec une mise en page flexbox de remplacement, écrit un test de régression et déployé en 45 minutes. La partie la plus difficile était la communication : j'ai envoyé une mise à jour claire au product owner toutes les 15 minutes avec le statut, le délai estimé de résolution et tout changement de cette estimation. Après l'incident, j'ai ajouté une vérification de compatibilité navigateur à notre checklist de revue de code.

En plein milieu d'un projet, l'équipe a proposé de copier un large bloc de code legacy spaghetti dans la nouvelle base de code pour tenir une deadline de sprint. J'ai argumenté contre, non par principe mais avec des éléments précis : ce bloc avait trois bugs ouverts dans le backlog, aucun test, et toucherait six composants que nous prévoyions de refactoriser le trimestre suivant. J'ai estimé le coût de reprise à environ deux jours de sprint, soit plus que le temps que nous économiserions en le copiant maintenant. J'ai proposé une alternative : une implémentation plus légère, propre et testable, que j'estimais à un jour et demi. Le tech lead a accepté. Nous avons livré à temps avec la version propre et n'avons pas payé le coût de reprise par la suite. J'ai aussi été dans des situations où j'ai accepté de contracter de la dette délibérément : l'essentiel est de rendre l'arbitrage explicite et de le consigner dans le backlog avec un ticket de remédiation.

Je commence par mesurer, pas par deviner. Je passe la page dans Lighthouse et l'onglet Performance de Chrome pour obtenir une base de référence. La première chose que je vérifie est le waterfall réseau : les images surdimensionnées et les assets non compressés représentent la majorité des problèmes de temps de chargement dans mon expérience. Ensuite je regarde les scripts bloquant le rendu, puis la taille du bundle JavaScript avec un outil comme webpack-bundle-analyzer ou le plugin d'analyse de bundle Next.js. Côté rendu, je vérifie les décalages de mise en page (CLS) et les tâches longues (TTI). Si la page est en React, j'examine les re-rendus inutiles avec le profileur React DevTools. Les corrections courantes : lazy-loading des images et des composants hors écran, code-splitting au niveau des routes, chargement des scripts tiers en async ou defer, et mise en cache des réponses API. Je mesure à nouveau après chaque modification.

Pour une récente fonctionnalité de notifications utilisateur, j'ai conçu un endpoint GET /users/:id/notifications. J'ai choisi REST plutôt que GraphQL parce que la structure des données était simple et que l'équipe connaissait déjà les conventions REST. J'ai versionné l'API en /v1/ dès le départ pour éviter les changements cassants ultérieurs. L'endpoint renvoie une liste paginée en utilisant une pagination basée sur curseur plutôt que par offset, parce que le fil de notifications se met à jour fréquemment et que la pagination par offset produit des doublons ou des omissions dans ces cas. J'ai inclus un filtrage par statut de lecture en paramètre de requête (?unread=true) et maintenu une enveloppe de réponse cohérente avec nos autres endpoints : un tableau data, un objet meta avec les curseurs de pagination, et une structure d'erreur standard. J'ai rédigé une spec OpenAPI avant l'implémentation pour que les équipes front et back puissent travailler en parallèle.

Je traite l'accessibilité comme une exigence de développement, pas comme un audit que je fais à la fin. En pratique, cela signifie : écrire du HTML sémantique en premier et n'utiliser div et span que lorsqu'aucun élément approprié n'existe ; ajouter un texte alternatif à toutes les images significatives ; s'assurer que chaque élément interactif est accessible et utilisable au clavier ; utiliser les attributs ARIA uniquement lorsque la sémantique native est insuffisante, car un ARIA incorrect est pire qu'aucun. Je lance axe-core dans l'environnement de développement comme linter afin que les problèmes remontent avant la revue de code. Je teste aussi périodiquement avec un lecteur d'écran : VoiceOver sur macOS couvre de nombreux cas réels. Côté CSS, je vérifie les ratios de contraste des couleurs par rapport aux minimums WCAG AA (4,5:1 pour le texte normal). Pour la validation des formulaires, je m'assure que les messages d'erreur sont associés programmatiquement à leurs champs via aria-describedby.