Software development & IA : qu'est ce que l'IA générative peut apporter à un PO au sein d’une équipe agile ?

le 10/06/2026 par Sylvain Fagnent

Tags: Software Engineering, Product & Design, Data & AI, Agile, Bonne Pratique

Introduction & question initiale

Dans un développement logiciel par les méthodes agiles qu'est ce que l'IA générative peut apporter à un PO ? Nous verrons que le PO profite de 2 axes d’amélioration.

Le PO accéléré : l’IA joue un rôle d’assistant (optimisation) et facilite son travail qu’il a l’habitude de faire : rédaction des US, aide à la discovery, génération de tests, génération de documentation etc. Elle libère ainsi du temps pour que le PO se concentre sur la stratégie produit, les arbitrages et la connaissance client.
Le PO augmenté : le PO profite de nouvelles possibilités auparavant impossibles car trop complexes ou trop lourdes à mettre en oeuvre comme :
- Accéder à une compréhension précise des règles de gestion réellement mises en œuvre dans l’application
- Prototyper et tester des parcours utilisateurs avant un engagement technique par l’équipe de développement
- Aider à la décision, priorisation et au pilotage
- Prioriser de manière plus argumentée et ainsi plus facilement aligner les parties prenantes

Précédemment au sein de l’équipe de développement…

Dans l'univers du développement logiciel, l'IA générative donne un puissant coup d'accélérateur aux équipes de développement : elle augmente fortement leur capacité technique à produire du code. Comme tout nouvel outil, il vient bousculer un mode de fonctionnement établi. Nous explorions dans ce précédent article la vision d’une équipe de développement face à ces transformations et leurs effets à son échelle. Nous y présentions son point de vue, les gains mesurés, les risques identifiés ainsi que des recommandations terrain en partant de l’hypothèse que les autres rôles de l’équipe (PO, UX, QA, etc.) n’avaient pas encore, ou seulement à la marge, fait évoluer leurs pratiques.

En conclusion, deux constats forts :

L'IA agit comme un amplificateur des dynamiques existantes. "Sous IA", une équipe dysfonctionnelle ne le reste pas simplement elle tend à devenir plus chaotique, plus rapidement, et à plus grande échelle. À l'inverse, une équipe disciplinée et bien organisée verra ses forces décuplées.
L’accélération de la production de code grâce à l’IA met en évidence que la vitesse globale reste contrainte par le maillon le plus lent. En augmentant fortement le débit de développement, de nouveaux goulets d’étranglement apparaissent notamment dans les phases de revue, de validation, de test voire de mise en production.

La construction d’un produit repose sur un équilibre entre trois impératifs

La construction d’un produit repose sur un équilibre entre trois impératifs (Src Henrik Kniberg - “Agile Product Owner in a Nutshell”); l'accélération des cycles peut conduire à des dérives, où l'exécution est au détriment de la pertinence du produit (Illustration réalisée avec Perplexity).

Rappel : Henrik Kniberg a popularisé les enjeux du cycle de développement logiciel agile dans sa vidéo « Agile Product Owner in a Nutshell ». Le triptyque qu'il y présente — “Build the right thing”, “Build the thing right” et “Build the thing fast” — structure encore la réflexion de nombreuses équipes.

Nos hypothèses de départ

L’IA avec laquelle le PO interagit a accès aux repositories des codes en cours d’élaboration par l’équipe de développement agile. Dans le cas d’une refonte, le PO a aussi accès aux codes sources du produit legacy en plus des développements en cours.

Ce que l’IA générative peut apporter au PO au milieu d’une équipe agile

En développement Agile, l’IA générative permet déjà au PO de s’accélérer sur ses tâches habituelles comme celles qui sont répétitives.

Niveau 1 - Le PO accéléré

