Face à un candidat CTO, beaucoup de fondateurs non techniques se retrouvent dans une position inconfortable : ils mènent l'entretien le plus important de l'année sur un sujet qu'ils ne maîtrisent pas. Alors ils se rabattent sur ce qu'ils savent juger, le parcours et le feeling, ou ils récitent des questions techniques trouvées en ligne dont ils ne sauront pas évaluer la réponse. Dans les deux cas, l'entretien ne dit presque rien de ce que la personne fera une fois en poste.
En entretien CTO, posez des questions sur des décisions vécues plutôt que sur des technologies : un arbitrage regretté, une équipe montée, un désaccord avec un dirigeant, une dette assumée. Vous n'avez pas besoin de juger la technique. Vous jugez la clarté du raisonnement, la capacité à parler coût et délai, et l'honnêteté sur les échecs.
Cet entretien n'est qu'une étape d'un processus plus large, que je détaille dans comment recruter un CTO, et ce recrutement s'inscrit lui-même dans la construction d'une équipe, le sujet du guide pour construire son équipe tech et produit. Ici, on se concentre sur la conversation elle-même : quoi demander, et comment lire ce qu'on vous répond.
Le principe : faire raconter, puis creuser
Une question d'entretien CTO utile porte sur une situation réelle que le candidat a traversée, jamais sur une connaissance. « Que pensez-vous des microservices ? » produit une réponse de manuel, que n'importe quel profil bien préparé sait réciter. « Racontez-moi la dernière fois que vous avez dû revenir sur un choix d'architecture » produit une histoire, avec un contexte, des contraintes, des gens et un résultat. Et une histoire se juge sans savoir coder : elle est cohérente ou elle ne l'est pas, elle parle de conséquences ou elle reste dans l'abstrait.
La vraie matière arrive ensuite, dans les relances. Trois suffisent pour presque toutes les questions ci-dessous : « Combien ça a coûté, en temps ou en argent ? », « Qui n'était pas d'accord, et comment ça s'est terminé ? », « Que feriez-vous différemment aujourd'hui ? ». Un candidat solide s'y sent à l'aise, parce qu'il a vécu la situation. Un candidat qui a embelli son rôle s'y perd vite, parce qu'il n'a pas les détails.
Vision et business : parler résultats, pas outils
Le premier bloc teste ce qui distingue un CTO d'un très bon développeur : la capacité à relier la technique aux résultats de l'entreprise, ce que je développe dans ce qu'on doit vraiment attendre d'un CTO. C'est aussi le bloc où un fondateur non technique est le plus légitime pour juger, puisqu'il parle son langage.
1. « Quelle décision technique a changé un résultat business ? »
Une bonne réponse cite un effet mesurable : un délai de sortie divisé, un coût d'infrastructure réduit, un client signé grâce à une fonctionnalité. Une réponse qui ne parle que de l'élégance de la solution révèle un profil qui pense code avant de penser entreprise.
2. « Que ne construiriez-vous pas ici la première année ? »
Vous cherchez des renoncements argumentés, liés à votre stade et à vos moyens. Celui qui veut tout reconstruire proprement avant d'avoir compris votre marché vous coûtera cher. Celui qui répond « je dois d'abord comprendre vos clients » a le bon réflexe.
3. « Expliquez-moi un choix technique comme à un investisseur »
Le test de vulgarisation. Si vous ne comprenez pas la réponse, un investisseur ou votre équipe commerciale ne la comprendra pas non plus. Le jargon défensif, qui ferme la discussion au lieu de l'ouvrir, est un signal d'alerte à ce niveau de poste.
Équipe et recrutement : ce qu'il a déjà construit
Un CTO de startup passe une grande partie de ses deux premières années à recruter, à faire grandir des gens et à gérer des départs. C'est sur ce terrain que les parcours se distinguent le plus, et c'est aussi le plus facile à vérifier ensuite auprès des références.
4. « Racontez-moi le meilleur recrutement que vous ayez fait, et le pire. » Le meilleur dit ce qu'il valorise chez les gens. Le pire dit s'il sait reconnaître une erreur et ce qu'il en a tiré. Un candidat qui n'a « jamais vraiment raté de recrutement » n'en a probablement pas fait beaucoup, ou n'a pas regardé de près ce que devenaient ses recrues.
5. « Comment avez-vous géré un développeur qui ne suivait plus ? » Écoutez la chronologie : quand il s'en est aperçu, ce qu'il a tenté, combien de temps il a laissé passer, comment ça s'est terminé. Trop brutal ou trop patient, les deux se paient dans l'équipe, et la réponse vous dit de quel côté il penche.
6. « Quelle équipe aviez-vous à l'arrivée, et laquelle au départ ? » Une question simple qui révèle l'échelle réelle du poste. Beaucoup de titres de CTO recouvrent en fait un rôle de premier développeur, parfaitement respectable mais différent. Je décris ces profils dans les quatre types de CTO, et le bon dépend de votre stade.
Décisions techniques, jugées sans lire le code
Vous ne pouvez pas évaluer la pertinence d'un choix de base de données. Vous pouvez en revanche évaluer la façon dont quelqu'un prend ce genre de décision, et c'est ce qui comptera quand il en prendra cinquante par mois à votre place.
7. « Parlez-moi d'une dette technique que vous avez choisi de prendre. » Le mot important est « choisi ». Un bon CTO assume d'aller vite à certains endroits et sait dire pourquoi, jusqu'à quand, et à quel prix il faudra rembourser. Celui qui présente toute dette comme une faute de ses prédécesseurs n'a jamais eu à arbitrer lui-même.
8. « Racontez un incident de production grave, et ce qui a changé après. » N'écoutez pas la panne, écoutez l'après : ce qui a été mis en place pour que ça ne recommence pas, et la façon dont l'équipe a été traitée. La recherche d'un coupable est un mauvais signe pour la culture qu'il installera chez vous.
9. « Comment choisissez-vous entre construire un outil et l'acheter ? » Une bonne réponse commence par des questions sur votre cœur de métier, pas par une préférence. Un réflexe systématique dans un sens ou dans l'autre annonce des factures évitables.
Je n'ai rien compris à la moitié de ses projets passés. Mais chaque fois que je demandais ce que ça avait coûté, il avait un chiffre, et il me disait ce qu'il referait autrement.
La relation avec vous : le bloc qu'on oublie
Les échecs de CTO que j'ai vus de près tenaient rarement à la technique. Ils tenaient à la relation avec le fondateur : des attentes jamais dites, des désaccords qui pourrissent, un rythme de décision incompatible. Les trois dernières questions servent à le voir avant de signer, pas six mois après.
| Question | Ce qu'une bonne réponse contient | Ce qu'une mauvaise réponse révèle |
|---|---|---|
| 10. « Racontez un désaccord avec un CEO. » | Le fond du désaccord, comment il a été tranché, ce qu'il a concédé | Un CEO « qui ne comprenait rien » : il dira la même chose de vous |
| 11. « De quoi auriez-vous besoin de moi au début ? » | Des demandes précises : accès, arbitrages, créneaux dans votre agenda | Rien ou tout : un profil qui travaillera seul, ou attendra |
| 12. « Qu'est-ce qui vous ferait partir au bout d'un an ? » | Une réponse franche sur ses conditions de réussite | Une formule de politesse, qui cache les vraies attentes |
Ce que l'entretien ne remplace pas
Même bien mené, un entretien reste une conversation, et certains candidats excellent à l'exercice. Deux compléments sont indispensables avant de décider. D'abord un regard de pair : un CTO de votre réseau, un investisseur au profil technique ou un CTO fractionnel qui assiste à l'un des entretiens et juge ce que vous ne pouvez pas juger. Ensuite une mise en situation sur un vrai problème de votre entreprise, que je détaille dans évaluer un candidat CTO par la mise en situation. C'est la logique décrite pour les développeurs dans les tests techniques en recrutement, transposée à des décisions plutôt qu'à du code.
Un dernier conseil, qui paraît anodin et change beaucoup : notez les réponses à chaud, question par question, et comparez les candidats sur la même grille. Sans cela, c'est le dernier entretien, ou le plus charismatique, qui l'emporte presque toujours.
J'interviens comme CTO fractionnel pour construire la grille d'entretien, assister aux rencontres et évaluer ce qui ne se juge pas sans expérience technique. 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.
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.
Je dois recruter mes premiers profils techniques
Le premier recrutement conditionne tous les suivants.
ou appelez-moi au 06 20 52 03 69