CTO-CDO - Regards croisés sur la data

0:05 Venez, viens, viens, viens, ma bande. Je vais vous laisser seul, mais vous ne serez pas seul. Parce que tu as l'immense chance, évidemment, de modérer cette table ronde. Et moi, je vais m'éclipser. Très bien. Et je reviendrai pour les Q&A tout à l'heure. Parfait. Bonjour à tous. Je suis Elise Delsol. Je pilote nos activités pour les entreprises de technologie et du digital chez Snowflake en France. J'ai le plaisir de modérer cette table ronde avec deux de nos clients qui nous sont chers, Qonto et Welcome to the Jungle. Merci et bienvenue. Pour les initiés, on va faire un format table ronde en mode Fast and Curious. Vous savez qui a inventé ce concept-là? C'est combini. C'est combini. Donc l'idée en fait c'est que je vais proposer à nos panélistes de choisir un concept parmi deux concepts et ils vont nous expliquer pourquoi ça leur parle. On va couvrir plusieurs thèmes mais effectivement sur un sujet qui nous est cher chez Snowflake qui est la data. Pour ceux qui ne savent pas ce qu'on fait chez Snowflake, je fais une petite digression.

1:08 On va permettre à nos clients un échange de données simplifié sur la partie data analytique. Et donc quel que soit votre volume de données, quel que soit le format de vos données, nous on va être la plateforme qui va accueillir toutes ces données, qui va vous permettre de les stocker, de les transformer, de les exploiter, pourquoi pas de les monétiser et de les partager à l'intérieur ou à l'extérieur de l'entreprise. Et tout ça de façon très simple, sécurisée et gouvernée. Donc juste à... Avant de vous mitrailler de questions, messieurs, je vais vous donner l'opportunité de vous présenter et de nous dire qui vous êtes. Est-ce que vous faites peut-être dire deux mots de votre entreprise aussi? Aymeric, on commence avec toi. Bonjour à toutes et à tous, je suis Aymeric, je suis le CTO de Qonto. Qonto, c'est la solution financière pour les PME en Europe. On fournit un compte bancaire et des services pour simplifier la comptabilité, la gestion des dépenses par-dessus ce compte. Aujourd'hui, on a 300 000 clients heureux, dont certainement un grand nombre de personnes dans la salle. Kevin? Bonjour à tous, du coup Kevin, CTO de Welcome to Jungle. Donc pareil, il doit y avoir de nombreux clients dans la salle, parce qu'aujourd'hui on en a 5000 et on les accompagne sur le développement de leur marque employeur et le recrutement.

2:11 Et notre mission un peu de fond, c'est de faire en sorte, ou en tout cas d'aider à ce que le travail devienne un peu plus durable dans nos vies. Et aujourd'hui, c'est 5000 clients, 300 employés, à peu près 80 entre les équipes tech et produits et une douzaine côté data. Jérémie? Moi, je suis en charge des données chez Qonto. J'ai la chance d'avoir une super équipe, une équipe d'une cinquantaine de personnes. Et voilà. On finit avec toi Brice. Très bien, bonjour à tous. Donc Brice, effectivement Head of Data de Welcome to the Jungle, arrivé il y a 18 mois et maintenant une douzaine de personnes côté data. Super. Sans transition, on va commencer tout de suite avec le premier point de vue. Vous allez voir un vaste débat. Data mesh ou data mess? Jérémie, qu'est-ce que tu en penses ? Tout de suite, les mots qui fâchent. Attention Elisa, on peut avoir DataMesh et DataMesh. Juste pour voir le nombre de copains que je vais me faire, qui est passé en organe DataMesh?

3:14 D'accord, ça va, je ne prends pas trop de temps. C'est bon, tu peux y aller. Ouf! Alors, chez nous, chez Qonto, c'est non. Ni Datamesh, ni Datames. On a une organisation qui est centralisée. Imaginez un peu, ça pourrait donner un truc du genre, Jérémie, on a signé combien de contrats le mois dernier? Je ne sais pas, tu veux le nombre de contrats au sens du domaine marketing ou le nombre de contrats au sens du domaine finance? Non, on a une seule notion, on a une équipe qui aligne tout le monde, c'est l'équipe BI. C'est un boulot qui n'est pas évident, parce que du coup, en hypercroissance, on croit, on croit, on crée. Donc il y a des concepts tout le temps qui ne manquent pas d'émerger. Et donc effectivement, on est encore au stade où on tient, centralisé, Je ne dis pas qu'il n'y a pas un moment où ça va tirer trop fort et qu'on va être obligé de passer en décentralisé, mais ce moment n'est pas encore venu. Oui, pas encore venu. Très bien. Alors, bonne BI ou mauvaise BI? Aymeric, ça t'inspire? Bonne BI, sans hésiter. Merci, merci Élise d'avoir pris une question facile pour CTO.

