Le CTO que vous ne pouvez pas recruter — et pourquoi ce n’est pas encore votre problème

La plupart des fondateurs non techniques essaient de recruter un CTO au mauvais moment. Jusqu’à la Series A, le bon choix est presque toujours un partner de delivery. Voici comment savoir où vous en êtes.

Un fondateur que nous avons accompagné l’an dernier nous a raconté, autour d’un café à São Paulo, qu’il avait passé quatre mois à chercher un CTO. Il avait parlé à vingt-trois personnes. Aucune n’avait dit oui. Deux avaient dit oui puis disparu avant de signer. Il a fini son café et posé une question qui, à ce stade de sa levée, tenait de l’urgence : « À qui s’adressent les fondateurs non techniques quand ils n’arrivent pas à trouver le CTO ? »

C’est la mauvaise question. La bonne est : devriez-vous être en train d’en recruter un, tout court ?

La plupart des fondateurs early-stage que nous croisons sont convaincus que oui. Ils ont lu le playbook. Le playbook dit : recrute le co-founder technique, donne 20–30 % de l’entreprise, livre le produit, lève le tour. Ce playbook a quarante ans en temps de startup. Il a été écrit à une époque où il n’y avait pas d’autre façon de construire du logiciel. Aujourd’hui, il y en a.

Jusqu’à la Series A — et souvent bien au-delà — le bon choix pour un fondateur non technique n’est presque jamais de recruter un CTO. Le bon choix, c’est de travailler avec un partner de delivery qui se comporte comme tel. La différence est subtile, le coût est dramatique, et la plupart des fondateurs ne le voient pas avant d’avoir déjà donné l’equity.

Ce que fait un CTO dans la vraie vie (et pourquoi vous n’en avez pas besoin pour la plupart)

Avant de discuter du recrutement, il faut être précis sur ce que l’on recrute. Un vrai CTO, dans une entreprise financée par du capital-risque, fait cinq métiers. Il définit l’architecture du produit. Il recrute et manage l’équipe d’ingénierie. Il porte la roadmap technique et arbitre face à la roadmap business. Il représente l’ingénierie devant le board, les investisseurs et les clients enterprise. Et — généralement en cinquième position, malgré ce que pensent les fondateurs — il écrit parfois du code.

Pour une entreprise pre-seed ou seed, les métiers trois, quatre et cinq sont presque entièrement fictifs. Il n’y a pas d’équipe d’ingénierie à manager. Le board ne se soucie pas encore. Les clients enterprise n’existent pas. Ce dont vous avez réellement besoin, dans les dix-huit premiers mois, c’est du premier métier — quelqu’un capable d’architecter le système — et d’une petite équipe qui exécute cette architecture sans transformer le fondateur en goulot d’étranglement.

Un partner de delivery fait la partie architecte et fournit l’équipe. Un recrutement de CTO fait la partie architecte et vous fournissez l’équipe. Dans un modèle, le problème de ressources est résolu dès le jour un. Dans l’autre, il devient le premier projet du CTO — et consomme en général six mois et l’essentiel du runway que vous avez levé pour le tour.

Le calcul que les fondateurs ne font pas

Voici la comparaison que personne ne déroule devant les fondateurs, parce que les gens dans la pièce ont presque toujours un intérêt dans l’un des deux camps.

Recruter un CTO en seed : vous cédez environ 15 à 25 % de l’equity et payez un salaire qui se situe, aux États-Unis, entre 200 000 et 280 000 USD par an, en France entre 8 000 et 14 000 euros par mois pour un profil senior, au Brésil entre 30 000 et 60 000 reais par mois. Il arrive et passe ses deux premiers mois à recruter. Il fait deux premières embauches. À trois mois, vous avez trois ingénieurs, aucun produit, et le coût fixe le plus élevé de votre P&L est l’équipe d’ingénierie. Vous allez passer les douze mois suivants à manager le manager qui manage l’équipe. Le CEO qui disait « je ne veux pas être tech manager » sera, de fait, tech manager.

