Avec un développeur backend, j’ai construit le MVP de PleaseFix pour vérifier qu’un même produit pouvait relier le signalement des joueurs, le triage des modérateurs et le suivi des équipes de développement. J’étais responsable de tout le frontend React, de son design system et de son architecture de thèmes.
Défricher le parcours
PleaseFix était un MVP de signalement et de suivi de bugs pour les jeux vidéo. Un joueur pouvait décrire un problème, retrouver un signalement existant et voter pour les bugs rencontrés. Ce tri communautaire aidait à faire remonter les sujets partagés par plusieurs personnes.
Les modérateurs disposaient ensuite d’un parcours de triage pour qualifier les signalements. Une automatisation créait ou reliait les bugs dans Jira afin que les équipes de développement puissent les intégrer à leur suivi habituel.
Une base pour plusieurs jeux
Le MVP devait confirmer la pertinence du parcours avec une équipe réduite : un développeur backend et moi côté frontend. Il fallait couvrir des usages très différents, du joueur au développeur, sans construire une solution rigide autour d’un seul jeu.
Nous avions besoin d’une base assez générique pour être déclinée. L’interface, les composants et les thèmes devaient pouvoir changer selon l’univers du jeu, tandis que les mécanismes de signalement, vote, triage et synchronisation restaient partagés.
Le frontend que j’ai construit
Je suis parti d’une base vide pour créer tout le frontend React. J’ai développé les fondations de l’application et les interfaces nécessaires aux parcours joueurs et modérateurs, en coordination avec le développeur backend pour le flux allant du signalement jusqu’à Jira.
J’ai également construit le design system et une logique de thèmes fondée sur des design tokens. Les couleurs, la typographie et les composants pouvaient ainsi recevoir un skin différent sans dupliquer toute l’interface.
Tokens, thèmes et reprise
Relier les acteurs dans un même flux
Le produit suivait une progression claire : le joueur signale ou vote, le modérateur trie, puis le sujet est créé ou relié dans Jira. Chaque interface exposait les informations utiles à son rôle tout en conservant la continuité du signalement.
Séparer les composants de leur apparence
Le design system portait la structure et les comportements communs. Les design tokens définissaient l’identité visuelle de chaque déclinaison, ce qui permettait d’adapter PleaseFix à plusieurs jeux sans réécrire les composants.
Préparer la reprise dès le MVP
La base devait rester compréhensible et extensible après la phase d’exploration. Lorsque le MVP a été repris par une équipe dédiée, elle a pu continuer à itérer en conservant cette logique de design system, de thèmes et de parcours partagés.
Ce que le MVP a permis
Le MVP a posé le fonctionnement complet du produit, du signalement joueur jusqu’au suivi dans Jira. L’équipe dédiée a ensuite poursuivi son développement et l’a décliné pour plusieurs jeux en réutilisant les fondations mises en place.
Je ne dispose plus du détail des tests qui ont précédé cette reprise et je ne lui attribue donc pas de métrique de validation. Le résultat documenté ici est la continuité de l’architecture et des principes produit dans les versions suivantes.
Le vrai sujet de ce MVP était la capacité de la base à changer d’identité selon le jeu tout en gardant les mêmes mécanismes.