Post de Achille Huet

👋 𝗥𝗲𝗻𝗰𝗼𝗻𝘁𝗿𝗲𝘇 Moudjibou OUSSEINI HASSANE, 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝗲 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗗𝗮𝘁𝗮 𝗰𝗵𝗲𝘇 𝗣𝘆𝗹.𝗧𝗲𝗰𝗵 ! 𝗣𝗿𝗲́𝘀𝗲𝗻𝘁𝗲-𝘁𝗼𝗶 : Fort de mon expérience comme Data Engineer et Lead Tech Data auprès de grands groupes en banque, assurance, télécoms et retail, j’ai développé des compétences en intégration de données et migration d'infrastructures Data. Aujourd'hui, je conçois des datastacks sur mesure, sélectionne les architectures et développe des data pipelines pour assurer l’autonomie des solutions. J’offre également aux entreprises des indicateurs clés pour piloter leurs activités, allant de la prévision des stocks au suivi de la performance financière. 𝗣𝗼𝘂𝗿𝗾𝘂𝗼𝗶 𝗹’𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗱𝗮𝘁𝗮 𝗲𝘀𝘁-𝗲𝗹𝗹𝗲 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁𝗲 𝗽𝗼𝘂𝗿 𝘂𝗻𝗲 𝗲𝗻𝘁𝗿𝗲𝗽𝗿𝗶𝘀𝗲 ? L'architecture data est essentielle car elle permet à une entreprise d'être "data-driven". Les décisions se basent sur des données fiables plutôt que sur des opinions. Cela permet d’optimiser les processus internes et de réduire les temps de traitement. Sans elle, certaines entreprises peuvent passer jusqu'à 80 % de leur temps à extraire des données, ne consacrant que 20 % à leur analyse. 𝗖𝗼𝗺𝗺𝗲𝗻𝘁 𝗮𝗱𝗮𝗽𝘁𝗲𝘀-𝘁𝘂 𝗹𝗲𝘀 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲𝘀 𝗱𝗮𝘁𝗮 𝗮𝘂𝘅 𝗯𝗲𝘀𝗼𝗶𝗻𝘀 𝗱𝗲 𝗰𝗵𝗮𝗾𝘂𝗲 𝗰𝗹𝗶𝗲𝗻𝘁 ?  Je cartographie les solutions du marché et les évalue selon les critères du client : coût, infrastructure, sécurité, etc. En cas de problème, je propose toujours des alternatives. Par exemple, chez un client, nous avons remplacé l'outil de data movement après deux ans en raison d'une incompatibilité avec la nouvelle version de l'ERP. Il est donc essentiel de rester prêt à adapter les choix. 𝗟𝗲 𝗰𝗹𝗶𝗲𝗻𝘁 𝗽𝗲𝘂𝘁-𝗶𝗹 𝗲̂𝘁𝗿𝗲 𝗮𝘂𝘁𝗼𝗻𝗼𝗺𝗲 𝗮𝗽𝗿𝗲̀𝘀 𝗹𝗮 𝗳𝗶𝗻 𝗱𝘂 𝗰𝗼𝗻𝘁𝗿𝗮𝘁 ? Je veille à documenter tous les aspects du projet : les choix techniques, l'architecture mise en place, les flux de données, etc. Cela permet au client d'être autonome après notre départ. Nous formons également les équipes internes et les accompagnons dans leur montée en compétence sur la supervision, la maintenance et l'évolution de la plateforme Data. 𝗤𝘂'𝗲𝘀𝘁-𝗰𝗲 𝗾𝘂𝗲 𝘁𝘂 𝗮𝗶𝗺𝗲𝘀 𝗰𝗵𝗲𝘇 𝗣𝘆𝗹.𝗧𝗲𝗰𝗵 ? J'apprécie que ce soit une entreprise à taille humaine, avec une forte proximité. Il y a une vraie audace et une passion pour l'innovation. Pyl.Tech se positionne à la pointe de la technologie, grâce à une veille constante sur les nouvelles tendances. C’est aussi le cas sur des technologies que l'on maîtrise déjà, on aime tester des nouveautés et c’est ce qui nous permet de travailler sur des projets innovants !

