Recruter n'est pas une fin en soi. On recrute pour accélérer la création de valeur, pas pour remplir un organigramme. C'est une nuance qui a l'air anodine, mais elle change tout : elle conditionne le profil qu'on cherche, le niveau d'expérience visé, l'urgence réelle du besoin et même la manière de mener les entretiens. Avant de lancer un process, posez-vous les bonnes questions.
- Quelle valeur le nouveau collaborateur va-t-il créer, et dans quel délai ? 2. Quelles compétences manquent pour accélérer cette création de valeur ? 3. Faut-il recruter un junior ou un senior ? 4. Quel est l'état actuel du marché pour ce profil ?
Sur le papier, ces questions paraissent évidentes. En pratique, je vois énormément d'équipes lancer une offre parce qu'« on est débordés » ou parce qu'un budget de recrutement vient d'être validé. Le besoin réel n'a jamais été formulé. Résultat : on déroule un process générique, on prend la personne qui coche le plus de cases sur le CV, et six mois plus tard on se demande pourquoi l'impact n'est pas au rendez-vous. Un bon process commence bien en amont du premier entretien, et s'inscrit dans une démarche plus globale pour structurer son équipe tech et produit, où chaque recrutement répond à un manque précis.
Les étapes clés d'un process efficace
Voici une trame de référence. Elle n'est pas gravée dans le marbre (selon le niveau du poste et le type de contrat, on enlève ou on ajoute des étapes), mais elle donne une vue d'ensemble du chemin qu'un candidat va parcourir.
| Étape | Durée | Objectif | Qui |
|---|---|---|---|
| Pré-qualification | 15 min | Filtrer les profils inadaptés | RH ou Manager |
| Entretien Manager | 1h | Contexte du poste, fit humain | Manager direct |
| Test pratique | 2-4h | Évaluer les compétences réelles | Équipe |
| Entretien RH | 1h | Diversité, admin, package | RH |
| Validation C-Level | 30 min | Alignement stratégique | CTO/CPO |
Chaque étape doit avoir un objectif clair et une décision à la sortie : on continue, ou on s'arrête. Un process qui empile des entretiens sans que personne ne sache vraiment ce qu'il valide est un process qui fatigue le candidat, mobilise l'équipe pour rien et finit par laisser passer les meilleurs profils faute de rapidité.
Adopter une approche Lean
Le temps est l'ennemi du recrutement. Un candidat de qualité a plusieurs offres en parallèle. Si vous traînez, vous le perdez : pas parce que votre offre était mauvaise, mais parce qu'une autre est arrivée avant vous, plus claire et plus rapide.
Les principes clés :
- Avancer vite (décision sous 2 semaines max)
- Rendre les décisionnaires disponibles
- Valider le process en amont (pas de surprise de dernière minute)
- Mobiliser les bonnes ressources dès le départ
Le piège classique, c'est le décisionnaire indisponible. Vous avez fait passer trois entretiens, le candidat est emballé, et il ne reste qu'une validation finale du CTO ou du CEO… qui est en déplacement pendant dix jours. Pendant ce temps, le candidat signe ailleurs. Caler les disponibilités des décideurs avant de lancer le sourcing évite ce genre de gâchis.
Le rythme dépend toutefois du type de poste, et c'est là qu'il faut nuancer. Pour un freelance, je vais beaucoup plus vite : le risque est faible, l'engagement est réversible, on se teste mutuellement sur une mission courte et on ajuste. Pour un CDI, le temps et le cycle ne sont pas les mêmes. Les très bons développeurs, ceux qui assurent la pérennité d'une équipe et la qualité dans la durée, ne sont pas toujours ceux qui ont le plus faim : ils sont déjà bien là où ils sont, ils ne courent pas après une offre. Les débaucher demande de la patience, plusieurs échanges, parfois plusieurs mois. « Aller vite » ne veut donc pas dire « tout boucler en une semaine pour tout le monde » : ça veut dire ne jamais être le maillon lent du process une fois qu'un bon candidat est dans le pipe. Pour arbitrer entre ces formats d'engagement, j'ai détaillé les trois grandes options dans CTO freelance, fractionnel ou CDI : comment choisir ? : la logique se transpose directement aux profils tech.
Attirer les candidats
Le salaire ne fait pas tout. Les développeurs et profils Produit évaluent aussi :
- La mission : quel problème résout-on ?
- Les valeurs : comment travaille-t-on ensemble ?
- La stack technique : est-elle moderne et maintenable ?
- Les conditions : remote, équipement, locaux
En phase de lancement ou de création d'équipe tech & produit, ces éléments sont cruciaux pour compenser une notoriété encore faible. Une jeune startup ne peut pas s'aligner sur les salaires d'un grand groupe, mais elle peut offrir ce que le grand groupe ne propose pas : un impact direct sur le produit, une autonomie réelle, une stack choisie pour de bonnes raisons et pas par inertie historique. Encore faut-il le rendre tangible dès l'offre d'emploi, pas le garder pour le dernier entretien.
Rédiger une offre d'emploi qui attire les bons développeurs quand votre startup est inconnue
Pour attirer un bon développeur quand votre startup n'a aucune notoriété, votre offre d'emploi doit vendre ce qu'un grand groupe ne peut pas offrir : une mission concrète, une équipe à taille humaine et ce qu'il va y apprendre. Là où une fiche de poste générique énumère des compétences, une offre qui convertit raconte un projet auquel le bon profil a envie de se joindre.
C'est le piège dans lequel tombent la plupart des jeunes startups : elles recopient le format d'annonce d'un grand groupe (intitulé, liste de missions, liste de compétences, avantages) alors que ce format ne marche que pour une marque déjà connue. Quand personne ne sait qui vous êtes, le candidat ne lit pas votre annonce en se demandant « est-ce que je coche les cases ? », il la lit en se demandant « pourquoi j'irais chez eux plutôt que de rester là où je suis ? ». Tant que l'offre ne répond pas à cette question-là, le salaire seul ne suffira pas à débaucher un bon profil déjà installé ailleurs.
Concrètement, je construis une offre de startup inconnue autour de trois choses que le grand groupe ne sait pas vendre :
- La mission, racontée comme une histoire, pas comme un intitulé. Quel problème vous attaquez, pour qui, et pourquoi maintenant. Un développeur curieux a besoin de sentir l'enjeu, pas de lire « rejoindre une équipe dynamique dans un secteur en croissance ». Si votre projet ne tient pas en deux phrases qui donnent envie, le problème n'est pas l'annonce, c'est le pitch.
- L'équipe, montrée à visage découvert. Qui sont les fondateurs, qui sont les premiers développeurs, comment vous travaillez au quotidien. À ce stade, le candidat ne rejoint pas une entreprise, il rejoint des personnes. Nommez-les, dites d'où ils viennent, assumez la petite taille : c'est un argument, pas une faiblesse.
- Ce qu'il va apprendre et l'impact qu'il aura. Dans une startup, un développeur touche à tout, voit l'effet de son code en production en quelques jours et pèse sur les décisions techniques. C'est exactement ce qu'un grand groupe ne peut pas promettre. Dites-le explicitement : autonomie réelle, périmètre large, voix au chapitre sur la stack et le produit.
Le réflexe inverse, celui qui plombe les annonces de startup, c'est d'essayer de paraître plus gros qu'on n'est : vocabulaire corporate, liste de quinze technos, « process » et « méthodologies » survendus. Un bon développeur le repère immédiatement et fuit, parce que ça sonne faux. L'authenticité d'une petite structure assumée attire bien davantage que l'imitation maladroite d'un grand groupe. Votre marque employeur, à ce stade, c'est votre honnêteté.
Une fois l'offre écrite, encore faut-il qu'elle atterrisse sous les bons yeux : une annonce sincère ne sert à rien si elle reste sur une page carrière que personne ne visite. C'est tout l'enjeu du sourcing, que j'ai traité à part dans où trouver un bon développeur pour sa startup. Et comme toujours, cette offre découle d'une décision prise en amont sur la forme de l'équipe : si elle n'est pas encore posée, commencez par le guide pour structurer son équipe tech et produit.
Comment rédiger une fiche de poste développeur qui attire les bons
Une fiche de poste développeur efficace fait deux choses : elle attire les bons profils et repousse les mauvais. Pour ça, soyez concret. Décrivez la mission réelle, la stack précise, le quotidien et le niveau d'exigence, plutôt qu'une liste de buzzwords. Un profil aligné se reconnaît ; un profil hors-cible se disqualifie de lui-même.
Le réflexe à fuir, c'est l'annonce passe-partout : « nous recherchons un développeur talentueux, passionné, autonome, force de proposition ». Personne ne se reconnaît là-dedans, et surtout personne ne s'exclut. Or une bonne annonce doit autant filtrer que séduire. Plus elle est vague, plus vous recevez de candidatures hors-cible que vous devrez trier à la main, et moins le bon profil se sent visé.
Concrètement, voici ce que je mets dans une fiche de poste qui travaille pour moi :
| Bloc | Ce qu'on y écrit | Ce que ça filtre |
|---|---|---|
| La mission réelle | Le problème produit à résoudre, pas l'intitulé RH | Celui que le sujet n'intéresse pas passe son chemin |
| La stack précise | Les vraies technos, sans gonfler la liste | Le profil hors-stack s'auto-écarte |
| Le quotidien | Une journée type, le ratio code / réunions / revues | Celui qui veut autre chose se reconnaît tout de suite |
| Le niveau d'exigence | Tests, revue de code, ownership attendu | Le candidat à l'aise avec ça est attiré, l'autre fuit |
La stack mérite une mention à part : c'est un signal de tri très fort. Annoncez précisément ce sur quoi le poste tourne, sans gonfler la liste pour paraître moderne. Un développeur compétent repère immédiatement une annonce qui empile quinze technos « pour faire bien ». Pour calibrer ce que vous mettez en avant et pourquoi, j'ai détaillé la méthode dans Choisir sa stack technique.
Dernier point : la fiche de poste n'est jamais isolée. Elle traduit une décision prise en amont sur la forme de l'équipe et le manque précis que ce recrutement vient combler. Si vous n'avez pas encore posé cette structure, commencez par là avec le guide pour structurer son équipe tech et produit et l'article frère Composer son équipe tech en startup : une fiche de poste juste découle toujours d'un besoin clairement formulé.
Le test technique : montrer comment on bosse, pas piéger
C'est l'étape qui révèle le plus de choses, et c'est aussi celle que la plupart des équipes ratent. Le mauvais réflexe : sortir un exercice algorithmique chronométré, façon épreuve d'école, qui n'a rien à voir avec le quotidien du poste. On y évalue le stress et la culture du concours, pas la capacité à produire du bon code dans un vrai contexte.
J'ai conçu et fait tourner un dispositif radicalement différent pendant des années, et il a très bien fonctionné. Le principe : un test fait à la maison, sans pression. On laissait environ deux semaines au candidat pour rendre un exercice qui, lui, ne devait pas dépasser deux heures de travail effectif. L'idée n'était pas de mesurer combien de temps il y passait, mais de lui retirer la contrainte de l'horloge pour qu'il code comme il code vraiment.
Le support, c'était un repo qu'on avait construit nous-mêmes : une mini-application de porte-monnaie électronique. On demandait au candidat d'ajouter une petite fonctionnalité concrète (par exemple, pouvoir dépenser de l'argent en s'assurant que le solde du compte ne passe jamais en négatif) et de livrer son travail via une merge request, exactement comme un développeur le ferait au quotidien dans l'équipe. La consigne tenait en une phrase : écris ce code comme tu l'écrirais chez nous, en production.
Le vrai intérêt venait après le rendu. On revoyait la merge request avec d'autres développeurs de l'équipe, en conditions réelles : commentaires, questions, suggestions, discussion sur les choix de conception. C'était exactement le process de revue de code interne, appliqué au candidat. Deux bénéfices d'un coup. D'abord, le candidat découvrait concrètement comment on travaillait : niveau d'exigence sur les tests, ton des revues, manière de discuter un désaccord technique. Ensuite, l'équipe voyait le candidat non pas sur un livrable figé, mais sur sa capacité à recevoir un feedback, à argumenter, à ajuster. C'est précisément ce qui compte une fois en poste. Ce qu'on évalue ici, ce n'est pas la performance sous pression : ce sont les méthodes de travail réelles, et surtout la façon de discuter une revue de code avec l'équipe : pile le quotidien du poste.
Le bilan parle de lui-même. Sur plusieurs années, une centaine de développeurs ont été recrutés via ce dispositif, avec très peu d'erreurs de casting. Et un point que je trouve encore plus parlant : quasiment aucune rupture de période d'essai à l'initiative d'un candidat déçu par l'écart entre ce qu'on lui avait vendu et la réalité du terrain. C'est logique : quand le test EST le quotidien du poste, le candidat sait à quoi il s'engage avant même de signer. Il n'y a pas de mauvaise surprise une fois en place, parce qu'il a déjà goûté à la façon dont l'équipe travaille.
Tout cela demande de l'investissement. Construire un repo réaliste, écrire une consigne courte mais non ambiguë, mobiliser deux ou trois développeurs pour chaque revue : ce n'est pas gratuit. Mais c'est un investissement qui se rentabilise vite quand on le compare au coût d'une erreur de recrutement, qui se chiffre en mois de salaire, en énergie d'équipe et en dette technique accumulée. Pour aller plus loin sur les formats, la durée et les pièges classiques, j'ai consacré un article entier au sujet : Tests techniques en recrutement : évaluer les compétences sans perdre de candidats.
Qui intervient dans le process ?
| Intervenant | Rôle | Ce qu'il valide |
|---|---|---|
| L'équipe | Fit humain et technique | "Je veux travailler avec cette personne" |
| Le Manager | Contexte et confiance | "Cette personne peut réussir ici" |
| Les RH | Diversité et admin | "Le profil enrichit l'équipe" |
| Le C-Level | Stratégie | "Ce recrutement sert notre vision" |
Faire intervenir plusieurs personnes n'est pas une lourdeur administrative, c'est une assurance. Chacun regarde le candidat sous un angle que les autres n'ont pas. L'équipe sent le fit au quotidien, le manager juge la capacité à réussir dans le contexte précis du poste, les RH veillent à la cohérence d'ensemble et à la diversité, le C-Level vérifie que le recrutement sert la trajectoire de l'entreprise. Le piège inverse existe aussi : trop d'intervenants diluent la décision et personne ne tranche. À chaque étape, désignez qui a le dernier mot.
En phase de scaling, le recrutement devient un enjeu stratégique. Je vous aide à définir les profils, structurer le process et former vos managers aux entretiens.
Le fit culturel prime sur les compétences
La plupart des échecs de recrutement ne viennent pas d'un manque de skills. Le vrai problème : le candidat n'a pas réussi à s'intégrer à l'équipe.
Un candidat moins expérimenté mais aligné avec la culture progressera plus vite qu'un expert qui ne s'intègre pas. Les compétences techniques se rattrapent ; un désaccord profond sur la manière de travailler ensemble, beaucoup moins. C'est exactement pour ça que le test pratique décrit plus haut était aussi efficace : en faisant vivre au candidat une revue de code réelle, il révélait les méthodes de travail et la posture relationnelle, pas seulement la maîtrise technique. Un candidat qui prend mal le moindre commentaire sur sa merge request en dira plus long sur son intégration future qu'une ligne de plus sur son CV.
Le package : au-delà du salaire
Pour vous différencier, pensez à :
- Avantages financiers : mutuelle, transport, budget formation
- Conditions de travail : remote, flexibilité, localisation
- Équipement : Mac récent, écrans, bureau ergonomique
- Perspectives : BSPCE, évolution de carrière
Le package ne se résume jamais au chiffre sur la fiche de paie. Un développeur expérimenté compare des offres dans leur globalité : la qualité de l'équipement, la souplesse du remote, la trajectoire de carrière proposée. Sur ce dernier point, les BSPCE sont un levier puissant mais souvent mal utilisé : ce n'est pas un bonus immédiat et il faut savoir quand les sortir. Pour comprendre quand et comment les employer, consultez mon article BSPCE : oui ou non ?
Après le recrutement... et après un refus
Un candidat refusé aujourd'hui peut être le bon dans 2 ans. Il parle aussi de son expérience à son réseau, et dans le petit monde de la tech, votre réputation d'employeur se construit autant sur la façon dont vous traitez les candidats que vous écartez que sur celle dont vous accueillez ceux que vous gardez. Soignez la relation :
- Donnez un feedback constructif
- Restez en contact (LinkedIn)
- Gardez une base de candidats qualifiés
Et une fois le candidat retenu, l'enjeu se déplace vers l'onboarding : transformer cette signature en un collaborateur épanoui et productif. Un bon recrutement mal embarqué reste un échec ; les premières semaines décident d'une grande partie de la réussite. Le process ne s'arrête donc pas à la signature : il bascule simplement dans une autre phase, tout aussi déterminante.
Envie d'en discuter ?
Réservez un créneau de 30 minutes pour un premier échange. Je vous aiderai à y voir plus clair sur votre situation.
Prendre rendez-vous