M6: du datalake à la GenAI, la Data comme moteur de l’innovation

Dans un contexte de transformation organisationnelle, le groupe M6 a entrepris la création d’un datalake. Basé sur une infrastructure AWS, ce projet de datalake visait à répondre aux besoins opérationnels immédiats de collecte et de traitement des données, tout en posant les bases d’une future stratégie d’innovation technologique et d’exploration des cas d’usage liés à l’intelligence artificielle.

Depuis 4 ans Devoteam accompagne M6 dans cette démarche. Cet article retrace l’histoire de sa création, les choix technologiques qui ont guidé son évolution, et le développement progressif de ses différentes composantes.

Nikola Pekez, manager du Datalake (M6), et Gauthier Vuong, Product Owner (M6), répondent à nos questions sur ce projet mené en collaboration avec les équipes Devoteam.

Contexte

Dans quel contexte a commencé le projet de Datalake ?

La création du datalake s’inscrit dans un contexte de transformation au sein du groupe M6. Initialement portée par la business unit 6play (aujourd’hui M6+), cette initiative a émergé au transfert d’une partie des compétences techniques et des savoir-faire data vers une nouvelle société, Bedrock Streaming, dédiée au développement d’une plateforme technologique de VOD. Cette évolution a conduit à une séparation des roadmaps et des objectifs, et a mis en lumière de nombreux besoins data qui n’étaient plus traités par cette nouvelle organisation.

Face aux besoins des équipes business et techniques, notamment des data analysts et opérateurs confrontés à des limitations dans le traitement des données, la verticale digitale du groupe a identifié la nécessité de reprendre son autonomie sur les sujets data.

La construction du datalake était une opportunité d’innovation et d’expérimentation de nouvelles technologies, et cette démarche a marqué le début de la collaboration avec les équipes de Devoteam. Le premier objectif de la création du datalake était de développer une infrastructure data plus performante et adaptée aux besoins spécifiques de M6+.

Pourquoi avoir choisi AWS comme stack technique ?

Le choix d’AWS comme infrastructure s’est naturellement imposé : nous avions déjà une petite expertise dans l’écosystème AWS, et la stack Data de Bedrock Streaming était également sur AWS. Notre objectif était de capitaliser sur les compétences existantes et de privilégier une solution simple et compétitive dans un environnement technologique familier.

Au-delà des aspects techniques, il y avait aussi une dimension humaine. Construire le datalake depuis la base, en évitant les solutions clés en main, répondait à l’objectif d’attirer des talents et de leur proposer un terrain de jeu stimulant. Cette approche nous a permis de développer nos compétences sur des briques technologiques fondamentales, que nous n’aurions probablement pas acquises avec des solutions prépackagées.

Challenge

Quels étaient les objectifs et ambitions du POC ?

Nous voulions explorer la faisabilité d’une approche itérative. L’idée était de de grandir progressivement, tout en répondant aux cas d’usage les plus urgents comme la récupération et le traitement de données pour du dashboarding. Notre objectif était de tester les technologies, leur adéquation aux besoins de nos équipes, et de proposer des innovations.

Comment avez-vous commencé la construction du Datalake ?

Nous avons développé les premières briques du datalake à deux, en testant différentes options de stockage et de construction de pipeline. Cette approche a permis de réduire le time to market de ces fonctionnalités.

Pour répondre aux besoins des équipes opérationnelles, la direction a validé le passage du POC au MVP. Cela s’est traduit par plus de moyens, et un accompagnement externe avec l’objectif de construire un datalake dans les règles de l’art.

Solution

Comment avez-vous organisé l’équipe entre M6 et Devoteam ?

Au démarrage du projet, la composition de l’équipe était la suivante :

• Nikola : référent technique
• Gauthier : product owner
• Consultants Devoteam : un architecte plateforme senior qui a structuré la V0 de la data platform, et un data engineer

Le datalake a été construit avec une approche bottom-up, à partir des cas d’usage prioritaires, comme le « carve out », c’est-à-dire la récupération de certains périmètres data auparavant pris en charge par Bedrock Streaming. En parallèle, M6 a déployé Looker comme outil de data visualisation groupe, nécessitant l’alimentation de différentes sources de données.

Nous avons commencé par la création de pipelines de données permettant de répliquer la donnée depuis l’environnement de Bedrock. Nous avions peu d’expérience, le datalake étant un sujet nouveau. On s’est retroussé les manches et on a travaillé sur la création de ces pipelines, faisant ainsi progressivement grandir la taille de notre propre périmètre data. 

L’objectif était de montrer rapidement la valeur ajoutée : démontrer la capacité du datalake à collecter, intégrer et distribuer des données, offrant ainsi un support aux équipes de data analysts qui étaient jusqu’alors en difficulté.

Quelle a été la plus-value de l’équipe Devoteam ?

