Le constat
J’ai vécu les deux côtés. Côté dev, tu reçois un ticket “le bouton marche pas” sans URL, sans navigateur, sans étapes de reproduction. Tu passes 20 minutes à reproduire ce que le testeur a vu en 5 secondes. Côté QA, c’est pas mieux : rédiger un bon ticket demande d’ouvrir DevTools, copier la console, noter l’URL, le viewport, le navigateur, faire un screenshot, tout coller dans Jira. C’est fastidieux, alors les gens bâclent, et le cycle recommence.
Le vrai problème, c’est que le QA fait deux boulots en même temps : trouver le bug et documenter le bug. L’un est intéressant, l’autre est une corvée mécanique. QA Panel existe pour supprimer la corvée.
Ce que ça fait
Le QA ouvre l’onglet QA Panel dans ses DevTools, clique sur “enregistrer” et navigue normalement sur l’application testée. L’extension capture chaque clic, chaque saisie, chaque navigation en arrière-plan. En parallèle, elle surveille les requêtes réseau et note celles qui échouent avec leur status et le body de la réponse décodé.
Quand le bug se manifeste, le QA capture l’écran, annote la capture directement dans un canvas intégré au panneau, et pointe l’élément problématique avec un sélecteur CSS intelligent qui génère le chemin le plus court vers l’élément du DOM. Le ticket sort formaté en Markdown avec tout le contexte technique : navigateur, viewport, OS, étapes de reproduction horodatées, erreurs réseau, captures annotées.
Le QA peut aussi exporter les actions enregistrées sous forme de scénario Playwright, pour que le dev puisse reproduire le bug automatiquement en lançant un test E2E. Plus de copie-colle entre DevTools et Jira, plus de “c’est sur quel navigateur ?”, plus de tickets incomplets.
Stack
| Couche | Choix | Pourquoi |
|---|---|---|
| Framework extension | WXT 0.19 (Chrome MV3 + Firefox MV2) | Un seul code source, deux navigateurs cibles |
| Frontend | Vue 3.5, Composition API, <script setup> | Réactivité fine pour le panneau DevTools |
| State | Pinia 3 (setup syntax) | 5 stores pour gérer issues, actions, réseau, scénarios |
| Validation | Zod 4 (inférence de types) | Schemas partagés entre extension et types |
| Design system | Totem (chargé en local, “Soft Minimal 2026”) | Cohérence visuelle avec l’écosystème |
| Tests | Vitest + Playwright | Tests unitaires et E2E |
| Storage | idb-keyval (IndexedDB) | Persistance locale des scénarios et tickets |
| Icons | lucide-vue-next | Iconographie cohérente |
L’état du projet
Le projet existe sous forme de prototype intensif : 20 composants Vue, 14 composables, 5 stores Pinia. Tout a été écrit en quelques sessions pilotées via Claude Code, mais rien n’est versionné. Zéro commit git. C’est un prototype fonctionnel qui a validé le concept, qui capture des screenshots via CDP sur Chrome avec fallback captureVisibleTab sur Firefox, qui génère des rapports Markdown structurés, mais qui attend son premier commit et une vraie confrontation avec des testeurs sur le terrain.
Côté audit structuré, Basalt Beholder s’attaque au même enjeu de qualité mais depuis l’autre bout : des audits CMMI industrialisés avec génération de rapports PDF automatique. Les deux projets partagent cette obsession que les outils de qualité soient aussi agréables à utiliser que les produits qu’ils sont censés tester.
Stats
| Composants Vue | 20 |
| Composables | 14 |
| Stores Pinia | 5 |
| Cibles | Chrome MV3 + Firefox MV2 |