Automatiser le flow Discovery : Tickets Jira avec Claude et Dust, sans déléguer le jugement produit

Ariane Ilgin, Lead Product Designer Indépendante, accompagne les équipes SaaS B2B dans la conception d’interfaces IA transparentes et explicables. Spécialiste des environnements réglementés (finance, ESG), elle transforme des données complexes en expériences utilisateurs claires, intuitives et conformes aux exigences européennes de l’AI Act.

À retenir

• L’IA (via Claude et Dust) automatise la production documentaire chronophage entre la phase de discovery et la création de tickets Jira, réduisant considérablement la friction opérationnelle.
• L’efficacité du système repose sur un workflow découpé en étapes strictes et l’utilisation d’agents spécialisés (séparant la réflexion de l’exécution), nourris avec un contexte précis (codebase, templates, glossaire).
• L’automatisation ne remplace pas le jugement produit : le Product Manager (PM) doit rester activement impliqué (« human in the loop ») pour cadrer les opportunités, arbitrer, prioriser et valider le passage d’une étape à l’autre.
• Le rôle du PM évolue : libéré de la rédaction documentaire à faible valeur ajoutée, il concentre son énergie sur les choix stratégiques et l’orchestration du travail entre l’humain et la machine.

Quatrième session du Grand Rattrapage, la série de talks organisée par Converteo et Le Ticket, et un cap dans la technicité : l’orchestration de premiers agents. Marion Jachimski, Head of AI Transformation chez AI Discipline, s’est attaquée à un moment critique du cycle produit, celui où beaucoup de valeur se perd : le passage de la discovery à la delivery.

Le problème : la traduction discovery > delivery est longue et inégale

Les enseignements d’une discovery sont souvent riches. Mais leur traduction en PRD, en arbitrages fonctionnels, en specs puis en tickets peut devenir longue, répétitive et de qualité inégale selon les équipes. C’est un travail de production documentaire indispensable, mais à faible valeur ajoutée intellectuelle : reformuler, décliner, mettre en forme, dupliquer des templates.

Pour le rendre tangible, Marion a pris un fil rouge : se mettre dans la peau d’un PM chez Jellyfin, bibliothèque multimédia open source façon Netflix. Problème identifié : sur une grande bibliothèque, les utilisateurs peinent à choisir un contenu, faute de preview, il faut ouvrir chaque fiche individuellement. Objectif de la session : partir d’une discovery déjà réalisée (fictive mais réaliste) et aller jusqu’aux tickets Jira, en deux grandes étapes : Claude pour transformer la discovery en PRD, puis Dust pour transformer le PRD en tickets, en gardant le contrôle humain à chaque étape.

Étape 1 – De la Discovery au PRD, avec Claude

Le point de départ : un document Notion de discovery standard (contexte, hypothèses, données disponibles, benchmark concurrentiel Netflix/YouTube/Plex, opportunités identifiées). Le setup mérite l’attention, car c’est lui qui sécurise la qualité :

• Claude en mode « Projet », pas juste un chat, avec Cowork pour que Claude enchaîne des actions en autonomie jusqu’à écrire dans Notion (le chat classique consomme moins de tokens mais convient à des besoins plus simples).
• Choix du modèle : Sonnet suffit pour cette tâche de réflexion, pas besoin d’Opus, plus coûteux.
• Un workflow en 5 étapes strictement imposé : review de la discovery (limites, biais), cadrage de l’opportunité, vérification de la codebase, proposition produit, puis rédaction du PRD final.
• Des règles transverses : le PM reste toujours propriétaire de la décision, aucune étape n’est sautée, économie de tokens.
• Du contexte additionnel attaché au projet : la codebase de Jellyfin (open source, donc récupérable, pratique aussi pour s’entraîner sans accès à une vraie codebase d’entreprise), un fichier de templates (PRD, spec, ticket) et un glossaire pour limiter les ambiguïtés et le risque d’hallucination sur le vocabulaire métier.
• Deux skills : un « challenger de PRD » qui vérifie la conformité aux principes produit, et un « Discovery to PRD » bien plus détaillé que les instructions du projet, précisant pour chaque phase l’objectif, les activités, les outputs et les questions à poser au PM.

En démo, le comportement de l’agent est révélateur. Claude va chercher lui-même le contenu Notion via le connecteur et refuse de sauter les étapes (« le process impose cinq étapes validées »). Il limite volontairement ses questions aux trois plus bloquantes plutôt que d’en lister dix, pour ne pas surcharger le PM. Il analyse la codebase pour repérer ce qui est réutilisable et préparer des questions concrètes pour les devs. Et à la phase finale, il refuse même de rédiger le PRD si des informations manquent (par exemple des seuils de déclenchement non définis), un garde-fou apporté par le skill « challenger de PRD ». Pourquoi ce mode « Projet » plutôt qu’une simple tâche ? Pour disposer en permanence du contexte (codebase, templates, glossaire) sans le rattacher manuellement à chaque conversation : une sorte de petit RAG personnel.