Comment choisir le bon propriétaire de la donnée ? Après avoir choisi le bon outil de data catalog, effectué la modélisation des métadonnées, il vient l’enrichissement dudit data catalog. Il est fortement recommandé de définir des data owners, également appelés référents métiers ou tout simplement propriétaires des données. Dans le cadre de la mise en place d’une gouvernance au sein d’une organisation, c’est important de définir des propriétaires pour les données, et cela pour plusieurs raisons : * Créer une synergie data avec les métiers en incluant les propriétaires dans les features teams qui délivrent les usages data. * Responsabiliser les métiers sur les données qu’ils produisent => améliore la qualité des données, notion de data contract. * Avoir un interlocuteur clairement défini pour la validation des règles de gestion métiers et des définitions métiers => améliore également la qualité des données. Maintenant, qui va-t-on choisir ? C’est important de sélectionner, dans un premier temps, un petit groupe de collaborateurs ayant une appétence et/ou une forte motivation à utiliser la data en plus de leur connaissances métiers. Trouver les champions data, ces collaborateurs qui seront un vrai catalyseur à la transformation data de l’organisation, va permettre de créer petit à petit une base solide à une effervescence grandissante autour de la data. #data #datagovernance #datacatalog #gouvernancedesdonnées #datacontract #dataaddict #dataforever #TechInnovation

1 minute ⏰ pour comprendre l’évolution vers l’ère des 𝙙𝙤𝙣𝙣𝙚́𝙚𝙨 𝙢𝙖𝙞𝙡𝙡𝙚́𝙚𝙨. Nous sommes entrés dans une nouvelle ère des données. Les grandes organisations depuis quelques mois orientent leur stratégie vers ce que l’on nomme les données maillées. Petit focus sur cette nouvelle architecture, organisation, et les capacités associées. Les ères des données se suivent … mais l’une n’efface pas l’autre. Il est nécessaire de tenir compte de l’historique de construction des systèmes data dans le temps. Le poids de l’existant (services rendus, investissements, maintenance) est prépondérant. A chaque ère ses capacités, ses usages, et ses contraintes. Ère des données enfouies : Les données sont enfermées dans des traitements, elles sont uniquement connues au travers des traitements.  Les données ne sont pas gérées en tant que tel et elles peuvent être « oubliées ». Ère des données centralisées : Les données sont regroupées dans des entrepôts (Data Warehouse > Data Lake) Elles sont traitées par les équipes équipes BI et les Data Scientist (Big Data). Les métiers sont de plus en plus éloignés des données … et ils s’en écartent. Ils n’en n’ont plus la responsabilité. Ère des données maillées : Les systèmes de centralisation de données n’arrivent pas à répondre aux enjeux autour des données. Les paradigmes de data mesh, data fabric (au sens tissus) émergent pour répondre à cette situation.  Des plates-formes data en support au maillage émergent. www.orkestra-data.com

Ces dernières années, j’ai vu de nombreux projets Big Data qui, malgré les ressources disponibles, ne respectent pas les fondamentaux des best practices . Que ce soit : • En architecture de stockage, souvent mal conçue et peu scalable, • En distribution des applications, mal optimisée pour les grandes volumétries, • En modélisation des données, qui manque de structure et de clarté, • Ou encore dans le lien entre la data et le reporting, souvent flou et peu aligné avec les objectifs métiers. Et vous, partagez-vous ce constat ? 🤔

Comment modéliser ses métadonnées dans son data catalog ? Le choix du data catalog est fait … on découvre l’outil … aïe .. comment on va modéliser ses métadonnées. Je ne peux pas faire exactement ce que je veux, il manque une fonctionnalité, à quoi sert cette fonctionnalité ? …. On passe tous par cette étape où l’on se pose des tas de questions. Effectivement, on observe un manque de maturité général sur les data catalog concernant le glossary. cette couche métier qui permet de colliger les termes et concepts métiers, classifier, identifier les owners, les points de vérités, les points d’acquisition, les règles de gestion métiers, etc. La bonne méthode est de définir un modèle de métadonnées simple et d’enrichir, dans un premier temps, les informations importantes comme la définition des concepts métiers, le propriétaire de la donnée ou encore le point de vérité de la donnée. Il convient ensuite de définir des domaines métiers, une hiérarchie métier si besoin. Puis arrive la classification avec les tags, très pratique. Notre modèle est prêt, il faut l’enrichir. Il est conseillé de procéder par petites étapes, repérer les référents métiers pour valider les concepts métiers, les champions Data qui vont nous aider à promouvoir l’outil. Enrichir au rythme des usages délivrés, faire adhérer le data catalog métier par métier. #data #datagovernance #datacatalog

