Identifier les appels à events.mapbox.com restant malgré la télémétrie coupée

Contexte

Epic : #8
Prérequis : #26 (carte, PR #142)
Securite-et-RGPD · Architecture-Technique › Environnements

Découverte de CODE pendant #26 (Inbox) : avec setTelemetryEnabled(false) et MGLMapboxMetricsEnabled=false, le simulateur iOS contacte encore events.mapbox.com/events/v2 au lancement. Ce sont peut-être les événements de facturation obligatoires (sessions actives), non la télémétrie ; le contenu, chiffré, n'a pas été vérifié. Mapbox est listé comme sous-traitant dans Securite-et-RGPD, mais ce flux n'y est pas décrit. À établir avant la production.

Comportement attendu

Le contenu des appels à events.mapbox.com est établi sur iOS et Android (proxy de débogage sur simulateur et émulateur, données fictives), et comparé à la documentation Mapbox.
Si ce sont des événements de télémétrie, ils sont coupés ; si ce sont les événements de facturation obligatoires, la nature des données envoyées (identifiant, position ou non) est décrite dans un commentaire de ce ticket, pour que DESIGN l'inscrive dans Securite-et-RGPD.

Critères d'acceptation

Contenu des requêtes relevé sur iOS et Android, sans jeton ni donnée réelle dans le ticket — résultat de CODE, 2026-10-09
Soit plus aucun appel de télémétrie (vérifié au proxy), soit les données restantes décrites en commentaire — télémétrie coupée ; restent l'événement de facturation appUserTurnstile et sdk-sessions/v1, décrits
Toute PR qui en découle déclare son niveau et une revue OWASP (A09, données personnelles vers un sous-traitant) — sans objet : aucune ligne de code ne change, aucune PR

Notes techniques

Si la télémétrie est déjà coupée et qu'aucune ligne de code ne change, CODE rend le résultat en commentaire, sans PR ; la clôture sans PR se décide alors avec Ilan, et la description du flux passe à DESIGN par un ticket needs-design.

🔨 Démarrage — plan :

Relever les requêtes vers events.mapbox.com derrière un proxy de débogage local (mitmproxy), sur le simulateur iOS (iPhone 17 Pro) puis l'émulateur Android (AVD Medium_Phone), sur un lancement à froid, un déplacement de carte et la sélection d'un parcours, avec les données fictives du seed local.
Anonymiser le relevé (jeton masqué, identifiants tronqués, position arrondie ou masquée) et le comparer à la documentation Mapbox (télémétrie vs événements de facturation map.load / turnstile).
Télémétrie : la couper par une PR. Facturation obligatoire : décrire ici la nature des données envoyées, sans PR.

Résultat — appels à `events.mapbox.com` : événements de facturation, pas de télémétrie

Conclusion : la télémétrie Mapbox est bien coupée sur iOS et Android. Les seuls appels restants sont l'événement de facturation appUserTurnstile, qui compte l'utilisateur actif mensuel (MAU), et l'ouverture d'une session de facturation. Ils ne contiennent aucune position. Aucune ligne de code ne change, donc pas de PR. La clôture sans PR revient à MANAGER, sur décision d'Ilan. L'inscription du flux dans Securite-et-RGPD passe à DESIGN par un ticket needs-design, comme le prévoient les notes techniques.

Méthode

Code de origin/main (8d498e0), dev builds @rnmapbox/maps 10.3.5 (Maps SDK 11.23.1, MapboxCommon 24.23.1), API locale avec les données fictives du seed, position fictive (République, Paris).
Proxy de débogage local : mitmproxy, via pipx run, rien d'installé sur le système. Un addon ne consignait que les hôtes *.mapbox.com et masquait à la volée le jeton (access_token), le paramètre sku et les UUID. Aucun flux brut n'a été écrit.
iOS (simulateur iPhone 17 Pro, iOS 26.4) : un PAC système envoyait au proxy les seuls hôtes *.mapbox.com. La CA mitmproxy était posée sur le simulateur seulement.
Android (AVD Medium_Phone, API 34) : proxy de l'émulateur seulement. CA en certificat utilisateur, et un build debug local, non commité, avec une network_security_config qui accepte les CA utilisateur.
Scénario sur chaque plateforme : lancement à froid, deux à trois déplacements de carte, « Rechercher dans cette zone », sélection d'un parcours (marqueur, tooltip, fiche résumée). Ensuite, plus de 3 minutes d'attente pour laisser partir un éventuel lot d'événements, puis passage en arrière-plan.
Fin de session : CA retirées du simulateur et de l'AVD, proxys rétablis, app de l'AVD réinstallée depuis main sans la config de capture.