Premièrement, l’équipe nous a aidé à sélectionner les bons services AWS et à les orchestrer pour construire le datalake. Devoteam nous a aussi apporté des compétences en DevOps et CI/CD que nous n’avions pas, et plus globalement, son expérience du Cloud et sa maîtrise des bonnes pratiques.

Cela nous a permis de construire ensemble une vision, l’objectif vers lequel nous allions tendre, à un moment où nous avions plutôt tendance à travailler au jour le jour. Construire un datalake, c’était un peu intimidant, ça semblait être un chantier gigantesque. L’équipe Devoteam, par son expérience, a pu nous montrer comment procéder par étapes.

Nous devions aussi gérer notre propre landing zone AWS (gestion du réseau des comptes, des utilisateurs, etc), et l’équipe Devoteam nous a accompagnés sur sa mise en place et son exploitation, sujets qui non seulement représentaient une charge importante, mais sur lequel nous avions peu de connaissances.

Quels étaient les premiers cas d’usage adressés ? 

Les data analysts utilisaient principalement du SQL pour leurs requêtes. Donc l’un des premiers besoins du Datalake était de permettre la collecte et le stockage des données, pour ensuite les requêter avec du SQL via Amazon Athena.

Les équipes ont ensuite exprimé le besoin de créer de nouvelles tables pour effectuer des calculs complémentaires. Nous avons donc commencé à construire des pipelines de transformation de données, en itérant sur l’architecture du datalake. Mais au fur et à mesure que les demandes se multipliaient, nous nous sommes rendu compte qu’il était nécessaire de faire évoluer notre plateforme data pour effectuer ce passage à l’échelle dans de bonnes conditions.

Comment avez-vous fait évoluer votre plateforme – quels choix et pourquoi ?

Au début de la construction du datalake, le contexte technologique était très différent d’aujourd’hui. Des solutions comme Databricks, Snowflake ou DBT existaient déjà, mais n’avaient pas encore atteint le niveau de maturité qu’elles ont aujourd’hui.

Nous avons donc opté pour une approche native AWS. L’idée était d’organiser nous-même les services et leurs interactions pour développer les pipelines de données. Le choix des services AWS n’a toutefois pas été un long fleuve tranquille, cela s’est fait au gré d’itérations. Là où notre première architecture s’est focalisée sur des technologies d’infrastructure bas niveau (Airflow sur Kubernetes, EMR avec EC2, …), nous nous sommes de plus en plus dirigés vers des services managés et serverless proposés par AWS (Amazon Managed Workflows for Apache Airflow (MWAA), EMR Serverless, …).

Le but de cette démarche est de faire mieux, avec moins. Plutôt que de passer du temps et de l’énergie à maintenir des infrastructures complexes, nous préférons nous focaliser sur notre cœur de métier : mettre à disposition de nos utilisateurs à l’aide du serverless une plateforme data robuste pour répondre rapidement à leurs cas d’usage parfois complexes.

Devoteam nous a beaucoup aidé à nous forger des convictions sur ces sujets technologiques hautement stratégiques, nous aidant à peser le pour et le contre, entre d’un côté davantage de flexibilité en manageant notre propre infrastructure, et de l’autre un meilleur time-to-market et un Total Cost of Ownership plus faible grâce au serverless.

Quelles sont les missions du Datalake ?

Les missions du datalake s’orientent autour de 3 piliers principaux : 

• La data ingénierie : permettre la collecte, la transformation et la mise à disposition de données.
• Etre un facilitateur opérationnel et business. Disposer de la donnée, la transformer, l’utiliser dans des dashboards, c’est une chose, mais nous voulons aller plus loin. Nous voulons aussi utiliser les données du datalake pour permettre aux métiers d’activer de nouveaux cas d’usage. Par exemple, mettre en place l’automatisation de certaines tâches afin de faire gagner du temps aux équipes métiers (par exemple avec l’automatisation de la création de segments utilisateurs), ou faciliter l’échange de données avec des partenaires externes.
• Ouvrir un chapitre sur l’innovation avec le machine learning en interne, et passer le cap des modèles mis en production.

Pour résumer, l’ambition de cet outil ne se limite pas à la collecte et la transformation, c’est un facilitateur pour les métiers, pour les aider à activer de nouveaux leviers dans leurs activités.

Bénéfices

Quels sont les cas d’usage aujourd’hui ?

Nous avons des cas d’usage de data ingénierie classiques, comme la collecte des données des partenaires internes ou externes, qui seront ensuite exploitées dans les dataviz.

Nous avons aussi créé un service qui permet aux métiers de segmenter leurs données via une interface applicative, puis de les envoyer vers d’autres systèmes d’information pour exploiter ces segments. Autre exemple, une brique spécifique pour le CRM, qui là aussi permet de travailler sur des segments de données utilisateurs, de les tester dans une campagne d’emailing, puis d’évaluer la performance de la campagne. Les équipes CRM sont maintenant autonomes dans l’exploitation de leurs données tout en ayant une interface plus user-friendly que peut l’être la console AWS pour un public peu technique.

