Je tiens le rôle de CTO externalisé de Vinyles.com, un comparateur de prix de vinyles construit sur Shopify, sans être salarié de l'entreprise. Ce montage répond à une question que se posent beaucoup de dirigeants de PME : faut-il recruter un directeur technique à plein temps, ou confier ce rôle à quelqu'un de l'extérieur, quelques jours par mois ? La réponse dépend moins du prestige du titre que de trois choses : ce que la technique représente dans votre activité, l'équipe à encadrer, et la charge fixe que vous pouvez porter.
Je suis développeur indépendant à Morlaix, dans le numérique depuis 2012. Ce guide compare les deux options sans chiffres invérifiables : quand le recrutement interne s'impose, quand un CTO à temps partagé suffit, les critères pour trancher, les risques de chacun (dont la propriété du code), et la façon de passer de l'un à l'autre.
En bref
- Un CTO interne se justifie quand la technique est le produit, qu'une équipe de développeurs existe ou va exister, et que le budget de salaire tient sans dépendre des premières recettes.
- Un CTO externalisé à temps partagé convient quand il faut décider, cadrer et faire tourner des outils numériques sans équipe technique interne.
- Le code écrit par un salarié dans ses fonctions revient à l'employeur pour les droits patrimoniaux (article L113-9 du Code de la propriété intellectuelle) ; celui d'un prestataire reste à son auteur tant qu'une cession écrite ne le transfère pas.
- Les deux options se suivent bien : commencer à l'extérieur, puis recruter, à condition que code, comptes et documentation soient à votre nom dès le premier jour.
Dans une PME, le CTO, ou directeur technique, choisit entre un logiciel du marché et un développement, cadre les prestataires, surveille la sécurité et les sauvegardes, prévoit la maintenance. Un bon développeur n'est pas forcément un bon CTO : le premier livre du code, le second arbitre et écrit ses choix pour la direction. Et ce rôle peut exister sans poste à plein temps.
Quand recruter un CTO interne
Le recrutement interne s'impose quand la technologie fait la valeur de l'entreprise et qu'il faut quelqu'un de présent chaque jour pour la faire avancer. Les situations typiques :
- Votre produit est un logiciel : un SaaS, une plateforme, un algorithme qui vous distingue. La connaissance du code et des choix passés doit rester dans l'entreprise.
- Une équipe technique existe ou se construit : plusieurs développeurs à recruter, à encadrer, à faire progresser. Ce management demande une présence continue.
- Le rythme des mises en production est soutenu : incidents, évolutions fréquentes, clients qui attendent une réponse technique rapide.
- Des investisseurs entrent au capital : ils regardent qui porte la technique et s'il restera.
- Le budget tient : un salaire de cadre et ses charges, engagés avant d'avoir la certitude des recettes.
Le salariat règle aussi une question juridique. Sauf clause contraire, les droits patrimoniaux sur les logiciels et leur documentation créés par un employé dans l'exercice de ses fonctions, ou d'après les instructions de son employeur, sont dévolus à l'employeur (article L113-9). Si votre CTO est mandataire social sans contrat de travail, ce texte ne s'applique pas tel quel : faites trancher le point par un avocat.
Quand un CTO externalisé à temps partagé suffit
Un CTO externalisé intervient quelques jours par mois, ou sur un périmètre défini, pour plusieurs entreprises. Il convient quand la technique sert votre métier sans en être le cœur, et quand personne en interne ne peut prendre les décisions techniques.
- Vous n'avez pas d'équipe technique : recruter un CTO sans développeurs à encadrer revient à payer un manager qui passera son temps à coder seul, ou à chercher des prestataires.
- Le besoin est surtout de décider et de cadrer : choisir un outil, lancer une application métier, reprendre un site, piloter un prestataire.
- Vous voulez démarrer sans charge fixe : un contrat de prestation se dimensionne et se résilie selon ses termes, un CDI engage autrement.
- Vous voulez un regard qui a vu d'autres projets : une personne qui travaille pour plusieurs clients croise plus de situations techniques qu'un salarié dans une seule entreprise.
La limite est la disponibilité. Un CTO à temps partagé n'est pas là tous les jours ; s'il faut une réponse dans l'heure à chaque incident, il faut le prévoir au contrat ou choisir l'autre option.
Les deux options comparées
Le tableau ci-dessous compare les deux formules sur ce qui compte pour une PME. Il ne donne volontairement ni salaire ni tarif : aucune source publique fiable ne publie ces montants pour la fonction CTO, et ils varient avec le périmètre.
| Critère | CTO interne | CTO externalisé |
|---|---|---|
| Nature de la dépense | Salaire et charges, dépense fixe | Honoraires, ajustables au périmètre |
| Mise en route | Recrutement de cadre : annonce, entretiens, préavis du candidat | Contrat de prestation, démarrage plus rapide en général |
| Disponibilité | Quotidienne | Planifiée, selon le contrat |
| Droits sur le code | Droits patrimoniaux à l'employeur (L113-9), sauf clause contraire | À l'auteur tant qu'une cession écrite ne les transfère pas |
| Management d'équipe | Oui, c'est son rôle | Limité, plutôt pilotage de prestataires |
| Risque principal | Départ avec la mémoire du projet | Dépendance si rien n'est documenté ni à votre nom |
Six critères pour trancher
Répondez à ces questions par écrit avant de publier une annonce ou de signer un contrat. Aucune ne suffit seule ; c'est leur combinaison qui oriente.
- La technique est-elle votre produit ? Si vous vendez un logiciel, la réponse penche vers l'interne. Si le logiciel sert à mieux vendre autre chose, l'externe suffit longtemps.
- Qui le CTO va-t-il encadrer ? Sans développeur en interne ni recrutement prévu, un poste à plein temps aura peu de leviers.
- Quelle disponibilité exigez-vous ? Décrivez un incident type et le délai de réponse attendu.
- Pouvez-vous porter une charge fixe ? Un salaire de cadre se paie chaque mois, que le projet avance ou non.
- Savez-vous évaluer un profil technique ? Si ce n'est pas le cas, un recrutement mal choisi coûte cher à corriger ; une mission externe courte permet de tester avant de s'engager.
- Où en est le projet ? Une idée ou une première version se cadre bien de l'extérieur ; un produit qui a des clients et une équipe demande une présence continue.
Si la plupart des réponses décrivent un produit logiciel avec une équipe, recrutez. Si elles décrivent une entreprise dont le métier est ailleurs et qui a besoin de décisions techniques fiables, commencez à l'extérieur.
Les risques de chaque option et comment les réduire
CTO interne : la mémoire qui part avec la personne
Un CTO salarié qui quitte l'entreprise emporte ce qu'il n'a pas écrit : pourquoi tel choix a été fait, où sont les accès, ce qui casse quand on touche à tel module. Le remède est le même que pour un prestataire : documentation tenue à jour, comptes au nom de l'entreprise, au moins une deuxième personne qui connaît l'architecture. Pensez aussi à la clause sur les droits : L113-9 couvre le logiciel et sa documentation, pas forcément d'autres créations (maquettes graphiques, textes), qui méritent une mention dans le contrat de travail.
CTO externalisé : dépendance et droits d'auteur
Le risque est de se retrouver lié à une seule personne qui détient les accès et la connaissance. Exigez dès le départ que le domaine, l'hébergement, le dépôt de code et les comptes de paiement soient à votre nom, que chaque décision technique soit écrite, et que la passation soit prévue au contrat.
Côté droits, payer un développement ne vous en transfère pas la propriété intellectuelle. L'auteur jouit de ses droits du seul fait de la création, et un contrat de prestation n'y déroge pas (article L111-1). Il faut une cession écrite. Si vous signez avec l'auteur lui-même, un indépendant qui code seul par exemple, l'article L131-3 impose que chaque droit cédé soit mentionné distinctement, avec son étendue, sa destination, son lieu et sa durée. Avec une agence qui cède le code écrit par ses salariés, ce formalisme n'est pas exigé par la loi, mais c'est la rédaction la plus sûre. Ajoutez un accord de confidentialité si votre activité l'exige.
Un rôle de CTO externalisé en pratique : Vinyles.com
Vinyles.com est un comparateur de prix de disques vinyles construit sur Shopify, pour lequel je tiens le rôle de CTO externalisé. Le site ne vend rien : chaque fiche affiche les prix de plusieurs revendeurs et renvoie vers eux. Le périmètre va au-delà du site : référencement Shopify (structure, balisage, vitesse, contenus), refonte visuelle de nombreux modules du thème, optimisation pour les États-Unis, et un serveur géré à côté de Shopify qui fait tourner de nombreuses tâches planifiées : scraping, récupération des prix, nettoyage et vérification des données.
La Search Console de Google montre un site passé d'environ 300 à environ 700 clics par jour entre mars et septembre 2026, avec 18 168 clics et 635 000 impressions sur les 28 jours du 18 août au 15 septembre 2026 ; les États-Unis sont le deuxième pays par nombre de clics, après la France. Ces chiffres mesurent l'activité de l'ensemble du site, pas l'effet d'une action isolée. La fiche du projet Vinyles.com détaille le périmètre.
Ce cas illustre le profil type de l'externalisation : une entreprise dont la valeur est dans le catalogue et le commerce, qui a besoin de décisions et d'outils techniques solides sans équipe de développeurs en interne.
Passer du CTO externalisé au CTO interne
Commencer avec un CTO externalisé puis recruter est une trajectoire courante, et elle se prépare dès le premier contrat. Quatre précautions la rendent simple :
- Tout à votre nom : domaine, hébergement, dépôt de code, comptes de paiement et d'e-mail, avec des accès administrateur que vous gardez.
- Des technologies standard, documentées publiquement, plutôt qu'un outil maison que seul le prestataire maîtrise. Un futur CTO recrutera plus facilement des développeurs sur une pile connue.
- Une documentation vivante : architecture, choix et raisons, procédures de mise en production et de restauration des sauvegardes.
- Une période de recouvrement prévue au contrat : le CTO externe présente le projet à son successeur, répond à ses questions, puis s'efface ou reste en appui sur un périmètre réduit.
Le CTO externalisé peut aussi aider au recrutement : rédiger la fiche de poste, préparer un exercice technique, participer aux entretiens. C'est souvent là que son regard extérieur sert le plus à un dirigeant qui ne code pas.
Sur les projets d'applications métier et de SaaS, je travaille avec un cadrage gratuit, une maquette cliquable validée avant d'écrire le code, puis 4 à 12 semaines de développement pour une première version, sur des technologies standard (Next.js, PostgreSQL via Supabase, Stripe) ; le code et les données vous appartiennent. Les pages applications métier sur mesure et micro-SaaS et MVP décrivent la démarche. Pour parler de votre situation, écrivez-moi, depuis Morlaix ou en visio.
Questions fréquentes sur le CTO externalisé
Qu'est-ce qu'un CTO externalisé ?
C'est un directeur technique qui n'est pas salarié de l'entreprise. Il intervient en prestataire, quelques jours par mois ou sur un périmètre défini, pour prendre les décisions techniques, cadrer les prestataires, suivre la sécurité et la maintenance des outils numériques.
À qui appartient le code écrit par un CTO externalisé ?
À son auteur, tant qu'une cession écrite ne vous transfère pas les droits : payer la prestation ne suffit pas (article L111-1 du Code de la propriété intellectuelle). Avec l'auteur lui-même, la cession doit lister chaque droit cédé et son domaine d'exploitation (article L131-3). Pour un salarié, les droits patrimoniaux sur le logiciel reviennent à l'employeur (article L113-9).
Un CTO à temps partagé peut-il encadrer une équipe de développeurs ?
Sur une petite équipe et un rythme calme, oui, avec des points réguliers et des règles écrites. Dès que l'équipe grandit ou que les mises en production se multiplient, une présence quotidienne devient nécessaire et le recrutement d'un CTO interne se justifie.
Quand passer d'un CTO externalisé à un recrutement interne ?
Quand la technique devient le produit, quand il faut recruter plusieurs développeurs, ou quand la disponibilité demandée dépasse ce qu'un contrat de prestation peut offrir. Préparez la passation dès le départ : comptes et code à votre nom, documentation, période de recouvrement prévue au contrat.
