La première édition du Data Days Lille a eu lieu le 28 mars 2025 et a permis d’avoir un premier échange de la communauté Data lilloise sur toute une journée. L’équipe a également pu enrichir ses connaissances par des échanges informels sur le stand et par le suivi de conférences.

L’IA, sans surprise, était fer de lance de nombreuses conférences. Le constat est général : la croissance et la pérennisation de l’IA a pour cœur le même et éternel sujet, la data. Ce thème névralgique se décompose sous forme de nombreuses problématiques :

• Comment la stocker ?
• Comment la transformer ?
• Comment la rendre disponible de manière simple, efficace et transparente ?

Ainsi, la GenAI était au cœur de la majorité des conférences, avec des sujets comme :

• la mise en application de RAG,
• la nouvelle architecture data pour intégrer les données non structurées et pouvoir être exploitée par les agents,
• l’optimisation de recherche produit...

Nous avons aussi parlé de “Model Platform” pour la gestion des modèles ML Ops mais également de sujets plus classiques, comme par exemple de dbt (transformation, data contracts et autres), "Terraform ta data platform" avec GCP, ou encore du CDC.

🧠 Quelques chiffres importants à noter :

• La durée de vie du choix technologique d'une data plateform est de 15 ans vs 3-5 ans pour un microservice
• Nous créons plus de 149 zettaoctets (149.10^12 Go) de données par an (c’est vraiment beaucoup)

Mais assez d’introduction, parlons plus en détail des sujets qui nous ont intéressés et de notre retour sur les applications possibles.

Préparez vos Data Platforms pour l’Agentic AI [Laurent LETOURMY]

L’intervenant nous a partagé sa vision sur l’architecture future des data platforms afin qu’elles puissent intégrer les 80% restants des informations de l'entreprise, qui ne sont aujourd’hui pas traitées, car non structurées. La vision Data Mesh ou Data Product devient la seule solution envisageable pour pouvoir gérer ce nouveau volume de données en assurant aux utilisateurs qu’il soit exploitable. Ce dernier point étant critique pour 2 raisons :

