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.