Du comment au pourquoi
CTO, CTPO. Quatre lettres au lieu de trois. Le titre a changé en une phrase. Le câblage dans ma tête, ça prend un peu plus longtemps.
Jeudi. Revue de roadmap. Les PMs présentent trois scénarios pour le prochain cycle. L’option B est la plus propre techniquement. C’est celle que j’aurais défendue il y a un an, sans hésiter. L’option A est un peu brouillonne côté archi, mais elle touche le bon segment, au bon moment.
J’ai choisi A.
Personne n’a sourcillé. Sauf moi, intérieurement. Parce que pendant vingt ans, mon boulot c’était de pousser pour la robustesse. De lever la main quand le raccourci technique allait nous coûter six mois plus tard. D’être la voix du comment.
Et là, j’étais en train d’arbitrer le pourquoi.
Le titre a changé en une phrase. CTO, CTPO. Quatre lettres au lieu de trois. Le périmètre s’élargit sur le papier, un rectangle qui englobe un rectangle voisin, les organigrammes se mettent à jour, les gens acquiescent en réunion.
Ce que le papier ne dit pas, c’est que le câblage interne met des mois à suivre. Ça fait un an. Le câblage suit, doucement.
Christian & Timbers (un cabinet de recrutement de C-levels) a mesuré une hausse de 110 % de la demande de CPTO entre fin 2023 et mi-2024. Leur prédiction : la moitié des boîtes software en auront un dans cinq ans. Le rôle est à la mode. Les articles “pour ou contre” se multiplient. Presque aucun ne parle de ce qui se passe dans la tête de la personne qui fait la transition.
Alors je vais parler de la mienne.
La littérature sur le sujet revient toujours au même argument : quand tu fusionnes CTO et CPO, tu perds la tension saine. Le CPO pousse pour itérer vite. Le CTO pousse pour la solidité. Les deux se challengent. Le produit en sort meilleur. Fusionner le rôle, c’est supprimer le contre-pouvoir.
Stéphane Cinguino, qui a été CPTO chez CleverConnect, le dit bien :
Quand il n’y a plus de binôme, il faut trouver un autre sparring partner.
Il a raison. Et j’ai eu du bol d’en trouver.
Mon head of product était déjà là avant que je prenne le rôle. Ma VP data me challenge. Ma CEO me challenge. Les PMs et les VPs dans les différents départements sont là depuis longtemps, on a une relation construite sur des années. Des gens senior, solides. Le challenge circule dans les deux sens, et tout le monde l’accepte.
La tension n’a pas disparu. Elle s’est redistribuée.
Mais je suis lucide. C’est du bol. Si ces personnes n’étaient pas là, ou si elles étaient plus junior, ou si on n’avait pas cette relation de confiance, je ne suis pas sûr que ça marcherait. Du tout.
Le truc qui m’a le plus surpris, c’est quand j’ai commencé à ne plus prendre le parti des ingénieurs.
Ça arrive souvent sur la même question : on prend le raccourci ou pas ? Avant, ma réponse par défaut c’était non. Pas par dogmatisme, par réflexe. Vingt ans à voir des raccourcis revenir en dette technique six mois plus tard, ça forge un instinct. Maintenant, je me surprends à dire oui. Pas toujours. Mais quand je vois le contexte produit, les contraintes de timing, le segment qui va décrocher si on attend trois semaines de plus, le oui sort avant que l’ancien CTO en moi ait le temps de lever la main.
Avant, mon CPO me poussait là-dessus. Il choisissait ses batailles, laissait passer certains trucs, insistait sur d’autres. C’était la tension saine en action. La friction produisait un meilleur compromis.
Maintenant, la friction est internalisée. Je n’ai plus besoin que quelqu’un me convainque. Je le vois moi-même. Et je peux redescendre le contexte aux ingénieurs directement, sans passer par une négociation entre deux C-levels. Un layer de moins. L’info arrive moins filtrée. Dans les deux sens. Quand mon intuition est bonne, ça va vite. Quand elle est mauvaise, ça va vite aussi.
Dans l’ensemble, j’ai l’impression que c’est sans douleur. Les équipes techniques ont le sentiment d’avoir plus d’accès, moins de filtres. Mais elles me voient aussi leur faire des grands discours sur telle business metric à craquer, sur l’importance d’expérimenter vite. Je ne suis pas certain de ce qu’elles en pensent vraiment. Peut-être qu’elles préfèrent le contexte direct. Peut-être qu’elles trouvent que leur CTO a changé de camp. Je n’ai pas encore osé poser la question.
Arbitrer le pourquoi, même 30 % du temps, c’est déjà vertigineux.
Quand tu es CTO, le pourquoi t’arrive emballé. Quelqu’un a fait le travail en amont. Tu peux te concentrer sur l’exécution, la faisabilité, les tradeoffs techniques. Le cadre est posé.
Quand tu es CTPO, le cadre c’est toi. Et le cadre, ça veut dire choisir quoi ne pas faire. Dire non à des features que l’équipe technique a envie de construire. Dire non à des idées produit qui sont bonnes mais pas maintenant. Dire non à ton propre instinct d’ingénieur qui dit “on pourrait faire ça proprement si on avait deux semaines de plus.”
Et quand tu te trompes, tu le sais. Pas tout de suite. Trois semaines plus tard, quand tu vois une équipe entière s’enliser dans un truc que t’as choisi. Quand on met beaucoup d’efforts sur une intuition et que l’AB test revient neutre. Ou négatif. Et là il n’y a personne d’autre à blâmer.
Benoît Bouffart, qui était CTPO chez SNCF Connect, résume ça sans détour :
Le rôle de CTPO empêche le Good Cop Bad Cop. On ne peut plus accuser l’autre parce que la roadmap n’était pas claire ou l’équipe pas assez staffée.
C’est libérateur. Et écrasant. Les deux en même temps.
La chose la plus contre-intuitive que j’ai apprise : lâcher prise sur ce que tu ne maîtrises pas, même quand c’est ton périmètre.
Le produit, c’est moins mon expertise que la tech. Je le sais. Mes PMs le savent. Plutôt que de jouer au PM qui n’en est pas un, je me concentre sur une seule chose : leur donner du contexte. La stratégie, les contraintes, les erreurs déjà faites, ce que dit la CEO, ce que remontent les données. Pas de la méthodologie. Pas de la technique. Du contexte.
Context, not control. C’est un mantra PM que j’ai emprunté. Et bizarrement, c’est en l’appliquant aux PMs eux-mêmes que j’ai l’impression d’être le plus utile.
Parfois je me demande si c’est de la sagesse ou un aveu de limite. Je vois l’utilisateur. Je comprends le parcours, le point de friction, le moment où ça coince. Mais est-ce que je vois les utilisateurs ? La masse, les patterns, les signaux faibles qu’un·e CPO de métier aurait captés avant moi ? Honnêtement, je ne sais pas.
En pratique, ça ressemble à ça : toutes les deux semaines, je leur raconte où en est le business. Les questions qu’on se pose. Les chiffres qu’on aimerait voir bouger. Les struggles des autres départements. Les personnes d’intérêt à qui aller parler. Pas de directives. Du contexte brut. Et ils sont super créatifs avec. Beaucoup plus que si je leur donnais une roadmap fléchée.
Ça marche. Mais ça marche parce que j’ai des PMs et des designers senior, voire très senior. Si l’équipe produit était plus junior, ce serait irresponsable.
J’en viens même à me demander si je ne devrais pas lâcher la tech un peu plus aussi. Donner du contexte aux engineering managers au lieu de plonger dans l’archi. La pensée me traverse de plus en plus souvent.
Ce qui me retient, c’est pas la peur que ça casse. Mon équipe tech est world class. C’est plutôt la peur de ne pas micro-optimiser le temps qu’on a. L’envie d’être celui qui dit “non, plus simple” quand personne ne voit le raccourci inutile. Et probablement un peu de plaisir, aussi. Le plaisir de rester les mains dans le moteur, même quand mon job ne le demande plus vraiment.
None of these setups worked well, and none lasted more than a year before either the executive left or the role devolved back into its original, distinct forms.
Le scepticisme est légitime. Ça fait un an que j’ai le rôle. Un an, c’est pile la durée que l’auteur donne comme plafond. Je ne sais pas si c’est un bon signe ou un mauvais signe.
L’argument que le CTPO ne fonctionne que pour des profils rares, dans des contextes rares, avec des équipes rares. Que c’est plus un accident de parcours qu’un choix organisationnel.
Cinguino dit quelque chose qui me parle :
Je suis convaincu que ce modèle est étroitement lié à l’individu. Ça ne se fait pas du jour au lendemain, ça reflète un parcours et une double affinité.
Étroitement lié à l’individu. Pas au rôle. Pas à l’organigramme. À la personne. Ce qui veut dire que le CTPO n’est peut-être pas un poste qu’on crée. C’est un poste qui émerge quand la bonne personne est au bon endroit, avec les bonnes personnes autour.
Et ça, aucun cabinet de recrutement ne peut le garantir.
Un an. Je ne sais pas combien de temps ça va durer. Le consensus dans la littérature dit que le modèle casse au-delà de 100 personnes. Que la complexité des deux fonctions finit par exiger deux têtes. Que ce qui marche en phase de croissance devient un goulot d’étranglement à l’échelle.
Peut-être. Mais en ce moment, avec cette équipe, dans cette phase, ça fonctionne. Pas parce que le rôle est bien conçu. Parce que les gens autour sont bons, qu’on se fait confiance, et que le contexte s’y prête.
(En attendant, je continue à choisir l’option A en comité produit. De temps en temps, ça me gratte encore un peu. 🙃)