J’ai réécrit notre fiche de poste TypeScript fullstack 4 fois — la version qui a divisé par 3 les candidatures hors sujet

William

Expert sourcing de talents · 4 septembre 2026 · 16 min de lecture

La première version de notre annonce a rapporté beaucoup de candidatures et presque aucun entretien utile. La quatrième en rapporte nettement moins, et nous embauchons. Voici les sept étapes qui séparent les deux, dans l’ordre où elles doivent être appliquées — l’étape 1 fait à elle seule la moitié du chemin.

Une fiche de poste n’est pas un document administratif : c’est le seul filtre qui travaille pendant que vous dormez. Mal écrite, elle produit un volume qu’il faut ensuite trier à la main, entretien après entretien. Bien écrite, elle fait le tri avant que quiconque ait perdu une heure.

Le poste en question était un développeur TypeScript fullstack, en France, sur un produit existant. Quatre versions publiées sur cinq mois. Ce qui suit est ce que chaque réécriture a changé et ce qu’elle a produit.

Étape 1 — Décrire les 90 premiers jours, pas le poste

C’est le changement qui a produit le plus d’effet, et c’est aussi le plus inconfortable à écrire parce qu’il oblige à savoir ce qu’on veut vraiment.

Une annonce classique décrit un rôle : « participer au développement de nos applications », « collaborer avec les équipes produit », « contribuer à l’amélioration continue ». Ces phrases sont vraies pour à peu près tous les postes de développement en France, ce qui signifie qu’elles ne renseignent personne.

Remplacez-les par ce que la personne fera réellement pendant ses trois premiers mois. Chez nous, cela donnait : reprendre un module de facturation écrit il y a quatre ans, sans tests, que deux personnes comprennent ; le couvrir de tests avant d’y toucher ; puis en extraire la logique de calcul pour qu’elle soit appelable depuis le nouveau parcours.

Cette description a deux effets opposés et également souhaitables. Elle fait fuir les personnes qui veulent démarrer un projet neuf — et c’est très bien, elles auraient été malheureuses. Elle attire celles qui aiment reprendre l’existant, une population plus restreinte et beaucoup plus rare sur le marché.

Le passage de la version 1 à la version 2 s’est joué presque entièrement là. Le volume a baissé d’environ 40 %, et la proportion de premières lectures concluantes a doublé.

Étape 2 — Publier la fourchette de rémunération

Ne pas afficher le salaire ne supprime pas la question. Cela la reporte à la fin du processus, au moment où les deux parties ont investi cinq à huit heures. Sur nos deux premières versions, trois candidats sur les onze arrivés en fin de parcours se sont retirés sur le montant. C’est le type de perte le plus coûteux qui soit.

La fourchette publiée filtre à l’entrée, gratuitement. Elle a aussi un effet interne rarement anticipé : elle oblige à trancher la fourchette avant de publier, plutôt qu’au moment de faire l’offre, quand la pression de conclure déforme le jugement.

Deux règles pratiques. La fourchette doit être réelle — si vous ne comptez pas payer le haut, ne l’affichez pas, cela se saura au premier échange. Et son amplitude doit rester raisonnable : au-delà d’un écart de 40 % entre le bas et le haut, elle cesse d’informer et redevient une esquive.

Étape 3 — Séparer indispensable et souhaitable, et s’y tenir

Le test à appliquer à chaque ligne de la colonne « indispensable » est unique : refuseriez-vous un excellent candidat qui ne l’a pas ? Si la réponse est non, la ligne appartient à la colonne « souhaitable ».

Appliqué à notre version 2, ce test a fait tomber la liste de onze exigences à trois. Les huit lignes retirées n’étaient pas fausses ; elles étaient simplement négociables, et le fait de les présenter comme obligatoires produisait un tri à l’envers.

Car c’est bien un tri inversé qui s’opère. Les candidats les plus solides lisent une liste de onze exigences, en cochent huit, et passent leur chemin en se disant que le poste n’est pas pour eux. Les moins rigoureux postulent quel que soit le contenu. Une longue liste sélectionne donc précisément la population dont vous ne voulez pas.

Étape 4 — Nommer la stack sans en faire une liste de courses

L’énumération de quinze technologies est le réflexe le plus répandu et le plus contre-productif. Elle signale deux choses au lecteur expérimenté : que personne n’a arbitré ce qui compte, et que l’équipe confond la connaissance d’un outil avec la compétence.

Ce qu’il faut nommer tient en quatre éléments : le langage, la nature de la base de données, l’environnement d’exécution, et une ou deux contraintes réelles — un volume, une exigence de latence, une intégration lourde, un existant à respecter.

