Data Legacy : les bonnes pratiques

0:14 Bonjour à tous et merci d'être venu aujourd'hui pour ce meetup Tech.Rocks. Je suis ravi d'animer ce meet-up autour de cette question, couramment abordée par les tech leads, la dette technique. Mais nous l'appliquerons aujourd'hui au monde de la data en parlant de Data Legacy. Pour me présenter brièvement, je suis Florian Baleil et je travaille en tant que staff data engineer chez Back Market. Bag Market, c'est une place de marché pour les produits reconditionnés qui sert d'intermédiaire entre particuliers et professionnels du reconditionnement. Les données sont cruciales car elles favorisent la vente des produits reconditionnés les plus fiables et ainsi prolongent la durée de vie en réduisant leur impact environnemental. Pour ma part, j'interviens au sein d'une tribu data qui est composée de trois équipes où nous rencontrons de nombreux challenges autour des données. En prenant en compte les 9 ans d'existence et le démarrage de notre stack sur une architecture monolithique, avec une base de données centrale, nous faisons souvent face à des gestions de nos données historiques dans notre hypercroissance. Particulièrement dans les projets de migration. Pour prendre un simple exemple, nous migrons vers une architecture orientée service où la production des données se décentralise avec la création de nouveaux modèles qui doivent cohabiter avec le bloc existant.

1:25 Il faut donc constamment adapter notre modélisation, la collecte, la transformation et l'exposition Liées aux données historiques. L'architecture évolue depuis le début et nous a fait grandir aujourd'hui à plus de 700 personnes, donc nous prenons soin du legacy car il reste le cœur de notre savoir pour prendre des meilleures décisions. Il faut aussi s'adapter rapidement de plus en plus à de nouvelles sources de données pour répondre à l'expansion géographique en Europe, aux US et en Asie. Et donc apprendre à gérer cette dette technique pour nous permettre d'avancer rapidement, tout en protégeant le savoir existant. Pour revenir à notre meet-up dédié aujourd'hui au Data Legacy, on va prendre le temps d'explorer les différentes formes prises par la technique dans la data, ses conséquences et ses coûts. Mais qu'est-ce que le concept de dette technique? C'est un vieux sujet inventé par Ward Cunningham, l'un des auteurs du Manifeste Agile. Il a dit que certains problèmes de code sont comme une dette financière. Une petite dette accélère le développement tant qu'elle est remboursée rapidement plus tard. Le danger survient lorsque la dette n'est pas remboursée. Chaque minute passée sur du legacy, compte comme un intérêt supplémentaire sur cette dette.

2:30 D'un point de vue des données, les conséquences peuvent être multiples. Nous allons le voir aujourd'hui. Il y a des coûts d'infrastructures de data qui peuvent s'envoler, un time to market qui grandit fortement, des données qui rendent les définitions business impossibles, voire peu fiables, ou même recevoir différentes réponses pour les mêmes questions, en perdre un peu la vérité. De manière très large, on peut voir des différents types de data techniques en data, de par sa structure même. Côté production de données, la structure des données n'est pas forcément adaptée, pas optimale ou pas standardisée. voire inexistantes par moment, ce qui conduit à une modélisation un peu complexe d'un point de vue consommation. On peut avoir des types de qualité de données, la qualité se dégrade et les informations sont peu cohérentes, manquantes ou fatalement plus disponibles. Et on a d'autres types, ainsi qu'avec la point de vue architectural, le système n'est plus performant, avec une nouvelle volumétrie, on ne s'adopte plus aux sources de destination, on a beaucoup de problèmes de disponibilité où cela revient très cher. Donc, du point de vue de la documentation aussi, ça peut être un type de dette dans la partie data qui décrit le besoin de savoir où provient cette donnée, qui sont les propriétaires ou qu'est-ce qu'elle veut dire, sont un challenge supplémentaire.

3:38 Mais il existe également, d'un point de vue sécurité ou légal, une dette qui peut risquer à avoir des fuites de données ou des attaques externes. Donc des adaptations légales sur la protection des données sont toujours recommandées. Plus qu'à particulièrement, nous nous poserons la question de savoir, avec nos interlocuteurs d'aujourd'hui, quelle est la particularité de cette dette dans le monde de la data? Comment la maîtriser en faisant des choix, d'expérimenter, de tester et de prendre des décisions de plus en plus rapidement? Si de nouvelles fonctionnalités sont nécessaires de toute urgence, alors peut-être vaut mieux accepter cette dette et la gérer le moment venu. Avec de plus en plus de production et de consommation de données, comment rendre visible cette dette pour décider de vivre avec ou investir dans une nouvelle solution? Dans un contexte où on parle de plus en plus de contrats et de qualité de données, en passant du big data au small data, comment s'assurer que les données produites sont de confiance, correctes, à jour et documentées? Quand il s'agit de créer une nouvelle entreprise ou faire face à l'hypercroissance, quels réflexes devons-nous adopter pour ne pas créer un futur data legacy ou manquer des opportunités liées à un manque de données historiques ?

4:43 Enfin, comment nous impacte financièrement ce data legacy, avec des coûts d'infrastructure de plus en plus importants, des solutions de plus en plus nombreuses? Bref, nous allons voir aujourd'hui comment diffuser toutes les bonnes pratiques, sensibiliser et convaincre le produit, la tech et le business d'agir collaborativement. pour la maîtriser. Pour échanger sur ces questions, nous serons ravis d'accueillir trois brillants speakers avec lesquels nous aurons un échange passionnant en toute transparence sur ce sujet pendant 30 minutes. À tour de rôle, pendant 10 minutes, nous aurons différents témoignages et camps concrets de la part de nos intervenants. Nous aurons le plaisir de commencer avec Claire Gouze, qui a débuté en data science chez BCG Gamma, l'entité data science du BCG. Elle est depuis deux ans Head of Data chez Sunday, où elle gère tous les aspects Data Engineering, Analytics et Data Product. Elle partagera avec nous la Valeye de régler cette dette technique et les enjeux de transformation vers une nouvelle plateforme. Ensuite, nous aurons le plaisir d'avoir Victor Cumer, qui viendra me rejoindre ensuite sur la scène.

5:44 Il a un parcours chez Veepee, il a travaillé dans différentes équipes analytics, sciences et gouvernance, avant de prendre en charge l'équipe Data Platform. Il viendra partager son expérience sur comment la stack a été transformée ces trois dernières années et comment ils ont géré leur legacy. Et enfin, à son tour, Edouard Ribes, avec plus de 10 années dans la tech et une expérience entre les US et en Europe, il est aujourd'hui CPTO de Manymore. Il échangera avec nous sur les différentes phases de gestion de la dette et comment il a géré sa croissance au sein de Manymore. Nous garderons 15 minutes pour échanger et répondre à vos questions à la fin. N'hésitez pas à utiliser le chat à votre droite de l'écran pour vous poser des questions. Et on se fera un plaisir d'y répondre à la fin avec les intervenants. Mais sans plus tarder, j'appelle notre première intervenante, Claire, à me rejoindre sur scène pour partager son... Témoignages chez Sunday. Bonjour à tous. Du coup, si je peux vous raconter un peu ce qui s'est passé chez Sunday. Je pense que quand on parle de data legacy, il y a deux façons de créer de la data legacy.

