Jusqu’où automatiser une tâche de PM avec l’IA ?

Avec l’IA, on peut automatiser beaucoup de choses quand on est PM. Mais est-ce que ça veut dire qu’il faut le faire ? Spoiler : non. Dans cet article, Théo Vialard Vesco, Product Manager chez Thiga, montre comment il choisit jusqu’où pousser l’IA sur chacune de ses tâches, du simple chat à l’orchestration de plusieurs agents.

Deux fois par mois chez mon client - un géant de la grande consommation - une release part en production. À chaque fois, il faut communiquer les nouveautés de la plateforme aux équipes Sales et CSM. La tâche est répétitive, ce qui en fait une candidate idéale à l’automatisation. Et pourtant, je ne l’ai pas fait.

L’IA s’invite partout en ce moment, mais le fait qu’une tâche soit automatisable ne veut pas dire qu’elle mérite de l’être. C’est cet arbitrage, qui revient à chaque palier d’automatisation, que je vais aborder dans cet article.

On parle beaucoup d’agents capables d’enchaîner des tâches sans intervention humaine, et la tentation de les mettre partout est réelle. Pourtant, une tâche mal choisie coûte souvent plus cher à construire et à maintenir qu’elle ne fait gagner de temps, et ses risques (des coûts non maîtrisés en tokens, une hallucination qui passe inaperçue) peuvent largement dépasser le bénéfice. Techniquement, tout est possible (ou presque) : le niveau à choisir est celui qui offre le meilleur rapport entre la valeur créée, la complexité, le risque et le coût de construction comme d’exécution.

Pour choisir, je distingue quatre manières différentes de faire travailler l’IA, que je range en palier : l’assistance, l’augmentation, la délégation et l’orchestration. Aucun n’est supérieur aux autres par nature : chacun résout une limite du palier précédent et introduit sa propre forme de complexité. C’est cet équilibre qui doit guider les arbitrages. Les outils que je cite sont ceux autorisés chez mon client, pas forcément les meilleurs du marché : le raisonnement reste valable avec d’autres.

Assistance : l’IA aide, ponctuellement

L’IA m’aide sur une tâche précise, que ce soit en direct dans un chat ou via un assistant (un Gem, un Custom GPT). Je reste responsable de l’essentiel du travail.

Revenons à l’exemple des releases. Deux fois par mois, il faut transformer une note de release technique en message compréhensible pour les équipes Sales et CSM. Je pourrais construire un agent qui lit les notes et génère le message, mais l’infrastructure (accès API sécurisés) serait disproportionnée pour deux exécutions par mois, et je devrais de toute façon vérifier les informations avant d’envoyer la moindre information au Business. Ici, l’assistance ponctuelle suffit : je rédige la version technico-fonctionnelle à partir des releases, je demande à l’IA de la retravailler pour un public métier, je relis, et j’envoie.

À ce stade, le contexte vient de moi : à chaque nouvelle conversation, je réexplique le produit et l’historique. On peut retarder cette limite en ajoutant une base de connaissance à un Gem ou un Custom GPT. Mais le contexte reste attaché à cet assistant précis, et il faut le nourrir et le nettoyer soi-même : trop de documents empilés, et on finit par devoir ranger sa propre mémoire avant de ranger son travail.

Quand on passe plus de temps à alimenter et à mettre à jour ce contexte qu’à utiliser l’IA, c’est le signal qu’il faut passer au palier suivant. Même chose quand on multiplie les assistants spécialisés (discovery, roadmap, tickets) au point de fragmenter sa propre connaissance entre plusieurs endroits.

Augmentation : donner à l’IA un environnement de travail

Ici, je donne à l’IA un environnement de travail plus riche, de deux manières : davantage de contexte, ou davantage de capacités.

Commençons par le contexte. Pour chaque EPIC que je suis, je construis un NotebookLM consacré à ce sujet : la documentation Confluence, les comptes-rendus de réunion, les présentations déjà faites... Chaque notebook devient ma base de connaissance sur le sujet. Quand j’ai besoin de produire une présentation plutôt qu’une user story, par exemple, je bascule sur Gemini connecté au même notebook, pour profiter de l’option Canvas et avoir plus de liberté sur la mise en forme.