4:18 C'est très orienté client de la part de Snowflake. Donc du coup, on peut essayer de parler de ce que c'est une bonne BI. Et si on se met dans les chaussures du client, une bonne BI, c'est un bon dashboard. Un bon dashboard, c'est un dashboard qui répond à une question. Il y a un titre dans le dashboard et puis le reste répond. Un titre qui est une question et le reste répond à la question. C'est des données qui sont correctes et à jour. C'est de l'information qui est sélectionnée et archivée. C'est un dashboard où il n'y a pas besoin de lire le manuel pour s'en servir. En gros, c'est ça. C'est ça, on est d'accord? C'est ça un bon dashboard? Non, ce n'est pas un bon dashboard, parce qu'on peut faire le plus beau des dashboards, le parthénon du dashboard, et si personne ne le regarde, on aurait mieux fait d'aller à la plage, ça ne sert à rien. Donc on peut se dire... qui ont un bon dashboard, c'est un dashboard qui est utilisé, et du coup Jérémie et son équipe ont un dashboard d'analytics d'usage des dashboards, pour voir si ça sert à quelque chose ce qu'on fait. Donc du coup maintenant on sait ce que c'est qu'un bon dashboard? Du coup, en janvier, il y a des promotions, des augmentations. Et du coup, moi, j'attends la première personne qui sera promue avec l'argumentaire.

5:20 J'ai vraiment regardé beaucoup de dashboards l'année dernière. J'ai envoyé du lourd. D'accord? Donc, un bon dashboard, c'est peut-être un dashboard dont on se sert pour agir dans le business, pour changer des choses. Un dashboard qui aide à faire monter les KPI. On y est là, on est d'accord? Non, il y a un piège? Ok. Il y a encore un petit piège, c'est de croire les chiffres juste parce qu'ils sont justes. Mais en fait, un dashboard, c'est que des moyennes. Et donc, lies, down lies and statistics. Et donc, peut-être que le bon dashboard, c'est le dashboard qui, au bout de 15 minutes, s'éteint et met un message disant« ça fait 15 minutes que tu regardes des moyennes, si tu allais parler à des clients à la place ou regarder des tickets, peut-être que tu saurais ce qui se passe dans le vrai monde». Donc on devrait essayer de faire ça, je pense, Jérémie, un de ces jours. Depuis le début, je vous parle de dashboard, mais en fait, je n'ai pas répondu à la question parce que quand on parle de la BI, la BI, ce n'est pas les dashboards, la BI, c'est la personne qui fait le dashboard. Et donc, en fait, la bonne BI pour moi, c'est...

6:23 C'est l'équipe où on développe les compétences pour répondre à tous les étages de la pyramide de Maslow du dashboard. Et donc la pyramide de Maslow du dashboard. de Maslow du dashboard, c'est la donnée est correcte et à jour, elle répond à la question qu'on a posée, elle est présentée de manière claire et hiérarchisée, elle est utilisée par le business, elle fait réfléchir le business. Voilà, donc rendez-vous dans 10 ans quand on a tous réussi ça. Dans BI, dans Business Intelligence, il y a intelligence. Donc je te rejoins pas mal là-dessus. Data team first ou data stack first? Par quoi on commence, Brice? Bonne question. Alors, dans le contexte de Welcome, je dirais les deux, en l'occurrence. Je voyais difficilement l'occasion de faire différemment. Pour recontextualiser un petit peu, il y a 18 mois, il y avait 4 personnes à la data et la stack n'était pas totalement moderne. On avait encore un bon gros post-grès, etc. Et donc, l'idée était d'accompagner le scale de l'entreprise, donc de faire grandir l'équipe et de moderniser la stack.

