Tech au COMEX : pourquoi votre CTO ne se fait pas comprendre

Le jour du COMEX arrive, votre CTO présente un sujet en comité. Vous suivez, vous hochez la tête, mais au fond vous n'êtes pas certain d'avoir saisi ce qui se jouait vraiment. Vous votez le budget, ou vous le repoussez, mais dans les deux cas vous tranchez un peu à l'aveugle. Et la plupart des gens autour de la table sont dans le même cas que vous.

Cette situation arrive bien plus souvent que beaucoup de dirigeants n'aimeraient l'admettre. Votre CTO maîtrise son sujet, votre COMEX sait piloter une entreprise. Le problème est que la communication entre les deux ne se fait pas. Personne ne traduit la vision de l'un pour l'autre et vice versa. C'est exactement dans ce genre de situation que se prennent les mauvaises décisions.

Cet article s'adresse autant au dirigeant qu'au profil technique, car le pont qui les relie se construit des deux côtés à la fois.

Comex et CTO : deux visions qui s'ignorent

Commençons par le fond du malentendu, parce que tout part de là.

Quand vous pilotez une entreprise, vous pensez en trimestres, en retour sur investissement, en risque de marché. Quand votre CTO pense à sa plateforme, il raisonne en années, en fondations, en dette qui s'accumule silencieusement. Ce sont deux visions qui se confrontes et deux horloges ne tournent pas à la même vitesse. Le jour où il vous explique qu'une refonte se justifiera sur trois ans, il est parfaitement rationnel dans son cadre. Mais de votre point de vue, trois ans, c'est presque une autre vie.

Le but n'est pas d'essayer de savoir qui a raison ou qui a tord. Les deux sont dans le vrai, mais sous un prisme qui leur est propre. Un directeur financier qui réclame un ROI daté fait son métier. Un responsable technique qui refuse de bâtir sur du sable fait le sien. La friction naît quand ces deux logiques se croisent sans que personne ne les articule, chacun repartant convaincu que l'autre n'a pas vu l'évidence. Et c'est souvent sur ce terrain que l'organisation se bloque, alors même que tech et business veulent la même chose.

Ce que le comité entend quand la tech s'exprime

Commençons par regarder du côté du comex et de la direction. On observe 3 choses, presque à chaque fois.

D'abord, le jargon. Dès que les acronymes s'enchaînent, l'attention décroche, et un décideur qui a décroché ne tranche plus sur le fond : il signe par confiance ou il repousse par prudence.

Ensuite, la forme du sujet. Un chantier technique arrive presque toujours comme une dépense, sans bénéfice qu'on puisse toucher tout de suite ; face à un projet commercial qui promet du chiffre au prochain trimestre, il part perdant.

Et puis il y a la dette technique, ce mot que l'équipe répète et que le comité finit par entendre comme une excuse. "Il faut refactorer" devient, à l'autre bout de la table, "ils veulent se faire plaisir".

À force, deux réflexes s'installent au sein de la direction, aussi peu utiles l'un que l'autre. Signer sans comprendre, en faisant confiance faute de mieux. Ou mettre les mains dans un sujet qu'on ne maîtrise pas, et ralentir tout le monde. Dans les deux cas, la décision se prend sur autre chose que le fond.

Le rôle du CTO : traduire, pas seulement livrer

C'est justement là que le rôle du CTO prend tout son sens. C'est lui qui crée le pont entre le business et la tech. Cela ne veut pas dire que tout les efforts lui reviennent, mais il doit de son côté, faire le travail de traduire les enjeux tech en enjeux business.

Un des réflexe qu'on observe le plus souvent : présenter la solution avant d'avoir posé le problème que le business comprend. Un CTO arrive en comité avec "il faut qu'on migre vers une architecture microservices". Pour lui, la phrase est limpide. Pour le reste de la table, elle est intraduisible, et surtout elle répond à une question que personne ne s'est posée à voix haute. La même intervention devient audible dès lors qu'elle commence par le problème : "aujourd'hui, quand on veut lancer une nouvelle offre, il nous faut six semaines juste pour préparer la technique, et nos concurrents le font en deux." Là, le comité écoute, parce qu'il reconnaît un enjeu qui le concerne. La solution vient après, et elle se discute.