Enfin, nous avons développé un service de work-spaces cloud en Python (basé sur des Jupyter Notebooks) pour les data analysts. Cela leur offre de nouveaux outils et capacités d’analyse qu’ils ne pouvaient pas exploiter auparavant en SQL.

Nikola, en tant que Data Scientist, j’imagine que l’IA et le ML sont des sujets qui vous tiennent à cœur ?

En effet ! D’ailleurs le premier cas d’usage est arrivé rapidement, il s’agissait du  développement d’un algorithme de détection du customer churn dans le but d’améliorer la rétention du service de streaming vidéo M6+. Cela a été pour nous l’occasion de mettre en place des pratiques MLOps grâce à Amazon Sagemaker, qui nous permet de facilement industrialiser nos modèles, suivre leurs performances et les ré-entraîner quand nécessaire.

Mais exposer le modèle et industrialiser son cycle de vie n’est pas tout. Nous avons aussi donné aux métiers la possibilité d’exploiter les résultats directement dans leurs outils de CRM en envoyant des campagnes d’e-mails pour ré-activer les utilisateurs identifiés. Nous avons ainsi observé un gain significatif sur la rétention de nos utilisateurs par rapport aux méthodes traditionnelles, tout en assurant une expérience utilisateur fluide pour notre équipe CRM.

Nous sommes aussi particulièrement fiers de notre service de transcription vidéo et audio, accessible via une API. Les utilisateurs peuvent soumettre des contenus multimédias et obtenir un transcript complet, identifiant même les différents intervenants.

Ce service est précieux pour les journalistes et les équipes de contenu, leur faisant gagner un temps significatif. Au-delà de la transcription de base, nous explorons des cas d’usage prometteurs comme la génération de résumés ou de sous-titres.

C’est une brique technologique qui s’inscrit parfaitement dans l’univers média du groupe, où le contenu représente une valeur stratégique. Les algorithmes permettent d’enrichir encore cette valeur.

Pouvez-vous présenter Alfred, votre solution de Chatbot LLM ?

L’enjeu était de proposer une solution d’IA générative sécurisée aux collaborateurs, en réponse aux risques de confidentialité liés à l’utilisation de ChatGPT.

Nous avons créé Alfred, un assistant IA interne « made in M6 », construit à partir de solutions existantes comme Claude 3.5 via Amazon Bedrock. En phase MVP, il compte déjà une centaine utilisateurs avec des retours positifs sur des usages classiques comme le résumé d’emails, la reformulation de texte ou la recherche sur internet.

Nos ambitions pour Alfred sont multiples :

• Proposer des fonctionnalités spécifiques aux métiers média
• Étendre les usages du RAG en sourcant les documents du drive d’entreprise
• Gérer des documents avec des droits d’accès contextuels
• Automatiser des tâches métier comme la promotion de contenus, en orchestrant différentes sous-tâches. Par exemple, obtenir le résumé d’une série, ses critiques, un synopsis, etc.

Nous souhaitons créer un assistant différenciant, adapté aux besoins spécifiques de M6, et apportant une réelle plus-value par rapport aux assistants généralistes. La roadmap 2025 vise à développer ces capacités.

Conclusion

L’objectif de départ du datalake était de permettre la collecte de données. C’est devenu au fil du temps un écosystème complet offrant des outils, des environnements et des services qui apportent de l’intelligence aux collaborateurs.

L’équipe a grandi, nous sommes passés de 4 à 15 personnes en 4 ans. Nous développons maintenant des cas d’usages variés, notamment autour de l’IA et du ML, qui s’inscrivent dans le mandat de la direction des technologies et de l’information de construire un socle technologique innovant au service de la raison d’être du groupe M6 : proposer un contenu de qualité, diversifié et engageant dans un paysage médiatique en perpétuelle évolution.

Notre équipe transverse a maintenant vocation à s’adresser à toutes les entités du groupe : 

• Sensibiliser les métiers aux bénéfices des outils mathématiques et algorithmiques et développer les automatisations pour améliorer les analyses.
• Mettre en place une politique de data management : data quality, data lineage, data catalog.
• Accélérer l’exploitation et la valorisation des données dans le groupe.

Tout cela n’aurait pas été possible sans l’aide de l’équipe Devoteam. Au-delà de la compétence technique, les consultants Devoteam partagent avec nous leur travail de veille et d’acculturation. Quand on s’intéresse au Data Mesh ou au Data Cataloging, nous savons que nous pouvons nous appuyer sur Devoteam pour creuser ces sujets et nous apporter leur expérience acquise sur d’autres projets clients.