7:28 Donc on a commencé par définir un petit peu la philosophie de stack que l'on voulait. Et les différentes briques à l'intérieur de celle-ci, pour attaquer le recrutement. Et effectivement, ça a été déterminant dans le fait de recruter. J'ai clairement mis en avant le plan de migration que je voulais et les technos que je voulais pour recruter. Typiquement, si on parle d'un... Recruter un analytics ingénieur, clairement, le fait de passer sur un framework DBT a été déterminant dans son choix à elle de rejoindre Welcome. en plus de l'expérience de travail qu'on peut proposer. Ou si on était aussi en phase de recrutement des data engineers, le fait de mettre en avant le passage à des Snowflake, à des outils plutôt récents d'ingestion, etc. Ça a été déterminant dans leur choix de rejoindre Welcome. Donc on a défini la philosophie et la stack. Pour recruter, une fois qu'ils sont arrivés, on a commencé le plan de migration. Et donc, on est passé effectivement de 4 personnes à 12.

8:28 Et on est maintenant sur une stack qui est complètement moderne. Dernier petit point à ajouter, c'est que dans tous les cas, je sais très bien que ce que j'implémente d'un point de vue orga ou techno, va être très vite challengée. La stack va être challengée, elle va rester au maximum deux ans, trois ans au maximum, au mieux. Ça dépend des briques, on va dire. La fondation, elle reste. Et l'organisation, si elle reste un an et demi, c'est déjà très bien, puisque ça va suivre les enjeux de l'entreprise. Donc voilà. Et pour compléter du coup la data into tech ou la data into business, Kevin, ta perspective en tant que CTO et observateur aussi chez Welcome to the Jungle, des organisations en place chez les clients? Oui, avant de répondre, peut-être un petit sondage. Qui a son équipe data dans son équipe tech? À main levée. Un petit tiers. Du coup, nous, aujourd'hui, l'équipe data est côté T.

9:30 Et du coup, ça s'est fait de manière historique, parce que du coup, l'équipe tech a été créée avant. Au tout début, dans une startup, généralement, l'équipe data, ou en tout cas les premières briques côté data, vont plutôt dans une équipe soit technique, soit analytique. Et du coup, nous, on avait plutôt une équipe technique. Donc, c'est comme ça que ça s'est fait. Et rétrospectivement, ce n'était pas inintéressant, parce que du coup, aujourd'hui, tous nos data analysts et toute l'équipe data est très intégrée dans l'équipe tech. Ils sont intégrés dans les squads. Ils travaillent main dans la main. avec les équipes ingénierie, qui travaillent main dans la main avec les équipes infrastructure. Et du coup, toute cette proximité avec l'équipe tech, c'est ce qui fait aujourd'hui aussi qu'ils sont vachement plus pertinents pour parler avec les équipes marketing et business et pour les alimenter en données. Et du coup, le fait qu'ils soient intégrés dans l'équipe tech aussi, ça ne veut pas nécessairement dire qu'ils sont complètement décorrélés du business. Et d'ailleurs, preuve en est, chez nous, on a dédié des data analysts aux enjeux business et marketing et ils sont intégrés dans les équipes d'Atum et ils travaillent que pour les autres équipes.

10:33 Ça marche très bien et ils sont d'autant plus pertinents que s'ils avaient été à part. Et peut-être pour compléter, pourquoi Data into Tech? Parce que pour moi, c'est aussi un sujet d'ambition. Si vous avez regardé les autres conférences hier, notamment de Miracle et de Préligence, je fais peut-être un petit écorchage du nom, je ne sais plus. Mais en tout cas, pour construire des infrastructures data aussi puissantes, aussi performantes et aussi scalables que ce qu'ils ont pu faire et ce qu'on fait aussi chez nous, ça nécessite derrière de l'ingénierie. Et du coup, pour ça, c'est forcément travailler un peu comme les équipes tech et avec les équipes tech pour que ce soit scalable, pérenne et performant. Fondation ou valorisation? L'avis du CDO de Qonto, Jérémie? Ça ne vous a pas échappé, en ce moment, c'est la Coupe du monde de foot. J'imagine avoir Didier Deschamps à côté et lui dire« Alors Didier, on est entre nous là. Pour France-Angleterre, tu seras plutôt défense ou plutôt attaque ?

