PO et IA : d’un sceptique convaincu à un utilisateur pragmatique

Je ne suis pas du genre à adopter un outil parce qu’il fait le buzz. Et quand l’IA générative a commencé à s’inviter dans toutes les conversations, mon réflexe a été de rester à distance.

Pas par paresse. Par expérience.

Ce qui me rendait méfiant

Les outils IA que j’avais testés dans ma vie perso ne me semblaient tout simplement pas taillés pour le travail de PO. Notre quotidien, c’est recouper des informations qui viennent de partout, Jira, Confluence, les échanges d’équipe. J’avais l’impression que l’IA ne savait répondre qu’à des prompts simples, pas à des problématiques vraiment complexes.

Il y avait aussi cette tendance à l’extrapolation : inventer une réponse plutôt qu’admettre ne pas savoir. C’est particulièrement gênant quand on rédige des spécifications qui doivent être exactes. Une spec floue ou incorrecte, c’est du temps perdu pour toute l’équipe en aval.

Et au-delà du côté pratique, je reste vigilant sur la question des données. Utiliser ces outils, c’est accepter de partager des informations avec des acteurs dont les intentions ne sont pas toujours transparentes. Ce n’est pas un détail.

Ce qui a commencé à faire bouger les lignes

Il n’y a pas eu de moment « révélation » à proprement parler. C’est une évolution progressive. Voir mes équipes de dev de plus en plus convaincues, les entendre en parler avec enthousiasme. Ça m’a naturellement poussé à reconsidérer mon scepticisme.

Et puis j’ai vu une collègue utiliser l’IA pour organiser ses notes de réunion. Ce qui m’a frappé, c’est la pertinence de l’outil même sur des sujets pointus, des problématiques IT spécifiques, des métiers de niche. Là, je me suis dit qu’il fallait que j’essaie sérieusement.

Mes premiers pas 

Mon premier usage concret, c’était en réunion et en atelier : prise de notes et résumé des actions à la suite des points. Ça nécessite toujours une relecture pour adapter le contenu, mais le gain de temps sur la rédaction de compte rendu était suffisamment net pour que je décide de systématiser cette manière de faire.

Un usage modeste, sur le papier. Mais suffisant pour que je commence à creuser.

Aujourd’hui : un PO augmenté, pas remplacé

Sur un projet interne chez Nakama, j’ai pu pousser l’expérience assez loin. Après un travail de configuration et de personnalisation, j’utilise maintenant l’IA à presque toutes les étapes : rédaction de spécifications, d’user stories, de rapports de bugs.

Mais c’est là où ça devient vraiment intéressant : j’utilise aussi l’IA pour détecter automatiquement des bugs avant qu’ils ne soient remontés manuellement, et pour identifier des incohérences entre les spécifications et le code réellement en place. Ce genre de contrôle croisé, qui prenait du temps et de la concentration, est aujourd’hui en partie automatisé.

« Pas un exemple unique et spectaculaire, mais c’est peut-être ça la vraie valeur : un gain de temps diffus, sur tout. Ce qui m’a le plus aidé, c’est d’avoir un point de départ quand on fait face au syndrome de la page blanche. L’IA ne remplace pas la réflexion, mais elle donne une première impulsion qui fait gagner un temps certain. »

Ce que je dirais à un PO qui est là où j’étais

D’essayer, mais dans les bonnes conditions.

Tester l’IA sur un prompt isolé, ça ne rend pas justice à l’outil. Ce qui fait vraiment la différence, c’est de la connecter aux différentes composantes du projet : les spécifications, les tickets, le code. C’est ce qu’on appelle les MCP, des connecteurs qui permettent à l’IA de naviguer entre toutes ces sources d’information.

« Sans ça, les gains sont limités. Avec ça, on commence à toucher à quelque chose de vraiment puissant. »

Mon scepticisme n’a pas disparu, je pense qu’il est même sain de le garder. Mais il a évolué : d’un scepticisme de principe à un scepticisme d’usage. Je questionne l’outil, je vérifie ses outputs, je contrôle ce que je lui soumets. Et dans ce cadre-là, elle m’aide vraiment à faire mon travail.

Adrien — Product Owner, Consultant Nakama