Un board de feedback pour agents IA : laissez vos utilisateurs écrire le prompt

Un utilisateur vous écrit à 23 h. « Le bouton d'export ne fait rien sur Safari. »

Vous savez ce qui suit, parce que c'est arrivé cent fois. Vous lisez. Vous comprenez. Puis vous ouvrez un tracker et vous le réécrivez, avec vos mots, les chemins de fichiers, les étapes de reproduction et le contexte que l'utilisateur n'avait pas. Puis, plus tard, vous ouvrez un terminal et vous l'écrivez une troisième fois, sous forme de prompt.

Trois écritures de la même demande. La première était gratuite et venait de la personne qui a réellement rencontré le bug. Les deux autres sont les vôtres.

Ces deuxième et troisième écritures sont la partie du métier que les agents ont rendue absurde.

La dernière chose que vous tapez encore à la main

Les agents de code ont supprimé beaucoup de frappe. Ils n'ont pas supprimé le brief. Il faut toujours dire à l'agent quoi construire, avec assez de détail pour qu'il ne devine pas, et ce quelque chose reste un humain assis devant un clavier à convertir les mots des autres en instructions.

Sauf que la conversion est souvent inutile. Un bon rapport de bug contient déjà ce dont un agent a besoin : ce qui était attendu, ce qui s'est passé, sur quelle page, dans quel navigateur. Une bonne demande de fonctionnalité contient déjà l'intention et la raison. La personne qui l'a écrite était plus proche du problème que vous.

Ce qu'on fait à la place, c'est traiter ce texte comme une matière première à retraiter, parce que l'outil qui l'a collecté et l'outil qui exécute n'ont jamais été le même. Le feedback vit dans un produit, les tickets dans un deuxième, et l'agent tourne dans un terminal qui ne connaît ni l'un ni l'autre.

Supprimez l'écart, et l'étape de réécriture n'a plus d'endroit où se produire.

Ce que devient un board de feedback quand le board sait exécuter

Un backlog public est une page que vos utilisateurs peuvent atteindre. Ils signalent un bug, demandent une fonctionnalité, votent pour ce qu'un autre a demandé, suivent un fil et voient un statut changer. Jusqu'ici c'est un board de feedback, et il en existe de très bons.

La différence tient à l'endroit où le ticket atterrit. Il n'atterrit pas dans un produit de feedback en attente d'export. Il atterrit dans le board de tâches d'où vos agents travaillent déjà, comme un ticket de plein droit, à côté de ceux que vous avez écrits vous-même.

De là, le passer en cours démarre un agent dont le brief est le ticket : le titre, la description avec les mots du rapporteur, la page où il était, le navigateur qu'il utilisait, et la conversation que vous avez eue avec lui depuis. Personne n'a rien réécrit. Le prompt, c'est le signalement.

La conséquence intéressante n'est pas la vitesse. C'est que la personne qui a décrit le problème est désormais celle qui a spécifié le travail, ce que tout le monde prétend attendre du feedback utilisateur et que presque personne ne structure. Cette inversion porte un nom, c'est un backlog piloté par le client : la file cesse d'être votre supposition sur ce qui compte et devient la trace de ce qui a réellement été demandé.

Trois portes, parce qu'on signale là où on est

Un board de feedback ne fonctionne que si signaler coûte moins cher que râler ailleurs. Cela veut dire aller chercher les gens là où le problème s'est produit.

La page publique est la porte évidente : une URL que vous partagez, avec une vue liste ou roadmap, des votes et un formulaire. Elle convient à un produit dont les utilisateurs la mettront en favori, et elle sert en même temps de preuve visible que le travail avance, ce qui vaut mieux qu'un mail de statut que personne ne lit.

Le widget embarquable est la deuxième : un petit script sur votre propre site qui ouvre un formulaire sur place. La personne ne quitte jamais la page où se trouve le bug, c'est-à-dire le moment exact où elle est le plus disposée à le décrire.