11:35 En fait, une équipe d'attaque, c'est comme une équipe de foot. On a une défense et une attaque. En attaque, on va créer de la valeur, on va apporter des euros, on va en défendre. Et en défense, c'est les fondations. C'est le fait d'ingérer les données, de les transformer, de les mettre à disposition. Et donc on ne peut pas faire l'un sans l'autre. Si on ne fait que de la valeur, on a une passoire et on prend 7-2. Si on ne fait que des fondations, on prend 1-0. Et il ne se passe rien. Donc voilà, c'est le numéro d'équilibriste de toutes les personnes qui sont dans ma situation, c'est d'arriver à trouver le juste équilibre entre faire de la fondation et faire tout de suite de la valorisation. Alors, on a un peu plus que 90 minutes, heureusement. Performance ou adminless? Brice, qu'est-ce que tu en penses? Un peu des deux forcément. Je vais attaquer avec la partie adminless. Le choix de passer sur Snowflake il y a un peu plus d'un an, c'était effectivement l'idée d'être beaucoup plus adminless.

12:45 Historiquement, on était sur du post-grès, comme je l'ai dit tout à l'heure. Et on se faisait accompagner par des experts de l'optimisation d'infrapost-grès, un métier très précis. Et c'était très coûteux en termes d'efforts. Pour le coup, et en termes de budget également, pour gagner quelques minutes de run quotidien. Et effectivement, je n'avais pas en plus ce niveau d'expertise dans l'équipe. Donc l'idée, c'était effectivement de passer sur des solutions totalement adminless, ce qui est fait depuis maintenant quelques mois. Et effectivement, on a gagné aujourd'hui, on n'a plus du tout d'efforts sur la partie admin. Et en plus, sur la partie performance, on a multiplié par trois notre temps de run quotidien. Donc, on a gagné vraiment sur les deux pans. Et chez Qonto, Jérémie? Oui, alors nous, il n'y a pas très longtemps, avec Aymeric, on bossait sur un modèle de... On regardait avec les équipes un modèle de lutte contre la fraude. Et vous savez comment ça marche les modèles, c'est-à-dire qu'il y a toute une partie de préparation des données.

13:48 Et donc nous, on utilise Snowflake pour cette partie-là. Et on regardait ce fichier qui faisait peut-être 700 lignes. Et on se disait, si on n'avait pas Snowflake à ce moment-là, on pourrait aller se prendre un petit café et puis en rediscuter après. Donc là, vraiment, nous, on s'appuie sur la perf pour être capable de passer notre temps là où vraiment ça vaut le coup, c'est-à-dire quelle feature on choisit et quel modèle on choisit. Donc on n'est pas sur du« ou», on est sur du« et». Merci pour ce partage. La suivante est difficile. SQL ou Varicel, Brice? Qu'est-ce que tu préfères? Je ne sais pas si j'ai un choix à faire, mais l'objectif... en changeant de warehouse, c'était aussi d'avoir le langage le plus commun dans sa version la plus basique. Dans le sens où avoir un warehouse avec du SQL permettait d'onboarder toutes les expertises côté data autour d'un même langage qui était le plus simpliste possible. Et également de pouvoir on-boarder des équipes tiers.

14:53 On parlait de BI tout à l'heure. Aujourd'hui, on envisage potentiellement d'ouvrir le... warehouse à des équipes PM ou développeurs qui ont le background technique et qui ont un accès direct à la donnée, ce qui évitera de faire de la mauvaise BI potentiellement, et qui va remettre en jeu aussi certains outils de BI en self-service qu'on avait jusqu'à présent. Donc évidemment SQL avec effectivement des fonctions assez intéressantes, assez avancées comme le time travel. Et ce qui est aussi intéressant, c'est la perspective de pouvoir rendre du Python dans ce même warehouse. Qui va pour moi emborder également le data scientist autour de cette techno. Et donc tout le monde bosse au sein d'un même warehouse et avec deux langages, un très basique, très commun à tous, et le langage plus Python pour les data scientists. J'en profite pour dire que Snowflake, c'est vraiment une plateforme programmable.

