CTO, freelance ou agence : qui doit coder votre produit au démarrage (et quand changer d’avis)
Un fondateur non-tech nous a appelés la semaine dernière, paniqué. Son agence venait de livrer un MVP « fini », sauf qu’il ne pouvait rien y modifier sans repayer un devis, le code était illisible, et son premier client demandait une fonctionnalité que personne dans son équipe ne savait implémenter. Il avait dépensé 60 000 € et se retrouvait propriétaire d’une boîte noire.
Ce scénario n’est pas un accident isolé. C’est la conséquence directe d’une décision prise sans cadre clair au tout début : à qui confier la construction du produit ? La réponse par défaut — « je trouve un CTO », « je prends une agence », « je bricole avec un freelance » — est presque toujours prise pour de mauvaises raisons, et rarement réévaluée quand le contexte change.
Le vrai critère n’est pas le coût, c’est qui détient la connaissance critique
La plupart des fondateurs comparent ces trois options sur le prix et le délai. C’est une erreur de cadrage. Au démarrage, votre produit n’a aucune valeur en lui-même : il sera réécrit, jeté, pivoté. Ce qui a de la valeur, c’est la connaissance du problème client encodée dans les décisions techniques — pourquoi telle table de base de données est structurée ainsi, pourquoi tel parcours a été simplifié, quels compromis ont été faits.
Quand cette connaissance vit dans la tête d’un prestataire externe, vous êtes locataire de votre propre produit. Quand elle vit dans votre équipe, vous êtes propriétaire. La vraie question à se poser n’est donc pas « combien ça coûte » mais « où va se loger l’apprentissage, et est-ce que je peux me permettre de le perdre ? »
À pre-seed, avant d’avoir validé votre ICP, la connaissance critique est encore l’hypothèse de marché — elle change toutes les deux semaines. À ce stade, garder un coût bas et une vitesse maximale prime sur la propriété du code. Une fois le product-market fit en vue, la donne s’inverse brutalement : chaque décision technique commence à porter la connaissance accumulée sur des clients réels, et l’externaliser devient un risque existentiel.
L’agence : excellente pour valider, dangereuse pour construire
Une agence vous vend de la prévisibilité : un périmètre, un prix, une date. C’est précisément ce qui la rend adaptée à un moment très précis — la validation rapide d’une hypothèse via un prototype jetable — et inadaptée à tout le reste.
Le problème structurel d’une agence n’est pas la qualité (les bonnes agences existent), c’est l’alignement d’incitations. Une agence est payée pour livrer un périmètre, pas pour faire réussir votre startup. Elle optimise pour fermer le ticket, pas pour la maintenabilité dans dix-huit mois. Et son modèle économique repose sur l’enchaînement de projets : elle n’a aucun intérêt à ce que vous deveniez autonome.
Concrètement, une agence a du sens si vous avez besoin d’un prototype cliquable pour décrocher un premier client ou convaincre un business angel, et que vous savez déjà que ce code finira à la poubelle. Elle devient un piège dès l’instant où vous commencez à empiler des fonctionnalités dessus, à construire votre roadmap autour, à signer des clients qui dépendent de sa stabilité. Le jour où vous voulez internaliser, vous découvrez le coût caché : la reprise d’un code que personne dans votre équipe n’a écrit prend souvent plus de temps que de tout réécrire.
Si vous passez par une agence, négociez deux choses dès le départ : la propriété pleine et entière du code source dans un dépôt que vous contrôlez, et une documentation minimale des choix d’architecture. Sans ça, vous achetez une dette, pas un actif.
Le freelance : le bon compromis sous-estimé — à condition de cadrer la sortie
Le freelance senior est l’option la plus mal comprise. Bien choisi, il combine le meilleur des deux mondes : la flexibilité d’un prestataire, mais avec une vraie implication individuelle et un coût bien inférieur à celui d’une agence à compétence égale. Un bon freelance fullstack vous construit un MVP propre et maintenable, et peut même rester en accompagnement pendant que vous structurez l’équipe.
Le risque n’est pas la compétence, c’est la continuité. Un freelance peut disparaître du jour au lendemain — meilleur client, burn-out, désaccord. Si tout le produit repose sur lui, vous reproduisez le problème de l’agence avec un seul point de défaillance humain.
La parade tient en trois exigences non négociables, dès le premier jour : le code vit dans votre dépôt, pas le sien ; les choix techniques sont documentés au fil de l’eau, même sommairement ; et vous, fondateur, vous imposez de comprendre l’architecture dans ses grandes lignes, même non-tech. Pas pour coder, mais pour pouvoir poser les bonnes questions et reprendre la main si besoin.
Pour une startup pre-seed à seed avec un runway serré, un freelance senior associé à un outil no-code pour les parties non différenciantes est souvent l’arbitrage le plus rationnel. Vous payez la complexité technique là où elle crée de la valeur, et vous évitez de réinventer ce qui existe déjà.
Le CTO associé : pas une ressource technique, un pari de long terme
Recruter un CTO associé n’est pas la version « premium » du freelance. C’est une décision d’une nature complètement différente, qui se paie en equity — la ressource la plus chère et la plus irréversible de votre cap table.
L’erreur classique consiste à donner 20 à 30 % du capital à un développeur talentueux pour qu’il code le MVP, en confondant « savoir coder maintenant » et « savoir diriger la technologie pendant cinq ans ». Ce sont deux métiers. Le premier MVP demande un excellent exécutant. Une startup en croissance demande quelqu’un capable de recruter une équipe, d’arbitrer la dette technique, de dialoguer avec les investisseurs sur la scalabilité. Beaucoup de fondateurs se retrouvent à série A avec un « CTO » qui était parfait pour bricoler le prototype mais incapable de structurer une équipe de huit personnes — et une part de capital désormais impossible à récupérer sereinement.
Un CTO associé se justifie quand la technologie est le cœur de la défensibilité du produit — un moteur d’IA propriétaire, une infrastructure temps réel complexe, un avantage algorithmique. Si votre différenciation est sur le marché, la distribution ou l’expérience utilisateur, vous n’avez probablement pas besoin d’un cofondateur tech à l’équity au démarrage : vous avez besoin d’un excellent exécutant que vous internaliserez plus tard.
Avant d’engager de l’equity, instaurez une période d’essai réelle — quelques mois de collaboration sur un livrable concret, idéalement rémunérée plutôt qu’au capital. Le vesting avec cliff d’un an est un minimum, mais il ne remplace pas le test grandeur nature de travailler ensemble sous pression.
Ce qu’il faut vraiment faire, selon votre stade
À pre-seed, votre seul objectif est d’apprendre vite et de dépenser peu. Privilégiez le no-code, un freelance ponctuel, ou une agence uniquement pour un prototype jetable. Ne donnez pas d’equity pour du code à ce stade : vous ne savez pas encore quel produit vous construisez vraiment.
À seed, une fois l’ICP en vue, commencez à internaliser la connaissance critique. Un premier développeur salarié ou un freelance en mission longue qui documente et transmet vaut mieux qu’une agence qui livre et disparaît. C’est aussi le moment où la question du CTO devient légitime — mais seulement si la tech est votre vrai moat.
À l’approche de la série A, vous devez avoir une équipe tech interne capable de soutenir la roadmap sans dépendance externe sur le cœur de produit. Les investisseurs regarderont précisément cela : qui détient la connaissance, et que se passe-t-il si cette personne part.
Le fil rouge est toujours le même : faites correspondre l’irréversibilité de votre engagement (cash flexible < freelance < salarié < equity) à la maturité de votre connaissance du marché. Engager de l’equity sur une hypothèse non validée, c’est payer le prix fort pour une certitude que vous n’avez pas encore.
En résumé
Il n’existe pas de bonne réponse universelle, seulement une bonne réponse pour un stade donné — et le tort le plus fréquent n’est pas de mal choisir au départ, mais de ne jamais réévaluer. L’agence qui convenait au prototype devient un boulet à seed. Le freelance parfait au démarrage doit céder la place à une équipe interne avant la série A.
Posez-vous régulièrement une seule question : si la personne qui détient aujourd’hui la connaissance critique de mon produit disparaissait demain, combien de temps me faudrait-il pour reprendre la main ? Si la réponse vous fait peur, c’est qu’il est déjà temps de changer de modèle.