Automatise les tests d'appli sur un vrai téléphone.Pas un émulateur qui devine.

Non. C'est votre vraie application sur un vrai téléphone. Les agents parcourent l'interface réelle et consignent des preuves rejouables : captures d'écran, journaux d'étapes, scripts de reproduction.

Aucune instrumentation ni intégration de framework de test. L'agent pilote l'application via l'écran, comme le ferait un utilisateur.

Les frameworks scriptés comme Appium et Maestro dépendent de sélecteurs qui cassent quand ton UI change. Le crew Device QA de Melaya lit l'écran réel : l'agent Frontend Engineer parcourt l'appli visuellement, donc un bouton déplacé ou un changement de texte ne tue pas l'exécution. Pour des assertions pixel-exact dans une suite CI mature, les scripts ont toujours leur place, et beaucoup d'équipes utilisent les deux.

Non. n8n, Zapier et Make exécutent des étapes trigger-action prédéfinies contre des API, et une appli mobile en cours de test n'en a généralement pas. Le Device Control de Melaya pilote un vrai téléphone Android : installe le build, ouvre les applis autorisées, lit l'écran, tape et navigue, et journalise chaque étape. Ces outils restent plus forts sur la largeur des connecteurs pour les automations web linéaires.

Chaque exécution Melaya produit des traces complètes : étapes horodatées, captures d'écran par écran et raisons d'échec typées. Le bundle knowledge transforme ces preuves en record consultable par build, et l'agent DevOps Engineer dépose des rapports via le bundle project_mgmt là où ton équipe travaille déjà. L'évaluation déterministe en premier exécute des vérifications basées sur des règles avant toute évaluation par modèle.

Oui. Construis les parcours une fois sur le canvas de Melaya avec ses agents, outils, triggers et portes d'approbation, puis sauvegarde n'importe quelle exécution comme pipeline réutilisable. L'agent Tech Lead planifie la couverture des parcours, l'agent DevOps Engineer intègre les exécutions dans ta cadence de release, et les mêmes parcours rejouent sur chaque build avec des preuves comparables.

Le Device Control de Melaya attend la notification sur un vrai téléphone Android, tape la notification, et vérifie que ton appli atterrit sur le bon écran en capturant une capture d'écran à chaque étape. Les deep links fonctionnent de la même façon : l'agent ouvre le lien et confirme l'écran de destination. Le bundle core lit les configs et journalise en parallèle de l'exécution sur l'appareil.

L'approbation HITL à chaque écriture. Le crew Device QA parcourt librement les parcours en lecture seule, mais toute étape qui publie, achète ou envoie s'arrête jusqu'à ce qu'une personne approuve, et le téléphone s'arrête pour une approbation sur l'appareil avant de publier quoi que ce soit. Les allowlists d'outils scopent les applis que le bundle phone peut ouvrir, et les traces complètes montrent chaque tap ensuite.

Oui. Exécute chaque variante comme un parcours parallèle sur du vrai hardware, et l'agent UI/UX Designer de Melaya compare les enregistrements côte à côte et signale les régressions. Les PMs obtiennent des captures d'écran par étape et les logs du bundle phone pour les deux variantes, donc la décision de release repose sur des preuves rejouables plutôt qu'une démo de couloir.

Oui. Melaya fonctionne dans le cloud ou sur ton runner local, et le téléphone de test se connecte à ce runner, donc les builds non publiés et les comptes de test ne quittent jamais tes machines. Le routage de modèle par étape sur 23 fournisseurs permet aux étapes sensibles de tourner sur des modèles locaux pendant que des modèles cloud moins chers rédigent le rapport.