Rien de tout cela n'exige de simplifier à l'extrême. La bonne étape, c'est de partir de ce que l'autre comprend déjà, puis de redescendre vers la technique seulement si c'est utile à la décision. Traduire fait aujourd'hui partie du rôle, au même titre que livrer.

La responsabilité du dirigeant : poser les bonnes questions

L'autre moitié du chemin appartient aux dirigeants, et elle ne consiste absolument pas à vous mettre à coder. Un CEO ne sait pas forcément piloter un logiciel comptable, mais ça ne l'empêche pas de piloter ses finances. Pour la technologie, c'est pareil : le rôle côté dirigeant n'est pas de comprendre le comment, mais de poser les questions qui obligent à traduire.

Quelques questions suffisent le plus souvent :

- Qu'est-ce qu'on risque si on ne fait rien ?

- À partir de quand ce risque devient sérieux ?

- Est-ce qu'on peut réparer plus tard, ou est-ce que la fenêtre se referme ?

- Et combien nous coûte l'attente, chaque mois qui passe ?

Aucune ne demande la moindre compétence technique, et toutes forcent votre équipe à reformuler son sujet en conséquences concrètes. Posez-les systématiquement, et vous verrez tout votre COMEX apprendre à mieux lire la tech sans même s'en rendre compte.

Il reste une exigence qu'on formule rarement : donnez au sujet technique un vrai moment dans votre agenda, ailleurs qu'en pleine crise. Une tech qu'on ne regarde que lorsqu'elle casse ne se comprend jamais à froid, et se pilote donc toujours avec un train de retard.

Gouvernance de la tech : trois habitudes qui changent tout

Quelques habitudes suffisent, à condition de les tenir dans la durée.

1. Décidez ensemble que tout sujet technique s'expose d'abord en risque et en impact, avant le moindre détail d'exécution. Ce n'est pas une compétence à acquérir, c'est une règle de présentation, et elle change tout.

2. Réservez à la tech un créneau régulier, au même titre que le commercial ou la finance, plutôt que de la traiter par à-coups. Et prenez le temps, une fois, de vous mettre d'accord sur le vocabulaire : rien n'interdit à un CTO de tenir un petit glossaire des termes qui reviennent, ça évite bien des quiproquos.

3. Quand le fossé reste trop large malgré tout, un tiers capable de parler les deux langues débloque souvent en quelques semaines ce qui traînait depuis des mois.

‍

Ces habitudes demandent uniquement un peu de méthode et l'envie réelle de se comprendre. Mises bout à bout, elles font passer la tech d'un poste qu'on subit à un sujet qu'on pilote, et elles évitent la plupart des erreurs de gouvernance tech que commettent les CEO.

‍

FAQ

Comment un dirigeant non technique peut-il évaluer un projet tech ?

En déplaçant ses questions du "comment" vers le "pourquoi" et le "combien" : qu'est-ce qu'on risque si on ne fait rien, à partir de quand ce risque devient sérieux, combien coûte l'attente. Ces questions ne réclament aucune compétence technique et obligent l'équipe à traduire son sujet en conséquences concrètes, le seul terrain sur lequel un dirigeant peut vraiment arbitrer.

Pourquoi les sujets techniques passent-ils mal en comité de direction ?

Parce que la technique et le business ne raisonnent ni sur le même horizon ni avec les mêmes repères : l'un pense en années et en systèmes, l'autre en trimestres et en retour sur investissement. S'ajoutent le jargon, qui fait décrocher, et l'habitude de présenter les chantiers techniques comme des coûts plutôt que comme des risques évités. Le malentendu est de structure, pas de personnes.

Faut-il un CTO au COMEX ?

Sa présence aide, mais ne règle rien à elle seule : un CTO qui ne parle que technique restera incompris, même avec un siège à la table. Ce qui compte, c'est sa capacité à traduire ses enjeux en risque et en impact, et la volonté du reste du comité de traiter la tech comme un vrai sujet de direction plutôt que comme une boîte noire à financer.