Ce qui a changé : les signaux sont partout — fils Slack, tickets d’assistance, notes commerciales, problèmes Jira — et perdent leur contexte lorsque les équipes passent d’un outil à l’autre. Pourquoi c’est important : passer à côté du « pourquoi » d’une demande entraîne des sprints improductifs. Qui est concerné : les chefs de produit, les responsables de la recherche et les équipes de réussite client, qui doivent décider quels problèmes résoudre. Conseils pratiques : configurez les connecteurs et laissez l’agent Discovery importer les transcriptions, documents et tickets. Appuyez-vous sur un tableau des points de friction fondé sur des éléments probants, qui évalue la fréquence et la gravité, fait ressortir des citations représentatives de clients et met en évidence les signaux contradictoires. Risques et limites : des données d’entrée bruitées peuvent fausser les scores ; prévoyez une validation humaine pour corriger les biais d’échantillonnage.

Ce qui a changé : la priorisation doit désormais tenir compte de la faisabilité agentique autant que de l’impact métier. Pourquoi c’est important : le développement plus rapide rend la création moins coûteuse ; le principal défi consiste alors à choisir les bons paris. Qui est concerné : les chefs de produit, les responsables du design et les parties prenantes métier, qui arbitrent entre valeur, risque et faisabilité. Conseils pratiques : utilisez une matrice de notation double — un barème de 0 à 10 pour l’adéquation des LLM et des outils ainsi que la préparation opérationnelle, et un autre pour l’impact, l’effort et les contraintes réglementaires. Demandez à l’agent Prioritize de produire une matrice de notation classée, avec les éléments probants associés et une courte justification pour chaque score. Risques et limites : les pondérations reflètent la stratégie ; définissez-les et consignez-les à l’avance, puis réévaluez les scores lorsque de nouveaux éléments apparaissent.

Ce qui a changé : la conception doit désormais produire des livrables qui servent aussi de contrat aux agents de développement. Pourquoi c’est important : une spécification claire, assortie de critères d’acceptation, réduit les ambiguïtés et accélère la livraison de bout en bout. Qui est concerné : les équipes UX et produit, ainsi que les responsables de l’ingénierie qui reçoivent la spécification. Conseils pratiques : utilisez l’agent Working Backwards pour générer un PR/FAQ, puis le Spec Generator pour le traduire en parcours utilisateurs, personas, critères d’acceptation et brief de transfert design. Veillez à ce que chaque exigence renvoie au point de friction d’origine et au contexte de priorisation. Risques et limites : des spécifications trop prescriptives peuvent brider la créativité de l’ingénierie ; ajoutez une section « contraintes et intentions » pour que les équipes chargées de l’implémentation puissent proposer des arbitrages équivalents.

Ce qui a changé : les agents de design peuvent générer des maquettes filaires, des cartes de parcours et des prototypes HTML cliquables dans le même espace de travail que celui utilisé par l’Orchestrateur. Pourquoi c’est important : des prototypes rapides permettent aux parties prenantes et aux clients de réfuter des hypothèses avant même l’écriture du code. Qui est concerné : les équipes de recherche et UX, ainsi que les parties prenantes dont l’approbation est nécessaire avant que l’ingénierie ne s’engage. Conseils pratiques : utilisez Fast Track pour les domaines connus et Deep Discovery pour les nouveaux problèmes. Réalisez de courts tests d’utilisabilité ou des tests de conciergerie à partir du prototype cliquable, recueillez des mesures et des citations, puis réintégrez les résultats au tableau des points de friction. Risques et limites : un prototype peut donner une impression trompeuse de fidélité ; les expérimentations de design doivent mettre l’accent sur les objectifs d’apprentissage et les seuils d’acceptation.

Ce qui a changé : les agents de développement comme Kiro ou Claude Code peuvent exploiter des spécifications structurées via l’Agent Client Protocol (ACP) et produire rapidement du code fonctionnel, mais ils ont besoin d’un contrat déterministe. Pourquoi c’est important : une spécification prête au développement, accompagnée de tests d’acceptation, comble l’écart entre l’intention produit et l’implémentation. Qui est concerné : les responsables de l’ingénierie, les ingénieurs SRE et les responsables de la sécurité. Conseils pratiques : regroupez les exigences, les modèles de données, les critères d’acceptation et les cas de test dans un fichier unique, prototype_spec.md ; utilisez des adaptateurs compatibles avec ACP pour le transfert et imposez une étape de validation humaine permettant d’accepter ou de refuser la spécification. Risques et limites : les développements automatisés peuvent accélérer de mauvaises décisions ; prévoyez des points de contrôle explicites concernant la confidentialité, la conformité et la cohérence architecturale.