IA & outils développeurs
Nous avons construit une IA qui bêta-teste votre app
2026-04-14 · 6 min de lecture
Le mois dernier, notre IA a refusé un déploiement. Les tests automatisés étaient verts, mais le produit n'était pas prêt : des contrôles étaient trop proches, un état d'erreur cassait sur les petits écrans, et un chargement ressemblait à un crash. Le score était de 64 sur 100. Le verdict était simple : ne pas livrer.
C'est le problème que Gadget a été conçu pour résoudre. Ce n'est pas un LLM posé sur un framework de test. C'est un bêta-testeur avec des yeux : un système qui exécute des parcours produit, capture ce qu'un utilisateur verrait réellement, puis demande à un modèle vision de juger si l'expérience tient debout.
Les tests end-to-end répondent à la mauvaise question
Cypress, Playwright et Selenium excellent pour prouver que les chemins de code s'exécutent. Ils peuvent confirmer qu'un formulaire s'envoie, qu'une route change, ou qu'une API renvoie le statut attendu. Mais un produit peut satisfaire toutes les assertions et rester cassé aux yeux d'un utilisateur.
La question manquante est visuelle et expérientielle : est-ce que cela a l'air correct, est-ce lisible, est-ce qu'un utilisateur hésiterait, et l'interface est-elle entrée dans un état que personne n'a pensé à vérifier ? La QA manuelle détecte ces problèmes, mais elle passe rarement à l'échelle de chaque pull request, chaque viewport et chaque release candidate.
Ce qui change quand le runner peut voir
Gadget conserve ce qui fonctionne dans les tests E2E. Il utilise Playwright pour naviguer, cliquer, remplir et vérifier. La différence vient après chaque étape : le runner attend que la page se stabilise, capture une capture d'écran pleine page, puis envoie la séquence à Claude avec la posture d'un bêta-testeur humain.
Le modèle analyse la mise en page, la lisibilité, les états cassés, les frictions UX et les incohérences visuelles. Il classe les problèmes par sévérité et renvoie du JSON structuré, validé avec Zod, afin que le pipeline dégrade proprement quand la sortie du modèle est imparfaite au lieu de faire de l'outil le maillon faible.
Cinq choix de conception ont façonné le produit
D'abord, les tests sont écrits en YAML pour que les product managers, QA engineers et designers puissent décrire des parcours sans écrire de TypeScript. Ensuite, les sélecteurs suivent ce que voient les utilisateurs : labels, placeholders et noms accessibles avant les sélecteurs fragiles. Les fichiers de test restent ainsi plus proches de l'intention produit que du détail d'implémentation.
Troisièmement, les captures d'écran sont une partie centrale du pipeline. En mode audit, chaque étape est capturée, mais seulement après l'inactivité réseau et un court délai de stabilisation, car un modèle vision ne peut pas distinguer une interface réellement cassée d'une page prise en plein chargement si le pipeline ne lui donne pas une image exploitable.
Quatrièmement, le prompt de revue est cadré de façon stricte. L'IA reçoit l'instruction de ne pas critiquer la couverture de test, la robustesse d'un mot de passe, la posture sécurité ou les pages de destination hors du parcours testé. Le travail de prompt le plus difficile consistait souvent à dire au reviewer quoi ignorer. Cinquièmement, la readiness est notée plutôt que réduite à un booléen : problèmes critiques, warnings, nitpicks et améliorations retirent des points à une base de 100.
La boucle agentique
La boucle d'audit est directe : parser le YAML, interpoler les variables, lancer Chromium, exécuter chaque étape, capturer les écrans, demander à Claude une revue de bêta-test, valider la réponse, agréger la readiness, puis produire des rapports pour les humains et les systèmes CI. Console, JSON, HTML, JUnit et annotations GitHub servent chacun une partie du même workflow.
Il existe aussi une seconde boucle. Gadget peut lire un git diff et générer des tests YAML ciblés sur les fonctionnalités modifiées, valider ces tests contre le schéma, puis les lancer immédiatement si besoin. Un agent écrit les tests ; un autre analyse ce que le produit avait vraiment l'air d'être pendant leur exécution.
Ce que nous n'avions pas anticipé
Le cadrage du prompt a compté davantage que le choix du modèle. Le temps de stabilisation a compté plus que prévu. La sortie structurée était non négociable. YAML a abaissé la barrière de contribution pour les non-engineers. Et le score a changé les conversations d'équipe : au lieu de débattre abstraitement de la readiness, tout le monde pouvait regarder le même nombre et les mêmes preuves visuelles.
La leçon est que les bugs coûteux ne sont pas toujours des crashes. Ce sont des expériences qui fonctionnent techniquement mais font hésiter, mal comprendre ou partir les utilisateurs. Les suites E2E traditionnelles attrapent les échecs d'exécution du code. Gadget vise l'écart entre du code qui tourne et un produit qui semble prêt.
Open source par défaut
Gadget est publié comme outil open source sous licence MIT. Le package tourne localement, utilise votre propre clé API Anthropic, et envoie les captures directement depuis votre machine vers le fournisseur de modèle. Le dépôt inclut le runner TypeScript, l'analyzer, le checker, les reporters, les prompts, des suites YAML d'exemple, des configurations CI, la documentation et des skills Claude Code.