Precheck : sachez que votre scan mobile fonctionnera avant qu'il ne tourne pendant des heures

Un scan mobile qui ne trouve rien devrait signifier que l'application est sûre. Trop souvent, cela signifie qu'elle n'a jamais dépassé son écran de connexion.

Precheck est une nouvelle étape des scans mobiles Ostorlab. Elle s'exécute dans tous les scans mobiles dynamiques : elle installe l'application sur un appareil physique, la lance, se connecte avec vos identifiants et exécute vos prompts d'interface. Si un blocage survient, par exemple un build impossible à installer, une application qui plante ou se fige, ou des identifiants refusés, le scan est marqué en erreur, et vous obtenez la raison ainsi que l'écran qui la prouve.

Le scan continue en arrière-plan : vous recevez toujours les résultats de l'analyse statique et toute la couverture dynamique que permet une application qui ne fonctionne qu'en partie.

Que fait Precheck ? (TL;DR)

Precheck confirme que l'application peut réellement être testée. Lorsqu'un blocage l'en empêche, Precheck marque le scan en erreur et ajoute un lien Learn more vers le graphe d'appels de l'interface, où chaque écran est coloré selon son statut. L'analyse statique et toute la couverture dynamique accessible vont tout de même jusqu'au bout.

Pourquoi un rapport vide est le pire des rapports

Un scan mobile complet exécute plusieurs analyses en parallèle : analyse statique, analyse dynamique, traces d'appels et interception du trafic. Ensemble, elles peuvent prendre des heures. La couverture dynamique dépend d'une seule condition : l'application doit réellement s'exécuter et être utilisable sur l'appareil.

Lorsque ce n'est pas le cas, le scan « se termine » quand même :

• Le build cible une architecture que l'appareil ne prend pas en charge : il ne s'installe jamais.
• L'application plante sur son écran de démarrage, ou se fige.
• Le mot de passe de l'environnement de staging a expiré la semaine dernière : tous les écrans authentifiés restent hors d'atteinte.
• Une étape 2FA n'a pas été configurée : l'application attend indéfiniment un code.
• Le backend de staging est indisponible : l'application affiche « Unable to connect » et ne fait rien d'autre.

Dans chaque cas, l'analyse dynamique explore ce qu'elle peut et ne remonte que peu de résultats, voire aucun. Un rapport silencieux issu d'une exécution défaillante ressemble trait pour trait à celui d'une application sûre. Vous le découvrez des heures plus tard, si tant est que vous le découvriez.

Dans un pipeline CI/CD, un pipeline qui passe pour de mauvaises raisons est pire qu'un pipeline qui échoue.

Precheck est conçu pour lever cette ambiguïté.

Ce que vérifie Precheck

Precheck exécute deux vérifications dans l'ordre. Si l'application ne peut pas être installée, la vérification de l'interface est ignorée.

1. Le build s'installe-t-il sur l'appareil ?

Precheck prend un appareil physique, le remet dans un état propre et installe votre build. Il ne s'arrête pas à « l'installateur a répondu OK » : il confirme aussi que l'application est bien présente sur l'appareil.

• Android (APK, AAB, XAPK) : le package doit figurer dans la liste des packages installés sur l'appareil. Precheck lit également l'activité de lancement de l'application dans le binaire. Pour les bundles XAPK, il parcourt chaque APK scindé jusqu'à trouver l'APK de base.
• iOS (IPA) : le bundle doit figurer parmi les applications installées sur l'appareil. Precheck lit le fichier Info.plist du bundle et compare à l'appareil l'identifiant du bundle, la version minimale d'iOS et les capacités matérielles requises.

Un build impossible à installer est signalé comme une erreur : aucune analyse dynamique ne peut fonctionner sans lui, mais l'analyse statique s'exécute quand même.

2. L'application se lance-t-elle, se connecte-t-elle et suit-elle vos prompts ?

Precheck confie ensuite l'application à Monkey Tester, l'agent IA d'Ostorlab qui pilote les interfaces mobiles. Il lui transmet :

• l'appareil à utiliser,
• les identifiants que vous avez configurés (identifiant et mot de passe, champs clé/valeur personnalisés, et 2FA par SMS, e-mail, TOTP ou manuelle),
• vos prompts d'interface, les instructions en langage naturel que vous donnez au scan, par exemple « accepter les conditions, passer l'onboarding, ouvrir la page des virements ».

Monkey Tester lance l'application, se connecte et traite chaque prompt. Il ne se contente pas de prendre des captures d'écran : il évalue chaque écran qu'il atteint.

Chaque écran reçoit un verdict

Pour chaque capture d'écran, Monkey Tester renvoie quatre informations :

Champ	Signification
prompt	Le prompt sur lequel il travaillait au moment de la capture, le cas échéant
status	ONGOING, SUCCESS, ERROR ou CRITICAL
reason	Ce qui, à l'écran, a conduit à ce statut
remediation	Ce que vous pouvez faire pour y remédier, pour ERROR et CRITICAL