Le reste s’écrit en une phrase, et cette phrase élargit le vivier plus que n’importe quelle autre : « le reste de la stack s’apprend, nous prévoyons le temps pour ça ». Un développeur TypeScript solide apprend un framework de rendu en deux semaines. Ce qui ne s’apprend pas en deux semaines, c’est travailler proprement sur une base existante, écrire des tests qui servent à quelque chose, ou tenir un contrat d’interface entre deux équipes.

Une précision utile à ce stade : si votre besoin porte sur une compétence réellement rare — une expertise de domaine, une contrainte réglementaire, un moteur métier particulier — c’est la seule chose à mettre en avant, et elle mérite d’être en tête d’annonce. Le reste peut être appris ; elle, non.

Étape 5 — Expliciter le processus de recrutement et sa durée

Trois lignes suffisent : le nombre d’étapes, ce que contient chacune, et le délai total visé. C’est une information que presque personne ne donne et que tout le monde cherche.

L’effet est double. D’abord, le candidat sait à quoi il s’engage, ce qui augmente nettement le taux de réponse aux premières sollicitations. Ensuite — et c’est l’effet principal — l’écrire vous oblige à l’avoir défini. Sur nos deux premières versions, le processus n’existait pas vraiment : il se composait au fil des disponibilités, avec des délais de dix à quinze jours entre les étapes.

Si votre processus comporte un exercice technique, dites-en la durée attendue et précisez s’il est rémunéré. Un exercice de huit heures non rémunéré et non annoncé est la première cause d’abandon en milieu de parcours, et l’abandon survient après que vous avez investi vos propres heures.

Étape 6 — Écrire le mode de travail réel

« Télétravail possible » ne veut rien dire. Les candidats ont appris à lire cette formule comme une réponse évasive, et ils ont raison de le faire.

Écrivez le réel : combien de jours sur site, lesquels sont imposés, quelle latitude horaire, comment se déroule une journée type entre travail synchrone et asynchrone, et surtout comment sont prises les décisions techniques. Ce dernier point pèse beaucoup plus qu’on ne le croit sur les profils expérimentés — plus, souvent, que quelques milliers d’euros de différence.

Si votre organisation est contraignante, dites-le franchement. Une contrainte annoncée écarte les mauvaises candidatures ; une contrainte découverte au troisième entretien fait perdre les bonnes, et laisse un souvenir durable dans un milieu où les gens se parlent.

Étape 7 — Mesurer trois indicateurs et réécrire

Une fiche de poste n’est pas un document figé. Elle se réécrit tous les trimestres tant que le poste est ouvert, à partir de trois chiffres.

La dernière ligne n’est pas une plaisanterie. Le volume de candidatures est l’indicateur le plus suivi et le plus trompeur : il augmente mécaniquement quand l’annonce devient vague, c’est-à-dire quand elle se dégrade. Une équipe qui optimise le volume optimise contre elle-même.

Les trois erreurs que nous avons commises dans l’ordre

Première erreur : décrire l’entreprise avant le travail. Nos deux premiers paragraphes parlaient de nous — histoire, valeurs, ambitions. Un candidat qui lit vingt annonces par semaine ne lit pas ces paragraphes ; il cherche ce qu’il fera. Nous les avons déplacés en fin d’annonce et rien n’a été perdu.

Deuxième erreur : confondre séniorité et durée. « 5 ans d’expérience minimum » exclut des personnes excellentes après trois ans et inclut des personnes qui ont répété la même année cinq fois. Nous avons remplacé cette ligne par la description d’une situation : avoir déjà repris seul un module qu’on n’a pas écrit et l’avoir mis sous tests. C’est vérifiable en entretien, contrairement à un nombre d’années.

Troisième erreur : publier et attendre. Une annonce est un point de départ. Sans relecture trimestrielle appuyée sur les trois indicateurs, elle se re-dégrade naturellement, chaque partie prenante y ajoutant sa ligne au fil des mois.

Si vous structurez le reste du processus, notre méthode de test technique couvre l’étape suivante, et nos guides sur les outils métier sur mesure et sur le recours à des profils externes aident à trancher entre embauche et externalisation avant même d’écrire l’annonce. Pour les profils orientés automatisation et intégration de modèles, l’outillage décrit par Plug-Tech donne une idée des compétences réellement mobilisées, et nos confrères en audit de sécurité détaillent les exigences à faire figurer dans l’annonce quand le poste touche des données sensibles.

Questions fréquentes