15:57 Et on prend vos développeurs comme ils sont, comme chez McDo. Vous venez comme vous êtes, avec le langage de votre choix. On est comme ça. Agilité ou Lean Management? Je crois qu'Aymeric, tu as un point de vue... Un point de vue très tranché. Agilité, sans hésiter. Il faut que je vous explique. Déjà, agile, ça fait un peu genre sportif, grimpeur et tout, alors que lean, ça fait un peu maigrichon, et puis management, ça fait gestionnaire et tout. Donc déjà, les mots, ça ne le fait pas. Puis franchement, lean, c'est rabat-joie. Déjà, ça ne s'appelait même pas lean. Au début, ça s'appelait Toyota Production System, TPS. Et c'était tellement la honte que les Américains... Ils ont dû le renommer. Donc maintenant, ça s'appelle Lean. Donc on en parlait ce matin, Nicolas parlait de Lean ce matin fondamentalement, et puis il a posé dire que c'était du Lean parce que c'est la honte. Et du coup, quand on fait du Lean, alors il faut réfléchir avant d'agir. Donc ça, c'est fatigant. Ensuite, il faut regarder ses erreurs pour s'améliorer. Alors franchement, c'est trop dur. Moi, je ne peux pas regarder mes erreurs. Je n'y arrive pas. Je préfère dire que c'est la faute de quelqu'un d'autre. Et puis après, on se trouve à bâtonner nos« right first time» sur le mur. On se prend pour des prisonniers qui bâtonnent les gens dans leur cellule.

16:58 C'est horrible. Et ça s'apprend à la japonaise. C'est-à-dire que le sensei va tracer une petite croix par terre à la crève, va te dire tu te mets debout là et tu regardes pendant 4 heures autour de toi. Et puis au bout de 4 heures, il te dit tu vas bâtonner ton« right first time» sur le mur. Et dans un mois, je reviens et tu me dis« qu'est-ce que tu as compris? » Et puis il va te dire« qu'est-ce qu'il me raconte? Bref, l'agilité, c'est beaucoup plus confort. Il y a des consultants, des coachs, des scrum masters, ils vont mettre les rituels, ils vont mettre les boards. Il n'y a même plus besoin de s'occuper du board, le scrum master s'occupe du board. On va papoter à la rétro de ce qui s'est passé et comment on le sent. Et puis après, on va mettre des trucs à l'ordre du jour, du monthly de la guild qui sera dans trois semaines. Et tout ça, c'est assez relax. Donc du coup, le Lean, c'est triste. Il n'y a pas le budget pour les overheads, il n'y a pas le budget pour les consultants, pour les scrum masters, pour les QA. De toute façon, la QA, on ne peut pas. Parce que si on a une QA, la boucle de rétroaction du writer's time, elle ne marche plus, elle est trop longue. Il faut faire son writer's time le plus en amont possible, au niveau A des bugs, comme on disait ce matin. Donc du coup, depuis que j'ai la digité, moi je me fatigue beaucoup moins.

18:00 Je paye des gens à apprendre à ma place et l'argent c'est fait pour ça, non ? On gagne de la qualité de vie. Alors moi j'ai une petite inquiétude quand même, c'est que l'agilité, les geeks qui ont écrit le Agile Manifesto, en gros ils ont pris les idées du Lean, ils ont essayé de les transposer dans le monde de l'IT et de faire un peu de marketing autour. Bon, c'était des très bonnes idées, on va se le dire. Et là je sens une petite résurgence limite en mode vintage du Lean, les gens en parlent de plus en plus, et donc du coup j'ai un peu peur d'être dépassé, mais il faut que je regarde ce truc de Lean Six Sigma, je crois qu'on peut acheter des consultants Lean Six Sigma, du coup je vais avoir ma solution. Pour l'instant je suis chez Qonto, du coup il n'y a pas de budget pour les overheads, du coup je suis encore du Lean. Job tech ou job data? Alors oui, on trouve des job tech et job data sur Welcome to Jungle, n'hésitez pas à les voir. Mais du coup, je pense que la question était plus la différence. En tout cas, ce qui est intéressant, et quelqu'un le relevait hier, sur les équipes tech, on trouve énormément de contenu sur comment les faire grandir, comment les structurer, etc. Sur les équipes data, un peu moins quand même, surtout sur les grosses équipes data.

