Plateforme chilienne de découverte de bières artisanales, produit et qualité
Chiffres au mois de novembre 2026
Cofondateur responsable de la gestion de produit et de la qualité au sein d’une équipe de 3 personnes, de la planification de tests fondée sur le risque à une nouvelle base d’automatisation de bout en bout.
- Rôle
- Cofondateur, Product Owner et responsable AQ
- Période
- 2026 à aujourd’hui
- Stack
- Next.js 15, TypeScript, MongoDB, Better Auth, Playwright
- Note
- Le code de l’application a été écrit par mes associés ; mon travail a porté sur la gestion de produit, les tests et le choix des outils.
Le problème
Une plateforme web pour découvrir des bières artisanales chiliennes, des bars et des brasseries sur une carte interactive allait vers le lancement sans tests formels, sans analytique et sans courriel officiel. Personne dans l’équipe n’était responsable du produit ni de la qualité.
Découverte
J’ai examiné l’état du projet par rapport au plan : j’ai analysé une réunion d’équipe enregistrée de près de deux heures, avec le brief de marque et le tableau du projet, et listé ce que l’équipe croyait prêt par rapport à ce qui était réellement construit. Les principaux écarts : pas de tests, pas d’analytique et pas de courriel sur le domaine propre du projet.
Décisions clés
- ▹Tester d’abord les zones les plus à risque. Les comptes et les permissions par rôle sont ce qui présente le plus de risque, ils sont donc passés en premier.
- ▹L’IA exécute, un humain vérifie. Des agents d’IA ont exécuté des sessions de test en parallèle ; j’ai conçu le plan, révisé les cas de test, vérifié chaque défaut manuellement et rédigé les rapports. La vérification manuelle a trouvé un défaut que les exécutions automatiques avaient manqué : une boîte de dialogue cachée derrière la carte.
- ▹Des outils simples aux limites claires. Pour l’analytique, j’ai recommandé un outil gratuit à la limite documentée (Umami) plutôt qu’un outil plus complexe, afin de réduire le travail de configuration et le risque pour la vie privée avant le lancement.
Ce que j’ai construit
- ▹Un plan de test fondé sur le risque. La portée de tout le site est estimée à 670 à 850 cas de test dans 12 zones.
- ▹Deux cycles de test : 144 cas de test exécutés (156 exécutions, dont 12 retests) et 24 défauts signalés (1 élevé, 10 moyens, 13 faibles) dans des rapports de style ISTQB.
- ▹Couverture des zones les plus à risque : compte et authentification 69 cas sur environ 90 ; permissions selon l’âge et le rôle 75 sur environ 110.
- ▹Une base d’automatisation de bout en bout avec Playwright, montée de zéro : paramètres régionaux et fuseau horaire du Chili, intégration au serveur de développement, premiers tests réussis. Sur la portée totale, 281 scénarios sont retenus pour l’automatisation et en cours d’implémentation.
- ▹Un document de décision d’outils pour l’analytique et le courriel du domaine, ainsi que les comptes rendus de réunion de l’équipe avec responsables et prochaines étapes.
Statut et résultats
Pré-lancement. Campagne de tests en cours et automatisation des 281 scénarios retenus en cours. Les constats de sécurité sont partagés en privé avec l’équipe.
Suite
Terminer l’automatisation des scénarios retenus, couvrir les zones restantes (tableau de bord des brasseries, découverte et carte, modération) et exécuter un cycle de régression avant le lancement.