Recruter un CTO sans perdre six mois : la méthode complète

Quand un CTO s’en va, ou quand une entreprise réalise qu’elle en a besoin, le réflexe est de publier une offre et d’attendre. Plusieurs mois plus tard, le poste est souvent toujours vide, les prestataires ont pris la main et la feuille de route a dérivé. Je ne donnerai pas de durée moyenne : elle dépend trop du marché, du salaire et du profil. Mais dans les recrutements de développeurs, de tech leads et de responsables techniques que j’ai menés depuis 2013, pour des équipes en France puis dans des centres à Madagascar, au Vietnam et à Maurice, ce qui allonge un recrutement est presque toujours la même chose : on ne sait pas précisément qui on cherche, et on ne sait pas comment le vérifier.

Voici la méthode que j’applique, de la fiche de poste à la passation. Les exemples sont volontairement génériques : ils sont à adapter à votre produit, votre équipe et votre stade.

1. Écrire la fiche de poste à partir des décisions des six premiers mois

Une fiche de poste de CTO classique liste des technologies et des qualités : « leadership », « vision », « maîtrise du cloud ». Elle ne dit rien de ce que la personne devra trancher. Je pars donc de l’inverse : la liste des décisions concrètes qui tomberont sur le bureau du CTO dans ses six premiers mois. Chaque décision implique une compétence, et chaque compétence devient un critère d’évaluation.

Exemple pour une entreprise générique avec un produit SaaS en production, une petite équipe interne et un prestataire externe :

Ce tableau a deux effets. Il oblige la direction à dire ce qu’elle attend réellement, ce qui fait souvent apparaître des désaccords internes à régler avant de recruter. Et il donne au candidat une image honnête du poste : un bon CTO lit ce tableau et sait tout de suite s’il a envie de prendre ces décisions-là.

2. Distinguer les trois profils de CTO

Derrière le titre, on trouve au moins trois métiers. Une même personne peut évoluer de l’un à l’autre au fil de sa carrière, mais à un instant donné, elle excelle rarement dans les trois. Le tableau des décisions dit lequel vous cherchez.

Si le tableau de la section 1 contient surtout des décisions d’architecture et de code, c’est un bâtisseur. S’il contient surtout des contrats, des recrutements et des arbitrages de priorité, c’est un manager. S’il contient surtout des échanges avec le board, des budgets pluriannuels et des choix de structure, c’est un stratège. Chercher les trois en même temps, c’est s’assurer de ne trouver personne, ou de trouver quelqu’un qui en survend deux.

3. La grille d’évaluation technique

Un dirigeant sait juger la posture, la communication, l’alignement sur les valeurs. Il ne peut pas juger seul une architecture ou la qualité d’un code. Le risque classique est de recruter le meilleur orateur. Je fais donc passer au moins un entretien par quelqu’un qui a déjà tenu le poste, avec une grille écrite partagée avant l’entretien et un avis écrit après.

La grille n’est pas un barème à additionner. Elle sert à rendre les avis comparables entre candidats et entre évaluateurs, et à obliger chacun à justifier son avis par ce qui a été dit, pas par une impression.

4. Un exercice d’architecture tiré d’un vrai problème de l’entreprise

Les exercices génériques (« concevez un clone de Twitter ») mesurent surtout la préparation aux entretiens. Je préfère donner au candidat un problème réel de l’entreprise, anonymisé si nécessaire, et observer comment il raisonne. Quatre formats fonctionnent bien, à choisir selon le profil recherché :

