CTO à temps partagé, audit, nearshore et MVP : 25 réponses franches.
Les questions que les fondateurs me posent le plus, avec une réponse d'un paragraphe chacune. Si la vôtre n'y est pas, posez-la lors du premier appel.
CTO à temps partagé
Qu'est-ce qu'un CTO à temps partagé ?
Un CTO à temps partagé est un responsable technique senior qui travaille pour votre startup à temps partiel, en général 1 à 2 jours par semaine, et qui porte réellement la responsabilité technique de l'entreprise. Concrètement : l'architecture, la revue de code, le recrutement technique, la sécurité et la roadmap, décidés par quelqu'un qui a déjà mis des produits en production. Vous avez le jugement d'un CTO sans le salaire, l'equity et les mois de recrutement d'un CTO à plein temps. Chez moi, c'est un forfait mensuel avec un engagement minimum de 3 mois, et tout ce que je produis vous appartient dès le premier jour.
Comment fonctionne la mission de CTO à temps partagé →Que fait un CTO externalisé en une semaine ?
Un CTO externalisé partage sa semaine entre décisions, revues et accompagnement de l'équipe, le tout concentré sur 1 à 2 jours de travail. Une semaine type, je relis les pull requests importantes, je débloque les développeurs sur les questions d'architecture, je mets à jour la roadmap avec les fondateurs et je vérifie que la production se porte bien. Certaines semaines sont consacrées au recrutement : fiche de poste, entretiens techniques, intégration du nouveau développeur. D'autres partent sur un risque précis, comme une base de données lente ou une faille de sécurité. Entre ces jours, je reste joignable sur Slack pour les questions courtes, pour que l'équipe n'attende pas une semaine.
CTO à temps partagé, CTO salarié, développeur freelance ou agence : que choisir ?
Un CTO à temps partagé apporte une direction technique senior à temps partiel, un CTO salarié apporte la même direction en poste permanent, un développeur freelance apporte des bras sur le code, et une agence livre un projet. Le bon choix dépend de ce qui vous manque. S'il vous manque une direction et quelqu'un de responsable de la technique, il vous faut un CTO, à temps partagé tant qu'un plein temps ne se justifie pas. Si la direction est claire et qu'il vous manque de la capacité, un freelance ou une agence ajoute de la production. La plupart des startups en seed ont d'abord besoin de direction : sans elle, plus de capacité construit juste le mauvais produit plus vite.
À quel moment une startup a-t-elle besoin d'un CTO freelance ?
Une startup a besoin d'un CTO freelance quand des décisions techniques se prennent sans personne d'assez senior pour bien les prendre. Les déclencheurs sont assez nets : vous allez lancer un MVP et ne voulez pas le construire de travers, le produit en ligne casse régulièrement, vos deux ou trois développeurs n'ont aucun senior pour relire leur travail, les investisseurs posent des questions techniques auxquelles vous ne savez pas répondre, ou un prestataire s'apprête à vous remettre un code que vous ne savez pas évaluer. Si rien de tout cela ne vous parle et que l'équipe livre de façon fiable, vous n'en avez probablement pas encore besoin.
Me dire où vous bloquez →Comment savoir si mon CTO à temps partagé fait du bon travail ?
Un CTO à temps partagé fait du bon travail quand l'équipe livre de façon plus prévisible et que les fondateurs prennent moins de décisions techniques à l'aveugle. Au bout d'un mois, vous devez voir des choses concrètes : une architecture et une roadmap écrites, une revue de code sur chaque changement, un déploiement qui ne dépend plus d'une seule personne et une courte liste de risques traités dans l'ordre. Au bout de trois mois, les mises en production doivent être plus calmes, le recrutement doit avancer, et vous devez pouvoir expliquer votre stack à un investisseur. Si vous ne pouvez citer aucune décision ni aucun document produit par votre CTO, demandez-les au prochain point d'étape.
Tarifs et engagement
Combien coûte un CTO à temps partagé ?
Un CTO à temps partagé se paie en général au forfait mensuel pour 1 à 2 jours par semaine, et les TJM courants des CTO freelance sur Malt se situent à peu près entre 700 et 1 500 €, soit un marché d'environ 3 000 à 10 000 € par mois. C'est une fourchette, pas un devis. Je facture la direction technique au forfait mensuel avec un engagement minimum de 3 mois, et les missions ponctuelles, comme un audit technique ou un MVP, au prix fixe pour un périmètre fixe. Mes prix de départ figurent dans l'encadré tarifs de chaque page de service, et vous recevez le chiffre final par écrit avant le début du travail.
Voir les tarifs du CTO à temps partagé →Pourquoi un prix fixe pour un audit ou un MVP plutôt qu'un TJM ?
Un prix fixe pour un périmètre fixe vous permet de savoir exactement ce que vous achetez, pour quand et pour combien, avant que le travail commence. Chaque audit technique et chaque MVP démarre par un périmètre écrit : ce qui est inclus, ce qui ne l'est pas et à quoi ressemble le livrable. Une fois ce périmètre validé, le prix ne bouge plus. Si un nouveau besoin apparaît en cours de route, on décide ensemble s'il remplace quelque chose du périmètre ou s'il part dans une phase suivante, au lieu de laisser la facture gonfler en silence. Quand on gère sa trésorerie au mois près, un chiffre qui ne peut pas dériver vaut plus qu'une estimation qui peut.
Voir les tarifs de l'audit technique →Qu'est-ce qui est inclus dans le forfait d'un CTO à temps partagé ?
Le forfait d'un CTO à temps partagé couvre le travail technique senior que ferait un CTO à plein temps, ramené aux 1 à 2 jours par semaine réservés. Avec moi, cela comprend les décisions d'architecture, la revue de code et les standards d'ingénierie, la roadmap technique, l'aide au recrutement et à l'intégration des développeurs, le suivi de la sécurité et du RGPD, et le rôle d'interlocuteur technique face aux investisseurs. Le forfait inclut aussi des réponses courtes sur Slack ou par email entre les jours de travail. Les gros chantiers de développement, comme un nouveau module complet, sont en général chiffrés à part. Tout ce qui est produit vous appartient.
Comment arrêter une mission de CTO externalisé, et y a-t-il un engagement ?
Une mission de CTO externalisé avec moi s'arrête à un point d'étape convenu, sans dépendance, une fois passé l'engagement minimum de 3 mois. Les points d'étape sont fixés par écrit dès le départ, et à chacun d'eux vous pouvez mettre en pause, réduire le nombre de jours ou arrêter. Comme vous êtes propriétaire des dépôts, des comptes cloud, des domaines et de la documentation dès le premier jour, arrêter signifie un appel de passation, pas une négociation. L'objectif du forfait est une équipe capable d'avancer sans moi : y mettre fin au moment prévu est une réussite, pas un échec.
Un CTO à temps partagé coûte-t-il moins cher qu'un CTO salarié ?
Un CTO à temps partagé coûte moins cher qu'un CTO salarié pour la plupart des jeunes startups, parce que vous payez 1 à 2 jours par semaine au lieu d'un salaire complet, des charges, de l'equity et un long recrutement. D'après ce que je vois, un CTO expérimenté en seed coûte souvent 80 000 à 130 000 € brut par an en France, et les charges patronales ajoutent à peu près 40 à 45 %, hors equity. Un forfait à temps partagé en coûte une fraction. La contrepartie, c'est la disponibilité : un CTO salarié est là tous les jours. À mon avis, à partir de cinq développeurs environ, une embauche à plein temps commence à se justifier.
Audit technique et due diligence
Qu'est-ce qu'un audit technique de startup ?
Un audit technique de startup est une revue structurée du code, de l'infrastructure et des pratiques d'ingénierie qui vous dit ce qui est risqué, ce qui vous ralentit et ce qu'il faut corriger en premier. Le mien dure deux semaines, avec un périmètre fixe et un prix fixe. Je lis le code et son historique, je vérifie l'infrastructure et le pipeline de déploiement, j'examine la sécurité et le RGPD, et je parle avec les personnes qui ont construit le produit. Le résultat est un registre de risques priorisé sur lequel vous pouvez agir, pas une note vague. On le demande souvent avant une levée, avant une réécriture ou après avoir hérité du code d'une équipe partie.
Comment se déroule l'audit technique →Que contient le rapport d'un audit de code ?
Le rapport d'un audit de code est un registre de risques priorisé qui couvre l'architecture, la sécurité, le RGPD et la protection des données, l'infrastructure, les tests et les pratiques de l'équipe. Chaque constat indique ce que j'ai trouvé, pourquoi c'est important, sa gravité, l'effort nécessaire pour le corriger et la correction concrète que je recommande. Les constats sont classés par impact et par effort : le haut de la liste montre ce qu'il faut corriger ce mois-ci, le bas ce qui peut attendre. Le rapport est écrit pour deux publics, assez précis pour vos développeurs et assez clair pour un fondateur ou un investisseur. Un appel de restitution permet de le parcourir ensemble.
Combien de temps dure un audit technique, et comment se passent les deux semaines ?
Un audit technique avec moi dure deux semaines : environ une semaine de lecture et de tests, puis une semaine de vérification des constats et de rédaction du rapport. Les premiers jours servent aux accès, à un appel de lancement et à la lecture de l'architecture, du code et de l'historique git. Ensuite, je passe en revue l'infrastructure, le pipeline de déploiement, la sécurité et le traitement des données, et je reproduis les problèmes qui comptent. La deuxième semaine, je parle avec les personnes qui ont construit le système, je confronte mes conclusions à ce qu'elles savent, je classe chaque constat et je rédige les corrections. L'audit se termine par le rapport et un appel de restitution.
Que vérifient les investisseurs lors d'une due diligence technique avant une levée seed ?
Une due diligence technique avant une levée seed vérifie que le produit peut encaisser la croissance et que la société en est vraiment propriétaire. Les relecteurs regardent six domaines : architecture, sécurité, RGPD et données, infrastructure et déploiements, tests et qualité du code, équipe et propriété intellectuelle. Les signaux d'alerte classiques : des secrets dans l'historique git, des sauvegardes jamais restaurées, une seule personne qui a tout en tête, une agence encore propriétaire de l'organisation GitHub. J'ai rassemblé ces points dans une checklist gratuite de 25 points, à passer en revue avec votre lead dev en un après-midi, avant l'ouverture de la data room.
Télécharger la checklist due diligence technique →Faut-il arrêter le travail de l'équipe pendant un audit de code ?
Un audit de code n'oblige pas votre équipe à s'arrêter, et c'est même préférable, car je veux voir comment elle livre d'habitude. J'ai besoin d'un accès en lecture aux dépôts, à l'infrastructure et à vos outils, et de quelques heures du temps de vos développeurs réparties sur les deux semaines : un appel de lancement, un ou deux entretiens et des réponses rapides à mes questions. Je ne pousse pas de code et je ne touche pas à la production pendant l'audit. Tout ce à quoi j'accède est couvert par un NDA, et les accès sont retirés à la fin de la mission. Pour la plupart des équipes, le coût se résume à quelques heures d'entretiens, pas à un sprint perdu.
Nearshore, RGPD et collaboration
Pourquoi choisir le développement nearshore en Tunisie ?
Le développement nearshore en Tunisie consiste à travailler avec des ingénieurs basés en Tunisie, à deux ou trois heures d'avion de la plupart des villes d'Europe de l'Ouest et quasiment à la même heure. Les startups européennes le choisissent pour trois raisons : des ingénieurs seniors moins chers qu'à Paris, Berlin ou Amsterdam, des horaires qui recoupent entièrement ceux de l'UE, et un français très présent dans la tech, à côté de l'anglais et de l'arabe. La différence avec l'offshore lointain : vous travaillez comme une seule équipe, avec des appels en direct et des revues de code le jour même. J'ai livré plus de 20 produits depuis Tunis, pour des clients en France, en Tunisie et au Royaume-Uni.
Lire l'étude de cas Facturra →Quel est le décalage horaire entre la Tunisie et Paris ?
La Tunisie est à UTC+1 toute l'année et n'applique pas l'heure d'été, donc Tunis a la même heure que Paris en hiver et une heure de moins que Paris en été. De fin mars à fin octobre, quand la France passe à l'heure d'été (UTC+2), 10 h à Paris correspondent à 9 h à Tunis. Le reste de l'année, les horloges sont identiques. Il en va de même pour Berlin, Amsterdam et Madrid. En pratique, une journée de travail à Tunis couvre une journée de travail à Paris toute l'année, avec au plus une heure de décalage à prendre en compte pour caler les réunions.
Est-ce conforme au RGPD de sous-traiter son développement en Tunisie ?
Sous-traiter son développement en Tunisie peut être conforme au RGPD, à condition de bien cadrer les contrats et les accès, car la Tunisie ne bénéficie d'aucune décision d'adéquation de l'UE. Dès qu'un développeur en Tunisie peut accéder à des données personnelles d'utilisateurs européens, même en se connectant à un serveur hébergé en Europe, il s'agit d'un transfert hors UE. La solution classique : un contrat de sous-traitance (DPA) et les clauses contractuelles types de la Commission européenne, avec une analyse d'impact du transfert. En plus des papiers, je garde les données hébergées dans l'UE, je donne des accès au strict nécessaire, et je travaille sur des données anonymisées ou de test dès que la production n'est pas indispensable.
Vérifier vos bases RGPD avec la checklist →Peut-on travailler en français avec un développeur en Tunisie ?
Travailler en français avec un développeur en Tunisie est tout à fait courant, et avec moi vous choisissez le français, l'anglais ou l'arabe pour les réunions, les revues de code et la documentation. Le français est très présent dans les affaires et la tech en Tunisie, et les ingénieurs travaillent tous les jours en anglais, puisque le code, les outils et la documentation technique le sont déjà. J'enseigne l'informatique et j'anime des formations en français comme en anglais, et je rédige les specs, les tickets et les documents de passation dans la langue de votre équipe. Les équipes mixtes fonctionnent aussi : fondateur français, investisseur anglophone et utilisateurs arabophones ont chacun des documents dans leur langue.
Suis-je propriétaire du code si je sous-traite mon développement, et signez-vous un NDA ?
Vous êtes propriétaire du code, de l'infrastructure et de la documentation dès le premier jour quand vous travaillez avec moi, et je signe volontiers un NDA avant que vous partagiez quoi que ce soit de confidentiel. Faites inscrire cette propriété dans le contrat sous forme de cession de droits, car les investisseurs la vérifient en due diligence. En pratique, les dépôts sont dans votre organisation GitHub ou GitLab, les comptes cloud, domaines et stores sont au nom de votre société, et j'y travaille avec des accès que vous contrôlez. À la fin de la mission, vous retirez mes accès et rien n'est à transférer. La plupart de mes missions récentes sont couvertes par un NDA.
Demander un NDA avant d'en parler →MVP et IA
Peut-on vraiment créer un MVP en 4 semaines, et qu'est-ce qui tient dans ce délai ?
Un MVP en 4 semaines est réaliste quand le périmètre se limite à un parcours utilisateur principal, écrit et validé avant la première ligne de code. En quatre semaines environ à périmètre fixe, cela couvre l'inscription et la connexion, le modèle de données principal, le parcours qui prouve votre idée, une vue d'administration, les emails ou un paiement simple, et une mise en production avec CI/CD. Ce qui ne tient pas : plusieurs rôles avec des applications séparées, des applications natives sur les deux stores, des intégrations lourdes avec l'existant, le mode hors ligne et le reporting avancé. Cela demande plus de semaines, et je l'écris dans le périmètre plutôt que de le découvrir en semaine trois.
Comment se déroule un MVP en 4 semaines →Quelle stack technique choisir pour son MVP ?
La meilleure stack pour un MVP est une stack courante, que vos futurs recrutés connaissent déjà et qui ne demandera pas de réécriture aux premiers signes de traction. Pour la plupart des produits web, je travaille avec Next.js et React côté front, Node.js avec NestJS ou Express, ou Python avec Django ou FastAPI côté back, sur PostgreSQL ou MongoDB selon les données. Pour le mobile, j'utilise Flutter ou React Native, pour qu'une seule base de code couvre Android et iOS. Les déploiements passent par GitHub Actions vers un VPS, ou vers OVHcloud quand l'hébergement dans l'UE compte. J'évite les frameworks exotiques : pouvoir recruter sur la stack compte plus que gagner une semaine.
L'IA peut-elle coder mon MVP, ou ai-je encore besoin d'un développeur senior ?
Les outils de code assisté par IA peuvent écrire une grande partie du code d'un MVP, mais un développeur senior reste nécessaire pour décider quoi construire, comment le structurer et si le code généré peut partir en production. J'utilise le développement agentique tous les jours, et sur Sabboura il a permis de passer du premier commit à la production en moins de deux mois, en menant plusieurs jalons en parallèle. Ce que l'IA ne fait pas de façon fiable : l'architecture, la modélisation des données, la sécurité, les contrôles de droits, et repérer quand une réponse plausible est fausse. Du code IA non relu marche en démo et casse face aux vrais utilisateurs, et c'est exactement ce qu'une revue senior attrape.
Lire l'étude de cas Sabboura →Que se passe-t-il après le lancement de mon MVP ?
Après le lancement d'un MVP, vous êtes propriétaire de tout et vous choisissez comment le faire grandir : en interne, avec un CTO à temps partagé ou avec une autre équipe. Les dépôts, l'infrastructure et la documentation sont à votre nom dès le premier jour, donc il n'y a rien à récupérer. Les premières semaines après le lancement servent surtout à corriger ce que révèlent les vrais utilisateurs, à surveiller les erreurs et les coûts, et à décider ce qui entre dans la version deux à partir de l'usage réel. Vous pouvez me garder en CTO à temps partagé pour cette phase, 1 à 2 jours par semaine, ou recruter votre premier développeur avec une passation propre.
Faire grandir le produit avec un CTO à temps partagé →Comment migrer son application de Bubble, d'un outil no-code ou de Firebase ?
Migrer une application depuis Bubble, un autre outil no-code ou Firebase fonctionne mieux sous forme de reconstruction planifiée du cœur, par étapes, pendant que l'ancienne version continue de tourner. Je commence par cartographier ce que fait réellement l'application, y compris la logique cachée dans les workflows, les règles et les plugins, puis j'exporte les données et je vérifie leur qualité. Ensuite, je reconstruis sur une stack standard comme Next.js et PostgreSQL, je migre les utilisateurs et les données avec un script qu'on peut relancer plusieurs fois, et on bascule quand la nouvelle version est au niveau. Les fondateurs migrent en général quand les coûts, les limites de performance ou les questions d'investisseurs sur la dépendance commencent à peser.
Une autre question ?
Posez-la directement. Je réponds sous 48 heures.
Me poser la question →