Réalisation grâce à l’IA générative	Bénéfices
- Générer des user stories (US) et leurs critères d’acceptation - Génération de premiers jets de stories à partir d’un besoin ou d’une Epic, - Reformulation selon INVEST, proposition de critères d’acceptance, découpage de gros items en stories plus petites, clarification de la valeur, suppression des ambiguïtés. - Définition de cas aux limites, - Définition de scénarios BDD (Gherkin, Behaviour Driven Development).	- Ce type d’assistance permet de réduire significativement le temps consacré à la rédaction et à la reformulation des user stories, tout en élevant leur qualité globale (clarté, testabilité, alignement avec la valeur métier). Cela contribue également à s’aligner sur le rythme accru des équipes de développement, dont la fréquence et la capacité de production ont fortement augmenté. - Note : Dans l'hypothèse où l’équipe de développement est augmentée aussi par l’IA (voir notre précédent article) il y a un vrai questionnement à réaliser sur le découpage. Est-ce que le besoin est toujours systématiquement utile ? Pour des tâches simples et très assistées par l’IA, un découpage ultra fin peut être inutile. Pour des sujets métier, d’architecture ou risqué, les US restent utiles pour clarifier la valeur et organiser l’apprentissage. Le découpage et puis l’estimation devrait évoluer vers une lecture plus orientée risque et incertitude que simple charge de travail. Voir point “Faire de estimations”. - Point de vigilance : comme pour les développeurs, si le PO n’effectue que des relectures, il peut perdre en compétence, en motivation, en recul. Préserver des élaborations d’US sans IA.
- Affiner et prioriser le backlog - Regroupement automatique de tickets similaires, - Détection des doublons, - Détection des tickets trop larges, - Clarification de tickets ambigus, - Suggestion de dépendances manquantes et d’items complémentaires, suggestion de découpage en tâches plus petites	- Renforce l’efficacité du PO et améliore la qualité du backlog en le rendant plus clair/limpide en particulier. Le processus de backlog grooming devient plus fluide, tandis que la qualité des inputs fournis à l’équipe de développement s’en trouve nettement améliorée. In fine, cela contribue à une hausse globale de la qualité du produit. - Point de vigilance : l'IA lorsqu’elle imagine les cas aux limites, elle est capable d'imaginer plétore de scénarios improbables et inutiles qu’il faut lire/consulter et exclure éventuellement.
- Faciliter l'interopérabilité des outils projet - Relier de manière semi-automatisée : Jira, Storymap, tests, roadmap, Kanban: l’IA peut lire et écrire dans chacun des outils via leurs API, puis créer automatiquement les liens (IDs, tags, relations). - Exemple: un agent IA lit une story Jira et génère des cas de test structurés, puis les pousse dans l’outil de test en les liant automatiquement à l’issue d’origine.	- Moins de copier‑coller entre outils : l’IA fait la synchronisation et la génération de liens. Meilleure traçabilité bout‑en‑bout : une story sur la storymap pointe vers l’issue Jira, qui pointe vers les tests, les défauts, et sa place sur le Kanban et la roadmap. Fiabilise des vues consolidées, car alimentées automatiquement à partir des mêmes sources plutôt que re‑saisies à la main. - À garder en tête : l’interopérabilité “magique” n’existe pas toute seule. Il faut définir des règles de nommage, de tags et de schémas de données pour que l’IA sache quoi relier à quoi. Ensuite, elle fera le travail de rapprochement sémantique entre les différents outils projet. Enfin, pour garantir un fonctionnement fluide, chaque étape doit être suffisamment structurée et rigoureuse afin de permettre à l’IA d’exécuter correctement sa tâche avant de passer à la suivante. Un pilotage et un suivi attentifs de la chaîne par le PO (surtout au début ou à chaque évolution) seront indispensables pour prévenir tout risque de désorganisation, d’hallucinations ou de prises de décision “hasardeuses” pour ne pas dire “rocambolesques” de l’agent.
- Faciliter la “discovery” et la compréhension client - L’IA établit des synthèses rapides de verbatims (interviews, avis stores, tickets support), agrège des retours par thème, met en avant les pain points récurrents et d’insights marché pour nourrir la vision produit, la roadmap et des hypothèses d’AB tests. Elle extrait et synthétise : tendances, problèmes récurrents, opportunités produit.	- Permet d’obtenir en quelques minutes une synthèse claire et exploitable sur des volumes importants de retours : l’IA transcrit, résume et extrait automatiquement les points clés à partir de sources multiples. Elle regroupe ensuite les informations par thématiques, même lorsque celles-ci sont formulées différemment. Cette approche réduit les biais de classification et facilite l’identification de signaux faibles et de thèmes émergents, souvent difficiles à détecter manuellement. - Point de vigilance : l'IA ne lit pas entre les lignes. Par conséquent, ne surtout pas négliger, les interviews en direct. La perception d’un non-dit, la captation d’une émotion ou la reformulation permettent d’alimenter ses réflexions pour construire un produit adapté et pas simplement répondre à une attente directe formulée par un utilisateur.
- Faciliter l’onboarding des PO en leur permettant de comprendre rapidement l’existant et de vérifier les fonctionnalités effectivement implémentées dans le code. - Le PO s’approprie plus rapidement les règles métier implémentées en interrogeant directement une IA connectée au code. Il accède ainsi à des réponses précises et contextualisées, ce qui réduit les sollicitations du Tech Lead et renforce significativement son autonomie et sa capacité de prise de décision.	- Le PO gagne en indépendance vis-à-vis du TL particulièrement au moment de son onboarding. Le Tech Lead se libère du temps.
- Faire des estimations : Après plusieurs itérations, en s’appuyant sur le code produit lors des cycles précédents, le PO s’appuie sur l’IA pour pré-estimer les stories à partir de l’historique (code et backlog). Cette approche permet de gagner en temps et en cohérence. Néanmoins, l’estimation finale demeure co-construite avec l’équipe : l’IA agit comme un outil d’aide au calcul contextualisé.	- Neutralité de l’approche sur la base de métriques. - Note : Toutefois, ne pas oublier que le rituel de l'estimation est un outil de discussion et d'alignement pour l'équipe, pas juste un calcul de complexité basé sur le passé. Si l'IA estime seule, on perd la valeur du débat technique. L’IA donne simplement un avis supplémentaire à l’équipe sur ses propres estimations. - Note : si l'on considère que ce rituel avait pour objectif de découper le travail en itérations maîtrisables, et que l'estimation servait avant tout à converger sur une compréhension commune, à donner de la visibilité et à dimensionner le pipe, alors l'IA pourrait bien rendre une partie de ces étapes obsolètes. Pour une IA qui assiste le développement logiciel, une différence de complexité qui aurait un impact significatif pour un humain peut lui être presque négligeable ! Dans de tels cas l’estimation devient obsolète !
- Automatiser la génération de documentation fonctionnelle - L'IA peut produire de la documentation à partir du code, des EPICs et des tickets, libérant du temps au PO et aux QA. Génération : notes de version, documentation utilisateur, …	- L’IA fait gagner du temps au PO sur des tâches répétitives mais essentielles comme la documentation - Point de vigilance : limitez la génération de documentation par l’IA au strict nécessaire. Une documentation trop abondante risque de ne jamais être lue tout en créant une charge de maintenance supplémentaire. De plus, puisque l’IA dispose d’un accès au code, une partie de la documentation produite automatiquement pourrait s’avérer inutile.