• Relire une pull request réelle. Une PR de taille moyenne, déjà mergée, avec ses défauts. On regarde ce que le candidat voit en premier : la logique métier, les tests, la sécurité, le nommage, ou le découpage du changement. Un bâtisseur doit y être très à l’aise.
• Critiquer un schéma d’architecture. Le schéma actuel, tel quel. Où sont les points uniques de défaillance, quel composant poserait problème si le trafic doublait, qu’est-ce qui manque pour l’observabilité.
• Estimer une évolution. Une fonctionnalité réellement prévue sur la feuille de route. On ne juge pas le chiffre, on juge la méthode : découpage, hypothèses explicites, risques, ce qu’il faudrait vérifier avant de s’engager.
• Lire un tableau de dette. Une liste de dettes connues avec une estimation grossière. Le candidat doit proposer un ordre de traitement et le défendre. C’est l’exercice le plus révélateur pour un manager ou un stratège.

Format pratique : le matériel est envoyé quelques jours avant, le candidat prépare une restitution courte, puis on en discute une heure. Je limite volontairement la préparation à quelques heures et je le dis explicitement, pour ne pas demander un travail gratuit déguisé. Si l’exercice touche du code ou des données sensibles, un accord de confidentialité est signé avant l’envoi.

La restitution elle-même est évaluée deux fois : par le pair technique sur le fond, et par la direction sur la clarté. C’est souvent là que la différence entre profils apparaît le plus nettement.

5. La revue de code du dépôt existant par le candidat

Pour le ou les finalistes, je vais plus loin : un accès en lecture seule au dépôt principal, pendant une durée limitée, avec une question simple : « Qu’est-ce qui vous inquiète, et par quoi commenceriez-vous ? »

Ce que j’attends d’une bonne revue :

1. une lecture de la structure avant le détail : organisation des modules, dépendances, configuration, tests ;
2. des constats hiérarchisés par risque, pas une liste de remarques de style ;
3. des questions plutôt que des verdicts quand le contexte manque (« pourquoi cette table est‑elle dupliquée ? ») ;
4. une proposition de premières actions réalistes, compatibles avec la livraison continue du produit.

Les signaux d’alerte sont symétriques : une condamnation globale du code sans l’avoir compris, la tentation de tout réécrire, ou au contraire une revue complaisante pour plaire. Côté entreprise, la règle est l’honnêteté : si le code est fragile, le candidat le verra, et il vaut mieux qu’il le voie avant de signer que trois semaines après. Un candidat qui décline après avoir vu le dépôt vous a épargné un départ dans l’année.

Précautions : accès nominatif, en lecture seule, sans secrets dans le dépôt (s’il y en a, c’est le premier constat à corriger, avant même d’ouvrir l’accès), révoqué à une date fixée à l’avance.

6. Les questions de référence

Les références sont souvent traitées comme une formalité. Je les utilise pour vérifier précisément les points de la grille qui sont restés incertains. Je demande au candidat deux types de contacts : quelqu’un à qui il a rendu des comptes, et quelqu’un qui a travaillé sous sa responsabilité.

Questions que je pose, toujours ancrées dans des faits :

• Quelle décision technique importante a-t‑il prise pendant que vous travailliez avec lui, et comment a-t‑elle vieilli ?
• Comment a-t‑il réagi au dernier incident de production grave ?
• Lui avez-vous déjà vu changer d’avis sur un sujet technique ? Qu’est-ce qui l’a convaincu ?
• Comment se passait un désaccord entre lui et la direction ?
• Qui a-t‑il recruté, et ces personnes sont‑elles restées ?
• Si vous deviez retravailler avec lui, sur quel type de poste le placeriez-vous ?

La dernière question est la plus utile : elle dit souvent, sans le formuler, si la personne est un bâtisseur, un manager ou un stratège.

7. La data room technique remise au candidat

Survendre le poste, c’est s’assurer d’un départ rapide. Les bons candidats posent les bonnes questions dès le deuxième entretien, et il vaut mieux avoir préparé les réponses. Je constitue donc une data room technique, remise au finaliste sous accord de confidentialité. Son contenu minimal :

Préparer cette data room a un effet secondaire précieux : elle révèle à l’entreprise elle-même ce qu’elle ne sait pas sur sa propre tech. Les trous dans le tableau sont les premières tâches du futur CTO, et il vaut mieux les lui présenter comme telles.

