M6: from datalake to GenAI, Data as a driver of innovation

In the context of organisational transformation, the M6 Group created a data lake. Based on an AWS infrastructure, this data lake project aimed to meet immediate operational needs for data collection and processing while laying the foundations for a future technological innovation strategy and exploration of use cases related to artificial intelligence.

For the past four years, Devoteam has been supporting M6 in this process. This article traces the history of its creation, the technological choices that guided its evolution, and the gradual development of its various components.

Nikola Pekez, Datalake Manager (M6), and Gauthier Vuong, Product Owner (M6), answered our questions about this project, which was carried out in collaboration with the Devoteam teams.

Download Now: Free AI Strategy Playbook
[New 2025]

Context

In what context did the Datalake project begin?

The creation of the data lake is part of a transformation within the M6 group. Initially led by the 6play business unit (now M6+), this initiative emerged from transferring some of the technical skills and data know-how to a new company, Bedrock Streaming, dedicated to developing a VOD technology platform. This evolution separated roadmaps and objectives and highlighted many data needs that this new organisation no longer addressed.

Faced with the needs of business and technical teams, particularly data analysts and operators facing limitations in data processing, the group’s digital vertical identified the need to regain autonomy over data topics.

Building the data lake was an opportunity for innovation and experimentation with new technologies, and this approach marked the beginning of the collaboration with the Devoteam teams. The primary objective of creating the data lake was to develop a more efficient data infrastructure adapted to the specific needs of M6+.

Why did you choose AWS as your technical stack?

The choice of AWS as our infrastructure was natural: We already had some expertise in the AWS ecosystem, and Bedrock Streaming’s data stack was also on AWS. We aimed to capitalise on existing skills and prioritise a simple and competitive solution in a familiar technological environment.

Beyond the technical aspects, there was also a human dimension. Building the data lake from the ground up, avoiding turnkey solutions, met the objective of attracting talent and offering them a stimulating playing field. This approach allowed us to develop our skills in fundamental technological building blocks, which we probably wouldn’t have acquired with prepackaged solutions.

Challenge

What were the objectives and ambitions of the POC?

We wanted to explore the feasibility of an iterative approach. The idea was to grow gradually while addressing the most pressing use cases, such as data retrieval and processing for dashboarding. We aimed to test the technologies, assess their suitability for our teams’ needs, and propose innovations.

How did you start building the Datalake?

We developed the first building blocks of the data lake together, testing different storage and pipeline construction options. This approach reduced the time to market for these features.

To meet the needs of the operational teams, management approved the transition from POC to MVP. This resulted in more resources and external support to build a state-of-the-art data lake.

Solution

How did you organize the team between M6 and Devoteam?

At the start of the project, the team composition was as follows:

• Nikola: Technical Advisor
• Gauthier: product owner
• Devoteam Consultants: a senior platform architect who structured the V0 of the data platform, and a data engineer

The data lake was built using a bottom-up approach based on priority use cases, such as “carve out,” i.e., the recovery of certain data perimeters previously handled by Bedrock Streaming. At the same time, M6 deployed Looker as a group data visualisation tool, requiring the feeding of various data sources.

We started by creating data pipelines to replicate data from the Bedrock environment. As data lakes were a new topic, we had little experience. We rolled up our sleeves and worked on creating these pipelines, gradually increasing the size of our data perimeter.

The goal was to quickly demonstrate the added value: the database’s ability to collect, integrate, and distribute data, thus supporting data analyst teams that had previously been struggling.

What was the added value of the Devoteam team?

First, the team helped us select the right AWS services and orchestrate them to build the data lake. Devoteam also brought us DevOps and CI/CD skills that we didn’t have, and more generally, its experience with the Cloud and its mastery of best practices.

This allowed us to build a vision together, the objective we would work towards, at a time when we tended to work day by day. Building a data lake was intimidating; it seemed like a massive project. The Devoteam team, through its experience, was able to show us how to proceed step by step.

We also had to manage our own AWS landing zone (management of the network of accounts, users, etc.), and the Devoteam team supported us in its implementation and operation, subjects which not only represented a heavy workload but on which we had little knowledge.

What were the first use cases addressed?

Data analysts primarily used SQL for their queries. So one of the primary needs of the Data Lake was to enable data collection and storage and then query it with SQL via Amazon Athena.

The teams then expressed the need to create new tables to perform additional calculations. So, we began building data transformation pipelines, iterating on the data lake architecture. However, as requests multiplied, we realised that it was necessary to evolve our data platform to scale successfully.

How did you evolve your platform – what choices and why?

When the data lake was first built, the technological landscape differed greatly from today. Solutions like Databricks, Snowflake, and DBT already existed but had not yet reached the level of maturity they have today.