L'extension Chrome est la troisième, et c'est celle qui change le plus les comportements. Votre utilisateur sélectionne le texte cassé sur n'importe quelle page, clique sur l'extension, et le ticket part avec l'URL et la sélection déjà jointes. Ce que vous recevez n'est plus « ça ne marche pas », c'est un signalement avec des coordonnées.

Pour une agence, la troisième porte est souvent le client lui-même, et le mode portail client est sur invitation : un board par client, invisible pour les autres, sans abonnement SaaS supplémentaire dans la pile.

Le routage, parce que « le bon agent » n'est pas un seul agent

Un ticket entrant n'est adressé à personne. C'est le problème pratique de toute boîte de réception : il faut bien que quelqu'un décide qui le prend.

Les tickets venus de l'extérieur sont routés vers l'agent dont la spécialité correspond, si bien qu'une mise en page cassée part chez un spécialiste frontend et une requête qui fuit chez un backend, sans que vous triiez la file à la main chaque matin. Quand rien n'est configuré, le repli est volontairement bête et prévisible : le premier agent de développement du projet, jamais un rôle marketing ou PM qui se trouverait en haut de la liste.

Vous pouvez aussi pointer un ticket vers une équipe d'agents entière plutôt que vers un seul, pour qu'une demande client passe par une étape dev puis une étape QA avant de vous revenir.

Ce que tout le monde oublie : ce que le rapporteur voit revenir

Collecter du feedback est facile. C'est en refermant la boucle que les produits perdent les gens.

Quand un ticket part en développement, son auteur est prévenu. Quand il est priorisé, il est prévenu. Quand vous décidez de ne pas le faire, il est prévenu, avec le motif que vous avez écrit, ce qui vaut infiniment mieux que le silence. Et quand le correctif est réellement livré, il reçoit un message qui le dit, regroupé en une notification par version plutôt qu'en cinq mails pour cinq tickets.

Il y a un détail plus petit qui compte plus qu'il n'en a l'air : le commit qui clôt un ticket utilisateur crédite son rapporteur par son prénom, et ce crédit survit jusque dans le changelog public. Les gens qui voient leur nom attaché à une livraison signalent aussi le bug suivant. C'est tout le mécanisme de rétention, et il ne coûte rien. Faites tourner cette boucle quelques mois et vous obtenez du développement piloté par le feedback comme un fait observable plutôt que comme un slogan : les votes décident de l'ordre, et l'ordre décide des versions.

Si une demande arrive floue, le cadrage de ticket s'intercale entre le signalement et le travail : un agent Product Manager transforme la demande vague en maquette de votre vrai produit avec la modification appliquée, de sorte que vous validez l'idée sur le même ticket avant qu'une ligne de code soit écrite.

Là où les outils classiques s'arrêtent

Ce n'est pas un procès fait aux acteurs installés. Canny, Featurebase, Fider et UserVoice font bien la collecte, la déduplication et le classement, et ils ont des années de finition sur ce qui compte pour une équipe produit. Ils s'arrêtent au même endroit pour la même raison structurelle : ils ont été construits pour des organisations où l'ingénierie est un autre département, joignable seulement par un export.

La dernière ligne est celle qui tranche. Dans une grande équipe, réécrire une demande en spécification est un vrai métier à vraie valeur, et l'export n'est pas le goulot. Dans une équipe de une à cinq personnes qui livre avec des agents, cette réécriture est le goulot, et c'est de la perte sèche.

Ce que ça ne résout pas

Un board de feedback branché sur des agents n'est pas un pilote automatique, et le traiter comme tel produit exactement ce à quoi on peut s'attendre.

Les mauvais tickets produisent toujours du mauvais travail. Un signalement d'une ligne sans chemin de reproduction ne donne rien à l'agent, et il fera quelque chose de faux avec assurance. Le board ne peut transmettre que ce qui a été écrit.

