La Grosse Conf 2025 - Construire une plateforme de données : entre mythes, récits et leçons à tirer.

Introduction

Les plateformes de données sont depuis plusieurs années une brique clé pour la collecte et le traitement des données. Pourtant, la variété des architectures, des technologies, des organisations en fonction des usages et des contraintes des entreprises fait de leur mise en place et de leur pérennité un challenge important pour beaucoup d’acteurs.

Karim Sayadi, Lead Data & IA Manufacturing X chez OCTO Technology, introduit son talk par une première comparaison avec un tableau de Gustav Klimt, Pallas Athena, pour nous donner sa vision d’une plateforme de données : le symbole de la stratégie, de la résilience et donc de la réussite d’une entreprise. On reconnaît dans cette représentation, les attributs conférés dans la mythologie grecque à la déesse Athéna peinte par G. Klimt.

> “Pour moi une plateforme de données, c'est Athéna, elle doit vous rendre victorieux, libérer l'innovation, et elle participe à votre résilience en établissant la bonne tactique !”

Karim Sayadi

Mais alors pourquoi dans la réalité des projets retrouve-t-on dans ces plateformes de données, plutôt un empilement de technologies très complexes et difficilement maintenables qui finissent par être laissées à l’abandon ?

Retours d’expérience :

Fort de ses 10 années d’expériences qui lui ont permis de voir et travailler sur des data platforms sous diverses formes et dans divers contextes, Karim nous partage les enseignements qu’il a pu tirer en imageant ses exemples par deux domaines qu’il apprécie particulièrement : l’art et la mythologie. Il répertorie au cours de sa présentation six patterns qu’il a pu observer.

Une accumulation de technologies :

Tout comme le roi Midas qui voulait devenir extrêmement riche en demandant le pouvoir de transformer en or tout ce qu’il touchait, jusqu’à transformer sa fille en statue, le travers de vouloir accumuler beaucoup de technologies les plus en vogue qu’elles soient, mène souvent à une non utilisation de ces outils par les développeurs qui n’y adhèrent pas. Une des clés de réussite de la mise en place d’une plateforme de données est l’adoption de celle-ci par les métiers et les développeurs, il est donc important d’investir dans la formation et l’expérimentation et surtout ne pas négliger le budget à allouer à la part humaine d’un projet.

Le silotage des équipes tech et business :

D’après la légende de la guerre de Troie, Cassandre avait prédit la chute de la cité par la ruse d’un cheval de bois mais le Roi ne l’avait pas écoutée ce qui mena à la défaite de son peuple. Nous pouvons y voir un parallèle avec le manque de communication et surtout d’écoute entre les équipes tech et business. Il est essentiel de construire une relation de confiance entre les développeurs et le produit car elle permet de prévenir de pertes de temps et d’argent (des features très coûteuses pour une faible plus-value, des risques liés à l’accumulation de la dette technique, l’over engineering sans valeur finale pour le métier). Cette relation peut être facilitée grâce à des “traducteurs”, des profils tels que des Data Product Manager ou des Data Analyst qui comprennent les différents enjeux et jouent ce rôle de pont entre les deux visions. Karim conseille aussi par expérience, l’organisation de sessions d’immersion dans le quotidien de chacun, des “vis ma vie” dans les équipes métiers ou du pair-programming avec les équipes tech.

La volonté de collecter toujours plus de données :

Un des critères utilisé pour comparer des data platforms est la quantité de données stockées, dans un datalake ou un datawarehouse par exemple. Mais l’utilisation de ces données ou encore leur gouvernance est un sujet trop souvent mis en second plan. Pourtant des données non exploitées n’apportent aucune valeur au projet ou à son amélioration continue. Elles sont même, d’après une étude réalisée par Splunk, qualifiées de “Dark Data” et représentent sur 1300 entreprises prises en exemple, 55% des données d’un datalake en moyenne. Karim assimile ce constat aux Danaïdes condamnées à remplir éternellement des jarres sans fond. Pour tendre vers une meilleure gestion des données, il est nécessaire de savoir définir un cycle de vie à la donnée utile : quelle donnée collecter, comment la stocker, la traiter, la visualiser, l’utiliser et puis quand et comment la détruire. L’optimisation d’un datalake, et notamment de la rétention des données est un enjeu très important qui impacte notamment l’infrastructure, la charge d’exploitation ou les temps de réponses.

Des livraisons en production irrégulières :

