« On cherche un CTO. »
C'est la phrase par laquelle commencent la plupart des échanges que j'ai avec des fondateurs. Je suis CTO hands-on : j'architecture, je code, je structure l'équipe technique. Les startups me contactent donc souvent avec ce mot en tête, et je passe une bonne partie de ces premiers appels à faire la même chose : comprendre ce qu'elles cherchent vraiment.
Parce qu'au bout de dix minutes, la réponse est rarement « un CTO » au sens où elles l'imaginaient. C'est parfois quelqu'un pour livrer un MVP en trois mois. Parfois quelqu'un pour reprendre un code laissé par une agence. Parfois quelqu'un pour trancher les débats entre trois développeurs qui avancent chacun dans leur direction. Et parfois, honnêtement, ce n'est pas un CTO du tout.
Voici ce que ces échanges m'ont appris sur la façon de choisir un CTO qui correspond à vos besoins réels, plutôt qu'à l'idée qu'on se fait du poste.
Le mot « CTO » recouvre plusieurs métiers
Le premier piège est de croire que « CTO » désigne un rôle précis. Ce n'est pas le cas, et ça ne date pas d'hier.
En 2007, Werner Vogels, CTO d'Amazon, recensait déjà quatre façons très différentes d'exercer ce rôle : le responsable d'infrastructure, le visionnaire qui pilote aussi les opérations, le technologue tourné vers les clients, et le « big thinker » centré sur l'innovation et la stratégie. ^1 Quatre métiers, un seul titre.
Greg Brockman, lorsqu'il est devenu CTO de Stripe, a fait l'exercice d'interroger une vingtaine de CTO et de VP Engineering sur leur rôle. Il s'attendait à trouver des architectes en chef. Il n'en a trouvé qu'un seul : tous les autres se voyaient comme des facilitateurs de l'organisation technique. ^2
Si les CTO eux-mêmes ne décrivent pas leur poste de la même façon, un fondateur qui publie une annonce « CTO » sans préciser le besoin est presque sûr d'attirer des profils qui ne lui correspondent pas.
Les cinq situations que je rencontre le plus souvent
En échangeant avec des startups à des stades très différents, les demandes finissent par se ranger dans quelques situations récurrentes. Chacune appelle un profil et un format différents.
| Ce que la startup me dit | Le besoin réel | Le profil adapté |
|---|---|---|
| « On a une idée validée, pas encore de produit » | Construire un MVP et prendre les premières décisions de stack | Un CTO hands-on qui code la majorité du temps |
| « Notre prestataire ou notre outil no-code atteint ses limites » | Auditer l'existant, décider quoi garder, migrer sans casser | Un profil hands-on qui a déjà repris et migré des bases existantes |
| « On a deux ou trois devs, mais personne ne tranche » | Un cadre de décision, des standards, de la code review, du recrutement | Un CTO hands-on à temps partiel, présent dans le code et dans les décisions |
| « On a levé, l'équipe va passer de 8 à 25 » | Structurer des équipes, des managers, des process de delivery | Un CTO orienté organisation ou un Head of Engineering |
| « Un investisseur nous demande qui porte la tech » | Crédibilité technique, feuille de route, réponses en due diligence | Selon le cas : un audit et une feuille de route, ou un associé technique |
Deux remarques sur ce tableau.
La première : les trois premières lignes représentent l'essentiel des startups pré-seed et seed avec qui j'échange. Ce sont des besoins où il faut à la fois exécuter et décider, avec un budget qui ne permet pas de financer deux postes. C'est exactement le terrain du CTO hands-on, et c'est aussi là que recruter un profil purement stratégique coûte le plus cher, comme je l'expliquais dans Recruter un CTO trop tôt.
La seconde : la quatrième ligne est un autre métier. Piloter une trentaine de développeurs répartis en plusieurs squads, je l'ai fait, et ce n'est plus le même travail. On y code beaucoup moins, on y gère des managers, des budgets et des arbitrages entre équipes. Une startup à ce stade a besoin de quelqu'un dont c'est le cœur de métier, pas d'un builder qui s'y adapte à contrecœur.
Quatre questions à vous poser avant de chercher
Avant de rédiger une annonce ou d'activer votre réseau, prenez une heure pour répondre à ces quatre questions. Elles éliminent la moitié des mauvais choix.
1. Qui écrit le code dans les trois prochains mois ?
C'est la question la plus révélatrice. Si la réponse est « personne pour l'instant », vous avez besoin de quelqu'un qui code, beaucoup, dès la première semaine. Un CTO qui vous explique en entretien qu'il « ne codera pas trop » n'est pas le bon profil, quelle que soit la qualité de son CV.
Si vous avez déjà des développeurs, le besoin se déplace : vous cherchez quelqu'un qui code assez pour comprendre la base de l'intérieur, mais dont la vraie valeur sera de cadrer, relire et décider. C'est la différence que je détaillais dans Un bon développeur n'est pas un CTO.
2. Quelles décisions sont vraiment irréversibles chez vous ?
Jeff Bezos distingue les décisions « portes à sens unique », difficiles ou impossibles à défaire, qui méritent du temps et de la réflexion, des décisions « portes à double sens », qu'on peut et qu'on doit prendre vite. ^3
En early-stage, la plupart des décisions techniques sont des portes à double sens. Mais quelques-unes ne le sont pas : le modèle de données au cœur du produit, la gestion de données sensibles ou de santé, un engagement long avec un fournisseur cloud, une architecture qui impose un type de profil à recruter. Listez-les. Si vous en avez plusieurs dans les six prochains mois, l'expérience du CTO pèse plus lourd que sa vitesse d'exécution.
3. De combien de présence avez-vous réellement besoin ?
Beaucoup de startups pensent temps plein par réflexe. Or le besoin réel est souvent :
- ponctuel : un audit, un choix de stack, un plan de structuration, sur une à quatre semaines ;
- régulier mais partiel : deux ou trois jours par semaine pour architecturer, coder les parties critiques et encadrer l'équipe ;
- à plein temps : quand le produit entier repose sur une seule personne technique.
Choisir le bon format est aussi important que choisir la bonne personne. Un excellent CTO à plein temps sur un besoin de deux jours par semaine, c'est un budget qui part en réunions pour occuper l'agenda.
4. Cherchez-vous un associé ou un intervenant ?
Un associé technique prend des parts, s'engage sur plusieurs années et partage le risque. Un CTO en mission apporte de l'expérience immédiate, sans dilution, avec un engagement délimité. Les deux sont légitimes, mais ils ne se recrutent pas de la même façon et ne règlent pas le même problème.
Le cas que je vois le plus souvent mal tourner : chercher un associé alors qu'on a surtout besoin d'aller vite sur un MVP, et passer six mois en « dating » de cofondateur pendant que personne ne construit rien. Une mission sur la phase de construction n'empêche pas de trouver un associé ensuite, au contraire : il arrivera sur une base saine.
Ce qu'il faut demander en entretien
Les entretiens de CTO dérivent souvent vers une discussion de stack. C'est le sujet le moins utile : un bon CTO choisira une stack raisonnable, un mauvais aussi. Ce qui les distingue se voit ailleurs.
- « Racontez-moi une décision technique que vous regrettez. » Un CTO expérimenté en a plusieurs, et sait expliquer ce qu'il ferait différemment. Une absence de réponse est un signal.
- « Qu'est-ce que vous ne construiriez pas dans notre produit ? » La capacité à dire non, à retirer du périmètre, compte plus en early-stage que la capacité à ajouter.
- « Combien coûterait notre infrastructure à 10 fois le trafic actuel ? » Vous ne cherchez pas un chiffre exact, mais quelqu'un qui pense spontanément en coûts et pas seulement en technologie.
- « Expliquez-moi ce choix comme si j'étais un investisseur. » Votre CTO devra défendre ses arbitrages devant des non-techniques. Mieux vaut le vérifier tout de suite.
- « Montrez-moi du code que vous avez écrit récemment. » Pour un poste hands-on, c'est non négociable.
Les signaux d'alerte que je repère chez les fondateurs et chez les candidats
Côté candidat, quelques signaux reviennent souvent dans les retours que me font les fondateurs après un mauvais recrutement :
- il propose une architecture avant d'avoir posé une seule question sur vos utilisateurs ;
- il recommande des microservices, Kubernetes et trois environnements dès le premier jour, pour un produit qui n'a pas encore de clients (un monolithe bien conçu suffit presque toujours) ;
- il ne parle jamais de budget, de délais ou de priorités business ;
- il annonce une disponibilité totale tout en cumulant plusieurs autres engagements.
Côté fondateur, le signal le plus fréquent est plus subtil : chercher un CTO pour se débarrasser du sujet technique. Un bon CTO prend en charge les décisions techniques, mais il a besoin d'un interlocuteur côté produit et business qui reste impliqué. Si personne dans l'équipe fondatrice ne veut entendre parler de la tech, même le meilleur profil finira par décider seul, dans le vide.
Tester avant de s'engager
Le moyen le plus fiable de savoir si un CTO correspond à vos besoins reste de travailler avec lui sur un problème réel.
C'est pour ça que je propose systématiquement de commencer par une mission courte : un audit technique de l'existant, un choix de stack argumenté ou un plan de structuration, sur une à quatre semaines. Pour la startup, c'est un livrable concret, utile quoi qu'il arrive ensuite. Pour les deux parties, c'est une période d'essai qui dit beaucoup plus qu'une série d'entretiens : la façon de communiquer, de prioriser, de dire « je ne sais pas ».
Si la collaboration fonctionne et que le besoin s'inscrit dans la durée, elle se prolonge en CTO à temps partiel ou à plein temps : architecture, code et encadrement de l'équipe, avec une présence régulière. Si elle ne fonctionne pas, la startup repart avec un diagnostic clair et une meilleure idée du profil à chercher.
Quand je ne suis pas le bon profil
Une bonne partie de mes échanges avec des startups se termine sans mission, et c'est normal. Quand le besoin est un VP Engineering pour structurer une organisation de quarante personnes, un associé technique à plein temps avec une part significative du capital, ou simplement un développeur supplémentaire pour exécuter une roadmap déjà bien cadrée, je le dis.
Mal nommer le besoin coûte des mois. Le dire franchement au premier appel coûte une conversation.
FAQ : choisir un CTO pour sa startup
Comment savoir de quel type de CTO ma startup a besoin ?
Partez de la situation, pas du titre. Demandez-vous qui écrira le code dans les trois prochains mois, quelles décisions techniques seront difficiles à défaire, et de combien de présence vous avez réellement besoin. Une startup sans produit a besoin d'un profil qui construit. Une startup avec une équipe en place a besoin d'un profil qui cadre et décide. Une startup en forte croissance a besoin d'un profil qui organise.
Faut-il un CTO associé ou un CTO en mission ?
Un CTO associé partage le risque et s'engage sur plusieurs années, en échange de parts. Un CTO en mission apporte une expérience immédiate, sans dilution, sur un périmètre défini. En early-stage, une mission permet souvent d'avancer sur le produit pendant la recherche d'un associé, qui arrivera alors sur une base technique saine.
Quelle est la différence entre un CTO hands-on et un fractional CTO ?
Un fractional CTO intervient généralement à temps partiel sur la stratégie technique, souvent à distance du code. Un CTO hands-on peut aussi intervenir à temps partiel, mais reste opérationnel : il architecture, écrit du code et encadre l'équipe au quotidien. Pour une startup pré-seed ou seed qui a besoin d'exécution autant que de direction, cette différence est déterminante.
Comment évaluer un CTO quand on n'est pas soi-même technique ?
Concentrez-vous sur ce que vous pouvez juger : sa capacité à expliquer ses choix simplement, à parler budget et priorités, à reconnaître ses erreurs passées. Pour la partie technique, une mission courte d'audit ou un échange avec un pair technique de confiance est plus fiable qu'un entretien centré sur la stack.
Peut-on commencer par une mission courte avant d'engager un CTO dans la durée ?
Oui, et c'est souvent la meilleure option. Une mission d'une à quatre semaines produit un livrable utile (audit, choix de stack, plan de structuration) et sert de période d'essai réelle aux deux parties, sur un vrai problème plutôt que sur des questions d'entretien.
Ce que je recommande, en tant que CTO hands-on
Ne cherchez pas un CTO. Cherchez la réponse à un problème précis : construire un premier produit, reprendre une base existante, cadrer une équipe qui avance sans direction, ou structurer une croissance rapide. Le bon profil découle de ce problème, pas l'inverse.
Écrivez ce problème en trois phrases avant votre premier appel. Si la personne en face vous aide à le reformuler plus précisément, plutôt que de vous vendre directement un titre et un tarif, vous êtes probablement en train de parler à quelqu'un qui pourra vous aider.