Comment certains voient le PO accéléré (illustration réalisée avec Gemini)

Niveau 2 - Le PO augmenté

Au-delà de ce que peut gagner en temps et en efficacité sur les tâches répétitives, le PO a accès bien plus que cela grâce à l’IA générative.

Réalisation grâce à l’IA générative	Bénéfices
- Grâce à son accès au code source, l’IA permet au Product Owner d’obtenir, à tout moment et en quelques instants, une compréhension précise des règles de gestion réellement mises en œuvre dans l’application.	- Le code devient la source documentaire. - Le PO a en permanence la possibilité d’interroger l’IA pour valider / se rappeler / confirmer une règle de gestion. - Le PO accède enfin à la "source de vérité" ce qui lui permet de mieux maîtriser son discours auprès des stackholders. - La compréhension du code et des comportements codés ne sera plus le fait exclusif des développeurs. - Point de vigilance : valider par le TL et par les tests fonctionnels que l’IA n’hallucine pas.
- Les parcours utilisateurs peuvent être prototypés et testés avant un engagement technique.	- Les UX, le PO en collaboration avec le métier, peuvent produire grâce à l’IA des prototypes fonctionnels pour valider l'expérience utilisateur avant de lancer un développement complet. Cela permet de dérisquer une idée et de démontrer concrètement l'attendu.
- Aider à la décision, priorisation et au pilotage - L’IA connectée aux outils d’analytics (Mixpanel, Amplitude, Google Analytics, Looker, etc.) peut interroger les données en langage naturel : l’IA génère les requêtes, agrège les résultats et renvoie un résumé et des visuels. Cela permet de : - Mettre en évidence des signaux faibles, en scannant funnels, rétention, tickets support, - Relier quanti et quali : En combinant logs d’usage et verbatims (reviews, support, interviews), l’IA clusterise les retours terrain et les relie aux métriques associées (taux d’erreur, temps d’exécution de tâche, abandon). - Détecter des tendances (adoption, churn sur une fonctionnalité) : Pour une fonctionnalité donnée, demander  par ex. : « Quels types d’utilisateurs adoptent le plus cette fonctionnalité, et lesquels l’abandonnent ? » « Quels comportements précèdent le churn sur cette fonctionnalité ? » Les modèles de churn / rétention assistés par IA savent identifier des patterns que l’œil humain rate (combinaisons d’événements, séquences d’usage, signaux de désengagement). L’IA peut ensuite proposer des cohortes à risque et des hypothèses d’actions : simplifier un flux, ajuster le pricing, déclencher des campagnes ciblées, etc.	- Permettre de passer de « on a l’impression que cette fonctionnalité ne marche pas » à « les données montrent que, malgré deux itérations, l’usage reste marginal et le coût de maintenance dépasse la valeur → on la tue / on la pivote, et voilà le scénario choisi ». L’IA prépare les analyses et les options. - Réduire l’effet HIPPO (Highest Paid Person’s Opinion) : sur la base de données mesurées et d’analyses factuelles, on écarte plus facilement la situation où une décision est prise en fonction de l’avis du décideur le mieux payé ou le plus gradé.
- Prioriser de manière plus argumentée et aligner les parties prenantes - En analysant l’historique de sprints, de stories et de code l’IA peut prédire la complexité/effort d’un type de fonctionnalité. - Le PO peut maintenir en continu une matrice de priorisation et générer automatiquement des fiches argumentaires “défendables” par lui auprès des parties prenantes. Celles-ci s’appuient à la fois sur des hypothèses explicitées et des données terrain. → Hypothèses explicitées : problème client, segments, données appuyant la valeur, hypothèses d’impact, risques identifiés, contraintes légales ou techniques → Données terrain : retours clients, KPIs d’usage, revenue, SLA, etc - Simuler des scénarios de release et réaliser des arbitrages : en fixant des contraintes (capacité de l’équipe, deadline réglementaire, budget, dépendances) l’IA simule plusieurs séquences de releases, en montrant impact attendu sur KPIs et charge par sprint. Pour chaque scénario, on peut visualiser des compromis time‑to‑market vs risque (ex. un scénario “go‑to‑market agressif” qui maximise la valeur court terme mais repousse les chantiers de conformité, vs un scénario plus averse aux risques qui intègre tout de suite des remédiations).	- Le PO obtient au final des scénarios comparés, chacun accompagné d’arguments chiffrés et de profils de risque explicite; “défendable” auprès des stakeholders. Le PO renforce sa crédibilité lors des décisions et facilite l’alignement des parties prenantes.