6:46 Il y a construire des solutions performantes. Obsolète dans le temps. Ça, c'est plutôt quelque chose qu'on va avoir dans des structures plus anciennes, notamment parce que les outils en data vont devenir rapidement obsolètes aujourd'hui. Et il y a une autre façon de construire de la dette, c'est de la construire, disons, dès le départ, c'est-à-dire construire des solutions en data qui vont être de base faites pour rester temporaires. Donc nous, chez Sunday, on est une startup qui a deux ans d'existence et qui va très vite. Donc pour la data aussi, ça doit aller très, très vite. Et quand je suis arrivée il y a deux ans, la stack n'existait pas et il a fallu centraliser les données, exposer les données au business sans forcément prendre le temps de poser les bonnes bases de la stack. Donc, du coup, pour répondre rapidement aux besoins du business, j'ai construit sur l'existant. Par exemple, j'ai construit sur les bases post-grès qui existaient. J'ai développé des ETL ad hoc pour chaque besoin d'ingestion.

7:48 Toujours dans l'optique de livrer rapidement, de livrer la semaine d'après. Et puis finalement, en fait, cette stack, elle a pris un mois à construire. Et au début, ça ne posait pas forcément de problème, cette stack un peu bancale. Mais petit à petit, en fait, comment est-ce qu'on l'a vu? On l'a vu parce que tout d'abord, il y a des problèmes de performance. Donc, plus on avait de données, plus on avait d'utilisateurs et plus, en fait, ça perdait du temps à tout le monde. L'équipe data prenait beaucoup de temps à produire cette analyse. Les équipes business prenaient 5 minutes à charger un dashboard. Et ça perdait beaucoup en productivité pour toutes les équipes. Et le deuxième impact que ça a eu pour nous, c'est aussi une perte en flexibilité. d'itération sur la stack, c'est-à-dire que dès qu'on devait faire une modification sur un champ, sur une ingestion, ça prenait deux semaines, alors qu'avec la stack qu'on a aujourd'hui, ça peut être fait en deux heures.

8:55 Et donc, on voyait ces impacts arriver petit à petit. Mais pour pouvoir s'attaquer à résoudre cette dette technique, le plus gros obstacle pour nous, ça a été de vraiment faire comprendre aux équipes non-tech l'intérêt de s'attaquer à cette dette technique. Et donc, ça passe par leur montrer très concrètement quels sont leurs pain points aujourd'hui. Et pourquoi c'est lié à la dette technique et pas juste à la non-performance de l'équipe data. Et donc, c'est leur parler de choses qu'ils connaissent. Par exemple, le fait que les dashboards... prennent du temps à charger, le fait que les datas ne soient pas consistantes entre plusieurs endroits, le fait que les reporting casse du jour au lendemain sans qu'on sache pourquoi, que ce soit eux qui nous préviennent quand un reporting casse. Donc, le plus compliqué, c'était vraiment de leur montrer tous ces pain points qu'ils avaient aujourd'hui et de leur expliquer que c'était lié à la legacy qu'on avait construite.

9:58 Et donc ensuite de... de les convaincre de nous protéger un peu de temps, parce que qui dit un peu résolution de la data legacy, dit on arrête la data legacy, on fait un feature freeze, et on prend le temps de travailler sur la nouvelle stack. Donc c'est ce qu'on a fait, on a imposé un feature freeze de trois mois à peu près, où on intégrait vraiment tout ce qui était très business critical. Et on travaillait, disons, à 80% du temps sur l'implémentation de la nouvelle stack. Et ça aussi, c'était aussi un gros challenge, c'est comment est-ce qu'on protège son équipe pour travailler sur la migration. Et comment est-ce qu'on assure la continuité entre la nouvelle stack et l'ancienne stack. Donc on a essayé de le faire le plus progressivement possible en débranchant des bouts par bouts l'ancienne stack pour pas qu'il y ait un bouton à appuyer un jour et tout est échangé. Et en fait, le jour où on appuie sur le bouton, On a juste supprimé l'ancien, mais la nouvelle stack était déjà fidée de façon indépendante.

11:08 Voilà, un peu l'expérience que j'ai eue sur la data legacy. Je ne sais pas s'il y a des questions. Super intéressant, Claire. Justement, quand tu parlais de rendre visible cette dette, comment vous êtes arrivé à la rendre visible d'un point de vue très concret? Parce que la data, c'est quand même très abstrait. C'est très difficile d'avoir des angles de vue différents dessus. Comment vous avez communiqué ça à différents parties prenantes? Il y a des façons très concrètes de le faire avec des chiffres, parce que nous, par exemple, on utilise Metabase en outil de visualisation et on peut sortir les données de chargement des dashboards. Donc, juste concrètement sortir le temps moyen de chargement d'un dashboard et de montrer, disons, aux gens du business combien de temps leurs équipes perdent à charger un dashboard, c'est assez parlant. Et une autre chose, c'est le business venait avec des projets et on leur disait, OK, si on le fait sur la stack actuelle, ça va nous prendre, disons, un mois. Et si on le fait sur la nouvelle stack, peut-être que ça nous prend un mois et demi.

12:11 Mais en fait, après... On pourra le faire en une semaine, le prochain projet. Donc, c'est vraiment prendre leur use case et leur montrer quelles auraient été les différences entre l'ancienne stack et la nouvelle stack. Super, Claire. Tu as pris l'exemple de Metabase qui permet de faire du easy dashboarding, en fait, simplement de partir de tout le monde, n'importe qui peut accéder et faire son dashboard pour avoir ses propres réponses aux questions. Comment vous vous êtes assuré de ne pas créer de la dette avec cet outil, en le mettant en place sur des données qui sont un peu brutes ou qui n'est pas de source de vérité commune? Oui, alors ça, ça a été beaucoup de travail en chambre, en fait, parce qu'avant, on était très open dans la façon dont on partageait la donnée, c'est-à-dire qu'on partageait la donnée de façon quasi brute. Et aujourd'hui, ce qu'on fait, c'est qu'on fait des choses. c'est qu'on filtre énormément ce qu'on partage aux gens non-tech. Ce qui fait qu'en fait, on leur met des barrières desquelles ils ne peuvent pas dépasser. C'est-à-dire, par exemple, on a un KPI principal qui est l'adoption de notre solution et il faut faire beaucoup de nettoyage sur la donnée avant de le calculer.

13:18 Ce qu'on fait, c'est qu'on pré-nettoie toute la donnée et qu'on leur met à la disposition que la donnée pré-nettoyée. Ce qui fait que n'importe qui dans l'entreprise peut calculer le KPI et on sait qu'il aura le même chiffre que son voisin. Du coup, les gens créent beaucoup sans limite. Ils ont accès à tout, mais en chambre, on fait le nettoyage qu'il faut avant. Super, Claire. C'est parfois difficile un peu d'investir du temps pour faire une nouvelle solution. Comme tu l'as dit, il faut essayer de convaincre, il faut essayer de rendre visible cette dette technique. Aujourd'hui, basé sur ce constat, après avoir délivré la nouvelle plateforme, quel est le retour que vous avez en interne des usages, de la manière dont vous travaillez maintenant? Je pense que sur le moment, effectivement, ce travail a été mal compris. Mais qu'avec le recul, on a eu plutôt des retours positifs. Et c'est gratifiant pour l'équipe parce qu'on a quand même passé beaucoup de temps en chambre. Ce n'est pas forcément du temps intéressant de faire cette migration. On n'est pas forcément très content de le faire non plus, mais on le fait. Et à la fin, en fait...

