Présentez-moi le stack technique que vous maîtrisez le mieux et pourquoi vous l'avez choisi.

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.

Comment restez-vous à jour avec les évolutions du développement web ?

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.

Comment gérez-vous une situation où les exigences sont floues ou changent en permanence ?

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.

Parlez-moi d'une fois où vous avez dû travailler étroitement avec un designer et où la collaboration a été difficile.

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.

Décrivez une fois où vous avez dû déboguer un problème sous pression avec une deadline imminente.

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.

Donnez un exemple où vous avez refusé d'accepter de la dette technique.

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.

Comment abordez-vous l'optimisation des performances d'une page web lente ?

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.

Expliquez comment vous concevriez un endpoint REST API pour une fonctionnalité que vous avez récemment développée.

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.

Quelles étapes suivez-vous pour rendre un site web accessible ?

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.

Développeur web

Les entretiens pour un poste de développeur web évaluent vos bases techniques ainsi que votre capacité à collaborer, à faire des arbitrages architecturaux et à livrer du code fonctionnel dans de vraies équipes. Les recruteurs veulent voir que vous maîtrisez l'ensemble du stack, que vous vous souciez de l'expérience utilisateur et que vous savez expliquer vos choix clairement. Ce guide couvre les questions les plus fréquentes et les réponses qui témoignent d'une vraie profondeur technique.

Pour des conseils généraux de préparation aux entretiens, consultez notre guide sur les questions d'entretien courantes.

Questions d'entretien courantes pour Développeur web

Questions comportementales pour les postes Développeur web

Questions techniques pour les candidats Développeur web

Ce que les recruteurs recherchent pour un poste Développeur web

Ce que les recruteurs cherchent vraiment chez les candidats développeur web :

Des récits de débogage concrets. N'importe qui peut dire qu'il est bon en débogage. Les candidats qui décrivent un incident réel avec les outils utilisés, la cause identifiée et le changement de processus qui a suivi se distinguent immédiatement.
Des opinions réelles sur les arbitrages. Les meilleurs candidats ne décrivent pas seulement ce qu'ils ont construit : ils expliquent pourquoi ils ont choisi une approche plutôt qu'une autre et ce qu'ils feraient différemment la prochaine fois.
Une conscience du cycle de livraison complet. Écrire du code fait partie du travail, ce n'est pas tout. Cherchez des candidats qui pensent aux tests, au déploiement, à la supervision et à la maintenance aussi naturellement qu'à l'implémentation.
La collaboration avec les non-ingénieurs. Les développeurs front end doivent surtout travailler avec des designers et des product managers. Écoutez comment un candidat décrit ces relations : la précision et le respect mutuel sont de bons signes.
Une connaissance des navigateurs et de l'accessibilité au-delà des bases. Beaucoup de candidats connaissent les fonctionnalités principales. Moins savent comment Safari gère certaines propriétés CSS ou comment implémenter correctement la navigation au clavier. Ceux qui le savent sont nettement plus prêts pour la production.

Questions à poser à votre interlocuteur

→À quoi ressemble le processus de déploiement et à quelle fréquence l'équipe livre-t-elle en production ?
→Comment le travail front end est-il revu ici : y a-t-il une étape de QA design dédiée avant que le code ne soit livré ?
→Quels sont les plus grands défis techniques que l'équipe affronte en ce moment ?
→Comment l'équipe gère-t-elle la compatibilité des navigateurs et les exigences d'accessibilité ?
→À quoi ressemble l'onboarding pour un nouveau développeur, et combien de temps avant que quelqu'un livre de façon autonome ?

Entrainez-vous sur ces questions avant votre entretien

Le simulateur d'entretien construit une session de pratique autour d'une offre d'emploi spécifique et de votre parcours, pour que vous répétiez les questions les plus susceptibles d'être posées.

Commencer l'entrainement

Gratuit pendant la beta. Sans engagement.

Métiers similaires