Pas de CTO, pas de produit ? Le vrai choix entre recruter, s'associer et externaliser votre dev early-stage

Un fondateur non-technique nous répète la même phrase depuis six mois : « Je cherche un CTO. » Il a une idée validée par une trentaine d’entretiens, deux lettres d’intention signées, et zéro ligne de code. Ce qu’il cherche vraiment, ce n’est pas un CTO. C’est un produit. Et confondre les deux lui a déjà coûté six mois.

Le réflexe est compréhensible. On raconte partout que sans co-fondateur technique, une startup ne lève pas, ne recrute pas, ne survit pas. C’est en partie vrai — et en partie un dogme qui pousse des fondateurs à s’associer dans l’urgence avec la première personne qui sait déployer un serveur. Le vrai sujet n’est pas si vous avez besoin de compétences techniques. C’est à quel moment, sous quelle forme, et pour construire quoi.

La question mal posée : « CTO » ne veut rien dire à ce stade

Un CTO de série B gère une équipe de vingt ingénieurs, arbitre une roadmap technique sur dix-huit mois et défend une dette technique auprès du board. Un « CTO » de pre-seed écrit lui-même le code, choisit la stack, parle aux premiers clients et débugge en production à 23h. Ce sont deux métiers différents portant le même titre.

Quand un fondateur early-stage dit « je cherche un CTO », il cherche en réalité l’une de ces trois choses, rarement clarifiée : un exécutant capable de sortir un MVP vite, un associé prêt à porter le risque avec lui sur plusieurs années, ou un architecte capable de faire des choix techniques qui ne coûteront pas une refonte dans dix-huit mois. Ces trois besoins n’appellent pas la même réponse. Confondre les trois, c’est chercher un mouton à cinq pattes qu’on paiera soit en equity mal placée, soit en salaire qu’on n’a pas.

Avant de recruter qui que ce soit, la vraie question est : de quoi ai-je besoin pour atteindre le prochain jalon ? Pas la vision à cinq ans. Le prochain jalon. Souvent, ce jalon, c’est « prouver que des gens paient pour ça ». Et pour ça, vous n’avez pas besoin d’un architecte système. Vous avez besoin de quelque chose qui marche assez bien pour être vendu.

Trois voies, trois logiques de risque

S’associer avec un profil technique

C’est la voie qu’on idéalise, et c’est aussi la plus irréversible. Un co-fondateur technique, c’est 30 à 50 % de votre equity, une relation qui doit tenir sous stress pendant des années, et une personne qui doit être aussi obsédée que vous par le problème — pas juste séduite par le projet.

Le piège classique : s’associer avec un développeur talentueux qui n’a aucune envie de porter le produit, seulement de le construire. Six mois plus tard, il veut coder de nouvelles features pendant que vous avez besoin de quelqu’un qui parle aux clients, arbitre des priorités et accepte de jeter du code qui ne sert pas. Un bon co-fondateur technique early-stage n’est pas le meilleur ingénieur que vous puissiez trouver. C’est celui qui comprend que le code n’est qu’un moyen.

Cette voie est la bonne si le produit est la difficulté centrale de votre startup — si votre avantage repose sur une prouesse technique réelle (traitement de données complexe, IA propriétaire, contrainte de latence, forte composante infra). Elle est la mauvaise si votre difficulté est d’aller au marché, de convaincre, de distribuer. Dans ce cas, donner la moitié de l’entreprise pour du code que vous pourriez acheter est une erreur de valorisation de vos propres compétences.

Recruter un premier ingénieur salarié

Entre l’associé et le prestataire, il y a l’employé numéro un. Souvent négligé parce qu’il suppose d’avoir déjà un peu d’argent — mais c’est parfois la meilleure option post-seed. Vous gardez votre equity, vous gardez le contrôle des décisions produit, et vous obtenez quelqu’un d’engagé au quotidien sans le poids d’une association définitive.

