Évaluer un candidat CTO : la mise en situation qui tranche

Vous avez trois finalistes pour votre poste de CTO. Tous ont un beau parcours, tous ont été convaincants en entretien, et vous devez choisir. Le réflexe classique consiste à leur faire passer un test technique que vous ne saurez pas corriger, ou à trancher au feeling. Dans les deux cas, vous décidez à l'aveugle sur le recrutement le plus structurant de votre jeune entreprise.

Pour évaluer un candidat CTO sans être technique, remplacez le test de code par une mise en situation sur un vrai problème de votre entreprise, comme une décision en suspens. Vous ne jugez pas la solution, mais la façon dont il la construit : ses questions, ses priorités, sa clarté, et ce qu'il admet ne pas savoir.

Ce recrutement s'inscrit dans une démarche plus large, que je détaille dans le guide pour construire son équipe tech et produit. Et si vous cherchez le processus complet, de la décision de recruter jusqu'à la signature, il est posé dans comment recruter un CTO. Ici, on se concentre sur l'étape qui fait basculer la décision finale.

Pourquoi le test technique ne marche pas pour un CTO

Pour un développeur, un test technique bien conçu reste un excellent outil, à condition qu'il soit court, réaliste et suivi d'une restitution avec l'équipe (je le détaille dans les tests techniques en recrutement). Pour un CTO, en revanche, il échoue sur trois plans à la fois.

D'abord, vous ne pouvez pas juger le rendu. Un code élégant et un code bricolé se ressemblent beaucoup quand on ne sait pas le lire, et vous finirez par noter ce que vous comprenez : la présentation, l'aplomb, la longueur du document. Ensuite, il mesure la mauvaise compétence. Un CTO en early stage code encore, mais son vrai métier est ailleurs : arbitrer, prioriser, recruter, dire non, expliquer la technique au CODIR et aux investisseurs. C'est tout l'écart entre ce qu'on doit attendre d'un CTO et ce qu'on attend d'un développeur senior. Enfin, les meilleurs candidats sont en poste, et beaucoup refusent poliment un exercice de plusieurs heures à rendre le week-end.

Il avait rendu le meilleur code des trois. J'ai mis six mois à comprendre qu'il était incapable de me dire non sur la roadmap.

un fondateur, un an après avoir recruté sur la seule base d'un exercice de code

Le principe : un vrai problème de votre boîte, pas un exercice

La mise en situation part d'une décision que vous avez réellement devant vous. Pas d'une énigme inventée pour l'occasion, ni d'une étude de cas générique trouvée sur Internet. Plus le cas est proche de votre quotidien, plus ce que vous observez ressemblera à ce que vous vivrez ensemble.

Les bons sujets ont trois caractéristiques : ils sont ouverts (plusieurs réponses défendables), ils mêlent technique et business, et ils vous tiennent vraiment à cœur. Par exemple : « l'agence est la seule à connaître le code, comment reprendre la main sans arrêter le produit ? », « on lève dans huit mois et la roadmap ne tient pas, que coupez-vous ? », ou « la plateforme tombe une fois par mois, par où commencez-vous ? ».

Deux garde-fous. Le candidat signe un accord de confidentialité simple avant de recevoir le dossier. Et vous ne lui demandez pas de livrer la solution, seulement son approche : sinon vous faites faire du conseil gratuit, et les bons profils le sentent immédiatement.

Construire la mise en situation en quatre étapes

Choisir le cas : une décision réelle et ouverte

Prenez une décision que vous n'avez pas encore tranchée, ou que vous avez tranchée récemment avec difficulté. Évitez les sujets purement techniques (le choix d'un framework) : vous ne pourriez pas en suivre la discussion. Visez un problème où la technique rencontre vos contraintes de temps, d'argent et d'équipe.

Préparer un dossier court, volontairement incomplet

Deux pages au maximum : le contexte, la taille de l'équipe, le budget, l'échéance, ce qui a déjà été tenté. Laissez des trous exprès. Un bon candidat les repérera et posera des questions avant de proposer quoi que ce soit. Envoyez le dossier quelques jours avant, en précisant que deux heures de préparation suffisent largement.

Faire vivre la restitution comme une vraie réunion

Comptez 90 minutes. Pas une présentation déroulée : une conversation. Au milieu, changez une contrainte (« l'investisseur veut une démo deux mois plus tôt », « votre développeur principal vient de démissionner »). C'est là que vous voyez comment il réagit quand son plan ne tient plus, ce qui arrivera chaque trimestre une fois en poste.

Débriefer avec un pair technique

Invitez à la restitution quelqu'un qui sait juger le fond : un CTO de votre réseau, un investisseur au passé technique, un CTO fractionnel. Il évalue la solidité technique, vous évaluez la relation, la clarté et l'alignement. Débriefez à chaud, chacun de votre côté d'abord, puis ensemble.

Ce que vous observez, sans savoir coder

Vous n'avez pas besoin de comprendre chaque terme pour lire l'essentiel. Les signaux qui comptent sont presque tous comportementaux, et ils se voient très bien depuis la place du fondateur.

Signal	Candidat solide	Candidat à risque
Avant de proposer	Pose des questions sur le besoin, les clients, le cash	Déroule une solution dès la première minute
Face aux contraintes	Les utilise pour trancher et couper du périmètre	Les conteste ou les ignore
Explication	Vous fait comprendre sans jargon	Se réfugie dans les termes techniques
Quand une contrainte change	Réajuste son plan et dit ce qu'il sacrifie	Défend le plan initial ou repart de zéro
Face à ce qu'il ne sait pas	Le dit, propose comment le vérifier	Improvise une certitude
Place de l'équipe dans la réponse	Parle de qui fait quoi, du recrutement, de l'existant	Ne parle que d'architecture et d'outils

Le piège le plus fréquent est le candidat brillant qui propose d'emblée la refonte complète : nouvelle architecture, nouvelle stack, tout reprendre proprement. C'est parfois la bonne réponse, mais presque jamais sans avoir d'abord questionné ce qui existe, ce que ça coûte et ce que ça bloque pendant six mois. Pour compléter cette lecture pendant les entretiens eux-mêmes, je propose une série de questions lisibles sans être technique dans les questions à poser en entretien CTO.

Les limites de l'exercice

La mise en situation tranche souvent, mais elle ne suffit pas seule. Un candidat peut être excellent dans la vraie vie et perdre ses moyens dans une restitution sous le regard de quelqu'un qu'il ne connaît pas. Si vous sentez que c'est le cas, proposez un second échange plus informel, ou laissez-le vous envoyer une note écrite après coup : certaines personnes réfléchissent mieux à froid, et ce n'est pas un défaut chez un CTO.

L'exercice ne remplace pas non plus les prises de références. Appelez deux ou trois personnes qui ont travaillé avec lui, idéalement quelqu'un qu'il a managé et un dirigeant avec qui il a dû arbitrer. Demandez-leur une situation précise où il a dû dire non, et comment ça s'est passé. C'est la pièce qui complète le mieux ce que vous avez observé en restitution.

Enfin, gardez l'étape à sa place dans le parcours : elle vient en fin de processus, pour deux ou trois finalistes, jamais comme premier filtre. Pour la trame complète d'un recrutement tech, étape par étape, reportez-vous à structurer son process de recrutement.

On prépare votre mise en situation ensemble ?

En création d'équipe tech et produit, je construis avec vous le cas à partir de votre contexte réel et je tiens le rôle du pair technique lors des restitutions. Ou réservons 30 minutes pour en parler.