19:04 Mais du coup, ce qui est intéressant, c'est qu'il y a plein de métiers qui sont en train de naître côté data et qui s'inspirent des équipes tech. Tout à l'heure, Brice parlait justement des analytics engineers qu'on vient de créer chez nous, qui sont à mi-chemin entre data analyst et data engineer, qui se rapprochent un petit peu de la QA, mais pas vraiment, qui sont là pour aller plus loin sur la modélisation, la structure et la qualité de la donnée. Donc ça, c'est un exemple. Hier, il y avait un autre exemple aussi sur les équipes data de Miracle qui commencent à internaliser des DevOps. Et du coup, c'est vrai qu'aujourd'hui, le métier de data engineer, il commence à s'élargir un petit peu plus, un petit peu plus SRE, un petit peu plus sur l'observabilité de la production, tout ce qui est sécurité, tout ce qui est mise à disposition d'outils pour aller plus loin sur la data experience, etc. Et du coup, on commence aussi à avoir des métiers de data reliability engineers. Du coup, tout ça, c'est en train de s'inspirer petit à petit. des équipes tech et on le voit aussi avec des data architects, avec la data governance, avec des métiers de data scientists qui se splitent aussi pour être de plus en plus précis.

20:10 Donc voilà, ça continue, ça va continuer à créer de nouveaux métiers côté data et clairement l'inspiration est forte par rapport aux équipes tech. Brice, tu avais une perspective complémentaire? Exactement pareil, on essaye maintenant même d'organiser des rencontres qui ne sont pas forcément des binômes, mais d'avoir l'analytics ingénieur qui va rencontrer mensuellement la partie QA chez Welcome, la partie architecture côté engineering qui va également parler avec l'analytics ingénieur pour définir un peu la structure du warehouse plus globale. Donc de faire des ponts, même si effectivement la data est dans la tech, mais de faire des vrais ponts. Entre les jobs tech et les jobs data, que ce soit aussi par exemple sur les guidelines, les bonnes pratiques de développement. Donc on essaye vraiment de pousser dans cette direction et d'organiser des vrais meetings de partage de connaissances autour de ces expertises chez Welcome. Donc les autres, on ne les a pas préparés, donc ça va être à vous de prendre la malle au vent.

21:13 Visiblement, si, si, elle était préparée. Alors j'ai une dernière question quand même avant. On en a parlé un tout petit peu tout à l'heure. Elle est très, très difficile. France ou Angleterre? Vous pouvez répondre. L'oncle rouge derrière. Donc voilà, Cocorico, ce sera le mot de la fin. On va pouvoir ouvrir la session à vos questions. J'espère que vous en avez. Si vous voulez les faire en format Fast& Curious, n'hésitez pas. Merci beaucoup en tout cas pour vos perspectives et vos partages. Je ne sais pas si tu veux revenir nous voir pour modérer les sessions. Il n'y a pas la place pour toi, c'est déjà terminé là? Non mais je veux dire, vous êtes bien en config. Ah bah c'est vrai qu'on est en config. Non, non, mais je ne servirai à rien. On est bootstrap jusqu'au bout. Des questions pour nos panélistes ? Bonjour monsieur. Bonjour à tous.

22:18 Pour rebondir sur la question Lean vs Agile, moi je voulais poser la question autrement. Méthode vs Skills, technique par exemple, pour la plupart des gens de l'IT. Quel est le poids de la méthode par rapport au poids des skills sur la réussite? Au quotidien ou sur un projet de données? C'est une super bonne question. Dans la manière de travailler, quand on se parle de skills, il y a du skill inconscient. Je roule à vélo. Franchement, personne ne sait expliquer que quand le vélo penche à droite, il faut appuyer sur la poignée de gauche, parce qu'en plus, c'est contre-intuitif, c'est inversé. Et il y a du skill conscient. Quand j'écris un pipeline data, j'ai mes 5-6 points de contrôle de qu'est-ce qu'un bon pipeline data. Et du coup, il y a des ping-pong entre ces deux mondes. Quand on est complètement une compétence inconsciente, je pense que j'écris un bon pipeline data, mais franchement, je n'ai aucune idée de pourquoi c'est un bon pipeline data. Ça vaut vraiment la peine de step back et de réfléchir à pourquoi je le fais comme ça.

