Situation réelle

“Le CEO veut cette feature pour demain, l’équipe produit dit que c’est critique, les commerciaux ont promis au client. Mais techniquement, c’est une dette massive qu’on mettra des mois à rembourser.”

Ce que j’ai observé : les moments les plus difficiles du rôle de CTO ne sont pas quand tout le monde est aligné, mais quand dire la vérité technique implique de décevoir des attentes légitimes. Dire non dans ces situations demande plus de courage que n’importe quelle décision technique.

Le faux problème

Le faux problème serait de croire qu’un bon CTO dit toujours oui pour ne pas bloquer le business. En réalité, un CTO qui ne dit jamais non crée une dette technique qui finira par bloquer le business de manière bien plus coûteuse.

Un autre faux problème : penser que dire non détruit nécessairement la confiance. En réalité, dire un non argumenté et proposer des alternatives renforce la crédibilité à long terme.

Le vrai enjeu CTO

Le vrai enjeu est de comprendre quand dire non, comment le faire, et comment proposer des chemins alternatifs :

Pourquoi dire non est nécessaire : Le CTO est souvent le seul à voir les conséquences techniques à long terme. Le CEO voit le marché, le CPO voit l’utilisateur, mais personne ne porte la cohérence technique dans le temps. Dire oui à tout, c’est abandonner cette responsabilité.

La tension entre court terme et long terme : Le business pense en trimestres, la tech accumule sur des années. Une décision qui semble mineure aujourd’hui (un raccourci, une feature mal architecturée) peut devenir structurante et impossible à défaire 18 mois plus tard.

Le coût du oui systématique : Chaque oui non réfléchi ajoute de la dette. Au début, c’est invisible. Puis un jour, la vélocité s’effondre, l’équipe passe plus de temps à corriger qu’à livrer, et le CEO demande “Pourquoi vous êtes si lents ?” La réponse : “Parce qu’on a dit oui à tout pendant 2 ans.”

Dire non pour protéger l’équipe : Quand la pression devient insoutenable, quand les délais sont irréalistes, quand le scope dérive. Dire non, c’est parfois protéger l’équipe du burn-out et de l’échec annoncé.

Cadre de décision

Voici comment je décide quand dire non et comment le faire :

1. Les situations où je dis non

  • Délais impossibles qui mèneraient à un échec ou un burn-out
  • Dette technique qui hypothèquerait la capacité future (coût de remboursement > 3× la valeur immédiate)
  • Compromis de sécurité inacceptables
  • Demandes qui créent une incohérence architecturale majeure
  • Surcharge d’une équipe déjà en limite

2. Comment je dis non Jamais juste “non”, toujours “non, mais voici pourquoi et voici les alternatives”. Expliquer le raisonnement en termes business (pas juste technique), proposer des options, négocier le scope ou le timing.

3. Le cadre dette technique Si livrer maintenant crée une dette X et que la rembourser coûtera 3X dans 6 mois, il vaut mieux dire non. Si la dette est 1.5X et le remboursement possible en parallèle, on peut dire oui avec un plan de remboursement explicite.

4. Négocier le scope, pas juste refuser “On ne peut pas livrer les 10 features en 2 semaines, mais on peut livrer les 3 critiques en 1 semaine avec qualité. Qu’est-ce qui a le plus de valeur ?” Cette approche transforme le non en négociation constructive.

5. Dire non tôt plutôt que tard Un non dit au bon moment évite 3 mois de travail dans la mauvaise direction. Un non dit trop tard après que tout le monde s’est engagé créé frustration et perte de crédibilité.

Retour terrain

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

Le oui systématique qui détruit : Un CTO qui ne dit jamais non, accepte tous les délais, toutes les features. Résultat : dette technique explosive, vélocité qui s’effondre après 18 mois, burn-out de l’équipe, perte de crédibilité quand les promesses ne sont plus tenables.

Le non brutal qui isole : Un CTO qui dit non sans explication ni alternative. “C’est impossible techniquement.” Résultat : le business contourne la tech, les décisions importantes sont prises sans lui, isolement progressif.

Le non argumenté qui convainc : “Cette timeline n’est pas réaliste. Voici pourquoi avec des données. Voici 3 options : réduire le scope de 50%, doubler le temps, ou accepter une dette qu’on remboursera en 3 mois. Laquelle préférez-vous ?” Cette approche transforme le non en décision collaborative.

La crédibilité qui se construit : Dire non sur une feature, proposer une alternative plus simple, livrer rapidement. Six mois plus tard, découvrir que la version simple satisfait 90% des besoins et a évité 3 mois de complexité inutile. Cette expérience construit la confiance pour les prochains non.

Erreurs fréquentes

Ne jamais dire non Accepter toutes les demandes pour ne pas bloquer le business. Résultat : dette technique explosive, vélocité qui s’effondre, équipe épuisée, promesses impossibles à tenir.

Dire non sans alternative Refuser sans proposer d’options. Résultat : le business voit le CTO comme un bloqueur, pas comme un partenaire. Contournement des décisions techniques.

Dire non trop tard Attendre que tout le monde soit engagé avant d’exprimer des doutes. Résultat : frustration massive, perception d’incompétence (“Pourquoi tu ne l’as pas dit plus tôt ?”).

Argumenter uniquement en termes techniques “Cette architecture est mauvaise techniquement.” Le business ne comprend pas, ne s’en soucie pas. Mieux vaut : “Cette approche nous ralentira de 40% dans 6 mois.”

Si c’était à refaire

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

Dire non plus tôt et plus souvent Ne pas attendre que la situation devienne critique. Exprimer mes doutes dès que je les perçois, même si je n’ai pas toutes les réponses.

Toujours proposer 3 alternatives Transformer chaque non en négociation : option rapide-et-sale avec dette documentée, option équilibrée avec scope réduit, option robuste avec plus de temps. Laisser le business choisir selon les priorités.

Mesurer et partager l’impact du non Documenter les fois où dire non a évité des problèmes. Cette visibilité construit la crédibilité pour les prochains refus.

Créer un cadre de décision partagé Plutôt que de dire non de manière ad hoc, créer un framework de décision partagé avec le CEO : critères de qualité non négociables, capacité maximale de l’équipe, règles d’arbitrage dette vs features.

Pour approfondir

Le livre “Être ou ne pas être CTO” explore comment différents CTOs gèrent la tension entre pression business et responsabilité technique.

Pour approfondir, tu peux aussi consulter l’article sur “La dette technique” ou les autres contenus du pilier “Le rôle du CTO”.