Externaliser votre développement ou recruter un CTO : la décision qui engage votre produit et votre valorisation

Un fondateur non-technique nous montre son MVP la semaine dernière. Il fonctionne, il a ses premiers clients payants, et il vient de signer un term sheet en seed. Puis vient la question de son investisseur : « Qui possède le code ? » Réponse gênée : une agence en Europe de l’Est, contrat au forfait, aucun développeur en interne. La discussion sur la valorisation a changé de ton dans la minute.

Le choix entre externaliser son développement et recruter un CTO n’est pas une décision d’intendance qu’on règle en comparant des taux journaliers. C’est une décision qui détermine qui contrôle votre produit, à quelle vitesse vous itérez, et ce que verra un investisseur lors de sa due diligence technique. Et la plupart des fondateurs la tranchent pour de mauvaises raisons — le coût affiché — en ignorant celles qui comptent vraiment.

Le faux arbitrage : le coût par jour

La comparaison qu’on fait spontanément est trompeuse. Une agence à 500 € la journée semble plus chère qu’un développeur senior à embaucher, jusqu’à ce qu’on ajoute les charges, le temps de recrutement, l’onboarding, et le risque qu’il parte au bout de huit mois. À l’inverse, un CTO cofondateur « ne coûte rien » en cash — sauf qu’il coûte parfois 15 à 25 % du capital, soit la ligne la plus chère de toute la vie de la startup.

Le vrai arbitrage ne porte pas sur le prix du jour-homme. Il porte sur trois variables : la vitesse d’itération dont vous avez besoin maintenant, le niveau de contrôle que vous devez garder sur le produit, et la capitalisation de la connaissance — ce qui reste dans l’entreprise quand le prestataire s’en va.

Une agence vous donne de la vitesse au démarrage mais capitalise peu : la connaissance du produit, des choix d’architecture, des raccourcis pris, tout cela vit chez elle. Un CTO salarié capitalise tout mais met du temps à recruter et coûte cher en cash. Un freelance senior se situe entre les deux, avec un risque de disponibilité et de bus factor à un. Aucune option n’est bonne dans l’absolu — elles sont bonnes ou mauvaises selon votre stade.

Pre-seed : vous cherchez la validation, pas l’excellence technique

Avant d’avoir validé que quelqu’un veut payer pour votre produit, votre priorité n’est pas de construire une architecture propre. Elle est d’apprendre le plus vite possible avec le moins d’argent possible. À ce stade, le no-code et le low-code battent souvent une agence, et une agence bat souvent un recrutement.

Recruter un CTO salarié en pre-seed pour un produit non validé, c’est immobiliser votre poste de dépense le plus lourd sur un pari que vous n’avez pas encore gagné. Si vous pivotez — et statistiquement, vous pivoterez — vous vous retrouvez avec un salaire à porter et un périmètre technique qui ne correspond plus.

Le piège symétrique existe : le fondateur non-technique qui signe un forfait de 40 000 € avec une agence pour « le vrai produit » avant d’avoir une seule preuve de traction. Il transforme des hypothèses non validées en spécifications figées, puis paie pour construire quelque chose que le marché ne veut pas. Le forfait est l’ennemi de l’apprentissage : il récompense la livraison conforme au cahier des charges, pas la découverte de ce qui marche.

Si vous devez externaliser en pre-seed, faites-le en régie légère et par sprints courts, sur un périmètre que vous pouvez remettre en cause chaque semaine. Et gardez une règle : ne payez jamais pour construire ce que vous n’avez pas encore essayé de vendre.

Seed : le moment où la propriété du produit devient stratégique

C’est ici que la plupart des erreurs coûteuses se paient. Vous avez de la traction, vous levez, et vous devez décider comment vous construisez pour les dix-huit prochains mois. Deux réalités changent tout par rapport au pre-seed.

D’abord, la due diligence technique devient réelle. Un investisseur seed sérieux voudra comprendre qui écrit le code, où il vit, sous quelle licence, et si vous pouvez continuer à avancer sans dépendre d’un tiers. Un produit entièrement externalisé, sans compétence technique en interne, est un signal de risque. Ce n’est pas rédhibitoire, mais ça pèse sur la valorisation et sur les clauses.

