Ludovic Lacroix est Product Owner au Figaro depuis cinq ans, en charge de la fidélisation au sein du pôle lecteurs.
Depuis plusieurs années, Le Figaro est confronté à la problématique du partage de compte par ses utilisateurs abonnés.
Il faut avoir à l’esprit que partager les services que l’on aime est un réflexe normal – et est même un signe positif sur la qualité de notre service. Nous avons voulu limiter cet usage sans contraindre nos abonnés à effectuer des vérifications de compte fastidieuses et qui seraient contre productives.
Pour cela, nous avons suivi un plan en deux étapes, afin d’inciter les abonnés à partager leur abonnement plutôt que leur compte personnel.
1ère étape : proposer une mécanique de partage différente
La première chose que nous avons faite était donc de proposer une mécanique de partage différente. Nous avons commencé par mettre en place un “Pack famille” sur les formules d’abonnement numérique et papier les plus valorisées, à savoir nos formules “Premium” et “Premium+”. Un abonné à l’une de ces deux formules a la possibilité de lier de 2 à 4 comptes utilisateurs à son abonnement. Les abonnés au quotidien papier disposent également de cette fonctionnalité.
2ème étape : limiter les sessions
Puis, nous avons pu passer à la phase de limitation des sessions. Nous avons mis en place un système empêchant la consultation simultanée des articles avec un même compte abonné sur différents navigateurs. Un seul internaute est donc autorisé à consulter les articles avec un compte (un couple ID/mot de passe) donné. Si un second internaute se connecte avec les mêmes identifiants et consulte un article en même temps, le premier internaute est bloqué par une modale lui proposant soit de passer à une formule d’abonnement supérieure, soit d’inscrire ses proches dans son Pack Famille avec des accès dédiés.
L’internaute invité dans un Pack Famille peut alors avoir son propre compte utilisateur. Il bénéficie des mêmes accès que son “parrain” en fonction de sa formule d’abonnement (lecture des articles, newsletters, commentaires…). Les commentaires étant désormais un avantage réservé aux abonnés, nous avions également à cœur de permettre à chaque internaute d’exprimer son opinion avec son propre pseudonyme, et non avec celui qu’il emprunte.
S’adapter aux usages pour faciliter la transition
Le système de limitation de session a été pensé en partant des cas utilisateurs pour proposer une expérience adaptée et non bloquante. L’expérience doit être suffisamment contraignante pour faire prendre conscience que des solutions existent pour remplacer le partage de mots de passe.
Nous avons donc fait en sorte d’interrompre la lecture simultanée des articles sur le site en diffusant une fenêtre modale simple et compréhensible afin d’informer les utilisateurs et leur proposer des solutions adaptées.
Les UX designers et les product owners ont travaillé à partir de prototypes très imagés sur les scénarios possibles pour dresser les cas utilisateurs les plus communs. Une fois les scénarios choisis, ils ont ensuite travaillé sur l’expérience utilisateur et les messages à faire passer en collaboration avec les responsables du service client, toujours dans l’optique de ne pas donner une impression restrictive trop forte. L’expérience devait rester compréhensible facilement sans pour autant donner une impression négative à l’utilisateur. Un travail important a également été fait sur les textes présentés à l’utilisateur, notamment au niveau des champs lexicaux (ici, en se concentrant sur celui de la famille), pour rester compréhensibles pour l’internaute, cohérents dans tous les espaces et en phase avec nos axes marketing.
A la suite de la mise en place du système de limitation de session, nous n’avons eu que très peu de retours négatifs de la part de nos abonnés. Le système nous a permis de mesurer plus finement les comptes les plus partagés, et notamment d’identifier les comptes utilisés massivement par des employés d’une même entreprise. Ces prospect se voient ensuite proposer des offres B2B.
Les premiers résultats étant positifs, nous souhaitons à présent étendre ce système à nos applications et à nos sous-domaines tout en travaillant la fluidité de l’expérience client.
Le mot de la tech
Nous avons développé ce service de limitation de session avec le product owner en nous fixant deux objectifs majeurs :
- la simplicité de l’API : le service doit être très simple à implémenter pour les front- end et les applications mobiles.
- la résilience du service : il doit pouvoir être scalable, tolérant aux pannes, et ne surtout pas pénaliser nos abonnés.
Avec ces objectifs en tête, nous avons développé une API Node.JS qui ne compte que trois endpoints REST permettant de répondre à tous les scénarios, et tiré profit au maximum de Kubernetes, de services managés dans le Cloud pour que cette API soit la plus résiliente possible avec une forte tolérance aux pannes et une résistance à l’augmentation de charge. De plus, notre solution permet de gérer les tentatives de connexion simultanées des abonnés, avec un système quasi-temps réel, en toute fluidité pour ces utilisateurs.
Plusieurs mois après le déploiement du service, et malgré l’augmentation croissante du nombre d’abonnés, aucun incident n’est à déplorer.