Travailler avec un partner de delivery : vous payez un forfait projet — pour une première version classique, entre 80 000 et 200 000 USD étalés sur quatre à neuf mois. L’équipe est en place dès le jour un. La discussion d’architecture se fait avec une personne senior avant la première ligne de code. Vous lancez, vous vendez à votre premier client payant, vous itérez — sans brûler du runway sur des personnes que vous n’êtes pas encore en mesure de manager.

Au bout de dix-huit mois, quand l’entreprise est plus grande et que le coût par feature en mode partner devient supérieur au coût d’une équipe interne, c’est le moment de recruter. Vous savez alors exactement quel type de CTO il vous faut, parce que le code le dit. Vous recrutez quelqu’un qui s’inscrit dans l’architecture déjà en place, au lieu de deviner l’architecture nécessaire avant qu’aucun code n’existe.

« Mais je veux un cofounder »

C’est là que les fondateurs poussent en sens inverse. Ils ne veulent pas externaliser le produit. Ils veulent un associé. Quelqu’un qui se réveille la nuit en pensant au même problème. Un nom sur le deck.

On l’entend. C’est une préférence réelle, et elle n’est pas fausse. Mais il faut être honnête sur ce qu’elle coûte et sur ce qu’on obtient.

Un cofounder technique qui rejoint en seed est rarement la personne qui construit l’entreprise que vous aurez en Series A. Les compétences nécessaires au mois deux — écrire du code, livrer vite, monter la base — ne sont pas celles du mois vingt — recruter, fixer la culture d’ingénierie, partitionner le système, gérer les audits de sécurité. Le nombre de CTOs qui font les deux bien, en succession, dans une équipe de moins de cinquante personnes, est faible. Le nombre de ceux qui pensent en être capables est élevé.

Si vous voulez un cofounder, recrutez-en un pour la zone du business où vous avez un vrai gap durable. Un cofounder go-to-market si vous êtes expert métier. Un cofounder produit si vous êtes commercial. Un second cofounder commercial si vous êtes builder. Le travail technique — tant que vous n’avez pas de quoi occuper une équipe à plein temps sur quelque chose que vous comprenez assez bien pour la diriger — peut être porté par un partner sans rien perdre d’essentiel. L’exception, c’est quand le travail technique est la défensibilité du produit (un produit lourd en recherche IA, une infrastructure profonde, un combo hardware-software), et même là, la plupart des fondateurs surestiment la part de leur code initial qui constitue vraiment le moat.

Comment savoir de quel côté vous êtes

Deux questions. Répondez-y honnêtement, par écrit, avant le prochain entretien avec un candidat CTO.

Première : suis-je capable, là, maintenant, d’écrire un brief d’une page sur ce que nous voulons construire dans les six prochains mois — ce que ça fait, qui l’utilise, à quoi ressemble le succès, avec quoi cela doit s’intégrer ? Si oui, vous n’avez pas besoin d’un CTO ; vous avez besoin d’un partner de delivery qui prenne ce brief et l’exécute. Si non, le gap est en amont de l’ingénierie — c’est de la clarté produit. Un CTO ne résoudra pas ça plus vite qu’un mois de plus en discussion avec des clients.

Deuxième : si un ingénieur senior arrivait demain, qu’est-ce que je lui confierais le premier mois ? Si la réponse honnête est « qu’il trouve quoi construire » — c’est un gap produit, pas un gap d’ingénierie. Si la réponse est « construire les features X et Y, voici les specs » — vous n’avez pas besoin d’un recrutement, vous avez besoin d’exécution. Si la réponse est « manager les quatre ingénieurs qu’on vient de lever de quoi recruter » — vous vous êtes convaincu du mauvais problème.

La seule réponse honnête qui justifie un recrutement de CTO en seed est : nous avons une décision technique complexe qui compose sur plusieurs années, la défensibilité du produit vit dans cette décision, et je ne peux pas, en bonne conscience, l’externaliser. C’est une situation réelle. C’est aussi une situation rare. La plupart des fondateurs n’y sont pas ; ils croient l’être parce que le playbook leur a dit qu’ils devraient l’être.

