Choisissez le rôle qui porte la responsabilité absente : un Lead Dev fait tenir l'exécution collective, un CTO prend les décisions qui engagent la technique, le produit, le budget et l'équipe. Le titre de votre startup ne suffit pas à trancher.
Je me souviens de Miloé Santé, en 2021. Une agence avait mis en place des microservices et une architecture hexagonale, deux choix défendables sur le papier. Pourtant, le développeur interne, seul à reprendre le produit, passait des jours, parfois des semaines, sur des modifications simples.
Avec lui et la porteuse du projet, nous avons simplifié progressivement vers un monolithe organisé par domaine. Il a participé à la réécriture en binôme et les fonctionnalités prévues ont continué à sortir. Le problème n'était ni l'agence ni le développeur. L'architecture n'était simplement pas adaptée à la personne chargée de la maintenir.
Deux rôles, deux responsabilités différentes
Un Lead Dev est responsable de la façon dont une équipe livre ensemble. Il rend l'exécution plus fiable : découpage du travail, qualité du code, revues, décisions prises au quotidien et aide aux autres développeurs lorsqu'un sujet bloque. Cela ne veut pas dire qu'il passe ses journées à coder en silence. Dans une petite équipe, sa capacité à créer des repères communs vaut souvent autant que sa vitesse de production.
Son terrain est concret. Une fonctionnalité doit-elle être découpée avant d'être confiée à deux personnes ? Une convention de code permet-elle à un développeur moins expérimenté d'avancer sans rester seul face aux erreurs qui reviennent ? Le Lead Dev transforme un objectif produit en travail exécutable, puis maintient le niveau de qualité nécessaire pour continuer à livrer.
Le CTO porte une autre responsabilité : les décisions qui dépassent un ticket ou un sprint. Il relie les choix techniques à leurs conséquences pour le produit, le budget, les recrutements et les partenaires. Il décide, par exemple, s'il faut accepter une dette technique temporaire pour tester une hypothèse, simplifier une architecture devenue coûteuse à maintenir, ou revoir un devis avant d'engager l'entreprise.
Ces rôles se croisent parfois. Un Lead Dev peut participer aux arbitrages techniques et un CTO peut mettre les mains dans le code. Dans une startup, une même personne peut même couvrir les deux pendant un temps. Le titre compte peu à ce moment-là. La responsabilité qui reste chez cette personne lorsqu'une décision doit être prise donne une distinction plus utile.
Une erreur de casting laisse une décision sans propriétaire
Une erreur de casting survient quand l'attente reste imprécise. Vous recrutez un Lead Dev parce que l'équipe livre avec difficulté, puis vous lui demandez aussi de choisir une architecture, de challenger une agence et de préparer les prochains recrutements. Ou vous faites venir un CTO alors que les décisions structurantes sont déjà prises, mais que personne ne coordonne le travail quotidien. Dans les deux cas, le besoin initial reste ouvert.
À Miloé Santé, personne n'avait choisi une architecture absurde. Les microservices séparaient bien les responsabilités et l'architecture hexagonale isolait la logique métier. Le souci est apparu après la livraison : un seul développeur devait comprendre ces couches, les modifier et continuer à livrer. Il fallait remettre la maintenabilité entre les mains de l'équipe qui allait vivre avec le produit, pas chercher un coupable.
Cette nuance compte quand vous recrutez. Une technologie sophistiquée peut être pertinente si une équipe sait l'exploiter. Elle peut devenir un coût fixe si les personnes disponibles doivent contourner sa complexité pour chaque changement.
Quand les conséquences touchent la trajectoire du produit, le CTO porte l'arbitrage. Le Lead Dev porte l'adoption du choix dans l'exécution collective. Il ajuste le découpage, les standards et le travail d'équipe pour que ce choix tienne au quotidien.
Ne demandez donc pas : "Quel rôle prend-on à ce stade ?" Demandez plutôt qui est responsable de la décision qui attend. Cette réponse fait souvent tomber une partie du flou. Elle évite aussi de transformer un titre en liste de missions impossibles.
Identifier ce qui manque vraiment à votre startup
Commencez par observer les situations qui se répètent. Si les fonctionnalités sont claires mais avancent mal, le manque se situe peut-être dans l'organisation de l'exécution. Si l'équipe attend qu'on lui dise quelle dette traiter ou si des partenaires proposent des solutions incompatibles, personne ne porte les arbitrages. Un budget engagé sans choix technique explicite raconte la même histoire.
Le tableau ci-dessous ne remplace pas une discussion avec l'équipe. Il sert à nommer le problème avant de chercher un intitulé de poste. La même situation peut appeler un autre profil si la responsabilité est déjà tenue en interne.
| Situation observée | Responsabilité manquante | Profil à privilégier |
|---|---|---|
| Une petite équipe doit construire un MVP dont le périmètre et les choix essentiels sont déjà tranchés. | Coordonner le travail, maintenir la qualité partagée et signaler les blocages. | Lead Dev |
| Une petite équipe livre de manière inégale et les développeurs n'ont pas de cadre commun. | Coordonner l'exécution, faire circuler les décisions du quotidien et faire progresser l'équipe. | Lead Dev |
| Des choix d'architecture, de prestataire ou de priorité engagent le produit sans direction claire. | Arbitrer les compromis et assumer leurs conséquences sur le produit, le budget et la continuité technique. | CTO |
| Le produit gagne en traction et les recrutements arrivent, mais personne ne définit le cadre technique de l'équipe. | Donner une direction aux recrutements, à l'architecture et aux responsabilités qui changent avec l'équipe. | CTO |
Ce cadre évite deux réflexes coûteux. Le premier consiste à associer automatiquement MVP et Lead Dev. Un MVP peut exiger un arbitrage difficile si le produit manipule des données sensibles, dépend de partenaires complexes ou repose sur un choix technique peu réversible. Le second consiste à croire que la traction appelle mécaniquement un CTO. Une équipe peut très bien avoir besoin d'un Lead Dev si sa direction technique existe déjà, mais que l'exécution se dégrade.
Si aucune équipe n'existe encore et que le MVP est déjà cadré, cherchez plutôt un développeur senior ou un freelance autonome. Vous avez besoin d'un bâtisseur, pas encore d'un rôle de coordination.
Regardez aussi ce qui se passe lorsqu'une personne s'absente. Si les développements s'arrêtent parce que personne ne sait répartir le travail ou relire les changements, vous avez un problème d'exécution collective. Si personne ne peut expliquer pourquoi une intégration est prioritaire, quelle dette peut attendre ou comment reprendre un prestataire, vous avez un problème de direction technique. Ce test est plus parlant qu'un organigramme.
Choisir le rôle adapté à votre situation
Une fois la responsabilité identifiée, formulez le besoin avec des résultats observables. Pour un Lead Dev, vous pouvez parler de cadence de livraison, de qualité partagée et de montée en autonomie de l'équipe. Pour un CTO, parlez des décisions à prendre, des risques à rendre visibles et des personnes qui devront appliquer les choix. Vous évaluez ainsi une capacité à tenir une responsabilité, pas la qualité d'un discours en entretien.
Si vos choix structurants restent ouverts, un CTO à temps partiel peut aider à les poser sans créer immédiatement un poste permanent. Son intervention rend les arbitrages explicites, cadre ce qui doit l'être et laisse à l'équipe une direction utilisable. Si le périmètre est clair et que le besoin est d'avancer avec une équipe plus cohérente, un Lead Dev expérimenté répondra souvent plus directement au problème.
Un freelance senior, une agence et un CTO à temps partiel ne remplacent pas exactement les mêmes responsabilités. J'ai détaillé ce point dans freelance senior, agence ou CTO part-time. Vous pouvez les combiner, à condition de savoir qui décide et qui exécute. Ajouter de la capacité à une décision floue ne la rend pas plus nette.
Enfin, ne recrutez pas sur une promesse d'évolution implicite. Un Lead Dev peut devenir CTO s'il souhaite et sait prendre les décisions qui sortent de l'exécution collective. Un CTO peut intervenir dans le code lorsqu'il faut comprendre une zone à risque. Aucun des deux parcours n'est automatique, et aucun ne vaut mieux que l'autre. Ils répondent à des responsabilités différentes, qui peuvent évoluer avec votre produit et votre équipe.
Ce qu'il faut retenir
Le bon choix commence par la responsabilité qui n'a pas de propriétaire. Si l'équipe a besoin d'un cadre pour livrer ensemble, cherchez un Lead Dev capable d'organiser l'exécution sans la confisquer. Si les décisions techniques engagent le produit, le budget, les partenaires ou les recrutements sans être réellement portées, cherchez une direction technique. Le titre n'est qu'une conséquence de ce diagnostic.
Avant un recrutement, écrivez deux ou trois décisions que cette personne devra assumer et ce qui changera concrètement dans le travail de l'équipe. Si vous ne pouvez pas les formuler, le besoin n'est probablement pas encore assez clair pour choisir entre Lead Dev et CTO.
Questions fréquentes
Un Lead Dev peut-il prendre des décisions d'architecture ?
Oui. Un Lead Dev prend régulièrement des décisions d'architecture proches de l'exécution, parce qu'elles déterminent la manière dont l'équipe construit et maintient le produit. La question est de savoir qui porte les arbitrages lorsque ces choix touchent aussi la roadmap, le budget, les prestataires ou les recrutements.
Faut-il un CTO dès que le produit gagne en traction ?
Non. La traction ne dit pas, à elle seule, quelle responsabilité manque. Si les décisions structurantes sont déjà portées et que l'équipe a surtout besoin de mieux livrer ensemble, un Lead Dev peut être le renfort adapté. Vous pouvez aussi avoir besoin d'une direction technique avant d'avoir beaucoup d'utilisateurs si un choix engage fortement la suite du produit.
Combien coûte un CTO à temps partiel ?
Le coût dépend du rythme, du périmètre de décision et de la responsabilité attendue. L'article combien coûte un CTO part-time explique les formats et les points à vérifier avant de comparer des offres.
Conclusion
Réservez un échange de 30 minutes pour clarifier la responsabilité technique qui manque aujourd'hui.