Une fonctionnalité qui n’est pas en production, ne peut pas être utilisée par les usagers. Alors dans ce cas-là, le développement est-il réellement terminé ? Karim attire notre attention sur ce “dernier kilomètre”, l’état dans lequel se situe une fonctionnalité quand il ne reste “plus que” les tests ou “plus que” le déploiement. Malheureusement, cette étape est trop souvent minimisée par les équipes de développement et alors qu’une fonctionnalité paraissait pouvoir être en service en quelques heures, elle prend finalement beaucoup plus de temps. Cette quête peut laisser penser à la malédiction de Tantale qui cherche à attraper une pomme juste au-dessus de sa tête pour se nourrir alors que la branche s’éloigne, de même que la rivière qui s’abaisse lorsqu’il essaye d’y boire: le but paraît à notre portée mais il n’est jamais atteint. Un autre risque de faire durer cette mise en production est l’over-engineering. Les développeurs ont souvent tendance à retarder une livraison en voulant trop en faire, ou en voulant traiter tous les détails avant de laisser la main aux utilisateurs. C’est un réflexe finalement assez souvent contre productif car l’objectif principal devrait être d’apporter le plus rapidement possible de la valeur à l’utilisateur et de récolter leur feedback, les tickets d’amélioration pouvant être livrés au fur et à mesure des incréments. Une fonctionnalité doit donc être considérée toujours en cours de développement tant qu’elle n’est pas en production et il est important de fixer des règles strictes sur les critères de mise en service pour fluidifier ces livraisons.

Sous-estimer la tâche de nettoyage des données :

Karim compare le nettoyage des données au mythe de Sisyphe, condamné à porter un rocher jusqu’en haut d’une colline pour qu’une fois au sommet le rocher retombe et que Sisyphe soit obligé de recommencer sa mission. Le nettoyage des données est évidemment un sujet très important dans la gestion d’une data platform mais c’est surtout perçu comme une tâche répétitive, chronophage qui n’ajoute pas de valeur au produit final. Il est donc assez fréquent qu’elle soit priorisée par les équipes métier au début du projet puis considérée comme réalisée, ne nécessitant plus aucune action supplémentaire. Karim note que dans le mythe auquel il fait référence, Sisyphe accepte sa situation, sait ce qu’il a à faire et prend à cœur de réaliser sa tâche correctement. De la même manière, il conseille d’accepter que le nettoyage des données soit une action récurrente et indispensable. Pour cela, il est nécessaire d’allouer du temps et donc du budget à ce nettoyage et à l’entretien des pipelines pour éviter les dettes techniques qui nuisent forcément à la qualité du produit. Il existe également des solutions qui permettent de faciliter ces tâches : la mise en place d’alertings automatisé****s qui préviennent des changements dans les données ou encore la formalisation de contrat de données qui permet d’assurer la cohérence entre les fournisseurs et les destinataires de ces data, par exemple avec des outils comme datacontract.com.

Compenser les performances par plus de moyens techniques :

Les lenteurs d’une plateforme de données sont une difficulté que de nombreux projets rencontrent. Un premier réflexe peut être d’investir dans plus de serveurs, plus de stockage ou plus d’équipements. Pourtant la solution se situe plus souvent dans l’optimisation du code et l’utilisation des briques déjà en place. Pour cela, il faut déterminer les flux critiques, les plus sollicités et coûteux en performance, pour pouvoir étudier les pistes d’amélioration : ajouter des index, partitionner, optimiser des requêtes ou plus globalement revoir l’architecture des briques concernées. Pour démontrer l’intérêt de prendre le problème de performance non pas par le manque de moyens techniques mais par les lacunes de conception, Karim fait le parallèle avec la légende du personnage d’Hippomène. Celui-ci réussit à se marier à la déesse de la chasse, Atalante, après avoir relevé le défi de la battre à la course. Il n’était évidemment pas plus rapide qu’une déesse mais usa de la ruse en déposant des pommes d’or sur le parcours pour lui faire perdre du temps à ramasser ces fruits. Il gagne ainsi son pari et la main de la déesse.

Conclusion

A travers tous ces récits, Karim insiste sur l'importance de trois piliers dans la réussite d'une plateforme de données :
La dimension humaine: avoir des équipes compétentes et valorisées qui travaillent ensemble et qui adhèrent aux outils de la plateforme.
L'organisation de la plateforme: avoir des données gouvernées, utiles pour le projet et qui alimentent des fonctionnalités en production, confrontées à l'utilisation des usagers et donc améliorées au fur et à mesure en fonction des retours terrain.
La qualité des données et de l’architecture de la plateforme: donner de l’importance même aux tâches plus techniques que fonctionnelles comme le nettoyage des données, le traitement de la dette technique, les performances des flux et les défis d’accès à la donnée.

Pour terminer, Karim nous partage un tableau de la Méditerranée, un lieu qui lui évoque la sérénité d’une platform data réussie :

Claude Monet, Rochers au bord de la Méditerranée

Et pour revoir le Talk de Karim en entier, c’est par ici !