Décision

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

Stratégies du livre “Être ou ne pas être CTO”, chapitre “Gérer la dette technique”. Situation réelle “On doit refactoriser tout le code !” Cette injonction revient régulièrement dans les équipes techniques. Elle traduit souvent une frustration légitime face à un code qui ralentit le développement, mais elle masque une question plus fondamentale : qu’est-ce qui est vraiment de la dette technique, et qu’est-ce qui est simplement du code qu’on n’aime pas ? ...

Basé sur “Être ou ne pas être CTO”, chapitre “Définir la stratégie technique”. Situation réelle “Notre vision technique ? Euh… on fait du bon code ?” Cette réponse revient souvent quand on demande à une équipe technique quelle est sa vision. Elle traduit une absence de stratégie claire, mais aussi une difficulté à articuler une vision technique qui guide les décisions au quotidien. Ce que j’ai observé : une vision technique n’est pas une liste de technologies cool à adopter. C’est une stratégie claire qui explique où vous êtes, où vous allez, comment vous y allez, et pourquoi. Sans cette vision, les décisions techniques deviennent réactives plutôt que stratégiques, et l’équipe perd son cap. ...

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 Incident majeur. Production down. Clients impactés. CEO qui appelle. Board qui demande des comptes. L’équipe est stressée. Comment communiquer dans ce chaos ? Ce que j’ai observé : la communication en crise révèle la vraie maturité d’un CTO. Paniquer contagie la panique. Mentir détruit la confiance. Dire la vérité calmement crée de la confiance durable. Le faux problème Le faux problème serait de croire qu’il faut tout expliquer immédiatement. En réalité, en pleine crise, on ne sait souvent pas tout. L’enjeu est de communiquer ce qu’on sait, ce qu’on ne sait pas, et ce qu’on fait. ...

Situation réelle “On a un incident majeur.” “Depuis quand ce problème existe ?” “Euh… probablement 6 mois.” La plupart des crises tech sont prévisibles si on sait où regarder. Ce que j’ai observé : les bons CTOs ne sont pas plus chanceux que les autres. Ils ont juste des systèmes pour voir les risques avant qu’ils explosent. Le faux problème Le faux problème serait de croire qu’on peut prévenir toutes les crises. En réalité, certaines sont imprévisibles. L’enjeu est de détecter et prévenir les 80% qui sont prévisibles. ...

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