• ONGOING : l'étape est en cours et rien d'anormal n'a encore été détecté.
• SUCCESS : le prompt a été mené à bien, et le résultat est visible à l'écran.
• ERROR : le prompt a échoué (par exemple, un bouton désactivé ou un virement qui n'a pas abouti), mais l'application fonctionne toujours.
• CRITICAL : un véritable blocage. Les identifiants fournis ont été refusés, ou l'application plante en boucle ou est figée.

Chaque écran est marqué de son statut : vous voyez d'un coup d'œil ce qui fonctionne et ce qui ne fonctionne pas, et chaque statut s'accompagne de la raison précise qui l'explique et de la manière d'y remédier.

Voici ce que cela donne sur un scan de Duolingo, où les prompts d'interface demandaient à Monkey Tester de commencer un cours de français, puis un cours de géorgien.

SUCCESS : connexion. Monkey Tester atteint l'écran d'accueil, ce qui prouve que les identifiants fonctionnent.

SUCCESS : un prompt mené à bien. L'écran de configuration du cours de français est ouvert : le prompt est donc marqué comme terminé.

ERROR : un prompt impossible à mener à bien. Duolingo ne propose pas le géorgien : le prompt échoue. L'application fonctionne toujours, il s'agit donc d'une ERROR et non d'un blocage.

CRITICAL : identifiants refusés. L'application affiche « Wrong username or password » : rien de ce qui se trouve derrière la connexion ne peut être testé.

Le champ reason décrit ce qui a mal fonctionné de votre côté, comme un message d'erreur, un mot de passe refusé ou une permission manquante. Un exemple réel se termine par le correctif lui-même :

L'authentification a échoué avec un message explicite « Wrong username or password » après la saisie des identifiants fournis. Remédiation : fournir des identifiants Duolingo valides pour le compte de test.

Ce que vous voyez lorsque Precheck échoue

Lorsqu'un scan est marqué en erreur, la page du scan en indique la raison, avec un bouton Learn more qui ouvre le graphe d'appels de l'interface sur l'écran en échec. Le graphe d'appels de l'interface est la carte de tous les écrans atteints par Monkey Tester et des transitions entre eux, chaque écran étant coloré selon son statut Precheck.

Sous le capot : comment Precheck est construit

Precheck s'exécute comme une étape légère et distincte : Monkey Tester évalue chaque écran, et Precheck décide en dernier ressort si le scan est marqué en erreur.

Une étape dédiée, plutôt qu'une charge supplémentaire pour chaque analyse

Le raccourci évident aurait été d'ajouter des contrôles de santé à chaque analyse dynamique. Nous y avons renoncé, pour deux raisons.

1. La rapidité de la première réponse. Les tests dynamiques approfondis nécessitent une préparation complète de l'appareil, comme la mise en place de l'interception du trafic. Rien de cela n'est nécessaire pour savoir si l'application démarre : Precheck s'en dispense. L'application est la seule chose testée.
2. Un seul point de décision. Si chaque analyse détecte les échecs de son côté, vous obtenez des verdicts contradictoires. Une étape dédiée donne une réponse unique et claire.

Precheck s'exécute donc comme une étape légère à part entière, en parallèle du reste du scan.

Le modèle évalue, le code décide

Le modèle de Monkey Tester décidait déjà de l'élément sur lequel appuyer ensuite. Nous l'avons étendu pour qu'à chaque étape il renvoie aussi le prompt en cours, un statut, une raison et une remédiation.

Le modèle a pour consigne de :

• réserver CRITICAL aux blocages explicites,
• ne signaler les échecs de connexion que lorsque des identifiants ont réellement été fournis,
• formuler chaque raison comme un correctif, par exemple « configurer le numéro pour la 2FA par SMS » plutôt que « 2FA requise ».

Le modèle rend un verdict pour chaque écran. La décision de marquer le scan en erreur est prise par Precheck à partir de l'ensemble de ces verdicts : un seul écran mal interprété ne peut donc pas faire échouer un scan qui progresse manifestement.

La preuve d'abord, le verdict ensuite

Chaque écran visité par Monkey Tester est enregistré, avec sa capture, son statut, sa raison et le prompt d'interface associé, avant que Precheck ne prenne sa décision. Ainsi, lorsqu'un scan est marqué en erreur, les preuves sont déjà en place, et le lien « Learn more » ouvre toujours un graphe d'appels complet.

Ces verdicts sont également disponibles via l'API d'Ostorlab et les outils MCP : les assistants de code IA connectés à Ostorlab peuvent ainsi expliquer pourquoi un precheck a échoué.

Tirer le meilleur parti de Precheck

La plupart des erreurs de precheck viennent de la configuration du scan ; trois éléments comptent donc avant tout : les identifiants, des prompts d'interface rédigés comme des objectifs et la configuration de la 2FA.

• Fournissez des identifiants pour toute application dotée d'une connexion. Precheck peut alors les vérifier avant que le reste du scan ne s'appuie dessus.
• Rédigez vos prompts d'interface sous forme d'objectifs, par exemple « ouvrir la page des paramètres du compte », plutôt que sous forme de coordonnées ou de séquences de taps exactes. Precheck considère un prompt comme réussi lorsque l'objectif est visible à l'écran.
• Configurez la 2FA (secret TOTP, SMS ou boîte e-mail) si votre connexion l'exige. Un écran 2FA resté sans réponse est traité comme un blocage.
• En CI/CD, traitez une erreur de precheck comme une étape de pipeline en échec. Le message d'erreur indique ce qu'il faut corriger avant de relancer le pipeline.

Seul un scan qui s'est réellement exécuté mérite votre confiance

Un scan de sécurité ne vaut que par ses résultats, et seulement s'il s'est réellement exécuté. Precheck vérifie que le scan peut s'exécuter, sur un appareil physique, avec les vrais écrans de l'application, vos propres identifiants et vos prompts. Lorsque ce n'est pas possible, le scan est marqué en erreur et vous obtenez la raison, un correctif suggéré et l'écran qui montre le problème, plutôt qu'un rapport silencieux plusieurs heures plus tard.

Entre-temps, le scan continue et fournit tous les résultats qu'il peut.

Precheck s'exécute dans tous les scans mobiles dynamiques Ostorlab pour Android et iOS. Pour l'utiliser, lancez un scan mobile avec votre build, vos identifiants de test et vos prompts d'interface : Precheck s'exécute automatiquement. Consultez les prérequis du scan mobile pour la configuration.