Quand un fondateur me montre la fiche de poste de son futur développeur, je la lis avec une seule question en tête : un bon développeur, déjà en poste et plutôt bien traité, aurait-il envie de répondre ? La plupart du temps, la réponse est non. Pas parce que le poste est mauvais, mais parce que la fiche dit tout ce qui intéresse une grille RH et presque rien de ce qui intéresse la personne qu'on veut convaincre.
Une bonne fiche de poste de développeur répond aux trois questions que se pose le candidat : ce qu'il va construire, avec qui et comment il va travailler, et ce que vous lui proposez vraiment. Elle sépare l'indispensable de ce qui s'apprend, affiche une fourchette de salaire et dit clairement pour qui le poste n'est pas fait.
Si vous voulez d'abord clarifier quel profil recruter et à quel moment, c'est dans le guide pour construire son équipe tech et produit. La fiche s'insère dans un process de recrutement tech plus large, et si c'est un CTO que vous cherchez, la logique est différente : elle est détaillée dans la fiche de poste d'un CTO en startup. Ici, on prend une fiche de développeur réaliste et on la réécrit.
La fiche « avant » : celle que je relis presque toujours
Voici une fiche fictive, mais assemblée à partir de phrases que j'ai lues des dizaines de fois :
Développeur full-stack H/F. Startup en forte croissance, vous rejoignez une équipe jeune et dynamique. Missions : développer de nouvelles fonctionnalités, maintenir l'application, participer aux choix techniques. Profil : Bac+5, 5 ans d'expérience minimum, maîtrise de React, Vue, Node.js, PHP, Python, Docker, Kubernetes, AWS. Passionné, autonome, force de proposition. Salaire selon profil. Télétravail possible.
Chaque ligne pose un problème. « Forte croissance » et « équipe dynamique » s'appliquent à toutes les startups, donc à aucune. Les missions décrivent le métier de développeur en général, pas ce poste. Les « 5 ans minimum » écartent un excellent profil de trois ans et laissent passer quelqu'un qui a répété la même année cinq fois. La liste de technologies, elle, envoie un signal que les fondateurs ne soupçonnent pas : soit vous ne savez pas ce qui tourne en production, soit tout y tourne à la fois, et aucune des deux hypothèses ne rassure. Quant à « salaire selon profil », un senior le lit comme « en dessous du marché ».
Quand je lis quinze technos et aucun mot sur le produit, je comprends que personne ne m'a écrit cette annonce. Elle a été écrite pour un logiciel de tri de CV.
Les trois questions qu'un développeur se pose en lisant
Un développeur qui lit votre fiche ne coche pas des cases. Il cherche à savoir si ce poste sera mieux que celui qu'il occupe déjà. Tout ce qui ne l'aide pas à répondre à l'une de ces trois questions est du bruit.
Qu'est-ce que je vais construire ?
Le produit, pour qui, et surtout les chantiers concrets des six premiers mois. Un développeur s'engage sur un problème, pas sur un intitulé. Dire qu'il reprendra un module fragile écrit par une agence n'est pas un aveu de faiblesse : c'est une information que les bons profils apprécient, parce qu'ils savent où ils mettent les pieds.
Avec qui, et comment on travaille ?
Qui sont les fondateurs, qui code déjà, qui relit le code, comment une idée devient une fonctionnalité en production. La stack réelle, en quatre ou cinq noms, pas quinze. Et la place du remote, écrite précisément : « deux jours sur site à Lyon » vaut mieux que « télétravail possible ».
Qu'est-ce que vous me proposez vraiment ?
Une fourchette de salaire, le type de contrat, la part au capital si elle existe, et le déroulé du recrutement. Annoncer le process (nombre d'étapes, délai, nature de l'échange technique) montre que vous respectez son temps. C'est souvent ce paragraphe qui décide un candidat en poste à franchir le pas.
La même fiche, réécrite
Même poste, même entreprise, même budget. Le texte est plus long, mais il se lit jusqu'au bout parce que chaque ligne apprend quelque chose au candidat.
Développeur full-stack TypeScript (CDI, Lyon).
Le produit. Un logiciel de planification pour les cabinets infirmiers libéraux. Une quarantaine de cabinets l'utilisent et le paient chaque mois.
Vos six premiers mois. Reprendre le module de facturation, construit par une agence sans tests, pour le fiabiliser. Puis construire la synchronisation avec les logiciels de télétransmission, la fonctionnalité que les cabinets réclament le plus.
L'équipe. Deux fondateurs, dont une ancienne infirmière libérale qui connaît chaque utilisateur par son prénom. Un développeur senior en poste depuis dix-huit mois, qui relira votre code comme vous relirez le sien.
La stack. TypeScript, Next.js, PostgreSQL, hébergement en France.
Indispensable. Avoir déjà mis en production et maintenu une application web utilisée par de vrais clients. Ce qui s'apprend ici. Next.js si vous venez d'un autre framework, le métier de la santé, la télétransmission.
Ce poste n'est pas pour vous si vous cherchez à travailler sur une architecture neuve sans historique, ou si parler régulièrement à des utilisateurs vous pèse.
Conditions. 50 à 60 K€ brut annuel selon expérience, BSPCE, deux jours par semaine sur site.
Le process. Un appel de 30 minutes, puis une heure à lire et discuter ensemble du vrai code du produit, puis une rencontre avec l'équipe. Réponse sous trois semaines, pas de test à faire chez vous le week-end.
J'ai choisi exprès une fourchette de salaire courante sur le marché régional pour un profil confirmé. Adaptez-la à votre ville et à votre budget, mais affichez-la. Remarquez aussi ce qui a disparu : les adjectifs, les années d'expérience, la liste de technologies. Rien de tout cela n'aidait le candidat à se décider, et tout cela vous faisait recevoir des candidatures que vous auriez écartées.
Ce qui repousse les mauvais profils, et c'est voulu
La réécriture produit moins de candidatures, et c'est précisément ce qu'on cherche. Chaque candidature hors cible vous coûte une lecture, un appel, parfois un entretien. Une fiche qui filtre bien vous rend ces heures.
Le paragraphe « ce poste n'est pas pour vous si »
C'est la ligne que les fondateurs hésitent le plus à écrire, et celle qui travaille le plus. Elle ne vise pas à décourager, elle nomme honnêtement les contraintes du poste : du code existant à reprendre, des utilisateurs à écouter, une petite équipe où personne ne filtre les urgences. Le développeur qui cherche une architecture neuve et un rôle purement technique s'écarte seul, sans rancœur. Celui qui aime justement remettre d'aplomb un produit qui a des clients se sent enfin visé. Vous obtenez en une phrase un tri que plusieurs entretiens n'auraient pas fait.
Deux autres choix font le même travail. Remplacer « X ans d'expérience » par une expérience vérifiable (« avoir maintenu une application en production ») filtre sur ce qui compte vraiment. Et séparer l'indispensable de ce qui s'apprend évite de perdre les profils prudents, qui ne postulent pas tant qu'ils ne cochent pas toutes les cases, alors qu'ils sont souvent les plus rigoureux.
Si vous n'êtes pas technique, vous ne pouvez pas vérifier seul que la stack annoncée est cohérente, que l'indispensable n'est pas irréaliste, ou qu'un chantier décrit en une phrase ne représente pas six mois de travail. Un développeur de votre réseau repérera en dix minutes ce qui ferait tiquer un candidat. C'est le même réflexe que pour la suite du processus, où il faudra évaluer un développeur sans être technique.
Une fiche tient ses promesses, ou elle se retourne contre vous
Une bonne fiche crée des attentes précises, et ces attentes vous engagent. Si vous annoncez une heure de discussion sur du vrai code, n'envoyez pas un test de huit heures au deuxième tour : le candidat le vivra comme une trahison, et il aura raison. La manière de concevoir cet échange sans perdre les bons profils est détaillée dans tests techniques en recrutement.
Enfin, même parfaite, une fiche publiée sur un site d'emploi touche rarement les meilleurs, qui ne lisent pas les annonces. Elle sert surtout de support aux messages que vous envoyez et aux recommandations de votre réseau, ce que je détaille dans où trouver un bon développeur pour sa startup. S'il s'agit de votre tout premier recrutement technique, commencez par recruter son premier développeur sans être technique : la fiche n'est qu'une des décisions à prendre.
J'aide des fondateurs à définir le bon profil, à écrire une fiche qui filtre et à mener le recrutement jusqu'à la signature. Découvrez la création d'équipe tech et produit, ou réservons 30 minutes pour en parler.
Et maintenant ?
Où en êtes-vous ?
Choisissez la situation qui vous ressemble. Pour chacune : ce que je vous conseille de lire, et ce que je peux faire avec vous.
Je dois recruter mes premiers profils techniques
Le premier recrutement conditionne tous les suivants.
Personne en interne ne sait arbitrer la technique
Les choix se prennent sans vous, et vous en découvrez les effets après coup.
Mon prestataire est le seul à connaître mon produit
Personne en interne ne sait reprendre le code ni les serveurs.
ou appelez-moi au 06 20 52 03 69