Situation réelle

“Je suis CTO mais je passe 80% de mon temps à coder.” “Je suis CTO mais je n’ai aucun pouvoir de décision.” “Je suis CTO mais on ne m’écoute jamais.” Ces phrases révèlent un décalage entre le titre et la réalité du rôle.

Ce que j’ai observé : le titre de CTO peut masquer des dysfonctionnements organisationnels ou servir de cache-misère. Reconnaître ces dérives permet soit de les corriger, soit de partir avant de s’y perdre.

Le faux problème

Le faux problème serait de croire qu’il existe une définition universelle du rôle de CTO. Le rôle varie selon la taille, la maturité, et le contexte. Mais certaines dérives sont toxiques quel que soit le contexte.

Un autre faux problème : penser que ces dérives sont rares. En réalité, elles sont fréquentes, surtout dans les startups early stage ou les organisations immatures techniquement.

Le vrai enjeu CTO

Le vrai enjeu est de reconnaître les dérives toxiques et de décider si elles sont corrigeables :

Dérive #1 : CTO = développeur senior avec un titre Réalité : code 80% du temps, aucune responsabilité stratégique, aucun pouvoir décisionnel. Le titre sert à attirer ou retenir, pas à décrire le rôle réel. Impact : frustration mutuelle, aucun impact stratégique, perte de temps.

Dérive #2 : CTO = fusible en cas d’échec technique Réalité : aucun pouvoir de décision ni budget, mais responsable de tous les échecs techniques. Le titre sert à avoir un responsable à blâmer. Impact : position intenable, burn-out, départ rapide.

Dérive #3 : CTO = interface avec les développeurs Réalité : le CEO ou le CPO prend toutes les décisions techniques, le CTO ne fait que transmettre et exécuter. Impact : rôle vidé de sens, perte de crédibilité, équipe désorientée.

Dérive #4 : CTO = architecte isolé Réalité : focus uniquement sur l’architecture idéale, déconnecté des contraintes business et des capacités de l’équipe. Impact : solutions non applicables, frustration du business, isolement progressif.

Dérive #5 : CTO = pompier permanent Réalité : passe tout son temps en mode urgence sans jamais pouvoir adresser les causes profondes. Impact : dette technique qui explose, équipe épuisée, aucune vision stratégique.

Dérive #6 : CTO = titre sans équipe Réalité : “CTO” d’une équipe de 2 personnes ou d’une organisation sans tech réelle. Le titre sert à valoriser mais ne correspond à aucune réalité. Impact : CV gonflé, compétences non développées, difficultés futures.

Cadre de décision

Voici comment je détecte ces dérives et décide si elles sont corrigeables :

1. Poser les questions de clarification

  • Quelle est ma capacité de décision réelle ?
  • Ai-je un budget et une équipe ?
  • Mes décisions sont-elles écoutées ou systématiquement overridées ?
  • Ai-je du temps pour la stratégie ou suis-je 100% opérationnel ?

2. Observer les signaux d’alarme

  • Je code plus de 50% du temps sans que ce soit un choix
  • Mes propositions stratégiques sont systématiquement ignorées
  • Je n’ai pas accès au board ou au comex
  • Je découvre les décisions techniques après qu’elles soient prises
  • Je n’ai aucun budget ni pouvoir de recrutement

3. Distinguer phase normale et dérive structurelle Startup 0-5 personnes : normal de coder 60% et d’avoir peu de budget. Startup 20-50 personnes : anormal de ne pas avoir de pouvoir décisionnel. Le contexte change le diagnostic.

4. Tenter de corriger avant de partir Discuter avec le CEO : clarifier les attentes, demander les moyens, proposer un plan. Si rien ne change après 3-6 mois, c’est une dérive structurelle.

5. Accepter de partir si non corrigeable Certaines dérives ne se corrigent pas. Rester dans un rôle vidé de sens détruit les compétences et la crédibilité à long terme.

Retour terrain

Ce que j’ai observé dans différentes organisations :

Le faux CTO startup : Titre donné au premier développeur pour attirer. Réalité : code 90%, zéro décision stratégique, pas d’équipe. Deux ans plus tard, difficultés à expliquer en interview pourquoi “CTO de 2013 à 2015” se résume à du développement.

Le CTO fusible : Recruté pour “fix la tech”. Aucun budget, aucun pouvoir, mais responsable de tous les problèmes. Part au bout de 8 mois, épuisé et blamed pour l’échec.

Le CTO qui corrige : Identifie la dérive (dérive #3), en discute avec le CEO, clarifie les responsabilités, obtient un budget. Six mois plus tard, rôle cohérent et impact réel.

Le CTO qui part à temps : Réalise après 3 mois que le rôle est une dérive #2. Plutôt que de rester et s’épuiser, part avant que ça détruise sa crédibilité.

Erreurs fréquentes

Accepter le titre sans clarifier le rôle Prendre le poste de CTO sans discuter concrètement des responsabilités, du pouvoir de décision, du budget. Résultat : découverte tardive que le titre ne correspond à aucune réalité.

Rester dans une dérive structurelle Espérer que ça va s’améliorer alors que rien ne change après 12 mois. Résultat : compétences qui stagnent, crédibilité qui baisse, difficultés à retrouver un vrai rôle de CTO ailleurs.

Accepter toutes les dérives “parce que c’est une startup” Utiliser le contexte startup pour justifier n’importe quelle dérive. Résultat : normalisation de dysfonctionnements qui ne devraient pas l’être.

Ne pas documenter les tentatives de correction Tenter de corriger sans documenter les échanges et décisions. Résultat : impossibilité de prouver qu’on a essayé si ça tourne mal.

Si c’était à refaire

Avec le recul, voici ce que je ferais différemment :

Clarifier les attentes avant d’accepter Discuter concrètement : quelle capacité de décision ? Quel budget ? Quelle équipe ? Quelle répartition de temps ? Cette clarification évite les mauvaises surprises.

Donner 3-6 mois pour corriger, pas 2 ans Identifier la dérive tôt, tenter de corriger, et partir si rien ne change. Rester 2 ans dans un faux rôle détruit plus de valeur qu’on ne pense.

Documenter les désaccords et tentatives Garder trace des échanges sur les responsabilités et les moyens. Cette documentation protège en cas de conflit et clarifie les positions.

Ne pas accepter un titre CTO trop tôt Avant 30-40 personnes, Staff Engineer ou Engineering Manager sont souvent plus honnêtes que CTO. Accepter un vrai rôle plutôt qu’un titre prestigieux mais vide.

Pour approfondir

Le livre “Être ou ne pas être CTO” explore ces dérives avec des témoignages de CTOs qui ont vécu ces situations.

Pour approfondir, tu peux aussi consulter l’article “CTO vs Lead Dev vs VP Engineering” ou les autres contenus du pilier “Le rôle du CTO”.