14:19 Ce qui a été très visible par les équipes, je pense, c'est un, la rapidité de la nouvelle stack, donc d'avoir un dashboard qui charge une seconde au lieu de 10 secondes. Et deux, Et deux, aussi la facilité d'utilisation de la nouvelle donnée, parce qu'on a fait en sorte que ça apporte de la valeur au business et pas juste à nous. Et donc tout ce sujet dont je parlais de cleaner la donnée, simplifier la donnée, ça a beaucoup aidé le business qui maintenant peut faire des queries en autonomie sans réfléchir trop à tous les filtres à faire, etc. Donc on a eu des retours assez positifs. Sur le côté user-friendly de la donnée qu'il y a. Super clair. Et du coup, qu'est-ce qui aurait pu arriver, à ton avis, si on n'avait pas géré cette dette technique de votre côté? Quel scénario aurait pu être possible? Une dégradation, un arrêt de disponibilité des données? En fait, c'est simple parce qu'on l'a vu arriver. C'est-à-dire qu'on a eu un truc assez magique du...

15:22 Je pense que le jour où on a débranché nos anciens ETL, et brancher sur les... Enfin, on ne les avait pas débranchés. On avait toujours nos anciens ETL qui filmaient les bases post-grès et on avait réussi à brancher en parallèle les nouveaux ETL. Et tout d'un coup, l'ETL a cassé. Et c'était un ETL sur une cloud function Google et on ne comprenait vraiment pas pourquoi ça cassait. On allait dans les logs, on ne comprenait pas. Et surtout, c'était un problème qui était arrivé avant, qui s'auto-résolvait. Il arrivait de façon de plus en plus récurrente et on ne savait pas comment le résoudre. Et le moment où on a branché le nouvel ETL, en fait, juste le truc, c'est plus jamais auto-résolvable. Donc, concrètement, si on n'avait pas résolu cette dette technique à temps, oui, il y aurait eu des données qui n'auraient plus été disponibles. Il y aurait eu une rupture de service pour le business. Ok, on a une question du chat, juste avant d'accueillir Victor. Tu parlais d'un legacy du nouvel stack, est-ce que tu pourrais nous donner plus d'informations sur l'ancien et sur la nouvelle stack que vous avez?

16:23 Oui, alors avant en fait on avait nos datas qui étaient stockées dans des bases post-grès, L'ingestion et la transformation se faisaient par des ETL Python codés un peu maison qui tournaient sur des cloud functions. C'était quand même assez maison et rudimentaire. Et maintenant, ce qu'on a, c'est de l'ingestion qui est faite par Airbyte, toute la donnée qui est stockée sur BigQuery et les transformations qui sont faites par dBt. Du coup, c'est vraiment des outils quasi no-code, ce qui fait que nous, on itère beaucoup plus vite, qu'on peut livrer beaucoup plus vite au business et tout est très performant. Ok, ce qu'on appelle un peu communément la moderne data stack, avec les différents composants. Super, merci Claire. Tu peux rester avec nous, on va accueillir Victor pour son témoignage chez Veepee. Vous m'entendez bien, ça fonctionne? Hello Victor. Hello, bonjour à tous. Je vais commencer par le même sujet, la question d'avant.

17:28 Je vais expliquer un peu ce qu'on avait chez Veepee il y a trois ans, ce qu'on a maintenant. Et mon idée, c'est de montrer tout ce qui a pu se passer au milieu et tout le legacy que ça a pu... Que ça a pu générer. Et moi, je m'occupe plus particulièrement de la plateforme chez Veepee, donc des questions plutôt d'ingestion de données ou de mise à disposition derrière au reste du monde, donc les produits qui veulent consommer la donnée consolidée ou des produits externes. Donc, on reviendra un peu plus... Sur ce thème-là et sur le Data Legacy, dans ce genre d'équipe. Veepee, il y a trois ans, c'était aussi une base post-grès au centre de tout ce qu'on faisait. On travaillait sur Green Club. C'était quelques algorithmes de machine learning qui fonctionnaient sur des machines GPU maison et des procédures SQL qui étaient orchestrées via Informatica. On utilisait Informatica pour sélectionner la donnée, pour la transformer éventuellement via ces procédures et on faisait tout ça dans Green Club.

18:34 Globalement, la data, c'était une grosse équipe BI qui gérait tout. On avait, pour donner des chiffres, 75 Teraoctets de données stockées. Donc, ce n'est pas énorme. Ce n'est toujours pas énorme ce qu'on fait chez IPI, mais on est passé, avec notre nouvelle infrastructure, à 600 Teraoctets. De données. Donc, on a multiplié par 10. La nouvelle infra, c'est quoi? C'est du full GCP. On fait du cloud. Donc, c'est BigQuery au centre de tout ce qu'on fait. Évidemment, toutes les API, que ce soit pour les produits de machine learning ou pour les produits d'ingestion ou d'extraction, ça va tourner sur Kubernetes, sur GKE. Et on schedule le tout avec, pour ce qui est des transformations DBT, mais la partie scheduling, c'est du Airflow. Donc, Composer chez Google. Tout le pipeline, ça va être Dataflow, les outils managés Google. Est-ce qu'on a mis en place Multiplier ce qu'on faisait avec notre donnée par 10, non, pas vraiment.

19:38 En termes de ce qu'on faisait avec notre donnée. Si, en réalité, on a multiplié les usages, les use cases. Aujourd'hui, on a plus d'une dizaine de produits, vraiment machine learning, data science, beaucoup, beaucoup de use cases côté analytics. Et évidemment, une partie BI, donc vraiment la partie data visualisation, qui n'a rien à voir avec ce qu'elle était avant, puisque maintenant, on a un concept de self-service où en fait, on va essayer d'accompagner les... On a plus de 1200 personnes qui sont consommateurs de micro-stratégie, notre outil BI chez Veepee, et qui vont aller eux-mêmes construire leur propre dashboard. Il y a vraiment une question de faire monter en compétence sur la connaissance de la data et ce à quoi ils peuvent accéder. Contrairement à avant où on faisait les dashboards pour eux et les équipes BI créaient les dashboards pour les équipes d'études. Bref, donc la partie source, production de la donnée, elle n'a pas été multipliée par 10. C'est là où je voulais en venir. En réalité, on ne fait pas 10 fois plus de visiteurs qu'il y a 3 ans ou on ne fait pas 10 fois plus de colis dans les entrepôts, donc on ne génère pas 10 fois plus de données.

20:39 Par contre, nos usages et ce qu'on fait de la donnée a complètement explosé avec la nouvelle stack. Pareil, les équipes qui gèrent tout ça ont complètement changé. On est passé, comme je disais, d'une grosse équipe BI à, on a entre 50 et 60 experts data chez Vicky, sur six périmètres, de la partie factory, qui gère vraiment les applications d'ingestion et d'extraction, les parties transverses comme les SRE, qui vont être spécialisées plutôt sur le GCP, et après les équipes de transformation, donc la gouvernance qui va s'occuper vraiment de la transformation, la partie modélisation de la donnée, la partie qualité, la partie documentation de cette donnée-là, les équipes BI qui vont faire la partie d'exporting, et derrière, ce qui apporte la valeur ajoutée, data science, et bien que le reporting soit aussi évidemment la valorisation de la donnée, mais derrière, ce qui va permettre d'augmenter les taux de conversion, les visites. donc les algorithmes de data science, et les analyses sur les ADTS qui sont menées par les data analysts. Donc en trois ans, on a changé beaucoup de choses, on a changé les gens, on a changé les outils, les gens, je veux dire les compétences, les métiers qu'on a, ils sont profondément transformés.

