CTO ou lead dev : qui décide quand le commerce et la technique se heurtent ?

Qui, chez vous, tranche quand une exigence technique heurte une échéance commerciale ? Si vous hésitez avant de répondre, vous tenez le sujet de cet article, et il n’a presque rien à voir avec le niveau de vos développeurs.

Un cas classique : le fondateur vient de promouvoir son meilleur développeur. Nouveau titre : CTO. Rien d’autre n’a changé. Les priorités, le budget et les recrutements se décident toujours dans le bureau du fondateur. Le nouveau CTO code autant qu’avant, avec en plus l’attente diffuse qu’il « prenne de la hauteur ». Dans un an, l’un des deux sera déçu. Souvent les deux.

Le lead dev rend une équipe efficace dans un cadre. Le CTO décide du cadre, avec vous, et répond de ses conséquences. Nommer un CTO sans lui donner de mandat, ce n’est pas créer un rôle, c’est renommer un lead dev. J’ai fait ce passage chez Ipedis, et c’est là qu’on voit ce que le titre ne dit pas.

Un tableau, parce qu’il remplace une page.

Responsabilité	Lead dev	CTO
Architecture	Fait évoluer le code de son équipe dans les choix établis	Arbitre l’architecture d’ensemble et ses compromis avec le budget, les délais et les risques
Roadmap	Découpe, estime et organise le travail prévu	Construit la feuille de route technique avec la direction et le produit
Recrutement	Participe aux entretiens techniques et à l’intégration	Définit les postes, le plan de recrutement et la structure de l’équipe
Direction	Rend compte de l’avancement et signale les blocages	Participe aux décisions et traduit la technique en coûts, délais et risques
Code	Une part importante de son temps	Une part qui diminue quand l’équipe grandit

Lisez la colonne de droite. Aucune de ces décisions n’est une décision de code. Un lead dev décide comment livrer une fonctionnalité. Un CTO décide, avec vous, s’il faut la livrer maintenant, avec quelle équipe et au prix de quel risque. Si personne chez vous ne prend ces décisions-là, vous n’avez pas de CTO, quoi qu’en dise l’organigramme.

D’abord le fondateur qui veut tout valider. Il a nommé un CTO parce que les investisseurs ou les clients en demandent un, puis il garde le produit, le budget et les embauches. Pas par malice : il a construit l’entreprise, chaque décision technique lui semble encore la sienne. Son CTO est un lead dev avec un titre coûteux et une frustration qui grandit.

Ensuite le CTO que l’on mesure aux tickets. Plus l’équipe grossit, plus son temps part dans des décisions, des recrutements et des conversations avec vous ; lui reprocher de moins coder, c’est lui reprocher de faire son travail.

Enfin le miroir du premier cas : le lead dev à qui l’on confie la feuille de route, les recrutements et la direction, sans le pouvoir de trancher. Il porte des choix qu’il ne peut pas arbitrer, et c’est le plus sûr moyen de perdre un bon lead dev.

Les titres, eux, ne prouvent rien. Chez Gridky, j’étais Head of Engineering. Pendant le gel des fonctionnalités, l’arbitrage du calendrier appartenait au CTO et au CEO, le traitement des sujets à l’équipe. Personne ne regardait les titres. Tout le monde savait qui décidait quoi.

Chez Ipedis, j’étais lead dev d’une équipe de cinq. J’avais construit la V1 de PubliSpeak à partir de rien, et c’était précisément le problème : tout passait par moi. Quand l’équipe a commencé à grandir, j’ai dû choisir entre rester son meilleur développeur et devenir celui qui décide où elle va. À vingt-cinq, on ne peut pas être les deux.

Ce passage a déplacé mon impact. Il ne venait plus du code, mais de la compréhension du business. Le jour où j’ai commencé à parler de revenu, de risque et de croissance avec la direction, la technique a cessé d’être une fin en soi pour devenir un levier. Pendant ce temps, PubliSpeak devenait une plateforme de dix microservices sans interruption de service, et l’équipe passait de 5 à 25 personnes. Comment nous avons recruté et organisé, c’est dans Faire grandir une équipe de développement.

Deux conditions ont rendu ce passage réel pour moi. Un mandat, d’abord : participer aux décisions de la direction, pas en être informé après coup. Un renoncement, ensuite : accepter que d’autres prennent des décisions de code qui étaient les miennes, et parfois autrement que je l’aurais fait. Le second est le plus dur. Un lead dev qui devient CTO sans lâcher le code ne change pas de rôle, il se surcharge.

Si vous préparez ce passage pour quelqu’un, écrivez ce qu’il décide avec vous, ce qu’il arbitre avec le produit, et ce que les développeurs décident sans lui. Puis confiez une partie de son code à quelqu’un d’autre. La réussite se lit à un seul endroit : l’équipe décide et livre sans l’attendre.

Un lead dev suffit quand les décisions qui engagent l’entreprise ont déjà un propriétaire. Un co-fondateur technique qui porte l’architecture et la feuille de route, un produit stable, une seule équipe, peu de recrutements prévus : n’embauchez pas de CTO. Donnez à votre lead dev le nom de la personne qui tranche quand une exigence technique heurte une échéance commerciale. Sans ce nom, il tranchera par défaut, ou laissera pourrir.

Il ne suffit plus quand des décisions techniques engagent l’entreprise au-delà d’une équipe et que personne ne les porte : plusieurs équipes sur une même architecture, un plan de recrutement à construire, des clients qui demandent des engagements, des contraintes de sécurité à faire respecter. Le signal n’est pas l’absence du titre, c’est la file des arbitrages en attente. Un fondateur qui décide de l’architecture peut très bien tenir ce rôle. Regardez comment les décisions se prennent avant de conclure qu’il manque quelqu’un.

Le test « Avez-vous besoin d’un CTO ? » distingue l’autonomie, l’action interne et plusieurs formats de renfort. Et si votre question est d’ouvrir un poste ou non, c’est l’article Faut-il recruter un CTO qui la traite.

Entre un lead dev seul et un CTO à temps plein, il y a une troisième forme, et c’est celle que je pratique. Un CTO à temps partagé prend les décisions de direction convenues dans la mission, architecture d’ensemble, feuille de route, plan de recrutement, pendant que le lead dev garde l’équipe et la livraison. Mon tarif est de 550 € HT la journée, de quelques jours par mois à une présence hebdomadaire ; ce que cela donne en budget est dans l’article sur le tarif d’un CTO externalisé.

Ce format prépare la suite. Le lead dev voit comment les décisions se prennent et reprend progressivement ce qu’il peut porter. Il peut devenir votre CTO, ou vous aider à définir le poste avant un recrutement. Une répartition durable entre lead dev et CTO à temps partagé peut aussi convenir : le but n’est pas de fabriquer un poste à tout prix. L’organisation de ce type de collaboration est dans l’article sur le CTO freelance.

Choisir entre CTO et lead dev n’est pas une question de niveau, c’est une question de décisions en attente d’un propriétaire. Si vous ne savez pas les nommer, ne nommez personne CTO : vous n’auriez changé qu’une ligne de l’organigramme. La page sur l’organisation de l’équipe technique prolonge la question côté structure.