Recruter son premier développeur sans être technique

Votre produit a besoin de quelqu'un qui code tous les jours, et vous n'avez jamais recruté de développeur. Vous ne savez pas lire un CV technique, encore moins juger un exercice de code, et vous sentez bien que ce premier recrutement comptera plus que les suivants. L'intuition est juste : le premier développeur ne rejoint pas une équipe, il la fonde, et ses choix vous suivront pendant des années.

Pour recruter son premier développeur sans être technique, ne menez pas le processus seul. Faites cadrer le poste et juger la partie technique par un tiers de confiance (développeur senior, CTO fractionnel), gardez pour vous la motivation, la communication et le rapport au produit, et décidez avant son arrivée de ce qu'il pourra trancher seul.

Ce recrutement est la première brique d'un chantier plus large, que je décris dans le guide pour construire son équipe tech et produit. Si c'est un directeur technique que vous cherchez, le processus diffère et il est détaillé dans comment recruter un CTO. Quant aux canaux pour trouver des candidats, ils ont leur propre article : où trouver un bon développeur pour sa startup. Ici, on regarde le processus lui-même, du cadrage du poste au premier jour.

Le premier développeur n'est pas un développeur comme les autres

Le cinquième développeur d'une équipe arrive dans un cadre : des conventions, une architecture, quelqu'un qui relit son code. Le premier arrive dans le vide. Il choisit la stack, organise le code, installe l'hébergement, décide comment on met en production. Et comme personne au-dessus de lui ne peut le challenger, chacune de ces décisions est prise par défaut, bonne ou mauvaise.

C'est pour cette raison que je conseille presque toujours un profil confirmé ou senior à ce poste, plutôt que deux juniors pour le même budget : le raisonnement complet est dans composer sa première équipe tech après le MVP. Mais le niveau ne règle pas tout. Pour un fondateur non technique, la vraie question est ailleurs : qui relira ses décisions une fois qu'il sera là ? Si la réponse est « personne », vous ne recrutez pas seulement un développeur, vous confiez votre actif le plus important à quelqu'un que vous ne pourrez jamais évaluer.

Il était très bon, je n'ai rien à lui reprocher. Le problème, c'est que le jour où il est parti, personne ne savait comment le produit tenait debout.

un fondateur que j'accompagnais, dix-huit mois après son premier recrutement

Le processus en quatre temps

Cadrer le poste avec un regard technique

Avant la moindre annonce, écrivez ce que ce développeur devra avoir livré au bout d'un an, en langage business : sortir la v1 de l'application client, reprendre le code laissé par une agence, brancher le paiement en ligne. Faites relire ce cadrage par quelqu'un de technique, qui le traduira en profil (back-end ou fullstack, niveau attendu, stack réaliste). Ce document servira ensuite d'annonce, de grille d'entretien et de base pour discuter du salaire.

Choisir le tiers de confiance qui jugera la technique