Le PO augmenté comme certains l’imaginent (Illustration réalisée avec Gemini)

Conclusion et perspectives

L'avenir du PO se joue sur deux niveaux. D’abord, l'IA comme assistant (Optimisation), facilite le fonctionnement que l’on a connu jusqu’ici dans au sein d’une équipe agile: rédaction plus rapide des user stories, aide à la discovery, écriture des tests…Cela libère du temps pour que le PO se concentre sur la pertinence produit, les arbitrages et la connaissance client. Le PO garde la main sur la priorisation, la validation des hypothèses et l’éthique (biais, conformité, confidentialité) et sur les productions de l’IA qui doivent être relues et challengées.

Perspectives

Mais l’IA s’apprête à provoquer un 2nd niveau de transformation bien plus profond qu’une simple accélération des pratiques actuelles. Lorsque l’IA devient capable de produire l’essentiel du code, le découpage traditionnel en User Stories respectant les critères INVEST perd une grande partie de sa pertinence. Le Product Owner évolue vers quelque chose que l’on pourrait nommer le “Product Builder”, s’intégrant directement dans la chaîne de production logicielle, jusqu’à la revue et la validation des Pull Requests. Cette évolution s’accompagne de l’apparition d’un nouvel artefact. La User Story laisse progressivement place à la “Living Specification” : une spécification vivante, enrichie de ses critères et tests d’acceptation, qui devient le point de référence central du produit. Le “Product Builder” maintient et fait évoluer cette spécification globale tandis que l’IA et l’équipe de développement se charge de sa traduction en code. À terme, la frontière entre documentation fonctionnelle et implémentation s’estompe.

Enfin, selon certaines visions, le « Product Builder » représente une évolution du Product Owner augmentée par l’IA : il ne se contente plus de piloter la livraison, mais acquiert la capacité à produire et à livrer lui-même certaines fonctionnalités. Le PO se rapproche alors du rôle de développeur et devient davantage un acteur de l’exécution qu’un simple prescripteur.

Cette perspective doit toutefois être nuancée. Par le passé, les approches low-code et no-code ont rendu ce modèle envisageable grâce à leurs environnements techniques fortement structurés qui encadrent la génération du code sous-jacent (au passage ni le PO ni le développeur n’ont la main sur le code sous-jacent généré par ces outils). En revanche, si les IA génératives peuvent considérablement accélérer la production de code, elles nécessitent encore un cadre, une supervision et une validation par des développeurs formés / expérimentés. À ce stade, elles ne constituent pas un système suffisamment fiable pour fonctionner en « pilote automatique » sur des sujets de développement complexes (et parfois même simples) ou critiques. Le “harness engineering” est alors la discipline que l’équipe de développement mobilise et qui consiste à construire l’environnement d’exécution autour d’un agent IA autonome, pour qu’il soit fiable et contrôlable. Le modèle (LLM) seul est imprévisible; le harness est la couche logicielle qui le “domestique” : contraintes, outils, règles, vérifications, observabilité.

Le “Product Builder” maintient et fait évoluer une spécification globale tandis que l’IA se charge de sa traduction en code (illustration réalisée avec Gemini)