8. La passation écrite

Le nouveau CTO arrive, et personne ne lui explique l’historique : pourquoi tel choix, quels contrats, quels risques. Il passe alors ses premiers mois à reconstituer ce que quelqu’un aurait pu lui transmettre en quelques jours. La passation doit donc être écrite, et préparée pendant la recherche, pas le jour de l’arrivée.

Le cœur de cette passation, ce sont les décisions d’architecture. Je les consigne sous forme d’ADR (Architecture Decision Record) : un document court par décision, versionné avec le code. Le modèle que j’utilise :

# ADR-007 : Stockage des fichiers clients sur un stockage objet

Date : 2026-03-14
Statut : acceptée (remplace ADR-002)

## Contexte
Les fichiers étaient stockés sur le disque du serveur applicatif.
Impossible de passer à plusieurs instances sans partage de fichiers.

## Décision
Stockage objet compatible S3, accès via URL signées à durée limitée.

## Alternatives écartées
- Volume partagé NFS : point unique de défaillance, coût d'exploitation.
- Base de données : volumétrie incompatible.

## Conséquences
- Migration des fichiers existants à planifier (script idempotent).
- Dépendance à un fournisseur : réversibilité vérifiée (API standard).
- Coût mensuel supplémentaire, à suivre dans le budget hébergement.

Si aucun ADR n’existe, je ne cherche pas l’exhaustivité : je rédige rétroactivement les cinq à dix décisions qui structurent le système et dont la raison n’est pas évidente à la lecture du code. Le reste de la passation tient dans une liste vérifiable :

• Accès : inventaire de tous les comptes (hébergement, registrar, DNS, dépôts, CI, outils SaaS, magasins d’applications), avec le propriétaire actuel et le plan de transfert. Les comptes détenus personnellement par un ancien salarié ou un prestataire sont à traiter en priorité.
• Contrats : prestataires, licences, hébergement, avec échéances, préavis et clauses de réversibilité.
• Risques : registre des risques connus (sécurité, dépendances non maintenues, personnes clés, dettes bloquantes), chacun avec un niveau et une action envisagée.
• Exploitation : procédures de déploiement, de restauration de sauvegarde (testée, pas seulement configurée), d’astreinte et de gestion d’incident.
• Engagements en cours : ce qui a été promis à des clients, au board ou à l’équipe, avec les dates.

9. Tenir la tech pendant la recherche

C’est le point le plus coûteux quand il est négligé. Pendant la recherche, personne n’arbitre : les prestataires décident seuls, les estimations gonflent, la dette s’accumule. Le futur CTO arrive ensuite sur un terrain qu’il devra d’abord déminer.

Le coût d’un recrutement de CTO, ce n’est pas le cabinet. Ce sont les mois sans pilote.

Tenir la tech pendant l’intérim ne demande pas un temps plein. Il faut quelqu’un qui assure un nombre limité de fonctions, de façon régulière :

1. Arbitrer : valider ou refuser les choix structurants, et refuser par défaut tout ce qui engage durablement (changement de stack, réécriture, nouveau prestataire) sauf urgence.
2. Contrôler : revue des livrables et des estimations des prestataires, suivi des incidents.
3. Sécuriser : reprendre la propriété des accès et des comptes, vérifier les sauvegardes.
4. Préparer : construire la data room, rédiger les ADR, mettre à jour le tableau de dette.
5. Recruter : rédiger la fiche à partir des décisions, mener l’entretien technique, construire l’exercice d’architecture.

Bien fait, cet intérim transforme la recherche : le poste est mieux défini, l’évaluation est plus fiable, et le CTO recruté commence par décider plutôt que par reconstituer.

Votre recrutement traîne ? Je tiens la tech pendant la recherche, prépare l’évaluation et la passation, puis je passe la main à votre CTO. Voir l’offre de CTO à temps partagé.