AWS Quick reçoit six agents pour les product managers : des plaintes clients à la spécification

Les agents de code ont appris aux équipes à écrire du code en quelques jours au lieu de plusieurs semaines. L'effet secondaire est désagréable : si vous avez rapidement construit ce qu'il ne fallait pas, vous arrivez simplement plus vite à l'échec. Dans son blog, AWS propose de déplacer l'effort vers l'amont, là où l'équipe choisit le problème et formule la tâche. Pour cela, l'entreprise a lancé AI-PDLC, un ensemble de six agents au sein d'AWS Quick.

Quel problème cela résout

Les signaux sur les besoins des clients sont dispersés dans une dizaine de systèmes. Les retours sont dans Slack, les enseignements des ventes dans Salesforce, les incidents dans ServiceNow, les exigences dans SharePoint, les tâches dans Jira, et les décisions se noient dans les e-mails et les réunions. À chaque transmission, le contexte se perd, et le développeur reçoit un ticket d'une ligne sans explication de son utilité.

AWS Quick joue ici le rôle de couche de liaison. Des connecteurs d'entreprise récupèrent les données, le système construit un graphe de connaissances sur les personnes, les projets et les décisions, et les agents s'appuient sur ces données et déposent leurs résultats dans un Space partagé. L'équipe ne démarre pas chaque initiative de zéro.

Comment fonctionne le pipeline

L'utilisateur ne dialogue qu'avec l'orchestrateur. Celui-ci lit les instructions des spécialistes en cours d'exécution, pose des questions sur l'étape en cours et transmet la tâche à l'agent approprié. On ne peut avancer qu'après qu'un humain a validé le résultat. Toutes les décisions sont consignées deux fois : le spécialiste les note dans son artefact, l'orchestrateur tient un journal commun et vérifie que les entrées sont bien présentes.

Le billet détaille quatre étapes « produit » sur huit. Les quatre autres (Engineer, Ship, Operate, Learn) restent aux agents de code.

• Discover. L'agent collecte les plaintes dans Slack, Jira, les tickets de support et Salesforce, évalue chacune selon sa gravité et sa fréquence, et produit le Pain Point Board.
• Decide. L'agent Prioritize attribue des notes de 0 à 10. Pour les cas agentiques, il examine l'adéquation aux capacités du LLM, la disponibilité des outils et l'adoption par les utilisateurs. Pour les applications classiques, il évalue la faisabilité, l'impact sur le business et la charge de travail. Ensuite, Working Backwards rédige un PR/FAQ selon la méthode d'Amazon, avec des questions sur l'économie unitaire, les modes de défaillance, les risques réglementaires et les concurrents. Si l'idée n'y survit pas, vous le savez sur le papier, et non après des sprints.
• Design. Spec Generator transforme tout cela en une spécification avec critères d'acceptation, scénario utilisateur et contraintes. Chaque exigence est liée à la douleur d'origine, à la note de priorité et au PR/FAQ.
• Prototype. L'agent Designer dessine des parcours, des wireframes et des prototypes HTML cliquables.

Le fichier final s'appelle prototype_spec.md. Ses critères d'acceptation servent deux objectifs : ils constituent le contrat pour l'agent de code et la grille d'évaluation pour l'agent de revue. La transmission passe par l'Agent Client Protocol (ACP), un standard ouvert basé sur JSON-RPC 2.0. L'exécutant peut être Kiro, Claude Code ou un autre agent compatible.

Le rythme est choisi à l'avance. Deep Discovery pose 8 à 12 questions par étape et convient à un domaine inconnu. Fast Track se limite à 3–5 questions et propose des réponses par défaut, qu'on peut accepter ou modifier.

Comment démarrer et où l'appliquer

Il faut un espace de travail AWS Quick avec le client de bureau et les droits de création d'agents personnalisés avec des connecteurs branchés. Ensuite, étape par étape :

• clonez le dépôt AI-PDLC sur GitHub et récupérez le fichier JSON avec les agents ;
• dans Quick Desktop, allez dans Customize → Agents → Create → Create from File ;
• créez un Space partagé pour les artefacts et donnez l'accès à l'équipe ;
• choisissez l'orchestrateur et écrivez « Run the full pipeline » ou « Fast Track ».

Au repos, les ressources ne coûtent rien. AWS décrit trois scénarios. Un nouveau produit parcourt tout le chemin. Une nouvelle fonctionnalité peut sauter la recherche approfondie. Un bug de production se réduit à un seul cycle, où la cause racine est consignée comme douleur et où la spécification contient des critères d'acceptation vérifiables.

Limites

Il s'agit d'un billet de fournisseur. La phrase « les semaines se transforment en jours ou en heures » est une estimation d'AWS, sans mesures ni analyse de déploiements réels. La solution est liée à l'écosystème Quick et à ses connecteurs : hors d'AWS, il faudrait tout assembler à la main. La qualité dépend aussi des données d'entrée. Si Slack est bruité, l'évaluation de la gravité des problèmes le sera aussi, et l'humain dans la boucle doit de toute façon vérifier les conclusions.

Ce qu'il faut en retenir

Les idées sont utiles même sans AWS. La spécification pour un agent de code doit renvoyer à la source de chaque exigence. Les critères d'acceptation gagnent à être rédigés pour servir à la fois de tâche et de grille de revue. Des points de validation sont nécessaires entre les étapes, et non un seul « approuver » à la fin. Si vous êtes déjà sur AWS, prenez le dépôt comme base et faites tourner Fast Track sur une petite fonctionnalité : on verra vite si l'approche apporte un gain à votre équipe.