Consentements sur mobile et apps : 4 challenges

Si tous les éditeurs de sites et d’apps rêvent d’une gestion des consentements cross-device, la pratique complique sérieusement la donne… Explications.

L’expression « mobile first » a beau être devenue très tendance, dans la pratique, le mobile et les apps passent encore trop souvent après le web. Y compris pour la gestion des consentements dans le sillage du RGPD (Règlement Général sur la Protection des Données). Sur ce sujet, le site web cristallise l’attention et les énergies alors que l’enjeu de la conformité au RGPD est bien entendu tout aussi sensible avec les apps mobiles. Tout aussi sensible, mais encore plus technique du fait de la nature même du mobile. Retour sur 4 challenges clés.

1) Gérer la connexion intermittente

C’est la principale difficulté sur mobile : penser la collecte des consentements sans supposer qu’une connexion sera toujours active pour nourrir un dialogue client-serveur. Seule solution si une app est exploitée hors connexion : tirer parti de l’un des grands avantages d’une app mobile, à savoir sa capacité à stocker de l’information localement.

Concrètement, si le smartphone est offline, toutes les actions enregistrées sur l’app sont stockées. Une fois la connexion rétablie, selon le statut identifié du consentement (acceptation totale, partielle ou rejet), les données sont envoyées à la CMP (Consent Management Platform), en partie ou dans leur totalité, ou bien effacées en cas de refus de la collecte. Dans tous les cas, l’app mobile doit intégrer ce mécanisme de « bufferisation » des données personnelles en mode offline.

2) Penser la demande de consentement pour l’UX du device

La bonne gestion des consentements sur mobile et sur les apps ne se résume pas à un enjeu technique. Il s’agit aussi de la penser pour ne pas compromettre l’expérience utilisateur. Hors de question de se contenter d’afficher les pop-in exploitées sur desktop, même en ayant pris soin de leur caractère responsive. Du mobile au desktop, la tolérance à l’obstruction de l’écran (le fait que la pop-in masque plus ou moins le contenu) et les modalités de validation du consentement diffèrent suffisamment pour justifier une UX spécifique. Le design des boutons de validation et refus mérite à lui seul une approche différenciée entre mobile et desktop.

Dans le cadre d’une app, c’est souvent un écran dédié à cette collecte qui s’impose. Avec une question clé : à quel moment afficher cet écran ? La réponse appartient à chaque éditeur, car elle dépend intimement de la nature de l’app. À quel public s’adresse-t-elle ? Nécessite-t-elle des instructions pour être prise en main ? Par exemple, il ne semble pas forcément opportun d’afficher cet écran avant même d’avoir délivré les informations pratiques essentielles pour bien utiliser l’app. Une phase d’A/B Testing pourra être mise à profit afin d’identifier un cheminement qui soigne la rétention.

3) Collecter un consentement spécifique

Évidemment, chaque éditeur de site ou d’app rêve de pouvoir déployer une mécanique de consentement cross-device. Avec un objectif évident : propager le statut d’un consentement collecté dans un navigateur desktop jusqu’à une app mobile pour éviter de questionner à maintes reprises l’utilisateur. Une louable intention qui pour l’heure demeure hors de portée technique. Même au sein d’un device, les « ruptures » de consentement sont inévitables : un utilisateur qui a donné son accord dans un navigateur pour un site web d’un éditeur se verra contraint de le redonner s’il utilise ensuite une app de ce même éditeur sur son smartphone.

Question légitime : et si l’utilisateur se logue de part et d’autre (sur le site et sur l’app) ? Oui, dans ce cas de figure, le consentement étant associé à un profil logué, il peut être « récupéré » d’un site à une app et vice versa. Mais à une condition qui n’a, cette fois, plus rien de technique : le consentement donné sur un site peut être valide pour une app seulement si les mêmes services sont activés sur l’un et l’autre…

Rappelons que, selon le RGPD, un consentement pour être licite et loyal doit être spécifique. Dans la pratique, d’une app à un site, les services mis en œuvre – donc les données envoyées aux partenaires – diffèrent. Les adservers par exemple sont rarement identiques entre mobile et desktop. De même pour les solutions d’A/B Testing.

En résumé, pour des raisons techniques, mais aussi juridiques, la collecte du consentement doit être gérée pour l’heure de manière spécifique selon les devices (desktop, mobile) et contextes (site, app).

4) Historiser les consentements

Autre principe clé du RGPD à garder à l’esprit : « l’accountability ». En clair, chaque éditeur de site ou app doit être en mesure non seulement de collecter les consentements de manière conforme au RGPD, mais aussi de prouver qu’il opère ainsi. D’où l’importance d’historiser pour l’ensemble des devices et contextes les statuts des consentements et les activations qui ont suivi. C’est d’ailleurs l’une des caractéristiques clés de la CMP de Commanders Act : assurer cette historisation des consentements collectés sur l’ensemble des devices.