Ensuite, la vitesse d’itération devient un avantage compétitif. En seed, vous n’itérez plus sur un prototype, vous itérez sur un produit que des clients utilisent. Chaque aller-retour avec une agence — ticket, devis, planning, validation — ajoute des jours de latence entre une décision produit et sa mise en production. Cette latence, invisible sur une facture, tue les startups qui affrontent des concurrents plus rapides.

À ce stade, le modèle qui fonctionne le mieux est souvent hybride et transitoire : un premier lead technique en interne — CTO ou lead dev salarié — qui possède l’architecture et les décisions, éventuellement épaulé par des freelances ou une agence sur des chantiers périphériques. La ligne rouge est claire : le cœur du produit et les décisions d’architecture restent dans l’entreprise. Le reste peut se sous-traiter.

Un mot sur le CTO cofondateur en equity. C’est un excellent choix quand la technologie est le produit — un enjeu d’infrastructure, de performance, d’IA, de complexité algorithmique. C’est un choix plus discutable quand la technologie n’est qu’un moyen et que votre différenciation est ailleurs (distribution, marque, opérations). Donner 20 % de capital pour une compétence que vous auriez pu acheter en salaire est une décision qu’on ne peut pas défaire.

Série A : vous n’externalisez plus le cœur, vous industrialisez

Arrivé en série A, la question n’est plus « externaliser ou internaliser » mais « comment scaler une équipe interne sans exploser mes coûts et ma qualité ». À ce stade, une dépendance forte à l’externe sur le cœur produit devient un plafond de verre : vous ne pouvez pas construire une culture d’ingénierie, une vélocité durable et une rétention des connaissances sur une base de prestataires interchangeables.

L’externalisation garde toute sa place — mais elle se déplace vers les marges : chantiers ponctuels, expertises rares mobilisées temporairement (sécurité, data, mobile), pics de charge. Le nearshore et le staff augmentation redeviennent pertinents une fois que vous avez une équipe interne assez mûre pour encadrer, revoir le code et intégrer ce qui est produit. Externaliser sans capacité interne d’intégration, c’est acheter de la dette technique à crédit.

Ce qu’il faut vraiment décider

Avant de choisir un modèle, posez-vous quatre questions dans l’ordre.

La technologie est-elle votre différenciation, ou un moyen ? Si c’est votre différenciation, internalisez tôt, quitte à payer en equity. Sinon, achetez la compétence en salaire ou en prestation et gardez votre capital.

Avez-vous validé ce que vous construisez ? Si non, restez léger, réversible, low-code ou régie courte. Ne figez rien dans un forfait.

Qui possédera le code, les comptes cloud, les noms de domaine et les accès dans six mois ? Si la réponse est « le prestataire », vous avez un problème de valorisation qui vous rattrapera en due diligence. Exigez que tout — dépôts de code, infrastructure, propriété intellectuelle — soit à votre nom dès le premier jour, quel que soit le modèle.

Quelle latence de décision pouvez-vous vous permettre ? Plus votre marché bouge vite, plus la vitesse d’itération justifie d’internaliser au moins le lead technique.

Un principe simple traverse ces quatre questions : externalisez l’exécution, jamais les décisions. Vous pouvez sous-traiter des mains, jamais l’architecture, la roadmap technique et la propriété de ce que vous construisez.

En pratique

La bonne réponse n’est presque jamais binaire ni définitive. Elle évolue avec le stade : no-code puis régie légère en pre-seed, premier lead technique interne épaulé d’externes en seed, équipe interne encadrant des renforts ponctuels en série A. Ce qui doit rester constant, c’est le contrôle : sur le code, sur l’infrastructure, sur les décisions.

La question à vous poser n’est donc pas « combien coûte un développeur ». C’est : dans dix-huit mois, quand un investisseur ou un acquéreur examinera votre produit, verra-t-il un actif que vous possédez et maîtrisez — ou une dépendance que vous avez louée ?