Des mois de recherche, des entretiens, une négociation serrée, et enfin la signature. Votre premier CTO arrive lundi. C'est souvent là que les fondateurs relâchent l'attention, alors que les trois mois qui viennent décident si ce recrutement tiendra. J'ai vu des CTO solides partir avant la fin de leur première année, non pas faute de compétence, mais faute d'une intégration pensée.
Réussir l'onboarding d'un CTO, c'est organiser un transfert progressif sur 100 jours. Les 30 premiers pour comprendre, avec tous les accès mais aucune décision structurante. Jusqu'au 60e, l'équipe et les premiers arbitrages. Au 100e, le budget, la roadmap technique et la parole face aux investisseurs. Et le fondateur lâche au même rythme.
L'intégration d'un CTO suit les principes de tout onboarding, avec une difficulté en plus : vous ne l'accueillez pas dans une équipe, vous lui confiez un pouvoir que vous exerciez jusque-là. C'est l'un des moments charnières quand on veut construire son équipe tech et produit dans la durée. Cet article est le pendant exact de ce qu'il faut faire quand votre CTO vient de partir : l'arrivée se prépare avec la même rigueur que le départ.
Avant le premier jour : ce qui doit être prêt
Un CTO qui passe sa première semaine à réclamer des accès comprend tout de suite quelle place on lui fait. Préparez donc l'essentiel avant son arrivée : les droits d'administration sur l'hébergeur, le dépôt de code, le nom de domaine, les comptes des outils et, s'il y en a, les contrats des prestataires techniques. Rien ne doit rester dans la seule tête ou la seule boîte mail d'un freelance.
Préparez aussi deux documents simples. Le premier liste les engagements déjà pris : une date promise à un client, une fonctionnalité annoncée à un investisseur, un chantier lancé avec une agence. Votre CTO doit les découvrir de votre bouche, pas au détour d'une réunion. Le second écrit son mandat : ce qu'il décide seul, ce qu'il décide avec vous, ce qui reste chez vous. Une page suffit, et elle évite l'essentiel des malentendus des premiers mois.
Les trois jalons des 100 jours
Le principe est le même à chaque étape : on donne une responsabilité réelle, on retire au CTO une charge qui l'empêcherait de l'exercer, et le fondateur recule d'un pas.
Comprendre sans rien casser
Ce qu'on lui donne : un accès complet, du temps avec chaque développeur, chaque prestataire et quelques clients, et la liberté de tout questionner. Ce qu'on lui retire : l'obligation de livrer vite pour prouver sa valeur, et la tentation de faire de lui le développeur de secours qui éteint les incendies. Ce qu'on attend au 30e jour : un diagnostic écrit et partagé de l'état de la technique, des risques et de l'équipe. Pas de refonte, pas de changement de stack, pas de départ décidé à ce stade.
Prendre l'équipe et les premiers arbitrages
Ce qu'on lui donne : le management direct des développeurs, la relation avec les prestataires, la main sur les recrutements techniques et les premières décisions tirées de son diagnostic. Ce qu'on retire au fondateur : les demandes envoyées directement aux développeurs. À partir de là, tout passe par le CTO, y compris vos urgences. C'est le jalon le plus difficile, parce que c'est le premier où vous renoncez à quelque chose.
Porter la technique au comité de direction
Ce qu'on lui donne : le budget technique, la roadmap qui en découle, sa place au comité de direction et la parole face aux investisseurs sur les sujets techniques. Ce qu'on retire au fondateur : l'arbitrage final des choix d'architecture. Ce qu'on attend au 100e jour : des métriques d'équipe suivies, un plan à six mois et une équipe qui sait vers qui se tourner sans hésiter.
Ces jalons ne sont pas des dates couperets. Dans une équipe de trois développeurs, le deuxième peut arriver au bout de trois semaines ; avec une agence à reprendre en main, il peut glisser. Ce qui compte, c'est l'ordre : comprendre, puis décider, puis représenter. Un CTO qui décide avant d'avoir compris détruit la confiance de l'équipe ; un CTO qui comprend sans jamais décider finit par partir. Le périmètre visé au bout du chemin est celui que je décris dans ce qu'on doit attendre d'un CTO.
Ce que le fondateur doit lâcher, et quand
La difficulté d'un onboarding de CTO se situe rarement du côté du CTO. Elle se situe du côté du fondateur, qui a porté la technique seul, parfois en codant lui-même, et qui doit maintenant rendre la main à quelqu'un qu'il connaît depuis quelques semaines.
Mon titre disait CTO. Mais chaque soir, le fondateur validait les tickets de l'équipe sur Slack, et tout le monde avait compris qui décidait vraiment.
Le court-circuit est le premier motif d'échec que je rencontre. Il n'est presque jamais volontaire : c'est un réflexe, une urgence client transmise directement à un développeur « pour aller plus vite », un avis donné sur une pull request par habitude. Chacun de ces gestes, isolé, paraît anodin. Répétés, ils vident le rôle de sa substance, et l'équipe apprend très vite à contourner le nouveau venu. Si vous êtes vous-même un fondateur technique, ce renoncement est encore plus dur, et je lui ai consacré un article, comment lâcher le code.
La règle que je propose est simple : pour chaque jalon, nommez à voix haute ce que vous arrêtez de faire, devant l'équipe. « À partir de lundi, les demandes techniques passent par elle. » Une phrase publique engage bien plus qu'une bonne intention privée.
Les signaux qu'une intégration dérape
Quelques signaux, observés entre le 30e et le 60e jour, disent qu'il faut corriger le tir. Le CTO code encore à plein temps pour tenir une échéance, et n'a rien écrit de son diagnostic. L'équipe continue de venir vous voir pour arbitrer. Il découvre des engagements pris avant son arrivée. Ou, plus discret, il ne conteste plus rien en réunion.
Fixez dès la signature un échange franc au 45e jour, à deux, sans ordre du jour opérationnel. Deux questions suffisent : qu'est-ce qui t'empêche de faire ton métier ? Qu'est-ce que je fais encore et que je devrais arrêter ? C'est le moment où un désalignement se corrige en une conversation, plutôt qu'en démission au neuvième mois.
Quand l'intégration échoue malgré tout, l'erreur remonte souvent plus haut, au moment du choix du profil ou de la promesse faite en entretien : c'est tout le sujet des erreurs de recrutement de CTO et, en amont, du processus pour recruter un CTO. Mais un bon recrutement mal intégré se perd aussi sûrement qu'un mauvais, et beaucoup plus bêtement.
J'accompagne les fondateurs du recrutement de leur CTO jusqu'à sa prise de poste : mandat, jalons, passation des sujets techniques en cours et points d'étape. 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.
Je dois recruter mes premiers profils techniques
Le premier recrutement conditionne tous les suivants.
Mon prestataire est le seul à connaître mon produit
Personne en interne ne sait reprendre le code ni les serveurs.
ou appelez-moi au 06 20 52 03 69