Pour qui ? Ma méthode Compétences Réalisations Avis Contact

Manuel de survie

du futur CTO

Photo principale: Manuel de survie

Manuel de survie du futur CTO : Petit lexique pour ceux qui pensaient que la technique suffisait

Pendant des années, vous avez été le meilleur dans la pièce dès qu'il s'agissait de code.

Vous connaissiez vos architectures par cœur. Vous pouviez déboguer un problème de performance à 2h du matin. Vous aviez des opinions tranchées sur les frameworks — et vous aviez souvent raison.

Et puis un jour, vous regardez des postes de CTO. Vous passez les premiers entretiens. Et quelqu'un en face de vous dit une phrase du genre : "On aura besoin de vous au CODIR pour défendre le budget de la BU, avec un suivi COPIL mensuel aligné sur nos OKR."

Vous souriez. Vous hochez la tête.
Vous ne comprenez rien.

Ce lexique est pour vous.

CODIR — L'endroit où la technologie devient politique

Le Comité de Direction, c'est là où les grandes décisions se prennent : stratégie, investissements, priorités. Ce que personne ne vous dit avant d'y entrer pour la première fois : on ne parle pas de technologie. On parle de l'entreprise. Et la technologie, elle, est quelque part entre les lignes.

🏛️

Un problème d'infrastructure devient une question de budget. Un choix d'architecture devient un arbitrage entre deux directions métier. Une dette technique accumulée devient un risque stratégique qu'il faut expliquer à des gens qui n'ont jamais ouvert un terminal. Au CODIR, vous ne défendez plus une solution technique. Vous défendez un point de vue sur l'avenir de l'entreprise. C'est un autre métier.

Le jargon stratégique et opérationnel

COMEX — Le niveau au-dessus, où votre nom n'est jamais cité

Le Comité Exécutif est le lieu des décisions structurantes : acquisitions, pivots majeurs, réorganisations. Si le CODIR pilote, le COMEX définit où on va. En tant que CTO, vous n'y siégez pas toujours. Mais vous en subissez toujours les conséquences.

La leçon : ce qui se décide sans vous peut vous tomber dessus très vite. Il vaut mieux avoir un relai au COMEX qu'espérer être épargné.

BU — Quand une entreprise devient plusieurs entreprises

Une Business Unit, c'est une division organisée autour d'un produit, d'un marché ou d'une activité. Dans une startup, tout le monde travaille sur la même chose. Dans une organisation plus grande, plusieurs BU coexistent — chacune avec ses objectifs, son budget, ses priorités.

Ce n'est plus "comment construire un bon produit ?". C'est "comment construire une plateforme qui serve plusieurs produits, plusieurs équipes, plusieurs directions — sans que tout parte en chaos ?"

COPIL — La réunion que vous trouviez inutile...

Le Comité de Pilotage suit les projets importants. Avancement, risques, budgets. Pour quelqu'un habitué aux sprints agiles, ça semble lourd. Puis vous pilotez votre premier projet transverse avec cinq équipes et un gros budget.

Sans COPIL, chaque partie prenante s'invente sa propre version de l'avancement. Avec, au moins, tout le monde lit le même tableau de bord.

COMOP — Là où les décisions deviennent du travail réel

Le Comité Opérationnel, c'est l'étage en dessous du COPIL. Moins de stratégie, plus d'exécution. C'est l'endroit où on découvre que la décision prise au COPIL la semaine dernière était techniquement impossible.

En pratique, c'est souvent aussi l'endroit où naissent les tickets Jira les plus cryptiques de l'histoire de votre backlog.

OKR — L'outil qui force à répondre à une question gênante

Objectives and Key Results. Un objectif ambitieux, quelques résultats mesurables. Quand on vous demande de définir les OKR, vous réalisez parfois que vous ne savez pas répondre à : "En quoi ce qu'on construit améliore concrètement les résultats de l'entreprise ?"

Les OKR transforment une roadmap de fonctionnalités en une liste d'impacts attendus. C'est inconfortable — et c'est exactement pour ça que c'est utile.

KPI — Les chiffres qui racontent ce que le code produit

Les Key Performance Indicators mesurent la santé d'une activité. Vous avez vos KPI techniques (latence, erreurs). L'entreprise a les siens (revenu, rétention). Un CTO apprend à faire le lien entre les deux colonnes.

Si vous ne faites pas ce lien vous-même, quelqu'un d'autre décidera à votre place si votre travail a de la valeur.

PO / PM — Vos meilleurs alliés ou votre source de friction

Product Owner / Product Manager. Pour un CTO, cette relation est centrale. Une bonne collaboration produit-tech, c'est une organisation qui avance vite. Une mauvaise, c'est des réunions qui s'allongent et des priorités qui changent.

Investir dans cette relation n'est pas un luxe. C'est une condition de survie.

QA — Ce que vous bâcliez au début...

Quality Assurance. Dans beaucoup de startups, la QA arrive à la fin. Ça fonctionne, jusqu'à une certaine taille. Puis l'entreprise grandit, le code s'accumule, et un jour, une mise en production anodine fait tomber une fonctionnalité oubliée.

Dans une organisation mature, la qualité n'est plus une étape qu'on coche avant de livrer. C'est une culture qui se construit dès le premier commit.

Ce que ce lexique ne vous dira pas

Comprendre ces mots ne fait pas de vous un CTO.

Mais ne pas les comprendre vous laissera souvent dans une position inconfortable : celle de quelqu'un qui maîtrise la technologie mais ne parle pas la langue de l'organisation dans laquelle elle vit.

Le passage de lead developer à CTO, c'est moins une évolution technique qu'une translation de contexte.

Vous ne construisez plus seulement un produit. Vous construisez une organisation capable de construire des produits.

...dans un environnement fait de contraintes budgétaires, de décisions politiques, et de personnes qui n'ont pas les mêmes priorités que vous.

Le métier devient complexe — et intéressant

La technologie reste au cœur du travail. Mais elle devient un levier parmi d'autres, dans un système bien plus large.

"Et c'est précisément là que le métier devient complexe — et intéressant."

FAQ : Comprendre le rôle de CTO

La différence réside dans le contexte et le périmètre. Le Lead Dev se concentre sur l'excellence technique, le code et l'architecture. Le CTO opère une "translation de contexte" : il doit transformer des problématiques techniques en enjeux stratégiques, budgétaires et organisationnels compréhensibles par le reste de l'entreprise (CODIR, COMEX).
Ne pas maîtriser ces termes laisse le CTO dans une position de simple exécutant technique. Comprendre les OKR permet d'aligner la tech sur la stratégie. Comprendre les KPI permet de prouver la valeur du travail technique (ex: lier performance et rétention). Sans ce langage commun, le CTO ne peut pas défendre ses budgets ni influencer les décisions stratégiques.
Dans une startup, le CTO construit un produit. Dans une grande organisation avec des Business Units (BU), il doit construire une "plateforme" et une organisation capables de servir plusieurs produits et intérêts divergents. Il est également soumis à des décisions prises à des niveaux où il ne siège pas toujours (COMEX), comme des acquisitions ou des réorganisations, nécessitant une forte capacité d'adaptation politique.

Partager cet article