21:48 Et ce sujet d'aide technique appliquée à la data, évidemment, il est omniprésent chez nous à tous les niveaux. Quand on reprend le software Capmonchip, la dette, c'est vraiment le code qu'on a livré et sur lequel on sait qu'on va devoir revenir. Donc, la dette, elle va être partout, en réalité, dans ce dont on hérite, le code qui a été développé il y a quelques années, celui dont on hérite de quelqu'un d'autre, celui que nous-mêmes, on a fait il y a quelques temps, et aussi celui qu'on écrit en ce moment, parce qu'on sait que c'est une solution temporaire ou parce qu'on sait que ce n'est pas quelque chose qui est drivé par un besoin un peu business ou imminent et que du coup, on a une solution temporaire. Donc, on sait qu'on est en train d'écrire de la dette technique. Appliquer à la data, au monde de la data, ça se traduit comment? Des pipelines qui vont sourcer des tables ou des producteurs de données qui sont temporaires.

22:51 Ça peut se traduire sur l'aspect transformation, où on va aller faire des transformations ad hoc pour répondre à un besoin spécifique. ou pour mettre des règles de calcul un peu à la volée pour répondre à des problèmes de qualité. Et sur la partie machine learning, ça pourrait être des règles, pareil, déterministes qu'on va aller appliquer en entrée de nos données ou en sortie de nos algorithmes pour revenir un peu à la réalité et contraindre un peu pour des sujets de forecasting, de prédiction, pour revenir sur des choses plus réalistes, plus proches du business. Encore une fois, pas lié à des problèmes de qualité de la donnée. Chez Veepee, on a eu tous ces problèmes-là, évidemment, comme je pense partout, chez Florian ou Claire. Par exemple, sur la partie machine learning, on se retrouve à avoir, par exemple, développé des algorithmes en parallèle de la transformation de toute la stack. Mais quand on fait ça, les besoins business, malheureusement, n'attendent pas. Donc, on se retrouve à développer beaucoup de choses en parallèle, en termes de sources, en termes de transformation.

23:54 On déduplique les mêmes transformations sur les mêmes entités données. On ne fait pas forcément la même chose. On a des règles de partout. Et en fait, quand on multiplie ça à l'échelle des produits, à l'échelle des entités de données qu'on peut avoir, ça devient vite un problème. Et tous les mois, on fait des dizaines et des dizaines de choses spécifiques ou ad hoc qui vont s'additionner les unes avec les autres. Donc, évidemment, le temps, tu parlais de time to market tout à l'heure, Florian, le time to dashboard, on va dire, pour une entité de données, il est énorme. Il est de plus en plus long. Sur la partie ingestion, La dette, elle va se traduire sur… Chez Veepee, par exemple, on a fait beaucoup d'acquisitions en Europe. Donc, des systèmes différents, c'est du commerce, mais des systèmes différents, des modélisations différentes, des produits software qui généraient des entités qui n'avaient pas vraiment la même structure. Je crois que tu en parlais aussi tout à l'heure, Florian, quand vous vous retrouvez à avoir des sources dans différents pays, dans différents continents.

24:57 Chez Veepee, on n'est pas encore concerné. Donc, pour l'instant, Ça, on fait tout dans une zone Europe, mais on va avoir différents systèmes qui produisent des choses qui sont techniquement différentes ou structurellement différentes, mais qui ont la même valeur pour le business. Des produits, des stocks, des commandes. Et donc derrière, on va évidemment créer plein de legacy pour avoir toutes les règles qui vont nous permettre de mapper le legacy avec la target, la modélisation cible. Mais il faut-il encore avoir une modélisation cible qui correspond et qui va avoir une vision assez large pour être pertinente sur plusieurs années. Super intéressant, Victor. Il y a un point dans la partie, dans ce que tu expliquais, on a parlé beaucoup de nouveaux outils avec Claire sur comment ça pouvait améliorer, réduire le time to market. Il y avait une partie aussi sur la partie organisationnelle. En fait, les personnes, comment on fait pour des compétences, des équipes qui travaillent sur un legacy, une certaine expertise, comment arriver à les convaincre ou les former pour aller sur une nouvelle technologie comme GCP ou autre, ce que vous avez fait chez Veepee?

26:10 C'est particulier. Sur une équipe comme on a aujourd'hui, on va avoir des personnes qui ont des compétences très différentes. Pour faire un changement global de toute la stack, en réalité, ça va impliquer un peu tout le monde, mais en même temps, on ne va pas révolutionner les méthodes. C'est-à-dire qu'on va changer. J'ai des outils, mais globalement, les choses, c'est-à-dire qu'on fait toujours des transformations SQL, DBT aujourd'hui, c'est de l'orchestration de requêtes SQL. Quand on orchestrait des procédures post-grès, des procédures SQL avec Informatica, fondamentalement, c'était la même chose. Donc derrière, il faut montrer la valeur. On a parlé de montrer la valeur au business en termes de réduire le temps pour charger les dashboards. La technologie de stockage qui est derrière va être plus efficace. Donc oui, c'est pertinent de changer. Nous, ça peut être la même chose. DBT, c'est un outil qui a en termes de facilité, de thèse, d'amélioration de la qualité, de temps de développement qui est beaucoup plus pratique, beaucoup plus facile qu'Informatica ou qu'orchestrer des procédures sur une base post-grès.

27:20 Donc, il y a l'aspect, techniquement, la vie va être plus facile pour les développeurs. Après, les performances sur une stack cloud comme GCP sont largement principales quand on veut faire du machine learning. La question se pose très peu. Il y a un aspect intéressant pour revenir sur ce que moi, je fais plutôt la partie factory, on va dire expertise cloud, c'est que quand on va faire tourner des algorithmes ou des produits dans Kubernetes, avoir une expertise cloud là-dessus, ça permet aussi de délester un peu les équipes qui ont une valeur ajoutée sur la modélisation ou sur vraiment la connaissance de la data et de leur enlever cette partie de machine learning. La question se pose très peu. Il y a un aspect intéressant pour revenir sur ce que moi, je fais plutôt la partie factory, on va dire expertise cloud, c'est que quand on va faire tourner des algorithmes ou des produits dans Kubernetes, avoir une expertise cloud là-dessus, ça permet aussi de délester un peu les équipes qui ont une valeur ajoutée sur la modélisation ou sur vraiment la connaissance de la data et de leur enlever cette partie.

28:00 Il faut derrière administrer le système, faire tourner ces choses-là en production, avoir du monitoring. On peut aussi les convaincre là-dessus. Oui, exactement, totalement d'accord avec toi. C'est vrai que, comme tu le disais, en fait, on monte en abstraction, mais les concepts et l'engineering qui est fait d'un point de vue data est assez vieux. Le fait qu'on passe sur des services plus ou moins managés avec différents niveaux de disponibilité et un peu plus à jour fait qu'en fait, on maîtrise. Donc, les personnes changent juste et se concentrent plus sur là où c'est cœur, la modélisation, la connaissance de l'entreprise. Le cœur de métier en fait, davantage qu'aller dans les profondeurs, mais si le profondeur est géré, il faut juste avoir cette volonté et cet engouement de changer de technologie. Après, on est dans un domaine, comme vous le disiez, où ça change énormément, il faut forcément avoir des gens qui ont une appétence pour aller chercher les nouvelles technologies, les appréhender, les tester et les mettre en place. Même si les concepts n'évoluent pas fondamentalement, quand même les outils évoluent beaucoup.