Relevé anonymisé

	iOS	Android
Lancement à froid	1 × `POST events.mapbox.com/events/v2?access_token=<masqué>` → 204 · 1 × `GET api.mapbox.com/sdk-sessions/v1?access_token=<masqué>&sku=<masqué>` → 200	2 × `POST events.mapbox.com/events/v2` → 204 (même `userId`, à 3 s d'écart : lanceur du dev client puis app) · 1 × `GET api.mapbox.com/sdk-sessions/v1` → 200
Déplacement de carte	aucun appel `events`	aucun appel `events`
Sélection d'un parcours	aucun appel `events`	aucun appel `events`
Attente > 3 min, arrière-plan	aucun appel `events`	aucun appel `events`

Aucune tuile n'a été demandée pendant les relevés : elles venaient du cache local du SDK. Les appels events et sdk-sessions passaient bien par le proxy, donc par la même pile HTTP.

Corps de events/v2 (JSON gzip, environ 400 octets), identique sur les deux plateformes aux libellés d'appareil près :

[{
  "event": "appUserTurnstile",
  "version": "2.0",
  "created": "2026-10-09T14:59:15.046Z",
  "userId": "<UUID aléatoire généré par le SDK>",
  "enabled.telemetry": false,
  "skuId": "00",
  "sdkIdentifier": "mapbox-maps-ios | mapbox-maps-android",
  "sdkVersion": "11.23.1",
  "locationEnabled": true,
  "locationAuthorization": "whenInUse",
  "accuracyAuthorization": "full",
  "device": "iPhone (arm64; Simulator) | emu64a (arm64-v8a; sdk_gphone64_arm64)",
  "model": "<idem>",
  "operatingSystem": "iOS Version 26.4.1 (…) | Android 14",
  "mapboxAgent": "MapboxCommon/24.23.1 Widoo/0.1.0/1 (app.widoo) <OS> <modèle> …"
}]

En-têtes : user-agent (identifiant et version de l'app, version de l'OS, modèle d'appareil), x-mapbox-app-info: app.widoo;IOS|Android, x-mapbox-sdks, content-encoding: gzip. Sur iOS, Sentry ajoute aussi sentry-trace et baggage à ces requêtes : c'est une découverte, déposée dans l'Inbox. sdk-sessions/v1 n'a pas de corps : jeton public et SKU en paramètres de requête.

Nature des données envoyées à Mapbox (pour Securite-et-RGPD)

Identifiant : userId, un UUID aléatoire généré par le SDK et stable pour une installation (le même sur deux lancements Android). Ce n'est ni l'IDFA/GAID ni un identifiant Widoo. Selon la doc Mapbox, une réinstallation crée un nouveau MAU : l'identifiant ne survit pas à une désinstallation.
Position : aucune coordonnée. Le corps contient seulement l'état de la permission (locationEnabled, locationAuthorization, accuracyAuthorization).
Appareil et app : modèle d'appareil, version de l'OS, identifiant et version de l'app, versions des SDK.
Réseau : l'adresse IP de l'appareil, vue par Mapbox comme pour toute requête de tuiles. La politique de confidentialité de Mapbox dit l'effacer après 30 jours.
Fréquence observée : au lancement de l'app (une fois sur iOS, deux fois sur ce dev build Android), plus l'ouverture de session sdk-sessions/v1. Rien pendant l'usage de la carte.
Jeton : le jeton public pk. de l'app, en paramètre de requête, comme pour les tuiles.

Comparaison avec la documentation Mapbox

Tarification Maps SDK iOS : le SDK est « billed based on monthly active users » ; un utilisateur compte « as soon as they view a map » ; une réinstallation compte un MAU de plus, car « the SDK does not store personally identifying information ». C'est ce que porte appUserTurnstile.
Politique de confidentialité produit Mapbox : l'utilisateur peut « opt-out of telemetry sharing » ; parmi les identifiants reçus figurent un « randomly generated billing ID, session ID […] and IP address » (IP effacée après 30 jours) ; « Billing IDs are not transmitted with unrelated events » et font l'objet de « regular ID rotation and 1-way hashing ».
Côté SDK : Mapbox.setTelemetryEnabled(false) (rnmapbox) écrit MGLMapboxMetricsEnabled=false sur iOS et userTelemetryRequestState=false sur Android. Les deux corps relevés portent "enabled.telemetry": false, et aucun événement de télémétrie (map.load, location, map.click, map.dragend…) n'est parti pendant les déplacements ni les sélections.

Rien n'est à couper : le turnstile conditionne la facturation et ne se désactive pas. Le seul levier serait de ne plus utiliser le SDK Maps.

Chef de projet (point du 2026-10-13) : jalon v0.2 → v0.6. v0.2 est échu depuis le 07/10 et ses P0 sont livrés ; ce ticket de finition de la découverte ne conditionne pas la suite. v0.6 (25/11) regroupe la finition avant le lancement, pour laisser la place à v0.3 (fiche, orchestration, compte), dont aucun P0 n'a encore démarré. Priorité inchangée.

📋 MANAGER (2026-10-13) : fermé sans PR, sur décision de Paul du 2026-10-13, comme le prévoient les notes techniques.

Vérification : diagnostic de CODE du 2026-10-09 (résultat), au proxy de débogage sur le simulateur iPhone 17 Pro (iOS 26.4) et l'AVD Medium_Phone (API 34), dev builds de main 8d498e0, données fictives du seed. Le seul appel à events.mapbox.com est l'événement de facturation obligatoire appUserTurnstile (identifiant aléatoire du SDK, modèle, OS, état des permissions, aucune coordonnée), plus l'ouverture de session sdk-sessions/v1. La télémétrie est coupée ; aucun code à changer.
Critères cochés : les deux premiers tenus par ce diagnostic, le troisième sans objet (aucune PR).
Suites : inscription du flux dans Securite-et-RGPD par DESIGN → Décrire le flux de facturation Mapbox (appUserTurnstile) dans Securite-et-RGPD #368 (needs-design) ; en-têtes Sentry envoyés à Mapbox sur iOS → Restreindre tracePropagationTargets de Sentry à l'API #374.

Chef de projet (2026-10-13, suite) : jalon v0.6 retiré, ticket remis au backlog, priorité inchangée. Orientation retenue ce jour avec Ilan et Paul : séparer le périmètre du temps, avec des sprints d'une semaine (champ Sprint du Project, à partir du 19/10). Un ticket de finition découvert en cours de route va au backlog et entre dans un sprint selon sa priorité. Le placer en v0.6 ce matin faisait déborder son epic sur une date sans rapport avec le travail.

Navigation Menu

Repository navigation

Identifier les appels à events.mapbox.com restant malgré la télémétrie coupée #173

Contexte

Comportement attendu

Critères d'acceptation

Notes techniques

Résultat — appels à `events.mapbox.com` : événements de facturation, pas de télémétrie

Méthode

Relevé anonymisé

Nature des données envoyées à Mapbox (pour Securite-et-RGPD)

Comparaison avec la documentation Mapbox

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Identifier les appels à events.mapbox.com restant malgré la télémétrie coupée #173

Description

Contexte

Comportement attendu

Critères d'acceptation

Notes techniques

Activity

PaulThiberville commented on Oct 9, 2026

PaulThiberville commented on Oct 9, 2026

Résultat — appels à events.mapbox.com : événements de facturation, pas de télémétrie

Méthode

Relevé anonymisé

Nature des données envoyées à Mapbox (pour Securite-et-RGPD)

Comparaison avec la documentation Mapbox

IlanAMG commented on Oct 13, 2026

PaulThiberville commented on Oct 13, 2026

IlanAMG commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Résultat — appels à `events.mapbox.com` : événements de facturation, pas de télémétrie