🔸 Rencontre avec Laure Gajetti, Data Scientist chez BIGSOOL 🔸 𝗣𝗼𝘂𝗿𝗾𝘂𝗼𝗶 𝗮𝘃𝗼𝗶𝗿 𝗰𝗵𝗼𝗶𝘀𝗶 𝗗𝗮𝘁𝗮 𝗔𝗰𝘁𝗲𝘂𝗿 ? 💬 "Après avoir lancé de nombreux projets de #data, nous nous sommes souvent retrouvés avec des résultats peu fiables ou de faible valeur ajoutée. La même problématique revenait sans cesse : la qualité des données, la connaissance fonctionnelle et technique des données, et la difficulté de maintenance due aux modifications des bases de données. Nous avons compris que le travail sur les données ne relève pas uniquement du service dédié, mais implique l’ensemble des collaborateurs de l’#entreprise. Il est essentiel de mettre en place une #gouvernance des données et de sensibiliser tous les acteurs métiers, ainsi que nos partenaires, à l’importance des données. 💪 Pour évaluer notre maturité en matière de gestion de la data en #interne, nous avons décidé de faire appel à Data Acteur". Découvrez l'entretien en intégralité 👉 https://lnkd.in/exUpShy8

🎯 [Big Data & Data Quality] – La qualité des données, une approche par étapes Quand on parle de data quality, la tentation est grande de vouloir tout tester, partout, dès le début. Mais si vous utilisez une architecture en médaillon (Bronze, Silver, Gold), il est essentiel de tester intelligemment. Pourquoi ? 👉 Chaque niveau dans la structure médaillon a un rôle précis : • 🥉Bronze : Données brutes, collectées telles quelles. • 🥈Silver : Données nettoyées et enrichies. • 🥇Gold : Données prêtes pour l’analyse et les KPIs. Tester la qualité des données doit donc être adapté à chaque niveau, sans alourdir inutilement vos pipelines. 💡 À chaque couche, ses tests spécifiques : 🥉 Bronze : Collecter, pas transformer À ce stade, les données sont brutes. ❌ Pas de tests de cohérence ou de relations complexes ici ! ✅ Tests de validité basiques : • Vérification des formats de fichiers (CSV, JSON, Parquet). • Détection des lignes corrompues ou illisibles. Exemple en PySpark : ➡️Vérifier si les colonnes attendues sont présentes if set(["id", "timestamp", "value"]).issubset(bronze_df.columns): print("Structure OK") 🥈 Silver : Nettoyer et enrichir La couche Silver est l’endroit idéal pour : ✅ Supprimer les doublons. (Test de uniqueness) ✅ Gérer les valeurs nulles. (Test de completness) ✅ Standardiser les formats. (une ingestion avec Metadata prédéfini ) ✅ Tester la cohérence des données ( Test de consistency => dates dans un intervalle, valeurs numériques positives, etc.). Exemple en SQL : ➡️ Afficher les doublons pour une colonne donne : SELECT duplicate_column, COUNT(*) AS occurrence_count FROM your_table GROUP BY duplicate_column HAVING COUNT(*) > 1; ➡️ Vérifier que les dates sont dans un intervalle : SELECT * FROM your_table WHERE date_column BETWEEN '2025-01-01' AND '2025-12-31'; 🥇 Gold : Tester les données métier La couche Gold contient des données prêtes à être utilisées dans les analyses et dashboards. Ici, les tests doivent valider : ✅ Les KPI et agrégats (totaux, moyennes, ratios). ✅ Les relations inter-tables (clés étrangères). ✅ Les seuils métiers (ex. : revenu mensuel > 0). Exemple en SQL : SELECT COUNT(*) AS total_sales, SUM(amount) AS total_revenue FROM gold_sales WHERE transaction_date BETWEEN '2025-01-01' AND '2025-01-31'; ⚠️‼️ L’erreur à éviter : Tester tout, tout de suite Par exemple, tester la consistency ou la cohérence métier sur la couche Bronze ? Mauvaise idée. 👉 Cela alourdit vos pipelines inutilement et peut ralentir vos traitements. Au contraire, adaptez vos tests : 🔹 Bronze = Tests basiques de validité. 🔹 Silver = Nettoyage et cohérence. 🔹 Gold = Validation métier et performance. Et si tu ne sais pas ce que c’est l’architecture médaillon, j’ai fait un post dessus ➡️ https://lnkd.in/eNHzTKi2