29:02 Exactement. L'écosystème est très large et il faut être curieux en data, c'est vrai que c'est un prérequis. Merci, on va accueillir, tu peux rester avec nous Victor, on va accueillir Edouard qui va nous présenter son témoignage. Merci Florian et bonjour à tous. Donc nous, côté Manymore, en fait, la partie Data Legacy, on y a été assez confrontés par rapport à ce que disait Claire sur une forme d'obsolescence dans le temps. Alors pourquoi? En fait, notre projet, il n'est pas si vieux que ça. Finalement, il a peut-être 3-4 ans. Et en fait, on a été face à une croissance assez forte. En fait, on est passé de 10 à 80 sur les deux dernières années et demie. Alors en fait, au démarrage, on était une petite boîte, on faisait plutôt de l'algo en finance, des outils de productivité pour des conseils financiers, en gros pour qu'ils puissent distribuer plus facilement des choses comme des assurances, des PVR. Et très vite, on s'est rendu compte que pour croître, il faudrait qu'on diversifie un peu notre portefeuille. Et c'est là où on a commencé à rentrer. dans de la data. Parce qu'en finance, c'est très bien de faire un petit peu d'algorithmie, des produits de recommandation et autres, mais on a un gros enjeu qui est la consolidation de données financières à partir de sources multiples.

30:12 C'est quelque chose qu'on retrouve dans le domaine de l'investissement, qui est le nôtre, dans le domaine du prêt, dans le domaine de l'assurance. Pour faire ça, ce qu'on a fait, nous, c'est qu'on a fait du M&A. Donc on a rejoint une autre structure qui était plus grosse que nous d'ailleurs, qui nous a porté justement à 60-70. Et on a fait ça il y a maintenant deux ans. Quand c'est arrivé, on a rencontré dans cette boîte-là, une boîte qui avait 10-15 ans d'existence et qui avait un portefeuille un peu ancien. Je pense que ça parlera à certains d'entre vous. On avait pas mal de surprises finalement qu'on n'avait pas forcément vu dans la partie du diligence. Alors la surprise principale sur la partie Data Legacy, ça a été, on avait un produit data. Alors déjà on avait une chance, on avait un produit data. C'est-à-dire qu'en fait on vend de la donnée agrégée et consolidée à un modèle unique à nos clients. Avec un modèle de pricing, tout ce qui va bien. Et alors, quelque part, jour 1 officiel de la fusion, on ouvre notre modèle de support, on se dit, tout va bien. En fait, le modèle de support était en train d'exploser. L'outline, chez nous, avait 10 000 à 15 000 appels juste parce que la donnée, sa qualité, était complètement foireuse.

31:19 Bon, voilà, petite surprise du legacy au journal de la fusion, c'était ravissant. Bon, ça se traduit aussi par des problématiques comme quoi après on a du churn sur nos clients et ce genre de choses. Mais en fait, fondamentalement, ce qui se passait, C'était quelque part, en fait, la partie data et le produit associé, c'était un petit peu endormi. En fait, on avait une accumulation de bugs au fur et à mesure du temps. En fait, sur de l'ETL, ça consiste à quoi? C'est que les flux ETL sont cassés ou en tout cas, ne sont pas rétablis suffisamment rapidement pour assurer une continuité de service. Ça faisait que nos clients étaient assez peu ravis, si on peut dire comme ça. Donc l'année, en fait, ça, on a vu ça, du coup, il y a deux ans. L'année 1, en fait, de la fusion, ça a été une période d'assainissement. Donc, en fait, on a formé une forme de gouvernance donnée, assez spécifique, dans laquelle, voilà, l'enjeu 1, c'était régler le backlog de bugs, si je peux dire comme ça, faire en sorte qu'on ait un index de qualité, un premier index de qualité qui soit à peu près propre. Et arriver à piloter l'année comme ça. Ce qui est intéressant, c'est que finalement, cette affaire-là nous a amené à réassainir non seulement un petit peu notre produit, donc maintenant il est stable, ça va à peu près, mais ça a donné lieu à la génération d'un produit supplémentaire, parce qu'en fait, on a fabriqué un produit de qualité des données.

32:27 En fait, on vend à nos clients de la mesure de qualité aujourd'hui, en plus de la data en elle-même. En fait, c'est une opportunité qui est peut-être un peu spécifique à notre milieu, mais en fait, ce qu'on fait fondamentalement, c'est qu'on agrège des informations sur des contrats financiers. De plein de sources différentes. Et quand on fait ça, on est capable de mesurer la qualité de la donnée que nous fournit une banque. Vous prenez un contrat financier qui a 10 ans, dans lequel un individu a fait des versements, des arbitrages, enfin tout un tas de trucs. En fait, on est capable de dire aujourd'hui assez finement si la banque n'a pas réussi à rétablir l'historique. Du contrat. Et en fait, pour un conseiller financier ou un broker qui, en fait, est notre client final, ça a pas mal de Valeye parce qu'en fait, c'est là-dessus que lui peut faire des recommandations ou doit faire des activités réglementaires. Donc, s'il est capable, en plus d'avoir la donnée, d'avoir un index de si, en fait, ses décisions sont probablement éclairées ou pas, ça a de la Valeye. Donc ça, c'était un peu un truc intéressant qui est sorti. Et aujourd'hui, dans la transformation, on est sur une phase où on a relancé de la croissance sur ce type de produit.

33:29 Parce qu'une fois que la base est assainie, qu'on a un index de qualité, qu'on est à peu près plus stable, on a refinanciarisé quelque part complètement notre produit, notre façon de faire. Et on se dit, si on veut croître, si on veut rajouter des partenaires, si on veut rajouter de l'infrastructure, on a complètement revu notre structure de pricing. Et on est capable d'identifier aujourd'hui sur le marché quels sont les gens qui seraient intéressants pour nous d'agréger, autant dans notre cœur de métier, pour finalement faire plus de chiffres et d'être capable de prioriser tout ça. Et en fait, en fur et à mesure, ce qu'on est en train de piloter maintenant, ça nous permet non seulement de croître, mais aussi de professionnaliser nos équipes. Parce que ce qu'on a fait en arrière-boutique, c'est que du coup, on a reségmenté quelque part la connaissance en fonction de, quelque part, nos périmètres d'agrégation. Et on a fait des sous-équipes. On va être un peu comme des feature teams, mais plutôt orientés data chez nous. Et donc ça, c'est un peu l'enjeu, c'est d'arriver à bien asseoir ça cette année. Et ce que j'espère, c'est que l'année prochaine, du coup, dans cette transformation, non seulement la legacy sera quelque part un peu...