• Comment, dans le monde de la data non structurée, s’assurer de la mise à jour des documents (versionning) et de la validation des datas extraites, quand ceci est déjà problématique dans le monde de la data structure ?
• Comment la rendre assez compréhensible (à l'échelle) pour que, demain, des utilisateurs mais aussi des agents puissent l’exploiter avec le même niveau de confiance ?

Le deuxième élément de transformation, qui va être permis par l’agentic AI, est une nouvelle approche de la BI. Tout d’abord, le premier impact sera la centralisation de la couche métier (sémantique) à l'extérieur des outils pour la rendre disponible à tous. En effet, si les dashboards de KPI restent un élément clé car structurant pour l’entreprise pour avoir des KPI’s transverse, s’ajoute une nouvelle couche d'interactivité qui va permettre aux utilisateurs de pouvoir poser leurs questions à travers une interface intuitive et simple. Si les challenges restent important (estimation de la véracité des réponses, scale à l'échelle de l’entreprise et non seulement d’un produit Data unique, ...), l’impact économique se voit déjà avec la réduction du nombre de licences pour les solutions de dataviz, ainsi que le nombre de dashboard devant être maintenu dans le temps.
La démonstration finale de leur POC Ask! a démontré un véritable game changer - car, qui dit agentic AI, dit réponse complexe avec pas seulement une réponse, mais des graphiques pour l’appuyer, ce qui permet à l’humain d'être au centre de la prise de décision et de partage.

Le sujet de l'évolution de la Data Quality, présenté la veille par Nathan Forestier lors de notre semaine de DataDays, a également été abordé lors de la présentation de Laurent LETOURMY. Il a souligné les défis des approches traditionnelles de la qualité des données, notamment la charge de travail en amont, la communication avec les métiers et l'adaptation aux nouveaux problèmes. Laurent a mis l'accent sur l'observabilité et l'apport de l'IA, qui permet d'obtenir une visibilité sur l'ensemble de la chaîne de valeur des données, de tester et détecter les anomalies en temps réel, tout en surveillant l'avancement vers une identification proactive des problèmes.

🧠 Petite remarque : demain, le patrimoine data de l’entreprise ne sera pas seulement de la donnée structurée et non structurée de documents, il faudra aussi ajouter des agents qui pourront être appelés pour répondre aux questions du besoin.

MLOps à l’échelle : Plateformiser le registre et l’inférence pour accélérer les déploiements [Emmanuel-Lin Toulemonde]

Dans le cadre de cette présentation, Emmanuel-Lin Toulemonde nous a parlé de sa vision d’une utopie d’une Model Platform. La Model Platform est une solution centralisée pour versionner, déployer, héberger et monitorer tous types de modèles. Assurant scalabilité, gouvernance et conformité, elle simplifie leur intégration et leur gestion. Tous ces éléments existent aujourd’hui séparément, avec des standards différents. Le but étant de les réunir autour d'un même produit.
Plusieurs architectures sont possibles pour la mise en place de ce Model Platform.

L’approche registre et runners centralisés, qui permet une standardisation du run de modèle et une mutualisation des ressources de calcul, mais qui peut avoir une latence entre le backend et les runners.

L’approche centralisée, qui permet une standardisation et une mutualisation, mais qui propose une logique métier à deux endroits différents. Nous avons eu le droit à une démo de cette architecture.

L’approche décentralisée, qui permet scalabilité et hétérogénéité technologique, mais qui a une faible mutualisation et des métriques fragmentées.

🧠 Element intéressant : la différence entre cycle de vie du software et du modèle ML. Dans beaucoup de cas, nous avons tendance à les mettre ensemble, mais chacun doit pouvoir avoir ses propres releases - d’où l'importance de découper le repository ML du repository software. Le second point est que ML est lié au produit aux données de production - comme en data ingénierie afin de faire nos tests valider les informations, nous avons besoin des données de productions et non de données simulés.

Quels cas d'usages pour Duck DB ?! [Antoine Giraud]

Duck BD - on en parle beaucoup ces derniers temps. Cette conférence m'a permis de voir quelques cas d’usage intéressants - mais d’abord commençons par une ségrégation des data engineers : le SQL et les dataframes… Chacun a sa propre approche. Duck DB est un outil analytique (engin de calcul) pour les premiers avec beaucoup de simplifications.
Pour moi, suite a cette conferences, 2 cas d’usage intéressants se distinguent autour de l’optimisation des coûts des computed des solutions data ( Snowflake, Databricks, … ).

Cas 1 : intégrer directement Duck DB dans les lambdas de transformations des clouds providers - on évite ainsi des coûts de réseau et des coûts de idles pour les petites et moyennes transformations. Les estimations sur les clients étaient d’environ 50 % d'économies de coûts sur ce type de transformation par rapport a du Snowflake classique.
Cas 2 : DuckDB comme partie de votre navigateur pour la BI. En effet, quand vous affinez vos recherches, vous allez augmenter les allers retours entre le serveur BI et votre poste de travail. Si vous déléguez les transformations a DuckDB localement, les rapports seront plus fluides et vous n’aurez qu'à gérer la partie incrémentale de la data, laissant l'incrémentation et la ségrégation a Duck DB.

Accélérez vos données : maîtrisez la capture de changement en temps réel [Benjamin Djidi, Stéphane Lambin]

Popsink lit le journal transactionnel de la base de données et transmet les changements en temps réel vers l'entrepôt de données — le tout sans aucun impact sur le système source. Chez Synergy France, cela est combiné avec Snowflake Streams and Tasks pour mettre en place une capture de changement en temps réel. Le résultat : des pipelines automatisés et des analyses instantanées, avec une latence d’environ six secondes.

Les volumes de données croissent rapidement, c’est un fait. Mais comment les déplacer vers nos entrepôts aussi vite qu’elles sont produites ? C’est la question explorée par Benjamin Djidi de Popsink et Stéphane Lambin de Synergy.
L’idée : ne plus interroger vos systèmes opérationnels, mais exploiter directement leur journal des transactions.

La fin du polling régulier

Plutôt que de requêter régulièrement les bases de données des systèmes opérationnels — une méthode sujette à la latence, aux pertes de données, et qui surcharge la base transactionnelle — Popsink se connecte directement au journal des transactions. L’outil capture les événements (insertions, mises à jour, suppressions) au fil de l’eau, en préservant leur ordre, et les transmet à Snowflake en temps réel.

Les limites du CDC "old-school"

Les solutions traditionnelles de CDC, basées sur des requêtes SQL, sont fragiles et inefficaces. En plus de ne pas garantir la consistance — on ignore comment la donnée a évolué entre deux scans — elles ajoutent une charge inutile sur des systèmes qui ne sont pas conçus pour l’analytique.

Alors, comment Popsink parvient-il à synchroniser les données tout en gardant le DBA de bonne humeur ?

L’architecture de Popsink et ses bénéfices

Au lieu de requêter la base, Popsink lit le journal des transactions. Résultat : aucun impact sur le système source. Les mises à jour sont traitées dans l’ordre, de manière incrémentale. Popsink gère aussi les évolutions de schéma et les slowly-changing-dimensions, évitant ainsi les pertes de données. En s’appuyant sur les transactions, la solution permet également le time travel et le reprocessing des données, toujours dans le bon ordre.

Cette architecture s’intègre bien avec des data warehouses modernes comme Snowflake.

Synergy utilise les streams, tasks et dynamic tables de Snowflake pour déclencher des actions dès qu’un changement est détecté — sans avoir besoin d’un orchestrateur externe.

Cas d’utilisation

Chez Synergy, Popsink se place entre l’application (qui écrit dans une base transactionnelle) et Snowflake. Grâce à son interface utilisateur et à ses nombreux connecteurs, Popsink est apparemment simple à déployer — une solution “set and forget”. Stéphane Lambin, CTO chez Synergy, souligne les nombreux bénéfices d’avoir des données disponibles pour l’analytique dès leur création.

Pour le métier, le CDC ouvre la voie à l’analyse en temps réel — par exemple, pour détecter des fraudes dès qu’elles surviennent.

Autre cas : le réapprovisionnement des stocks. Habituellement effectué la nuit, ce processus pourrait être rendu plus agile : disposer d’un état d’inventaire en temps réel permettrait de planifier plusieurs commandes par jour.

Et les bénéfices ne s’arrêtent pas au métier : l’extraction en temps réel permet aussi aux équipes techniques de réagir immédiatement aux incidents, plutôt que d’attendre le lendemain matin. Le résultat : un data downtime réduit au strict minimum nécessaire pour restaurer le système.

Conclusion

Cette présentation démontre qu’une solution de CDC bien conçue — reposant sur les journaux transactionnels et une approche temps réel — dépasse le simple cadre d’une mise à jour technique. Elle transforme les capacités opérationnelles. C’est une solution particulièrement pertinente pour les équipes confrontées à des traitements nocturnes rigides, des tableaux de bord obsolètes, ou des logiques d’ingestion fragiles.

Débuter sa Data Governance par le Data Catalog: déconseillé, risqué, mais comment en faire une force ? [Élodie Paresys]

Commencer sa gouvernance de la donnée par un outil de data catalog est en général déconseillé — mais pas voué à l’échec. En posant les bons jalons (sponsors, MVP, accompagnement métier), cela peut devenir un bon point d'entrée plutôt qu’un piège.

Data Governance et Data Catalog

Dans cette présentation, Élodie Paresys a partagé une méthode nuancée mais pragmatique : oui, commencer sa gouvernance de la donnée par un data catalog est une prise de risque, mais si ce risque est assumé et cadré, il peut être transformé en levier.

Qu'est-ce que la gouvernance de la donnée ? En bref, il s’agit avant tout de savoir ce qu’on a, où c’est, et à quoi ça sert. Donc, une question de valeur. Lorsqu’on commence à douter de ses données, que les chiffres ne concordent pas entre les sources, ou que la confiance s’érode, c’est souvent le signal qu’il faut passer à l’action.

Le data catalog, dans ce contexte, agit comme un glossaire : il nous dit ce que signifie un objet métier. Elodie Paresys prend l'exemple du client : tout le monde pense savoir ce que représente un "client" dans une organisation. Mais quand il s'agit de le définir clairement, on se rend compte que ce n'est pas si simple. Le Data Catalog peut donc être perçu comme un accélérateur de gouvernance — à condition de ne pas le confondre avec la gouvernance elle-même. Les objectifs, les indicateurs, et les périmètres sont différents.

Les cinqs pilliers de la data governance

Elodie Paresys a structuré son approche autour de cinq piliers : la stratégie, le modèle opérationnel, les outils/processus, la communication, et l'accompagnement métier.

Côté stratégie, le message est clair : intégrer le métier dès le départ, et obtenir des sponsors métier plutôt qu’IT. L’adhésion doit venir de ceux qui vivent la donnée au quotidien.
Pour le modèle opérationnel, un conseil à contre-courant : éviter les profils hybrides IT/métier. Il faut aussi attribuer des rôles clairs à chacun, en s’appuyant si possible sur ceux déjà présents dans le futur outil. Cela permet d’éviter les confusions et d’aligner les pratiques sur le fonctionnement réel.

Sur les outils et processus, Elodie Paresys note : acheter un outil peut être un bon signal, car cela traduit un engagement. Mais pour les processus, il faut aller au-delà de l’aspect documentaire. La question n’est pas "comment documenter ?", mais "pourquoi le faisons-nous ?". Un autre but: viser un MVP qui fonctionne, même si basique, tant qu’il génère de la valeur.
Ce MVP doit être mis entre toutes les mains le plus tôt possible. Mais avec une large diffusion vient aussi la nécessité de communiquer — et de le faire sur le changement, pas seulement sur l’outil. La gouvernance, c’est un projet de transformation.

Conclusion

Élodie Paresys, contrairement à de nombreuses publications sur Linkedin, nous le dit: commencer la gouvernance par un data catalog n'est pas une si mauvaise idée que ça. Si l’on assume ce choix, qu’on le structure autour d’une vision claire et d’un accompagnement solide, il peut devenir un point de départ efficace.

Data as Code : la révolution des Data Contracts [Cédric Olivier]

Chez Orange, chaque échange de données entre couches passe désormais par un contrat formel — un data contract — décrivant le modèle, le contenu, les usages, et même les tests appliqués à la donnée. Résultat : une architecture modulaire, une assurance sur la qualité, et plus de transparence. Bienvenue dans l’ère du Data as Code.

🧠 Comment rendre l'ingestion de données aussi lisible, modulaire et vérifiable que du code source ?
Pour Cédric Olivier, tech lead chez Orange, la réponse passe par une nouvelle brique architecturale : le data contract.

Des silos aux surcoûts

Les équipes Orange composent avec plusieurs environnements (GCP, Hadoop, Teradata), chacun organisé en silo.
Même avec une architecture en médaillon (bronze, silver, gold), les échanges entre plateformes forçaient souvent les données à repasser par le niveau brut — une redondance coûteuse, tant au niveau finops, qu'en charge de développement.

L’objectif était donc triple : mutualiser les ressources, harmoniser les pratiques, et réduire les coûts. Pour cela, il fallait standardiser les échanges de données, sans sacrifier l’agilité.

Un contrat pour chaque produit

Cédric Olivier introduit alors la notion de data product : un ensemble cohérent de données exploitables par le métier. Chaque data product est accompagné d’un data contract, véritable contrat d’interface — à la manière d’un OpenAPI, mais pour la donnée.

Ce contrat formel décrit le modèle, le propriétaire, la fréquence des mises à jour, la définition métier, les règles de qualité, les SLA, l’environnement de stockage, et même des exemples d’usage.
Cette spécification, rédigée en YAML, devient la référence unique entre producteurs et consommateurs.

Générer le code, valider les attentes

Le data contract n’est pas qu’un document. Grâce au data contract CLI, il permet de, par exemple, générer automatiquement du code d'ingestion.

Une démonstration live l’a montré : à partir d’un contrat, Cédric Olivier a pu générer les modèles dbt nécessaires à l’importation des tables d’un produit. Un réel gain de temps pour le développeur, qui n'a plus à réaliser ce travail fastidieux et répétitif.

Chez Orange, chaque couche — du fichier brut à la donnée métier — est désormais interfacée par un contrat. Et dans la CI/CD vient vérifier que les data contracts écrits pour un produit data respectent bien les exigences attendues.

Intégration avec dlt

Autre brique technique utilisée pour la couche bronze: dlt. dlt prend en entrée différents fichiers (CSV, JSON, etc) et les extraits vers des tables. Avec dlt, le contrat gouverne le schéma de destination : par exemple, si un fichier CSV contient une colonne imprévue, elle est tout simplement ignorée.
Cela garantit la stabilité des pipelines même en présence de variations dans les sources.

Conclusion

Le data contract devient un pivot central entre équipes, environnements et outils.
Il permet d’industrialiser la production de données sans perdre en transparence ni en souplesse.

Moderniser un projet dbt legacy : tests, observabilité et migration sans risque [Henri-Maxime Ducoulombier]

Migrer un projet dbt legacy vers une architecture propre et testée, sans casser les produits de données existants ? C’est possible. Grâce à une approche structurée combinant tests, data contracts, observabilité et refonte progressive, Henri-Maxime Ducoulombier partage comment il a transformé 200 projets dbt hétérogènes sans interruption de service.

Certains doivent déjà se poser une question: du legacy dbt ? Et bien le client de Henri-Maxime Ducoulombier est un "early adopter" de dbt. Et ils se sont retrouvés avec un grand nombre de projets difficilement maintenables. Versions incohérentes, absence de tests, modèles obsolètes, et gouvernance peu formalisée — le tout hérité d’une époque pré-1.0 pour les plus vieux projets. Migrer ces projets sans impacter les utilisateurs finaux est un défi à la fois technique et organisationnel.

Une migration à grande échelle

Le client d’Henri-Maxime possède plus de 200 projets dbt, construits au fil du temps sans réelle homogénéité. Le travail a consisté à tout reprendre, sans (presque) rien casser. La première étape fut de repérer le code mort via le lignage. L’objectif : ne pas migrer l’inutile, et simplifier ce qui peut l’être. Ensuite, un gros travail de mise à jour des versions dbt et des packages a été mené, avec l’introduction progressive de l’outil dbt Elementary pour ajouter de l’observabilité sur les projets legacy.

Unifier les structures et renforcer les garanties

Une fois la dette identifiée, les structures des projets ont été uniformisées autour des bonnes pratiques dbt : séparation claire entre les couches staging, intermediate et mart. Chaque niveau s’est vu appliquer un traitement spécifique.
Au niveau staging, priorité à la fraîcheur des données, aux data contracts, et aux tests de qualité.
Dans la couche intermediate, où les schémas évoluent rapidement, les tests et tests unitaires ont été privilégiés, sans imposer de contrats.
Enfin, côté mart, là où résident les produits de données finaux, des tests, des contrats et un système de versionning des modèles ont été mis en place pour éviter les breaking-changes.

Gouvernance et accompagnement métier

La migration technique n’aurait pas été possible sans un travail de gouvernance. Respect des politiques internes, harmonisation des noms, et lutte contre la duplication de termes. Les tests ont été construits conjointement avec les utilisateurs pour garantir leur pertinence.

Leçons apprises

Les clefs du succès d'après Henri-Maxime Ducoulombier ? Respecter les lignes directrices et politiques internes, qui sont là pour une raison. Il insiste aussi particulièrement sur les différents tests (data contracts, tests unitaires, tests des données) ainsi que le model versionning. De plus, pas de big bang, mais une refonte en douceur. Et bien entendu, impliquer le métier.

Conclusion

Moderniser un écosystème dbt vieillissant n’est pas qu’un problème de tooling. C’est un chantier de fond, mêlant gouvernance, accompagnement métier, bonnes pratiques de développement et outils d’observabilité. Avec une approche incrémentale et outillée, il est possible de reprendre la maîtrise de projets legacy, tout en continuant à livrer de la valeur sans interruption.

Remarque: avec 200 projets dbt, on se retrouve avec 200 dashboards Elementary. dbt-loom, avec un peu de bricole, permettrait de rassembler tous ces dashboards en un seul.

Transformez l’Accès à l’Héritage Scientifique Lesaffre avec un RAG Avancé [Julie ADALIAN]

L'objet de cette conférence était de partager les étapes de la mise en place d’un RAG sur les documents chez Lesaffre dans le cadre ou la gestion des documents avec leurs différentes versions était déjà mise en place.

Le but était de mettre à disponibilité des employés un chat bot capable de répondre sur des questions liées à une base documentaire déjà managée. Les challenges :

• les mots clefs techniques,
• le multilingue.

Qu’est ce qui m’a semblé intéressant ? Les différentes stratégies autour de la reformulation de la question afin d’obtenir les chunks pertinents ( approche embedding, par mots clés, traductions, reformulation de questions, …).

Data vs. Zombies: Ethical Dilemmas in a Fictional Apocalypse [Fred Jacquet]

Il s'agissait de la conférence de conclusion où l'auteur, a travers différentes questions, essaie de nous projeter dans un monde futur apocalyptique, pour nous poser multiples questions sur des possibles usages de la data qui appartiendrait a un nombre limité de personnes ? Les impacts de biais de lecture, de data erronés sur nos vies - comme une fièvre dans son enfance mais qui apparaîtraient comme symptôme du Zombisme nous mettant au banc de la société.
Quand je dis futur apocalyptique, ça serait plutôt une image car aujourd’hui nombre des situations décrites existent déjà, comme la collection et l’exploitation de nos données personnelles par les GAFA - leur donnant un avantage marketing supérieur, la complexité du droit à l'oubli numérique … tout cela certes a un niveau moindre. Cela nous force à penser en temps que data engineer :

• Attentions aux biais que l’on peut introduire
• Garantir l'anonymisation des données ou leur facile suppression ( dans le data swamp )
• Essayons au maximum de rendre la data accessible et audible à tous

Sur la petite conclusion : l’erreur humaine est plus facilement acceptable que l’erreur d’une machine.

Rencontre intéressantes :

Les conférences sont également un lieu de rencontre. Nous avons notamment échangé avec Cédric Olivier, le tech lead chez Orange impliqué dans le projet To Be Continuous. Désormais open source, ce projet propose un ensemble de templates modulaires pour GitLab CI. Au-delà de la standardisation des pipelines CI/CD, il met à disposition tout un éventail d’outils DevSecOps. La composante composant du projet IPPON : “Plateform Enginnering” sur GCP s’inspire de ces bonnes pratiques. D’ailleurs, chez Ippon nous avons contribué à ce projet open source.