PMania 6/6 - Du prompt au produit : votre premier workflow IA de bout en bout

PMania - Chroniques d'un PM augmenté par l'IA, épisode 6 (final)

Cinq épisodes plus tôt, je préparais une session de priorisation en un quart d'heure au lieu de deux, en déléguant la corvée de synthèse à une IA restée dans une fenêtre de chat. Depuis, cette IA est sortie de sa fenêtre pour travailler dans mes dossiers (épisode 2), j'ai appris à la traiter comme un vrai coéquipier capable d'agir seule (épisode 3), à la piloter avec des specs et des evals plutôt qu'un vague prompt (épisode 4), et à lui transmettre les règles maison via des skills (épisode 5). Il est temps d'assembler ces pièces dans un seul workflow, de bout en bout, sur un cas concret.

Le nouveau goulot d'étranglement

Avant d'assembler quoi que ce soit, un constat structurant : dans un cycle de développement classique, le facteur limitant a toujours été la capacité à développer, le sprint, la disponibilité des devs. Dans un cycle agentique, ce goulot d'étranglement se déplace : ce n'est plus la technique qui freine, c'est la spécification, les boucles de feedback et l'adoption.

“La charge de travail humaine glisse de la réalisation vers la planification et le contrôle qualité.”

C'est un changement de paradigme, pas seulement un gain de vitesse.

Le workflow, étape par étape

Prenons un scénario courant : votre équipe vient de récolter des dizaines de retours sur une fonctionnalité (verbatims d'interviews, avis, tickets support), et l'objectif est d'aller de cette matière brute jusqu'à des tickets de sprint prêts à développer, sans y passer trois jours. Voici comment les quatre briques des épisodes précédents s'enchaînent pour y arriver, chacune prenant en entrée le livrable de la précédente.

💡 Tips : les actions détaillées ci-dessous sont montrées dans Claude, tout simplement parce que c'est l'environnement que j'utilise au quotidien. La logique (Project pour le contexte, skill pour la méthode, agent pour l'action) se transpose chez la plupart des éditeurs, seuls les noms d'écrans changent.

Ce workflow ne part pas de zéro à chaque cycle : quatre briques doivent exister en amont, chacune créée une fois puis réutilisée à chaque nouvelle synthèse de retours.

Étape 1 : l'IA collecte et synthétise les retours utilisateurs

Livrable d'entrée : les retours bruts (verbatims d'interviews, avis, tickets support). Livrable de sortie : une synthèse structurée, pas encore priorisée.

Tout workflow commence, dans mon expérience, par la même étape que celle décrite en épisode 2 : un assistant configuré avec le bon contexte (rôle, produit, format de sortie attendu) lit les retours bruts et produit une synthèse structurée directement dans l'espace de travail de l'équipe. Le point de vigilance reste le même qu'à l'épisode 1 : vérifier les sources et les chiffres avant de considérer cette synthèse comme un livrable fiable, pas juste un premier jet inspirant.

Concrètement, dans Claude :

Étape 2 : un skill applique le template de spec maison

Livrable d'entrée : la synthèse structurée de l'étape 1.
Livrable de sortie : un mini-backlog de user stories avec critères d'acceptation, pas encore poussées dans l'outil de suivi.

C'est là que le skill de l'épisode 5 entre en jeu : plutôt que de repartir d'un prompt vague, on invoque sur cette synthèse une méthode déjà encodée, priorisation, rédaction de user stories avec critères d'acceptation au format Given/When/Then, structuration en épopées et features. Le gain n'est pas seulement le temps gagné, c'est la cohérence du livrable produit, quelle que soit la personne qui a lancé la tâche ce jour-là.

Concrètement, dans Claude :

Étape 3 : un agent connecté pousse vers vos outils

Livrable d'entrée : les user stories validées de l'étape 2. Livrable de sortie : des tickets créés dans l'outil de suivi, pas encore engagés dans un sprint.

