Un panneau QA dans les DevTools

Le problème qu’on accepte tous

Le workflow QA dans un navigateur est une suite de micro-frictions que tout le monde tolère sans les remettre en question. On reproduit un bug. On ouvre les DevTools pour vérifier la console. On fait un screenshot. On note l’URL, le viewport, le user-agent. On ouvre Jira. On rédige le ticket. On colle le screenshot. On ajoute les étapes de reproduction.

Quinze minutes pour documenter un bug de trois secondes.

L’idée

Et si les DevTools avaient un panneau dédié à la QA ? Un endroit où on enregistre ses actions pendant qu’on navigue, où le contexte technique est capturé automatiquement, où le screenshot est annotable sur place, et où le ticket sort formaté en Markdown prêt à coller dans n’importe quel tracker.

C’est QA Panel.

WXT pour le framework

Le choix du framework d’extension s’est posé rapidement. Plasmo, CRXJS, WXT - les trois principaux. WXT a gagné pour une raison simple : le support natif Chrome MV3 et Firefox MV2 depuis le même code source. Un seul wxt build produit les deux extensions. Pas de fork, pas de conditions if chrome.

// wxt.config.ts
export default defineConfig({
  manifest: {
    name: 'QA Panel',
    permissions: ['activeTab', 'debugger', 'storage'],
    devtools_page: 'devtools.html',
  },
});

Le devtools_page est la porte d’entrée. C’est un HTML minimal qui enregistre un nouveau panneau dans les DevTools du navigateur. L’utilisateur ouvre F12 et trouve un onglet “QA Panel” à côté de Console, Network, etc.

4 entrypoints, 1 architecture

L’extension a quatre points d’entrée qui communiquent via le messaging natif du navigateur :

• DevTools panel : l’UI principale, Vue 3, Pinia, 20 composants
• Popup : création rapide de tickets sans ouvrir les DevTools
• Background : service worker qui intercepte le réseau et gère le storage
• Content script : injection dans la page pour la sélection d’éléments et l’enregistrement d’actions

Le content script est le plus délicat. Il injecte un sélecteur CSS intelligent dans la page visitée - on survole un élément, il se met en surbrillance, on clique, et le sélecteur CSS le plus spécifique est capturé. Comme l’inspecteur d’éléments des DevTools, mais orienté QA.

Capture d’écran cross-browser

Chrome offre le Chrome DevTools Protocol (CDP) pour des captures haute fidélité. Firefox n’a pas d’équivalent - on se rabat sur captureVisibleTab, qui capture seulement la partie visible. La logique est encapsulée dans un composable :

async function captureScreenshot(): Promise<string> {
  if (isChrome()) {
    return await cdpCapture(); // Full page, haute résolution
  }
  return await browser.tabs.captureVisibleTab(); // Visible uniquement
}

L’annotation canvas permet de dessiner des flèches, des rectangles, du texte sur la capture avant de l’inclure dans le ticket. Pas besoin de passer par un outil externe.

Totem à l’intérieur

L’UI utilise Totem, le design system maison, en version “Soft Minimal 2026”. C’est un choix de cohérence : les mêmes atomes (boutons, badges, cards) que dans les autres projets, mais adaptés aux contraintes d’une extension (popup de 400px de large, panneau DevTools à hauteur variable).

Les tokens de Totem sont chargés en local, pas via CDN. Une extension navigateur ne peut pas dépendre d’un réseau pour son UI.

L’état du projet

8 000 lignes de code. 20 composants Vue. 14 composables. 5 stores Pinia. Zéro commits git.

C’est un prototype intensif - le code est là, fonctionnel, mais non versionné. Le prochain pas est le premier git init, un nettoyage des imports inutilisés, et la publication sur le Chrome Web Store.

Le projet est en phase “pousse” dans le jardin. La graine a germé vite, mais il faut encore l’arroser.