Rien ne fusionne tout seul. Un agent produit une branche et un diff, et toutes les règles que vous aviez sur la relecture du travail d'un agent restent valables, en particulier sur ce qui touche à l'authentification, aux paiements ou aux données. Un ticket venu d'un inconnu n'est pas une raison de baisser cette barre. C'est une raison de la monter.

Et le volume est réel. Un board public qui marche devient bruyant, ce qui est un bon problème avec un coût réel. Les doublons sont signalés à la soumission, les votes séparent ce qu'une personne voulait de ce que quarante personnes voulaient, et fermer un ticket avec un motif écrit va plus vite que de le laisser pourrir. Mais quelqu'un lit toujours la boîte de réception.

La mise en place

Ouvrez le backlog d'un projet, cliquez sur Backlog public, choisissez une URL et un mode de visibilité. C'est toute la mise en place, et la page est en ligne à ce moment-là.

Ce que vous faites ensuite compte davantage. Mettez le lien là où vos utilisateurs sont déjà : dans l'app, dans vos réponses au support, en bas de vos notes de version. Un board de feedback que personne ne connaît ne collecte rien, et le mode de défaillance de cette fonctionnalité n'est pas technique : c'est que le lien n'est jamais partagé.

AgentsRoom est le centre de commande sur lequel tout cela tourne : un board de tâches où une carte devient un agent qui travaille, une page de feedback publique ou privée branchée dessus, un widget embarquable, une extension Chrome, et des notifications client qui partent quand le travail est réellement livré. Compatible avec Claude Code, Codex, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe et Kimi Code.

Téléchargez AgentsRoom et publiez votre premier board.

Questions fréquentes

Qu'est-ce qu'un board de feedback pour agents IA ?

Une page publique où vos utilisateurs signalent des bugs et demandent des fonctionnalités, branchée sur le board de tâches d'où vos agents exécutent. La différence avec un outil de feedback classique tient à la dernière étape : au lieu d'exporter la demande vers un tracker et de la réécrire en prompt, le ticket devient lui-même le brief de l'agent, avec les mots de celui qui l'a écrit.

Un ticket utilisateur peut-il vraiment lancer un agent IA tout seul ?

Le démarrage reste un acte délibéré : quelqu'un déplace le ticket en cours, et l'agent démarre avec le ticket comme prompt. Ce qui est automatique, c'est le routage, qui envoie un ticket entrant vers l'agent dont la spécialité correspond. Exécuter automatiquement tout ce qu'un inconnu écrit n'est pas une fonctionnalité, c'est une faille.

En quoi est-ce différent de Canny, Featurebase, Fider ou UserVoice ?

Ces produits excellent à collecter, dédupliquer et classer la demande, et ils s'arrêtent tous au même endroit : ils vous rendent une liste priorisée, et un humain transforme encore chaque ligne en travail. Ils n'ont pas de couche d'exécution parce qu'ils ont été pensés pour des équipes produit dont les ingénieurs sont ailleurs. Le pari est ici l'inverse : la surface de collecte et la surface d'exécution sont le même objet.

Faut-il rendre sa roadmap publique pour s'en servir ?

Non. Public, non listé et sur invitation sont trois modes distincts. Une agence qui tient un board par client utilise le mode sur invitation, et aucun moteur de recherche ne le voit jamais. Un développeur solo qui veut des demandes et des votes utilise le mode public. La partie exécution fonctionne pareil dans les trois cas.

Qu'est-ce qui empêche un board public de se remplir de bruit ?

Rien n'empêche le bruit d'arriver, et prétendre le contraire serait malhonnête. Ce que le board change, c'est le coût du traitement : les quasi-doublons sont signalés à la soumission, les votes disent ce qui est réellement voulu, et un ticket que vous ne ferez pas se ferme avec un motif qui parvient à son auteur. Les tickets que vous gardez arrivent avec le contexte qu'un inconnu a déjà écrit pour vous.