Un prompt peut-il remplacer Canny ?

Construis un tableau public de demandes de fonctionnalités dont la particularité est la déduplication.

Le tableau lui-même est ordinaire : n’importe qui peut poster un titre et une description, voter une fois par post, et commenter. Les posts portent un statut — ouvert, planifié, en cours, livré, refusé — et la roadmap publique n’est qu’une vue filtrée sur ce champ.

La partie qui mérite d’être bien construite : quand un nouveau post est soumis, calcule un embedding de son titre et de sa description, compare-le aux posts existants par similarité cosinus, et si quelque chose franchit un seuil, montre à la personne les quasi-doublons avant qu’elle ne soumette, avec un bouton « c’est aussi ma demande » qui vote sur le post existant au lieu d’en créer un nouveau. Dévier le doublon au moment de la soumission est bien plus efficace que fusionner après coup.

Pour ceux qui passent quand même, donne à l’admin une action de fusion qui déplace les votes, les commentaires et les demandeurs vers le post survivant, garde les titres fusionnés comme alias pour que la recherche les retrouve encore, et qui soit réversible. Une fusion irréversible sur une mauvaise estimation détruit un signal irrécupérable, donc stocke la fusion comme un lien plutôt que de supprimer la ligne.

Envoie un email à chaque votant d’une demande quand son statut change, en un seul message groupé plutôt qu’un par post, et toujours avec un lien de désabonnement. Ce bouclage de la boucle est la seule raison pour laquelle les gens postent.

Le spam est la réalité opérationnelle d’un tableau public : limite le débit par IP, exige une confirmation par email avant qu’un post n’apparaisse, et mets en revue les premiers posts des nouveaux venus.

Hors périmètre : les intégrations avec des outils de support, l’attribution de revenu, le SSO. Affiche les votes comme des comptages, jamais comme un score de priorité — dès qu’un tableau classe par votes, la roadmap appartient à qui a organisé une campagne.