Situation réelle

Un CTO prépare sa première présentation au board. Il ouvre avec un slide sur la dette technique, enchaîne sur l’architecture microservices, parle de couverture de tests et de temps de déploiement. Quinze minutes plus tard, un membre du board demande : « Et concrètement, quel est l’impact sur le chiffre d’affaires ? » Le CTO bafouille. La confiance est entamée. Pas parce que le travail technique est mauvais — mais parce que la traduction n’a pas été faite.

Ce que j’ai observé, après avoir assisté à — et raté — plusieurs de ces exercices : la relation CTO/board ne se joue pas sur la qualité technique. Elle se joue sur la capacité à traduire la tech en décisions business.

Le faux problème

La plainte habituelle : « Le board ne comprend rien à la tech. »

En réalité, ce n’est pas son rôle de comprendre la tech. Le board comprend le risque, la croissance, les coûts, le timing et la stratégie. Si le CTO parle de Kubernetes au board, le problème n’est pas le board. C’est le CTO.

L’autre piège : croire qu’il suffit de « vulgariser ». Vulgariser, c’est simplifier un concept technique pour un public non technique. Ce n’est pas ça que le board attend. Le board attend des réponses à trois questions : quel est le risque ? Quel est le coût ? Quel est l’impact sur la trajectoire de l’entreprise ?

Le vrai enjeu CTO

Le vrai enjeu n’est pas technique. C’est un enjeu de traduction stratégique. Le CTO est le seul dans la salle qui comprend à la fois la réalité technique et ses implications business. S’il ne fait pas le lien, personne ne le fera à sa place.

Ce que le board attend réellement

  • De la lisibilité. Pas un état des lieux technique exhaustif, mais une photo claire de la situation : où en est-on ? Quels sont les risques ? Qu’est-ce qui avance, qu’est-ce qui bloque ?
  • Des arbitrages explicites. La tech est faite de compromis. Le board veut comprendre quels compromis ont été faits, pourquoi, et quelles sont les conséquences.
  • De la prévisibilité. Pas des estimations au jour près, mais une capacité à dire : « Dans trois mois, on sera là. Si tel risque se matérialise, on sera plutôt là. »
  • De la confiance. Le board ne peut pas vérifier le travail technique. Il fait confiance au CTO. Cette confiance se gagne par la clarté, la constance et l’honnêteté — pas par l’expertise.

Les trois langages du CTO

Un CTO navigue entre trois langages :

  • Le langage technique — celui de l’équipe. Précis, concret, orienté implémentation.
  • Le langage produit — celui du CEO et du CPO. Orienté utilisateur, valeur, roadmap.
  • Le langage stratégique — celui du board. Orienté risque, coût, trajectoire, compétitivité.

La plupart des CTO maîtrisent les deux premiers. C’est le troisième qui manque souvent. Et c’est celui qui détermine la crédibilité face au board.

Cadre de décision

Avec le recul, voici les principes qui m’ont aidé à structurer cette traduction.

  1. Partir de l’impact, pas de la cause. Ne pas dire : « On a de la dette technique sur le module de paiement. » Dire : « Le module de paiement ralentit notre capacité à lancer de nouvelles offres. Chaque nouvelle intégration prend trois semaines au lieu de trois jours. » Le board comprend le coût d’opportunité. Il ne comprend pas la dette technique.

  2. Quantifier quand c’est possible. « La fiabilité de la plateforme est passée de 99,2 % à 99,8 % ce trimestre. » « Le temps de mise en production est passé de deux semaines à deux jours. » Les chiffres ne sont pas toujours parfaits, mais ils ancrent la discussion dans le réel. Sans chiffres, la tech reste abstraite.

  3. Nommer les risques avant qu’ils n’arrivent. Le board déteste les surprises. Un CTO qui dit « il y a un risque sur X, voici comment on le gère » gagne en crédibilité. Un CTO qui découvre le problème en même temps que le board la perd. Mieux vaut signaler un risque qui ne se matérialise pas que de taire un risque qui explose.

  4. Distinguer l’urgent du structurel. Le board confond souvent les deux. C’est au CTO de clarifier : « Ce sujet est un incident ponctuel, il est résolu. Ce sujet est structurel, il nécessite un investissement sur six mois. » Sans cette distinction, chaque incident devient une crise.

  5. Proposer des options, pas des solutions uniques. « On peut faire A, avec tel coût et tel risque. Ou B, avec tel autre compromis. Je recommande A pour telle raison. » Le board veut participer à la décision, pas la subir. Lui donner des options, c’est le respecter.

Retour terrain

Situation 1 — Un CTO présente un plan de migration cloud au board. Il parle d’AWS, de conteneurs, de scaling horizontal. Le board valide sans comprendre, par confiance. Six mois plus tard, le budget dérape de 40 %. Le board se sent trahi. En réalité, le CTO avait sous-estimé les coûts — mais surtout, il n’avait pas partagé les hypothèses ni les risques.

Situation 2 — Un CTO présente le même type de migration, mais différemment. « On investit 200K sur six mois pour réduire nos coûts d’infrastructure de 35 % par an. Le risque principal est un retard de deux mois si l’intégration avec le système legacy est plus complexe que prévu. Dans ce cas, l’économie sera de 25 % la première année au lieu de 35 %. » Le board challenge, pose des questions, ajuste. La relation est saine.

Situation 3 — Un CTO cache un problème de sécurité au board parce que « c’est technique, ils ne comprendraient pas ». Le problème fuite six mois plus tard via un audit externe. Le CTO perd sa crédibilité. Non pas parce que le problème existait — mais parce qu’il n’en avait pas parlé.

Ce que j’ai constaté : la transparence, même inconfortable, construit plus de confiance que l’expertise la plus brillante.

Erreurs fréquentes

  • Parler technique au board. Le réflexe naturel du CTO est de montrer sa maîtrise. Mais chaque terme technique non traduit creuse un fossé. Le board ne dira pas qu’il ne comprend pas — il retiendra que le CTO ne sait pas communiquer.
  • Promettre des délais irréalistes. Sous la pression du board, accepter des timelines intenables pour « ne pas décevoir ». Le prix se paie toujours plus tard — en dérapage, en qualité, en crédibilité.
  • Être en réaction permanente. Répondre aux questions du board sans jamais prendre l’initiative de cadrer le sujet. Un CTO qui ne propose que des réponses est perçu comme un exécutant. Un CTO qui arrive avec une vision est perçu comme un leader.
  • Ignorer la politique. Le board a ses dynamiques internes : alliances, tensions, agendas. Les ignorer, c’est naviguer à l’aveugle. Il ne s’agit pas de faire de la politique — mais de comprendre le contexte dans lequel on intervient.

Si c’était à refaire

  • Je préparerais chaque board comme une présentation stratégique, pas comme un reporting technique. La question de départ ne serait jamais « qu’est-ce qu’on a fait ? » mais « qu’est-ce que le board a besoin de savoir pour prendre les bonnes décisions ? ».
  • Je testerais mes slides avec le CEO avant le board. Pas pour obtenir sa validation, mais pour vérifier que la traduction fonctionne.
  • Je garderais un document vivant — un « tech brief » trimestriel d’une page — que le board peut consulter entre les sessions. Ça réduit les surprises et installe une routine de transparence.
  • Je nommerais les désaccords ouvertement. « Je ne suis pas aligné avec cette décision, voici pourquoi. » Un CTO qui dit toujours oui n’est pas un partenaire. C’est un prestataire.

Pour approfondir