Étape 2 – Du PRD aux tickets Jira, avec Dust

Pourquoi Dust plutôt que rester sur Claude ? D’abord un choix historique (le workflow a été construit dès décembre, avant l’arrivée de Claude sur ce terrain), mais aussi une adéquation : Marion le trouve particulièrement adapté à la partie découpage/exécution, avec un bon équilibre coût/token. Le modèle sous-jacent reste interchangeable (GPT-5.5 ici, mais Sonnet aurait aussi convenu).

L’architecture repose sur un orchestrateur et des sous-agents spécialisés. Optimisation clé : Marion a séparé les rôles « agent qui réfléchit » et « agent qui exécute » pour gagner en vélocité, Dust étant plus lent quand tout est mélangé. Le déroulé tient en quatre étapes : un Spec Gatekeeper (agent de réflexion) vérifie que le PRD contient assez d’informations et répond par un statut visuel (bloqué / prêt avec hypothèses / validé) ; la rédaction de la spec (user stories « en tant que… je veux… afin de… », critères d’acceptation en Given/When/Then, edge cases) ; un agent de planification qui structure la restitution dans Jira (épiques, user stories) ; et un agent rédacteur qui crée effectivement les tickets, avec un label « AI generated » pour un statut de review intermédiaire avant intégration au backlog, bonne pratique pour stabiliser le workflow avant industrialisation.

Détail instructif : Marion avait tenté de reproduire cette partie sur Codex, sans succès. Non par manque de qualité de l’outil, mais parce que Codex partait directement en exécution et rédigeait le ticket d’un bloc, sans le côté séquencé et arbitré qu’elle recherche. D’où son message : chaque outil a ses forces et ses faiblesses, il faut tester par rapport à son propre besoin plutôt que suivre les tendances.

Ce que l’IA peut faire, et ce qu’elle ne doit pas faire

L’intérêt de ce workflow est qu’il révèle avec précision la frontière entre ce que l’IA fait bien et ce qu’elle ne doit pas porter seule. Elle excelle à reformuler, structurer, synthétiser, décliner un problème en exigences, préparer une documentation, créer des tickets à partir d’un template, vérifier la cohérence d’une spec, en un mot, réduire la friction documentaire.

En revanche, elle ne doit pas remplacer les moments de jugement produit : cadrer l’opportunité, arbitrer ce qui compte vraiment, challenger la faisabilité, décider du niveau d’ambition, prioriser, et surtout renoncer. Ces moments-là restent le cœur du métier. C’est ici que la notion de « human in the loop » prend tout son sens, non comme une précaution théorique en bas de slide, mais comme une discipline produit : la question n’est pas comment tout automatiser, mais où concentrer l’énergie humaine. Marion résume sa relation à l’IA par une image : celle du « sparring partner », un partenaire qui challenge et renvoie la balle, plutôt qu’un exécutant qui produit un livrable en un coup.

Deux points de méthode complètent le tableau. Le découpage en étapes n’est pas un dogme : le nombre d’étapes (cinq côté Claude, quatre côté Dust) est propre à chacun, à ajuster pour éviter un flow trop long qui finirait par ne jamais servir. Et la maintenance compte : les prompts et skills ne se mettent pas à jour tout seuls. Marion révise régulièrement ses instructions, par exemple après une mise à jour de modèle qui avait dégradé la qualité des réponses. Enfin, les devs sont sollicités tôt, dès la vérification de la codebase, pour arriver aux rituels de refinement avec des questions déjà dégrossies plutôt qu’un blanc.

Pourquoi c’est un sujet structurel pour les équipes produit

Ce cas d’usage est probablement celui qui préfigure le mieux l’évolution du rôle de PM. À mesure que la production documentaire s’automatise, la valeur du Product Builder se déplace vers ce que la machine ne sait pas faire : porter une intention produit, faire des choix engageants, dire non. Cela implique une compétence de conception nouvelle : savoir dessiner un workflow dans lequel la machine accélère la production, tandis que l’humain reste responsable de la décision. Automatiser sans discernement, c’est confondre vitesse et qualité. Concevoir le bon partage des rôles entre agents et humains, c’est précisément ce qui distingue une équipe produit augmentée d’une équipe simplement outillée.