CTO à temps partagé : ce que vous obtenez vraiment

« Un CTO à temps partagé, à deux jours par semaine, ça sert vraiment à quelque chose ? » C'est la première question des fondateurs. Réponse directe : oui, à condition de bien comprendre ce qu'on achète. Pas une paire de bras supplémentaire, mais une tête. Quelqu'un qui prend les décisions structurantes que vous ne savez pas prendre seul, et qui débloque ce qui coince, sans le coût d'un temps plein.

La confusion la plus fréquente, c'est de raisonner en volume horaire. « Deux jours sur cinq, je n'ai que 40 % d'un CTO. » C'est faux, parce qu'un CTO ne produit pas de la valeur à la ligne de code. Il en produit aux moments de décision, et ces moments ne tombent pas tous les jours. Je détaille ce qu'est ce format dans le guide complet du CTO fractionnel ; cet article-ci répond à une question plus terre-à-terre : concrètement, qu'est-ce que vous obtenez quand un CTO entre dans votre boîte deux jours par semaine ?

Ce que vous ne pouvez pas vous payer en temps plein

Posons le problème tel que la plupart des fondateurs non-techniques le vivent. Vous savez qu'il vous manque une tête tech. Vous regardez les salaires d'un CTO senior (facilement 150 K€ brut, soit autour de 220 K€ chargés) et vous fermez l'onglet. Ce n'est pas le bon moment, vous n'avez ni le budget ni la certitude que le besoin est durable. Alors vous reportez. Et pendant ce temps, les décisions techniques se prennent quand même : par votre prestataire, par votre premier développeur, ou par défaut, faute d'arbitre.

Le temps partagé existe précisément pour cette zone-là. À deux jours par semaine, vous mobilisez un profil senior (quinze à vingt ans de terrain, plusieurs boîtes accompagnées) pour un coût de l'ordre de 80 à 120 K€ par an, et autour de 40 à 60 K€ à un jour. Vous n'achetez pas une fraction de salaire, vous achetez une séniorité ciblée sur la phase où elle compte. Le détail des fourchettes, format par format, est dans combien coûte vraiment un CTO.

L'erreur serait de croire qu'à mi-temps, on obtient la moitié des résultats. Un CTO à temps plein passe une bonne part de ses journées en réunions et en gestion de l'urgence. Le fractionnel concentre ses jours sur ce qui fait levier : les choix d'architecture, les recrutements, les arbitrages de roadmap. C'est plus dense, pas plus dilué.

Une journée type : quelles décisions je prends

Pour rendre ça concret, voici à quoi ressemblent mes deux jours dans une jeune startup. Le matin du premier jour, je revois l'état du produit avec le développeur en place : ce qui avance, ce qui coince, ce qui a été décidé sans moi la semaine précédente. C'est souvent là que se jouent les vrais sujets. Un choix de base de données pris à la légère, une dépendance externe qui devient critique, une fonctionnalité partie dans une direction coûteuse : autant de décisions qui, non challengées, deviennent irréversibles ou très chères à corriger.

Mon travail, à ces moments-là, c'est de trancher avec le recul que personne n'a en interne. Pas « c'est mieux comme ça parce que je le dis », mais « voici les deux options, voici ce que chacune coûte dans six mois, voici celle que je recommande et pourquoi ». Sur une semaine, les décisions structurantes que je prends ressemblent à ça :

Aucune de ces décisions ne demande que je sois présent tous les jours. Elles demandent que je sois là au bon moment, avec le bon recul, et qu'entre deux, l'équipe sache exécuter sans moi.

Ce que je débloque, ce que je délègue

C'est l'autre malentendu à lever : un CTO à temps partagé ne fait pas tout, et surtout ne fait pas tout lui-même. Une mission qui marche repose sur une répartition claire entre ce que je porte et ce que je confie au développeur ou au lead dev en place.

Ce que je porte

La vision technique et sa traduction en décisions : les choix d'architecture qui engagent l'entreprise pour deux ans, les arbitrages de roadmap (ce qui passe avant la levée, ce qui attend), le recrutement des premiers profils et la relation avec les investisseurs sur les sujets tech. Quand un fondateur prépare une levée, c'est moi qui réponds aux questions de due diligence sur l'architecture, la dette, le plan de scaling : des réponses floues à ce stade entament la crédibilité du dossier.

