Recruter son premier développeur quand on est CTO solo : le guide que j'aurais voulu avoir

Il y a un moment charnière dans la vie d'une startup early-stage que personne ne prépare vraiment.

Pas la levée de fonds. Pas le premier client. Pas même le premier bug en prod à 23h.

C'est le moment où le CTO solo - celui qui a tout construit seul depuis le début - doit recruter son premier développeur.

Et c'est souvent là que tout se complique.

Pas parce que les bons profils n'existent pas. Parce que personne ne vous a expliqué que recruter quand on est seul sur la base de code, c'est un exercice complètement différent de recruter dans une équipe constituée.

Voici ce que j'ai appris, à force de le faire, de le rater, et de le refaire.

Le piège de départ : recruter un clone de soi

Quand vous avez tout construit seul, la tentation est de chercher quelqu'un qui pense exactement comme vous. Même stack, même style de code, même réflexes d'architecture.

C'est humain. C'est aussi une erreur.

Votre premier dev n'a pas besoin d'être vous en moins expérimenté. Il a besoin d'être complémentaire sur ce qui vous coûte le plus de temps aujourd'hui.

Avant d'ouvrir la moindre fiche de poste, la vraie question est : qu'est-ce que je fais en ce moment qui ne devrait pas être fait par moi ?

Pas "de quoi ai-je besoin en théorie". Pas "quel profil idéal je pourrais recruter". Ce que vous faites vous, maintenant, qui bloque la croissance du produit parce que vous en êtes le seul point d'entrée.

C'est ça, votre premier recrutement.

Cette clarification en amont change tout : vous ne cherchez plus "un bon développeur", vous cherchez quelqu'un qui résout un goulot d'étranglement précis. Et ça, ça se décrit dans une fiche de poste. Ça s'évalue en entretien. Ça se mesure après la période d'essai.

Senior ou junior : la question que tout le monde pose mal

C'est le débat qui revient systématiquement. Et il est souvent mal posé.

Le réflexe est de vouloir un profil senior, quelqu'un d'autonome qui ne va pas solliciter toutes les 10 minutes. Logique quand vous êtes déjà débordé.

Mais un senior dans une équipe d'une personne, sur une base de code qu'il n'a pas construite, avec des décisions d'architecture implicites que vous n'avez jamais eu à documenter - ça peut devenir une source de friction plus qu'un accélérateur.

Voici le filtre que j'utilise :

Recrutez un profil senior si vous avez besoin de quelqu'un qui prend des décisions techniques en autonomie, qui peut challenger votre architecture, et que vous avez le temps de l'onboarder sur le contexte métier.

Recrutez un profil intermédiaire si vous avez besoin d'un exécutant solide qui avance sur un périmètre bien défini, que vous encadrez sur la direction technique, et que vous pouvez faire monter en compétence progressivement.

Le junior en premier recrutement solo, sauf cas très particulier, c'est presque toujours une erreur. Le coût d'encadrement est trop élevé quand vous êtes encore le seul à porter la vision technique. Vous n'avez ni le temps ni la structure pour former quelqu'un en partant de zéro.

L'entretien technique : ce qui révèle vraiment un profil

Les tests techniques classiques mesurent la syntaxe. Ils ne mesurent pas ce qui compte vraiment dans un contexte early-stage.

Ce que je cherche à évaluer, ce sont trois choses :

1. La gestion de l'ambiguïté

Je donne un problème volontairement sous-spécifié. Je ne cherche pas la bonne réponse - je cherche les bonnes questions. Un développeur qui demande le contexte métier avant de coder la solution est infiniment plus précieux qu'un développeur qui optimise dans le vide.

Dans une startup, les specs sont toujours incomplètes. Ce qui compte, c'est la capacité à naviguer dans l'incertitude sans se bloquer.

2. La posture face à du code qu'il n'a pas écrit

Je montre un extrait de ma base de code, avec ses imperfections, ses compromis, ses raccourcis assumés. Comment réagit-il ? Critique-t-il sans comprendre le contexte ? Cherche-t-il à comprendre pourquoi avant de juger ?