"Les data products et le golf ont un point commun : même avec la meilleure préparation, parfois ça finit dans le sable." ⛳️📊 ... Autant illustrer avec ses passions ... oui sur la photo c’est moi 😅 💡 Lors d’un retour d’expérience sur les data products, j’expliquai ainsi à un client que sans une gouvernance des données solide et une gestion rigoureuse des master data, il peinera à en délivrer la valeur. 🎯 La réalité rencontrée sur le terrain montre que lors d’un projet pour développer un data product, vous n’échapperez pas aux défis : 1️⃣ Des données dispersées et incohérentes ?  Les master data, comme les référentiels clients ou produits, sont-ils gérées différemment selon les équipes, entraînant doublons et des conflits ? 2️⃣ Du Manque de standards clairs ? Chaque système a ses propres règles, compliquant l’intégration et la fiabilité des données ? 3️⃣ Des Délais allongés ? Quels efforts à produire pour nettoyer et uniformiser les données, au lieu de développer des insights ? ⚒️ Les solutions à mettre en place ? 1️⃣ Centralisation des master data via un référentiel unique, accessible à toutes les équipes. 2️⃣ Mise en place d’une gouvernance claire : Rôles, responsabilités, et processus pour garantir la qualité et la conformité des données. Rôle de Data Product manager ? 3️⃣ Collaboration renforcée entre les équipes métiers et data pour aligner les définitions et priorités. 🚀 Les résultats sur les Data Products ? 1️⃣ 30 % de temps gagné dans votre déploiement. 2️⃣ Meilleure adoption par les utilisateurs grâce à des données fiables et compréhensibles. 3️⃣ Une capacité à répondre rapidement aux exigences réglementaires et aux évolutions stratégiques. 🎙️ Mes conseils complémentaires : « Voyez la gouvernance des données et des master data comme des investissements stratégiques pour pérenniser et amplifier la valeur de vos data products et surtout ne négligez pas la documentation dans vos outils de gouvernance pour en faciliter l’adoption. » ⁉️ Et vous, quelles leçons avez-vous tirées du déploiement de vos propres data products, quelles difficultés rencontrez-vous ? Les équipes Ishango (by Lamarck) seraient ravies d’échanger sur le sujet pour vous présenter nos méthodes et solutions sur la gouvernance des données et le data management ainsi que toute l’expertise de Lamarck Group sur les volets transformation par la technologie, l'innovation et les règlementaires ! Contactez-nous 😉 Quentin ROUSSEL Didier DUMONT Matysse Monbruno-Roy #GouvernanceDesDonnées #DataGovernance #MasterData #DataQuality #DataProducts #RetourDExpérience #TransformationDigitale

La promesse des 5 clés pour ouvrir les 5 verrous ⬇ La suite du précédent article https://lnkd.in/djMQZBXw 🔓 Verrou 1️⃣ La structuration de la donnée est le 1er verrou à lever. L’idée est bien de respecter les critères UCE que sont l’Unicité, la Complétude et l’Exactitude mais aussi CIA (Confidentiality, Integrity and Availability) au travers de l’élaboration d’un schéma relationnel des données (Master Data Model). La finalité de cet exercice est de de consommer des données fiables au travers d’un modèle pérenne et en appui à une structure générale des données de votre organisation. Garder en tête de concevoir ce modèle à l’architecture générale de l’entreprise sinon, vous n’en consommerez pas les avantages tels que l’optimisation des performances, l’amélioration de la qualité des données et la facilitation de la communication entre les parties prenantes. Cela peut sembler barbare et difficile à comprendre mais, vulgarisons le sujet 🔎 Comme je le mentionne à mes clients, il est question de représenter visuellement l’architecture des données et plus particulièrement de structurer les données dites de référence (Reference Data) aussi appelées données maîtres (Master Data). Si je me contente d’une définition, elle serait celle-ci : Ce sont des données partagées par l'ensemble des processus (souvenez-vous : https://lnkd.in/dfk6uiAe ) qui soutiennent l'activité courante d'une entreprise (ou plus généralement d'une organisation – rappel d’un précédent post : https://lnkd.in/dNaRg4xP ) et ses prises de décision. Ces données sont utilisées tant dans les applications opérationnelles (effectuant les différentes opérations courantes) que dans les applications de support (création/production de rapports, etc.) pour des prises de décision stratégiques. L'organisation et l'architecture de vos modèles de données sont basées sur les services composant l'entreprise : achats, produits, communication, marketing (clients, marque, packaging), R&D, juridique, commerce, logistique (en rappel de la chaine de valeur : https://lnkd.in/dDJR8CGa ) , … Mais, en pratique, comment je le traduis auprès de mes clients ❓ J’y reviendrai rapidement dans mon prochain post. Stay tune … #digitaltransformation #datamanagement #MasterDataManagement 

❓ La Data Lineage, vous connaissez ? ☝️ On peut aussi parler de traçabilité des données. 📊 Il permet de suivre, souvent graphiquement, tout le parcours des données depuis leur création jusqu’à leur utilisation. 👻 Il apporte de la transparence sur l’origine et les utilisateurs de la donnée. 👍 Il aide à identifier rapidement des erreurs ou anomalies dans les données. 🧨 Cette visibilité permet de connaître les différents impacts d’un changement sur la source ou un processus des données. 💰 Ce n’est pas toujours explicite, mais il est possible d’identifier des opportunités d’optimisation comme des processus en doublon. 👇 Pensez à aller visiter le blog (lien en commentaire) pour avoir plus de concepts en Data ! #data #conceptData