18 avril 2019 : comment garantir la sécurité des données des clients dans une campagne omnicanale
Cette contribution est issue de celle postée par David Baldaro le 10 avril 2019 sur le blog (en) de notre fournisseur XMPie
Je me souviens d'avoir vu pour la première fois une campagne omnicanale et un site éphémère personnalisé il y a 15 ans, lorsque j'ai découvert XMPie. Bien sûr, l'élément sousjacent de tous les sites éphémères personnalisés est l'URL personnalisée (PURL) ; c'est même la clé permettant d'identifier qui est le destinataire visitant le site.
A cette époque, les marketeurs aimaient bien les PURL du genre www.societe.fr/jean.dupont. Cette tradition a duré un bon moment. Invariablement, le nom du client figurait dans l'URL parce qu'il donnait l'impression rassurante à l'internaute que cette URL était la sienne ; et c'est exactement ce que voulaient les marketeurs, qui espéraient que le client clique !
Mais comme l'URL était la clé pour accéder aux pages personnalisées, cela pouvait être problématique si elle contenait elle-même des données personnelles. Vous n'aviez pas besoin d'être un hackeur très inspiré pour pouvoir deviner facilement l'URL de votre voisine ! Néanmoins, jusqu'à il y a quelques années, la sécurité des données n'était pas vraiment le centre d'intérêt de beaucoup de gens ; disons même que ce n'était pas du tout la préoccupation de la plupart des prestataires de service qui déroulaient des campagnes pour le compte de leurs clients.
Evidemment, on ne peut plus dire la même chose aujourd'hui. Nous vivons désormais dans une ère post-apocalyptique – pardon... "post RGPD" – dans laquelle la sécurité des données privées est devenue primordiale dans toute activité en ligne. Étrange paradoxe : vous devez respecter la vie privée de vos clients finaux et protéger leurs données ; mais dans le même temps, vous devez aussi créer des campagnes très personnalisées pour les annonceurs. Comment donc réussir à concilier les deux aspects ??
La solution XMPie Circle et les campagnes omnicanales de XMPie proposent deux fonctionnalités qui, toutes les deux, répondent à cette problématique et s'assurent que les PURLs sont plus difficiles à deviner et son verrouillées. Ceci découle des nouvelles versions mises sur le marché par XMPie pour se conformer au RGPD.
Secure ID
SecureID est un mécanisme optionnel intégré, permettant d'empêcher de deviner les PURLs. Désormais, lorsque vous envoyez les données dans une campagne utilisant des PURLs, vous aurez deux choix :
- Utiliser un (ou deux) champs de votre base de données comme clé pour vos destinataires
- Demander à votre solution XMPie de créer automatiquement un identifiant unique pour chaque destinataire de la base
La seconde option va générer un identifiant sur 32 caractères pour chaque destinataire. Elle vérifie aussi la présence d'éventuels doublons et insère ces données directement dans votre base, sans que vous ayez quoi que ce soit à faire manuellement. Les idenfiants sont générés de manière aléatoire (un même destinataire présent dans deux campagnes aura deux identifiants distincts). Le point important à retenir est que les identifiants sont totalement dépersonnifiés – ils ne font aucunement mention à leur nom, leur email – de ce fait, il est virtuellement impossible de deviner l'identifiant de quelqu'un d'autre !
À l'opposé, il est vrai que l'URL devient franchement illisible pour un être humain : elle est moins attirante et aura du mal à trouver sa place dans un document imprimé ; mais nous ne pouvons malheureusement pas avoir le beurre et l'argent du beurre. Dans tous les cas, c'est là où le QR Code va montrer tous ses avantages : il va permettre de "cacher" une URL longue et indigeste derrière un simple flashage.
Il existe aussi des situations où vous n'aurez pas besoin d'un identifiant à 32 caractère ; vous pouvez alors générer vos propres identifiants lorsque vous importerez vos données. Comme toujours, XMPie ne vous empêchera pas de le faire : la solution vous offrira plusieurs approches et c'est vous qui restez décideur en dernier ressort.
Secure URL
Que faire si l'annonceur exige un niveau supplémentaire de sécurité et de protection ? Par exmple, un QR code imprimé sur un document marketing amènera l'utilisateur à une PURL impossible à deviner, mais n'importe qui - y compris un "méchant" - peut flasher ce QR Code, pour peu qu'il y ait physiquement accès.
Dans cette situation, vous voulez protéger les données sur la page avec un niveau de verrouillage supplémentaire ; l'utilisateur devrait devoir s'authentifier avant que ses données personnelles ne s'affichent ; c'est ici que notre seconde fonctionnalité, Secure URL (parfois aussi appelé SecURL) va entrer en jeu.
SecURL est apparu dans Circle en décembre 2018, en même temps que le support de HTTPS, car les deux aspects sont très liés. En effet, ça ne sert à rien de mettre un verrou à la porte si un "méchant" peut le contourner pour entrer dans la maison ! SecURL est implémenté dans Circle au niveau de chaque projet et fonctionne parfaitement, à la fois dans les sites hébergés sur votre serveur XMPie ou ceux hébergés ailleurs - par exemple chez l'annonceur, hors de contrôle du prestataire XMPie.
Une fois encore, XMPie a imaginé cette fonctionnalité de la manière la plus flexible possible : vous avez la possibilité de mettre en place un verrou à base de mot de passe, ou de nom d'utilisateur et de mot de passe. Parce que dans de nombreuses situation, le SecureID peut déjà agir comme une sorte de nom d'utilisateur, il n'est donc pas toujours nécessaire d'en rajouter un second. Dans la plupart des cas, vous préférez vous contenter de demander aux utilisateurs de confirmer leur identité par la saisie d'un simple mot de passe. Mais Circle vous laisse le choix, et c'est bien vous qui décidez !
Concernant les mots de passe, la complexité est aussi de votre choix. XMPie autorise les mots de passe encryptés ou en clair ; même si les mots de passe en clair ne sont pas acceptés dans de nombreuses situations, il se peut qu'ils fournissent quand-même un niveau de sécurité suffisant de votre point de vue. Par exemple, dans une campagne d'inscription à un événement, vous allez envoyer des invitations à des destinataires déjà connus, listés dans votre base de données. Sur leur URL personnalisée, vous voulez qu'ils confirment leurs coordonnées et qu'ils ajoutent leur numéro de plaque d'immatriculation et leurs préférences alimentaires. Maintenant, même si SecureID offre un premier niveau de sécurité, vous voulez aussi vous assurer que les utilisateurs soit rassurés vis-à-vis de la protection de leurs données personnelles. C'est ici que SecURL va jouer. Chaque utilisateur va devoir confirmer son identité en saisisant son code postal ou son numéro de compte, avant de pouvoir aller plus loin. Ici, vous utilisez une donnée "connue" comme mot de passe ; c'est cohérent, car c'est une campagne indépendante, dans laquelle de nouveaux destinataires ne peuvent s'ajouter eux-mêmes. Peut-être avez aussi aussi déjà dans votre base de données une colonne contenant un mot de passe encrypté ; auquel cas vous pourrez l'utiliser dans votre processus SecURL.
À l'inverse, dans une campagne où de nouveaux destinataires peuvent s'ajouter eux-mêmes, ils pourront saisir leur mot de passe (qui sera alors encrypté et stocké dans la base de données), en regard de leur identifiant, généré aléatoirement par XMPie. Toute tentative ultérieure d'accéder à leur URL nécessitera alors la validation de leur mot de passe.
Ces fonctionnalités sont abordées encore plus en détail dans le Webinaire (en) présenté le 12 février 2019 par David Baldaro. Il y évoque l'utilisation de ces fonctionnalités XMPie de sécurisation avancées dans des applications transpromotionnelles et des applications d'entreprise.
Une démo ?