Découvrez les Suggestions : des retours utilisateurs qui deviennent des change requests
Vos Contributeurs peuvent désormais envoyer fonctionnalités, améliorations et correctifs sur votre tableau, et suivre ce qu'ils deviennent.
La plupart des équipes produit collectent déjà des retours. Le plus difficile, c’est la distance entre l’endroit où ils arrivent et celui où se prennent les décisions. Un client décrit un problème à un endroit, quelqu’un le recopie dans un ticket, quelqu’un d’autre le réécrit en requirement, et quand un agent de code s’en empare, la demande d’origine a été paraphrasée plusieurs fois.
Les Suggestions réduisent cette distance. Les personnes qui utilisent votre produit peuvent désormais envoyer leurs demandes directement dans votre projet Kairo, et suivre ce qu’elles deviennent.
Qui peut envoyer une suggestion
Les suggestions viennent des Contributeurs : clients, parties prenantes ou experts métier que vous invitez sur un projet. Un Contributeur dispose d’une page simple pour proposer des améliorations et suivre ce que deviennent ses suggestions. Il ne voit pas votre workspace interne : ni vos specs, ni vos chats, ni le reste de votre tableau.
Cette frontière est tout l’intérêt. Vous ouvrez la porte aux personnes les plus proches du problème, sans ouvrir votre roadmap.
Ce que contient une suggestion
Une suggestion a la même forme que le travail qu’elle peut devenir : un titre, une description, un type et une priorité. Les types sont ceux que votre équipe utilise déjà pour les change requests : une fonctionnalité, une amélioration ou un correctif.
Le formulaire indique aussi aux Contributeurs à quoi s’attendre : l’équipe projet examine chaque suggestion.
Votre équipe décide
Chaque suggestion arrive sur votre tableau de change requests, dans sa propre colonne, à côté du travail que vous êtes déjà en train de définir et de construire. Votre équipe l’accepte ou la décline.
Quand une suggestion recoupe une change request existante, elle est fusionnée dans cette change request au lieu de créer un doublon. Cinq clients qui demandent la même chose donnent du poids à une seule demande, au lieu d’en créer cinq.
Une suggestion acceptée suit ensuite le même chemin que toutes les autres change requests : l’IA de Kairo interroge l’intention, un skill transforme les réponses en document de requirements, et vos agents de code lisent le résultat via MCP.
Les Contributeurs voient ce qui s’est passé
Chaque Contributeur suit ses propres suggestions grâce à un statut simple : soumise, acceptée, terminée ou non retenue. Quand une suggestion a été fusionnée, il voit qu’elle est suivie dans une change request existante : il sait qu’elle a été entendue, même si elle n’a pas créé de nouvel élément.
C’est la liste en haut de cet article. Personne n’a besoin de demander si sa demande a été lue.
Pourquoi c’est encore plus important avec les agents de code
Quand les agents rendent l’implémentation rapide, le plus coûteux devient de décider quoi construire. Les retours utilisateurs comptent parmi les meilleurs éléments pour cette décision, et ils sont d’autant plus utiles qu’ils arrivent là où elle se prend : à côté des specs, dans le même flux, avec les mots de l’utilisateur.
Nous l’utilisons nous-mêmes
Les captures de cet article viennent de notre propre projet : nous construisons Kairo avec Kairo. Le correctif de dictée visible dans le formulaire ci-dessus est une vraie suggestion, acceptée et suivie dans une change request existante.