34:30 derrière nous. Mais ce que j'aimerais aussi, c'est que le système en tant que tel soit un petit peu autogénératif et autonome, c'est-à-dire que finalement les équipes soient capables de tout autoprioriser. S'il y a un petit peu d'évolution à faire, parce qu'il y a de la maintenance sur typiquement nos stacks, c'est pas mal de MariaDB sur lequel on pond du SQL custom. En fait, on a des problématiques qui sont plutôt, on va dire, sympas. C'est-à-dire que nous, on n'a pas trop de problèmes de performance. En fait, tous nos calculs doivent tourner plutôt la nuit. Donc, si ça tourne en moins de 7 heures, on est à peu près ravis. On va dire ça comme ça. Donc, grosso modo, qu'ils puissent arriver à faire un petit peu leurs optimisations eux-mêmes de manière autonome sur ces contraintes horaires-là. Et voilà, donc c'est plutôt vers ça qu'on va. Et finalement, nous, la façon dont on a géré, en résumé un peu le legacy, c'est plutôt essayer de comprendre quel a été notre problème de fond, l'objectiver un peu d'un point de vue avec beaucoup de métriques business, faire remonter le plus haut possible quelque part dans notre chaîne hiérarchique, et puis on l'adresse un petit peu progressivement, étape par étape. On traite la base, on assainit, on met un peu de métriques de qualité, on met des métriques de croissance en fait derrière, pas mal financières, et puis après on essaie de rendre le système autonome.

35:36 Merci pour le partage, super clair. La question qui me vient, c'est est-ce que tu crois qu'en étant dans un milieu de la finance, la discussion autour du legacy et de l'impact financier de cette dette-là est plus facile dans une entreprise plutôt qu'une entreprise dans un autre secteur? Je pense que oui, parce qu'en fait, de par nos business models en finance, la donnée est quelque chose qui vaut très très cher, qui est un peu au centre de l'attention, donc ça c'est un plus. Ça vient avec aussi quelques contraintes, parce qu'on est énormément sujet à de l'audit de la part de nos clients et des institutions de place. Je pense que c'est vrai que la finance est un petit peu spécifique à ce niveau-là. Super clair. Donc, on a vu différents points de vue sur Data Legacy avec vous trois. Et je trouvais ça intéressant que vous nous partagiez comment vous avez vu le legacy émerger.

36:37 Et devoir raconter le fait qu'en fait, avec un rachat, on pouvait s'apercevoir qu'il y avait... Certaines contraintes qui apparaissaient. Claire, avec la partie nouvelle stack, l'ancienne qui devient très longue d'un point de vue title market. Claire, qu'est-ce qu'il y a des éléments, les premiers détecteurs que tu pourrais conseiller à la communauté pour dire attention, dans cette partie-là, peut-être qu'il y a du data legacy. La première chose visible, ça a été de par les utilisateurs. Donc, on est dans la même salle que tout le monde et tout le monde se plaint tous les jours que le dashboard prend trop de temps à charger. Donc, ça, c'est un peu un... On n'a plus envie d'entendre ces plaintes et qu'il faut qu'on agisse. Et après, quand on se rend compte qu'on devient vraiment un bottleneck pour le reste de l'entreprise et que notre stack actuel nous empêche de scaler, là, on se dit qu'il faut agir parce que sinon, on devient vraiment trop bloquant. Et c'est vrai que nous, on avait beaucoup de features qui se développaient, beaucoup de nouvelles sources de données qui allaient arriver.

37:42 Et en fait, on prenait les sujets un à un. Et on était très lent par rapport au reste de l'entreprise. C'est un peu comme ça qu'on s'en est rendu compte, quand on s'est rendu compte qu'on était un bottleneck pour... Pour le reste. Question de la communauté, on parle beaucoup de dette technique ou de différents aspects pour la gérer. En bonne pratique, est-ce que vous avez des exemples de guidelines que vous donnez dans vos équipes pour plus générer justement de la nouvelle dette sur la nouvelle stack? Parce qu'on peut rapidement arriver sur une nouvelle stack et finalement recréer rapidement de la dette. Quelles sont les bonnes pratiques que vous pourriez partager aujourd'hui? Tu peux peut-être enchaîner si tu veux. Je pense qu'il y a beaucoup de choses du software craftmanship ou du manifeste agile qui peuvent vraiment s'appliquer, copier-coller au monde de la data. Quand on dit que la dette technique apparaît, quand on sait qu'on va devoir changer quelque chose, que c'est un problème, approcher les problématiques par le test, c'est une première solution.

38:49 Savoir avant de développer un nouveau pipeline, une transformation, on peut le tester, savoir ce qu'on veut tester, savoir où sont les... Quel est le ratio? Quelles sont les valeurs limites à ne pas atteindre? Voilà, c'est des manières d'approcher le développement qui existent depuis très longtemps dans le monde du software engineering et qui, côté data, parce que dans la data, il ne faut pas s'en dire, on a beaucoup de profils qui ne sont pas... Qui n'ont pas une culture software engineering. Et en fait, c'est des concepts qui ne sont pas encore, je trouve, Ce sont des outils qui ne sont pas encore très présents. Des concepts classiques d'approche par le test, le monitoring, vraiment, c'est des choses... Classique et qu'on doit encore appliquer. Mais les équipes, de manière générale, et Claire, arrête-moi si je me trompe, surtout côté analytics, je trouve, sur la dernière année, ou sur les deux dernières années, ont vraiment changé. C'est beaucoup plus technique qu'avant. Les gens savent faire beaucoup plus de choses techniquement, sur l'aspect code.

39:52 Donc, on parlait des outils de no-code. D'ailleurs, il y a une question dans le chat là-dessus. Mais en réalité, j'ai l'impression qu'en termes de compétences, Les gens sont de plus en plus techniques dans le monde de la data. C'est un très bon point, on le voit sur la partie data analyst et l'introduction du rôle d'analytics engineer. Il y a un data analyst qui s'est inspiré du cloud-facramachip, du software engineering, des bonnes pratiques pour versionner, pour mettre quelque chose à l'échelle en fait. On a un peu le même phénomène aussi quand le cloud est arrivé et toute l'infrastructure a ce code, comment tester ce code-là, parce que du coup l'infrastructure devient du code, comment le tester, comment tester notre infrastructure. Donc on a eu ce mouvement aussi d'un point de vue data avec cette notion de data ops où on récupère un peu aussi la partie opérationnelle du cloud. Donc oui, il y a beaucoup de bonnes pratiques dans ce sens-là. Le software cardmanship peut être appliqué à de nombreux domaines. Le fait que la data soit un peu de côté, finalement, on peut s'inspirer de ces bonnes pratiques pour les mettre en place dans notre domaine et tester nos modèles, tester la donnée en entrée, en sortie et voir comment ça se comporte.

40:55 De la même manière que typiquement l'infrastructure ou les SRE auraient le chaos engineering, essayer de bouleverser un peu la plateforme pour voir comment elle répond, ce qui est tout à fait le cas, notamment quand les données prennent des formes différentes, une volumétrie différente, des formats qui changent, etc. C'est bien d'avoir ces tests qui protègent et qui évitent de créer du legacy. Est-ce que vous avez d'autres guidelines que vous avez, d'un point de vue analytics, Claire, de ton côté, sur DBT ? Est-ce que vous avez une façon de travailler sur cet environnement-là pour s'assurer que DBT, il n'y ait pas plusieurs DBT, qu'il n'y ait pas un gros DBT qui bloque tous les modèles? Est-ce que vous avez réfléchi à ces aspects? On a pas mal réfléchi à ces aspects, d'autant plus qu'on a fait le choix d'ouvrir notre stack data à l'ensemble de la tech. Parce qu'aujourd'hui, on a nos équipes tech qui poussent de la donnée sur des BT pour pouvoir l'exposer dans une application par la suite ou pour pouvoir nous fournir la donnée.

