De developer à product owner : la transformation nécessaire à l'ère de l'IA

Photo de Tara Winstead : https://www.pexels.com/it-it/foto/arte-testa-pensando-consapevolezza-8378726/

Il y a quelques jours, un collègue de mon équipe qui utilise Claude Code a implémenté une feature qui, à l’époque où je faisais son travail, m’aurait pris plus d’une demi-journée. Lui l’a finie en quarante minutes, avec qualité et sécurité. Et en y réfléchissant, je ne pensais pas à la puissance de l’outil. Je pensais à quel point mon parcours professionnel, cette transition de developer vers des rôles de product ownership et de leadership ces dernières années, se révèle plus prescient que ce que j’imaginais.

Je ne l’ai pas fait par clairvoyance, soyons clair. Je l’ai fait parce qu’à un moment, écrire du code toute la journée avait cessé de me donner ce que je cherchais. Je voulais comprendre le pourquoi des choses, pas seulement le comment. Je voulais être dans la pièce quand on décidait quoi construire, pas seulement recevoir des tickets à implémenter. Un choix instinctif, en partie égoïste. Mais avec le recul, il m’a placé à un point intéressant pour observer ce qui se passe en ce moment.

La valeur migre du comment vers le quoi

Le point d’inflexion où nous sommes ne concerne pas l’IA qui « vole le travail aux programmeurs », comme on lit dans les titres sensationnalistes. Il concerne quelque chose de plus subtil : la valeur se déplace. Elle migre du comment vers le quoi et le pourquoi. Et je le vois chaque jour, dans les conversations avec les autres professionnels et managers que je connais, dans les choix d’embauche qui ont déjà changé, dans la façon dont il faut désormais structurer les équipes.

Les entreprises ne se demandent plus « combien de developers puis-je embaucher ». Elles se demandent « comment maximiser la productivité avec des équipes plus petites et de meilleurs outils ». Un changement de perspective radical. Dans mon rôle, je me retrouve de plus en plus à raisonner sur l’intégration d’agents IA dans les workflows existants plutôt que sur le scaling de l’équipe. Et cela a d’énormes implications pour qui aujourd’hui écrit du code comme activité principale.

Les agents IA autonomes qu’on utilise au quotidien ne sont pas des autocomplete dopés. Ils font des choses qui, il y a deux ans, semblaient de la science-fiction : ils prennent un problème mal défini, le décomposent, cherchent du contexte dans la codebase, implémentent, testent, itèrent. On les supervise, bien sûr. On les corrige, souvent. Mais la quantité de travail qu’ils produisent, avec la bonne guidance, est impressionnante. Et cela change tout.

Ce que je cherche aujourd’hui dans les équipes

Quand on sélectionne des candidats ou qu’on évalue les performances, il faut radicalement changer les questions qu’on se pose. Je ne m’intéresse plus tant à la rapidité d’écriture du code. Je m’intéresse à la qualité de compréhension du problème qu’on résout. À savoir si la personne pose les bonnes questions avant de commencer, anticipe les cas limites, sait expliquer ses choix dans des termes qui ont du sens pour le business. Voilà ce que l’IA ne sait pas encore bien faire.

Je connais des professionnels qui refusent d’utiliser Copilot ou Claude Code parce qu’« ils préfèrent tout écrire à la main ». Je les comprends, vraiment. Je viens de là, je connais cette sensation de contrôle total, ce plaisir de voir le code naître sous ses doigts. Mais d’où je suis maintenant, je vois aussi le risque. C’est un peu comme les typographes qui refusaient le PAO parce qu’ils aimaient le plomb. Romantique, certes. Soutenable économiquement, beaucoup moins.

La transition de developer à product owner — ou, en tout cas, vers des rôles où l’on définit le quoi au lieu d’implémenter le comment — ne signifie pas cesser d’être technique. Au contraire, dans mon expérience, elle demande plus de compétence technique, pas moins. Mais une compétence différente : il faut savoir ce qui est possible, ce qui est coûteux, ce qui est risqué, sans nécessairement implémenter soi-même. Il faut diriger l’IA et les agents comme un chef d’orchestre dirige les musiciens : tu ne joues pas chaque instrument, mais tu dois savoir comment chaque instrument doit sonner.

Les developers que je vois faire le mieux cette transition ont des traits que je reconnais en moi. Ce ne sont pas forcément les plus brillants techniquement. Ce sont ceux qui ont toujours posé beaucoup de questions, qui voulaient comprendre le pourquoi derrière chaque feature, qui s’agaçaient face à des spécifications floues. Ceux qui ont toujours pensé au produit, même quand leur rôle officiel était d’écrire du code. Si vous vous reconnaissez là-dedans, vous avez probablement la moitié du travail déjà fait.

