Le PO traditionnel est mort — voici son successeur

Le PO de 2020 n'a presque rien à voir avec celui de 2026. Pas dans le titre — sur LinkedIn, on lit toujours Product Owner. Dans le quotidien. Dans la matière du travail. Dans la nature des artefacts produits.

Voici les trois traits qui distinguent l'un de l'autre. Aucun n'est théorique : ce sont des changements que je vois s'installer chez les équipes qui fonctionnent vraiment avec un agent IA en production.

Trait 1 — La roadmap n'est plus un fichier Excel. C'est un fichier vivant.

Le PO traditionnel ouvrait Excel. Une colonne par trimestre, une ligne par initiative, des cases colorées en orange pour « en cours » et en vert pour « livré ». La roadmap était un document de communication, lu par les humains, mis à jour par le PO une fois par mois.

Le PO de 2026 ouvre un fichier markdown. Versionné dans le repo. Lu par les humains et par l'agent. Mis à jour à chaque décision importante, parfois plusieurs fois par jour.

Concrètement, ce fichier contient :

• L'objectif du produit, en deux paragraphes que tout le monde peut citer.
• Les contraintes du métier — ce qu'on ne fait jamais, ce qu'on doit toujours faire, les règles non négociables.
• Les décisions d'architecture passées et leur raison.
• Les compromis assumés (et leur date d'expiration).
• Le glossaire métier, pour que « client inactif » veuille dire la même chose pour tout le monde — y compris pour l'agent.

Ce fichier devient le contexte de l'agent. À chaque session, il le lit. À chaque décision, le PO l'enrichit. La roadmap n'est plus une vue à un instant : c'est une mémoire vivante que l'équipe et l'agent partagent.

Effet de bord, immense : le PO qui produit ce fichier devient indispensable. Personne ne le remplace, parce que c'est lui qui sait ce qu'il faut y mettre. Le PO qui n'en produit pas devient opaque : l'agent ignore son existence, l'équipe se passe de lui, le client commence à parler directement aux devs.

Trait 2 — La réunion hebdo est remplacée par un journal partagé.

Une heure de réunion hebdomadaire pour aligner cinq personnes, ça coûte cinq heures-homme. À l'année, deux semaines pleines de salaire pour chaque participant. Et le rendement informationnel est faible : on partage trois choses qu'on aurait pu lire en cinq minutes.

Le PO de 2026 tient un journal. Pas un compte-rendu. Un fichier court, dans le repo, mis à jour en temps réel ou en fin de journée :

2026-04-22 — Décision : on garde Stripe pour les paiements, pas Mollie.
  Raison : 80 % du trafic est en France et Stripe a un meilleur support
  Apple Pay sur Safari iOS, qui fait 30 % de notre trafic mobile.
  Reconsidérer si on attaque le marché DACH au S2.

2026-04-23 — Bug : les emails de relance partaient en double pendant
  3 jours. Cause : double déclencheur (cron + webhook). Corrigé par X.
  Action : ajouter un test d'intégration pour ce cas.

Tout le monde y a accès. L'équipe le lit le matin, à la place de la réunion. Les nouveaux arrivants le lisent en intégration, à la place d'une semaine d'onboarding flou. L'agent IA le lit aussi, en début de session — et il sait pourquoi telle décision a été prise, ce qui réduit dramatiquement les régressions.

La réunion ne disparaît pas complètement. Elle change de nature. Plus une réunion d'information — c'est dans le journal. Une réunion de décision, sur les sujets qui ne se tranchent pas en async, où il faut sentir le ton, lire les visages, débattre. Ces réunions-là deviennent rares. Trente minutes, deux fois par semaine. Pas une heure et demie tous les jours.

Trait 3 — Le backlog n'est plus dans Jira. Il est dans le repo.

Jira, Linear, Asana — peu importe l'outil. Le PO traditionnel y déversait des tickets. Format prose, plus ou moins précis, parfois copié d'un ticket Slack. Le dev allait le chercher, le lisait, posait trois questions, finissait par le coder à sa façon.

Le PO de 2026 écrit ses tickets dans le repo, à côté du code. Format markdown. Versionnés. Lus par l'agent au moment où il code. Avec une structure stricte :

• Titre : ce qu'on veut obtenir, pas comment.
• Contexte : pourquoi on fait ça maintenant, qui le demande.
• Critères d'acceptation : liste explicite, vérifiable, sans ambiguïté.
• Cas-limite : ce qui ne doit pas arriver, ce qui peut arriver et qu'on accepte.
• Dépendances : les autres tickets dont celui-ci dépend, les fichiers à toucher.

Cinq sections, vingt lignes. Beaucoup plus structuré que le ticket Jira moyen, beaucoup plus rapide à écrire que le cahier des charges d'avant.

Effet observé : l'agent prend le ticket, l'exécute, propose une PR. Le PO revoit en lisant la PR et les critères d'acceptation. Si ça ne match pas, on itère sur le ticket — pas sur le code. Le ticket devient le contrat entre le PO et l'agent. Et tout ce qui est contractualisé clairement s'exécute beaucoup plus vite.

Bonus : les tickets sont versionnés. On peut voir comment le besoin a évolué dans le temps. C'est un acquis pour l'équipe, pas un fil Slack qui disparaît au bout de deux semaines.

Ce qui reste — et qui devient la seule chose qui compte

Trois changements de surface. Mais ils pointent tous vers le même fond : la valeur du PO se déplace de la production d'artefacts vers la qualité de la décision.

Quel ticket. Dans quel ordre. Avec quel critère d'acceptation. Quel arbitrage entre rapidité et dette. Quelle règle métier ne souffre aucune approximation. Quelle exception est acceptable.

Ces décisions, l'agent ne les prend pas. L'équipe ne les prend pas seule. C'est exactement ce qu'un bon PO faisait déjà — mais qui était dilué dans la production des Excel, des slides, des comptes-rendus.

Maintenant que la production d'artefacts est largement absorbée par l'agent, il ne reste plus que la décision. Et cette décision-là, elle est visible. Mesurable. Comparable d'un PO à l'autre. Le PO qui décide bien et vite voit la machine s'aligner sur lui en quelques heures. Le PO qui décide mal ou lentement voit la machine produire du code qu'il faut jeter.

Le PO ne disparaît pas. Le PO traditionnel — celui qui produisait des artefacts pour des humains — disparaît. Le PO qui décide pour des humains et pour des agents devient le poste le plus critique de l'équipe.

Et concrètement, par où basculer ?

Trois actions, dans l'ordre, à essayer dès cette semaine :

1. Écrire le fichier de contexte projet. Une page suffit pour démarrer. Objectif, contraintes, glossaire, trois décisions importantes. Le commiter dans le repo. Le tester en début de session avec l'agent — il s'y réfère immédiatement.
2. Remplacer le compte-rendu de la prochaine réunion par une entrée de journal. Cinq lignes, pas trois pages. Si l'équipe ne lit pas ces cinq lignes, c'est qu'elle ne lisait pas non plus le compte-rendu de trois pages.
3. Réécrire un seul ticket au format structuré (titre, contexte, critères, cas-limite, dépendances). Le donner à l'agent. Comparer le résultat avec un ticket « normal » de la même semaine. La différence est immédiate.

Aucune de ces actions ne demande un nouvel outil. Ce sont des changements de discipline. Et c'est exactement pour ça qu'elles séparent ceux qui basculent de ceux qui restent.

Le PO traditionnel n'est pas mort par accident. Il est mort parce que la machine qui exécute en aval n'a plus besoin de ses artefacts. Elle a besoin de sa décision. Le PO qui l'a compris est en train de prendre douze à dix-huit mois d'avance sur les autres. Et cette avance ne se rattrape pas en lisant un article — elle se construit en pratiquant, sur un vrai projet, dès maintenant.