Quand l’IA code à ta place, c’est le product manager en toi qui fait la différence

J’ai passé des années à écrire du code. Après ça, plusieurs années en product management. Deux métiers, deux façons de penser, et longtemps, j’ai cru que mon bagage technique était mon principal atout. Celui qui me donnait la crédibilité, la vitesse, l’autonomie. Avec le coding agentique, je réalise que j’avais tort. Pas sur la valeur de l’ingénierie, elle reste fondamentale. Mais sur la hiérarchie. Aujourd’hui, quand je build, mon expérience de PM pèse au moins autant que celle d’ingénieur. Et c’est peut-être elle qui fait la vraie différence.

L’exécution se commoditise, le jugement non

Un agent IA écrit du code correct, structuré, fonctionnel. Il le fait vite, il le fait bien, et il s’améliore chaque mois. Ce qu’il ne fait pas, c’est décider quoi construire. Quand tu développes avec un agent, tu passes ton temps à arbitrer. Pas des choix stratégiques mais des micro-décisions, en continu. Est-ce qu’on traite ce edge case maintenant, ou plus tard ou jamais ? Est-ce que cette feature mérite un écran dédié ou un simple toggle ? Est-ce qu’on optimise pour celui qui découvre le produit ou pour celui qui l’utilise tous les jours ? Quel niveau de finition suffit pour valider l’hypothèse ? Ces questions n’ont rien de technique. Elles sont purement produit. Et elles reviennent des dizaines de fois par jour, à chaque prompt, à chaque revue de code, à chaque choix d’implémentation. Un ingénieur sans culture produit va construire quelque chose qui fonctionne. Un ingénieur avec un œil produit va construire quelque chose qui a du sens.

Deux cerveaux, une boucle

Ce qui rend la combinaison ingénieur-PM redoutable aujourd’hui, ce n’est pas l’addition de deux compétences. C’est la disparition du délai entre les deux.

Dans une organisation classique, le PM pense, spécifie, priorise puis attend. L’ingénieur reçoit, implémente, livre puis attend le retour. Entre la décision produit et le feedback terrain, il peut se passer des jours, parfois des semaines. Chaque itération coûte cher en temps et en coordination. Quand tu portes les deux casquettes avec un agent IA comme partenaire d’exécution, cette boucle se compresse à quelques minutes. Tu décides, tu builds, tu vois le résultat, tu ajustes dans la même session. La pensée produit et l’implémentation ne sont plus deux étapes, elles deviennent un seul flux. C’est là que la magie opère. Pas dans la vitesse d’écriture du code. Ça, l’IA le fait. Mais dans la vitesse de convergence vers le bon produit.

Ce que l’ingénieur apporte (et que le PM seul n’a pas)

Tentant d’en conclure que la technique devient secondaire. Ce serait une erreur. En effet le system thinking de l’ingénieur reste indispensable. Pas pour écrire chaque ligne, mais pour juger si l’architecture tient la route. Pour anticiper les dépendances. Pour sentir quand l’agent prend un raccourci qui coûtera cher dans trois mois. Pour automatiser ce qui doit l’être et résister à la tentation d’automatiser ce qui ne le mérite pas. L’ingénieur apporte aussi la rigueur, cette capacité à distinguer un prototype qui a l’air de marcher d’un système qui marche vraiment. Avec les agents IA, la distinction est plus critique que jamais : le code compile, les tests passent, la démo impressionne. Mais est-ce que ça scale ? Est-ce que c’est maintenable ? Est-ce que les fondations tiennent ? Répondre à ça demande un œil formé. La vision produit te dit où aller. La rigueur technique te dit si le chemin est viable.

Le vrai risque du profil hybride

Il y a un piège à nommer. Le PM-ingénieur peut aussi devenir celui qui fait tout à moitié. Assez technique pour bricoler, pas assez pour construire des fondations solides. Assez product-minded pour avoir des intuitions, pas assez pour les valider sérieusement. L’IA agentique amplifie ce risque. Elle rend tellement facile de produire quelque chose qu’on finit par confondre vitesse et valeur. Shipper vite n’est pas shipper bien. Et le confort de tout contrôler soi-même peut devenir un frein : on arrête de collaborer, on arrête de confronter ses idées, on s’enferme dans sa propre boucle. Le combo ne fonctionne que s’il reste honnête. Si le côté ingénieur sait dire « ça, je ne maîtrise pas assez, il faut quelqu’un de meilleur que moi ». Et si le côté PM sait dire « mon intuition ne suffit pas, il faut aller parler à des utilisateurs ».

Ce que ça change concrètement

Au quotidien, ça ressemble à ça. Tu ouvres ton éditeur avec une intention produit claire. Tu guides l’agent avec des décisions, pas seulement des instructions techniques. Tu relis le code généré avec un double filtre : est-ce que c’est correct, et est-ce que c’est pertinent ? Tu tues des features avant même qu’elles existent parce que tu sais qu’elles n’apportent rien. Tu en ajoutes d’autres parce que tu reconnais un pattern utilisateur que l’agent ne peut pas voir. Le rythme change. Ce qui prenait une semaine de ping-pong entre PM et développeur se résout en une après-midi concentrée. Pas parce que le travail est bâclé, mais parce que la personne qui décide est la même que celle qui implémente, avec un assistant qui absorbe la charge d’exécution.

La vraie question

Ce n’est pas « est-ce que les PM devraient apprendre à coder ? » ni « est-ce que les ingénieurs devraient faire du produit ? ». Ces questions sont dépassées. La vraie question : dans un monde où l’exécution technique devient de plus en plus accessible, qu’est-ce qui reste rare et précieux ? Le jugement. La capacité à prendre les bonnes décisions, vite, en continu, avec des informations incomplètes. Et ce jugement se forge exactement à l’intersection de la pensée technique et de la pensée produit. Le combo PM-ingénieur n’est pas juste un avantage. Dans l’ère du coding agentique, c’est peut-être le profil le mieux armé pour construire.