The Doppler Quarterly (FRANÇAIS) Été 2018 | Page 12

applications cloud natives pour aider les clients de
l’organisation à moderniser leurs processus.
Phase préparatoire
CTP a combiné une conception d'expérience de
niveau agence à des règles de bonne pratique
d'adoption afi n d’imaginer et développer une solu-
tion offrant aux clients une expérience exception-
nelle, ainsi qu'un déploiement du cloud qui optimise
à la fois les performances et les coûts.
Dans un premier temps, CTP a dirigé un atelier de
découverte de conception d’expérience (XD) avec
des acteurs clé (notamment des membres de la
direction possédant une riche expérience secto-
rielle), afi n de défi nir des objectifs clés et recenser
les défi s auxquels l’entreprise de médias était
confrontée. CTP a identifi é quelques acteurs incon-
tournables (« power players », vétérans, fi gures de
proue du secteur et directeurs des programmes)
animés par des approches et possédant des expé-
riences diversifi ées en matière d’analytique et de
technologie. Nous avons organisé des entretiens et
des tests d'utilisateur en impliquant ces grands
acteurs et en cherchant à mieux comprendre leur
existence au quotidien. Leur dénominateur com-
mun, c'est qu'ils avaient tendance à traiter les don-
nées de manière incohérente et à les considérer
généralement comme un outil de confi rmation
secondaire de leurs hypothèses. Il leur manquait un
moyen de visualiser aisément les données relatives
à la diffusion d'une chanson par rapport à d'autres
indicateurs
clés
et
profi ls
d'audience
interdépendants.
CTP est ensuite passé à la phase de prototypage.
L’équipe a recueilli des lignes de données par l'inter-
médiaire de pages Google Sheets et de fi chiers JSON
afi n de concevoir un modèle de visualisation de la
trajectoire d'un titre. Nos experts ont exploré une
diversité d’options de visualisation des données et
mis au point une interface utilisateur basée sur des
cartes géographiques, des histogrammes et des
courbes de tendance. Puis, un fl ux de travaux évolué
a été créé afi n de mesurer les cycles de vie des
artistes et des chansons par voie comparative.
CTP a découvert que le plus important défi était
celui du manque de « données propres », dans la
mesure où leur processus de génération était inégal.
Les frontières des marchés et les fenêtres tempo-
10 | THE DOPPLER | ÉTÉ 2018
relles de vente, par exemple, se caractérisaient par
un manque de cohérence entre les canaux de vente
au détail, de diffusion et de digitalisation. Pour
extrapoler les connaissances approfondies à partir
de plateformes multiples, CTP a envisagé différentes
options visant à réarchitecturer les stratégies de
données existantes. Nos ingénieurs ont aidé le client
à dimensionner un « pool » de données préfi gurant
l'élaboration d’indicateurs standard sur lesquels
leurs équipes pourraient se reposer par la suite.
Parallèlement à cela, en exploitant les feuilles de
calcul Excel existantes pour réinventer l'expérience
utilisateur de l'application, CTP a mis en place un
mécanisme secondaire de validation des données
confi é aux vétérans de l’industrie. L'objectif de cette
confi guration était de permettre une familiarisation
avec les modèles de données, réduire la complexité
et cultiver l’intelligence au fi l du temps. Sur la base
des enseignements retirés, l’équipe a réduit et sim-
plifi é l’interface utilisateur de manière à fournir les
bonnes données au bon moment et à la bonne per-
sonne, dans le format et sur le support ou le canal
approprié.
L’application Music Analytics Dashboard s'appuie
sur une architecture classique à trois niveaux com-
prenant une couche de présentation, une couche
métier et une couche de données. La couche de pré-
sentation est une application AWS Elastic Beanstalk
exécutant un module node.js et bâtie autour de
composants d'architecture React. La couche métier,
conforme à la tendance d’architecture sans serveur
a été développée via la passerelle d’API Amazon et
AWS Lambda, plus des composants d'autorisation
personnalisés et une intégration à Active Directory
Azure via son interface OAuth. La couche de don-
nées est une instance AWS RDS à zone multi-dispo-
nibilité utilisant le moteur PostgreSQL en raison de
la nature relationnelle des données.
Le pipeline ETL sans serveur MapReduce a été éla-
boré à partir de composants sans serveur plutôt que
Hadoop. Ses principales caractéristiques sont : l'abs-
traction de l'ingestion de données connectée aux
services FTP, S3, Google Cloud Storage, les bases de
données SQL, les services SOAP, les partages réseau
Windows et sources de données HTTP, les modules
node.js pour toutes les fonctions ETL, ainsi que le
streaming asymétrique entre les différents proto-
coles de données.