Faut-il recruter un CTO ? Montrez-moi d’abord les décisions qui attendent

Le message arrive souvent de la même façon. « Je cherche un CTO. » Je demande ce qu’il devra décider le premier mois. Silence, puis une liste de symptômes : les livraisons glissent, les développeurs se plaignent, un gros client a posé des questions techniques auxquelles personne n’a su répondre. Ce n’est pas une fiche de poste. C’est une pile de décisions que personne n’a prises.

La plupart des entreprises qui veulent recruter un CTO n’ont pas un poste vacant. Elles ont des arbitrages en souffrance, et le recrutement est la manière la plus confortable de ne pas les regarder. Pendant toute la durée d’un recrutement, personne n’est responsable, et tout le monde trouve ça normal. Il arrive qu’un CTO soit la bonne réponse. On ne le sait qu’après avoir fait la liste.

Un ralentissement ne prouve rien. Il peut venir d’un manque de capacité, d’un problème d’organisation ou d’une friction technique, et aucun des trois ne se règle avec un titre. Ce qui prouve quelque chose, c’est une décision qui engage l’entreprise et que personne ne peut prendre : une architecture à faire évoluer, une contrainte de sécurité à imposer, un engagement technique demandé par un client.

Alors prenez une feuille. Quelles décisions attendent ? Qui devrait les prendre aujourd’hui, avec quel mandat ? Combien de temps demandent-elles, préparation et suivi compris ? Survivront-elles au chantier en cours ? Quatre questions, et une bonne partie des « besoins de CTO » que je vois deviennent autre chose : un fondateur qui doit cesser de décider seul, un lead dev à qui il manque un mandat, une migration à faire faire une fois.

Méfiez-vous surtout de la fréquence. Une réunion quotidienne de dix minutes ne fait pas un temps plein. Un arbitrage mensuel peut en occuper la moitié. La fiche de poste doit décrire ce travail, pas recopier un intitulé.

Le fondateur qui décide de tout et le lead dev débordé se ressemblent plus qu’il n’y paraît. Le premier porte l’architecture, la feuille de route et les embauches, il le fait correctement, et il est fatigué, pas incompétent : il doit écrire ce qu’il décide et ce qu’il délègue, puis déléguer vraiment, pas accueillir un CTO qui viendrait se heurter à lui. Le second tient l’équipe et la livraison, et on lui a ajouté au fil des mois la roadmap, les recrutements et les réunions de direction. Il manque de mandat, pas de niveau ; retirez-lui ce qui peut l’être avant d’ajouter une couche de management au-dessus de lui. La différence entre les deux rôles est dans CTO ou lead dev.

Les bugs à répétition. Ils appellent des tests, des revues, un suivi des incidents, et un responsable disponible organise ça en interne. Une migration fragile justifie une mission délimitée si la capacité manque. Ni l’un ni l’autre ne crée un besoin permanent.

Ce qui crée un besoin permanent, c’est une charge de direction technique qui occupe le quotidien et qui durera. Là, il faut quelqu’un. Reste à savoir à quel rythme.

« Sans recruter » peut vouloir dire sans CDI, sans temps plein, ou simplement sans ajouter quelqu’un. Ces trois demandes n’appellent pas le même dispositif. Je commencerais par écrire les décisions à couvrir le mois prochain, puis par nommer la personne qui prépare chacune, celle qui tranche et celle qui vérifie la suite.

Situation à couvrir	Option à examiner	Ce qu’il faut lui donner
Un responsable interne sait décider, mais son mandat reste flou	Clarifier sa responsabilité et sa délégation	Un périmètre écrit, du temps dégagé et un accès aux arbitrages de direction
Une migration ou une décision d’architecture est délimitée	Une mission spécialisée	Une question précise, un livrable attendu et un responsable interne pour la suite
Les arbitrages reviennent, avec une charge compatible avec quelques jours par mois	Un CTO à temps partagé	Un mandat, une cadence, une disponibilité convenue et une règle pour les urgences entre deux interventions
La direction technique demande une présence quotidienne durable	Préparer un rôle interne	Le budget, la place dans la direction et une passation organisée

