Faire venir un CTO fractionnel sur une équipe déjà en place

Vous avez déjà une équipe : trois, cinq, parfois huit développeurs, dont un lead dev qui porte la technique depuis le début. Mais les décisions structurantes restent sans arbitre, les recrutements patinent, et vous envisagez de faire venir un CTO fractionnel. Une inquiétude arrive aussitôt : comment l'équipe va-t-elle le prendre ?

Un CTO fractionnel s'intègre à une équipe interne déjà en place s'il arrive avec un mandat annoncé par le fondateur, s'il écoute plusieurs semaines avant de trancher, et s'il fait du lead dev en poste son relais plutôt que son subordonné. Le rejet vient presque toujours d'une arrivée vécue comme un désaveu, rarement de la personne elle-même.

Ce qu'est ce format, et quand y recourir, est détaillé dans le guide complet du CTO fractionnel. Le cas voisin d'une équipe externalisée (agence, offshore) est traité dans piloter une équipe externalisée comme CTO fractional : l'autorité y découle du contrat. Face à des salariés arrivés avant lui, un CTO externe doit la gagner.

D'où vient le rejet

Le rejet prend rarement une forme ouverte. Il est le plus souvent passif : personne ne signale les sujets au nouveau venu, les décisions se prennent entre deux de ses jours de présence, et il découvre les problèmes après coup. Parfois il est frontal, et chaque arbitrage est contesté en réunion. La forme la plus coûteuse reste silencieuse : le lead dev qui ne dit rien et commence à regarder ailleurs. Dans une équipe de cinq, perdre la personne qui connaît tout le système coûte des mois.

Le lead dev en poste : le relais, pas la victime

Tout se joue avec lui. Le premier entretien que je demande, avant même de rencontrer l'équipe, c'est avec le lead dev, seul. Pas pour l'évaluer, mais pour comprendre ce qu'il porte, ce qu'il aimerait lâcher et ce qu'il n'a jamais eu les moyens de faire. Très souvent, il réclame depuis des mois quelqu'un pour trancher les sujets qui dépassent le code : un recrutement, un prestataire, une priorité imposée par la vente. Mon arrivée peut le soulager plutôt que le déposséder, à condition de le lui dire, puis de le prouver.

Le partage des rôles s'écrit ensuite, et il se présente à l'équipe à deux voix. Le lead dev garde la conduite technique du quotidien : l'organisation du travail, les revues de code, les choix d'implémentation, le premier niveau face aux incidents. Je prends ce qui relève de la direction : les arbitrages qui engagent l'entreprise, les recrutements, la relation avec le fondateur et les investisseurs sur les sujets techniques. Entre les deux, une règle simple : je ne décide pas d'un sujet de son périmètre sans lui, et il me remonte ce qui dépasse le sien. La différence entre ces rôles est détaillée dans CTO, Head of Engineering, Lead Dev : qui fait quoi.

Il y a aussi une question qu'il vaut mieux poser tôt : le lead dev veut-il un jour prendre la direction technique ? Si oui, la mission change de sens. Elle devient une préparation, et c'est lui qui prendra la suite le jour où il faudra sortir de la mission de CTO fractionnel. Si non, rien ne l'y oblige, et le lui dire franchement évite un malentendu qui pèserait sur toute la mission.

Désamorcer : trois gestes dans les premières semaines

Ces gestes s'inscrivent dans le cadrage plus large du premier mois (accès, rituels, périmètre de décision), que je détaille dans les 30 premiers jours d'une mission de CTO fractionnel. Ils ne remplacent pas le temps pour autant : une équipe accorde sa confiance sur des décisions qui se révèlent justes, pas sur des intentions. Les premières semaines servent seulement à ce que ces décisions soient écoutées au lieu d'être contournées.

Quand l'intégration échoue malgré tout

Il arrive que le rejet persiste. Avant d'y voir une équipe réfractaire, je regarde trois causes, dans cet ordre. D'abord le fondateur : s'il continue d'adresser ses demandes directement aux développeurs, l'équipe comprend vite que le CTO n'a pas vraiment la main, un piège que je décris aussi pour l'intégration d'un premier CTO en CDI. Ensuite le besoin : parfois l'équipe avait raison, et ce qui manquait était un manager présent chaque jour plutôt qu'une direction technique quelques jours par semaine. Enfin moi-même : un CTO fractionnel qui tranche trop tôt, ou qui manque les rituels qu'il a lui-même installés, fabrique le rejet qu'il redoutait.

Dans les rares cas où rien ne bouge au bout de deux ou trois mois, il vaut mieux le dire et arrêter. Une mission qui dure contre l'équipe coûte plus cher que son absence : elle use le lead dev, ralentit les décisions et abîme la confiance du fondateur envers ses propres développeurs. À l'inverse, quand l'intégration prend, l'équipe en place devient le meilleur argument du format : elle garde son histoire et gagne un arbitre, sans avoir vécu l'arrivée comme une mise sous tutelle.