Une thèse séduisante
Depuis dix-huit mois, une thèse circule dans les conférences produit et les fils LinkedIn : puisque l’IA écrit le code, le Product Owner pourra bientôt construire lui-même, et le développeur devra devenir produit. Deux métiers convergeraient vers un seul.
C’est une belle histoire. Elle a l’inconvénient de mal résister à l’examen.
Pourquoi la thèse de la fusion ne tient pas
Le raisonnement implicite est le suivant : la barrière entre les deux métiers était technique, le PO ne savait pas coder, et l’IA supprime cette barrière.
C’est une erreur de diagnostic. Ce qui séparait un PO d’un développeur n’était pas la syntaxe. C’était deux systèmes de valeurs différents, et deux façons différentes de se tromper.
Un bon PO optimise pour la valeur utilisateur sous contrainte de temps. Il accepte volontiers une dette technique si elle permet de valider une hypothèse plus tôt. C’est son travail, et c’est légitime.
Un bon développeur optimise pour la capacité du système à encaisser les six prochains changements. Il refuse volontiers un raccourci qui coûtera trois fois plus cher dans huit mois. C’est son travail, et c’est légitime aussi.
La tension entre ces deux postures n’est pas un défaut d’organisation. C’est le mécanisme qui produit de bons arbitrages. Une équipe où elle disparaît ne devient pas plus rapide : elle devient unilatérale. Elle livre vite et mal, ou proprement et hors sujet.
L’IA ne supprime pas cette tension. Elle en change simplement le point d’application.
Ce qui change réellement : l’intention devient exécutable
Voici le vrai déplacement, et il est considérable.
Avant, une spécification était un document d’entrée dans un processus humain. Elle passait entre les mains de développeurs qui la lisaient, la critiquaient, repéraient les contradictions, posaient des questions et comblaient les manques avec leur compréhension du métier. Une spécification médiocre produisait quand même un logiciel correct, parce qu’une demi-douzaine de cerveaux la corrigeaient silencieusement en chemin.
Aujourd’hui, une spécification peut être exécutée à peu près directement. Et un agent ne pose pas de questions. Il comble les manques avec une hypothèse plausible, sans signaler qu’il a comblé quoi que ce soit, à la vitesse de plusieurs milliers de lignes par heure.
La conséquence est brutale : l’imprécision en amont ne se dilue plus, elle s’amplifie.
C’est là que se joue la revalorisation du travail de spécification. Pas parce que c’est devenu à la mode, mais parce que le mécanisme de rattrapage humain qui masquait les spécifications faibles a été retiré.
Spec-driven development : promesse et angles morts
Le mouvement du spec-driven development est la réponse méthodologique à ce constat. Il consiste à faire de la spécification structurée l’artefact central du développement, en séparant explicitement la phase de conception de la phase de génération. GitHub a publié Spec Kit en open source, Amazon a construit Kiro sur ce principe.
L’analyse de Thoughtworks est la plus honnête disponible sur le sujet, notamment parce qu’elle ne cache pas les problèmes non résolus.
La génération reste non déterministe. La même spécification ne produit pas le même code deux fois. Cela complique tout : la maintenance, la reproductibilité, le débogage, la revue.
La dérive entre la spec et le code est difficile à éviter. Dès qu’un correctif est appliqué directement au code, et il le sera, les deux artefacts divergent. On se retrouve avec deux vérités, comme au temps où la documentation vivait dans un wiki que personne ne mettait à jour.
La question de la source de vérité n’est pas tranchée. Si la spec fait foi, il faut régénérer à chaque changement, ce qui est instable. Si le code fait foi, la spec redevient de la documentation, c’est-à-dire un artefact mort.
Le risque de retour au cycle en V est réel. Thoughtworks le dit sans détour : une spécification sur-formalisée ralentit les cycles de changement. C’est exactement le problème que l’agilité avait été inventée pour résoudre.
Il y a donc une méthode prometteuse, pas une méthode mûre. Les publications qui présentent le spec-driven development comme un état de l’art établi vendent quelque chose.
Les trois compétences qui se redistribuent
Formuler sans ambiguïté. Ce n’est pas du prompt engineering. C’est une compétence beaucoup plus ancienne : écrire une règle métier qui ne peut être interprétée que d’une seule façon. « L’utilisateur peut annuler sa commande » est une phrase de réunion. Elle ne dit ni jusqu’à quand, ni ce qu’il advient d’un paiement déjà capturé, ni ce qui se passe si l’expédition est partielle, ni qui est notifié.
Un développeur humain aurait posé ces quatre questions. Un agent, non.
Savoir ce qu’on ne sait pas. C’est la compétence la plus difficile à acquérir et la plus rapidement dégradée par l’usage de l’IA. Elle consiste à reconnaître qu’une réponse produite instantanément et avec assurance peut être fausse, et à savoir sur quels sujets se méfier.
Un PO qui ne sait pas que le modèle de données qu’il vient de faire générer rendra impossible une fonctionnalité prévue au trimestre suivant ne le découvrira pas en lisant le code. Cette anticipation est de l’expérience technique. Elle ne se délègue pas et ne s’improvise pas.
Arbitrer. Aucune génération n’arbitre. Un modèle produit l’option demandée, pas l’option juste. Quand deux besoins s’opposent, vitesse contre robustesse, personnalisation contre maintenabilité, ce client-là contre les quarante autres, il faut quelqu’un qui tranche et qui en porte la responsabilité.
C’est la seule des trois compétences dont on peut dire qu’elle est totalement insensible au progrès des modèles, parce qu’elle ne relève pas de la capacité mais de la légitimité.
Le vrai risque : fabriquer deux demi-métiers
La version optimiste du changement produit des profils hybrides compétents. La version probable produit autre chose.
Le PO qui construit sans comprendre. Il livre vite, obtient des démos convaincantes, et accumule des décisions structurelles qu’il n’a pas identifiées comme telles. Le modèle de données, la stratégie d’authentification, le découpage des services : rien de tout cela ne lui a été présenté comme un choix. Ce sont pourtant les décisions les plus coûteuses à défaire.
Le développeur qui se disperse. Sommé de « penser produit », il passe en réunion le temps qu’il passait à comprendre le système. Deux ans plus tard, l’équipe n’a plus personne qui sache réellement comment fonctionne ce qu’elle exploite.
Ces deux dérives ont un point commun : elles échangent une compétence profonde contre une compétence de surface, et l’échange ne se voit pas avant deux ou trois ans.
Ce que ça implique pour l’organisation
Quatre principes qui tiennent à l’usage.
Séparer la formulation de la validation. Celui qui écrit la spécification et celui qui valide le résultat ne devraient pas être la même personne. C’est le principe de base du contrôle interne, et il devient critique quand l’intermédiaire humain qui corrigeait silencieusement a disparu.
Nommer un responsable des décisions structurelles. Modèle de données, sécurité, découpage, dépendances externes : ces choix doivent avoir un propriétaire identifié, indépendamment de qui a lancé la génération. Sans cela, ils sont pris par défaut, par un agent, sans traçabilité.
Faire du refus une compétence attendue. Une équipe produit saine contient quelqu’un dont le rôle explicite est de dire « cette demande est incohérente avec ce qu’on a construit ». Ce rôle était rempli implicitement par les développeurs qui lisaient les specs. Il doit être réattribué, explicitement.
Mesurer la compréhension, pas le débit. Une question utile en revue : quelqu’un dans l’équipe peut-il expliquer pourquoi ce composant est écrit ainsi ? Si la réponse est non de façon répétée, le débit actuel est emprunté à l’avenir.
En résumé
La frontière entre développeur et Product Owner ne disparaît pas. Elle se déplace, et elle se déplace vers le haut.
Elle ne sépare plus « celui qui sait coder » de « celui qui sait ce qu’il faut construire ». Elle sépare désormais ceux qui comprennent les conséquences de ce qu’ils demandent de ceux qui ne les comprennent pas. Cette frontière-là traverse les deux métiers.
Questions fréquentes
**L’IA va-t-elle fusionner les métiers de développeur et de Product Owner ? ** Non. Ce qui change, c’est que la spécification est devenue directement exécutable, ce qui revalorise la précision de l’intention. Mais la tension entre optimisation de la valeur à court terme et robustesse du système reste nécessaire, et elle suppose deux points de vue distincts.
**Qu’est-ce que le spec-driven development ? ** Une approche où une spécification structurée sert d’artefact central au travail des agents d’IA, avec séparation explicite des phases de conception et d’implémentation. Outils de référence : GitHub Spec Kit, Amazon Kiro.
**Quelles sont les limites du spec-driven development ? ** Thoughtworks en identifie quatre : génération non déterministe, dérive entre spécification et code, absence de consensus sur la source de vérité, et risque de sur-formalisation ramenant aux problèmes du cycle en V.
**Un Product Owner doit-il apprendre à coder en 2026 ? ** Pas nécessairement à écrire du code, mais à comprendre les conséquences des décisions structurelles, modèle de données, sécurité, découpage. C’est cette compréhension, et non la syntaxe, qui distingue un arbitrage informé d’un arbitrage par défaut.
Sources
Thoughtworks, Spec-driven development: unpacking one of 2025’s key new AI-assisted engineering practices
GitHub Blog, Spec-driven development with AI: an open source toolkit
DORA, Balancing AI tensions (2025)
SFEIR, AI Product Owner : rôle, compétences et mutation du métier
Stack Overflow Developer Survey 2025