Cto

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. ...

Situation réelle “J’ai délégué cette décision au Tech Lead, donc ce n’est plus ma responsabilité, non ?” Cette question révèle une confusion classique : déléguer l’autorité de décision ne supprime pas la responsabilité finale. Ce que j’ai observé : déléguer efficacement est l’un des leviers les plus puissants du CTO. Mal fait, ça crée soit du micro-management (délégation en apparence seulement), soit de l’abandon (délégation sans support). Le faux problème Le faux problème serait de croire que déléguer signifie “je ne suis plus concerné”. En réalité, déléguer signifie “je donne le pouvoir de décision mais je reste responsable du résultat”. ...

Situation réelle “On sait tous que cette architecture est morte, mais personne n’ose dire qu’il faut tout refaire.” “Cette personne ne performe pas depuis 6 mois, mais personne ne veut gérer.” “On devrait arrêter ce projet, mais le CEO y tient.” Ces décisions, personne ne veut les prendre. Elles finissent par remonter au CTO. Ce que j’ai observé : certaines décisions sont structurellement inconfortables. Elles impliquent des conflits, des déceptions, des risques. Le rôle de CTO inclut de prendre ces décisions que personne d’autre ne prendra. ...

Situation réelle L’équipe débat depuis 3 jours sur le choix entre PostgreSQL et MongoDB. Deux camps s’opposent, aucun consensus n’émerge. Dois-je trancher ou laisser le débat continuer ? Ce que j’ai observé : savoir quand intervenir est l’une des compétences les plus difficiles du rôle. Intervenir trop tôt déresponsabilise l’équipe. Intervenir trop tard laisse pourrir des situations bloquantes. Le faux problème Le faux problème serait de croire qu’il existe une règle universelle. En réalité, la décision d’intervenir dépend du contexte : urgence, impact, maturité de l’équipe, nature du conflit. ...