Il y a aussi la question des compétences relationnelles, et je dois admettre que ce passage a été dur pour moi aussi. Pendant des années, j’ai évité les réunions avec les stakeholders business, je les voyais comme des interruptions du « vrai travail ». Maintenant, c’est mon travail. Traduire le langage technique en termes qu’un CFO peut comprendre, négocier les priorités avec une équipe marketing/commerciale qui veut tout pour hier, expliquer à un dirigeant pourquoi cette feature « simple » prend trois mois : ce sont des compétences qu’aucune IA ne sait encore faire, et qu’elle ne saura peut-être jamais faire. Et ce sont elles qui me rendent précieux aujourd’hui.

Spécifier, le nouveau métier

Une chose que j’ai apprise sur le terrain : la qualité des exigences que tu donnes à l’IA détermine la qualité de l’output. Cela paraît évident, mais les implications sont profondes. Quand j’écris des spécifications précises, contextualisées, avec les bonnes contraintes et les bonnes libertés, j’obtiens du code qui marche. Quand je suis vague, incomplet, contradictoire, j’obtiens de la bouillie. Cela veut dire que la compétence critique n’est plus « savoir coder », c’est « savoir spécifier ». Et bien spécifier demande une compréhension profonde du domaine technique et du domaine business.

J’ai déjà vu des équipes de cinq personnes au plus produire un output équivalent à des équipes de douze, simplement parce qu’elles avaient quelqu’un capable de définir les tâches comme il faut. Je ne parle pas de documentation formelle, de diagrammes UML ou de spécifications techniques de cent pages. Je parle de cette capacité à articuler ce qu’il faut vraiment, à poser les bonnes questions avant de commencer, à anticiper les problèmes. Une skill qu’on peut apprendre, mais qui demande un changement de mindset.

Le saut demande humilité et courage

Cela dit, je ne veux pas peindre un tableau trop rose. La transition que j’ai faite n’a pas été linéaire, et je vois des collègues peiner énormément. Cela demande de l’humilité : accepter qu’une chose qu’on savait bien faire perd de la valeur relative, et qu’il faut investir dans des compétences différentes. Cela demande aussi du courage : sortir de la zone de confort du code, où les choses sont déterministes et contrôlables, pour entrer dans le monde ambigu des décisions produit, où l’on a toujours des informations incomplètes et des stakeholders aux agendas opposés.

Il y a aussi une dimension éthique qui m’inquiète et me fascine. Utiliser l’IA pour accélérer le développement n’est pas neutre. Il y a des biais dans les modèles, des implications sur la qualité du code produit, sur la sécurité, sur la maintenabilité. Il faut être un peu paranoïaque aussi, savoir quand l’IA fait quelque chose de mal même si techniquement ça marche. Une responsabilité nouvelle, qui demande conscience et intentionnalité. On ne peut pas tout déléguer en espérant que ça aille bien.

Le pari à faire maintenant

Ce que je vois depuis mon point d’observation, c’est que les rôles de leadership technique, product management, tech strategy seront de plus en plus demandés et de plus en plus difficiles à remplir. Qui vient du code a un avantage compétitif énorme par rapport à qui arrive du business pur : il comprend ce qui est possible, ce qui est coûteux, ce qui est risqué. Mais il doit faire le saut. Il doit cesser de s’identifier aux lignes de code qu’il écrit et commencer à s’identifier aux problèmes qu’il résout.

Le faux mythe que j’entends le plus souvent chez les developers avec qui je parle, c’est « je n’ai pas le temps d’apprendre ces choses ». Mais le temps que tu gagnes en utilisant l’IA pour écrire du code, où va-t-il ? Si tu le réinvestis pour perfectionner encore plus tes skills de coding, tu optimises quelque chose qui devient une commodité. Si tu le réinvestis pour apprendre à penser comme un product owner, tu construis ta pertinence future.

La question que je me posais il y a des années, quand j’ai commencé cette transition, était « qu’est-ce que je veux faire dans cinq ans ? ». La réponse n’était pas « écrire du code encore plus vite ». Elle était « avoir plus d’impact, mieux comprendre le business, être dans la pièce où l’on prend les décisions ». Cette question est aujourd’hui encore plus urgente pour qui est au début du parcours.

L’avenir appartient à ceux qui savent définir quoi construire, pas seulement à ceux qui savent le construire. J’ai fait ce pari il y a quelques années, sans savoir combien il deviendrait pertinent. Pour qui me lit aujourd’hui, l’avantage est de pouvoir le faire avec plus de conscience. Mais il doit le faire.