Recruter un CPTO n’est pas une décision de titre.
C’est une décision sur la personne qui tranche lorsqu’une opportunité client, une échéance et un risque de production partent dans des directions différentes. Si vous vous trompez, vous ne créez pas de l’alignement. Vous créez un goulot d’étranglement coûteux avec une carte de visite plus longue.
Cet article s’adresse aux CEO, conseils, fondateurs et recruteurs qui évaluent un Chief Product and Technology Officer. La question n’est pas de savoir si la personne peut prononcer produit et architecture dans le même entretien. La question est de savoir si elle peut prendre la décision commune sans affamer une moitié de l’entreprise.
Imaginez le rôle comme le contrôle aérien. Le contrôleur ne pilote pas chaque avion. Il voit les trajectoires qui se croisent, connaît les limites de sécurité et décide avant que 2 bonnes intentions ne deviennent une collision.
Dans un contexte logiciel, un CPTO ne doit pas approuver chaque fonctionnalité ou chaque choix de base de données. Il porte la séquence entre valeur client, priorités produit, réalité technique et conséquence business.
Commencez par le mandat, pas par le candidat
Beaucoup de recherches commencent par une liste de souhaits : ancien CTO, expérience produit, expérience avec l’IA, présence au conseil. On fabrique une personne mythique, puis une description de poste vague. Rédigez le mandat d’abord. Nommez la décision qui arrive trop tard, trop chargée politiquement ou trop abîmée par les passages de relais.
- Une demande client contourne la discovery produit et arrive comme urgence en ingénierie.
- Un investissement plateforme est repoussé parce que personne ne le relie à une conséquence commerciale.
- Le CEO traduit sans cesse entre produit et ingénierie.
- Des fonctions IA sont une idée produit le lundi et un risque le vendredi, sans personne pour tenir les 2 réalités ensemble.
Si vous ne pouvez pas nommer cette décision, ne recrutez pas encore un CPTO. Vous avez peut-être besoin d’un rythme plus clair, d’un CTO plus solide, d’un CPO plus solide, ou des 2. Le rôle répond à un problème de coordination. Ce n’est pas du papier peint exécutif.
Test 1 : donnez-lui un arbitrage ingrat
Ne demandez pas si la personne est stratégique. Donnez un cas : un client majeur veut un workflow dans 6 semaines. Le produit pense sécuriser un renouvellement. L’ingénierie estime que l’intégration rendra un système fragile plus difficile à sécuriser et à maintenir. Le budget est fixé. Que se passe-t-il pendant les premières 48 heures ?
Une réponse crédible rend l’arbitrage visible. Elle demande quelles preuves soutiennent le risque de renouvellement, ce qui peut être testé à petite échelle, ce que l’architecture peut absorber, qui détient chaque fait, et ce que l’entreprise apprend si elle répond non.
- Lancer une expérimentation limitée avec une frontière explicite.
- Réutiliser une capacité existante, même moins élégante.
- Investir d’abord dans le prérequis.
- Refuser parce que la valeur ne justifie pas le risque.
La bonne réponse dépend de l’entreprise. Le point est de relier problème client, approche technique et conséquence business.
Test 2 : identifiez la discipline d’origine et l’angle mort
Un CPTO n’a pas besoin d’être le meilleur ingénieur et le meilleur product manager du bâtiment. Cette fiction pousse les conseils à chercher une licorne et à embaucher un cheval très sûr de lui.
Chaque candidat réel a une discipline d’origine. Un leader technique fera confiance à l’architecture, à la fiabilité et à la livraison. Un leader produit fera confiance au signal client, à la priorisation et au timing de marché. Rien de cela ne disqualifie. Ce qui disqualifie est de prétendre ne pencher d’aucun côté.
Demandez quelle décision lui paraît difficile, quand sa première intuition était mauvaise, et quels dirigeants expérimentés il lui faudra dès le premier jour. Un bon CPTO nomme sa limite et organise le système autour. La largeur relie les disciplines. Le flou évite la responsabilité.
Test 3 : inspectez le modèle opérationnel
Le rôle échoue lorsque toute décision importante passe par une seule personne. L’organigramme paraît net. 12 mois plus tard, cela ressemble à une file d’attente.
Demandez les 90 premiers jours. Pas un deck de transformation. Le système de décision réel. Vous devez voir des relais clairs, un rythme partagé, et des déclencheurs de séparation liés à la complexité, la réglementation, la largeur du portefeuille ou la bande passante.
Une direction produit forte et une direction ingénierie forte gardent l’expertise, les équipes et le travail quotidien. Opportunité, capacité de livraison, risque technique et budget sont discutés avant qu’une feuille de route devienne une promesse.
Consultez la définition : https://the-cpto.com/fr/definition. Comparez les 3 titres : https://the-cpto.com/fr/journal/cpto-vs-cto-vs-cpo. L’épisode 1 de Code Meets Business explique le problème : https://www.youtube.com/watch?v=uc7YNs-apLQ.
Questions avant l’offre
- Quelle décision business cette personne porterait-elle clairement ?
- Que doit-elle savoir avant une exception client ?
- Quelle partie du mandat est la moins forte, et qui la renforcera ?
- Que peuvent décider sans elle les responsables produit et ingénierie ?
- Quel signal imposera de séparer de nouveau le rôle ?
- Recrutons-nous de la responsabilité ou faisons-nous disparaître 2 emplois sur le papier ?
En bref
Un recrutement de CPTO ne se valide ni par un CV hybride ni par un titre à la mode. Il se valide par les arbitrages, les limites nommées et le système de décision construit autour de la personne.
Ne recrutez ce rôle que si un siège responsable rend l’entreprise plus claire et plus rapide, sans la rendre plus superficielle.
Souvenez-vous : un responsable pour l’arbitrage, jamais une personne pour chaque travail.
