Mis à jour le 17 min de lecture
Sébastien Nobour
Fondateur de DEVEDANOS
Vous avez levé des fonds ou obtenu un prêt d’honneur, ou vous êtes en train de le faire ? Votre produit n’existe pas encore, ou seulement sous forme de maquette, et il vous faut quelqu’un pour le construire et prendre les décisions techniques qui engageront votre entreprise pendant des années ? Vous pensez peut-être à recruter un directeur technique, ou CTO, en CDI.
Un CTO salarié construit et décide. Il est payé en salaire plutôt qu’en parts. Ce salaire, vous le versez chaque mois, que votre produit trouve ses clients ou non. Il faut aussi le trouver, puis juger ses compétences sans être technique vous-même. À notre avis, ce recrutement se fait au meilleur moment quand vos premiers utilisateurs se servent déjà de votre produit.
CTO, ou directeur technique, est un poste : celui qui l’occupe dirige la technique de votre produit. Le titre ne dit pas comment il est lié à votre entreprise, ni depuis quand. Au tout début, écrit Fred Wilson, investisseur du fonds américain Union Square Ventures, une startup n’a encore ni CTO ni directeur de l’ingénierie : son cofondateur technique tient les deux rôles.
L’associé technique, ou cofondateur technique, entre au capital et partage votre risque. Il porte souvent le titre de CTO, et trouver un associé technique engage une part de votre entreprise.
Le CTO salarié est lié à votre entreprise par un contrat de travail. Il travaille pour vous seul, contre un salaire versé chaque mois : c’est de lui que parle la suite de cet article.
Le CTO à temps partagé travaille pour plusieurs entreprises. Il prend les décisions techniques, et quelqu’un d’autre construit le produit : c’est l’une des quatre formes du partenaire technique.
Le founding engineer, expression anglaise employée telle quelle en France, est l’un des tout premiers développeurs recrutés. C’est un salarié, à qui l’entreprise attribue souvent une petite part de son capital, et pas un cofondateur.
Le product engineer est un développeur qui répond du produit autant que du code : il parle aux utilisateurs, et participe aux décisions sur ce qui se construit en priorité.
Un développeur indépendant ou une agence peut aussi construire votre produit, sous un contrat commercial. Avant de signer, vérifiez ce que ce contrat doit prévoir.
Au début, un CTO salarié construit le produit lui-même. Il écrit le code, choisit les technologies, décide de ce qui se fait d’abord et de ce qui attendra. Quand l’entreprise grandit, il recrute l’équipe technique et la dirige.
Il travaille pour vous seul, à temps plein. Le logiciel qu’il développe dans le cadre de ses fonctions revient à votre entreprise (article L113-9 du Code de la propriété intellectuelle). Pour un associé ou un prestataire, il faut une cession écrite des droits, l’acte par lequel l’auteur d’un code transmet ses droits sur ce code. Pour un salarié, la loi suffit.
Il ne décide pas seul de ce que votre produit doit faire. Marty Cagan, spécialiste de la gestion de produit et auteur du livre Inspired, distingue quatre risques dans la création d’un produit, et n’en confie qu’un à l’ingénieur : la faisabilité. Savoir si des clients veulent du produit, et s’il convient au reste de l’activité, revient au responsable du produit, et dans une jeune entreprise, c’est souvent vous.
Un CTO ne peut donc pas savoir à votre place si des clients veulent de votre produit. Le cabinet d’études CB Insights a analysé 111 startups qui ont cessé leur activité, dans une étude de 2021 relayée par le site SmartCompany. L’absence de besoin sur le marché figure parmi les causes citées pour 35 % d’entre elles. Avant de recruter, posez la question à vos futurs clients.
Le salaire. L’Association pour l’emploi des cadres (Apec) publie chaque année les salaires des cadres, métier par métier. L’étude présentée par Le Monde Informatique ne donne pas de chiffre propre au directeur technique (CTO). Nous retenons la famille de métiers la plus proche, celle des directions informatiques. En Île-de-France, la moitié de ces cadres a un salaire fixe inférieur à 77 000 € brut par an, l’autre moitié un salaire supérieur : c’est le salaire médian. S’y ajoute une part variable médiane de 7 000 €. En régions, la fourchette publiée va de 46 000 à 96 000 €.
Les cotisations patronales. Elles s’ajoutent au salaire brut. Selon Payfit, éditeur d’un logiciel de paie, elles représentent en moyenne 25 à 42 % du salaire brut, selon l’entreprise et le profil du salarié.
Le recrutement. Si vous passez par un cabinet de recrutement, ses honoraires pour un poste de direction « peuvent dépasser 25-30 % » du salaire annuel brut, d’après le guide des honoraires de Talent Program.
Appliqués aux salaires médians de la direction informatique en Île-de-France, part variable comprise (77 000 € de fixe et 7 000 € de variable), ces taux donnent un coût annuel pour l’employeur de 105 000 à 119 000 €, cotisations comprises, soit 8 750 à 9 900 € par mois. S’y ajoutent des honoraires de recrutement, payés une seule fois, qui peuvent dépasser 25 à 30 % du salaire annuel, soit plus de 19 250 € sur ce salaire fixe. Nous comparons ce coût à celui d’un développeur.
Divisez vos fonds disponibles par ce coût mensuel : vous obtenez le nombre de mois pendant lesquels vous pouvez payer votre CTO avant que votre produit ne rapporte de l’argent.
Dans un article du Journal du Net publié en juin 2026, des fondateurs qui ne sont pas techniques racontent comment ils ont choisi leur CTO. Amélie Schieber, présidente de Tiime, une fintech qui propose une plateforme de comptabilité aux indépendants, a confié à un cabinet de recrutement la recherche de son CTO. Elle a fait évaluer les compétences techniques du candidat que ce cabinet lui avait présenté par le cabinet lui-même, et par les équipes techniques de son entreprise. L’article rappelle aussi qu’un profil qui convient au lancement d’un produit ne convient pas toujours à sa croissance : dites au candidat jusqu’où vous voulez mener votre produit, et demandez-lui ce qu’il a déjà mené à cette taille.
Si vous n’avez personne pour évaluer un candidat, faites-vous aider : par un cabinet de recrutement spécialisé, par un développeur en qui vous avez confiance, ou par un CTO à temps partagé. Et posez au candidat la question que l’on pose à un associé : quel logiciel a-t-il mis en production, puis fait évoluer pendant plusieurs années ?
Les délais pour se séparer. La période d’essai d’un cadre en CDI dure au plus quatre mois. Elle peut être renouvelée une fois, jusqu’à huit mois au total, si un accord de branche étendu le prévoit et que le salarié l’accepte par écrit. Ensuite, le préavis dépend de la convention collective que votre entreprise applique, si elle en applique une. Si votre entreprise applique la convention Syntec, il est de trois mois pour un cadre, qu’il démissionne ou qu’il soit licencié. Avec cette convention, une séparation après la période d’essai prend donc trois mois.
Le coût d’un recrutement raté. Un article du site HelloWorkplace détaille un exemple : un collaborateur qui coûte 50 000 € par an à l’employeur, cotisations comprises, quitte l’entreprise au bout de six mois. En additionnant le salaire et les cotisations déjà versés, l’intégration et la formation, la productivité perdue et le nouveau recrutement, l’article chiffre ce recrutement raté à 43 000 €. Cet exemple porte sur un autre profil. Le coût d’un CTO, calculé plus haut à partir des chiffres de l’Apec et de Payfit, va de 105 000 à 119 000 € par an, contre 50 000 € dans l’exemple : ce chiffre ne donne qu’un ordre de grandeur. Le successeur d’un CTO devra en plus reprendre le code qu’il a écrit. Gardez dans vos fonds de quoi absorber un recrutement raté.
Sans directeur technique, vous pouvez aussi recruter d’abord un développeur.
Un développeur écrit le code, le teste, le met en production et le corrige. Dans une startup sans CTO, il prend aussi des décisions qu’un directeur technique prendrait ailleurs : le langage, l’hébergement, l’organisation du code, ce qu’il vérifie automatiquement et ce qu’il laisse de côté. Ces décisions engagent votre entreprise pour des années.
Sans CTO, il n’y a pas encore d’équipe technique pour donner son avis sur le travail d’un premier développeur. Vous pouvez tout de même le juger de trois façons.
Ce que vos utilisateurs en font. Ils se servent du logiciel, ou ils ne s’en servent pas. Ils signalent ce qui manque et ce qui ne marche pas. Ce jugement-là est le vôtre, et il ne demande aucune compétence technique.
Le rythme et la fiabilité des mises en production. DORA (DevOps Research and Assessment), le programme de recherche de Google Cloud sur le développement et la mise en production des logiciels, suit cinq indicateurs. Vous pouvez en demander trois à votre développeur chaque mois, sans lire une ligne de code : combien de fois une modification a été mise en production, combien de ces mises en production ont cassé quelque chose et demandé une intervention immédiate, et combien de temps il a fallu pour rétablir le service. Les recherches de DORA montrent régulièrement que « la vitesse et la stabilité ne sont pas des compromis » : une équipe qui met souvent en production n’a pas à le payer en pannes.
Dave Farley, l’un des pionniers de la livraison continue et coauteur du livre Continuous Delivery (Livraison continue), pose dans Modern Software Engineering (Ingénierie logicielle moderne) une question que vous pouvez reprendre : « Combien de temps faut-il pour qu’une modification d’une seule ligne passe de l’“idée” au “logiciel qui fonctionne” ? » Posez-la à votre développeur, et demandez-lui de vous montrer le chemin que suit cette modification.
Un regard technique extérieur. La qualité du code, la sécurité et les choix d’architecture ne se voient pas depuis l’extérieur du logiciel. Pour les juger, il faut un autre professionnel : un CTO à temps partagé, ou un autre développeur qui relit une partie du code, à intervalles réguliers.
Ce regard extérieur compte d’autant plus que votre développeur écrira probablement une partie du code avec l’IA. Dans l’enquête 2025 de Stack Overflow, le site de questions-réponses des développeurs, 84 % des répondants utilisent ou prévoient d’utiliser des outils d’IA pour développer. Dans la même enquête, 46 % des répondants se méfient de l’exactitude de ce que ces outils produisent, contre 33 % qui leur font confiance. Pour Dave Farley, écrire du code coûte désormais peu, et c’est la vérification qui prend le temps. Demandez à votre développeur comment chaque modification est vérifiée avant d’être mise en production.
À notre avis, ce qui protège le travail d’un premier développeur sans CTO, c’est la livraison continue. Dès son premier mois, avant que vos clients dépendent de son logiciel, faites vérifier qu’il en connaît et en applique les principes : un pipeline de déploiement tel que Dave Farley l’enseigne, qui rejoue des tests automatisés à chaque modification, de petites modifications livrées en continu, et une conception qui suit le métier de votre entreprise.
Quand un premier développeur est la bonne réponse. Votre produit est déjà utilisé, et il doit évoluer chaque semaine au rythme de vos clients. Il y a là du travail pour une personne à plein temps, pendant des années, et un salarié qui connaît votre activité de l’intérieur peut s’y investir dans la durée. Son travail fera gagner à votre entreprise plus qu’il ne lui coûte, et vous avez les moyens de porter son salaire. Et quelqu’un, CTO à temps partagé ou développeur extérieur, peut vérifier qu’il applique les principes de la livraison continue. Dans ce cas, recruter un premier développeur est un bon choix.
Paul Graham, cofondateur de l’accélérateur de startups Y Combinator, l’écrivait en octobre 2015 : « Recruter trop vite est de loin la première cause de mort des startups qui lèvent des fonds. » Il ajoute que les fondateurs qui viennent de lever des fonds sont souvent encouragés à recruter plus que nécessaire par les investisseurs qui les ont financés.
En France, selon deux acteurs du financement, les investisseurs demandent davantage de preuves avant d’investir. Grenoble Angels, un réseau d’investisseurs individuels de l’Isère, membre de la fédération France Angels, constatait au second semestre 2024 « des attentes plus fortes en termes de traction marché et donc de chiffre d’affaires ». En juillet 2025, Nicolas Forey, président du cabinet de conseil In Extenso Innovation Croissance, commentait dans Le Journal des Entreprises le baromètre des levées de fonds du réseau d’expertise comptable In Extenso, qui compare le premier semestre 2025 à 2023. Selon lui, les jeunes startups ont plus de mal à réaliser leur première levée de fonds, l’amorçage, qui résistait encore en 2024. Le journal ajoute que les investisseurs, devenus plus prudents, « préfèrent recentrer leurs activités sur des entreprises plus matures ».
Une idée seule permet encore de lever des fonds auprès de certains investisseurs. Y Combinator indique dans sa foire aux questions qu’en moyenne, 40 % des entreprises qu’il finance à chaque promotion ne sont encore qu’une idée. Ce que vous faites de cet argent reste votre décision.
À notre avis, l’argent levé sert d’abord à vérifier que des clients veulent de votre produit. Recruter un CTO salarié avant cette vérification, c’est payer chaque mois un salaire de direction pour un produit dont personne ne sait encore s’il trouvera ses clients. Une fois que vos premiers utilisateurs s’en servent, vous recrutez pour des besoins que vous avez observés, et vous pouvez les expliquer à votre futur CTO.
Qu’est-ce qui prouve aujourd’hui que des clients veulent de votre produit ? Si la réponse est encore une intention, vérifiez-la d’abord avec un MVP, le produit minimum viable. Ce n’est pas une première version du produit, mais le plus petit test qui vérifie que l’idée vaut d’être construite.
Le code de votre CTO salarié revient à votre entreprise, mais pas ce qu’il sait du logiciel. Tant qu’il est seul, toute la connaissance du logiciel repose sur lui. S’il quitte l’entreprise, elle part avec lui, sauf si elle a été écrite et transmise. Son préavis, trois mois si votre entreprise applique la convention Syntec, est le temps dont vous disposez pour qu’il la transmette. Demandez-lui dès le début d’écrire comment le logiciel fonctionne, au fur et à mesure.
Ouvrez aussi au nom de l’entreprise, pas au nom de votre CTO, les comptes du logiciel : le nom de domaine, l’hébergeur, et le dépôt où son code source est conservé.
Seul un essai de reprise, fait une fois avant d’en avoir besoin, prouve qu’un autre développeur peut reprendre le logiciel : il reçoit le code et la documentation, installe le logiciel, puis met une petite modification en production. S’il y parvient, la connaissance est dans l’entreprise.
Un directeur technique apporte ses compétences, et aussi une façon de décider ce qui se développe, et dans quel ordre. Avec une approche prédictive, la liste des fonctionnalités se fixe au départ, avec un planning et des dates. Or cette liste s’écrit avant que le logiciel n’existe, le jour où l’on en sait le moins sur l’usage qu’en feront les utilisateurs de votre application. Avec une approche adaptative, le logiciel passe tôt entre leurs mains, et c’est leur usage qui définit les fonctionnalités suivantes.
Pendant le recrutement, demandez au candidat comment il décidera de ce qui se développe en premier, et ce qu’il fera le jour où vos utilisateurs demanderont autre chose que ce qui était prévu.
Un CTO salarié se justifie quand quatre conditions sont réunies. Des utilisateurs se servent déjà de votre produit, ou des clients s’y sont engagés. Vos fonds peuvent porter son salaire pendant le temps qu’il faudra à votre produit pour rapporter de l’argent. Son travail fera ensuite gagner à votre entreprise plus qu’il ne lui coûte. Et la technique est au cœur de votre produit : les décisions techniques s’y prennent chaque jour, et demandent quelqu’un à temps plein. C’est aussi lui qui recrutera et dirigera l’équipe technique quand elle grandira.
Pour Y Combinator, l’équipe fondatrice doit avoir dès le départ les compétences pour construire elle-même son produit. Si votre produit est d’abord une technologie, un logiciel dont la difficulté technique fait la valeur, ce conseil s’applique : recruter un CTO tôt, ou vous associer avec lui, est alors la bonne réponse.
Si vous ne pouvez pas payer de salaire, la question devient celle d’un cofondateur technique. Si vous avez surtout besoin de décisions et d’un regard sur le travail de vos prestataires, un CTO à temps partagé peut suffire.
Votre produit peut aussi répondre d’abord à un besoin que vous connaissez par votre métier ou par vos clients. La technique sert alors ce besoin. À notre avis, vous pouvez faire construire votre produit dès maintenant, avec un code qui appartient à votre entreprise, et le mettre entre les mains de vos premiers utilisateurs. Pendant cette période, les compétences techniques sont hors de l’entreprise. Y Combinator conseille au contraire, dans sa foire aux questions, que l’équipe fondatrice ait les compétences pour construire elle-même son produit, plutôt que de le confier à un prestataire. Pour un produit dont le besoin vient de votre métier, nous pensons autrement : sa difficulté tient d’abord à ce besoin, que vous connaissez, et un prestataire peut le construire tant que le code appartient à votre entreprise. Vous recrutez ensuite votre CTO au vu d’un produit déjà utilisé, et il reprend un logiciel dont le code vous appartient.
Un CTO recruté quand vos utilisateurs se servent déjà du produit sait ce qu’il doit faire évoluer, et vous savez pourquoi vous le recrutez.
Jusqu’à ce recrutement, nous prenons les décisions techniques que demande votre produit, comme le ferait un directeur technique : les technologies, l’architecture, la façon de le tester et de le mettre en production. Nous les alignons sur vos objectifs, et les décisions sur votre produit restent les vôtres.
Chez DEVEDANOS, nous développons votre logiciel sur mesure, utilisable en un mois, pour un budget mensuel fixe, et l’ajustons en continu à l’évolution de votre activité. Le budget se construit avec vous, à partir de vos chiffres et de vos objectifs : nous fixons ensemble le montant et le problème que votre application doit résoudre. Avec ce budget fixe, vous n’avez à payer ni honoraires de cabinet de recrutement, ni cotisations patronales. Les utilisateurs de votre application s’en servent dès le premier mois de développement, et c’est leur usage qui définit la ou les fonctionnalités suivantes. Vous changez de direction quand vous voulez, en toute réactivité, sans avenant ni surcoût.
Notre approche est adaptative : elle prédit ce qui est prévisible, le budget mensuel et les jours de développement par mois, et ne cherche pas à prédire ce que vos utilisateurs feront d’une fonctionnalité avant de l’avoir entre les mains.
Et pour que ce qui fonctionnait le mois dernier fonctionne encore ce mois-ci, nous appliquons une garantie zéro régression : chaque régression est corrigée et couverte par un test automatisé, pour qu’elle ne revienne pas, et sans surcoût.
Le code source, l’infrastructure, le pipeline de déploiement et la documentation sont votre propriété intellectuelle dès le règlement de la première mensualité. Période d’essai jusqu’à 15 jours ouvrés sur le premier mois : aucune facture si vous ne voulez pas des livrables.
Vous pouvez mettre fin au contrat par écrit à tout moment, sans justification. Pendant le mois de réversibilité, nous accompagnons votre équipe jusqu’à ce qu’elle puisse construire, tester et déployer sans nous. Le jour où vous recrutez votre CTO, il trouve un logiciel déjà utilisé, avec son code, ses tests et sa documentation. Le pipeline continue de protéger chaque modification future, quel que soit le développeur qui intervient.
Nous construisons notamment des marketplaces, des applications métier et des applications mobiles.
Vous hésitez à recruter un CTO, ou à faire construire votre produit d’abord ? On en parle ?
Comment intégrer l'IA dans son entreprise : partir d'une tâche précise, savoir quand une règle suffit, choisir entre un outil d'automatisation et un logiciel sur mesure, et connaître les risques.
Fichier Excel partagé entre plusieurs utilisateurs, erreurs, versions qui se croisent : quand le tableur est devenu une application, et ce que change le passage à une application web métier.
Reprise d'application web : ce qu'il faut récupérer avant de changer de prestataire informatique, pourquoi des tests précèdent toute modification, et quand une refonte s'impose.