Therefore, we opted for an AWS-native approach. The idea was to organise the services and their interactions ourselves to develop the data pipelines. However, the choice of AWS services was not a long, calm river; it was made through iterations. Whereas our initial architecture focused on low-level infrastructure technologies (Airflow on Kubernetes, EMR with EC2, etc.), we increasingly moved towards AWS managed and serverless services (Amazon Managed Workflows for Apache Airflow (MWAA), EMR Serverless, etc.).

The goal of this approach is to do better with less. Rather than spending time and energy maintaining complex infrastructures, we focus on our core business: providing our users with a robust serverless data platform to respond quickly to their sometimes complex use cases.

Devoteam has greatly helped us form our convictions on these highly strategic technological subjects, allowing us to weigh the pros and cons between, on the one hand, greater flexibility by managing our infrastructure and, on the other, a better time-to-market and a lower Total Cost of Ownership thanks to serverless.

What are the missions of the Datalake?

The datalake’s missions are based on 3 main pillars:

• Data engineering: enabling the collection, transformation and provision of data.
• Being an operational and business facilitator. Having data, transforming it, and using it in dashboards is one thing, but we want to go further. We also want to use data from the data lake to enable businesses to activate new use cases. For example, we want to implement the automation of certain tasks to save business teams time (for example, by automating the creation of user segments) or facilitate data exchange with external partners.
• Open a chapter on innovation with machine learning and bring our models to production.

To sum up, this tool’s ambition is not limited to collection and transformation; it is a facilitator for businesses that helps them activate new levers in their activities.

Benefits

What are the use cases today?

We have classic data engineering use cases, such as collecting data from internal or external partners, which will be used in data visualisation.

We also created a service that allows businesses to segment their data via an application interface and send it to other information systems to exploit these segments. Another example is a specific CRM building block that also allows you to work on user data segments, test them in an email campaign, and evaluate the campaign’s performance. CRM teams are now autonomous in exploiting their data while having a more user-friendly interface than the AWS console can be for a non-technical audience.

Finally, we developed a cloud workspace service in Python (based on Jupyter Notebooks) for data analysts. This offers them new tools and analysis capabilities they couldn’t previously leverage in SQL.

Read our expert view on datalake management for more in-depth strategies on optimising your data infrastructure and cutting costs.

Nikola, as a Data Scientist, AI and ML are topics close to your heart?

Indeed! The first use case came quickly: developing a customer churn detection algorithm to improve M6+ video streaming service retention. This was an opportunity for us to implement MLOps practices using Amazon Sagemaker, which allows us to easily industrialise our models, track their performance, and retrain them when necessary.

But exposing the model and industrialising its lifecycle isn’t everything. We also allowed business units to leverage the results directly in their CRM tools by sending email campaigns to reactivate identified users. We’ve observed significant gains in user retention compared to traditional methods while ensuring a seamless user experience for our CRM team.

We’re also particularly proud of our video and audio transcription service, which is accessible via an API. Users can submit multimedia content and receive a full transcript, even identifying the individual speakers. This service is invaluable for journalists and content teams, saving them significant time. Beyond basic transcription, we’re exploring promising use cases like generating summaries or subtitles.

It’s a technological building block that fits perfectly into the group’s media universe, where content represents strategic value. Algorithms allow this value to be further enriched.

Can you introduce Alfred, your LLM Chatbot solution?

The challenge was to offer a secure generative AI solution to employees in response to the confidentiality risks linked to the use of ChatGPT.

We created Alfred, an internal AI assistant “made in M6,” built from existing solutions like Claude 3.5 via Amazon Bedrock. In its MVP phase, it already has around 100 users with positive feedback on typical uses like email summarisation, text rephrasing, and internet searches.

Our ambitions for Alfred are multiple:

• Offer features specific to media professions
• Expand the uses of RAG by sourcing documents from the company drive
• Manage documents with contextual access rights
• Automate business tasks like content promotion by orchestrating different subtasks. For example, getting a series summary, reviews, synopsis, etc.

We aim to create a distinctive assistant tailored to the specific needs of M6 and provide real added value compared to general assistants. The 2025 roadmap aims to develop these capabilities.

Conclusion

The initial objective of the data lake was to enable data collection. Over time, it has become a complete ecosystem offering tools, environments, and services that bring intelligence to employees.

The team has grown; we’ve gone from 4 to 15 people in 4 years. We’re now developing a variety of use cases, particularly around AI and ML, which are part of the Technology and Information Department’s mandate to build an innovative technological foundation to serve the M6 Group’s purpose: to offer quality, diverse and engaging content in a constantly evolving media landscape.

Our cross-functional team is now intended to address all entities within the group:

• Raise awareness among professionals of the benefits of mathematical and algorithmic tools and develop automation to improve analyses.
• Implement a data management policy: quality, lineage, and catalogue.
• Accelerate the exploitation and enhancement of data within the group.

None of this would have been possible without the help of Devoteam. Beyond their technical expertise, Devoteam consultants share their monitoring and acculturation work with us. When we’re interested in Data Mesh or Data Cataloging, we know we can rely on Devoteam to delve deeper into these topics and bring us their experience gained from other client projects.