Les fondations d'équipe : qui recruter, dans quel ordre, à quel niveau, sujet que je creuse dans composer sa première équipe tech. Et c'est moi qui repère les risques invisibles depuis le siège du fondateur, une dépendance critique à un prestataire, un choix de stockage qui coûtera une réécriture, avant qu'ils ne se paient au pire moment.

Ce que je délègue

L'exécution au quotidien. Le développeur en place code, déploie, gère les incidents courants. Mon rôle n'est pas de lui prendre son travail mais de lui donner un cadre et un cap, et souvent de le faire monter en compétence pour qu'il devienne le futur lead dev. Un bon signe que la mission fonctionne, c'est quand l'équipe se met à décider juste sans m'appeler.

Pour qui c'est fait, et pour qui ça ne l'est pas

Le temps partagé n'est pas une solution universelle, et je préfère le dire avant qu'après. Il y a une fenêtre où c'est le meilleur format, et des situations où c'en est clairement un mauvais.

C'est fait pour vous si vous êtes en amorçage ou en pré-série A, avec un produit qui avance mais une tech qui devient un sujet sérieux : un MVP à structurer, une première équipe à recruter, une levée à préparer. À ce stade, vous avez besoin d'une vision juste et de quelques décisions bien prises, pas d'une présence permanente. C'est exactement la zone où un CDI est surdimensionné et où un freelance purement technique ne suffit pas : je détaille ce choix de format dans CTO freelance, fractionnel ou CDI.

Ce n'est pas fait pour vous dans deux cas. D'abord, si votre tech exige une présence quotidienne : une plateforme critique qui tombe la nuit, des incidents permanents, une charge opérationnelle qui réclame quelqu'un en première ligne tous les jours. Deux jours par semaine ne tiendront pas ce rythme. Ensuite, si votre équipe technique est déjà grosse (au-delà de quinze à vingt développeurs sans personne pour porter les sujets au quotidien), un temps partagé se disperse. À ce stade, c'est un CTO en CDI qu'il faut, et le rôle du fractionnel est plutôt de préparer ce recrutement que de s'y substituer.

Un exemple concret

Un fondateur non-technique me contacte, expert reconnu de son domaine (un secteur réglementé exigeant) mais sans la moindre brique d'équipe tech. Il a une conviction produit forte, une fenêtre de marché étroite, et trois mauvaises options en tête : recruter un CTO (trois à six mois rien que pour le trouver), confier le tout à une agence (un prototype à jeter, zéro transfert), ou bricoler en no-code (intenable dans un secteur aussi sensible).

Ce dont il avait besoin n'était pas une paire de bras, mais quelqu'un pour trancher les choix qui engageaient les années suivantes : comment isoler les données de chaque client, quelle architecture pour tenir une contrainte réglementaire forte, quoi construire d'abord et quoi reporter. Ces décisions-là, prises tôt et bien, ont évité des mois de réécriture. Ce cas a pris la forme d'un Sprint Fondateur, un format intensif, mais la logique est la même en temps partagé étalé : la valeur ne vient pas du nombre de jours, elle vient de la justesse des décisions structurantes. J'ai raconté ce projet dans un SaaS de santé livré en un seul Sprint Fondateur.

Le fil conducteur, ici comme dans la plupart de mes missions : un fondateur non-technique n'a pas besoin qu'on lui code plus vite. Il a besoin qu'on prenne, à sa place et avec lui, les quelques décisions qui feront la différence entre un actif solide et une dette qu'il découvrira au pire moment.

Comment ça s'articule dans le temps

Une mission à temps partagé bien menée n'est pas une présence diffuse qui s'étire indéfiniment. Elle suit une logique en trois temps. Un bon CTO à temps partagé se rend remplaçable, c'est même le critère de réussite : la boîte doit pouvoir tourner sans lui.

C'est tout l'objet d'une mission de création d'équipe tech & produit : porter la casquette CTO le temps de poser les bases, recruter et former l'équipe qui prendra le relais, puis passer la main proprement. Vous ne vous engagez pas à l'aveugle sur un CDI dont vous ne savez pas encore s'il est justifié : vous clarifiez le besoin réel avant de vous engager.