Une disponibilité convenue compte plus qu’un intitulé. Si votre équipe attend tous les matins une décision pour avancer, deux jours par mois risquent surtout de créer une nouvelle file d’attente. Si les décisions sont espacées et préparables, payer un temps plein pour rassurer l’organigramme ne les rendra pas meilleures.

Avant de signer, je voudrais trois choses sur une page : les décisions confiées, les limites de délégation, et ce qui se passe quand la personne n’est pas là. Qui peut engager une dépense ? Qui accepte un risque ? Qui appelle qui lorsqu’un incident dépasse le mandat ? Le CTO freelance décrit les formats de mission ; les tarifs du CTO externalisé permettent ensuite de chiffrer le rythme retenu. Le titre vient après le travail à couvrir.

Mon tarif de CTO à temps partagé est de 550 € HT la journée : deux jours par mois font 1 100 € HT, quatre jours 2 200 € HT. Le diagnostic technique et organisationnel dure cinq jours pour 3 000 € HT. Je facture hors TVA depuis l’île Maurice.

Pour un CTO salarié, je n’ai pas de grille à moi. La fiche métier Directeur des systèmes d’information de l’Apec, qui range « Chief Technical Officer (CTO) » parmi ses intitulés, indique que 80 % des rémunérations annuelles brutes proposées dans les offres d’emploi, fixe et variable compris, vont de 45 k€ à 110 k€, pour une moyenne de 71 k€. Ce sont des offres publiées, hors charges patronales, et le métier de DSI ne recouvre pas toujours celui d’un CTO de startup.

Mais ne comparez pas des lignes de budget, comparez du travail. Un CTO salarié est là tous les jours, porte la responsabilité dans la durée et peut devenir associé. Deux jours par mois ne remplacent pas ça. Ils suffisent quand les décisions de direction sont réelles sans remplir une semaine, ou pour préparer le recrutement de celui qui les portera ensuite.

Alors recrutez pour des décisions, pas pour des technologies. La fiche de poste liste ce que le CTO décidera : architecture d’ensemble, feuille de route technique, recrutement des développeurs, budget des outils et des prestataires, sécurité. Pour chaque ligne, qui décide aujourd’hui et ce qui change à son arrivée. Une fiche qui énumère des frameworks attire des lead devs, et vous aurez recruté la mauvaise personne avec la bonne étiquette.

Faites un état des lieux avant les entretiens : architecture, dette, organisation, risques connus. Les bons candidats le demanderont. Si personne chez vous ne peut juger la profondeur technique d’un candidat, faites-vous aider pour définir le poste et mener les entretiens. C’est une des missions que je prends en temps partagé, précisément pour que le poste soit défini avant d’être pourvu.

Enfin, décidez de sa place avant son arrivée. Un CTO tenu à l’écart des décisions sur le produit et le budget fera un travail de lead dev, au prix d’un CTO. Et il ne restera pas.

Je ferais la liste avant toute chose, pour estimer le temps de préparation, de décision et de suivi, ainsi que la disponibilité nécessaire. Si quelqu’un en interne peut porter ce travail, je clarifierais son mandat et je dégagerais le temps qui lui manque. Si la charge est récurrente, tient dans quelques jours par mois et permet à l’équipe d’avancer entre les interventions, je prendrais un CTO à temps partagé, avec un périmètre écrit. Si elle exige une présence quotidienne durable, je préparerais le poste interne, et je m’entourerais pour le pourvoir.

Le test « Ai-je besoin d’un CTO ? » formalise cette discussion en quelques minutes. La page sur la gouvernance technique liste les décisions qu’un dirigeant doit pouvoir suivre, avec ou sans CTO.

Ce que coûte de ne pas faire la liste est simple : des mois de recrutement pendant lesquels les décisions attendent encore, puis un CTO qui découvre qu’on l’a embauché pour les prendre à votre place, sans qu’on les lui ait jamais formulées.