L’entretien CTO : ce qu’une heure de conversation révèle

La data room montre des artefacts ; l’entretien CTO montre le jugement. Une heure de conversation bien menée révèle des choses qu’aucun document ne contient : comment cette personne raisonne sous contrainte, ce qu’elle sait de ses propres faiblesses, et si le système qu’elle décrit est celui qui tourne réellement. Dans nos due diligences, c’est souvent l’heure qui pèse le plus dans la conclusion.

Encore faut-il la mener correctement. Un entretien conduit comme un interrogatoire produit des réponses défensives, donc de l’information pauvre. Un entretien conduit comme une conversation entre pairs produit des récits, et les récits ne mentent pas longtemps.

Poser le cadre : une conversation entre ingénieurs

Nous commençons par annoncer la couleur : pas de piège, pas de quiz d’algorithmique, une conversation d’ingénieur à ingénieur sur un système que nous avons déjà étudié. Puis une première demande large : "expliquez-moi l’architecture comme à un senior qui arrive lundi". La qualité de cette explication est déjà un signal. Un CTO qui sait rendre son système simple le comprend en profondeur ; celui qui se réfugie dans le jargon est parfois en train de masquer qu’il ne l’a plus en main.

Le respect n’est pas une politesse, c’est une méthode. Cette personne a construit quelque chose qui fonctionne, avec des moyens contraints et sous pression : partir de là change tout ce qui suit. On teste le système, pas la personne. Et c’est en montrant qu’on a compris la difficulté qu’on obtient les confidences sur les raccourcis.

Les questions qui ouvrent

Quelques questions produisent presque toujours de la matière :

• Racontez-moi la dernière panne sérieuse : ce qui s’est passé, comment vous l’avez trouvée, ce qui a changé depuis.
• De quelle partie de la base de code êtes-vous le moins fier, et pourquoi est-elle encore là ?
• Que réécririez-vous avec six mois devant vous, et pourquoi ne l’avez-vous pas encore fait ?
• Comment une fonctionnalité passe-t-elle de l’idée à la mise en production, sur un exemple récent et réel ?
• Pour un produit IA : comment savez-vous que le système répond bien, et que se passe-t-il quand il se trompe ?
• Qui peut déployer, qui peut déboguer la production à 2 heures du matin, et que se passe-t-il pendant vos vacances ?

Aucune de ces questions n’a de bonne réponse unique. Ce qu’elles testent, c’est la précision, la lucidité et la manière d’en parler.

Ce que les récits de panne révèlent

La question des pannes est la plus riche, au point que nous la posons toujours en premier. Un bon récit de panne est précis (dates, symptômes, chemin de diagnostic), systémique (ce que l’organisation a changé, pas seulement le correctif) et sans coupable désigné. Ce CTO dirige une équipe où les problèmes remontent vite, et c’est exactement ce qu’un investisseur achète.

Les mauvaises réponses ont des formes reconnaissables. "Nous n’avons jamais eu de panne sérieuse" signifie que la mémoire des incidents n’existe pas, ou qu’on ne vous dit pas tout ; les deux inquiètent. Un récit qui s’achève sur la faute d’un ancien développeur décrit une culture où les problèmes se cachent. Un récit vague, "un souci de base de données, réglé depuis", appelle une vérification dans les logs, qui fait partie de ce que la due diligence technique contrôle ensuite.

Les récits disent aussi qui fait quoi. Quand le même prénom apparaît à chaque étape de chaque histoire, l’entretien vient de révéler un risque homme-clé qu’aucun organigramme ne montrait.

Croiser avec le reste de l’audit

L’entretien ne vaut que confronté aux artefacts. Nous le plaçons après la première lecture du code et de la data room, jamais avant : il faut arriver avec des questions précises, nées du dossier. Si le CTO décrit un processus de revue systématique et que l’historique git montre des fusions sans relecture, l’écart est une trouvaille, à classer parmi les signaux d’alerte. S’il décrit honnêtement les mêmes faiblesses que celles que nous avons vues dans le code, c’est l’inverse : la crédibilité de tout le reste de son discours monte.

C’est aussi pour cela qu’une heure suffit souvent. L’entretien n’a pas à couvrir le système entier, seulement à sonder les zones où le dossier laisse des questions ouvertes.

L’entretien CTO est l’une des pièces de notre audit technique, entre la lecture du code et le rapport final. Bien mené, il protège les deux parties : le fonds, qui voit le jugement derrière les artefacts, et le CTO, qui préfère toujours être évalué par des gens qui comprennent ce qu’il a construit.