Passons à l’augmentation des capacités. Pour la discovery, je construis régulièrement des prototypes pour aligner ma vision avec celle des parties prenantes métier, et avoir des briques concrètes sur lesquelles échanger. Gemini Canvas atteint vite ses limites sur cet usage : au bout de quelques itérations, on finit par casser une partie du prototype existant. Je suis donc passé à Google AI Studio, qui permet de créer des interfaces avec de vraies interactions et de travailler par branches, pour proposer plusieurs versions de la fonctionnalité. AI Studio a aussi ses limites : il ne connaît ni le design system ni l’historique constitué dans mon NotebookLM, et tout doit être décrit dans le prompt. Ça tient car l’objectif est de se rapprocher suffisamment du produit pour retrouver les mêmes parcours sans forcément le répliquer à l’identique.

Le signal de saturation arrive quand le workflow devient assez répétitif et stable pour tourner sans intervention à chaque étape. C’est ce qui m’est arrivé avec les démos de fin de sprint : le contenu vient toujours de Jira et des mêmes KPIs de suivi, la structure ne change jamais. Deux obstacles m’empêchent pour l’instant d’automatiser cette étape : l’extraction du contenu depuis Jira est freinée par des droits d’accès API insuffisants, et Gemini a encore du retard sur son intégration avec Google Slides. C’est ce blocage qui m’a donné envie d’explorer le palier suivant.

Délégation : l’IA exécute une partie du workflow, sous contrôle

Avec la délégation, l’IA exécute une partie du workflow. Chez mon client, j’ai ainsi pu tester un agent interne connecté à Jira, capable de créer directement des tickets à partir d’une demande en s’appuyant sur des connexions à la documentation. Le workflow s’y prête : la structure d’un ticket est stable et la documentation de référence existe déjà.

Mais l’IA peut commettre des erreurs dans la rédaction des user stories, et ma connaissance du produit me permet de les détecter à la relecture. Parmi celles que je repère, deux types reviennent. Le premier est un résultat incomplet : l’IA peut oublier une partie des modifications à faire, par exemple mettre à jour les KPIs en haut d’une page et laisser de côté une section en bas. Je précise alors les éléments manquants pour qu’elle retravaille sa proposition.

Le second est une donnée douteuse. Si l’IA mentionne une table “Dimension Promo” dans mon application alors que je ne trouve qu’un indicateur précisant si un achat est promotionnel ou non, je lui demande où elle a trouvé cette information, je vérifie la source et corrige au besoin.

Quand une erreur passe, ce sont les développeurs qui en paient le prix. Ils relisent ce que l’IA a produit et perdent du temps à comprendre ce que le ticket veut dire. Dans le pire des cas, ils développent une fonctionnalité construite sur une hallucination. Avec de la chance, l’impact reste minime et l’équipe corrige vite mais il peut aussi exiger une refonte plus importante. La responsabilité du résultat reste entre mes mains, même quand l’exécution est déléguée.

Cette supervision a toutefois ses limites : tant que je dois traiter individuellement les erreurs et les exceptions, le gain reste partiel. Le signal de saturation apparaît lorsque plusieurs étapes doivent s’enchaîner et interagir, de la création de l’EPIC jusqu’aux tickets, aux release notes et à la mise à jour de la documentation, au point que piloter le workflow devient une tâche à part entière.

Vient alors le palier suivant : l’orchestration.

Orchestration : quand plusieurs agents doivent collaborer

Lorsque les tâches atteignent un certain niveau de complexité, mieux vaut ne pas les attribuer à un seul agent, qui risque de traiter chaque partie en surface. Une approche consiste à créer plusieurs agents spécialisés qui collaborent au fil d’un même workflow, sous la supervision d’un agent coordinateur : c’est ce qu’on appelle l’orchestration.

En tant que PM, c’est la première fois que je m’attaque à ce genre d’architecture, et j’en suis encore au stade de l’expérimentation. Mon point de départ est un problème que je vis chaque semaine : mes cadrages de MVP ont presque toujours la même structure d’un EPIC à l’autre, mais avec les outils autorisés chez mon client, aucune des présentations générées n’a le même design, car aucun ne sait appliquer un template et l’adapter dynamiquement au besoin. Je reprends donc chaque cadrage à la main. L’idée est de construire un système capable de générer un cadrage complet à partir de mes présentations et comptes-rendus, conforme à mon design system. J’en retiens trois complexités pour l’instant.