Le problème : recruter un bon ingénieur quand on n’est pas technique soi-même est difficile. Vous ne pouvez pas évaluer sérieusement la qualité de quelqu’un dans un domaine que vous ne maîtrisez pas. C’est là qu’un accompagnement externe, un CTO fractionné ou un advisor technique de confiance change tout : quelqu’un qui fait passer les entretiens techniques à votre place et vous évite de recruter un profil brillant sur le papier mais incapable de livrer dans un contexte de startup.

Externaliser à une agence ou un freelance

C’est l’option qu’on méprise à tort. Externaliser son MVP à un freelance senior ou une petite agence produit peut être la décision la plus rationnelle pour un pre-seed non-technique. Vous transformez un besoin flou en un livrable daté, vous ne diluez personne, et vous validez votre marché avant d’engager quoi que ce soit d’irréversible.

Le risque réel n’est pas la qualité — de bons prestataires existent. Le risque, c’est le transfert. Un MVP externalisé mal cadré, c’est du code que personne dans l’équipe ne comprend, sans documentation, sur une stack que le prochain développeur voudra jeter. Vous vous retrouvez propriétaire d’une boîte noire. La parade tient en quelques exigences non négociables : le code vous appartient contractuellement, il est sur votre dépôt Git dès le premier jour, la stack est mainstream et non exotique, et un minimum de documentation est livré. Externaliser n’excuse pas de rester ignorant de ce qu’on construit.

Le lien qu’on oublie : chaque voie engage votre architecture

Voici ce qui échappe à la plupart des fondateurs business : ces choix humains sont aussi des choix techniques. Un freelance payé au forfait pour un MVP optimisera pour livrer vite, pas pour construire une base scalable — c’est légitime, mais ça veut dire une dette technique assumée d’avance. Un co-fondateur qui adore l’ingénierie voudra peut-être une architecture propre et sur-dimensionnée pour un produit qui n’a pas encore un seul utilisateur payant. Les deux erreurs coûtent, dans des directions opposées.

La bonne nouvelle, c’est qu’au stade pre-seed, la réponse technique par défaut est presque toujours la même quelle que soit la voie : la stack la plus ennuyeuse possible. Un monolithe classique, une base de données relationnelle standard, un hébergement managé simple, et éventuellement des briques no-code ou low-code pour tout ce qui n’est pas votre cœur de valeur. Vous ne construisez pas pour le million d’utilisateurs. Vous construisez pour les cent premiers, et pour pouvoir pivoter en deux semaines si le marché vous dit non.

Le vrai signal qu’il est temps d’internaliser sérieusement la tech — associé ou premières embauches — ce n’est pas « on a levé ». C’est « le produit est devenu la source de notre avantage, et le sous-traiter nous ralentit maintenant que nous savons quoi construire ». Tant que vous cherchez encore votre marché, la tech est un moyen d’apprendre vite. Une fois le marché trouvé, elle devient un actif à protéger.

Ce qu’il faut vraiment faire

Commencez par nommer honnêtement votre difficulté centrale. Si c’est aller au marché, ne bradez pas votre equity pour du code : externalisez le MVP proprement et gardez votre capital pour recruter quand vous saurez précisément quoi construire. Si votre avantage est authentiquement technique, cherchez un associé — mais un associé aligné sur la mission, pas le meilleur codeur disponible.

Ne recrutez jamais un profil technique que vous ne pouvez pas évaluer sans aide extérieure. Faites intervenir un advisor, un CTO à temps partagé ou un mentor technique pour vos entretiens et vos choix de stack. Le coût de ce filet est dérisoire face à celui d’un mauvais recrutement senior ou d’une architecture à refaire.

Et quelle que soit la voie choisie, gardez la propriété du code, une stack banale, et une documentation minimale. Ce sont les trois choses qui rendent réversible une décision qui, sinon, vous enferme.

Alors, avant de rouvrir votre annonce « CTO recherché », posez-vous la seule question qui compte : est-ce que ma prochaine étape a besoin d’un architecte, d’un exécutant ou d’un associé ? La réponse détermine tout le reste — et elle change avec chaque jalon franchi.