J’ai deux livres qui m’ont formé au produit : l’Inspired, de Marty Cagan, et le Gestão de Produtos, de Joca Torres, avec qui j’ai même eu la chance de faire du mentorat. Pendant des années, ces deux-là ont été ma carte : ce qu’est un PM, ce qu’est un product designer, ce qu’est un ingénieur, qui fait quoi. Chaque rôle avec un contour net.
Au cours de la dernière année, en regardant mon équipe travailler avec l’IA chez Prolog, j’ai commencé à sentir ces contours glisser. Ce n’est pas que les livres soient devenus faux : c’est que la couche où chaque rôle s’exerce a monté.
Dans le premier texte de la série j’ai raconté la gêne qui m’a poussé à commencer à reconstruire la tech chez Prolog, et dans le deuxième, ce qu’est un harness, l’infra qui fait rendre l’IA. À la fin du premier, j’avais promis d’ouvrir une partie précise : comment le travail de chaque poste change quand l’IA devient celle qui construit. C’est le sujet ici.
Le travail ne disparaît pas, il monte d’une couche
L’IA n’est pas en train d’effacer le rôle de chaque profession, elle change la couche où il s’exerce.
La lecture facile, celle qui vend la peur, c’est « l’IA va remplacer le poste X », et ce n’est pas ce que j’ai vu se passer. Ce que j’ai vu, c’est le contenu du travail changer de place : ce qui était avant faire est devenu diriger et critiquer celui qui fait.
L’ingénieur, qui écrivait le code, révise maintenant ce que l’agent a écrit. Le PM, qui écrivait la spec, juge maintenant en quelques heures le prototype qui en est sorti. La personne est la même, c’est l’instrument dans sa main qui a changé.
Quand je suis revenu à Cagan et à Joca avec ça en tête, le déclic s’est fait autrement. Les deux décrivent, avec soin, l’exécution de chaque rôle (la tâche concrète, le livrable, ce qui sort de vos mains à la fin de la journée), et c’est exactement ce que l’IA est en train de reprendre. Ce qu’il reste à l’humain, c’est l’autre moitié : décider ce qui mérite d’être construit, trouver le trou dans ce qui a été construit, avoir le goût pour savoir ce qui est bon. Le jugement, pas l’exécution.
Alors je vais faire ce que j’ai fait avec moi-même : prendre la définition de chaque rôle dans les livres, et demander ce que l’IA en mange et ce qu’il en reste (et qui devient plus cher).
L’équipe des trois, selon les livres
Avant de découper rôle par rôle, ça vaut le coup de rappeler comment les livres montent l’équipe. Joca est direct : un produit qui réussit doit être désirable, viable et possible à construire, et cela définit « les trois fonctions essentielles pour créer un produit qui réussit » (chap. 2) : designer UX, gestion de produit et développeur, le trio qu’il appelle core team. Cagan, dans Inspired, décrit les mêmes rôles dans son chapitre d’ouverture, « Key Roles and Responsibilities ».
Les deux insistent sur un point que je reprendrai à la fin : ce n’est pas une relation de chef à subordonné. Selon les mots de Joca, « l’ingénierie produit, la gestion de produit et l’UX sont une équipe, il n’y a de subordination entre aucun de ces groupes » (chap. 31), et chez Cagan la même idée apparaît comme le PM et l’ingénierie étant « des pairs, aucune position n’est subordonnée à l’autre » (chap. 5, dans ma traduction). Et quand l’IA entre au milieu du trio, c’est ce partenariat qui change le plus de forme.
Tableau : chaque métier de la tech monte d'une couche. L'ingénierie passe de producteur de code à critique d'agent ; le produit, de spec writer à architecte d'itération ; le design, de producteur d'écrans à chef d'orchestre d'expérimentation ; la qualité, de testeur à constructeur de validation.
Le rôle de chaque métier dans la tech
Le même rôle, une couche au-dessus
l'exécution passe à l'agent · le jugement reste avec vous : décider, critiquer, avoir du goût
Ingénieur : de producteur de code à critique d’agent
Pour l’ingénierie, ce qui compte a cessé d’être la quantité de code que vous produisez : c’est devenu la qualité avec laquelle vous critiquez ce que l’agent a produit.
La définition de Joca est si claire qu’elle fait mal à relire aujourd’hui : « l’ingénierie produit est responsable de développer le produit et de le maintenir en fonctionnement », et, plus loin, l’ingénierie « construit le produit » (chap. 31). Construire, c’était le verbe. Cagan complète par l’autre côté, en parlant de la relation avec le produit : « le product manager est responsable de définir la solution, mais l’équipe d’ingénierie sait mieux ce qui est possible, et c’est elle qui, au bout du compte, livre cette solution » (chap. 5, dans ma traduction). Définir d’un côté, livrer de l’autre.
Maintenant, la livraison de la première version appartient à l’agent. Ce qui n’a pas changé, et qui est devenu plus cher, c’est tout ce que Cagan collait à l’ingénieur comme source d’innovation : « les ingénieurs savent mieux que personne ce qui est possible » (chap. 5). Savoir ce qui est possible, trouver le trou dans le plan que l’agent a proposé, voir le trade-off de performance ou de sécurité qu’il ne voit pas, décider quand intervenir et quand laisser filer. Ça pèse plus lourd chaque mois. La syntaxe de mémoire, le boilerplate à la main, ratisser Stack Overflow, le volume de code comme trophée personnel : ça pèse moins.
Chez Prolog, je l’ai dit à l’équipe en toutes lettres : personne ne sera évalué à la ligne de code. Ceux qui ont toujours été bons pour « trouver le trou » deviennent plus précieux, et ceux qui s’identifiaient à « produire beaucoup de code vite » vont devoir recalibrer là où ils investissent. Et ça ne diminue pas l’ingénierie. Sa valeur a toujours été davantage dans le fait de savoir ce qui tient que dans le fait de produire vite, et maintenant ça devient juste explicite.
PM : de spec-writer à architecte d’itération
Le PM le sent quand le prototype devient bon marché : son travail cesse d’être écrire le document et devient choisir quelle idée mérite le temps de l’équipe.
Cagan est catégorique sur le cœur du travail : « quelqu’un doit découvrir quelle est la solution, le produit, y compris les fonctionnalités, l’expérience utilisateur et les critères de lancement. Ce quelqu’un, c’est le product manager, et cette tâche est le cœur de son travail » (chap. 1, dans ma traduction). Joca donne le contour large : la gestion de produit est « la fonction responsable de tous les aspects d’un produit logiciel, pendant tout le cycle de vie de ce produit, depuis sa conception jusqu’à la fin de sa vie » (chap. 2).
Remarquez que chez les deux, le mot-clé est découvrir, pas spécifier. Cagan a un chapitre entier rien que pour défendre que le travail est du discovery, pas des « exigences » : le logiciel a deux étapes, « découvrir quoi construire (le bon produit) et construire (le produit de la bonne manière). La première est dominée par le discovery, la seconde est de l’exécution » (chap. 12, dans ma traduction). Ça a toujours été son message, et l’IA n’a fait que le rendre littéral.
Parce que quand le build s’effondre de semaines à heures, le goulot d’étranglement cesse d’être construire et devient décider ce qui vaut la peine d’être construit. La spec longue révisée en comité, le planning trimestriel bouclé, le status report comme livrable, le contrôle du trafic entre ingénierie et design : tout ça pèse moins. Ce qui pèse plus, c’est le discovery rapide (prototyper pour comprendre, pas spécifier pour construire), la curation d’hypothèses (quelle idée mérite le temps de l’équipe) et décider ce qu’il ne faut pas faire, plus souvent. Certaines entreprises appellent déjà ce PM « Éditeur » ou « Architecte ». Ce n’est pas moins PM : c’est un autre PM, celui qui cure, qui décide avec goût, qui donne la direction. Ce qui était central dans l’ancien, écrire la spec, c’est ce qui est devenu léger.
Product designer : de producteur d’écrans à chef d’orchestre d’expérimentation
Dans le design, l’unité de travail sort de l’écran et va vers le système qui produit des écrans, et le product designer se met à choisir quelle variation survit.
Chez Joca, la définition de l’UX, c’est comprendre pour dessiner : « l’UX est responsable de comprendre à fond l’utilisateur et le problème qu’on souhaite résoudre pour cet utilisateur » (chap. 32). Et le flux qu’il décrit est le rituel que tout le monde connaît : prototype papier, puis wireframe, puis « le designer visuel d’UX commence à mettre de la couleur et de la forme sur ces écrans ». Cagan coupe le rôle en deux avec la même logique : l’interaction designer « développe une compréhension profonde des utilisateurs et crée les tâches, la navigation et le flux », traduit ça en wireframes et passe le relais au visual designer, qui « met de la chair sur le wireframe » (chap. 4, dans ma traduction).
Cet enchaînement, comprendre, esquisser, affiner écran par écran, c’est justement ce que l’IA raccourcit. L’unité de travail cesse d’être « l’écran » et devient « le système qui génère des écrans ». Refaire la même variation cinq fois dans Figma, spécifier composant par composant, le handoff pixel-perfect comme rite : ça pèse moins. Prototyper à vitesse d’itération (plusieurs options en parallèle, on jette les mauvaises), définir le système visuel au lieu de chaque écran isolé, et la critique visuelle rapide (voir l’IA proposer quelque chose et repérer d’un coup d’œil que c’est faux avant que l’utilisateur ne le repère) : ça pèse plus.
Et ici Cagan dit, en 2008 déjà, une chose qui protège le product designer de croire qu’il est devenu presse-bouton : son travail n’a jamais été seulement de dessiner joli. « Un bon produit exige une bonne expérience utilisateur. Et une bonne expérience exige la collaboration étroite entre le produit et le design » (chap. 4, dans ma traduction). L’IA génère la variation, et celui qui décide laquelle mérite d’arriver jusqu’à l’utilisateur reste quelqu’un qui a du goût.
QA : de testeur à constructeur de validation
Le QA est le cas le plus intéressant, parce que c’est le rôle que les livres n’ont presque pas isolé, et c’est celui que l’IA bouge le plus.
Remarquez : dans le trio de Joca (designer, PM, développeur) et dans les rôles de Cagan, la qualité apparaît diluée, comme une responsabilité de l’équipe, pas comme une chaise à part avec une méthode propre. Longtemps ça a eu du sens, mais maintenant non, et la raison est simple : si l’agent construit vite et que la validation reste manuelle, vous n’avez fait que produire de la dette technique à grande vitesse.
Alors le QA cesse d’être celui qui déroule le cas de test à la main et devient celui qui conçoit le testing harness, le système qui teste le système : configurer une IA pour écrire des tests pour le code qu’une autre IA a écrit, détecter la régression avant l’utilisateur, penser où le défaut a tendance à apparaître. En pratique, c’est devenu une question opérationnelle qu’on a adoptée : chaque bug qui passe devient « comment on détecte ça automatiquement la prochaine fois ? ». Le test manuel exhaustif d’un flux connu, la régression déroulée à la main à chaque release, le QA comme portail unique avant de monter : ça pèse moins. La validation comme système, pas comme passe de balle au bout de la chaîne.
C’est le rôle qui monte le plus de couche précisément parce que c’était le moins défini. Là où les livres n’ont pas gravé de contour, l’IA en dessine un nouveau.
La constante : ce que les livres disaient déjà compter le plus
Il y a une chose qui ne change pas, et elle était cachée en pleine lumière dans les deux livres : ce qu’ils placent comme la caractéristique la plus importante est exactement ce que l’IA ne fait pas.
Joca ouvre le chapitre des caractéristiques d’un bon PM sans détour : « la plus importante de toutes est, sans le moindre doute, l’empathie » (chap. 4). Ce n’est pas un tableau de fonctions ni un livrable : c’est la capacité de se mettre à la place de celui qui utilise. Cagan, de son côté, passe le livre entier à défendre le discovery, le taste et le jugement au-dessus du processus, et les deux, chacun à sa manière, disaient la même chose : ce qui sépare le bon du moyen n’a jamais été la partie mécanique du travail.
Et la partie mécanique est justement celle qui est passée à l’agent. Écrire la spec, dessiner l’écran, écrire le code, dérouler le test. Ce qui est resté, et qui est devenu plus cher, c’est le sens critique, le taste (savoir ce qui est bon), le jugement sous ambiguïté, la curiosité, le soin de celui qui utilise ce que vous faites. Pour le résumer dans la phrase que j’ai utilisée avec l’équipe : le contenu du travail change, la personne qui le fait, non.
Schéma en deux couches. En haut, ce qui est resté avec nous et est devenu plus cher : taste (savoir ce qui est bon), jugement sous ambiguïté, empathie avec l'utilisateur, décider ce qu'il ne faut pas faire, ce que les livres disaient déjà compter le plus. Le travail est monté d'une couche. En bas, ce qui est passé à l'agent : écrire la spec, dessiner l'écran, écrire le code, dérouler le test manuel.
Resté avec nous · et devenu plus cher
ce que les livres disaient déjà compter le plus
le travail est monté d'une couche
Passé à l'agent
Ce que ça va coûter (sans cliché)
Je ne veux pas boucler ça trop joliment, parce que ça ne l’est pas. Ce changement coûte des choses concrètes, et aucune n’est confortable.
La première, c’est laisser derrière soi une habitude d’une décennie. Ceux qui sont depuis cinq, dix ans dans l’ancienne manière portent des schémas qui ont aidé à arriver jusqu’ici, et ce sont justement ces schémas qui pèsent au moment de changer. Il n’y a pas de raccourci, et la gêne est attendue.
Ensuite, critiquer l’IA autant que créer avec elle : accepter la suggestion qui est apparue n’est pas du travail ; trouver le trou dans le plan qu’elle a proposé, si. Ce qui a toujours été cher (la pensée critique, le taste, le jugement) devient plus cher.
Il y a aussi se tromper en équipe, pas en tant que personne. On ne licencie pas un ingénieur pour un bug en production, on améliore le review, et quand l’IA se trompe c’est le harness qu’on renforce. Le bug de l’agent est un processus, pas une personne : un engagement, pas un slogan.
Et la plus inconfortable : accepter que certaines fonctions changent plus que d’autres. Ça crée un malaise chez ceux qui ont peu changé jusqu’ici, et on ne peut pas faire semblant que tout est pareil. Ce qu’on peut faire, c’est amener ça dans une conversation ouverte.
Et pour ne pas sonner comme quelqu’un arrivé à destination : Prolog en est encore au début. On reste en AI-assisted, avec un gain de 10 à 20 %, pas en AI-first de 5x ou 10x. Je raconte une direction qu’on est en train de construire, avec des réussites et des erreurs, pas une victoire.
Ce que j’en retiens
Les livres ne sont pas devenus faux. Ils décrivaient l’exécution de chaque rôle avec une précision que je n’ai vraiment comprise que maintenant (écrire la spec, dessiner l’écran, construire le produit, dérouler le test), et cette exécution appartient désormais à l’agent. Et ce qui est resté à l’humain, c’est l’autre partie, juger, critiquer, avoir du goût, prendre soin de celui qui utilise, qui, en revenant à Cagan et à Joca, est ce qu’ils disaient compter le plus dès la première page.
C’est peut-être ça la bonne partie : le travail que l’IA nous a retiré des mains est celui qui était le plus répétitif, et ce qu’elle a laissé est ce qui a toujours été le plus difficile, et le plus intéressant. Je continuerai à raconter comment ça avance.
Sources
- Marty Cagan, Inspired: How to Create Products Customers Love (1ʳᵉ édition, 2008). Les définitions de rôle viennent des chapitres 1 (Key Roles and Responsibilities), 4 (Product Management vs. Design), 5 (Product Management vs. Engineering) et 12 (Product Discovery). Les traductions des extraits sont de moi.
- Joca Torres, Gestão de produtos: Como aumentar as chances de sucesso do seu software (Casa do Código). Les définitions viennent des chapitres 2 (Qu’est-ce que la gestion de produit logiciel ?), 4 (Principales caractéristiques d’un gestionnaire de produit), 31 (Ingénierie produit et gestion de produit) et 32 (UX et gestion de produit).
- La lecture sur le rôle qui monte d’une couche appuie la série : OpenAI, Harness Engineering, et Peter Pang, CTO de CREAO.