La complexité technique : chaque agent appelé via l’API ne peut produire qu’un volume limité de tokens par requête. Si je lui demande de créer un cadrage de A à Z, j’obtiens quatre ou cinq slides à moitié vides : il a trop à faire. Itérer slide par slide avec un seul agent reste possible, mais la coordination se fait manuellement, ce que l’orchestration cherche à éviter. Un agent coordinateur doit donc déléguer à des agents spécialisés : l’un structure la présentation, un autre rédige chaque slide, un expert tech vérifie la véracité technique, un designer met en forme, avant ma propre relecture. Je définis les rôles, les objectifs et l’ordre des étapes, et le coordinateur gère les échanges entre agents.

La complexité de pilotage : avec un seul agent, je relis une sortie et je juge. Avec plusieurs agents, le résultat dépend d’une chaîne d’étapes où chacune s’appuie sur la précédente, et il devient difficile de savoir si le système produit le résultat attendu, ou seulement quelque chose qui y ressemble. Malgré des critères de complétion pour chaque phase et une quinzaine de fichiers de suivi, je ne sais toujours pas avec certitude si j’ai avancé vers un résultat exploitable. Comme l’IA qui m’aide à développer le système a tendance à foncer sans prendre de recul, je dois spécifier en amont le résultat exact attendu de chaque phase, bien au-delà des critères d’acceptation d’une user story, avec des compétences d’architecte agentique en plus de celles d’un PM.

La complexité opérationnelle : un prototype qui tourne en local n’est pas un produit déployable. Mon système ignore pour l’instant les contraintes d’exploitation et de sécurité d’un vrai déploiement, à commencer par la gestion des identifiants et des droits d’accès, et tout ce travail d’Ops et de sécurité reste à faire. À cela s’ajoute le coût d’exécution. Plusieurs agents consomment beaucoup de tokens, et c’est le coordinateur qui décide du nombre d’échanges entre eux : même avec des limites fixées dans la configuration, le coût de chaque demande reste difficile à prévoir, avec un impact financier et environnemental.

Face à ces trois complexités, il reste à vérifier que le gain justifie l’effort, par rapport à ce que j’obtiens déjà avec NotebookLM et Gemini, suivis d’un travail manuel sur les slides.

Comment choisir son niveau ?

Pour situer une tâche, je me pose quatre séries de questions :

1. Valeur : est-ce que ça vaut le coup ?

• À quelle fréquence la tâche revient-elle, et est-elle suffisamment répétitive ?
• Combien de temps puis-je économiser ?
• Quel gain de qualité cela pourrait me faire gagner ?

2. Faisabilité : est-ce que je peux le faire ?

• Le workflow est-il suffisamment stable et connu, avec un objectif clair pour chaque étape ?
• Le contexte nécessaire est-il disponible et exploitable ?
• Quelles intégrations sont nécessaires ?

3. Risque : que se passe-t-il si l’IA se trompe ?

• Quelle part demande encore mon jugement, et puis-je repérer l’erreur avec mon expertise ?
• Quel est le coût d’une erreur, et puis-je l’annuler facilement ?
• Est-ce que cet usage risque de déresponsabiliser ou d’irriter un autre métier ?

4. Coût : combien cela va-t-il me coûter ?

• Combien de temps pour construire la solution ?
• Quel est son coût d’exécution, financier et environnemental ?
• Combien coûte sa maintenance et son évolution ?

Voici ce que la grille donne sur mes quatre exemples. Le message de release s’arrête à l’assistance : à deux exécutions par mois, ce que j’économiserais ne couvrirait jamais ce que coûterait la construction, et une erreur qui passe inaperçue abîme la crédibilité du produit auprès des Sales et des CSM. Mes démos de fin de sprint s’arrêtent à l’augmentation : le workflow est stable, mais faute d’accès API à Jira, je ne peux pas automatiser l’extraction. L’agent Jira passe en délégation parce que le workflow est stable et documenté, et que mon expertise me permet de repérer l’essentiel de ses erreurs à la relecture. Pour l’orchestration, la valeur est plausible puisque le problème revient régulièrement et prend beaucoup de temps de rédaction, mais la faisabilité et le coût restent à démontrer : l’exploitation, la sécurité et la consommation de tokens.

Choisir le bon niveau d’automatisation est une décision Produit avant d’être une décision technique. Automatiser déplace souvent le travail vers la relecture et le pilotage. Pour mon projet d’orchestration, je n’ai pas encore la réponse à cette question. Pour votre prochaine tâche, demandez-vous ce que vous y gagnez, et jusqu’où cela justifie d’aller.