Recruter sur Vue.js en France pose un problème que ne pose pas React : le vivier est plus étroit, et surtout beaucoup plus hétérogène. Sous une même ligne de CV — « 4 ans d’expérience Vue.js » — vous trouverez aussi bien quelqu’un qui a maintenu une application Vue 2 en Options API sans jamais toucher au rendu serveur, que quelqu’un qui a mené une migration complète vers Vue 3 et exploite Nuxt en production.
Ces deux personnes n’ont presque aucune compétence en commun au-delà de la syntaxe des composants. Et aucune des deux ne ment sur son CV.
Nous avons recruté quatre développeurs Vue.js entre janvier et août 2026, après 61 candidatures et 27 entretiens. Voici la méthode en 7 étapes que nous avons stabilisée, les 5 questions qui font le tri, et les chiffres de salaire que nous avons réellement pratiqués.
Étape 1 : écrire une annonce qui dit la version et l’existant
C’est l’étape la plus rentable de toute la méthode, et celle que nous avons ratée sur notre premier poste. L’annonce disait « développeur Vue.js confirmé ». Nous avons reçu vingt-trois candidatures, tenu neuf entretiens, et découvert en entretien que sept des neuf n’avaient jamais travaillé sur du rendu serveur — alors que notre application est intégralement rendue côté serveur avec Nuxt.
Vingt-sept jours perdus, entièrement de notre fait. Votre annonce doit répondre à quatre questions, dans le texte et non en filigrane :
- Vue 2 ou Vue 3 ? Et si vous êtes encore en Vue 2, dites-le franchement en précisant si une migration est prévue. Certains candidats fuient, d’autres sont précisément intéressés par ce chantier.
- Options API ou Composition API ? La bascule est structurante dans la manière de penser un composant.
- Nuxt, oui ou non ? Et si oui, en rendu serveur, en génération statique, ou en application monopage.
- Dans quel état est le code ? « Base saine avec tests » et « code repris d’un prestataire, peu testé » n’attirent pas les mêmes profils. Le second n’est pas honteux : il intéresse les gens qui aiment remettre d’aplomb.
Sur les trois postes suivants, annonce précisée, nous sommes passés de neuf entretiens pour un recrutement à environ six pour un recrutement.
Le réflexe qui change tout
Écrivez dans l’annonce la phrase que vous auriez peur de lire à voix haute en entretien. « Le code a été repris d’une agence, la couverture de tests est de 12 %, et le premier chantier est la migration Vue 2 vers Vue 3. » Cette phrase divise le nombre de candidatures par deux et multiplie la pertinence par trois. Les gens que vous perdez sont exactement ceux qui auraient démissionné au bout de quatre mois.
Étape 2 : filtrer les candidatures sur trois signaux seulement
Sur 61 candidatures, nous en avons écarté 34 en lecture rapide. Pas sur le nombre d’années, ni sur les logos, ni sur la longueur de la liste de technologies — trois critères qui ne prédisent rien.
Nous cherchons la trace de trois travaux :
- Un travail de migration. Vue 2 vers Vue 3, Options vers Composition, ou même une montée de version majeure de Nuxt. Quelqu’un qui a migré a nécessairement compris ce qu’il migrait.
- Un travail de performance. Une mention concrète de temps de chargement, de taille de paquet, de rendu serveur optimisé. Cela prouve un contact avec la production réelle et pas seulement avec l’environnement de développement.
- Un travail de test. Même modeste. C’est le signal le plus discriminant de tous, parce qu’il est le plus rare sur les CV front-end français.
Deux signaux sur trois suffisent pour passer en entretien. Les CV qui n’en présentent aucun ne sont pas mauvais : ils sont simplement invérifiables à ce stade, et notre temps d’entretien n’est pas extensible.
Étape 3 : envoyer un exercice de 90 minutes maximum
Nous avons longtemps envoyé un exercice « à faire chez soi, comptez une demi-journée ». Nous avons arrêté. Le taux d’abandon dépassait 40 %, et les meilleurs candidats — ceux qui ont déjà un poste et plusieurs pistes en parallèle — étaient les premiers à décliner.
L’exercice actuel tient en 90 minutes annoncées, et nous le disons explicitement : personne ne sera pénalisé pour avoir rendu un travail incomplet dans le temps imparti. Il porte sur un composant réaliste : une liste filtrable avec un état partagé entre deux composants frères, une gestion d’erreur, et un cas de chargement.
Ce que nous regardons n’est pas que ça marche — ça marche presque toujours. Nous regardons où le candidat a placé l’état, s’il a distingué ce qui est calculé de ce qui est stocké, et comment il a traité le cas d’erreur. Trois éléments qui se lisent en dix minutes et qui prédisent bien le comportement sur une base de code réelle.
Étape 4 : poser les 5 questions éliminatoires
Voici le cœur de la méthode. Ces cinq questions ont écarté 80 % des candidats arrivés en entretien. Aucune ne porte sur la syntaxe, aucune ne se prépare la veille, et toutes admettent plusieurs bonnes réponses — ce qui compte est le raisonnement.
Question 1 — « Qu’est-ce qui déclenche exactement un nouveau rendu dans Vue 3 ? »
La réponse faible décrit un comportement observé : « quand une variable change ». La réponse solide parle de dépendances suivies pendant le rendu et de la différence entre une référence réactive et un objet réactif. Cette question sépare immédiatement ceux qui ont lu la documentation de ceux qui ont copié des exemples.
Question 2 — « Ce composant fonctionne en développement et casse en rendu serveur. Par où commencez-vous ? »
C’est la question la plus discriminante de la série si vous êtes sur Nuxt. On attend la mention de l’accès à des objets de navigateur pendant le rendu serveur, ou d’un état partagé entre requêtes. Sur nos 27 entretiens, 16 candidats n’ont pas su par où commencer — ce qui est parfaitement légitime pour qui n’a jamais fait de rendu serveur, et rédhibitoire pour notre poste.
Question 3 — « Quand mettez-vous quelque chose dans un magasin d’état global, et quand refusez-vous ? »
La réponse inquiétante est « tout ce qui est partagé ». La réponse solide distingue l’état réellement global — session, préférences — de l’état de page qu’on remonte par paresse. Cette question prédit mieux que toute autre la qualité du code que la personne écrira dans six mois.
Question 4 — « Que testez-vous sur un composant, et que refusez-vous de tester ? »
La seconde moitié compte plus que la première. Quelqu’un qui dit vouloir tout tester n’a jamais maintenu une suite de tests front-end sur la durée. On cherche la distinction entre comportement observable et détail d’implémentation.
Question 5 — « Vous devez migrer un composant Options API vers Composition API. Que faites-vous en premier, et que ne touchez-vous surtout pas ? »
Question de prudence autant que de technique. Les bonnes réponses commencent par « je vérifie qu’il y a un test, sinon j’en écris un » — ce qui est exactement le réflexe qu’on veut dans une base de code héritée.
Besoin d’un développeur Vue.js sans passer par 27 entretiens ?
Nous présentons des profils Vue.js et Nuxt déjà passés par cette grille, avec le compte rendu des cinq questions et l’exercice technique rendu. Vous reprenez le processus à l’étape 5.
Lance-toi — voir des profils Vue.jsÉtape 5 : faire une mise en situation sur votre propre code
Une heure, sur un vrai morceau de votre application, avec le candidat aux commandes et vous en observateur. Pas un exercice inventé : un ticket que vous auriez pu attribuer.
Ajoutez une contrainte de production réaliste au bout de vingt minutes — « en fait cette donnée peut arriver vide », « ce composant est aussi utilisé sur la page de paiement ». Vous n’évaluez pas la vitesse mais la réaction au changement de cadre, qui est l’essentiel du métier.
Cinq candidats ont atteint cette étape sur 27. Quatre ont reçu une offre. C’est le meilleur taux de conversion de tout l’entonnoir, ce qui indique que le filtrage en amont fait correctement son travail.
Étape 6 : vérifier les références sur le travail en équipe
Deux appels de quinze minutes, et deux questions utiles seulement : comment cette personne réagit-elle en revue de code, et que s’est-il passé la dernière fois qu’elle a été en désaccord technique avec quelqu’un de plus expérimenté.
Tout le reste — ponctualité, autonomie, qualité — produit des réponses convenues sans valeur informative. Ces deux questions-là produisent des anecdotes, et les anecdotes sont vérifiables.
Étape 7 : faire une offre chiffrée et datée
Une offre écrite, avec un montant, une date de réponse, et la fourchette d’évolution à douze mois. Sur nos quatre recrutements, deux candidats avaient une offre concurrente ; les deux ont accepté la nôtre, dans un cas pour un montant inférieur, parce que l’annonce et le processus avaient été honnêtes sur l’état du code.
Voici les fourchettes que nous avons réellement pratiquées ou discutées en 2026 :
| Profil | Hors Île-de-France | Île-de-France | Freelance (TJM) |
|---|---|---|---|
| Junior (0 à 2 ans) | 34 000 – 40 000 EUR | 38 000 – 45 000 EUR | 300 – 400 EUR |
| Confirmé (3 à 5 ans) | 45 000 – 55 000 EUR | 52 000 – 64 000 EUR | 450 – 550 EUR |
| Senior + Nuxt rendu serveur | 58 000 – 68 000 EUR | 64 000 – 78 000 EUR | 550 – 650 EUR |
Ce que nous ferions différemment
Deux choses. D’abord, poser la question 2 — celle du rendu serveur — par écrit, avant l’entretien. Elle élimine à elle seule plus de la moitié des candidats sur un poste Nuxt, et lui consacrer un créneau d’entretien complet est un gaspillage de temps pour les deux parties.
Ensuite, dire le salaire dans l’annonce. Nous ne l’avons fait que sur le quatrième poste, et il a été pourvu en 21 jours contre 34 en médiane. Le vivier Vue.js français est suffisamment étroit pour que les candidats compétents aient le choix : leur faire deviner votre fourchette est un luxe que peu d’entreprises peuvent s’offrir.
« 4 ans de Vue.js » ne veut rien dire tant qu’on n’a pas demandé si ces quatre années comportaient un rendu serveur, une migration et une suite de tests. Trois questions, et le CV redevient lisible. — Sebastian, D-Open
Pour aller plus loin
Si votre besoin est ponctuel plutôt que permanent, la logique change complètement : notre analyse du contrat de mission freelance et de la propriété intellectuelle traite les points à border avant de démarrer. Et si vous partez d’une page blanche, notre guide pour créer une plateforme de mise en relation aide à trancher la question du rendu serveur avant d’écrire l’annonce — ce qui est l’ordre correct.
Sur la manière de faire monter en compétence un profil junior sur une base de code héritée, les retours publiés par Plug-Tech sur l’accompagnement d’équipes internes sont transposables. Et pour tout ce qui touche aux habilitations et à la sécurisation des accès d’un nouvel arrivant, les procédures d’intégration documentées par WebGuard Agency évitent quelques oublis classiques la première semaine.
Commencez par réécrire votre annonce
Si vous ne faites qu’une chose : ajoutez la version de Vue, la présence ou non de Nuxt, l’état réel du code et la fourchette de salaire. Vous recevrez moins de candidatures et vous recruterez plus vite.
Lance-toi — parler à un ingénieurFAQ : recruter un développeur Vue.js en France
Quel salaire proposer à un développeur Vue.js en France en 2026 ?
Un profil confirmé de trois à cinq ans se situe entre 45 000 et 55 000 EUR bruts annuels hors Île-de-France, et entre 52 000 et 64 000 EUR en région parisienne. Un senior avec expérience de migration Vue 2 vers Vue 3 et maîtrise du rendu serveur Nuxt atteint 70 000 EUR. En freelance, le taux journalier constaté va de 450 à 650 EUR selon la séniorité et la durée.
Vue.js ou React : le vivier est-il vraiment plus petit ?
Plus petit en volume, mais moins bruité. Nous avons reçu 61 candidatures pour un poste Vue.js contre environ 200 pour un poste React comparable, avec un taux de pertinence nettement supérieur : 27 entretiens tenus sur 61 candidatures. Le tri coûte moins cher, ce qui compense largement l’étroitesse du vivier.
Faut-il exiger Nuxt ou seulement Vue.js ?
Cela dépend de votre rendu. En rendu serveur, Nuxt n’est pas un bonus mais le cœur du poste, et un développeur Vue.js sans cette expérience mettra plusieurs semaines à être autonome. En application monopage classique, l’exiger réduit votre vivier d’environ un tiers sans bénéfice. Tranchez avant d’écrire l’annonce.
Combien de temps prend un recrutement Vue.js de bout en bout ?
Trente-quatre jours en médiane sur nos quatre recrutements. Le plus long a pris 61 jours parce que l’annonce ne précisait pas la version de Vue, ce qui a produit un afflux de candidatures inadaptées. Le poste dont l’annonce affichait le salaire a été pourvu en 21 jours.