Développeur·euse Front-end
Fiche de poste, salaire, sourcing, 15 questions d'entretien et plan 30/60/90 pour recruter un·e Développeur·euse Front-end en PME française.
Compilé par l'équipe Join à partir de données publiques et de notre expérience de recrutement.
Mis à jour
En un coup d'œil
- Salaire médian 52 000 € 42 000 € – 65 000 €
- Délai de recrutement 45–75 jours
- Expérience 3–6 ans
Comment recruter un·e Développeur·euse Front-end pour votre PME
Avant de rédiger l’annonce, posez-vous trois questions de cadrage. Elles déterminent le profil que vous cherchez réellement et évitent les erreurs courantes en PME tech.
Question 1 : Front-end spécialiste, Full-stack, ou UI Designer ? Le·la Front-end spécialiste creuse en profondeur la couche UI : composants, état, interactions, accessibilité, performance perçue, browser quirks. Le·la Full-stack couvre Front et Back à un niveau intermédiaire-avancé sans creuser autant le Front. Le·la UI Designer travaille en amont sur la maquette (Figma, typographie, hiérarchie, design system côté design) mais ne code généralement pas en production. En PME tech de moins de 5 ingénieur·e·s, un·e Full-stack suffit souvent ; au-delà, dès qu’un design system existe et que les exigences d’accessibilité ou de performance montent, un·e Front-end spécialiste devient le bon choix. Si vous hésitez, regardez la maquette de vos 3 dernières features livrées : si vous remarquez des composants quasi-doublons, des états manquants (vide, chargement, erreur, focus visible), ou des problèmes de performance perçue, vous avez besoin d’un·e Front-end.
Question 2 : Quelle est la maturité de votre design system et de votre stack ? Un·e Front-end qui a passé 4 ans à maintenir un design system mature (tokens documentés, composants partagés, alignement code-design serré) n’opère pas comme un·e Front-end qui a construit un système de zéro en early-stage. Les rituels, la cadence, et la tolérance au désordre diffèrent. En PME sans design system formalisé, cherchez un·e profil à l’aise pour construire au fil de l’eau. En scale-up avec design system mature, cherchez un·e profil capable de respecter une gouvernance existante. Côté framework, la fit stack compte beaucoup pour un·e mid-level : un·e profil React + TypeScript ne devient pas immédiatement productif·ve sur Vue 3 + Composition API sans 2-4 semaines de prise en main. Soyez explicite sur votre stack dans l’annonce ; vous filtrerez naturellement les profils mal-fittés.
Question 3 : Quel niveau d’exigence sur l’accessibilité et la performance ? Un·e Front-end qui n’a jamais testé avec un lecteur d’écran, qui ne connaît pas les patterns WAI-ARIA, ou qui ne sait pas profiler une page avec Chrome DevTools va livrer un Front-end fragile. Si votre produit est destiné au grand public, au secteur public, à une clientèle B2B grand compte, ou si vous avez des contraintes légales (RGAA, directive européenne sur l’accessibilité 2019/882 transposée en France au 28 juin 2025), exigez explicitement ces compétences dans l’annonce et évaluez-les en entretien (questions techniques, cas de modal accessible, mini-audit Lighthouse). Sinon vous obtiendrez un produit qui passe les tests visuels mais qui exclut une partie de vos utilisateur·rice·s et qui dégrade votre SEO.
Si les trois réponses convergent vers un·e Front-end à temps plein (et non un·e Full-stack ou un·e UI Designer), passez au modèle d’annonce ci-dessous.
Modèle de fiche de poste
Développeur·euse Front-end (H / F) PME française
Mission. Concevoir, développer et maintenir la couche Front-end du produit : composants, état, interactions, accessibilité, performance perçue. Vous travaillez en partenariat étroit avec une équipe de [X] ingénieur·e·s Back-end ou Full-stack, [1] designer produit, et [1] Product Manager. Vous reportez au·à la [Tech Lead / Lead Front-end / CTO].
Responsabilités.
- Livrer des features Front-end bout en bout : compréhension du besoin produit, échange avec le·la designer en amont sur la maquette, implémentation, tests, déploiement, suivi en production.
- Maintenir et faire évoluer le design system côté code : composants partagés, tokens, gouvernance légère, alignement avec le design system côté Figma.
- Maintenir la qualité Front-end : accessibilité (WCAG 2.1 AA en pratique, tests avec VoiceOver ou NVDA), performance (Core Web Vitals en zone verte, profilage régulier), cohérence visuelle entre écrans.
- Reviewer les PRs Front-end des collègues avec feedback structuré et pédagogique.
- Contribuer à la résolution des incidents de production sur la couche Front-end (rendu cassé, fuite de listeners, layout shift inattendu).
- Documenter les décisions Front-end importantes (choix de librairie, patterns de composition, gouvernance design system).
- Collaborer avec le·la PM et le·la designer sur les briefs produit ; challenger constructivement les contraintes infaisables ou contre-productives en proposant des alternatives.
Profil recherché.
- Indispensable : 3 à 6 ans d’expérience Front-end en production ; maîtrise solide d’au moins un framework moderne (React, Vue, Svelte) avec TypeScript ; maîtrise opérationnelle de HTML sémantique, CSS moderne (Grid, Flexbox, custom properties), accessibilité (WCAG 2.1 AA, patterns WAI-ARIA), performance web (Core Web Vitals, DevTools, profilage runtime) ; expérience de mise en production (déploiement, monitoring, gestion d’incident).
- Apprécié : familiarité avec la stack [React / Vue / autre] de notre produit ; expérience d’un design system mature (tokens, composants partagés, gouvernance) ; contributions open source ou side-projects publics ; sensibilité au pont design-code (variables Figma, tokens partagés avec l’équipe design).
- Disqualifiant : aucune expérience de mise en production en autonomie ; rejet systématique des frameworks modernes ; ignorance de l’accessibilité ou refus de la prendre en charge ; portfolio composé uniquement de projets sans utilisateur·rice·s réel·le·s.
Conditions.
- Rémunération brute annuelle : fixe [42-65] k€ selon expérience. Pas de variable structurel ; BSPCE éventuels selon le stade de la société.
- Modalité : [temps plein, hybride 2-3 jours / semaine sur site, base à [ville] / remote-friendly].
- Avantages : [mutuelle, tickets resto, RTT, BSPCE, télétravail policy, budget matériel, budget formation et conférences Front-end].
- Stack et outils : [à compléter : framework Front, TypeScript, design system, outils de test (Vitest, Playwright), CI/CD, monitoring perf et a11y].
Fourchette salariale
Salaire fixe annuel brut
Fourchette de référence pour un·e Développeur·euse Front-end mid-level (3 à 6 ans d'expérience pro) en PME ou scale-up SaaS française. Île-de-France et scale-up B2B SaaS tirent vers le haut (55-75 k€) ; les régions et secteurs traditionnels tirent vers le bas (38-48 k€). Stack moderne (React, Vue, Svelte avec TypeScript + design system mature) tire vers le haut ; stack legacy (jQuery, AngularJS, Bootstrap 3) tire vers le bas. Les profils avec une vraie maîtrise de l'accessibilité (WCAG 2.1 AA en pratique) et de la performance web (Core Web Vitals, profilage runtime) se positionnent au-dessus de la médiane. Pas de variable structurel en PME ; BSPCE possibles en scale-up.
Sources: APEC, Baromètre 2025 de la rémunération des cadres tech ; Talent.io, Étude rémunération tech France 2025 ; Welcome to the Jungle, Salaires développeur·euse Front-end France
Où sourcer ce profil
-
LinkedIn
800-1 200 € / mois (Recruiter Lite, sourcing actif)Canal principal pour les profils Front-end en France. Le sourcing actif (Recruiter Lite + InMails ciblés qui citent un projet visible du·de la candidat·e, un dépôt GitHub, ou un article publié) bat largement les Job Posts seuls : un·e bon·ne Front-end ne consulte quasi jamais le feed Jobs. Filtrez précisément sur le framework (« React » ou « Vue » seuls ramènent trop de bruit ; combinez avec « TypeScript », « design system », ou « accessibilité » pour cibler les profils sérieux). Personnalisez systématiquement le premier message ; les messages génériques ont un taux de réponse inférieur à 5 %.
-
Welcome to the Jungle
Dès 990 € HT / offreForte audience tech scale-up et PME modernes, surtout à Paris, Lyon, Bordeaux, Nantes. Les candidat·e·s WTTJ valorisent la stack, la maturité du design system, la composition de l'équipe produit (PM dédié·e, designer dédié·e, ratio Front / Back), et la culture de revue de code. Bien adapté pour les marques employeur jeunes ou un produit en construction. Moins efficace en région ou pour les profils seniors qui passent par leur réseau ou par des communautés tech.
-
Dribbble / GitHub / communautés Front-end de niche
Variable ; sponsoring meetup 200-600 € / événement, communautés Slack souvent gratuitesNiche mais haut signal : GitHub (dépôts publics et contributions open source) reste la référence pour vérifier le niveau de code réel avant de prendre contact ; Dribbble et CodePen rassemblent les profils qui soignent la qualité visuelle des interactions. Les communautés Slack et Discord Front-end françaises (Paris.js, ReactJS France, Vue.js Paris, Frontend Heroes) rassemblent les profils les plus engagé·e·s dans le métier. Volume faible mais qualité élevée pour des postes mid-senior. À combiner avec une présence active de l'équipe Front-end sur ces communautés (talks, articles, partages de cas) pour rester visible.
Playbook d'évaluation
Le rôle de Développeur·euse Front-end se signale à travers cinq stades d'évaluation. Le pair-programming sur composant et le cas design system (stades 3 et 4) sont les plus prédictifs : ils révèlent la profondeur réelle sur HTML sémantique, CSS, accessibilité, et collaboration avec le design, là où le CV et le phone screen filtrent surtout sur la stack déclarée.
-
Stade 1: Lecture du CV et exploration GitHub / portfolio
Lisez le CV en parallèle du profil GitHub et d'éventuels dépôts publics. Cherchez la cohérence de stack (un·e profil React + TypeScript ne se replonge pas dans AngularJS sans 2-4 mois de réadaptation), la stabilité (durée minimale 18-24 mois sur les postes précédents), et les signaux d'investissement métier (contributions open source, articles publiés, talks meetup, side-projects avec démos publiques). Le diplôme compte moins que les 3-5 dernières années d'expérience : un·e autodidacte avec 5 ans de production solide vaut plus qu'un·e diplômé·e top école avec 2 ans de stage prolongé. Discount : profils qui n'ont jamais touché à CSS au-delà des classes utilitaires Tailwind, ou qui décrivent toute leur expérience sous l'angle algorithmique sans mention d'UI ou d'utilisateur·rice·s.
-
Stade 2: Phone screen (30 min)
Trois questions seulement : (1) « Décrivez le projet Front-end dont vous êtes le·la plus fier·ère ; quelle a été votre contribution exacte sur la couche UI ? », (2) « Quelle décision Front-end (choix de framework, refactor de composant, arbitrage perf vs DX) avez-vous prise récemment dont vous doutez encore ? » (humilité et rétrospection), (3) « Pourquoi un changement maintenant ? ». Sortie : go ou no-go en 5 min de débrief. Évitez les questions « gotcha » sur les API JavaScript à ce stade ; cherchez la maturité de raisonnement Front-end.
-
Stade 3: Pair-programming sur composant (60-90 min)
Exercice borné (45-60 min) : ajouter une feature ou refactorer un composant React, Vue ou Svelte existant. Cas typiques : ajouter la gestion clavier complète à un menu déroulant, refactorer un composant à 400 lignes en 2-3 sous-composants, débuguer un re-render inutile. Suivi de 15-30 min de Q&A sur les décisions prises. Évaluez la capacité à raisonner à voix haute, à demander des clarifications, à itérer, à reconnaître ce qu'il·elle ne sait pas. Évitez les algorithmes purement académiques sans rapport avec le métier ; privilégiez un exercice qui ressemble au quotidien d'un·e Front-end.
-
Stade 4: Cas design system et collaboration design (60 min)
Présentez un cas concret : « Voici une maquette Figma qui propose un nouveau composant proche d'un existant ; comment cadrez-vous la décision avec le·la designer ? ». Évaluez la capacité à reconnaître les patterns existants, à challenger constructivement la maquette, à proposer des arbitrages (étendre l'existant vs créer un nouveau composant), à anticiper l'accessibilité et les états (vide, chargement, erreur, focus visible). C'est le stade le plus prédictif pour un·e Front-end qui travaillera étroitement avec un·e designer en PME.
-
Stade 5: Références (vérification structurée)
Appelez 2 références : un·e ancien·ne lead Front-end ou tech lead et un·e ancien·ne collègue designer ou Product Manager qui a travaillé avec le·la candidat·e au quotidien. Posez à chacun·e les mêmes 4 questions : « Sur quoi est-il·elle le·la plus fort·e ? », « Sur quoi recruteriez-vous quelqu'un de complémentaire ? », « Le·la reprendriez-vous demain ? », « Un exemple de décision Front-end difficile prise en autonomie, ou d'arbitrage tenu sous pression PM ou design ? ». La 4e question révèle le vrai signal d'autonomie et de jeu d'équipe.
Questions d'entretien structurées
-
Comportementale Décision technique Front-end Décrivez la décision Front-end la plus difficile que vous avez prise sur votre dernier poste (choix de framework, refactor majeur, arbitrage performance vs DX). Pourquoi était-elle difficile et comment l'avez-vous tranchée ?
Ce qu'une bonne réponse révèleCapacité à structurer une décision sous incertitude : identification des contraintes (équipe, calendrier, dette existante, parc utilisateur·rice), arbitrages explicites, consultation des parties concernées (designer, back-end, PM), validation a posteriori avec des données (Core Web Vitals, taux d'erreur, feedback équipe). Bonus : la·le candidat·e mentionne avoir changé d'avis en cours de route ou avoir documenté la décision. Les candidat·e·s qui décrivent une décision « évidente » avec recul révèlent qu'ils·elles n'ont jamais vraiment arbitré.
-
Comportementale Debug et investigation Front-end Parlez-moi d'un bug Front-end pénible que vous avez résolu (rendu cassé sur un navigateur, fuite mémoire dans un composant, layout shift inattendu). Quel était le symptôme, comment avez-vous diagnostiqué, et combien de temps a-t-il fallu ?
Ce qu'une bonne réponse révèleMéthode de debug structurée : reproduction, DevTools (Performance tab, Memory tab, rendering, network), instrumentation, hypothèses validées par expérimentation. Honnêteté sur la durée (un vrai bug Front-end dure rarement moins de 30 min). Bonus : la·le candidat·e cite la cause profonde et le correctif systémique (pas seulement le hotfix). Les réponses « j'ai changé une propriété CSS au hasard et ça a marché » sans diagnostic révèlent une faiblesse d'investigation.
-
Comportementale Apprentissage et humilité Décrivez un moment où vous avez dû refactorer ou réécrire un composant Front-end que vous aviez vous-même écrit quelques mois auparavant. Que s'était-il passé entre-temps ?
Ce qu'une bonne réponse révèleHumilité technique et capacité à apprendre. Bonus : la·le candidat·e identifie ce qu'il·elle aurait fait différemment dès le départ (découpage, gestion d'état local vs global, séparation logique / présentation). Les candidat·e·s qui n'ont « jamais vraiment dû refactorer leur code » mentent ou n'ont pas porté de code en production sur la durée.
-
Situationnelle Collaboration design system Le·la designer vous livre une maquette Figma qui propose un nouveau composant ressemblant beaucoup à un composant existant du design system, mais avec quelques variations visuelles. Comment vous positionnez-vous ?
Ce qu'une bonne réponse révèlePosture de partenariat : challenger constructivement, proposer un échange rapide pour comprendre l'intention (variation justifiée par un cas d'usage différent ou simple écart non intentionnel ?), proposer 2 options chiffrées (étendre l'existant via une variante de composant vs créer un nouveau composant). Bonus : la·le candidat·e mentionne le coût caché des composants quasi-doublons (maintenance, accessibilité, cohérence visuelle). Les candidat·e·s qui implémentent en bloc sans poser de question, ou qui refusent en bloc sans proposer d'alternative, révèlent une faiblesse de collaboration.
-
Situationnelle Communication produit Un·e Product Manager vous demande d'ajouter une feature Front-end que vous estimez à 2 semaines. Le·la PM veut la livrer en 5 jours pour une démo client. Comment réagissez-vous ?
Ce qu'une bonne réponse révèleClarification du besoin avant de négocier la timeline (la démo a-t-elle besoin de toute la feature ou seulement du happy path ?). Proposition d'options : MVP visuel non interactif en 2 jours pour la démo + V2 fonctionnelle en 2 semaines ; coupes explicites de scope (un seul navigateur, pas d'accessibilité clavier, pas de gestion d'erreur). Bonus : la·le candidat·e signale les risques de chaque coupe. Les réponses « je peux le faire en 5 jours si je travaille les week-ends » sont un drapeau rouge.
-
Situationnelle Pragmatisme et priorisation Vous rejoignez une équipe avec un Front-end legacy : pas de design system, composants à 600 lignes, jQuery mélangé à React, pas de tests, pas de typage. Quel est votre plan en 60 jours ?
Ce qu'une bonne réponse révèleDiagnostic d'abord : ne pas tout vouloir réparer en même temps. Priorisation par risque / impact (typiquement : extraction d'un noyau de tokens et de 5-10 composants partagés d'abord, puis introduction progressive de TypeScript sur les nouvelles features, puis tests sur les zones critiques). Validation avec l'équipe et la·le lead avant d'engager. Bonus : la·le candidat·e propose de mesurer la valeur du chantier (vélocité, taux de régression, accessibilité) plutôt que de refactorer pour la beauté du geste. Les candidat·e·s qui veulent tout réécrire en React Server Components dès le jour 1 manquent de pragmatisme.
-
Étude de cas Performance web Performance : votre page principale charge en 6 secondes sur mobile 4G. LCP à 4,8 s, CLS à 0,28, INP à 380 ms. Vous avez 2 semaines pour passer les trois métriques en zone verte (Core Web Vitals). Plan d'action ?
Ce qu'une bonne réponse révèleMesurer avant d'optimiser : Lighthouse, WebPageTest, Chrome DevTools Performance tab, RUM si disponible. Identification des bottlenecks par métrique (LCP : image héros non optimisée, font-display:swap manquant, CSS bloquant ; CLS : images sans dimensions, fonts qui reflowent, bannières insérées tardivement ; INP : long tasks JS, listeners coûteux, hydration trop lourde). Hiérarchisation par effort × impact. Bonus : la·le candidat·e mentionne qu'une page à 6 s en prod indique souvent un problème systémique (bundle énorme, trop d'hydration) plus qu'une optimisation locale. Les réponses « j'ajoute un lazy-load » sans diagnostic révèlent un réflexe d'optimisation prématurée.
-
Étude de cas Accessibilité Accessibilité : on vous demande de rendre accessible un modal complexe (formulaire à plusieurs étapes, validation inline, fermeture par clic extérieur). Comment cadrez-vous ?
Ce qu'une bonne réponse révèleConnaissance des patterns WAI-ARIA (rôle dialog, aria-modal, aria-labelledby, gestion du focus à l'ouverture, focus trap pendant l'ouverture, restauration du focus à la fermeture, gestion de la touche Escape). Distinction entre dialog modal et dialog non-modal. Bonus : la·le candidat·e mentionne avoir testé avec VoiceOver ou NVDA, et signale les pièges classiques (modal qui ferme au focus sur un input externe, validation inline non annoncée aux lecteurs d'écran). Les candidat·e·s qui répondent « j'utilise une librairie comme Radix » sans pouvoir expliquer ce qu'elle fait sous le capot révèlent un manque de fondamentaux.
-
Étude de cas Architecture de composants Conception : on vous demande de créer un composant Select autocomplete partagé pour le design system (recherche async, navigation clavier complète, multi-sélection optionnelle, support mobile). Comment cadrez-vous ?
Ce qu'une bonne réponse révèleClarifications avant code : volume attendu d'options (10 vs 10 000 changent l'architecture), source des données (local vs API), comportement attendu sur mobile (sheet vs popover), accessibilité requise (combobox WAI-ARIA pattern). Architecture cohérente : composition (un Select de base + variantes vs un Select monolithique configurable), gestion d'état (controlled vs uncontrolled), API publique stable. Bonus : reconnaissance des zones d'incertitude (« je ferais un prototype rapide pour valider l'API publique avec 2-3 cas d'usage de l'équipe avant de m'engager »). Les candidat·e·s qui plongent dans le code sans clarifier les contraintes révèlent une faiblesse de design de composant.
-
Technique Fondamentaux framework Différence entre useMemo, useCallback, et React.memo ? Dans quels cas un mauvais usage cause-t-il plus de problèmes qu'il n'en résout ?
Ce qu'une bonne réponse révèleuseMemo mémoïse la valeur de retour d'une fonction coûteuse ; useCallback mémoïse une référence de fonction stable ; React.memo évite le re-render d'un composant si ses props n'ont pas changé (comparaison superficielle par défaut). Pièges classiques : mémoïser un calcul trivial coûte plus en mémoire et en complexité qu'il n'économise en CPU ; React.memo est inutile si le composant reçoit des props non stables (objets ou fonctions recréés à chaque render) ; la sur-mémoïsation rend le code illisible. Bonus : la·le candidat·e cite avoir mesuré avant de mémoïser (Profiler React DevTools). Les candidat·e·s qui mémoïsent tout par réflexe révèlent un manque de fondamentaux.
-
Technique Performance web Expliquez le rendering critical path d'une page web moderne. Quels sont les leviers Front-end pour réduire le LCP et le CLS ?
Ce qu'une bonne réponse révèleCompréhension de la séquence : HTML parsing, construction du DOM, CSS parsing et CSSOM, blocking resources (CSS et JS sync), construction du render tree, layout, paint, composite. LCP : optimiser le plus gros élément visible (image preload, fetchpriority=high, formats modernes, dimensions explicites, font-display:swap, CSS critique inline). CLS : dimensions explicites sur médias, réservation d'espace pour bannières et embeds, transitions CSS plutôt que reflows JS, font fallback métriquement proche. Bonus : la·le candidat·e mentionne les outils (Lighthouse, WebPageTest, Chrome DevTools Performance) et la distinction entre données synthétiques (lab) et données réelles (RUM, CrUX).
-
Technique Pragmatisme et priorisation Vous arrivez sur un codebase React mal organisé : composants à 500 lignes, props drilling à 5 niveaux, pas de séparation logique / présentation, mélange de classes et de fonctionnels. Plan d'action en 60 jours sans tout casser ?
Ce qu'une bonne réponse révèleApproche progressive : (1) cartographier les composants critiques et les patterns récurrents, (2) extraire les hooks et la logique métier d'abord (impact massif, risque faible), (3) découper les gros composants par boundary métier plutôt que par contrainte technique, (4) introduire un state-manager si nécessaire (Context, Zustand pour PME, Redux si volume) seulement sur les zones où le props drilling est réellement douloureux, (5) typer progressivement en TypeScript sur les nouvelles features et les zones touchées. Les candidat·e·s qui veulent tout réécrire en React Server Components dès le jour 1 manquent de pragmatisme.
-
Valeurs Coachabilité Comment recevez-vous une revue de code critique sur un composant Front-end que vous étiez convaincu·e d'avoir bien fait ?
Ce qu'une bonne réponse révèleOuverture : capacité à dissocier le code de l'ego personnel. Bonus : la·le candidat·e cite une fois où il·elle a changé d'avis grâce à une review, ou cite une review qu'il·elle a fait sienne après réflexion. Les candidat·e·s qui décrivent avoir « expliqué leur logique » au reviewer au lieu de l'écouter révèlent une faiblesse de coachabilité critique pour le travail en équipe.
-
Valeurs Communication produit et design Comment travaillez-vous avec un·e designer ou un·e Product Manager ? Décrivez une situation où vous avez poussé en arrière sur un brief ou sur une maquette.
Ce qu'une bonne réponse révèlePosture de partenariat : challenge constructif basé sur la faisabilité, la complexité, l'accessibilité, ou la cohérence avec le design system. Proposition d'alternatives. Bonus : la·le candidat·e cite un cas où il·elle a accepté le brief initial après échange (n'est pas en mode opposition systématique). Les candidat·e·s qui décrivent les designers comme « ne comprenant pas la technique » ou les PMs comme « ne comprenant pas le Front » révèlent une faiblesse de jeu d'équipe.
-
Valeurs Jugement Front-end et curiosité Quels produits ou sites web utilisez-vous au quotidien et qui vous inspirent en ce moment sur la dimension Front-end (interactions, perf, accessibilité, design system) ? Qu'est-ce qui en fait la qualité ou la limite ?
Ce qu'une bonne réponse révèleCuriosité Front-end authentique : capacité à citer 3-5 produits récents (pas seulement Apple, Linear, Notion par réflexe), avec une analyse précise de ce qui fonctionne (qualité des interactions, performance perçue, cohérence visuelle, accessibilité au clavier, gestion des états). Bonus : la·le candidat·e cite un produit que personne ne cite et explique pourquoi. Les candidat·e·s qui répondent par des généralités (« j'aime quand c'est rapide ») ou par des produits évidents sans analyse révèlent un manque de regard critique entraîné, ce qui est rédhibitoire pour un poste qui exige du goût technique au quotidien.
Comment reconnaître un·e excellent·e Sales Manager
| Compétence | Sous la barre | Au niveau | Au-dessus |
|---|---|---|---|
| Solidité Front-end | Bute sur les fondamentaux (HTML sémantique, modèle CSS de flux, cascade, événements DOM, JavaScript asynchrone). Cherche les solutions par essai-erreur sans modèle mental clair. Difficile à charger sur un nouveau framework ou un nouveau navigateur. | Maîtrise la stack actuelle en autonomie (React, Vue ou Svelte avec TypeScript). Comprend le rendering critical path, la cascade CSS, la propagation d'événements. Sait apprendre un nouveau framework Front-end en 2-4 semaines. Comprend les fondamentaux suffisamment pour déboguer en profondeur quand nécessaire. | Référent·e Front-end sur sa stack et capable de basculer sur une nouvelle stack en quelques semaines. Anticipe les pièges classiques (re-renders inutiles, fuites de listeners, layout thrashing, hydration mismatches). Construit des abstractions utiles, pas prématurées. Lit le code source des dépendances quand nécessaire. |
| Collaboration design system | Implémente les maquettes en bloc sans questionner les patterns existants. Crée des composants quasi-doublons par réflexe. Pas de réflexion sur les états (vide, chargement, erreur, saturé). Pas de discussion en amont avec le·la designer sur la faisabilité ou la cohérence. | Reconnaît les patterns existants et propose d'étendre plutôt que de dupliquer. Discute la maquette en amont avec le·la designer sur les états et l'accessibilité. Maintient la cohérence visuelle et structurelle du design system. Sait dire non à un pattern qui casserait le système. | Référence sur le pont design-code : variables Figma alignées avec les tokens de code, composants partagés documentés, gouvernance légère et tenue. Pair fréquemment avec le·la designer pour cadrer les composants en amont. Forme l'équipe sur la composition de composants accessibles et performants. |
| Performance et accessibilité | Pas de mesure avant optimisation. Ne connaît pas les Core Web Vitals ni les patterns WAI-ARIA de base. Reflows JS, images sans dimensions, fonts qui décalent le layout, listeners coûteux, composants inaccessibles au clavier ou aux lecteurs d'écran. | Mesure avant d'optimiser (Lighthouse, DevTools Performance, profilage React ou Vue). Applique les fondamentaux d'accessibilité (HTML sémantique, focus visible, navigation clavier, labels de formulaire, contrastes WCAG 2.1 AA). Connaît les Core Web Vitals et sait identifier les bottlenecks classiques. | Référence dans l'équipe pour la performance et l'accessibilité. A déjà testé avec VoiceOver ou NVDA. Sait construire des composants complexes accessibles (combobox, dialog modal, datepicker) sans dépendance lourde. Pilote des chantiers performance avec mesure avant et après. Forme l'équipe sur les patterns WAI-ARIA et sur le profilage runtime. |
| Communication produit et design | Explique mal son travail aux non-techniques. Posture défensive en revue. Travaille en silo, partage peu son contexte. Posture d'opposition systématique face aux PMs ou aux designers (« ils ou elles ne comprennent pas la technique »). | Sait expliquer son travail à un·e PM, un·e designer, ou un·e dirigeant·e en langage clair. Reçoit la review constructivement. Partage son contexte en revues d'équipe et 1:1. Sait négocier une timeline ou un périmètre avec une proposition d'options chiffrées. | Pont entre la tech et les autres fonctions. Anime les debriefs Front-end, vulgarise les arbitrages performance et accessibilité, négocie les timelines de manière transparente. Référence dans l'équipe pour la communication transverse. |
| Autonomie et débrouillardise | Bloque sur un sujet inconnu sans demander d'aide pendant des heures, ou demande de l'aide au moindre obstacle. Pas de stratégie de debug structurée. Difficulté à lire la documentation officielle ou le code source d'une dépendance. | Sait diagnostiquer en autonomie sur les sujets familiers, demande de l'aide après une investigation préalable (résumé du problème, hypothèses, ce qui a déjà été essayé). Lit la documentation officielle plutôt que les premiers résultats Stack Overflow. Reproduit les bugs de manière minimale. | Débrouillardise élevée sur des sujets non familiers : lit le code source des dépendances Front-end, instrumente le runtime navigateur, isole les causes profondes. Documente les apprentissages pour l'équipe. Capable de prendre une décision Front-end structurante en autonomie sur un sujet ambigu. |
Plan 30/60/90 jours
À J+30
- Setup complet de l'environnement local et déploiement d'une PR en production (même triviale) validée
- Lecture et compréhension du code des 3 zones Front-end les plus critiques de la stack métier
- Premier 1:1 documenté avec la·le tech lead ou lead Front-end sur les conventions, la dette identifiée, et les priorités
- Première PR substantive (fix de bug, petit composant) reviewée et mergée
À J+60
- Livraison d'une feature Front-end complète bout en bout (UI + état + intégration API) en autonomie
- Première review de PR Front-end d'un·e collègue avec feedback structuré, sans juste cliquer approve
- Première contribution au design system : nouveau composant partagé ou refactor d'un composant existant
- Documentation rédigée ou mise à jour sur un composant ou un pattern récemment touché
À J+90
- Livraison régulière (1-2 PRs Front-end par semaine) avec qualité validée par l'équipe en review
- Première décision Front-end en autonomie sur un sujet ambigu (refactor, choix de librairie, design de composant partagé)
- Mentorat informel d'un·e junior ou nouveau·elle arrivant·e (pair-programming, reviews pédagogiques)
- Bilan formel avec la·le tech lead : ramp validé, plan de progression sur 1-2 axes prioritaires (perf, a11y, design system, leadership technique)
Erreurs de recrutement courantes pour ce poste
-
Recruter un·e Full-stack en pensant gagner un·e spécialiste Front-end
Un·e Full-stack mid-level couvre Front et Back à un niveau intermédiaire-avancé, mais sa profondeur Front est rarement comparable à celle d'un·e spécialiste qui a passé 5 ans à creuser HTML sémantique, CSS, accessibilité, performance, et browser quirks. Si votre besoin réel est « livrer une UI de qualité, accessible, performante, cohérente avec le design system », recrutez un·e Front-end. Si votre besoin est « livrer une feature de bout en bout en autonomie », recrutez un·e Full-stack. Préciser le besoin dans l'annonce filtre naturellement les profils mal-fittés.
-
Sous-pondérer l'expertise accessibilité
L'accessibilité reste largement traitée comme un bonus en France alors qu'elle est une exigence légale (RGAA pour le public, directive 2019/882 pour le privé transposée en France au 28 juin 2025), un signal de qualité produit, et un levier SEO. Recruter un·e Front-end qui ne sait pas construire un modal accessible, un combobox WAI-ARIA, ou tester avec VoiceOver vous coûtera cher en remédiation. Évaluez explicitement l'accessibilité en entretien (questions techniques, cas de modal ou de combobox) et privilégiez les profils qui en parlent spontanément.
-
Embaucher un·e profil jQuery ou AngularJS pour une stack React ou Vue moderne
Le réflexe « tous les développeur·euse·s Front-end se valent » conduit à recruter des profils qui ont 5-8 ans d'expérience jQuery ou AngularJS et qui devront se reconvertir en React ou Vue. Le coût caché est important : 3-6 mois de réadaptation au composant, à la gestion d'état moderne (hooks, signals), au tooling (Vite, ESBuild, TypeScript), aux patterns d'hydration et de rendering. Privilégiez les profils qui ont au moins 2-3 ans d'expérience récente et continue sur votre stack, ou explicitez la reconversion comme un atout et acceptez les 3-6 mois de ramp.
-
Sous-évaluer la profondeur CSS
CSS est largement sous-estimé dans les entretiens Front-end alors qu'il représente souvent 30-50 % du travail réel (mise en page complexe, animations, états interactifs, accessibilité visuelle, dark mode, responsive). Un·e candidat·e qui ne sait pas expliquer la cascade, le contexte de bloc englobant, la différence entre stacking context et z-index, ou qui ne maîtrise pas Grid et Flexbox au-delà des cas triviaux, va livrer un Front-end fragile. Inclure une question CSS technique précise dans l'entretien et un mini-exercice de layout dans le pair-programming.
-
Attendre des compétences design visuel ou d'illustration sans les préciser
Le métier de Développeur·euse Front-end ne suppose pas d'office des compétences de design visuel, d'illustration, ou de motion design avancé. Un·e Front-end excellent·e implémente fidèlement une maquette livrée par le·la designer, mais ne crée pas la maquette. Si vous attendez du·de la candidat·e qu'il·elle prenne des décisions visuelles en autonomie (typographie, hiérarchie, palette), vous cherchez en réalité un·e UI Designer ou un·e Designer Engineer (profil rare et cher), pas un·e Front-end. Explicitez le périmètre dans l'annonce ; sinon vous filtrerez par défaut des profils Front-end solides et vous laisserez passer des candidat·e·s mal-fittés.
Questions fréquentes
-
Quel est le salaire d'un·e Développeur·euse Front-end en PME française ?
La fourchette de référence pour un·e Développeur·euse Front-end mid-level (3 à 6 ans d'expérience) en PME ou scale-up SaaS française est de 42 à 65 k€ bruts annuels (médiane autour de 52 k€). Île-de-France et scale-up B2B SaaS tirent vers le haut (55-75 k€) ; régions et secteurs traditionnels tirent vers le bas (38-48 k€). Les profils avec une vraie maîtrise de l'accessibilité (WCAG 2.1 AA en pratique) et de la performance web se positionnent au-dessus de la médiane. Le poste n'a généralement pas de variable structurel en PME ; certaines scale-up attribuent des BSPCE (stock-options).
-
Quelle est la différence entre Développeur·euse Front-end, Full-stack et UI Designer ?
Le·la Front-end se concentre sur la couche UI (composants, état, interactions, accessibilité, performance perçue) et travaille étroitement avec un·e designer et un·e Back-end. Le·la Full-stack couvre Front et Back à un niveau intermédiaire-avancé ; en PME, c'est souvent le profil par défaut quand le volume ne justifie pas de spécialiste. Le·la UI Designer crée la maquette (typographie, hiérarchie visuelle, palette, design system côté Figma) mais ne code généralement pas en production. Pour un produit B2B SaaS avec un design system mature et des exigences fortes d'accessibilité ou de performance, le·la Front-end spécialiste est le bon choix dès 3-5 ingénieur·e·s dans l'équipe.
-
Combien de temps faut-il pour recruter un·e Développeur·euse Front-end en France ?
Comptez 45 à 75 jours entre la publication de l'annonce et la signature pour un·e profil mid-level. Le marché Front-end reste tendu en 2025-2026, surtout pour les profils avec stack moderne (React ou Vue avec TypeScript) et expertise accessibilité ou performance. Les délais s'allongent en septembre et janvier. Réduire le délai sous 45 jours impose en général de sacrifier le pair-programming sur composant ou le cas design system, ce qui dégrade fortement la qualité du recrutement.
-
Faut-il un diplôme spécifique pour recruter un·e Développeur·euse Front-end ?
Non. Le marché Front-end français accepte largement les profils autodidactes ou issus de bootcamps (Le Wagon, 42, OpenClassrooms) dès qu'ils·elles ont 3-5 ans de production solide. Le diplôme (école d'ingénieur, master informatique) est rassurant pour les profils junior mais perd de l'importance après 5 ans d'expérience. Évaluez sur le code et la résolution de problèmes Front-end, pas sur le pedigree académique.
-
Quelles sont les obligations légales d'une annonce Développeur·euse Front-end en France ?
Trois obligations principales : (1) intitulé neutre ou avec mention H / F (article L. 1142-1 du Code du travail), (2) affichage de la fourchette salariale ou communication avant le premier entretien (directive 2023 / 970, transposition au 7 juin 2026), (3) transparence sur tout outil d'IA utilisé pour le tri des candidatures et supervision humaine garantie (EU AI Act, applicable au 2 août 2026). Les développeur·euse·s en PME sont quasi systématiquement au forfait jours, ce qui implique le respect du droit à la déconnexion et un suivi régulier de la charge de travail.
-
Faut-il faire un pair-programming systématique pour un·e Front-end ?
Oui, et idéalement deux exercices : un pair-programming sur composant (45-60 min) pour évaluer la profondeur Front-end réelle, et un cas design system ou collaboration design (60 min) pour évaluer le jugement et la posture de partenariat. Le pair-programming est le meilleur prédicteur de performance future devant le CV, le diplôme, et même les tests techniques à emporter (qui prennent 24 h en pratique pour le·la candidat·e et n'évaluent pas mieux). Bornez explicitement le temps attendu et acceptez les solutions incomplètes mais bien argumentées.