Évaluer un CTO quand on n'est pas technique : ce qu'un CTO regarde

Un fondateur non technique qui doit recruter un CTO croit qu'il lui manque des connaissances. En réalité il lui manque une grille, et l'essentiel de ce qu'il faut observer se voit sans écrire une ligne de code.

Je le sais parce que je suis de l'autre côté de cette table. Je suis directeur technique, j'ai passé ces entretiens et j'en ai fait passer. Le constat est toujours le même : les fondateurs posent des questions sur la stack, où ils n'ont aucun moyen de juger la réponse, et laissent de côté les questions sur la décision, où leur jugement vaut celui d'un ingénieur.

Les grandes lignes :

• Le CV et le GitHub d'un profil senior ne t'apprendront presque rien
• Un bon CTO se distingue d'un bon développeur par sa façon d'arbitrer, pas par ce qu'il sait
• Le signal le plus fiable est la manière dont il raconte un projet qui a raté
• Fais toujours valider la technique par un pair extérieur, rémunéré, et choisis-le toi

Il te manque surtout quelqu'un pour valider le niveau ?

La méthode qui suit fonctionne, à une condition : avoir un développeur senior extérieur à qui confier l'évaluation. C'est la pièce que la plupart des fondateurs non-tech n'ont pas, et elle ne se trouve pas sur un site.

Trouver le pair qui fera l'évaluation →

Pourquoi le CV et le GitHub ne te diront rien

Le CV d'un profil technique senior contient une liste de technologies et une liste d'entreprises. Aucune des deux n'est un signal.

Les technologies ne disent rien du niveau : maîtriser un langage à fond et l'avoir croisé sur un projet s'écrivent de la même façon. Et les technologies changent tous les quatre ou cinq ans, donc ce que la personne connaît aujourd'hui vaut moins que sa capacité à apprendre la suivante.

Les entreprises ne disent rien non plus. Cinq ans dans une entreprise connue peuvent recouvrir un rôle central ou une position de figuration dans une équipe de soixante personnes.

Quant au GitHub public, il est vide chez la majorité des très bons profils seniors, pour une raison banale : ils écrivent du code propriétaire depuis quinze ans, dans des entreprises qui ne publient pas. Un GitHub bien fourni est un signal chez un junior. Chez un candidat CTO, son absence n'est pas un signal négatif.

Ce qui reste lisible : le nombre de contextes différents traversés, la présence de responsabilités qui ne sont pas techniques, et la durée. Quelqu'un qui a fait trois ans, puis deux, puis quatre, dans des tailles d'entreprise différentes, a vu plus de choses que quelqu'un qui a fait douze ans au même endroit.

Les six questions qui séparent un bon CTO d'un bon développeur

Ces six questions se jugent sans compétence technique. Ce que tu écoutes, c'est la structure du raisonnement, pas le vocabulaire.

« Raconte-moi une décision technique que tu as prise et qui s'est révélée mauvaise. »

Un bon candidat en a plusieurs et les raconte avec le contexte : ce qu'il savait au moment de décider, ce qu'il a découvert après, ce qu'il ferait différemment. Un candidat qui n'en a aucune n'a jamais décidé seul, ou ne se relit pas.

« Sur quoi as-tu accepté de faire de la dette technique volontairement ? »

La bonne réponse existe et elle est banale : on sacrifie la propreté pour sortir à temps, en sachant ce qu'on sacrifie et pour combien de temps. Un candidat qui répond qu'il ne fait jamais de compromis sur la qualité est soit inexpérimenté, soit dangereux pour une entreprise à ton stade.

« Comment tu m'expliquerais ce qu'est une base de données, à moi ? »

Le test de vulgarisation. Un CTO passe la moitié de son temps à traduire de la technique pour des gens qui n'en font pas : toi, les commerciaux, les investisseurs, les clients. Celui qui ne sait pas simplifier va créer un mur dans ton entreprise.

« Qu'est-ce que tu ferais pendant tes trente premiers jours ici ? »