Un développeur senior de votre réseau, un investisseur au passé technique, un CTO fractionnel : peu importe le titre, il faut quelqu'un qui sait lire du code et qui n'a aucun intérêt à ce qu'un candidat plutôt qu'un autre soit retenu. Fixez son rôle dès le départ (relire l'exercice, mener un entretien technique, rendre un avis écrit) et dédommagez-le si besoin. Une demi-journée de son temps par finaliste coûte beaucoup moins cher qu'une erreur de casting.

Évaluer à deux regards, sans les mélanger

Vous jugez ce que vous savez juger : l'intérêt pour votre produit, la capacité à expliquer simplement, les questions posées sur vos clients, la réaction quand vous changez une contrainte. Le tiers juge le reste, à partir d'un exercice court sur un cas proche de votre produit, comme je le décris dans les tests techniques en recrutement. Votre grille à vous, question par question, est détaillée dans évaluer un développeur sans être technique.

Décider vite, puis préparer son arrivée

Prenez deux références, dont une personne qui a relu son code au quotidien. Faites ensuite une offre rapide : un bon développeur mène souvent deux ou trois processus en parallèle. Puis préparez son arrivée pendant son préavis : les accès, la documentation existante, ses premiers sujets, et le nom de la personne qui relira ses premières décisions.

Rien de tout cela ne demande de devenir technique. En revanche, il faut renoncer à l'idée qu'un bon feeling suffira. Le feeling mesure l'aisance à l'oral et la sympathie, deux qualités utiles, mais qui n'ont presque aucun rapport avec la capacité à poser seul des fondations saines. Le processus sert précisément à mettre en face de chaque question la personne capable d'y répondre.

Ce que vous lui confiez, et ce que vous gardez

Un premier développeur autonome est une excellente nouvelle. Un premier développeur seul maître de tout est un risque, même quand il est excellent. La frontière se décide avant son arrivée, pas au lendemain de la première crise, et elle se dit explicitement dès l'entretien final : un bon candidat appréciera la clarté.

Sujet	Qui décide	Pourquoi
Organisation du code, outils du quotidien	Lui	C'est son métier, et le micro-management le fera partir
Choix de la stack et de l'hébergement	Lui, relu par le tiers	Ces décisions engagent le produit pour plusieurs années
Priorités de la roadmap	Vous	Elles viennent des clients et du marché, pas du code
Comptes, accès et propriété du code	Vous, au nom de la société	L'actif doit rester dans l'entreprise
Recrutement du deuxième développeur	Vous deux, avec le tiers	Il connaît le besoin, vous tenez le cadre et le budget

Les accès au nom de la société, dès le premier jour

Dépôt de code, hébergement, nom de domaine, comptes sur les stores, outils payants : tout doit être ouvert au nom de l'entreprise, avec vous comme administrateur. Il est fréquent qu'un premier développeur crée ces comptes avec son adresse personnelle pour aller vite. Personne n'y voit malice, jusqu'au jour où il part et où récupérer l'accès à votre propre production prend des semaines.

Les pièges d'un premier recrutement à l'aveugle

Retenir la personne qui vous rassure le plus. Sans repère technique, on choisit le candidat le plus clair, le plus sympathique, parfois celui qui arrive par un ami commun. Ce sont de vraies qualités, mais elles ne disent rien de sa capacité à construire seul. Si le tiers de confiance émet une réserve technique franche, prenez-la au sérieux, même quand le courant passe très bien.

Donner le titre de CTO pour attirer. C'est tentant quand on ne peut pas s'aligner sur les salaires du marché. Mais le titre crée des attentes que ni lui ni vous ne pourrez tenir : une vision, des recrutements, une présence face aux investisseurs. Six mois plus tard, vous êtes déçu de ne pas avoir de directeur technique, et lui d'être jugé sur un métier qu'il n'a jamais exercé.

Le laisser seul trop longtemps. Les premières semaines, tout va vite et tout le monde est content. C'est justement là que se prennent, sans témoin, les décisions qui coûteront cher plus tard. Prévoyez une relecture régulière par le tiers de confiance : une heure toutes les deux semaines suffit au début, et c'est souvent l'heure la plus rentable de votre mois.

Trancher la question du contrat par réflexe. Freelance pour démarrer vite ou CDI pour la continuité : les deux se défendent selon votre stade, et ce choix change le processus comme le calendrier. Je le traite à part dans freelance ou salarié pour son premier développeur.

Combien de temps prévoir

Entre le cadrage du poste et l'arrivée de la personne, comptez souvent trois à quatre mois : quelques semaines pour cadrer et sourcer, un mois d'entretiens si les décideurs sont disponibles, puis le préavis du candidat, souvent d'un à trois mois en France. Si votre produit ne peut pas attendre, un freelance senior peut assurer la jonction, à condition qu'il documente ce qu'il construit pour que votre recrue ne reparte pas de zéro.

On recrute votre premier développeur ensemble ?

J'interviens comme tiers de confiance technique : cadrage du poste, exercice et entretien technique, relecture des premières décisions après l'arrivée. Découvrez la création d'équipe tech et produit, ou réservons 30 minutes pour en parler.