Une fois les user stories validées et les critères d'acceptation posés, un agent connecté via MCP (épisode 4) prend le relais pour les pousser directement dans l'outil de suivi, Jira, Notion, ou équivalent, plutôt que de les recopier à la main. C'est le principe du moindre privilège qui s'applique ici très concrètement : l'agent a le droit de créer des tickets, pas de modifier le périmètre du sprint en cours sans validation. Et c'est aussi ici que le human-in-the-loop de l'épisode 3 devient très concret : plutôt que de laisser l'agent créer les tickets tout seul, on lui demande de s'arrêter et de présenter ce qu'il s'apprête à faire avant de le faire.

Concrètement, dans Claude :

Étape 4 : evals et point de contrôle humain avant publication

Livrable d'entrée : les tickets créés à l'étape 3.
Livrable de sortie : un sprint validé, prêt à démarrer.

Avant toute publication, deux garde-fous, non négociables : une eval qui vérifie que le livrable respecte le format et les critères attendus (épisode 4), et un point de contrôle humain explicite sur toute action qui engage l'équipe ou le produit, priorisation finale, validation d'un scope de sprint. C'est le curseur human-in-the-loop de l'épisode 3, appliqué à l'échelle d'un workflow complet plutôt qu'à une seule action.

« Lancer une eval » n'est pas un bouton à cliquer : concrètement, c'est demander à Claude de comparer chaque ticket créé à la checklist de critères définie dans la spec de l'épisode 4 (le même principe que la Quality Checklist du skill « Roadmap Challenger » de l'épisode 5), et de signaler ce qui ne passe pas. Pour une checklist qui revient à chaque sprint, on l'encode une fois pour toutes dans un skill dédié, plutôt que de la retaper à chaque fois.

Concrètement, dans Claude :

Ce que ça pourrait changer à l'échelle

En zoomant sur ce workflow, une question plus large se pose : et si ce n'était pas qu'un gain de temps sur une tâche, mais un changement de taille d'équipe ?

Une squad classique, c'est en général un PO ou un PM, un designer, plusieurs développeurs, et quelqu'un côté ops. Avec ce type de workflow, une équipe plus petite, appuyée par plusieurs agents spécialisés, pourrait produire un volume de travail comparable.

Ce n'est pas de la science-fiction : des équipes fonctionnent déjà sur un principe simple. Une personne pilote et supervise, elle lance les agents, les arrête, tranche en cas de doute. Un backlog partagé sert de tableau de bord commun, avec des colonnes claires : à faire, en cours, en revue, terminé. Plusieurs agents spécialisés (un qui analyse, un qui développe, un qui relit) se relaient sur ce backlog, sous surveillance humaine continue.

Pour le PM, ça change le métier au quotidien : moins de temps passé à produire soi-même un livrable, plus de temps passé à cadrer le travail des agents et à trancher. Pour le manager, ça change aussi la nature du rôle : il ne coordonne plus seulement des personnes, il organise aussi la répartition du travail entre humains et agents, en sachant à quel moment l'humain doit reprendre la main (priorisation, décisions d'architecture, sécurité).

Et cette bascule reste théorique tant qu'elle n'est pas confrontée au contexte réel, et aux risques déjà évoqués en épisode 1. Avant d'imaginer réduire la taille d'une équipe grâce à l'IA, quelques questions à se poser :

• Contractuel : a-t-on assez de recul sur le gain de productivité réel pour réduire les effectifs, ou est-ce encore trop tôt pour l'inscrire dans le contrat ou le budget ?
• Sécurité et gouvernance : la politique du client autorise-t-elle de connecter un agent à ses données ou à ses outils, et jusqu'à quel niveau d'autonomie ?
• Humain : que devient l'équipe en place ? Une charge concentrée sur moins de personnes, moins d'occasions d'apprentissage pour les profils juniors, un risque de perte de compétence si l'IA fait le travail à leur place ?
• Environnemental : le volume d'appels aux agents, donc de calcul, augmente avec l'échelle : est-ce qu'on mesure et questionne cet usage, ou l'IA devient-elle un réflexe systématique ?
• Maturité : quel est le niveau de maturité IA de l'équipe en face, et de l'organisation cliente ?

Le bilan : temps gagné, ce qui reste manuel, les vraies limites