Écoute s'il commence par regarder ou par refaire. Un candidat qui annonce une refonte complète avant d'avoir lu le code te dit qu'il aime construire du neuf, pas qu'il a compris ton problème.

« Combien coûte notre infrastructure aujourd'hui, à ton avis, et pourquoi ? »

Question de cadrage économique. Un bon CTO relie systématiquement une décision technique à une facture. Celui qui n'a jamais regardé un budget serveur dirigera bien une équipe et te ruinera à l'échelle.

« Qu'est-ce que tu refuserais de faire, même si je te le demandais ? »

Le seul moyen de savoir si la personne sait dire non. Un directeur technique qui accepte tout ne protège rien : ni la sécurité, ni les données, ni son équipe.

Le signal le plus fiable : comment il parle de ce qui a raté

Si tu ne dois retenir qu'un critère, prends celui là.

Demande à la personne de raconter un projet qui s'est mal passé. Trois profils de réponse apparaissent.

Le premier attribue l'échec à l'extérieur : le management ne comprenait rien, les délais étaient intenables, les commerciaux vendaient n'importe quoi. Ce récit peut être vrai et il ne t'apprend rien, sauf que la personne ne se met pas dans l'équation.

Le deuxième s'accuse globalement, sans détail. C'est de la modestie de façade, souvent apprise en préparation d'entretien.

Le troisième décrit une chaîne : voilà ce qu'on a décidé, voilà pourquoi ça semblait juste, voilà le signal qu'on a raté, voilà quand on aurait dû changer d'avis. C'est le seul des trois qui prouve une capacité d'analyse, et c'est celui qui prédit le mieux le comportement quand ça dérapera chez toi. Parce que ça dérapera.

Les red flags que je repère en vingt minutes

Il ne pose aucune question sur les clients ou le chiffre d'affaires. Un CTO qui ne s'intéresse qu'à la technique est un très bon lead développeur. Ce n'est pas un membre de direction.

Il critique tout de suite l'existant sans l'avoir vu. Le réflexe « tout ce qui a été fait avant moi est mauvais » se retournera contre toi dans dix-huit mois, quand un autre le dira de son travail à lui.

Il ne sait pas dire combien coûterait ce que tu demandes. Même une fourchette large, même assortie de conditions. Un candidat incapable de dire si c'est deux semaines ou six mois n'a pas l'habitude d'engager sa parole.

Il utilise du vocabulaire technique là où il pourrait faire simple. Souvent involontaire, parfois défensif. Dans les deux cas, ça complique tout ce qui suivra.

Il veut un titre plutôt qu'un périmètre. La discussion sur le nom du poste arrive avant celle sur ce qu'il y a à faire.

Il accepte ton offre trop vite. Un profil senior en poste calcule, en parle chez lui, revient avec des questions. L'enthousiasme immédiat est rarement un bon signe.

Faire évaluer par un pair : le mode d'emploi

L'évaluation technique par un tiers est l'étape à ne pas sauter, et elle a ses propres pièges.

Choisis le pair toi même. Pas quelqu'un que le candidat suggère. Pas quelqu'un qui a un intérêt à ce que le recrutement échoue non plus, ce qui écarte le prestataire qui travaille actuellement sur ton produit.

Paie-le. Deux à quatre heures au tarif journalier habituel, entre 200 et 500 euros. Un service rendu gratuitement est un service bâclé, et tu ne pourras rien exiger du rendu.

Donne-lui un cadre écrit. Trois questions auxquelles tu veux une réponse : la personne est elle capable de tenir la technique à notre stade, quelles sont ses deux plus grandes faiblesses, et sur quoi faudra-t-il l'accompagner. Sans ce cadre, tu recevras une appréciation générale inutilisable.

Demande un avis écrit et une note. L'oral produit de la politesse. L'écrit force l'engagement.

Croise avec deux pairs si le poste est central. Deux avis divergents sont plus informatifs qu'un seul avis positif.