Ce que veut vraiment dire « partner de delivery »

Nous utilisons l’expression avec précaution, parce qu’elle a tellement été dévoyée par les agences qu’elle ne signifie presque plus rien. Un partner de delivery — celui dont nous parlons — se rapproche plus d’un CTO fractionné que d’une SSII. La relation a quatre propriétés.

L’ingénieur senior qui cadre votre projet est le même qui en relit le code six mois plus tard. Pas de handoff entre commercial et delivery, parce que ceux qui ont promis l’architecture sont ceux qui la construisent. Vous voyez comment se prennent les décisions — chaque arbitrage d’architecture est une vraie discussion, pas un livrable. Les trade-offs sont visibles. L’équipe écrit du code que vous pourrez confier à quelqu’un d’autre quand vous embaucherez en interne — parce que la transition est un objectif explicite du contrat, pas une réflexion de fin de course.

Cette dernière propriété est celle que la plupart des fondateurs ratent quand ils évaluent des partners. Le mauvais partner construit un système que lui seul peut maintenir, parce que cela enferme le fondateur. Le bon partner construit quelque chose qu’un futur CTO pourra reprendre proprement — c’est ainsi qu’on sait qu’il a la peau dans votre jeu long, et pas juste dans la facture du trimestre.

Quand, vraiment, recruter

Il y a des signaux. Le plus clair, c’est le volume — quand il y a, semaine après semaine, assez de travail d’ingénierie pour que payer ce volume via le partner devienne plus cher que faire tourner une équipe interne, et que ce volume est stable depuis au moins six mois. Cela arrive en général entre la Series A et la Series B en SaaS B2B, et plus tôt sur des produits grand public.

Le deuxième signal, c’est la vitesse de décision technique — quand la fréquence des arbitrages devient telle que la communication avec le partner devient une taxe. À ce stade, un lead interne est plus rapide, même s’il n’est pas strictement meilleur.

Le troisième signal, c’est la gravité du talent — quand les ingénieurs que vous voulez recruter ne viendront que si vous avez un CTO crédible à leurs yeux. Ce signal arrive plus tard que ce que les fondateurs imaginent ; des ingénieurs seniors acceptent volontiers de rejoindre une boîte en croissance accompagnée par un partner solide, à condition que le fondateur soit honnête sur le modèle et qu’un chemin clair vers la première embauche VP/CTO existe.

Quand vous recruterez, recrutez quelqu’un qui s’adapte au code construit par le partner, pas à l’idée abstraite de « un CTO ». Le rôle du partner est de faciliter ce recrutement, pas de le compliquer. C’est le test.

Ce que personne ne dit à voix haute

Nous avons vu des dizaines de fondateurs seed traverser cette décision. Ceux qui ont recruté trop tôt ont presque tous dit, douze mois plus tard, qu’ils auraient préféré ne pas le faire. Ceux qui ont d’abord choisi un partner ne disent presque jamais l’inverse. L’asymétrie n’est pas subtile.

Il y a une raison. La pression à recruter un CTO en seed est, pour l’essentiel, sociale. Elle vient d’investisseurs qui aiment voir une équipe « complète » sur un deck. Elle vient de pairs qui ont pris la même décision avant que les partnerships de logiciel sur mesure ne soient crédibles. Elle vient de l’angoisse du fondateur d’être la seule personne au cap table qui n’écrit pas de code. Aucun de ces arguments ne porte sur ce qui est bon pour l’entreprise. Ce sont des arguments sur ce qui est confortable pour le fondateur.

La réponse inconfortable, c’est que, dans les dix-huit premiers mois, la plupart des fondateurs non techniques n’ont pas besoin d’un CTO. Ils ont besoin d’une personne senior qui a déjà construit ce genre de chose, d’une petite équipe qui exécute, et de la discipline de garder leur propre rôle braqué sur les clients, la distribution et le business — pas sur l’organigramme d’ingénierie qui n’existe pas encore.

Quand ce jour arrivera, recrutez. D’ici là, construisez.