"67% des consommateurs utilisent à la fois leur ordinateur, leur tablette et leur smartphone pour faire un achat. Et 98% d’entre eux passent d’un support à un autre dans la même journée" (source : Skeelbox). Cette tendance souligne l'importance de s'adapter à ces usages en adoptant une stratégie cross-canal. Mais qu’est-ce qui se cache vraiment derrière ce terme? Quels sont les enjeux technologiques liés à cette stratégie? Comment la mettre en oeuvre chez moi, et avec quelles solutions pour stocker mes données. C’est ce que nous allons présenter dans cet article, premier d’une série concernant les différents use-cases liés aux nouvelles architectures de traitement et de persistance de la donnée.
Le terme cross-canal regroupe les techniques de vente ayant pour but d’utiliser tous les canaux de distribution disponibles de façon transverse et sans couture, et de tirer parti du meilleur de chaque pour offrir un parcours optimal à l'utilisateur. Dans notre cas, nous nous intéresserons uniquement au canal web et non au canaux physiques. En effet, la problématique de récupération des données sur les canaux digitaux "hybrides" (magasin connecté, produit connecté, vitrine connectée...) mériterait en effet un article à part entière.
Le périphérique que nous utilisons est choisi à partir du contexte (lieu dans lequel nous nous trouvons, temps dont nous disposons, etc) et il convient donc d'exploiter les spécificités de chaque canal pour offrir la meilleur expérience client possible. Il est par exemple pratique de parcourir un catalogue produits sur son téléphone mais un paiement par carte bancaire ne sera pas forcément adapté si l'on se trouve dans la rue ou le métro, d'où la possibilité d'enregistrer ses achats dans des listes ou des paniers "longue durée".
L'infographie suivante illustre, pour chaque "device", le pourcentage d'achats qui y ont été initiés, et le parcours qu'a ensuite suivi l'utilisateur.
Afin de donner à notre utilisateur une impression de fluidité dans son parcours, il est donc indispensable de synchroniser les différentes informations d'un canal à l'autre.
Concrètement, cela peut se traduire par les cas suivants :
Ce type d’utilisation devient de plus en plus courante chez l’utilisateur, qui prend l’habitude de voir ses choix, effectués sur un canal donné, mémorisés et disponibles immédiatement sur les autres.
Outre les problématiques d’identification unique de notre client, indispensable pour faire le lien entre nos canaux, et de récupération des données utiles (avantages fidélité du client, adresse préférée de livraison, historique...), ce cas d’utilisation pose de gros enjeux au niveau persistance de nos données. En effet, il nous faut maintenir une cohérence globale de notre contexte, le tout en garantissant des performances compatibles avec une bonne expérience utilisateur.
Face à ces besoins, la solution retenue devra donc répondre aux enjeux techniques suivants :
Au vu des enjeux technologiques que représente ce cas d'utilisation, les bases de données relationnelles ne semblent pas répondre à toutes les exigences (ou du moins pas forcément à des coûts raisonnables). En effet, même si certains SGBDR peuvent fournir des latences très faibles, ces solutions n’offrent pas de scalabilité horizontale (du moins pas nativement) nécessaire pour pouvoir répondre à une montée en charge de l’application ou a des pics d’activité saisonniers. La modélisation relationnelle peut également s’avérer être un point bloquant lorsqu’il s’agit de réunir des données hétérogènes provenant de plusieurs applications différentes (tunnel de vente online, application en magasin...), là ou une base NoSQL permet de gérer des documents aux formats différents (panier non terminé, profil à moitié rempli...). La base de donnée retenue devra donc faire la différence sur les aspects haute disponibilité, élasticité et facilité de prise en main, les autres conditions pouvant être remplies par la plupart des SGBDR.
Nous vous proposons donc 3 solutions NoSQL, Aerospike, Cassandra et Couchbase, connues pour leurs performances élevées, notamment en ce qui concerne la latence en lecture. Cette liste ne se veut pas exhaustive, d'autres solutions pourraient être retenues dans certains cas particuliers, il s'agit là de bases sur lesquelles nous avons des retours d'expérience et pour lesquelles nous sommes convaincus qu'elles peuvent répondre au besoin.
Ces 3 solutions sont en effet réputées pour leurs très bonnes performances en lecture/écriture. Elles disposent toutes d'un mécanisme de réplication de données pour assurer de la haute disponibilité, y compris une replication cross-datacenter permettant à la fois de se prémunir de pertes de données lors d'un sinistre mais également de s'assurer que les données seront localisées au plus près de l'utilisateur final. Enfin elles proposent toutes un mécanisme d'ajout / suppression de machines dans le cluster, à chaud, permettant aisément de dimensionner l'infrastructure en fonction de la charge.
Le plus de détails) est disponible pour les trois.
Du point du vue durabilité, Aerospike offre également le choix de persister les données uniquement en mémoire, et non sur disque, mais cette option ne concerne pas notre cas d'utilisation car nous cherchons bien à utiliser ces solutions en tant que primary datastore et non comme cache uniquement.
Nous disposons donc de 3 bases répondant très bien à nos contraintes de performance et de haute disponibilité. Couchbase et Aerospike apparaissent comme les plus simples à utiliser et administrer, et l'aspect schema-less permet d'intégrer des formats de donnée hétérogènes facilement. L'association Couchbase Server - Couchbase Lite pourrait se révéler déterminante dans le choix de la solution au vu de notre cas d'utilisation. Le fonctionnement de Cassandra est peut être moins trivial à appréhender (on pense notamment à des concepts comme la Tunable Consistency) mais c'est une base qui peut s'avérer un bon choix dans des cas d'écritures massives et qui a fait ses preuves chez beaucoup de clients.
La stratégie cross-canal présentée ci-dessus est juste une première étape. Chez OCTO, nous sommes convaincus que derrière cette problématique de stockage/restitution de la donnée se cache un enjeu plus important : celui de l'architecture de nos données . En effet, stocker dans un endroit unique les transactions et paniers d’utilisateurs issus d'un site web, d’une tablette, d’un téléphone ou d'un magasin physique est déjà une étape importante mais le vrai objectif pour nous est de décloisonner le SI pour rendre ces données accessibles en temps réel aux autres briques métier. Et, pour que cela devienne vraiment pertinent, un des challenges est de collecter le maximum de données et d'essayer de les traiter au fil de l'eau, comme nous le présentions lors de notre petit déjeuner sur les Nouvelles Architectures de Données, en structurant notre SI autour d'évènements. Toute action de notre utilisateur, que ce soit une mise à jour panier, un clic, une modification de son profil… devient donc un évènement, accessible par nos différentes applications. Cette nouvelle manière d'aborder vos data pourront ainsi vous ouvrir de nouveaux cas d'utilisation comme par exemple la vision 360 d'un client qui est mise à jour dès qu'il déclare un sinistre, la détection d'abandon de panier dans le eCommerce.
Et en allant un peu plus loin, on peut aussi se dire que ces évènements ne devront pas être limités aux canaux digitaux mais permettront également d'intégrer les canaux physiques : consultation des stocks en temps réel du magasin physique depuis mon smartphone, achat depuis le magasin physique qui déclenche un bon de reduction pour un prochain achat que je pourrais aussi utiliser sur mon téléphone... Il faudra alors évaluer la capacité des solutions citées dans cet article à intégrer ces nouveaux besoins, quitte à utiliser une autre base pour stocker et traiter tous ces évènements, la persistance polyglotte étant de plus en plus courante dans les SI.
https://ssl.gstatic.com/think/docs/the-new-multi-screen-world-study_research-studies.pdf
http://www.nngroup.com/articles/response-times-3-important-limits/
http://wiki.apache.org/cassandra/ArchitectureOverview#Consistency
http://www.odbms.org/wp-content/uploads/2013/11/NoSQL-Failover.pdf
http://martinfowler.com/bliki/PolyglotPersistence.html