Dans Kookee, le tableau de retours se trouve sur le portail hébergé, et il demande un compte avant toute publication. C’est voulu. Un compte, c’est un vote, chaque publication a un auteur à qui répondre, et votre équipe décide de ce qui reste visible publiquement.
Pensez maintenant aux personnes qui tombent sur les bugs. Quelqu’un est en plein export, et le dernier graphique manque dans le PDF. Pour vous le signaler, il doit quitter la page, trouver votre portail, créer un compte, confirmer son e-mail et rédiger une publication que des inconnus liront. Quelques-uns le feront. La plupart fermeront l’onglet, ou en parleront au support une semaine plus tard, en deux mots.
Le widget du site a donc désormais un onglet Retours. Le visiteur écrit ce qui s’est passé, sur la page où c’est arrivé, et l’envoie sans compte. Le message va à votre équipe, et à personne d’autre. Dans la même version, j’ai aussi fait une chose que je repoussais depuis un moment : le chat IA, Demander à l’IA, est devenu facultatif.
Voici les règles que j’ai suivies pour le construire.
1. Demander le message, pas un compte
Le formulaire demande trois choses : le sujet (une idée, une amélioration, un bug ou autre chose), le message lui-même, et un e-mail si le visiteur veut une réponse. Quand votre site indique déjà au widget qui est connecté, l’e-mail est prérempli. La page où se trouvait le visiteur part avec le message : « l’export ne marche pas » arrive avec l’adresse de la page où il a planté.
J’ai bien envisagé le raccourci évident. Kookee gère déjà les utilisateurs invités, donc chaque message aurait pu en créer un. J’y ai renoncé. Un compte invité par message remplit votre liste d’utilisateurs de gens qui ne se sont jamais inscrits, et il promet quelque chose qui n’existe pas : un compte auquel personne ne peut se connecter, avec une publication que personne ne retrouvera. Un message du widget est enregistré pour ce qu’il est, un message, avec les coordonnées que le visiteur a choisi de laisser.
2. Rien n’est public tant qu’une personne ne l’a pas lu
Un formulaire ouvert sur Internet reçoit trois sortes de messages : des messages utiles, des idées à moitié formulées et du spam. Les envoyer directement sur un tableau public donnerait à votre tableau l’allure de votre boîte de réception.
Les messages attendent donc. Dans votre tableau de bord, la page Retours a une deuxième vue, Depuis le widget, avec chaque message, sa catégorie, son auteur s’il s’est présenté, la page d’origine et l’heure d’arrivée.
Un message ouvert propose trois actions. Ajouter au tableau le transforme en publication dans votre première colonne ouverte, sous un titre de votre choix. Lier à un retour existant sert pour une demande que vous avez déjà : le message rejoint ce retour au lieu d’en devenir le doublon. Ignorer le supprime.
À mon avis, c’est la liaison qui comptera le plus. Dix personnes qui décrivent la même fonctionnalité manquante de dix façons différentes doivent devenir une seule publication, avec dix personnes derrière. La publication garde leurs messages, et ceux qui ont laissé un e-mail peuvent avoir de vos nouvelles quand la fonctionnalité sort.
3. Prévenir l’équipe une fois par heure, pas à chaque message
Une notification par message fonctionne jusqu’au premier jour chargé. Ensuite, elle apprend à tout le monde à ignorer les notifications.
Le widget ne prévient donc personne en temps réel. Une fois par heure, si de nouveaux messages sont arrivés, chaque membre de l’équipe reçoit une notification dans le tableau de bord et un e-mail qui signale des messages en attente. Dix messages en une heure font un seul e-mail. Une semaine calme n’en fait aucun.
4. Un formulaire ouvert a besoin de limites qu’aucun humain n’atteint
Tout ce qu’un visiteur peut envoyer sans compte, un script peut l’envoyer aussi. Les limites se situent bien au-dessus de ce que fait une personne et bien en dessous de ce que fait un script : 30 messages par heure depuis une même adresse, 120 par heure pour tout un projet, et au plus 1 000 en attente d’examen. Quand la file est pleine, le widget refuse les nouveaux messages jusqu’à ce que quelqu’un en traite quelques-uns, et le tableau de bord en indique la raison.
Deux autres décisions viennent du même raisonnement. Un message que personne n’ajoute au tableau ni ne lie à une publication est supprimé au bout de 90 jours, pour que la file ne grossisse pas indéfiniment. Et un message envoyé ne compte pas dans votre quota mensuel d’API. Un formulaire de retours ne devrait rien vous coûter quand quelqu’un s’en sert.
5. Le chatbot aussi doit être facultatif
Jusqu’à cette semaine, le chat était le seul onglet impossible à désactiver. Accueil, Aide et Retours n’étaient que des compléments autour de lui. J’avais fait ce choix tôt, quand le widget n’était qu’un chat, et il a survécu à sa raison d’être.
Certaines équipes ne veulent pas encore qu’une IA réponde à leurs clients. D’autres ont une douzaine d’articles d’aide et savent que l’assistant répondrait surtout qu’il n’est pas sûr. D’autres encore veulent seulement un endroit pour leur documentation, leur journal des modifications et un formulaire de retours. Pour elles, un widget qui impose un chatbot est un widget qu’elles n’installent pas.
Demander à l’IA est désormais un onglet comme les autres. Décochez-le, et le widget n’a plus de chat nulle part : l’Accueil perd son champ de question, les articles perdent Poser une question sur cet article, et même un appel KookeeChat.sendMessage() depuis votre propre code ne fait rien. Le widget ne génère donc pas de réponse que personne ne lirait.
Un détail a demandé plus de soin qu’il n’y paraît. Le widget s’ouvrait sur le chat, puis passait aux onglets enregistrés quand ils arrivaient du serveur, un instant plus tard. Avec un chat peut-être désactivé, cet instant afficherait un chatbot que le propriétaire avait coupé, et un visiteur rapide pourrait commencer à y taper. Un panneau qui s’ouvre avec la page attend donc désormais ses paramètres, cinq secondes au plus. Si la requête bloque, le visiteur obtient le chat plutôt qu’une icône de chargement, et les vrais onglets prennent le relais à leur arrivée.
Le tableau de bord a son propre garde-fou : le dernier onglet coché ne peut pas être décoché, si bien qu’un widget affiche toujours quelque chose.
Ce que j’ai laissé de côté
Les réponses. Le widget n’a ni boîte de réception ni conversation. Pour répondre à quelqu’un, écrivez à l’e-mail qu’il a laissé. Un fil de réponses est un outil de support, et un formulaire de retours qui essaie d’en être un finit en version dégradée des deux.
Les votes. Les visiteurs ne peuvent pas voter depuis le widget. Le vote reste sur le portail, où un compte égale un vote.
La confiance dans ce que dit la page. Le nom, l’identifiant et l’e-mail qu’un site transmet au widget apparaissent sur le message avec la mention « Non vérifié ». Ce sont des étiquettes, pas des identités.
Pour l’obtenir
La balise script prend tout cela en compte sans aucune modification de votre site. Depuis npm, l’onglet Retours demande @kookee/react 1.13, et la désactivation de Demander à l’IA, la 1.14. Ouvrez ensuite Widget du site → Personnaliser, cochez Retours, et décochez Demander à l’IA si vous voulez un widget sans chat.
Pour ouvrir le formulaire depuis votre propre lien « Signaler un problème » :
KookeeChat.open('feedback');Le guide complet se trouve dans Recueillir des retours depuis le widget de votre site, et les autres onglets sont présentés dans Ajouter les onglets Accueil et Aide à votre widget.