La réponse dit beaucoup sur ce que ça donnera au quotidien. Une base de code early-stage est toujours imparfaite. Quelqu'un qui ne peut pas travailler dedans sans mépris pour ce qui a été fait avant lui ne tient pas dans une équipe de deux.

3. La capacité à estimer honnêtement

Je donne une feature à chiffrer. Pas pour tester la précision - pour tester l'honnêteté. Un développeur qui dit "je ne sais pas, j'ai besoin de creuser tel point" est plus fiable qu'un développeur qui annonce 3 jours avec une assurance qui cache une absence de questionnement.

Les estimations fausses en early-stage ne tuent pas les projets - c'est la confiance aveugle dans des estimations fausses qui les tue.

L'onboarding : l'étape que les CTO solo sabotent systématiquement

Vous avez recruté. Vous êtes soulagé. Vous avez envie de déléguer immédiatement.

C'est là que la plupart des premiers recrutements échouent.

Quand vous avez construit seul, votre base de code est pleine de décisions implicites. Des choix d'architecture que vous n'avez jamais eu à expliquer parce que vous en êtes le seul auteur. Des conventions que vous appliquez naturellement et qui n'existent nulle part dans une documentation.

Votre nouveau développeur ne peut pas deviner tout ça. Et il ne vous le dira pas, parce qu'il ne sait pas encore ce qu'il ne sait pas.

Voici ce que je mets en place systématiquement :

Une session d'architecture d'abord. Avant la première ligne de code - 2 à 3 heures où je marche dans la base de code avec lui. Pas pour tout expliquer. Pour expliquer les décisions structurantes et les zones où il ne doit pas improviser sans en parler.

Un premier ticket représentatif, pas le plus simple. Le premier ticket doit ressembler au travail réel. Un ticket trop simple ne lui apprend rien sur la façon dont le produit fonctionne. Un ticket représentatif lui donne une vraie carte d'entrée dans la base de code.

Des points courts et fréquents au début. Pas pour micro-manager. Pour détecter les incompréhensions avant qu'elles deviennent des jours de travail dans la mauvaise direction. Au bout de 3 semaines, si l'onboarding se passe bien, ces points s'espacent naturellement.

L'onboarding mal géré, c'est le cas le plus fréquent d'un recrutement qui semblait bien parti et qui tourne court en période d'essai.

La question que personne ne pose avant de signer

Est-ce que cette personne sera encore adaptée dans 12 mois ?

Le contexte d'une startup change vite. La base de code va évoluer. L'équipe va grandir. Les problèmes à résoudre vont changer de nature.

Le profil parfait pour les 3 premiers mois n'est pas toujours le profil qui scale avec le produit.

Ce n'est pas une raison pour ne pas recruter. C'est une raison pour être honnête dès l'entretien sur la trajectoire du poste, sur ce que le rôle va devenir, et sur ce qu'on attend en termes d'évolution.

Un développeur qui sait dans quoi il s'engage reste. Un développeur qu'on a mal informé part au pire moment - en général au moment où vous commencez à avoir besoin d'une deuxième personne.

Ce que ce recrutement dit de vous en tant que CTO

Recruter son premier développeur quand on est solo, c'est aussi la première fois qu'on bascule d'un mode "je fais" à un mode "je fais et je fais faire".

C'est inconfortable. Parce que déléguer du code qu'on a écrit soi-même, c'est accepter que quelqu'un d'autre prenne des décisions sur quelque chose qu'on a construit de ses mains.

Mais c'est exactement là que commence le vrai rôle de CTO.

Pas dans la qualité du code qu'on écrit seul. Dans la capacité à construire une équipe qui écrit du bon code sans vous dans la boucle à chaque pull request.

En 18 ans de CTO hands-on - j'architecture, je code, je structure l'équipe - j'ai appris que la transition de "seul sur la codebase" à "premier recrutement" est le moment où les CTO se révèlent. Certains optimisent pour garder le contrôle total. D'autres optimisent pour construire une équipe capable de les dépasser.

Les seconds construisent de meilleures boîtes.

Le premier recrutement est le premier test de cette capacité. Autant le préparer sérieusement.