Presque tous les CV de développeurs front-end affichent la même ligne : React, TypeScript, Redux, Next.js, Tailwind, Jest. Ces technologies sont attendues, et leur absence serait éliminatoire pour la plupart des offres. Leur présence, en revanche, ne dit presque rien. Elle ne permet pas de distinguer quelqu’un qui a suivi un tutoriel de quelqu’un qui maintient depuis trois ans l’interface d’un produit utilisé chaque jour par des milliers de personnes. Ce qui fait la différence aux yeux d’un lead front-end, ce sont des sujets précis, décrits dans les expériences. Cet article les passe en revue et montre comment les écrire.
Pourquoi « React, Redux, Next.js » ne suffit pas
Un lead qui recrute un développeur front-end lit la rubrique compétences en quelques secondes : il vérifie que la stack de l’offre y figure, puis passe aux expériences. C’est là qu’il cherche la réponse à sa vraie question : ce candidat sait-il construire une interface qui reste rapide, accessible, testée et maintenable quand le produit grandit ?
Une liste de bibliothèques ne répond pas à cette question, pour trois raisons.
- Les bibliothèques changent vite. La gestion d’état, le routage, le style ou les outils de build ont connu plusieurs générations en quelques années. Un lead s’intéresse davantage à votre compréhension des problèmes (état partagé, rendu côté serveur, découpage du code) qu’à l’outil du moment.
- Elles sont les mêmes pour tous les candidats. Les frameworks dominants sont enseignés partout, des écoles aux bootcamps. Les citer vous met au niveau de la concurrence, pas au-dessus.
- Elles ne disent rien de l’échelle. Une application de cinq écrans et une application de deux cents écrans partagée par plusieurs équipes utilisent les mêmes bibliothèques, mais demandent des compétences très différentes.
La rubrique compétences doit donc rester courte et précise, comme l’explique notre article sur la présentation de la stack technique. L’essentiel se joue ailleurs.
Les sujets qui signalent un front-end confirmé
Cinq sujets reviennent dans les échanges avec les leads front-end et dans les offres de niveau confirmé. Chacun mérite au moins une puce dans vos expériences, si vous l’avez réellement pratiqué.
- La performance. Temps de chargement, réactivité aux interactions, stabilité visuelle de la page. Google regroupe ces mesures dans les Core Web Vitals 🔗 (LCP, INP, CLS), que beaucoup d’équipes suivent.
- L’accessibilité. Navigation au clavier, compatibilité avec les lecteurs d’écran, contrastes, gestion du focus. En France, le RGAA 🔗 sert de référentiel pour les services numériques publics et de nombreuses entreprises, en s’appuyant sur les WCAG 🔗 du W3C.
- La gestion de l’état et des données. Où vit l’état, comment il est partagé, comment les données du serveur sont mises en cache et synchronisées. C’est souvent là que naissent les bugs les plus coûteux.
- Le design system. Une bibliothèque de composants réutilisables, documentée, partagée entre équipes, construite avec les designers. C’est un marqueur fort d’un profil qui pense au-delà de son écran.
- Les tests et la qualité. Tests unitaires de composants, tests de parcours, typage strict, revue de code.
TypeScript 🔗 mérite une mention à part. L’écrire dans les compétences est attendu ; ce qui distingue un confirmé, c’est l’usage qu’il en fait : typage strict activé, types partagés avec l’API, génération de types à partir d’un schéma, migration progressive d’une base JavaScript.
Écrire la performance et l’accessibilité dans une expérience
Ces deux sujets sont les plus faciles à rendre concrets, parce qu’ils se mesurent.
La performance
Une bonne puce de performance donne la métrique, la valeur avant et après, la page ou le parcours concerné, et la technique employée.
Avant : « Optimisation des performances de l’application React. »
Après : « Réduction du LCP de la page catalogue de 3,8 s à 1,7 s (mesures terrain) : découpage du code par route, chargement différé des images, rendu serveur avec Next.js pour les pages d’entrée. »
Le lead vous demandera comment vous avez mesuré : préparez la réponse (outil de mesure, échantillon, période). C’est aussi l’occasion de montrer que vous distinguez mesures de laboratoire et mesures réelles.
L’accessibilité
Une puce d’accessibilité cite le référentiel, le périmètre et le résultat.
Avant : « Prise en compte de l’accessibilité. »
Après : « Audit RGAA des parcours d’inscription et de paiement avec l’équipe design, puis correction des non-conformités bloquantes (focus clavier, libellés de formulaires, annonces des erreurs aux lecteurs d’écran) ; tests réalisés avec NVDA et VoiceOver. »
Si vous n’avez pas de taux de conformité mesuré, ne l’inventez pas : décrire les corrections réalisées et les outils de test suffit à prouver une vraie pratique. Le modèle de CV de développeur front-end montre une puce de ce type, associée à un design system et à des tests de parcours.
Tests et qualité du code
Les tests sont le sujet le plus souvent oublié sur les CV front-end, alors que les leads le regardent de près. Trois niveaux à distinguer :
- les tests de composants, avec Testing Library et Vitest ou Jest : ils vérifient qu’un composant se comporte comme l’utilisateur l’attend ;
- les tests de parcours (de bout en bout), avec Playwright ou Cypress : ils vérifient qu’un utilisateur peut aller au bout d’une inscription ou d’un paiement ;
- les tests visuels ou de régression, plus rares, souvent branchés sur le design system.
Écrivez ce que vous avez mis en place, sur quel périmètre, et ce que cela a changé.
Avant : « Tests unitaires avec Jest. »
Après : « Mise en place de 30 parcours Playwright sur les fonctions critiques (connexion, commande, paiement), exécutés à chaque pull request ; les régressions détectées en recette sont devenues rares. »
Les autres signaux de qualité ont aussi leur place, en une ligne : typage strict, règles de lint partagées, revue de code systématique, documentation des composants dans Storybook. Ce sont des pratiques d’équipe qui montrent votre maturité.
Front-end ou full stack : se positionner
Beaucoup de développeurs front-end touchent aussi au serveur : routes d’API dans Next.js, fonctions serverless, intégration de services tiers. Faut-il alors se présenter comme full-stack ?
La réponse dépend de ce que vous voulez faire et de ce que vous savez défendre.
- Si votre cœur de métier est l’interface, présentez-vous comme développeur front-end, et mentionnez vos incursions côté serveur dans les expériences. Les équipes qui cherchent un spécialiste de l’interface préfèrent un profil clairement positionné.
- Si vous concevez régulièrement des API, modélisez des bases de données et gérez le déploiement, l’intitulé full-stack est justifié. Dans ce cas, montrez au moins un module que vous avez porté de la base à l’écran, comme le fait le modèle de CV de développeur full-stack.
- Si vous hésitez, adaptez l’intitulé à l’offre, sans changer le contenu : « développeur front-end avec une pratique de Node.js » est une formule honnête qui ouvre les deux portes.
Dans tous les cas, l’intitulé doit correspondre à ce que montrent les expériences. Un CV qui s’annonce full-stack mais ne parle que de composants React sera lu comme un CV front-end, et un lead s’en apercevra en entretien.
Pour que ces puces soient lues, elles doivent aussi être extraites correctement par les logiciels de recrutement, qui ont du mal avec les mises en page en colonnes et les compétences présentées en icônes. Notre article sur les ATS des scale-up détaille ces pièges. L’éditeur de TechCV produit une page sobre, en une colonne, où chaque technologie reste du texte lisible. Vous pouvez mettre à jour votre CV en partant du modèle front-end.
Questions fréquentes
Faut-il citer Vue ou Angular en plus de React ?
Seulement si vous les avez utilisés dans un projet réel que vous pouvez raconter. Une expérience significative sur deux frameworks est un atout, notamment pour les ESN et les agences ; une mention sans contexte ajoute du bruit à votre rubrique.
Comment montrer son niveau sans chiffres de performance ?
Décrivez les problèmes résolus et les choix faits : une architecture de gestion d’état revue, un design system construit, une migration vers TypeScript menée. Ces éléments sont aussi parlants qu’un chiffre, à condition d’être précis.
Le portfolio est-il indispensable pour un développeur front-end ?
Il est fortement conseillé, car votre travail se voit. Deux ou trois réalisations bien présentées, avec un lien vers le code ou une démonstration, valent mieux qu’un site portfolio spectaculaire mais vide. Notre article sur le lien GitHub dans un CV donne des pistes pour le préparer.
Faut-il mentionner les outils de build ?
En une ligne, oui, surtout si vous avez mené une migration (d’un outil de build à un autre, par exemple) ou optimisé un temps de compilation. Sans contexte particulier, ils ne vous distinguent pas.