Je suis d’accord sur le problème, pas forcément avec la solution.
Revenons donc à la base du problème.
Quels sont les types de problèmes utilisateurs qu’on rencontre sur le forum ?
- Un périphérique non-géré par Gladys qu’il pensait gérer dans Gladys mais n’arrive pas à le gérer.
- Un périphérique non découvert par Gladys alors qu’il devrait être compatible selon le site.
- un bug d’interface
Si tu vois d’autres cas précis de post sur le forum dis moi 
Dans 1., c’est un souci de communication: notre doc n’est pas assez riche et l’utilisateur pensait que ça allait marcher, alors que nous ne gérons pas le périphérique. L’interface aurait pu le prévenir en lui disant “Aucun périphérique détecté. Est-ce que votre périphérique est bien dans la liste des périphériques géré ? [INSERER LIEN VERS LISTE ICI]”.
Dans 2. c’est un souci de clarté d’interface. L’interface pourrait donner plus de retours sur ce que le code backend “voit” en “brut”. Il faut voir service par service comment on pourrait rendre l’interface plus clair avec des retours d’états plus fin de la data concrètement reçu par le backend. Exemple: dans le cas du Xiaomi, on pourrait afficher une liste de 10 derniers messages reçus par Gladys, en format quasi brut.
Dans le cas 3., souvent une simple description de comment reproduire le bug suffit à le reproduire côté dev.
Le problème que je vois avec une solution type “on sort un fichier export de l’instance Gladys et l’utilisateur le met sur le forum”, est qu’on incite l’utilisateur a être passif dans son débuggage, et que ça place l’utilisateur dans une relation “utilisateur <-> support client” avec le forum. Le fichier risque d’être un gros pavé remplit de jargon tech, que l’utilisateur ne lira pas (car illisible pour un non initié), il le copiera seulement sur le forum.
Le résultat ? La charge de support sur le forum ne va faire qu’augmenter, et la satisfaction utilisateur va paradoxalement diminuer car l’utilisateur devra attendre un retour d’un “expert”, “expert” qui ne sera pas disponible car il aura trop de requêtes à répondre.
Ce que je vois plutôt
L’utilisateur devrait avoir pour moi toutes les clés en main dans le produit pour voir ce qui ne va pas, et être ainsi acteur de sa résolution de problème.
Il faut faire une passe service par service pour identifier les points souvent bloquants, et ajouter dans l’interface plus de messages (d’erreurs, d’information) clair pour chaque point bloquant identifié.
Pour les simples soucis de compréhension (qu’est ce qui est compatible gladys?), il faut réussir à mieux rediriger vers la documentation au lieu du forum pour que l’utilisateur puisse s’auto-répondre et avoir sa réponse sans attendre
Qu’en pense tu ?
Je sais que mon post peut faire hyper complet pour la simple fonctionnalité que tu demandais, mais je pense qu’il est crucial de poser les bonnes bases pour s’éviter des heures de support inutile là ou une simple interface plus clair suffit souvent. C’est des petits choix d’UX simple comme ça qui vont faire que la v4 va pouvoir se “scaler” à plusieurs milliers d’utilisateurs ou pas.
