CTO externalisé ou CTO associé : ce qu'un founder non technique achète réellement
Les offres de CTO externalisé se ressemblent toutes : deux à quatre jours par semaine, trois à douze mois. Ces chiffres décrivent une facture, pas un périmètre. Voici les cinq rôles que le mot « CTO » recouvre, ce que chacun coûte, et les quatre situations où externaliser est le mauvais achat.
title: "CTO externalisé ou CTO associé : ce qu'un founder non technique achète réellement" seoTitle: "CTO externalisé ou associé : que paie-t-on ?" description: "Les offres de CTO externalisé se ressemblent toutes : deux à quatre jours par semaine, trois à douze mois. Ces chiffres décrivent une facture, pas un périmètre. Voici les cinq rôles que le mot « CTO » recouvre, ce que chacun coûte, et les quatre situations où externaliser est le mauvais achat." seoDescription: "CTO externalisé, associé, salarié ou tech lead : ce que chaque rôle couvre réellement, combien il coûte par mois, et quand externaliser est une erreur." date: "2026-10-06" author: "Équipe Raicode" tags: ["mvp", "saas", "gestion de projet", "freelance"] category: "SaaS & MVP" keywords: ["CTO externalisé", "CTO associé", "CTO as a service", "CTO à temps partagé", "recruter un CTO", "directeur technique externalisé", "founder non technique", "CTO freelance startup", "coût CTO externalisé"]
Le MVP est livré, le prestataire a facturé son solde, et les premiers utilisateurs remontent des choses que personne ne sait arbitrer. Faut-il corriger le bug d'export ou sortir la fonctionnalité promise au prospect de la semaine prochaine ? Le développeur freelance que vous avez gardé deux jours par mois répond qu'il fait ce qu'on lui demande. Vous êtes founder, vous ne codez pas, et vous venez de découvrir que la livraison d'un produit ne règle pas la question de savoir qui tient la roadmap technique ensuite.
Alors vous cherchez « CTO externalisé » et vous recevez cinq propositions qui disent toutes la même chose : deux à quatre jours par semaine, trois à douze mois d'engagement, un tarif journalier. Ces chiffres sont exacts — c'est la fourchette réelle du marché français — mais ils décrivent une facture, pas un périmètre. Deux prestataires au même tarif peuvent vous vendre deux métiers qui n'ont rien à voir, et l'écart ne se voit qu'au quatrième mois, quand vous constatez que celui que vous avez pris ne fait pas ce dont vous aviez besoin.
Le mot « CTO » recouvre cinq métiers différents
Avant de comparer des prix, il faut savoir ce qu'on compare. Dans les propositions que reçoit un founder non technique, cinq rôles distincts se présentent sous le même titre.
| Rôle | Ce qu'il décide | Ce qu'il ne fait pas | Rémunération type | | --- | --- | --- | --- | | CTO associé | Tout le technique, et il en porte le risque | Il ne part pas si ça se passe mal | Capital, 5 à 20 %, salaire différé ou nul | | CTO salarié | Stack, recrutement, roadmap technique | Rarement du code au quotidien passé 10 personnes | 85 à 130 k€ brut, plus BSPCE | | CTO externalisé (temps partagé) | Architecture, arbitrages, qualité de ce que livrent les autres | Il ne produit pas le volume de code attendu | 700 à 1 200 € par jour | | Tech lead ou lead dev | Comment c'est construit, dans le cadre déjà posé | Il n'arbitre pas le budget ni le build/buy | 500 à 750 € par jour | | Consultant technique | Rien, il recommande | Il ne tient pas la décision dans la durée | 1 000 à 2 000 € par jour, sur quelques jours |
La confusion la plus fréquente se joue entre les lignes trois et quatre. Un founder qui dit « j'ai besoin d'un CTO » veut en général dire « j'ai besoin que quelqu'un décide à ma place sur le technique et réponde de ce qui sort ». Mais ce qu'il achète souvent, c'est un très bon développeur senior facturé au tarif d'un CTO, qui attend qu'on lui dise quoi construire. Les deux sont utiles. Ils ne résolvent pas le même problème, et surtout, ils ne se remplacent pas : mettre un lead dev sur un arbitrage de build/buy produit systématiquement du build.
La deuxième confusion porte sur le CTO associé. Ce n'est pas une version moins chère des autres, c'est une transaction d'une nature différente. Vous ne payez pas un temps de travail, vous cédez une part du produit en échange d'un engagement dans la durée et d'un risque partagé. Un associé ne s'achète pas en trois semaines, ne se résilie pas avec un préavis d'un mois, et ne se négocie pas sur un tarif journalier. Si vous cherchez quelqu'un qui portera le produit pendant cinq ans, aucun contrat de prestation ne vous le donnera, quel que soit le nombre de jours.
Ce que vous achetez réellement : des décisions, pas des jours
Un contrat de CTO externalisé se vend en jours parce que c'est mesurable. Mais ce qui détermine la valeur de la mission, ce sont quatre ou cinq décisions qui, chacune, engagent douze à vingt-quatre mois de développement.
L'arbitrage build ou buy. Pour chaque brique — authentification, facturation, recherche, envoi d'e-mails, génération de documents — quelqu'un doit décider si on l'achète ou si on la construit. Un founder non technique se fait toujours avoir dans le même sens : il accepte de construire ce qu'il aurait fallu acheter, parce que la personne en face est payée pour construire. Une seule décision de ce type mal prise coûte entre trois semaines et deux mois de développement, et se paie ensuite en maintenance à chaque montée de version.
Le périmètre de ce qui est repris et de ce qui est jeté. Quand il existe déjà du code — un MVP livré par une agence, un prototype interne, un assemblage no-code arrivé au bout de ses limites — la première décision est de savoir ce qu'on garde. C'est exactement le genre d'arbitrage que nous menons dans nos missions de développement de MVP et de SaaS, et c'est celui où le coût d'une erreur est le plus asymétrique : reprendre une base irrécupérable coûte deux fois le prix d'une réécriture, et réécrire une base saine fait perdre quatre mois pour rien.
Ce qu'on accepte comme dette. Un produit jeune doit accumuler de la dette technique volontairement, et un bon CTO sait laquelle. Le sujet mérite sa propre discussion — nous l'avons traité en détail dans ce qu'on accepte et ce qu'on refuse comme dette technique sur un MVP — mais le point important ici est que cette décision ne peut pas être prise par la personne qui écrit le code, parce qu'elle en subit seule les conséquences au quotidien et optimisera naturellement son confort.
Qui code, et sous quel contrôle. Recruter un développeur, choisir une agence, encadrer un freelance : un founder non technique n'a aucun moyen d'évaluer seul la qualité d'une candidature ou d'une proposition. C'est souvent le seul poste qui justifie à lui seul la dépense. Le jour où votre CTO externalisé écarte un prestataire à 60 k€ que vous étiez sur le point de signer, il a remboursé six mois de mission.
Si une mission ne couvre aucune de ces quatre décisions, ce n'est pas une mission de CTO. C'est de la production, et elle doit être payée au tarif de la production.
Les deux chiffres du marché, et ce qu'ils cachent
Les offres convergent sur « deux à quatre jours par semaine » et « trois à douze mois ». Ces fourchettes ne sont pas fausses, mais elles mélangent deux régimes très différents, et c'est ce mélange qui produit les mauvaises surprises.
Le régime de construction. Vous bâtissez le produit, vous recrutez, vous mettez en place l'infrastructure et les processus. Sur cette phase, en dessous de deux jours par semaine, un CTO externalisé devient un goulet d'étranglement : l'équipe l'attend pour avancer, les décisions s'empilent entre deux passages, et chaque question posée le mardi coûte six jours d'attente. Trois jours par semaine est le minimum honnête pour une phase de construction avec deux ou trois développeurs. À 900 € par jour, cela représente environ 11 700 € par mois.
Le régime de pilotage. Le produit tourne, l'équipe est en place et sait travailler, les décisions structurantes sont prises. Un jour par semaine, parfois un jour tous les quinze jours, suffit à tenir la revue d'architecture, les arbitrages de roadmap et le contrôle de ce qui est livré. Soit 1 800 à 3 900 € par mois.
Le piège est de signer un engagement de douze mois sur le régime de construction. Vous payez douze mois à 11 700 € — 140 000 € — pour un besoin qui s'effondre naturellement au bout de quatre ou cinq mois, quand l'équipe devient autonome. Comparé à un CTO salarié à 110 k€ brut, soit environ 13 000 € chargés par mois, l'externalisation n'a plus aucun avantage de coût. Elle n'en a jamais eu sur la durée : son avantage est de démarrer en deux semaines au lieu de quatre à six mois de recrutement, et d'être réversible.
La bonne structure contractuelle découle de là : un engagement court et dense, puis une décroissance explicite. Trois à quatre mois à trois jours par semaine, puis un passage automatique à un jour par semaine, écrit dans le contrat dès la signature, avec la révision du rythme comme clause prévue et non comme négociation à mener. Un prestataire qui refuse la clause de décroissance vous dit quelque chose d'utile sur ce qu'il vend.
Les quatre situations où externaliser est le mauvais achat
Vous n'avez pas encore de produit, et le technique est le produit. Si votre différenciation est technique — un moteur, un modèle, une performance que les autres n'atteignent pas — ce savoir-faire ne peut pas être loué. Il doit s'accumuler chez quelqu'un qui reste. Cherchez un associé, acceptez de diluer, et prenez les six mois que cela demande.
Vous cherchez en réalité quelqu'un qui code. C'est le cas le plus fréquent et le plus coûteux. Vous avez besoin de trois cents heures de développement, pas de quinze décisions. Prenez un développeur senior, ou une agence, et gardez quelques jours de consultant pour cadrer et pour relire. Le budget est divisé par deux et le produit avance plus vite.
Vous levez des fonds dans les six mois. Les investisseurs regardent la composition de l'équipe fondatrice, et un CTO facturé à la journée ne compte pas comme une équipe technique. Ce n'est ni juste ni injuste, c'est une contrainte du marché du financement, et elle se prépare avant le premier rendez-vous, pas pendant la due diligence.
Vous n'êtes pas prêt à être contredit. Un CTO externalisé dont toutes les recommandations sont acceptées est un mauvais signe, et un CTO dont aucune n'est suivie est une dépense pure. Si vous avez déjà décidé de la stack, du calendrier et du périmètre, vous ne cherchez pas un décideur technique mais un exécutant, et c'est une autre fiche de poste.
Ce qu'on écrit dans le contrat
Les propositions de CTO externalisé sont souvent rédigées en termes d'intentions : accompagnement, vision technique, pilotage. Rien de tout cela ne se vérifie. Quatre clauses rendent la mission contrôlable par un founder qui ne code pas.
Des livrables datés. Un document d'architecture à la fin du premier mois, un plan de recrutement si le recrutement fait partie du périmètre, un état mensuel de la dette et des risques. Trois documents courts qui existent ou n'existent pas, et qu'un tiers peut relire.
Tous les accès à votre nom. Le dépôt de code, le cloud, le nom de domaine, les clés d'API, le fournisseur de modèles si vous en utilisez un : les comptes sont ouverts avec votre adresse et votre carte, le prestataire y est invité. C'est la vérification qui coûte le moins cher et celle qu'on regrette le plus de ne pas avoir faite. Les autres signaux à surveiller chez un prestataire technique sont détaillés dans notre grille de questions pour choisir une agence MVP ou SaaS, et la plupart s'appliquent telles quelles à un CTO externalisé.
Un délai de réponse, pas une astreinte. Vous n'achetez pas une permanence de nuit, mais vous avez besoin de savoir en combien de temps quelqu'un répond quand la production tombe un vendredi soir. Quatre heures ouvrées sur un incident bloquant est une demande raisonnable ; vingt-quatre heures est acceptable si c'est écrit et assumé.
Une sortie préparée. Préavis d'un mois des deux côtés, passation documentée, et surtout : l'obligation que chaque décision structurante soit écrite quelque part d'autre que dans la tête du prestataire. Un CTO externalisé qui part en emportant le modèle mental du système vous laisse dans la même situation qu'au départ, avec six mois et 50 000 € de moins. La même logique vaut à la réception de chaque livraison, et nous l'avons détaillée dans le cahier de recette qui protège le founder.
Se situer en trois questions
Avant de répondre à la première proposition, trois questions tranchent la typologie plus vite qu'un comparatif.
Combien de décisions techniques structurantes restent à prendre dans les six prochains mois ? Si la réponse est « moins de cinq », vous n'avez pas besoin d'un CTO en continu : prenez un consultant sur quelques jours, puis un tech lead pour exécuter.
Est-ce que je saurai, dans un an, si cette personne a bien travaillé ? Si la seule réponse possible est « le produit marchera ou pas », le contrat est sous-spécifié. Les livrables datés existent pour cela.
Qu'est-ce qui se passe si elle part dans trois mois ? Si la réponse est « tout s'arrête », vous ne cherchez pas un prestataire mais un associé, et il faut en payer le prix réel, qui est du capital.
Votre prochaine action, si vous avez des propositions sur le bureau : reprenez chacune d'elles et classez-la dans l'une des cinq lignes du tableau du début, en vous appuyant sur ce qu'elle décide et non sur son titre. Il y a de bonnes chances que deux des cinq soient en réalité des offres de production facturées au tarif d'un décideur — et c'est la comparaison la plus rentable que vous ferez cette semaine.
Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.
Un MVP à sortir ? Cadrons-le ensemble.
Périmètre tranché en une semaine, sprints hebdomadaires démontrables, mise en production avec paiement et authentification. Devis ferme après cadrage.
Articles similaires
Le document qui fait chiffrer un MVP : ce qu'un prestataire lit pour s'engager sur un prix
Recevoir le MVP livré par un prestataire : le cahier de recette qui protège le founder, et ce qu'on ne signe pas