41:59 Donc, ça nous a un peu bousculé dans la création de guidelines, parce qu'avant, on n'était pas nombreux, donc on faisait ça en bonne entente, on va dire. Et donc là, ça nous a obligés à préciser nos guidelines. Mais je dirais que c'est quand même quelque chose d'assez compliqué, parce que c'est un domaine où il y a encore assez nouveau, finalement, le data modeling, et où il n'y a pas, disons, de one way to do. Il n'y a pas un bouquin qui explique comment il faut faire pour tout le monde, toutes les entreprises, tous les use cases. Et du coup, on apprend un peu en faisant. Donc, on développe des choses. Parfois, ça devient un peu trop complexe et on se demande ce qu'on a mal fait. Et on établit des guidelines pour corriger ce qui a été mal fait dans le passé. Donc, je dirais qu'on a des guidelines. On a, par exemple, Par exemple, un Ocean avec des bonnes practices de naming, de modeling. Mais on est toujours obligé d'en rajouter quand on voit qu'on arrive à quand même construire de la legacy sur le modeling dessus.

43:05 Je vais peut-être rajouter une chose assez concrète qui me vient à l'esprit sur ce qu'on essaie de mettre en place, nous. Airflow, c'est un outil qui est utilisé beaucoup dans la data pour orchestrer les transformations, la gestion, etc. Nous, en l'occurrence, on orchestre DBT et les requêtes DBT avec Airflow. Nous, on essaie d'avoir une équipe transverse, qui gère par exemple un monorepo Airflow, pour éviter d'avoir différentes équipes. Quand on travaille avec Airflow sur GCP, on utilise Composer, donc on pousse tous nos DAGs, tous les scripts vers un seul et même bucket. Ça, c'est un exemple très concret de choses. On peut mettre des guidelines en place pour aligner les différentes équipes qui vont toutes avoir besoin, toutes les équipes d'attaque, que ce soit science, analytics, BI ou l'aspect transformation, gouvernance, ils vont tous avoir besoin au moment d'orchestrer quelque chose. Ils vont devoir utiliser Airflow. Ils ont des niveaux technistiques qui sont plus ou moins différents. Donc, mettre en place des guidelines et éviter que ça parte en branche sur des différents projets, différents repositories qui sont hébergés à droite à gauche, ça permet de garder le contrôle un peu sur ce qui se passe

44:16 et d'assurer qu'on ne crée pas trop de dégâts. Exactement. Et pour revenir sur Airflow, c'est un très bon exemple, à vrai dire. C'était un outil qui a été créé par Airbnb dans une communauté un peu de data qui a été open sourcée et qui était très difficile à maintenir. Je me rappelle des premiers decks, justement, des premières créations de ces schedulers qui étaient vraiment difficiles à obtenir. Et on a eu différentes plateformes qui, comme tu le cites sur GCP Cloud Composer, Cloud Composer, c'est juste un Airflow managé. Donc, c'est enlever toute la gestion de l'infrastructure, la scalabilité, etc. Et de le gérer par GCP et de se concentrer sur nous, ce qu'on veut faire d'un point de vue d'ag en Python, donc avec ces schedulers qui vont piloter. Donc ça, c'est vraiment un changement et en effet, un Airflow. Distribuer, c'est toujours compliqué parce qu'on a une infrastructure pour de multiples usages. Donc, il faut arriver à bien savoir découper ces ressources, qui utilisent quoi et quand. Donc, c'est vraiment un bon exemple. Et oui, mettre en place des guidelines pour savoir comment on fait au départ. C'est le prérequis, parce que si on fait un peu de manière itérative avec beaucoup d'usecases différents, ça peut venir très très lent globalement aussi, que ce soit en primal, que ce soit dans GCP ou ailleurs.

45:26 Edouard, il y avait une petite question pour revenir sur l'index de qualité que vous avez mis en place. Est-ce que tu pourrais nous en dire un peu plus? Oui, alors on a plusieurs. Pour faire simple, il y a différents niveaux chez nous de mesures de qualité. Premier truc, en fait, c'est qu'on a, encore une fois, sur cette partie data, on a un business model qui est assez simple. On prend une source, un catalogue, au-dessus de laquelle on les met à un modèle unique et on revend ça. Donc l'étape zéro, c'est en fait savoir sur une de ces sources-là si les données sont disponibles ou pas, et rafraîchir le jour même. Si ce n'est pas le cas, ou en tout cas si ce n'est pas rafraîchi à la fréquence habituelle, du coup, on a un problème. Donc ça, c'est le premier niveau de mesure de qualité. Le deuxième niveau, il est un peu plus fin. En gros, on va commencer à regarder un petit peu ce qui est dans la source de données en elle-même. Pour nous, c'est des contrats financiers sur un set de personnes données. Donc, si on voit qu'il y a des variations trop fortes sur le volume de contrats auxquels on s'attend ou sur le volume de personnes ou de foyers concernés, on a un problème en fait, on le diagnostique aussi. Et le numéro 3, en fait, c'est on va encore plus finement dans véritablement ce que nous envoient nos partenaires ou ce qu'on récupère chez eux, qui est en fait un contrat financier en tant que tel.

46:30 Aujourd'hui, on est capable de recalculer complètement la performance d'un contrat financier dans lequel vous avez acheté des actions, des matières liquides, ce que vous voulez. Et en fait, on compare ce qu'on a dans le contrat vis-à-vis de ce qu'on observe, nous, sur les flux boursiers. Et du coup, après, si on se rend compte, déjà, sujet numéro un, que le contrat, par exemple, a un taux de rendement à 600%, ce n'est pas vraiment un truc qui se trouve sur le marché, on va dire. J'aimerais bien, mais en quelque cas, j'arrête juste de travailler et puis c'est parti. On se dit qu'on a un problème. Et deuxièmement, quand on compare ça aux informations boussières standards, on voit qu'il y a une variance qui est trop forte, on considère qu'on a un problème aussi. Et ça ouvre automatiquement des tickets. Donc, en fait, c'est un peu ce type d'analyse qu'on a. Donc, il y a effectivement différents niveaux. C'est pour ça aussi qu'on est capable de rentabiliser quelque part la partie index de qualité un peu plus poussée parce que justement, faire des comparaisons à la maille contrat vis-à-vis des informations boursières qu'on peut avoir d'Euronext et compagnie, ça, ça a de la valeur. En fait aujourd'hui. Super clair. Tout ça, ça me pensait à, est-ce que vous avez un index, vous, Claire, Victor, de votre côté, de qualité, on va dire, ou est-ce que dans le backlog, vous traquez cette dette technique, vous la traquez aussi dans...

47:43 Qualité de données, est-ce que quelque part on peut, si je viens chez vous, voir rapidement en fait quel est l'état de cette dette, comment travailler dessus. Ça fait partie des chantiers qu'on a dans le futur. Mais en fait, on commence surtout par des choses assez... des basiques de tests vraiment de fraîcheur, par exemple, de la donnée, Vraiment, on a mis en place que les tests les plus critiques sur les données qui servent à... Affider les capillaires les plus importants, par exemple. Et après, il faut qu'on continue à construire là-dessus pour monitorer la qualité de la donnée. Mais c'est un gros chantier, donc on est encore dessus. Nous, de notre côté, très concrètement, on va essayer de mesurer le nombre d'incidents, le temps qu'il nous faut pour sortir des transformations, des features. Mais après, en termes de legacy, source de données, c'est assez facile finalement avec DBT de savoir ce qui vient de quel système.