23:20 Et donc, de ressortir la méthode de l'exemple. C'est un peu méta, ça fait pas mal à la tête. Et là, on se dit, je fais ça à chaque fois. Mais pourquoi je le fais? En fait, ça ne sert à rien. Je peux arrêter de le faire. Je gagne 20% de mon temps. Génial. Je peux aller prendre des bières à 16h maintenant. Et une fois que la méthode, tu l'as pratiquée et répétée, la méthode que tu as construite, tu la pratiques, tu la répètes, tu repasses dans ce qui est inconscient parce que tu le fais de manière plus efficace et tu n'as plus besoin de suivre ta méthode pas à pas. Et donc, tu as en permanence ces ping-pong. Et typiquement, regarder les erreurs, les quasi-bugs ou les bugs, c'est une manière de voir là où, tiens, si on réfléchit à notre méthode, on passe en mode conscient pendant quelque temps, là on ralentit quand on fait ça, et ensuite on peut réaccélérer. Merci. D'autres questions? La data, ça ne déchaîne pas les foules. Merci. Bonjour, merci déjà beaucoup pour les échanges, c'est très intéressant. J'ai oublié les prénoms, mais c'était l'équipe Qonto, désolée.

24:25 Vous aviez dit qu'on veut ouvrir notre data warehouse éventuellement à d'autres personnes, des products, des devs, notamment parce qu'il y avait des problèmes au niveau de la BI. Vous avez parlé du fait que... Malheureusement, il y avait un retour en arrière sur le CFBI, en tout cas la façon dont vous l'aviez conçu au départ. Je ne sais pas si vous avez du feedback là-dessus, un peu plus en détail. Pourquoi vous avez fait ce choix-là? Alors, c'est welcome. C'est welcome to the jungle. On n'est pas encore passé à cette étape-là, mais on est en train d'y réfléchir. On a effectivement ouvert des outils de self-bi il y a quelques années, mais qui adressent des populations qui sont très diverses. Donc des populations qui sont totalement étrangères à le SQL et au fait de pouvoir coder eux-mêmes, et d'autres qui sont assez advanced et qui... Finalement sont assez restreints par l'outil de SelfBI qu'on leur met à disposition. Donc l'idée était plutôt de dire, plutôt que d'avoir un outil qui va essayer de répondre à des populations totalement différentes, à l'aise techniquement ou pas du tout,

25:36 ouvrons notre warehouse aux populations qui sont totalement techniques et qui écriront du très bon SQL, et pour les autres, orientant plutôt directement vers des outils plus BI traditionnels qu'on a l'habitude, au lieu d'avoir un outil qui essaye de faire les deux pour deux populations pas forcément au même niveau techniquement. Ok, merci. Oui, effectivement, on a deux systèmes. Je complète rapidement pour la partie compto. On a un système officiel pour des chiffres qu'on veut... Être gravé dans le marbre, ou en tout cas dont on veut être sûr qu'il y a une définition et une seule. Le fameux contrat signé. On veut que tout le monde calcule de la même manière les contrats signés du mois dernier. Et donc ça, ça ralentit. Ça ralentit parce qu'il y a un processus de relecture, ça crée des allers-retours, ça crée du travail supplémentaire.

26:39 Et on a du coup un autre système qui donne plus d'autonomie aux équipes pour que les équipes ne soient pas en train d'attendre l'équipe BI et qu'elles puissent avancer sur des sujets sur lesquels elles sont en autonomie. Et là-dessus, on utilise Metabase. Donc pour tous les tableaux officiels, ces tableaux, tous les tableaux officiels de ces tableaux et le Metabase pour les équipes en autonomie. Chez nous, c'est pareil avec Looker et Metabase. Qui est très assidu, je répète, un Tristan qui nous pose énormément de questions et on l'embrasse, dans le thème Data Lake, Data Warehouse ou Data Lake House? Lake House, parce que franchement, la petite terrasse, le petit cocktail, le coup de soleil et tout, moi je suis très très très Lake House. Après, s'il y a des gars de la data qui ont la vraie réponse, on la prend. C'est toi qui payes, Aymeric. Il faut qu'on finisse Qonto d'abord.

27:43 Du coup, nous, très rapidement, on ingère les données. Les données, c'est un processus de maturation. On ingère les données depuis la source, on les injecte dans un data lake. Qui dit data lake, on est dans un endroit qui n'est pas structuré, qu'on ne peut pas requêter facilement avec du SQL, même s'il y a des solutions pour faire ce genre de choses. Et puis une fois qu'elles sont dans le data lake, on les structure et on les modélise dans le data warehouse. On essaie de les amener le plus rapidement possible dans le data warehouse, de sorte à pouvoir utiliser la puissance de SQL, entre autres, pour faire la modélisation. Mais on a ce sas de décompression avant. Oui, on partage cette vision, je pense tous, d'une plateforme pour servir les usages qui soient Lake ou qui soient Warehouse. Oui, et puis je pense que c'est pour avoir plus de contrôle aussi sur la donnée. Pour le coup, je suis... Je ne sais pas si cette discussion, cette question est toujours d'actualité. Je pense qu'on fait tous, ou la grande majorité, de l'extract load et ensuite on transforme pour avoir plus de contrôle sur la donnée, que ce soit de la raw data et sur la modélisation après.

