Leadership

Article basé sur le livre “Être ou ne pas être CTO”, chapitre “Le rôle de CTO démystifié”. Situation réelle “Je veux devenir CTO.” Cette ambition est légitime, mais elle masque souvent une confusion sur ce que représente réellement ce rôle. Dans la pratique, j’observe que beaucoup confondent CTO, Lead Developer et VP Engineering, trois rôles aux responsabilités et aux enjeux distincts. Cette confusion crée des attentes décalées : des développeurs qui visent le titre CTO sans comprendre qu’ils devront coder moins, des organisations qui nomment CTO quelqu’un qui devrait être VP Engineering, des carrières qui s’orientent vers un rôle qui ne correspond pas à leurs aspirations réelles. ...

Situation réelle “En tant que CTO, tu décides de la stack, non ?” Cette question revient régulièrement. Elle traduit une vision simplifiée du rôle : le CTO comme celui qui tranche, qui impose, qui décide de la direction technique. Ce que j’ai observé après 17 ans dans ce métier : le poids du rôle de CTO ne réside pas principalement dans les décisions qu’on prend, mais dans ce qu’on porte pour l’équipe et l’organisation. Une responsabilité invisible qui se manifeste dans les non-dits, les arbitrages silencieux, les angles morts qu’on surveille. ...

Situation réelle “Notre nouveau CTO était le meilleur dev de l’équipe.” Cette phrase, je l’ai entendue des dizaines de fois. Elle traduit une croyance répandue : le CTO devrait être le développeur le plus talentueux de l’organisation. Ce que j’ai observé : cette croyance crée des attentes décalées et des promotions ratées. Le meilleur développeur ne fait pas nécessairement un bon CTO. Pire, promouvoir systématiquement les meilleurs devs au rôle de CTO prive l’organisation d’excellents contributeurs techniques et crée des CTOs malheureux. ...

Situation réelle “Personne ne comprend vraiment ce que je porte.” Cette phrase, je l’ai entendue de la bouche de dizaines de CTOs, et je l’ai moi-même prononcée. Elle traduit une réalité peu discutée du rôle : une solitude structurelle qui ne vient pas d’un manque de relations, mais de la nature même des responsabilités. Ce que j’ai observé : cette solitude n’est ni un mythe romantique ni une fatalité à subir. C’est une conséquence de l’asymétrie informationnelle et décisionnelle du rôle. Comprendre sa source permet de mieux la gérer. ...

Situation réelle Après avoir observé, accompagné et échangé avec des dizaines de CTOs, certains patterns d’erreurs reviennent systématiquement. Pas par manque de compétence technique, mais par mécompréhension de ce que le rôle demande vraiment. Ce que j’ai observé : ces erreurs ne sont pas des défauts personnels, ce sont des pièges structurels du rôle. Comprendre ces patterns permet de les reconnaître chez soi avant qu’ils deviennent toxiques. Le faux problème Le faux problème serait de croire qu’il existe une “bonne” posture de CTO universelle. En réalité, la posture doit s’adapter au contexte : taille d’organisation, maturité technique, culture existante. ...

Situation réelle “L’IA va-t-elle remplacer les développeurs ?” Cette question, tous les CTOs la reçoivent depuis 2023. Mais la vraie question est : comment l’IA transforme-t-elle le rôle de CTO et les responsabilités qui vont avec ? Ce que j’ai observé : l’IA générative ne remplace pas le rôle de CTO, elle le transforme. Certaines responsabilités deviennent obsolètes, d’autres émergent, et la posture doit évoluer. Le faux problème Le faux problème serait de croire que l’IA est juste un nouvel outil qu’on intègre comme les autres. En réalité, c’est une transformation aussi profonde que le passage au cloud ou au mobile. ...

Situation réelle Dans le monde du développement logiciel, il existe une tentation récurrente : celle de tout jeter pour recommencer à zéro. Face à une application devenue difficile à maintenir, truffée de bugs ou dont le code ressemble à un plat de spaghetti, la solution de la refonte complète apparaît souvent comme la panacée. Ce que j’ai observé : la dette technique s’accumule inexorablement au fil des années dans les applications. Le code devient de plus en plus difficile à maintenir, les correctifs s’empilent sans réelle cohérence, et la documentation, quand elle existe, ne reflète plus la réalité du système. Les tests automatisés, s’ils ont été mis en place, ne couvrent souvent qu’une partie minime des fonctionnalités ou sont devenus obsolètes. ...

Situation réelle “Je pars dans 3 mois. Mon successeur arrive dans 1 mois. Comment lui transmettre 3 ans de contexte et de décisions sans le noyer ni disparaître brutalement ?” Cette question, tout CTO qui part proprement se la pose. Ce que j’ai observé : une bonne succession se prépare des mois à l’avance et continue quelques semaines après le départ. Une mauvaise succession crée du chaos pour des mois. ...

Situation réelle “On vient de lever 5M€. Le board veut scaler à 50 personnes en 18 mois. Hier on était 8 développeurs qui se parlaient autour d’une table. Aujourd’hui on me demande une roadmap tech à 3 ans et un plan de recrutement.” Cette accélération brutale, beaucoup de CTOs la vivent mal préparés. Ce que j’ai observé : la levée de fonds change radicalement les attentes envers le CTO. Ce qui était valorisé avant (coder, livrer vite, être proche du produit) devient secondaire. Ce qui devient critique (recruter, structurer, anticiper) n’a jamais été pratiqué. ...

Situation réelle “Quand je suis devenu CTO, je codais 60% du temps. Aujourd’hui, 10%. Quand je suis devenu CTO, je pensais en sprints. Aujourd’hui, je pense en trimestres et années.” Cette évolution, beaucoup de CTOs la vivent sans la choisir consciemment. Ce que j’ai observé : le rôle de CTO évolue avec la croissance de l’organisation. Le CTO qui code 80% à 5 personnes doit devenir stratégique à 50 personnes. Cette transition est difficile car elle demande d’abandonner ce qui a fait son succès initial. ...