Access Monitor
Sachez à l'instant où votre page critique ne charge plus — depuis un vrai téléphone Android, pas un bot.
- 2 cibles surveillées
- 6 000 checks / mois
- 2 Go de stockage de preuves
- 20 000 requêtes API / mois
- rétention de 60 jours
Le problème
Les moniteurs synthétiques traditionnels s'exécutent dans un datacenter : ils passent à côté des blocages par user-agent/géolocalisation et des challenges (403/CAPTCHA) qui n'apparaissent que depuis un vrai appareil mobile.
A qui cela s'adresse
Toute entreprise avec une URL/app critique (checkout, connexion, landing) doit savoir si elle charge correctement depuis un vrai appareil Android, pas un bot ou un navigateur headless.
Ce que vous nous envoyez
| Champ | Format | Validation |
|---|---|---|
| target | URL http(s) (ou nom de package Android pour app_launch) | Pas d'IP littérale, pas de caractères de contrôle, denylist SSRF — rejeté avec 422 à la création du check |
| check_type | url_load ou app_launch | Enum, par défaut url_load |
| frequency_minutes | Entier, minutes | Plafonné par les checks inclus / cibles incluses de votre plan |
| timeout_seconds | Entier, 5-120 | Par défaut 30 |
| failure_threshold | Entier, 1-10 | Échecs consécutifs avant l'ouverture d'un incident |
| alert_email / alert_telegram_chat_id / results_webhook_url | E-mail / id de chat Telegram / URL https:// | results_webhook_url doit être en https:// ; au moins un canal d'alerte recommandé |
| country_code | Code à 2 lettres | Doit être l'un des corridors inclus dans votre plan |
Ce qui s'exécute
- Le worker récupère les checks dus sur de vrais appareils Android (jamais un émulateur), jusqu'à la max_concurrency de votre plan.
- Chaque exécution charge la cible et enregistre status, latency_ms, une capture d'écran et une preuve signée.
- Une exécution classée comme échec côté client (votre site est en panne) compte tout de même comme une exécution autonome réussie, documentée en conséquence.
- Un incident s'ouvre dès que failure_threshold échecs consécutifs sont atteints.
Ce que vous obtenez
- Un MonitorRun par check (status, latency_ms, screenshot, evidence)
- Alertes
- Dashboard
- API/webhook selon le plan
Limites et quotas
Loading...
Autonomie
Les checks planifiés s'exécutent sans surveillance de bout en bout — récupération, chargement, preuve, alerte. L'escalade humaine ne se déclenche que si failure_threshold est dépassé ou si le worker lui-même ne peut pas atteindre un appareil (classe d'échec d'infrastructure).
Conformité
Preuve
PILOT evidence: 1,503 qualified backtests measured on a real Android phone with a real SIM (99.9% autonomy measured across those runs); network path recorded per run (Wi-Fi today). (Remarque : les déclarations de preuve sont publiées en anglais afin d'en préserver l'exactitude.)
Limites connues
- The screenshot doesn't replace functional business testing — only load is verified.
- AI Visual Change Intelligence (part of Web Assurance) isn't validated yet — not a dependency of Access Monitor's core.
- Runs from a real phone with a real SIM in the served corridor; today the browsing path is the phone's Wi-Fi (the site sees a local fixed-line ISP address, not a mobile-carrier address); the network path is recorded in every signed run.
- (Remarque : les déclarations de preuve sont publiées en anglais afin d'en préserver l'exactitude.)
Questions sur ce service
Guides associés
- Quelle est la différence entre la surveillance synthétique et la surveillance sur appareil réel ?
- Quelles preuves nécessite un audit de consentement aux cookies ?
- Qu'est-ce que la vérification géographique basée sur la carte SIM, et en quoi diffère-t-elle des vérifications par IP ou GPS ?
- Que couvre la vérification web sur appareil réel, et quand en a-t-on besoin ?
- Comment tester si une application ou un site web fonctionne sur des téléphones Android d'entrée de gamme ?