48:45 Donc, quand on est encore dans une phase, tout à l'heure, je ne suis pas allé finalement au bout, mais notre base de déploiement, on l'a décommissionné en décembre. Donc en fait, on a eu les deux systèmes en parallèle pendant des années et des années, enfin pendant des années et des années, pendant trois ans. Mais du coup, on peut identifier facilement les sources qui viennent du système legacy et ce qui est du nouveau système, la nouvelle infrastructure. Avec des outils comme le lignage de DBT, c'est assez... On peut mapper. D'ailleurs, je vous conseille, ceux qui utilisent DBT, de faire de la customisation sur les couleurs, sur plein de choses, sur le lignage, parce que ça peut donner des insights assez intéressants sur justement la qualité et globalement le mapping de l'infrastructure. Alors, je vois le temps qui file. Basé sur vos expériences et chacun de vos témoignages, à la communauté de Tech.Rocks qu'on a aujourd'hui, quels sont les conseils que vous donneriez pour justement anticiper cette dette ou mieux la gérer en deux, trois apprentissages que vous avez de votre côté à partager?

49:53 Si je peux me permettre, il y a un truc que je trouve intéressant et ça rebondira sur ce qu'avait dit Victor à un moment. En fait, nous, on essaie de... considérer le software engineering et le data engineering de manière assez similaire. On a un gros enjeu de professionnalisation des équipes sur tout un tas de sujets, les réflexions d'architecture typiquement. Nous aujourd'hui on essaie de faire sur la partie data une réflexion d'architecture par projet où à la fin on est capable de sortir un prix du produit. C'est-à-dire qu'on a réfléchi en termes d'unité compute, combien on va consommer, l'unité stockage, combien on va consommer, si on met une marge par-dessus, ce que ça va faire, le support qu'on va avoir associé, et ainsi de suite. vis-à-vis d'un autre niveau de performance attendu. Donc ça, en fait, c'est quelque chose qu'on a commencé à mettre en place. Je dois avouer que ça se met, Doucement, on va dire, en mouvement. Mais on a ça, on a toutes nos problématiques d'opérabilité qu'on a également dans le software. Donc, on calque véritablement notre organisation data là-dessus pour la professionnaliser. Et ça semble être une recette qui marche. Donc, peut-être à répliquer. I don't know.

51:03 La dette, c'est les fois où on travaillait de façon réactive avec le business. C'est-à-dire que le business venait avec des demandes et nous, on n'avait juste pas le temps de réfléchir à comment le faire bien. Alors qu'en fait, ce besoin, il existait depuis plus de temps que ce qu'on savait. Donc, je pense que ça passe aussi. Nous collaborer avec les équipes produits, les équipes business, pour savoir en amont quels vont être leurs projets et nous pouvoir anticiper, soit on peut influencer la façon dont ils veulent développer quelque chose pour que ça fasse plus sens d'un point de vue data, soit nous avoir le temps de planifier le travail pour le faire de façon bien, plutôt que de le faire de façon shortcut à la dernière minute. Donc, ça rejoint un peu le point de se dire, il faut convaincre le business que c'est important de résoudre la data legacy. Il faut aussi convaincre le business que c'est important de travailler avec l'équipe data pour construire ensemble tous les outils data. Et moi, de mon côté, ça va aller vraiment dans le même sens, la relation avec le business.

52:10 Nous, côté ingestion, on a développé une plateforme qui est très, très stable, qui est très résiliente maintenant en termes d'ingestion. Alors, ce n'est pas du tout du no-code, au contraire, c'est très technique, ça fait intervenir plein de microservices, donc ça a été long à développer, mais on a essayé d'avoir quelque chose pour communiquer avec les différents produits qui veulent envoyer, exposer de la donnée, de très stable et qui va nous permettre de gérer et de comprendre une fois qu'on a le concept global et d'appliquer pour tous les use cases. Plutôt que de faire du spécifique à chaque fois. Après, il vient du coup l'étape de faire adopter cette solution pérenne, on va dire, très constante, aux équipes qui gèrent la donnée. Et responsabiliser les équipes sur leurs données, sur cette volonté. En fait, en réalité, les équipes produits n'ont pas forcément la volonté d'exposer la donnée. C'est des choses qui sortent complètement du périmètre de leur produit. Le produit data est derrière ce qui lui arrive, le cycle de vie de ce produit data et des entités, même s'ils en sont responsables, parce que c'est eux qui la produisent, finalement, ça a peu d'impact sur leur produit intrinsèquement.

53:22 Donc, il faut arriver à vraiment travailler avec eux pour que ça ne devienne pas une priorité, mais comment ça sera inclus dans les roadmaps. Et nous, je dirais que l'erreur, c'est que... de ne travailler qu'avec les produits qui fournissent la data pour les convaincre de la pertinence de changer de système, de devenir plus responsable de ce qu'ils produisent, de pousser la donnée plutôt que de nous laisser venir dans leur base. Je dirais que la meilleure solution, en tout cas les moments où ça a mieux marché chez nous, c'est quand le business comprend bien toute la stack et travaille directement avec le produit. Donc, comme dit Pierre, oui, la data va être impliquée et ils vont travailler avec nous, c'est sûr. Mais nous, chez Veepee, la data, c'est beaucoup de gens, beaucoup d'intermédiaires. Donc, en fait, multiplier les intermédiaires, ça met beaucoup aussi de flou sur qui est responsable de quoi. Et ça augmente beaucoup le temps, le time to dashboard. Donc, arriver à faire travailler, à orchestrer la discussion, et chez nous, c'est le rôle de la gouvernance, en l'occurrence, qui fait ça très bien, qui orchestre la discussion entre les besoins business et les produits qui sont responsables des entités qui sont nécessaires

54:27 aux analyses d'affaires. Donc, mettre vraiment l'accent sur faire comprendre au business, comme disait Claire, l'impact de tout ça, la pertinence de tout ça, et les faire communiquer avec le produit. À la fin, c'est ceux qui produisent la donnée pour les convaincre aussi de prendre le train en marche. Super, merci à tous les trois pour ces témoignages, c'était vraiment super intéressant. Donc on voit que la dette technique, en fait, d'un point de vue data, ça a des impacts, il faut y agir dessus collaborativement. trouver des solutions, mais la rendre visible, parce qu'en fait, financièrement parlant, ça peut avoir un impact. On peut les découvrir comme avec Edouard, on peut ralentir un peu avec Claire et dire on va miser sur le futur, mais tous ensemble, il faut prendre une décision parce que ça a un impact. Ou comme avec Victor, en disant qu'il y a un changement de modèle, un changement de stack, et on va être plus rapide, on va pouvoir faire autre chose et investir du temps ailleurs pour construire des nouveaux produits ou des nouvelles fonctionnalités ou étendre sa zone géographique. Donc tout ça, tous les challenges finalement de la data dans la dette technique,

55:31 C'est un peu les mêmes que dans les autres domaines, donc il faut s'en inspirer, prendre les bonnes pratiques et rendre visible le travail de vos équipes data pour qu'elles puissent aussi répondre aux futurs usages. Un grand merci à tous et merci à la communauté. Vous pouvez rester, on va partir sur des tables juste après pour discuter ensemble.