Contexte et affirmation principale
L’article affirme que l’intelligence artificielle générative (genAI) perturbe non seulement les développeurs, mais aussi les chefs de produit (PM). L’auteur, développeur passé chez Cloudflare et Zaraz, indique que la capacité des modèles à produire du code à faible coût rend la distinction traditionnelle entre « tech guy » et « product guy » de plus en plus floue.
Fait clé : l’automatisation du prompt de fonctionnalité par les LLM réduit la dépendance du PM à la traduction des besoins en spécifications.
Mécanismes d’automatisation par les LLM
Les modèles de langage large (LLM) acceptent des requêtes textuelles et génèrent du code fonctionnel. Selon le texte, « code is cheap », ce qui libère du temps pour analyser les points de douleur du client. Le processus décrit repose sur trois étapes concrètes : saisie du besoin, génération du code, itération sur le résultat. Chaque étape élimine une interaction humaine (réunion, validation juridique, revue de conformité).
Le texte mentionne explicitement les contraintes de sécurité, de conformité, de capacités techniques et de budget. Ces contraintes imposent l’accès à des données privées et à des réunions interpersonnelles, ce qui constitue aujourd’hui le principal obstacle à l’automatisation totale. En pratique, un LLM qui ne possède pas ces informations ne peut pas garantir que le code généré respecte les politiques internes.
Implications pour le rôle de chef de produit
Lorsque le même individu qui code peut également formuler l’intuition produit, le rôle de PM se transforme. L’auteur compare ce phénomène à la perte de « moat » des photographes amateurs face à Instagram : 90 % des compétences standards sont remplacées, les 10 % restants exigent un talent non reproductible. Ainsi, les PM doivent développer des compétences d’architecture logicielle pour rester pertinents.
Le texte indique que la capacité à concevoir une architecture reste « one of the last bastion of human intelligence ». Cette affirmation repose sur le fait que l’architecture implique des décisions de compromis techniques, d’évolutivité et de résilience qui ne sont pas encore modélisables de façon fiable par les LLM.
Limites et compétences résilientes
Le document souligne l’absence de données chiffrées sur le taux de remplacement des PM. Cette lacune empêche une quantification précise du risque, mais le raisonnement logique montre que chaque automatisation de tâche réduit le besoin de médiation humaine. En l’absence de métriques, la recommandation consiste à consolider des compétences non automatisables : analyse de données complexes, négociation de contraintes réglementaires, conception d’architectures hybrides.
En conclusion, l’auteur préconise aux PM de renforcer leurs connaissances techniques afin de conserver une valeur ajoutée distincte des capacités de génération de code des LLM. Cette stratégie repose sur les faits présentés : coût marginal du code, contraintes de conformité, et besoin persistant d’une architecture pensée par l’humain.
