DrizzVision mise sur l’IA visuelle pour tester les applis mobiles

À Bengaluru, DrizzVision veut simplifier un métier où la moindre retouche d’interface peut faire dérailler une campagne de tests. Son agent Fathom utilise des modèles visuels pour comprendre l’écran d’une application mobile et exécuter des consignes en langage naturel, sans dépendre uniquement d’identifiants techniques figés. L’idée compte pour les équipes produit et QA, car elle vise les tests qui cassent à la première modification d’un bouton, d’une page ou d’un pop-up. Reste un point têtu : la fiabilité chute dès que l’environnement change.

Quand l’écran change, le test casse moins vite

Le projet est né d’une frustration classique du développement mobile : aller vite puis passer deux ou trois jours en tests de bout en bout, selon Yash, l’un des cofondateurs. Avec Asad, il a commencé à travailler sur cette idée en 2024, au moment où les modèles de vision devenaient capables d’interpréter des écrans d’ordinateur. DrizzVision s’est alors éloignée des outils d’automatisation traditionnels, comme Appium, qui s’appuient sur la structure interne d’une application pour cliquer sur des éléments précis.

Cette méthode fonctionne tant que l’interface reste stable. Mais un bouton renommé, une page redessinée ou une fenêtre inattendue suffit à casser le script, même si la fonction métier n’a pas bougé. DrizzVision dit vouloir “just understand the screen and execute”, autrement dit reconnaître ce qui est visible à l’écran et agir en conséquence. Une promesse simple sur le papier. Beaucoup moins dans un téléphone réel.

Pop-ups, icônes et “self heal” : le vrai terrain de jeu

La startup prend l’exemple d’une application de livraison alimentaire. Pendant une commande, un utilisateur peut tomber sur une offre promo, une demande d’autorisation ou une autre fenêtre surgissante. L’agent est censé ignorer ces interruptions et poursuivre le parcours prévu. “A pop-up ideally should not break your test case”, a déclaré Yash. “It should say that your checkout functionality is working fine. Although there were three pop-ups that we saw on our way.”

Le même raisonnement vaut pour les changements d’interface. Si un bouton “Edit” devient une icône de crayon, l’IA devrait toujours comprendre la fonction visée et continuer. Yash parle de système qui “self heal”, c’est-à-dire qui ajuste son comportement quand l’interface bouge. DrizzVision affirme avoir fait baisser la “test flakiness”, soit le taux de tests instables ou intermittents, de 15 % à 50 % à environ 3 % sur son benchmark interne, avec des résultats qui varient selon le client et le cas d’usage.

Des résultats très inégaux selon les modèles et les écrans

Les chiffres fournis par DrizzVision invitent toutefois à la prudence. La société a testé Fathom sur Android avec six configurations de modèles frontier et 20 tâches, dans deux environnements distincts, en répétant chaque combinaison cinq fois. Dans la suite la plus simple, sur une image Android standard, les modèles ont réussi 217 exécutions scorées sur 300, soit 72,3 %. Dans la suite plus difficile, qui utilisait une image Android rootée et des tâches plus complexes, ils n’ont réussi que 86 exécutions sur 300, soit 28,7 %.

Les écarts entre modèles sont eux aussi marqués. GPT 5.6 Luna a obtenu 64 % sur la suite la plus simple mais 4 % sur la plus dure. Gemini 3.5 Flash a fait moins bien dans la première, avec 54 %, puis mieux dans la seconde, avec 34 %, devant toutes les configurations GPT testées sur ce volet. DrizzVision précise que ce benchmark mesure l’ensemble du système — modèle, agent Fathom et image Android utilisée — et non le modèle seul. Autrement dit, comparer ces scores comme on comparerait des temps au 100 mètres serait un peu trop confortable.

La sécurité des données et le marché qui s’ouvre

La question ne porte pas seulement sur la performance, mais aussi sur les données. “The screenshot should not leave the device”, a expliqué Yash, alors que les applications testées peuvent contenir des informations personnelles ou financières. Pour ses déploiements clients, DrizzVision dit utiliser ses propres modèles sur site, plutôt que de dépendre entièrement de grands modèles cloud. Le cofondateur évoque aussi comme objectif proche un modèle de moins d’un milliard de paramètres capable de gérer la moitié, ou davantage, de la charge de travail.

Commercialement, la startup a commencé avec un outil en ligne de commande, piloté avec Walmart, où les utilisateurs écrivaient des tests dans des fichiers texte pour les lancer sur des émulateurs locaux. Le produit est désormais accessible via desktop, web, pipelines CI/CD et une interface MCP, ce protocole permettant à des assistants de code de piloter des outils externes. DrizzVision revendique plus de 10 clients entreprise et plus de 20 PME en Inde, ainsi qu’une autorisation de citer Tata 1mg parmi eux. Elle a levé 2,7 millions de dollars en amorçage et emploie environ 15 personnes.

La société se situe aussi face à des outils comme Maestro, très utilisés aux États-Unis. Yash dit s’attendre à ce que DrizzVision le complète plus souvent qu’elle ne le remplace, car les deux produits ne visent pas exactement le même problème : Maestro s’appuie sur des flux YAML, des attentes automatiques et l’arbre d’accessibilité, tandis que DrizzVision cible les tests qui cassent quand l’interface change. La startup voit déjà plus loin, vers la vérification d’agents IA capables d’agir à la place des utilisateurs, un marché qu’elle juge potentiellement sept à dix fois plus important que ses contrats actuels. Ce n’est pas encore un revenu, mais la piste est sur la table.