Ce mouvement est déjà largement engagé, mais encore loin d'être maîtrisé. 88 % des organisations utilisent l'IA dans au moins une fonction (McKinsey, State of AI, 2025), et 66 % déclarent en tirer des gains tangibles (Deloitte, State of AI in the Enterprise, 2026). Mais le passage à l'échelle reste rare : seules 23 % ont réellement déployé leurs agents à grande échelle (McKinsey, State of AI, 2025).

Plus révélateur encore : 74 % espèrent une hausse de revenus grâce à l'IA, contre seulement 20 % qui en constatent une réellement (Deloitte, 2026). Malgré cet écart entre attente et résultat, 94 % des entreprises s'engagent à poursuivre leurs investissements IA même sans retour immédiat démontré (BCG, AI Radar 2026). Autre repère utile en garde-fou : Gartner prévoit que plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027, faute de valeur business claire ou de garde-fous suffisants.

Une enquête interne menée chez OCTO recoupe ce que je constate sur le terrain :

• Côté bénéfices :
  • un vrai gain de temps et de productivité (« je vais trois fois plus vite »),
  • une acquisition de compétences étendues au-delà du socle technique initial,
  • et un appui permanent qui agit comme un coéquipier disponible en continu pour challenger les idées.
• Côté limites :
  • une charge cognitive élevée liée au nouveau rôle de relecteur constant des livrables générés,
  • un risque de dépendance qui peut affaiblir les capacités de réflexion propre,
  • et un isolement accru quand l'autonomie réduit les moments de synchronisation directe avec les collègues.

Trois conseils reviennent systématiquement dans cette même enquête, et je les ai adoptés comme boussole personnelle pour clore cette série :

1. maintenir l'esprit critique (ne jamais déléguer sa réflexion de base à l'outil),
2. miser sur l'humain compétent (la relecture humaine reste indispensable pour valider la qualité), et
3. favoriser l'expérimentation (l'apprentissage passe par la pratique concrète des cas d'usage, pas par la théorie).

Les 3 choses à retenir de toute la série

• L'assemblage complet vaut plus que la somme des outils pris séparément. Un assistant contextualisé, un agent bien cadré, une spec comportementale, un skill partagé : c'est leur combinaison, pas un outil isolé, qui produit le vrai gain.
• Le workflow reste piloté par le PM à chaque étape clé. L'automatisation gagne du terrain sur l'exécution ; elle n'a jamais gagné de terrain sur le jugement, priorisation, arbitrage, décision finale restent humains, systématiquement.
• On ne termine pas sur une démo, mais sur un cas reproductible. La vraie mesure de succès d'un workflow IA n'est pas qu'il ait fonctionné une fois, mais qu'il tienne la charge, semaine après semaine, avec les mêmes garde-fous.

Maintenant, il n’y a plus qu’à passez à l’action

1. Reprenez une tâche déjà régulière (synthèse, rédaction de specs, suivi de sprint).
2. Donnez-lui le bon niveau de contexte, chat, assistant ou agent, selon l'épisode 2 de cette série.
3. Encodez la méthode récurrente dans un skill, selon l'épisode 5.
4. Fixez les points de validation humaine avant de lâcher quoi que ce soit en autonomie, selon les épisodes 3 et 4.
5. Mesurez avec des evals simples, pas seulement avec une impression de gain de temps.

C'est ainsi que se termine cette série de chroniques, non pas sur une certitude, mais sur une pratique qui continue de s'affiner à chaque sprint.

PMania, chroniques d'un PM augmenté par l'IA

1. Bienvenue dans l'ère du PM augmenté par l'IA : ce qu'un vrai PM doit savoir (et faire)
2. Votre backlog a gagné un coéquipier : quand l'IA sort du chat et entre dans vos dossiers
3. Ces nouveaux collègues qui n'attendent plus vos ordres : comprendre les agents IA
4. Piloter un agent au quotidien : specs, evals, sécurité
5. Apprendre à l'IA les règles de la maison : les skills
6. Du prompt au produit : votre premier workflow IA de bout en bout (cet épisode)