Decision

Situation réelle “Qui décide si on migre vers Kubernetes ?” “Qui valide le choix de cette librairie ?” “Est-ce que je peux changer cette architecture sans demander ?” Ces questions révèlent un flou sur qui décide quoi. Ce que j’ai observé : sans cadre clair de décision, soit tout remonte au CTO (bottleneck), soit tout le monde décide en silo (incohérence). Le bon équilibre est un cadre explicite qui donne de l’autonomie sans créer le chaos. ...

Situation réelle Tu réalises que tu es dans un environnement toxique. Anxiété dimanche soir, burn-out rampant, culture du blâme. La question n’est pas “est-ce toxique ?” mais “quand et comment je pars ?” Ce que j’ai observé : rester trop longtemps dans un environnement toxique détruit santé mentale, compétences, et confiance. Partir est souvent la décision la plus saine, même si difficile. Le faux problème Le faux problème serait de croire que tu dois “tenir” ou “faire tes preuves”. En réalité, rester dans un environnement toxique ne prouve rien sauf ta capacité à souffrir inutilement. ...

Situation réelle “Je m’ennuie, je pars.” Ou à l’inverse : “Je suis malheureux mais je reste par peur.” Ces deux extrêmes sont problématiques. Changer de boîte est une décision importante qui mérite réflexion. Ce que j’ai observé : les meilleurs changements sont réfléchis, motivés par attraction (vers quoi tu vas) pas juste répulsion (fuir d’où tu es). Le faux problème Le faux problème serait de croire qu’il faut rester 5 ans minimum dans chaque boîte. En réalité, 12-24 mois peut suffire si tu as appris ce que tu pouvais et que l’opportunité suivante est vraiment meilleure. ...

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