3 CPOs débattent de l'avenir du PM face au code et à l'IA

Dans cet épisode, je réunis 3 CPOs pour un débat sur le PM, le code et l’IA :

• Amélie Caudron, ancienne CEO et CPO d’Invoxia, passée par Withings, aujourd’hui Fractional CPO
• Clark Chahine, ancien CPO de Kpler, passée de 80 à 800 personnes (de 5 à 50 au Produit) en 6 ans.
• Alex Wattrelos, ex-CPO de Sunday et de Furious, Partner de Stellar.

1. Prévoir plus d’ingénieurs pour review le code

Chez Kpler, Clark voit les ingénieurs écrire moins de code et en relire beaucoup plus. Son CTO explique qu’il faut plus d’ingénieurs, parce que l’équipe produit davantage. Clark fait une comparaison avec les avocats qui relisent des contrats.

2. Choisir qui accède au code selon son profil

À Kpler, Clark avait ouvert la lecture du code lié à la base de données aux seuls PM capables de lire des modèles mathématiques. Pour lui, le profil compte plus que la taille de l’entreprise.

3. Séparer la validation d’un prototype de son passage à l’échelle

Amélie décrit le vibe coding comme un Pareto : 80 % pour obtenir un résultat OK en 1 minute. Puis des heures pour les derniers %. Clark n’a pas vu beaucoup de boîtes tenir le passage à l’échelle grâce à ça.

4. Garder le temps client comme premier job du PM

Clark a travaillé chez SLB sur un logiciel de 16M de lignes de code (et 3 500 boutons). Il prévient que construire est addictif et que le PM doit d’abord comprendre les clients.

5. Découper les rôles

Amélie cite Boris Cherny (Head of Apps de Anthropic) : selon lui, il n’y aura plus de rôle fonctionnel dans la future orga d’une boite tech. A la place, il y aura celui qui prototype, celui qui nettoie et celui qui industrialise.

6. Ouvrir d’abord le code en lecture seule aux PM

Alex distingue 3 niveaux d’accès : lecture, écriture sur des branches éphémères (que les ingénieurs regardent sans les réutiliser) et écriture directe dans la codebase. Pour Amélie et Clark, la lecture est le minimum que toute boite doit installer.

7. Compartimenter les parties sensibles du code avant d’ouvrir l’accès

Alex constate que les garde-fous dépendent de la maturité technique d’une boîte, pas de sa taille. Certaines savent isoler les parties sensibles du code, d’autres non.

8. Poser des garde-fous sur le PM qui soumet du code

Clark prévient qu’ouvrir l’accès peut surcharger les ingénieurs de features et détériorer la stratégie Produit. Les garde-fous se posent donc sur le PM ou le product builder, pas sur le code des ingénieurs.

9. Tester 4 idées et n’en soumettre qu’une aux ingénieurs

Alex voit le gain principal de l’IA dans le filtre en amont : un PM teste 4 idées avec des utilisateurs, n’en garde qu’une et les ingénieurs se concentrent sur celle qui marche. Il exige de la discipline sur les prototypes.

10. Packager son design system pour Claude Code et Cursor

Clark raconte que chez Kpler, l’équipe Design a intégré son design language et tous ses composants dans Claude Code et Cursor. Les prototypes des PM ressemblent au produit et les développeurs retrouvent des composants prêts.

‍