Cto

Situation réelle “Le CEO veut cette feature pour la démo client dans 1 semaine. Techniquement impossible sans casser tout le reste.” Dire non au CEO est l’un des moments les plus difficiles du rôle de CTO. Ce que j’ai observé : les CTOs qui ne disent jamais non perdent leur crédibilité technique. Ceux qui disent non sans alternative perdent leur crédibilité business. L’art est dans le “non, mais”. Le faux problème Le faux problème serait de croire qu’un bon CTO dit toujours oui. En réalité, dire oui à tout mène à des promesses impossibles et détruit la crédibilité à moyen terme. ...

Situation réelle “Le CPO veut 10 features ce trimestre. Moi je veux 3 sprints de dette technique. On fait comment ?” Ce conflit, c’est le quotidien de nombreux CTOs. Ce que j’ai observé : ce conflit est structurel. Le CPO optimize pour valeur utilisateur court terme, le CTO pour capacité long terme. Les deux ont raison selon leur perspective. Le faux problème Le faux problème serait de croire que l’un a tort et l’autre raison. En réalité, les deux perspectives sont légitimes. L’enjeu est de créer un cadre d’arbitrage partagé. ...

Situation réelle “On veut innover mais on ne peut pas se permettre d’instabilité.” Cette tension, tout CTO la ressent. Le business veut de la nouveauté, mais aussi que rien ne casse. Ce que j’ai observé : innovation et stabilité ne sont pas opposés. C’est une fausse dichotomie. L’enjeu est de créer les conditions pour innover sans mettre en danger la stabilité. Le faux problème Le faux problème serait de croire qu’il faut choisir entre les deux. En réalité, les organisations qui durent savent faire les deux simultanément, sur des timeboxes et scopes différents. ...

Situation réelle “On a 3 mois de dette technique accumulée. On la rembourse maintenant ou on continue à livrer des features ?” Cette question revient constamment, et la réponse change selon le contexte. Ce que j’ai observé : il n’y a pas de bon moment universel pour rembourser la dette. Mais il y a des signaux qui indiquent qu’il est temps d’investir. Le faux problème Le faux problème serait de croire qu’on peut toujours reporter. En réalité, la dette technique croît de manière exponentielle. Reporter trop longtemps mène à la paralysie. ...

Situation réelle “On livre maintenant avec de la dette, ou on prend 2 semaines de plus pour faire propre ?” Ce dilemme, tout CTO le rencontre quotidiennement. Et il n’y a jamais de bonne réponse universelle. Ce que j’ai observé : ni “toujours la qualité” ni “toujours la vitesse” ne marchent. L’arbitrage dépend du contexte, et le CTO porte la responsabilité de cet arbitrage. Le faux problème Le faux problème serait de croire qu’on peut toujours avoir les deux. En réalité, vitesse et qualité sont souvent en tension. L’enjeu est de choisir consciemment selon le contexte. ...

Situation réelle “Pourquoi on a choisi cette architecture ?” Cette question revient 6 mois après chaque décision importante. Sans documentation, le contexte est perdu, et on refait les mêmes débats. Ce que j’ai observé : les ADR (Architecture Decision Records) sont l’outil le plus sous-utilisé et le plus utile pour la gouvernance technique. Ils coûtent 30 minutes à écrire et économisent des heures de débats futurs. Le faux problème Le faux problème serait de croire que “le code se documente lui-même”. En réalité, le code explique le “comment”, pas le “pourquoi” ni les alternatives considérées. ...

Situation réelle “On doit choisir entre PostgreSQL et MongoDB. Le débat dure depuis 1 semaine, 2 camps s’opposent, aucun consensus.” Sans processus structuré, ces débats s’éternisent ou se terminent par une décision frustrante. Ce que j’ai observé : la RFC (Request for Comments) est un outil remarquablement efficace pour décider collectivement sans paralysie. Mais mal utilisée, elle devient bureaucratique. Le faux problème Le faux problème serait de croire que la RFC est juste “un doc technique”. En réalité, c’est un outil de gouvernance qui structure la prise de décision collective. ...

Situation réelle Jeff Bezos a popularisé le concept : Type 1 decisions (irréversibles, portes à sens unique) vs Type 2 decisions (réversibles, portes à double sens). Cette distinction change radicalement comment on décide. Ce que j’ai observé : traiter toutes les décisions comme irréversibles ralentit l’organisation. Traiter toutes les décisions comme réversibles crée des erreurs coûteuses. Distinguer les deux est crucial. Le faux problème Le faux problème serait de croire que la plupart des décisions sont irréversibles. En réalité, 80-90% des décisions tech sont réversibles. On les traite juste comme irréversibles par peur. ...

Situation réelle “On doit implémenter un système de paiement. On le code nous-mêmes, on prend Stripe, ou on s’associe avec un partenaire fintech ?” Cette question, tout CTO l’a déjà rencontrée des dizaines de fois. Ce que j’ai observé : la décision Build vs Buy vs Partner revient constamment. Sans cadre clair, elle se prend au feeling ou selon les préférences techniques. Avec un cadre, elle devient rationnelle. Le faux problème Le faux problème serait de croire qu’il existe une réponse universelle. “Toujours acheter” ou “Toujours construire” sont également faux. La bonne réponse dépend du contexte. ...

Situation réelle “Il nous faut ta décision sur la migration cloud maintenant, le board veut une réponse demain.” La pression transforme une décision stratégique qui mériterait 2 semaines d’analyse en un choix à faire en 24h. Ce que j’ai observé : les décisions stratégiques sous pression sont inévitables. L’enjeu n’est pas de les éviter, mais de structurer sa pensée pour décider rapidement sans être impulsif. Le faux problème Le faux problème serait de croire qu’on peut toujours prendre son temps. En réalité, certaines décisions ont des fenêtres temporelles serrées. L’enjeu est de décider vite ET bien. ...