L’agent de Momentic a trouvé 269 bugs en une heure, soit trois fois plus que Codex

Les tests automatisés détectent efficacement ce que l’équipe a déjà anticipé. Si un développeur a écrit le scénario « ouvrir le panier, cliquer sur payer, voir la confirmation », le système le reproduira fidèlement. Mais il n’essaiera pas de cliquer deux fois sur le bouton, de revenir en arrière pendant le paiement ou d’ouvrir le formulaire sur un écran étroit, tant que quelqu’un n’aura pas explicitement ajouté ces étapes.

La start-up Momentic propose une autre approche. Son agent QA Mo accède à une application fonctionnelle et se comporte comme un utilisateur persévérant : il inspecte les écrans, cartographie les actions disponibles, lance des vérifications en parallèle et documente les problèmes découverts. Il n’a pas besoin du code source pour cela.

Sur le benchmark publié par l’entreprise, Mo a trouvé 269 bugs confirmés en 60 minutes. Codex avec Playwright MCP en a détecté 86, Claude Code 59 et Devin 27. Le résultat paraît impressionnant, mais la principale conclusion n’est pas qu’« un agent a battu tous les autres ». Le point le plus intéressant est ailleurs : les tests se détachent progressivement des scénarios écrits à l’avance pour devenir une exploration autonome du produit.

Comment l’agent cherche ce qui ne figure pas dans le cas de test

Imaginons un service de livraison. Après une mise à jour, les tests habituels ont vérifié la connexion, la recherche d’un restaurant et la validation d’une commande. Tout est au vert. Pourtant, lorsque l’utilisateur revient de la fenêtre de paiement, l’adresse sélectionnée est soudainement réinitialisée. L’équipe n’avait pas prévu ce parcours et il n’existe donc aucun test correspondant.

Mo commence par construire le graphe de l’application : quels écrans sont accessibles et quelles actions les relient. Il répartit les grandes zones entre des agents distincts. L’un explore l’authentification, un autre le panier et un troisième le paiement. Des composants spécialisés analysent l’image de l’écran, repèrent les éléments d’interface nécessaires et suivent les changements d’état.

Pour éviter que les vérifications parallèles n’altèrent mutuellement leurs données, les agents réservent les ressources partagées. Plusieurs processus peuvent lire simultanément un même objet, mais un seul est autorisé à le modifier. C’est important pour les scénarios qui utilisent un compte commun, des commandes ou des enregistrements de test dans la base de données.

Cette approche n’impose pas de définir rigidement un XPath, le texte d’un bouton ou un attribut aria précis pour chaque action. L’agent reçoit un objectif en langage naturel et cherche lui-même comment l’accomplir. En cas de modification de la mise en page, cela peut rendre les vérifications moins fragiles, sans toutefois éliminer complètement le problème des tests instables.

Des chiffres solides, mais issus du benchmark du fournisseur

Le jeu de données comprend 1 396 bugs annotés dans quatre applications open source : Gitea, Metabase, Twenty et Saleor. En une heure, Mo a atteint un rappel de 19,3 % avec une précision de 84 %. Codex a obtenu un rappel de 6,2 %, mais une précision légèrement supérieure, à 86 %.

Autrement dit, Mo a trouvé nettement plus de défauts connus, mais ses signalements comportaient aussi un peu plus de faux positifs. L’écart de coût est également notable : chaque bug confirmé a coûté 2,67 $ avec Mo, contre 0,80 $ avec Codex. D’après ces données, Mo est plus efficace pour explorer largement un produit, tandis que Codex paraît plus économique lorsque le budget est limité.

Ces résultats doivent être interprétés avec prudence. Momentic a conçu le benchmark, les conditions du test et le système d’évaluation. Une première vérification a été réalisée par un modèle de langage, puis les résultats ont été examinés par un humain. L’entreprise a publié le jeu de données et l’environnement de test, ce qui permet de reproduire l’expérience, mais les chiffres présentés ne remplacent pas encore une comparaison indépendante sur votre propre produit.

Ce que les équipes peuvent faire dès maintenant

Il n’est pas nécessaire d’abandonner Playwright ou Selenium. Les tests scénarisés restent utiles pour les parcours critiques et prévisibles : connexion, paiement, attribution des droits et sauvegarde des données. L’exploration agentique est plus pertinente comme seconde couche, destinée à rechercher les problèmes inconnus.

Un pilote pratique est simple à mettre en place : lancer l’agent sur la préversion de chaque pull request importante, limiter son temps et son budget, puis confirmer manuellement les défauts détectés. Il faut ensuite comparer le nombre de bugs uniques trouvés, le nombre de signalements erronés et le nombre d’heures de QA manuel économisées.

Si l’agent trouve régulièrement des dysfonctionnements que les tests existants ne détectent pas, il peut être intégré au processus de publication. S’il se contente de répéter les vérifications déjà connues et génère du bruit, les beaux chiffres du benchmark d’un tiers n’apporteront rien à votre équipe.