28:51 Donc nous, on est sur le même modèle que Qonto. Effectivement, c'est extraction. Stockage de la donnée pure, raw, et ensuite on modélise proprement par rapport à nos use cases. On n'a pas trop parlé de gouvernance de la data, alors que c'est souvent un sujet d'actualité ou un sujet de préoccupation. Où est-ce que vous en êtes chez Qonto et chez Welcome to the Jungle? C'est pour ça qu'on a commencé à créer un... En l'occurrence, poste d'analytics ingénieur qui a été créé cette année pour aller plus loin sur la gouvernance, que ce soit sur l'observabilité, que ce soit sur la partie data cataloging et sur la qualité de la donnée. Donc vraiment le scope d'analytics ingénieur chez Welcome, c'est celui-ci, gouvernance, qualité et observabilité. Dès les premières semaines, c'est fruit, clairement. La partie d'Atel Cataloging viendra dans un deuxième temps, mais on en est au tout début.

29:52 Et dès les premières semaines, on a vraiment vu un shift sur la qualité de la donnée. une vision très opinionated, on pense qu'il y a une bonne et une mauvaise manière de faire de la gouvernance de la donnée, et qu'on est dans un sujet de mastery, c'est-à-dire que si la vision sait, et l'équipe data, les données ne sont pas de bonne qualité, qu'est-ce que vous faites ? On n'est déjà pas en train de poser le problème comme il faut. C'est-à-dire que ça se passe à la source, le problème. Et donc, il faut mettre en responsabilité, rendre accountable les producteurs de la donnée. Une fois que tout le monde connaît sa partition, ensuite on peut jouer ensemble et ça se passe bien. L'anti-pattern, c'est de se dire que ceux qui produisent ne se préoccupent pas, parce que je ne connais pas grand monde dont l'intitulé du job soit de produire de la donnée. En général, c'est toujours une conséquence, la production de la donnée. Et donc, c'est très important que les gens qui produisent de la donnée, souvent sans le savoir, comme M. Jourdain, aient en tête qu'en fait, ils sont en train de produire quelque chose qui est utilisé ailleurs dans la boîte et qu'il faut que ce soit quali.

30:55 Il faut le faire bien, mastery. Et donc voilà, nous c'est notre parti pris. Si chacun fait bien son job, l'ensemble fonctionnera bien. Jérémie est un peu trop modeste pour exprimer comment il l'a mis en pratique, parce que la théorie à la pratique, vous voyez qu'il peut quand même y avoir un gap. Ce qu'on a vu bien marcher, c'est d'asseoir autour d'un objectif commun, Des équipes produisent ces données, par exemple dans l'écosystème Growth, Marketing. Des équipes techniques qui, derrière, processent ces données. Parce que dans des équipes web, s'il y a du tracking dans le site web aussi, on trouve... un certain nombre d'acteurs et on leur donne un objectif de mettre les choses au carré, nettoyer, enlever ce qui ne sert à rien, etc. Donc il y a une petite phase d'alignement pour justifier d'investir là-dedans, mais quand en même temps ça fait un an qu'on entend que le dashboard n'est pas vraiment bon, du coup on arrive à boucler la boucle. Et à s'y mettre ensemble. Et en fait, c'est assez fédérateur comme objectif, parce qu'après, ça se game ici bien. C'est OK, du coup, on a nettoyé quel pourcentage, et puis on fait grimper la courbe, et puis on améliore le cadre de travail de ces équipes.

31:58 Et donc ensuite, elles travaillent mieux, plus vite, etc. Et elles le sentent. Donc il y a vraiment un cercle vertueux qui est un petit peu délicat à embrayer quand ce n'est pas dans la culture. Mais une fois que ça embraye, ça continue tout seul. Le cercle d'archi de la data. Merci beaucoup, messieurs. Bravo. Merci à tous. Bon après-midi. Merci, merci. Merci, Elise. Une brillante animation. Bravo.