Où trouver ce pair quand on n'a pas de réseau technique : un CTO d'une entreprise non concurrente rencontré dans un cadre professionnel, un ancien collègue devenu développeur, ou un dirigeant du même écosystème. C'est l'un des usages les plus concrets d'un réseau de pairs, détaillé dans notre article sur les groupes de pairs entre dirigeants.

L'exercice à faire faire, et celui à ne surtout pas demander

À faire. Une mise en situation de deux heures, payée, sur une décision réelle que tu dois prendre. Reprendre ou refaire la base existante. Internaliser ou continuer avec l'agence. Tenir la charge d'un pic saisonnier. Tu n'achètes pas la conclusion, tu observes le chemin : les questions posées avant de trancher, les hypothèses formulées, et la capacité à dire qu'il manque des éléments plutôt qu'à improviser une réponse.

À ne pas demander. Un exercice d'algorithmique chronométré, un test de code standardisé, ou un prototype gratuit. Les deux premiers évaluent un développeur junior et font partir les candidats seniors, qui y lisent un signal sur ta compréhension du poste. Le troisième est simplement du travail non payé, et les meilleurs profils refusent.

Entre les deux, une zone grise : la revue de code. Demander à un candidat de commenter un morceau de ton code existant fonctionne bien, à condition que ce soit court et que tu aies fait relire la même chose par ton pair évaluateur pour comparer.

Le reste du processus, du sourcing à l'offre, est décrit dans notre guide comment recruter un CTO. Et si l'arbitrage entre recrutement et association n'est pas encore tranché, associé, salarié ou prestataire donne la grille.

FAQ

Comment savoir si un développeur est bon quand on n'est pas technique ?

Observe trois choses accessibles sans compétence technique : sa capacité à expliquer simplement, sa façon de raconter un projet raté, et sa capacité à relier une décision technique à un coût. Pour le niveau technique proprement dit, fais évaluer par un développeur senior extérieur que tu choisis et que tu rémunères. Ton intuition d'entretien mesure la sympathie, pas la compétence.

Quelles questions poser à un candidat CTO ?

Les plus utiles portent sur l'arbitrage, pas sur le savoir : une décision technique qu'il a regrettée, une dette technique acceptée volontairement, ce qu'il ferait pendant ses trente premiers jours, ce qu'il refuserait de faire. Ajoute une demande d'explication vulgarisée d'un concept technique, qui teste la compétence la plus utile au quotidien dans un comité de direction.

Faut-il faire passer un test technique à un CTO ?

Pas un test de code standardisé, qui évalue un profil junior et fait fuir les candidats seniors. Une mise en situation payée de deux heures sur une décision réelle de ton entreprise donne beaucoup plus d'information, et respecte le temps du candidat.

Combien coûte une évaluation technique par un tiers ?

Entre 200 et 500 euros pour deux à quatre heures d'un développeur senior indépendant, incluant l'entretien et un avis écrit. Rapporté au coût d'un mauvais recrutement de direction technique, qui se chiffre en dizaines de milliers d'euros et en mois perdus, c'est la dépense la plus rentable du processus.

Un CTO doit-il encore savoir coder ?

Cela dépend du stade. Avant la série A, oui, et il doit même coder une partie du temps. Au delà, la compétence utile devient l'arbitrage, le recrutement et la relation avec le reste de la direction. Un CTO de scale-up qui code encore tous les jours est souvent le signe qu'il n'a pas délégué ce qu'il aurait dû.

Conclusion

Tu n'as pas besoin d'apprendre à coder pour recruter un CTO. Tu as besoin de poser des questions sur la décision plutôt que sur la technologie, d'écouter comment la personne raconte ses échecs, et de confier la vérification technique à quelqu'un dont c'est le métier.

Le reste, l'intuition et le courant qui passe, se trompe une fois sur deux.

Le pair qui fera cette évaluation, tu ne le trouveras pas sur un site. Tu le rencontreras. Les dîners Linkeat réunissent huit entrepreneurs parisiens sélectionnés pour être complémentaires, profils techniques compris.