Transcription de l'épisode : "Corentin Limier, Comprendre les métiers de la data science : Data Scientist, Data Engineer, Data Analyst"
Terry : Et bien on est good, donc salut Corentin.
Corentin : Hello Terry.
Terry : Merci du coup de m'accorder ton temps aujourd'hui. Donc on va parler de data engineering, de en gros la donnée dans les boîtes tech. Comment c'est utilisé, à quoi ça sert, quelles sont les problématiques qu'on y retrouve. On entend beaucoup parler de job data scientist, de job autour de l'IA, autour du machine learning, beaucoup de choses qui sont liées à la donnée en fait. Et c'est vrai qu'avec toi on va dégrossir ce sujet au travers de tes différentes expériences que tu vas nous raconter. Donc avant de rentrer dans le vif du sujet, je te propose tout d'abord de te présenter.
Corentin : Eh bien, je vais commencer par une petite dédicace à Fabien, avec qui j'ai travaillé, Fabien Jean Genelen de Lydia, qui m'a toujours dit de préparer ma phrase de présentation pour les clients et que je n'ai jamais écouté. Donc, ça va être peut-être compliqué. Voilà, donc moi j'ai commencé dans la recherche opérationnelle. Donc tu as déjà interviewé quelqu'un de la recherche opérationnelle, Mathieu, qui travaille chez Air France. Et donc je travaillais chez Air France, moi en prestat, et lui en interne. Et on travaille dans la même équipe de recherche opérationnelle. La recherche opérationnelle, il l'a présenté un petit peu, c'est un pan de l'intelligence artificielle, donc c'est des algorithmes mathématiques qui permettent de résoudre des problèmes. Pour différencier un peu avec la data science aussi, j'imagine qu'on va en discuter quand même aujourd'hui, moi je dirais que généralement, la limite est toujours floue, il y a recherche opérationnelle, machine learning, deep learning, compagnie. Mais la recherche opérationnelle c'est surtout essayer de trouver une solution, une très bonne solution ou une solution optimale, souvent dans les problèmes académiques, dans un univers combinatoire avec énormément de solutions différentes. Voilà, donc j'ai travaillé dans ce domaine-là avec beaucoup quand même de software development parce qu'on construisait nos logiciels de recherche opérationnelle. Et en travaillant là-dedans, tout simplement, le secteur de la data a explosé à ce moment-là. Je me suis rendu compte que ça m'intéressait également. Ça faisait partie du même pan d'intelligence artificielle. Et je voyais beaucoup d'opportunités. Je me rappelle avoir fait le switch dans ma tête. Le jour où DeepMind a battu Lee Sedol au go, ça a été une grosse révolution dans l'intelligence artificielle. C'était un problème, moi, qui joue au go de façon loisir. Je pensais vraiment qu'on était à des années-lumière de battre l'humain au go. Je trouve que c'est beaucoup plus compliqué qu'aux échecs. Et donc à ce moment-là, je me suis dit, waouh, il y a un truc à faire dans la data science. Et là, on atteint un truc assez incroyable. Peut-être que d'autres personnes se diront la même chose avec JGPT d'ailleurs aujourd'hui. Mais moi, le déclic, c'était DeepMind. Et donc, j'ai décidé de travailler la data à ce moment-là. J'ai rejoint une autre entreprise de conseil qui s'appelle Olydia. Donc, j'ai cité Fabien de Olydia. Et je travaillais chez EuroDécision, ma première boîte, qui était spécialisée en recherche opérationnelle. Et Olidiac était plus spécialisé dans la data pour faire un petit peu mes armes, pour apprendre le métier parce que quand même les choses étaient très différentes. Ce que j'ai beaucoup appris finalement c'est les outils nous en recherche opérationnelle. Il y avait un côté un peu old school je pense où on travaillait en C++ sur des serveurs hébergés. Et en arrivant dans un secteur un peu plus moderne qui était la data, qui expose à ce moment-là, ça m'a fait un peu prendre le pli des outils, de voir qu'en fait on peut utiliser des solutions un peu plus clés en main, notamment l'Idea est société partenaire avec Dataiku par exemple, avec Snowflake, et c'est là où j'ai un peu appris à manier les différents outils du monde de la data. Et ensuite, j'ai décidé de rejoindre Vestiaire Collective, un peu par hasard, honnêtement. J'étais très convaincu par le CIO Vipidata qui s'appelle Sacho. J'ai fait une petite dédicace à Sacho également. J'avais vraiment eu envie de travailler pour lui et en fait, c'est pour son projet qu'il m'avait expliqué. Et en fait, je n'avais aucune idée à ce moment-là que je rentrais dans le monde de la tech, de les start-up, d'escaler vraiment. Mais alors, aucune idée. Je ne connaissais pas très bien Vestiaire Collective. Je ne connaissais pas du tout le milieu de la tech. Et je suis rentré complètement par hasard. Et j'étais plutôt ravi de voir que je rencontrais ce milieu-là qui est assez passionnant. Donc Vestiaire Collective est devenu une licorne un peu après. Et c'est là où je pense que je me suis vraiment rendu compte en fait de ce que c'était. Et donc depuis, j'ai continué à travailler un peu dans ce monde-là. Donc j'ai fait deux ans chez Vincere Collective, j'ai travaillé environ je crois sept mois chez Conto, qui est devenu une licorne aussi à ce moment-là. Je dirais pas que c'est grâce à moi dans les deux cas, loin de là, mais... Mais les deux sont devenus licornes à ce moment-là, donc c'est assez intéressant de voir vraiment les entreprises scaler à mon arrivée. Et maintenant, j'ai rejoint Castor depuis un an maintenant, qui est plus une start-up et qui va aussi devenir une licorne dans les prochaines années.
Terry : Et dis-nous du coup, qu'est-ce que tu peux brièvement… Ouais, Castor, qu'est-ce que vous faites chez Castor ?
Corentin : Alors qu'est-ce qu'on fait chez Castor ? Chez Castor on crée un logiciel, alors je crois que les sales ils vont me tuer, pareil je ne prépare pas. C'est pas grave ils accoutent pas. On prépare une solution de Data Catalog, donc ça va permettre aux équipes de documenter leurs données et de les retrouver. Moi, j'ai été assez séduit par Castor quand j'étais chez Vestercolective. Effectivement, pour l'anecdote, j'ai commencé à travailler avec Castor, enfin commencer à être en collaboration avec eux quand les deux fondateurs, les trois fondateurs à l'époque, étaient encore étudiants. Ils n'avaient pas vraiment monté de structure. On avait commencé à tester l'époque chez Vesterco, du coup. Et ensuite, du coup, j'ai rejoint plus tard l'entreprise quand elle avait déjà commencé à ce qu'elle est en post-serie A. Et du coup, l'entreprise a fourni un Data Catalog, aussi des outils d'observabilité de la donnée, pour les équipes, les différentes équipes utilisatrices de la donnée, qui peuvent être ceux qui fabriquent la donnée, mais aussi, et c'est ce sur quoi on met l'accent aujourd'hui, les utilisateurs, les équipes métiers, qui ont besoin de la donnée pour leurs analyses, et qui vont du coup avoir besoin de Castor pour la trouver, la comprendre et l'utiliser.
Terry : Ok, du coup pour être sûr de bien comprendre ce que vous faites, je me mets dans la peau d'une boîte qui vend des chocolats, je ne sais pas pourquoi je pense ça, mais qui vend des chocolats et qui a quand même pas mal de franchises on va dire, qui a du coup pas mal de données en termes de données clients, de données de vente, de données aussi opérationnelles sur la logistique autour de comment on distribue les chocolats entre la chocolaterie centrale et tout le reste. Bref, beaucoup de données. Via Castor, je vais pouvoir à la fois héberger toutes ces données et ensuite bénéficier de services pour naviguer dans cette donnée de manière intelligente et mieux la comprendre, c'est ça ?
Corentin : Alors, pas tout à fait. Nous, on n'héberge pas la donnée des clients. Et d'ailleurs, pour bien comprendre, on n'utilise même pas la donnée des clients. on ne travaille que sur la métadonnée des clients. Donc la métadonnée, c'est un peu la donnée des données. Par exemple, le client, souvent, va se connecter plutôt à son Data Warehouse. On pourrait se connecter, on a des connecteurs sur les données applicatives, mais dans la plupart des cas, on se connecte déjà à l'entrepôt de données qui est déjà centralisé, sur lequel les équipes ont fait des efforts de centralisation. Et du coup, par exemple, pour l'entreprise de Chocolat, il va y avoir des équipes, une ou plusieurs, qui vont, selon l'architecture, Data Mesh ou pas, de la donnée, qui vont travailler sur l'entrepôt de données et qui vont devoir documenter cette donnée pour que les utilisateurs puissent l'utiliser et créer par exemple des tableaux de bord et l'analyser. Donc par exemple, ils vont dire, voilà, cette table, c'est celle-là sur laquelle je vais stocker les transactions de vente en France ou dans le monde d'ailleurs si c'est généralisé. Sur celle-là, on va avoir les données des clients de mon entreprise. et d'ailleurs c'est comme ça qu'on les connecte la plupart du temps et ça va permettre aux utilisateurs de savoir comment je les connecte, comment je peux la query et comment je peux l'utiliser pour faire mes tableaux de bord. Sachant qu'on documente aussi ensuite les tableaux de bord, et qu'on essaie de fournir beaucoup de solutions pour automatiser la documentation. C'est-à-dire pour faire en sorte que ce ne soient pas les équipes de données qui aient besoin de tout documenter à la main sur Castor, mais plutôt que nous on trouve aussi de la valeur dans les métadonnées directement pour documenter cette donnée.
Terry : Donc je vais rephraser pour être sûr de bien comprendre. J'ai déjà mon infra, un data lake, peu importe l'infraxay, mais il vaut ce qu'il vaut. J'ai un data lake avec les données dont je parlais de vente de chocolat, de logistique autour de la distribution, etc. vous, vous allez venir apporter une couche qui va me permettre en fait rapidement d'exploiter cette donnée là de manière efficace sans avoir à me prendre la tête à devoir potentiellement restructurer mon schéma de base de données et y faire un paquet de...
Corentin : C'est surtout la comprendre en fait, moi j'ai travaillé pour beaucoup d'entreprises quand j'étais prestat où finalement on crée beaucoup de données, on crée beaucoup de données et nos utilisateurs ne savent même pas où elles sont, ne savent pas comment l'utiliser et nous on va leur expliquer comment l'utiliser, on va pouvoir leur dire est-ce que cette donnée elle est de qualité ou pas, est-ce qu'elle est au niveau attendu pour par exemple un tableau de bord critique et on va lui permettre de donner toutes les informations pour qu'elle puisse l'utiliser au mieux. Mais la donnée derrière elle elle va être déjà structurée normalement de la meilleure façon pour être quand même consommable par des tableaux de bord et ça c'est le travail justement des data engineers ou des analytics engineers au niveau de l'entrepôt de données directement.
Terry : D'accord, ok, c'est plus clair. Maintenant, on va quand même, tu viens de parler de data engineer et de la structure des données, ça m'intéresse déjà que tu expliques un peu les différences entre les différents métiers, data scientist, data engineer, et même le troisième, le business analyst, je ne sais pas où tu le positionnes ou potentiellement d'autres un peu. Concrètement déjà, d'un point de vue théorique, quels sont ces métiers ? Et puis après, on va rentrer dans la réalité pratique de ce qui se fait en fait.
Corentin : — Bien sûr, bien sûr. Alors c'est vrai que... Je devrais peut-être garder cette information pour tes fameuses questions de fin, mais je pense que je fais partie des gens qui, de base, vont promouvoir un peu les profils généralistes et donc peut-être éviter la casquette d'un poste en question, même si c'est important d'avoir des rôles clairs et des attentes claires. C'est différent de dire que cette équipe a des attentes, ce rôle en a telle attente par exemple cette année, mais de ensuite se dire, est-ce que par contre je privilégie des profils généralistes ou pas. Donc voilà, ça c'est un peu ma conviction. Maintenant, je vais quand même te parler des différents rôles. Je ne vais pas te parler seulement du full stack, du data full stack ou je ne sais pas comment on pourrait l'appeler. Alors il y en a quand même pas mal des rôles, je vais essayer de ne pas en oublier. Peut-être, je ne sais pas, je vais essayer de faire dans l'ordre chronologique, à la limite. Mais l'ordre chronologique ne sera pas forcément vrai d'ailleurs, parce qu'il y a des rôles qui existaient avant, qui sont revenus à la mode aujourd'hui. Mais bon, dans mon ordre, je l'ai vu émerger dans mon quotidien. Donc vraiment, ce qui a explosé au départ, c'est le data scientist. Je ne sais pas si l'anecdote est vraie ou pas, mais de ce qu'on m'a raconté. D'ailleurs, à l'époque, c'était peut-être une entreprise comme Google qui a testé différents noms de postes, de titres de postes, et qui a regardé lequel marchait mieux, avec des AB test un peu, pour recruter des gens. Et c'est Data Scientist qui est remonté. Et donc ça n'a pas forcément de valeur, finalement, tant que ça a de valeur réelle de définition de poste. Mais le Data Scientist a vraiment émergé, je dirais c'était l'année 2010, 2013, 2015, entre 2010 et 2015. Et pour le coup, quand même, le poste était assez, je pense, toujours proche de ce qu'est un Data Scientist aujourd'hui, c'est-à-dire qu'on s'attendait à ce qu'il nous fasse des modèles de Machine Learning pour faire des prédictions ou de la classification, en tout cas, des choses d'intelligence artificielle. en utilisant des modèles statistiques, donc mathématiques, pour arriver à faire des pratiques.
Terry : Donc quand tu dis aussi machine learning, tu mets quoi derrière ce mot ? Modèle de machine learning, donc modèle statistique, on va dire que c'est assez clair. Quand tu dis modèle de machine learning, tu mets quoi derrière ?
Corentin : Moi, je mets beaucoup les modèles statistiques, justement. Je ne mets pas les autres outils d'intelligence artificielle type Arbre Expert, Armin Max ou ce genre de choses. Je vais mettre vraiment tous les modèles statistiques qui permettent de faire souvent soit de la prédiction, soit de la classification. Mais pas forcément de l'optimisation, l'optimisation linéaire, là je parlerais plus de recherche opérationnelle. Alors deep learning permet de faire quand même les mêmes choses mais on se concentre beaucoup sur les réseaux de neurones. Donc là ça a eu une émergence d'un nouveau poste qui est le deep learning engineer ou le machine learning engineer d'ailleurs. Machine learning engineer fait aujourd'hui du deep learning je pense. Et donc oui c'est beaucoup des modèles statistiques vraiment basés sur les stats.
Terry : Donc des profils quand même plus mathématiciens.
Corentin : À la base ? Oui, je dirais que le data scientist à la base était quand même un mathématicien qui comprenait bien les modèles statistiques et c'est ce qu'on attendait de lui. Et ça d'ailleurs, je vais pouvoir potentiellement dire que c'est aussi pour ça qu'on a Je vais essayer de ne pas être trop négatif, mais on a eu une petite déception, un constat un peu difficile, quelques années après, sur ce poste-là, à ce moment-là. Mais oui, un profil très mathématicien, je crois que beaucoup de postes sortaient de l'ENSAI, il me semble, si je ne dis pas de bêtises, et d'ailleurs de très bons profils de la science. qui comprenaient très bien les modèles et qui savaient les appliquer sur les données des entreprises. Donc on a eu une émergence à ce moment-là du data scientist et quand même un peu la montée en puissance du POC pour montrer qu'on était capable de faire des belles choses en data science.
Terry : Donc le proof of concept, la capacité à faire un proto hyper rapide sans se prendre la tête sur les problématiques d'industrialisation mais pour montrer une preuve de faisabilité de quelque chose avant de passer à l'échelle.
Corentin : Je ne l'aurais pas mieux dit.
Terry : On le répète souvent mais bon on sait jamais.
Corentin : Oui oui tout à fait je crois que je vois pas mal de postes de Rudy que t'as aussi interviewé qui parle de la différence entre POC, MVP et première version qui sont assez intéressants je trouve. Je trouve qu'on a eu un gros succès sur l'époque à ce moment là franchement les entreprises ont vraiment compris la valeur de la data science et c'est pour ça que la data a explosé à ce moment là c'est vraiment parce que ces profils là ont vraiment réussi à prouver leur valeur sur l'époque et à montrer que les modèles statistiques étaient capables de faire des choses assez puissantes pour les entreprises. Par contre, la difficulté, ça a été la mise en production. La mise en production, la scalabilité des modèles, le fait qu'un modèle pouvait durer dans le temps. le fait qu'il pouvait marcher sur l'ensemble des jeux de données, le fait qu'en pratique, il n'y avait pas seulement être capable de vérifier que notre modèle fonctionnait sur les données qu'on avait déjà, mais sur les données qu'on allait avoir par la suite. Et là, ça a été plus compliqué. Je crois que c'est vraiment dans les années 2017-2018 où j'ai fait pas mal de salons, et c'était vraiment le thème numéro un des salons, le problème de mise en production des modèles de data science.
Terry : C'est vrai que ma compréhension, sans être du coup un data scientist ou du milieu directement, mais c'est effectivement que quand tu es dans un format preuve de concept, tu peux te permettre d'avoir la donnée la plus propre possible, d'avoir tout le contexte on va dire qui va bien pour que tes modèles s'appliquent bien, mais quand tu passes en mode industrialisation, dans d'autres applications ça peut être une non-question, c'est-à-dire qu'il faut scaler, passer à l'échelle, on va se mettre sur le cloud et puis on aura les machines qui vont qui vont grossir assez facilement, mais dans le cas de modèle de data science, en fait j'imagine que l'une des problématiques c'est effectivement que tu passes d'un monde où c'est quand même le cœur de la machine c'est la donnée, d'un monde où la donnée tu l'as contrôlée, à un monde où la donnée tu ne la contrôles plus, tu ne sais même pas ce qu'il y a encore.
Corentin : Exactement.
Terry : De mon regard, je comprends bien pourquoi tu dis que c'était le sujet n°1. Donc j'imagine qu'il y a d'autres postes aussi qui ont...
Corentin : Exactement, il y a d'autres postes qui ont émergé, notamment aussi à ce moment-là, je pense qu'avec les problèmes de mise en production, on s'est rendu compte que finalement, généralement, Ce n'était pas le cas pour l'époque où le modèle devenait hyper intéressant à creuser, à optimiser, à paramétrer. Finalement, souvent, ça ne fonctionnait plus au moment de la mise en prod. Finalement, on s'est rendu compte que ce qui marchait le mieux, c'était d'optimiser justement les features, donc les données qu'on avait, et donc de faire du feature engineering. Et là, je pense que c'est vraiment à ce moment-là que le data engineer est arrivé pour vraiment consolider les données, avoir des features qui sont fiables et permettent d'alimenter un modèle.
Terry : Alors là, il faut que tu m'expliques ce que tu entends par feature engineering.
Corentin : Oui, alors le modèle de Machine Learning, je ne suis pas un expert de Machine Learning, donc désolé si tous les modèles ne sont pas comme ça.
Terry : Tu peux faire des généralités.
Corentin : Voilà, je ferai des généralités, et ça dépend aussi si on a la target avant ou pas, ou si on… je ne me rappelle plus le terme. mais on va avoir finalement des colonnes qui vont alimenter notre modèle et qui vont permettre de prédire une colonne cible. Voilà, ça c'est pour un certain type de modèle en tout cas. Et donc ces colonnes qui vont servir d'entrée, vont s'appeler des features et potentiellement, par exemple si on prend un sujet sur Kaggle qui était à l'époque le site pour tester des jeux de données, les entreprises mettaient des jeux de données pour faire des challenges et compagnie, on avait déjà un ensemble de features qui était fini et il fallait juste optimiser le modèle. Aujourd'hui, on s'est rendu compte que finalement il suffisait peut-être d'ajouter une feature, une donnée qui manquait ou de consolider une pour exploser les performances de notre modèle. au lieu de sur-optimiser notre modèle. Donc c'est d'ajouter de la donnée et de la consolider en fait.
Terry : D'accord, donc le feature engineering c'est d'ajouter une donnée particulière pour le modèle et de consolider cette donnée particulière. Exactement, de faire en sorte qu'elle soit.
Corentin : De qualité et qu'elle existe, qu'elle existe et qu'elle soit de qualité.
Terry : Et donc à ton sens, ce que tu dis c'est que ça a vu émerger le rôle de data engineer.
Corentin : Exactement, et aussi je dirais qu'il y a eu un autre pan qui manquait de clarification à ce moment-là, Deux, aussi, il faut être capable de déployer ce modèle en production et les profils, désolé pour les profils data scientist de l'époque, je ne veux pas les blesser, mais ils n'étaient pas spécialement formés pour les déployer en production, faire en sorte qu'ils puissent tourner à haute charge sur des microservices ou ce genre de choses et on a aussi fait appel au data engineer qui était un profil un peu plus informaticien pour aussi déployer les modèles en production. Donc voilà, on a eu l'émergence du Data Engineering à ce moment-là, et je ne sais pas à quel point c'était avant, pendant ou pas, mais finalement le fait de parler de la donnée a aussi fait remonter un sujet qui était quand même assez vieux comme l'informatique, qui était finalement les données, elles ne servent pas que pour des modèles mathématiques, mais elles servent tout simplement aussi à faire des tableaux de bord. Et donc probablement au même moment que l'arrivée du Data Engineer, on a eu pour un autre besoin cette fois-ci des Data Analysts qui sont arrivés, des BI Engineers, pour vraiment faire autre chose. que le data scientist n'était plus pour construire des modèles statistiques, mais juste être capable de montrer la donnée aux équipes métiers et d'être capable d'apporter de la valeur via des tableaux de bord aux équipes métiers. Et ça c'est quelque chose, je m'en suis vraiment rendu compte aussi à Air France, dans le sens où vu que je faisais de la recherche opérationnelle, nous on travaillait quand même aussi sur des jeux de données, ce n'était pas si éloigné du data scientist ou data analyst. On essayait de comprendre avec l'expert métier son problème à optimiser et finalement je me suis rendu compte que l'industrialisation des modèles de recherche opérationnelle était très complexe et souvent n'apportait pas une valeur très franche à l'expert métier parce qu'il suffisait qu'il y ait un paramètre qu'on n'avait pas pris en compte ou quelque chose qu'on n'avait pas anticipé pour que finalement la solution optimale qu'on avait trouvé via le modèle était loin d'être bonne, même bonne sur le terrain. mais finalement j'arrivais à apporter beaucoup plus de valeur en creusant la donnée avec des tableaux de bord pour montrer aux clients c'est quoi ton métier, qu'est-ce qui ne fonctionne pas, qu'est-ce qu'on pourrait optimiser.
Terry : Yes très très clair, juste du coup précise je pense ce que tu optimisais chez Air France en fait quand tu parles parce que du coup ça ne portait pas tant de valeur c'était quoi en particulier ?
Corentin : Oui alors il y avait plein, en fait c'était vraiment tous les sujets où on pouvait essayer de creuser une solution une bonne solution pour le métier dans un ensemble assez fort de solutions pour aider la recherche opérationnelle. En fait, vu que c'était une équipe de recherche opérationnelle, finalement, on essayait pas mal de trouver des besoins où la recherche opérationnelle pouvait aider. Et moi, j'étais sur l'exploitation au sol. Et du coup, on essaie d'optimiser tous les métiers de l'exploitation au sol, donc ceux qui restent dans les aéroports. Et donc, par exemple, on avait des sujets de bagages à Charles de Gaulle. Pour moins les perdre, par exemple, dans les bagages, il faut savoir qu'ils passent par plein de trieurs à bagages. Quand je dis les perdre, ce n'est pas les perdre physiquement, parce qu'en fait, on les retrouve toujours, mais c'est juste perdre un bagage. La perte d'un bagage, on disait que c'était que le bagage n'avait pas réussi à prendre le vol du client. Souvent, c'était dans les correspondances. le client prenait son bagage, le bagage était mis dans le bon avion. L'avion atterrissait notamment à Charles de Gaulle, puisque c'était Charles de Gaulle qui avait des biens d'infrastructure et donc un taux de perte qui était assez élevé, quand je dis assez élevé, c'est très bas, mais pour la satisfaction client. Et donc du coup, au moment donné où le client change de vol, en fait le bagage n'a pas réussi à passer dans tous les triggers à bagage et donc n'a pas réussi à atteindre le vol cible. Et donc du coup, il y avait toute une optimisation derrière, sur savoir comment le bagage, par quel trieur il devait passer selon le parking de l'avion, et ce genre de choses. Mais en fait, finalement, en creusant les données, on se rendait compte que Charles de Gaulle, il y avait des biens d'infrastructure, et donc du coup, qu'il y avait quand même pas mal de pannes de trieur, et que finalement, les pannes de trieur, elles te mettaient un tel coup dans les problèmes que tu avais beau essayer d'optimiser le meilleur scénario, tu pouvais pas trop anticiper une panne, enfin d'ailleurs il y a d'autres algorithmes qui pourraient le faire, mais c'était pas ce qu'on avait choisi là et que finalement on optimisait des miettes par rapport au problème global.
Terry : Ok, hyper intéressant et hyper concret quand même, je trouve ça cool. Donc si je résume trivialement un peu les trois jobs autour de la data, ça a commencé avec les data scientists qui étaient là pour faire les modèles, pour créer des prototypes pour montrer que ces modèles peuvent servir à résoudre des problèmes comme celui que tu viens de décrire. Derrière, ils se sont rendu compte qu'il y a eu des problèmes de ces modèles-là pour qu'ils passent à l'échelle et qu'ils soient utilisés avec beaucoup plus de données sur des infrastructures qui soient aussi exploitables par des développeurs beaucoup plus orientés métier et pas du tout data. Il a fallu mettre ce rôle un peu faisant le pont entre les deux, le data engineer. Et une fois que ça était en place, il y a aussi eu une réémergence de la data analyse, de la.
Corentin : Business intelligence, de la BI qui est redevenue à la mode à ce moment là.
Terry : Pour te paraphraser, le fait de construire des tableaux de bord, des dashboards pour des décideurs métiers, donc qui sont dans la spécialité de ce qu'ils font, que ce soit des assurances, que ce soit du coup des gestionnaires de compagnies aériennes sur des sujets de gestion des bagages ou autre. Et donc est-ce que là, ces trois, on va dire, Paul, ça regroupe un peu les principaux Ça a regroupé à.
Corentin : Ce moment-là et sachant qu'aussi le Data Engineer finalement, parce que je trouve pareil, le BI Engineer en tout cas était aussi peut-être une casquette un peu plus business, le Data Engineer est venu aussi consolider cette partie-là en aidant la construction des données et toutes les pipelines de données et donc à travailler aussi sur le pan de la BI. Donc là, je pense que ça fait quelques années comme ça. Et puis pour moi, finalement, ça regroupe quand même l'ensemble des choses. Il y a peut-être d'autres métiers un peu plus niches de la data pour le MDM, les ERP, enfin des choses qui sont peut-être un peu plus niches dans les plus grandes entreprises, mais je pense que ça résume pas mal l'ensemble des métiers. Et il y a quand même d'autres postes qui ont émergé aussi, typiquement le Machine Learning Engineer, qui est finalement un Data Scientist, qui est aussi Data Engineer. Franchement, je trouve que c'est vraiment le mix des deux. Le Analytics Engineer, qui est typiquement le Data Engineer, qui est aussi BI Engineer. Et donc finalement, je trouve qu'on tend vers le full stack data, le data full stack. Sauf qu'on a juste donné encore d'autres noms de postes là-dessus. Mais finalement, j'ai discuté avec quelqu'un, je ne sais plus quelle entreprise de la tech aussi, qui me disait « tiens, on a remplacé tous les data engineers, on n'a plus besoin de data engineers ». Moi, j'étais vachement étonné puisque étant data engineer, un peu vexé aussi. Comment ça, d'être poste ? Et il me dit, ben oui, on n'a que des analytic engineers aujourd'hui. Et donc quand je lui ai demandé, ok, c'est quoi les missions de ton analytic engineer ? Ah, ben c'est de créer les pipelines. Je lui ai dit, ok, analytic engineer, des fois, il ne fait que le modèle de données. C'est vrai qu'une pipeline, je rentre un peu dans les détails techniques, mais une pipeline, aujourd'hui, c'est l'extraction, load et transforme. À l'époque, c'était l'extraction, transforme, load. Aujourd'hui, dans quelques entreprises, le Data Engineer fait Extraction & Load, et l'Analytic Engineer ne fait que du Transform pour créer le modèle. C'est-à-dire que les données sont déjà en base, mais elles sont sur un format qui n'est pas forcément adapté pour les tableaux de bord. L'Analytic Engineer va transformer la donnée en base pour qu'elle soit accessible facilement dans les tableaux de bord. Bon et là la personne me dit bah non l'analytical engineer fait aussi extraction and load. Bon bah en fait c'est vraiment un data engineer qui fait aussi de l'analytical engineer et je trouve ça super d'ailleurs qu'ils aient pris la même personne parce que ça permet de comprendre tout le modèle.
Terry : Top ouais donc hyper intéressant et je pense c'est bien aussi voilà de remettre un peu aussi le cadre en gros les trois piliers puis derrière les dénominations qui évoluent avec le temps aussi avec les modes donc maintenant ce que j'aimerais c'est qu'on rentre du coup maintenant qu'on a posé ce cadre là sous ton prisme, enfin sous ton expérience que tu as eu dans les différentes boîtes que tu as mentionné, un peu les problématiques auxquelles tu as fait face, entre ce que tu pensais peut-être au début en arrivant dans ces boîtes et ce que tu as dû résoudre comme problème, et je pense que ça va aussi faire écho à pas mal de data engineers ou même de data scientists qui nous écoutent.
Corentin : Peut-être, peut-être. Je dirais que la première chose, c'est que moi, à la base, je voulais, quand je me suis reconverti, entre guillemets, c'est quand même une petite reconversion, la recherche opérationnelle, c'est quand même quelque chose d'assez proche, mais quand je me suis reconverti, à la base, ma cible, c'était d'être data scientist. Moi, ce qui vraiment m'a... fait rentrer là-dedans, c'est DeepMind, donc c'est, tiens, comment on peut faire des modèles de machines et de deep learning, d'ailleurs, puisque DeepMind nous ont fait du deep learning pour Logo, on arrive à faire ça. Donc moi j'étais en tête d'être data scientist et déjà je me suis rendu compte que c'était difficile de me vendre en tant que data scientist et que finalement je suis peut-être arrivé un peu tard où ça y est on ne voulait plus recruter que des data scientist, on voulait aussi recruter des data engineer. Et sachant que j'avais quand même un background un peu différent des gens qui justement sortaient de l'ENSAI et qui avaient une très forte connaissance des modèles statistiques, ce que je n'ai vraiment jamais eu, j'étais prestat consultant à l'époque et j'ai finalement été quasiment mandaté que pour des missions de data engineer. Et c'est là où je me suis rendu compte, tiens, on a ce besoin-là quand même d'industrialisation et on a surtout cette problématique d'industrialisation. On n'y arrive pas et on a besoin de main pour ça. Donc ça ça a été mon premier constat de bah en fait je n'arrive même pas à être vendu en data scientist parce qu'on commence à avoir un besoin fort en data engineer et c'est plus ma casquette et donc bah du coup c'est plus là où j'arrive à aider. Donc bon j'ai fait un petit peu mon deuil, ça a pris un quelque temps et après je me suis dit bon bah quand même je vais continuer là où je suis le plus utile.
Terry : Donc tu devras continuer à battre les jeux de go à la main et pas avec tes propres modèles.
Corentin : Exactement. Et donc ça, c'était le premier constat de tiens, finalement, il y a une difficulté de mettre en prod et ce n'est pas là où j'arrive à me vendre et donc à apporter de la valeur dans une entreprise. Et donc, par mes missions de data engineer, je me suis aussi rendu compte d'une deuxième chose, c'est que aussi, finalement, j'étais plus mandaté par des entreprises qui voulaient des data engineer pour faire de la BI que pour de la data science. Et donc ça rejoignait un peu le côté de finalement à court terme on a plus à gagner à juste, enfin je devrais pas dire juste mais parce que c'est très compliqué, mais à faire des bons tableaux de bord que à faire des modèles. Et donc là j'ai découvert un peu le monde de la BI et le deuxième constat c'était que finalement c'était un monde qui était très très neuf qui et pour lequel on ne savait pas trop où se situer. Il n'y avait pas de standard. Et d'ailleurs, c'est peut-être encore toujours le cas aujourd'hui. On manque un peu de standard. Ça commence à standardiser un petit peu nos façons de faire, même nos objectifs. Mais finalement, on a regroupé tous les gens qui ont voulu cette casquette ou qui avaient le background casquette Tata dans une équipe souvent la même. et pour leur dire, allez, on fait de la data maintenant. Et on ne savait pas trop, on n'était pas sûr de ce qu'on voulait faire. Et souvent, même les fiches de poste n'étaient pas forcément claires. Il y avait de la frustration de la part des data scientists qui, pour le coup, eux, étaient recrutés en data science, qui n'avaient pas forcément l'opportunité de faire des modèles eux non plus, parce que ce n'était pas l'urgence numéro un. Et donc, on ne savait pas trop, finalement, qu'est-ce qu'on pouvait faire rentrer dans le scope de la data. Et ça, je trouve que c'est quelque chose qui est vraiment Très difficile à éclaircir, mais c'est finalement ce que je conseillerais demain à n'importe quel Head of Data d'une entreprise tech, c'est de clarifier quelles sont les attentes des autres équipes, quelles sont mes attentes moi, qu'est-ce qu'on a envie de livrer ensemble pour la conduite des projets. Est-ce que finalement là le besoin numéro un c'est faire des tableaux de bord et comprendre notre métier ? Est-ce que c'est pas ça que j'ai envie de faire ? Est-ce que la cible, c'est faire des modèles de machine learning ? Je crois que tu avais interviewé une personne, j'avais adoré son podcast, j'ai plus son nom, désolé, je suis très mauvais pour les noms, qui travaille dans la biologie.
Terry : La biologie, c'est Charlotte Dupont, c'était la CTO de Biocéanor.
Corentin : Oui. Et donc là, on a une cible qui est claire, c'est d'arriver à créer des modèles, arriver à faire des prédictions. Et par contre, ce n'est pas parce que la cible est claire que le chemin va être tant que ça différent. Oui, elle en parle. Au début, c'est beaucoup de data engineer, c'est beaucoup de mains dans le cambouis. Les modèles qui marchent, c'est beaucoup d'expertise métier. C'est pour ça d'ailleurs que c'est très intéressant ce qu'elle dit, parce qu'elle est experte dans son domaine avant tout, et c'est comme ça qu'elle a réussi à être performante, je pense. Parce que derrière, ce n'est pas juste des modèles mathématiques. Mais la cible était claire dans son besoin. C'est d'éclaircir ce que j'ai besoin parce qu'on peut tout mettre dans la data. Même dans toutes les entreprises pour lesquelles j'ai travaillé, on n'avait pas une limite claire, on n'avait pas un contrat assez clair et d'ailleurs c'est quelque chose qu'on pourrait faire, se dire quels sont les 3-4 points qui feront que ce projet, finalement, ça rentre sous notre scope ou pas. Alors bien sûr, il y a toujours de la flexibilité, surtout dans les startups, là-dessus, mais c'est intéressant de savoir qui devrait être honneur de telle chose. Je me rappelle chez Conto, par exemple, moi j'ai pas mal travaillé sur la fraude avec Bachir, que je salue, et Johanna aussi, et toutes les équipes. Et moi, quelque chose qui m'avait surpris, c'est que finalement j'avais l'impression qu'on était aussi back-end-fraude parfois. C'est-à-dire que Notre rôle était tout simplement de couper les transactions frauduleuses et quel que soit le moyen, mais je dirais que finalement c'est aussi le rôle du back-end pour une banque de dire « Tiens, c'est mon job de couper ». Et par contre, est-ce qu'on est capable de faire des modèles pour être encore plus performants et d'utiliser ces modèles, d'être consommateur de ces modèles pour ensuite couper les transactions ? Mais c'était quand même nous qui visions les règles métiers, ce genre de choses, qui finalement, ça devenait beaucoup de back-end, beaucoup de, ok, si on allait voir les experts, si ça, ça, ça, alors ok, je coupe. Et du coup, il y avait une pression forte là-dessus sur la fraude. Forcément, c'était un sujet hyper important.
Terry : Et donc là-dessus, sur cette ligne fine effectivement du Data Engineer versus un Dev Back qui implémente une logique métier, toi aujourd'hui là, dans ce que vous faites chez Castor par exemple, j'imagine que vous avez des Dev Back et des Data Engineers ou que des Data Engineers, je ne sais pas...
Corentin : Nous, c'est encore différent chez Castor parce que nous, on crée un software as a service. C'est la première fois que je travaille dans une équipe. D'ailleurs, on a renommé l'équipe extraction. parce qu'on n'est pas une équipe data classique comme dans une entreprise, c'est-à-dire que notre rôle n'est pas de faire soit du machine learning soit de la BI, notre rôle c'est vraiment d'extraire la donnée des clients et de fournir le data catalogue et donc on est des pipelines au service des full stack engineers et donc du coup finalement on est.
Terry : On.
Corentin : Est des gens qui ont construit un software, mais on s'occupe vraiment du scope des pipelines de données.
Terry : Donc vous êtes plus en fait sur la partie dev avec cette compréhension de ce qui est nécessaire pour les métiers que là tu représentes aussi.
Corentin : Mais voilà, nous notre client n'est plus un métier comme c'était le cas souvent dans les équipes BI. Nos clients sont les vrais clients de software en fait, c'est ceux qui vont consommer la donnée via notre software.
Terry : Et du coup, je suis curieux un peu de creuser ça, peut-être par expérience aussi passée, soit chez Air France ou chez Vestiaire, en tout cas sur comment, sur cette répartition, enfin, sur cette ligne entre le Data Engineer et le Dev Back, en fait. C'est-à-dire que sur ces sujets très orientés de données, est-ce que tu as vu des orgas, ou est-ce que même en échangeant avec tes pairs, des orgas dans lesquels tu as le Data Engineer qui est vraiment là pour faire le pont entre les modèles, ou en tout cas mettre en place les pipelines qui vont bien, et qui laisse la charge au DevBank de vraiment connecter ça via des microservices sur des logiques pur métier. Ou est-ce qu'en fait tu as plus vu des data engineers qui se retrouvaient aussi à implémenter complètement des microservices qui allaient direct ensuite passer dans le cœur des applications sur lesquelles tu bossais ?
Corentin : Oui, honnêtement, je pense que la réponse n'est vraiment pas facile. Parce que justement, on manque de standards là-dessus, on manque de recul, c'est quand même neuf. Donc je n'ai pas une conviction forte. Là-dessus, je pense que le plus important c'est d'être clair et de se dire, tiens, est-ce que du coup je prends ce projet parce que ça rentre dans mon scope ? Parce que sinon, finalement, ça sera très facile pour un métier de dire, ah mais il y a de la donnée dans mon projet. ça devrait être l'équipe de Data Engineer, ben non, parce que les équipes full stack elles manipulent énormément de données, elles sont d'ailleurs très fortes pour manipuler la donnée transactionnelle, souvent bien meilleures que les Data Engineer qui eux travaillent beaucoup sur de la donnée qui sont... la donnée d'analyse, la donnée qui va servir à être agrégée. Donc voilà, moi c'est... Je n'ai pas une conviction aujourd'hui, mais le choix que je ferais aujourd'hui, c'est justement ça, c'est de me dire, OK, est-ce qu'on a besoin de beaucoup d'analyse, d'agrégation, d'être capable d'agréger de la donnée ? Dans ce cas-là, ça peut rentrer dans une équipe de data. Même pour des modèles, on a besoin finalement d'un ensemble de données, un modèle pour qu'ils l'apprennent. ou on a besoin d'agréger des données pour faire les tableaux de bord, ou en tout cas de construire la donnée qui va être agrégée pour les tableaux de bord et donc de comprendre comment elle doit être agrégée. Ce n'est pas forcément le cas pour des moteurs de règles, pour reprendre l'exemple de la fraude, où là finalement une donnée transactionnelle va souvent être bonne. Et ça va être juste des... on va query des lignes de notre base de données, et plus un ensemble de lignes, pour juste dire est-ce que parmi ma ligne, cette valeur est plus grande que ça, plus faible que ça ? Ok, dans ce cas-là, je rends un.
Terry : Tel pattern, — Donc dans le cas où la donnée est déjà prête, ce que tu dis c'est que c'est plus...
Corentin : — Si on n'a pas besoin d'agrégation, je pense que ça peut être un bon signal que c'est pas forcément l'équipe d'Atta qui doit prendre ça. Si on n'a pas besoin d'un ensemble de données historiques... Par exemple, je reprends le cas de la fraude, Par contre, je trouvais ça hyper intéressant que les équipes de BI fassent des tableaux de bord pour comprendre avec le métier et co-construire les règles. Parce que là, on a besoin d'agrégation de données. Mais ensuite, développer ces règles sur les données transactionnelles, ce n'est pas forcément intéressant. Et en plus, ça peut pénaliser parce que, du coup, on va se dire, OK, nous, dans une architecture microservice, on n'a pas forcément accès à ces données transactionnelles. Et donc du coup on va devoir les rapatrier, on va devoir les rapatrier en temps réel, on va devoir les rapatrier dans une base de données qui est transactionnelle et pour laquelle souvent les data engineers on n'a pas forcément une expertise forte et donc du coup on va pouvoir mal s'orienter sur la base de données et choisir une base de données pour laquelle on a l'habitude de travailler qui est plus une base de données d'analyse et donc du coup ça peut amener des erreurs dans le développement du projet.
Terry : Hyper intéressant sur ce point, du coup ça m'amène aussi, je suis curieux de savoir aussi chez Vestirco, l'expérience que tu as eue autour, parce que là tu l'as mentionné en trame de fond parce que pour toi c'est évident, mais je pense que ça n'est pas nécessairement pour nous tous le sujet de la qualité de la donnée, c'est qu'en gros tu disais si jamais la donnée elle est déjà prête, et qu'elle est accessible de manière simple, sans agréger des paquets de données mais en allant ligne par ligne pour caricaturer, potentiellement t'as peut-être pas besoin d'un data engineer pour faire ça. En revanche, pour agréger cette donnée, pour la rendre mangeable, ça se dit pas, mais pour la rendre consommable, là tu vas plus avoir besoin d'un data engineer. Du coup, je suis curieux un peu de savoir, toi, dans ce cadre-là, est-ce que ça a été des problématiques que t'as pu rencontrer chez Vestirco, notamment dans un cadre de croissance hyper rapide, comme tu parlais du passage en mode start-up valorisé à un milliard, comme le dit Korn.
Corentin : Oui, l'exemple d'Asierco, il est assez parlant. Moi, je suis assez fier de ce qu'on a réussi à faire tous ensemble dans l'équipe Data, qui était finalement... L'objectif était quand même de populariser l'usage de la donnée et de faire en sorte que, finalement, l'usage de la donnée soit accessible à tout le monde et que tout le monde ait accès à la donnée pour faire ses analyses.
Terry : Que je sois un tech ou pas dans la boîte.
Corentin : Exactement, que je sois un tech ou pas. Et il y avait aussi, et c'est là où on voit que forcément il y a déjà peut-être quelque chose à éclaircir, il y avait aussi une équipe de data science qui, eux, devaient créer plutôt des microservices de prédiction et trouver des cas d'usage. Mais c'est là où on voit qu'il y a quand même deux choses qui sont très différentes qui est la BI et la data science. Et moi qui étais data engineer, j'étais un peu au milieu et donc je travaillais avec la BI et la data science. Je pense que, par exemple, on aurait pu éclaircir vraiment ça dès le départ et se dire, OK, on a fait qu'on a une équipe qui, la target, c'est des tableaux de bord, et donc on a des data engineers et des BI engineers là-dessus, et on a une équipe, la target, c'est des microservices de data science, on a des data scientists, des machines learning engineers, des data engineers dans cette équipe-là. D'ailleurs, c'est le cas, je crois qu'ils ont fait ça aujourd'hui. Mais l'usage était vraiment de populariser la donnée, donc il y avait vraiment un enjeu de confiance quand même là-dessus. Et il y avait un enjeu de rapidité qui est, je pense, vraiment le combo le plus passionnant et la question à un milliard de comment améliorer la célérité de nos projets tout en perdant en confiance et en qualité. Et donc du coup, on devait vraiment être capable de créer très vite cet entrepôt de données pour que toutes les équipes métiers puissent l'utiliser, mais qu'elles puissent l'utiliser en confiance pour, eux, créer leur dashboard. Donc comment on a fait ça ? On a d'abord créé aussi une équipe BI Engineer qui, elle, a modéliser la donnée et à commencer à créer les premiers tableaux de bord. Et ensuite, l'équipe BI Engineer a été en charge de populariser ces méthodes-là aux data analysts que j'ai oublié de mentionner dans mon introduction de poste tout à l'heure, mais qui étaient plutôt des profils très métiers, vraiment très métiers, avec pas forcément une compétence tech accrue. et donc de populariser l'usage en leur apprenant à utiliser des outils comme Tableau et faire un peu plus de SQL.
Terry : Tableau du coup, si je dis pas de bêtises, équivalent de Power BI.
Corentin : Exactement, concurrent de Power BI et de Locker.
Terry : Voilà, en troisième comme ça c'est bien.
Corentin : Ça c'est les trois plus gros et il y en a plein d'autres mais c'est les trois plus gros. Et donc du coup on avait vraiment cette volonté là de créer un entrepôt de données centralisé donc un Data Warehouse et de l'ouvrir à toute la boîte.
Terry : Et du coup, désolé je te coupe là-dessus, ce que tu disais sur la pertinence de ça, c'est-à-dire que quand tu disais le gros challenge a été à la fois d'être capable de faire ça vite mais en même temps de pas passer pour des brocs six mois après parce que la donnée qu'on a mis à dispo de ceux qui sont confrontés au métier c'est du n'importe quoi, c'est vraiment ça que tu disais, c'est que là si tu mets vite à dispo à tout le monde accès pour construire des dashboards, Power BI ou autre avec du drag and drop et des clics sur des connecteurs de données mais qu'en fait ces données-là elles sont assez mauvaises, ça peut avoir des conséquences dramatiques sur le business. Donc c'était aussi ça l'enjeu.
Corentin : Bien sûr, bien sûr, parce que c'est vrai qu'on dit souvent qu'on a besoin de la donnée pour prendre une bonne décision, mais quand on prend une décision sur une mauvaise donnée, ça peut être pire. Mais je dirais que l'avantage c'est que normalement, si on prend une décision sur de la mauvaise donnée, À moins que vraiment les données soient catastrophiques au niveau de notre entrepôt de données, normalement, on va se rendre compte, au moins que la décision n'était pas bonne. Alors que quand on prend une décision sans données du tout, on ne s'en rend même pas compte. C'est ça la grosse différence quand même. Mais oui, effectivement, ça, c'était vraiment ultra capital. Je pense qu'on a assez bien géré ça, honnêtement. Il faudrait interviewer quelqu'un qui était côté métier. J'ai discuté d'ailleurs avec Philippe qui travaillait en data analyst chez Vesterco et qui m'a rejoint dans l'équipe data chez Conto. Donc j'ai pu discuter un petit peu et lui demander un peu de feedback sur ce qu'on faisait parce qu'il était consommateur de notre donnée. Mais effectivement, j'ai l'impression qu'on a plutôt bien géré et surtout avec deux éléments forts, c'est de la communication déjà vraiment, être capable de dire ben voilà on essaie d'aller vite aussi et donc ça peut être normal de d'avoir des erreurs dans nos données et on fait confiance pour nous les remonter. Et du coup, c'est le deuxième point, c'est d'être capable d'avoir une très bonne communication, c'est le premier. Et le deuxième, c'est d'être capable d'itérer très vite, de prendre le feedback très vite. Et là, on revient vraiment aux méthodes agiles qui peuvent revenir dans la data, qui est, on essaie de construire assez rapidement de la valeur et on est surtout très ouvert au feedback, au retour utilisateur et on itère très rapidement pour progresser là-dedans. Je pense que c'est le point fort des itérations rapides, c'est que finalement, même s'il y a des choses qui ne marchent pas tout à fait au début, en prenant en compte le feedback, on augmente immédiatement la confiance. Et ensuite, on va beaucoup plus vite ensemble en co-construisant une solution avec des experts métiers qui sont très rapidement capables de nous dire, là, Stashboard, vraiment, ce n'est pas possible. Ma transaction, elle n'a pas pu être divisée par deux depuis la semaine dernière, c'est qu'il y a probablement un problème dans ta pipeline.
Terry : — Ouais, donc ça aussi, c'est hyper intéressant ce que tu dis, c'est de rappeler un peu l'importance, notamment, tu vois, tu mentionnais au tout début chat GPT, mais c'est l'intelligence humaine, en fait, et la capacité critique qu'a le cerveau humain. Certes, on peut pas faire les calculs sur des masses de données que peut faire un ordinateur, en revanche, Voir qu'une donnée est complètement incohérente, un point qui est parti dans l'espace, clairement c'est là aussi...
Corentin : C'est hyper dur, c'est là où Jadipiti moi je trouve son point faible en fait, c'est tout simplement d'arriver à trouver une solution qui est mathématiquement cohérente. Je suis impressionné par ses capacités à créer du code, parce que pour moi ça me paraît être le même problème finalement, d'arriver à créer quelque chose qui répond à un besoin.
Terry : Je pense qu'il y a tellement de.
Corentin : Ressources sur Stack Overflow qu'il a dû.
Terry : Bien scraper les bons sites et du code assez propre.
Corentin : Par contre, effectivement, dès qu'on lui pose des petits problèmes mathématiques, on se rend compte que la réponse n'est pas cohérente. Par contre, là où il est très fort, c'est de créer du contenu qu'un expert va valider, mais il va vouloir accélérer sur la mise en forme de son contenu dans un article par exemple. C'est impressionnant là-dessus.
Terry : Donc hyper, hyper personnel. Du coup sur ce sujet, puis le sujet aussi de capacité d'itération, d'itérer rapidement aussi, d'où l'intérêt de ce métier-là de Data Engineer comparé au Data Scientist qui va être plus... Si je devais, tu vois, vraiment caricaturer aussi le job qui est plus en mode R&D côté Data Scientist versus le Data Engineer qui est plus dans l'opérationnel, enfin qui est entre les deux quoi. Mais du coup, qui va assurer ce test and learn entre ce qu'on met en prod versus les retours. Ensuite, on ajuste parce qu'il y a aussi ça, j'imagine, dans la réalité du métier, qui est qu'il n'y a pas tout qui peut être planifié. Il y a des choses, tu ne sais pas trop, tu le mets en prod et tu vois aussi... Et je.
Corentin : Trouve, alors là, pareil, je n'ai pas assez d'expertise sur les autres métiers de la tech, mais je trouve que sur les problématiques data, Surtout sur les problématiques de data science, c'est très compliqué de faire un POC, justement de valider que la solution va fonctionner. Et c'est ça qui rend les choses pas forcément simples dans la relation, par exemple, dans une équipe produit et une équipe data. c'est que c'est un peu plus compliqué selon moi d'être capable de valider la solution ensemble et de se dire ok bah là on part sur un mois de développement et ça va fonctionner. J'ai l'impression que c'est un peu plus simple dans les autres métiers de la tech mais vraiment n'hésitez pas à me taper sur les doigts si c'est complètement faux. Mais ça arrive assez souvent qu'on se rend compte à la fin qu'en fait c'est quand même très compliqué, que les résultats sont pas forcément bons et c'est là où il faut être capable d'itérer très rapidement.
Terry : C'est-à-dire que ce n'est pas forcément simple d'arriver à construire cette solution qui répond aux besoins de l'équipe produit.
Corentin : J'ai l'impression que dans les autres métiers de la tech, à partir du moment où on a validé le besoin, on arrivera généralement à... Avec tous les problèmes que toutes les personnes de la tech connaissent, c'est-à-dire avec des délais qu'on n'avait pas anticipés, des problèmes de scale qu'on ne connaissait pas. Mais généralement on est assez confiant pour dire ok on est capable de créer quand même cette interface qui permette de faire ça. Pour les problèmes data c'est arrivé plusieurs fois que finalement on se casse les dents et que le modèle on n'arrive pas à le sortir, qu'on n'ait pas de modèle qui soit bon pour ce cas d'usage et en fait du coup le modèle n'apporte pas la valeur attendue et on n'est pas capable de sortir.
Terry : Ouais, c'est vrai, dans le produit en fait, le cœur du jeu c'est d'être sûr de trouver le bon problème qu'on veut résoudre. C'est vraiment se dire quel est le problème auquel je veux apporter une solution. C'est vrai que quand t'es dans des cas d'usage, je veux utiliser la donnée pour supporter mes problèmes, pour créer du coup de l'usage, c'est pas la même approche que de dire je suis sûr que c'est ce problème que je veux résoudre, là t'es plus en mode de te dire j'ai de la donnée, comment est-ce que je peux l'exploiter pour venir et t'es pas sûr de cette capacité d'exploitation.
Corentin : Et donc, il va y avoir plus de co-construction, j'ai l'impression, avec l'équipe produit, pour se dire, OK, du coup, on va adapter. OK, peut-être qu'on n'est pas capable de répondre à ce besoin-là précis. Est-ce que, finalement, on ne peut pas répondre à ça ? Est-ce que c'est intéressant pour toi ? Et voilà, d'évoluer un petit peu au fur et à mesure le besoin.
Terry : Hyper intéressant parce qu'il y a quand même pas mal de PM qui écoutent ce podcast, donc aussi pour justement comprendre aujourd'hui qu'on est sur un job, le data engineer, et puis les métiers autour de la donnée qui sont aussi des jobs récents, et dans lesquels il y a ces problématiques de ne pas toujours savoir si on peut faire ou non, et donc cette approche de... Ça c'est.
Corentin : Très spécifique vraiment je dirais aux problèmes de data science et de machine learning, et donc de data engineering associés, mais c'est quand la target c'est de faire de la prédiction, de créer de la valeur, d'arriver à Voilà, c'est peut-être un peu moins le cas pour de la biaille où là, à priori, quelqu'un qui produit sait que cette donnée on l'a, alors parfois elle n'est pas forcément de très bonne qualité, mais c'est pareil. Il y a des fois où on n'est pas capable de la cliner, de la rendre parfaite, mais j'ai l'impression que c'est plus prédictible. On veut faire ce tableau de bord, ok, on va y arriver. Il y aura des délais, il y a des délais de toute façon. On n'est pas très bons pour estimer, je crois. Mais voilà, ça c'est plus sur les problématiques de data science. Je pense là où il y a des frustrations parfois, sur ces postes-là. Et moi, c'est quand même ma conviction, c'est que surtout dans la tech, à moins qu'on tombe sur, vraiment, on crée une entreprise qui veut faire de la prédiction. C'était le cas pour l'entreprise de biologie, c'est le cas pour une entreprise comme OpenAI, c'est le cas pour DeepMind. Finalement, pour des entreprises type Vestierco, c'est pas le cœur de métier de faire de la prédiction, c'est plutôt on veut faire de la prédiction ou on veut faire ça pour optimiser le métier ou pour ajouter des features sur le site web qui sont sympas pour le client. Là-dessus, finalement on se rend aussi pas mal compte que on est capable de faire des choses avec des solutions assez simples, par exemple juste avec parfois des requêtes SQL et c'est là où la limite va être assez floue avec le back-end, c'est que finalement quand on se rend compte, on se dit tiens j'ai besoin de tel problème, ah c'est de la data parce qu'il y a de la donnée derrière, alors que c'est pas forcément de la data pour ça. et on va se mettre sur la data science. La data science, elle va faire plus ou moins ses preuves, ça dépend, et on pourra se dire ok, ben finalement quand on teste cet ensemble de query, ça va fonctionner et du coup ça reste l'ownership de la data alors que c'est pas forcément son cœur de métier.
Terry : Ouais, non, c'est très clair et du coup c'est des fois prendre un peu un marteau pour tuer une mouche quoi. C'est un peu le fameux...
Corentin : Exactement. Et moi, ce que j'avais apprécié dans l'expérience Vestiaire, c'est qu'il y avait, je trouve, une très bonne... Il y avait un très bon, je ne dirais pas compromis, mais on essayait de répondre un peu à ces deux besoins-là. Adrien a parlé sur, je crois, une conférence qui était hyper intéressante avec Adrien. C'était mon chef chez Vestiaire Co. Petite dédicace à lui également. et je trouvais qu'elle était très bonne là-dedans justement pour à la fois répondre aux besoins métiers, c'est-à-dire on va essayer de trouver où est-ce que la donnée elle peut nous aider, on va essayer de construire avec des équipes et souvent pour la data science là on travaille avec des équipes tech parce que c'était pour rajouter des features ou sur le site web, on va essayer de se dire, allez, où est-ce qu'on va pouvoir utiliser du machine learning ? Et après derrière, est-ce qu'il y a quand même des solutions pragmatiques pour faire une première version MVP, pour déjà commencer à créer de la valeur ? J'ai par exemple, j'ai travaillé avec Piotr, je fais un peu du name dropping, mais ça me fait plaisir aussi de... sur un problème où chez Vestiaire Co, un client quand il met un produit, donc Vestiaire Co c'est un peu, je ne suis pas vraiment concurrent de Vinted parce que c'est sur deux secteurs d'activités différentes, mais Vestiaire Collectif c'est un peu plus sur le luxe que Vinted, c'est pas le même panier moyen mais derrière c'est quand même la vente de vêtements surtout de seconde main.
Terry : Ouais moi j'ai pas bossé pour eux donc je peux le dire de manière plus... je peux faire la grosse métaphore qui en gros c'est le Vinted des gens plus aisés. Je pourrais rendre la métaphore... Ouais carrément.
Corentin : Je pense effectivement le panier moyen rien à voir et la cible on est moins sur les étudiants quand même.
Terry : Et donc ce qui est hyper important c'est la qualité et je pense que c'est ce sur quoi tu allais venir dans la qualité des produits ou je.
Corentin : Sais plus si... Non, c'était pas forcément ça, même si, alors là pareil, il y avait énormément de besoins où justement on a essayé de creuser comment on est capable de faire là du deep learning, parce que surtout pour le traitement de l'image, le deep learning est très très fort, les réseaux de neurones, là on est plus là-dessus. Comment on est capable de, par exemple, déjà donner une première indication de si un produit est faux ou pas, même si les produits passent par quand même les moulinettes des experts de Vestirgo. Mais là, le problème en question, c'était d'être capable de dire au client quand il pose son produit, d'être capable de le guider sur un prix de vente optimal. Et je me souviens, la première version qu'on a faite, c'est on a mis des données dans un Elasticsearch. et on a fait des agrégations, on a essayé de trouver les articles similaires aux produits vendus par le client, d'abord juste avec des attributs de texte, même pas des images, et on va faire une moyenne pondérée là-dessus. Et là, on se rend compte que finalement, c'est une approche qui est quand même assez pragmatique parce qu'on n'a pas utilisé de deep learning dans la première version pour ça. On a essayé de faire le plus rapide une première version qui apportait de la valeur, mais derrière, C'était quand même intéressant que l'équipe Data prenne ce sujet, parce qu'il y avait vraiment un sujet d'agrégation des données, d'essayer de trouver les articles similaires, d'agréger ça. Là-dessus, il y avait vraiment, je pense, une expertise Data dans le sens Data Engineering, Data Science intéressante. Ensuite, ils ont fait une deuxième version, là avec du Deep ou du Machine Learning, qui a battu ce modèle-là d'Elasticsearch. Mais voilà, c'est l'idée qu'Adrien a essayé de faire, j'ai l'impression en tout cas. C'est à la fois de répondre à des vrais problèmes métiers pour apporter de la valeur, mais à la fois aussi, dans un second temps, d'être capable justement de faire un peu plus de R&D sur le machine learning, d'être capable de montrer que ça apportait de la valeur, d'être capable de montrer qu'on était capable de mettre en production ce type de modèle. Et honnêtement, le résultat est assez convaincant. C'est-à-dire qu'aujourd'hui, je ne connais quand même pas tant que cette boîte. qui ont des modèles en prod, vraiment de machine learning ou de deep learning, et c'est tel cas sur Collectiv.
Terry : Super, merci pour tous ces partages, hyper inspirants, et puis c'est bien de mentionner cet aspect, c'est pas tout noir ou tout blanc, mais vraiment cet aspect aussi progression entre ce rôle data engineer versus software back et derrière qui a permis de mener à mettre plus vraiment là de R&D pur et de deep learning. Et donc une approche aussi très pragmatique, ça c'est quelque chose parfois qu'on peut tendance à avoir oublié quand on est dans des Dans des secteurs très spécialisés, on se dit que l'Amazonia est pourrie, on n'a pas besoin de mes compétences, mais en fait, il faut aussi amener. Ce que j'aime dire aussi sur le podcast, de manière transverse, peu importe les sujets, c'est qu'on est dans des métiers qui n'existaient pas il y a 10 ou 20 ans, donc qui sont en train de se créer. On se structure tous à part l'échange, c'est aussi pour ça qu'il y a plein de podcasts, plein d'articles, tout le monde écrit, donne ses avis. Et par rapport à cette structuration et cette évolution des jobs dans la tech, il y a aussi cette importance, je pense, de prendre sur soi parfois quand, entre la théorie qu'on aimerait appliquer à la lettre et la réalité business, il faut faire les premiers pas, des petits pas, pour emmener...
Corentin : C'est vraiment le principe de l'agile. C'est pareil, je n'ai pas d'expertise sur les process Chrome et compagnie, mais j'ai l'impression qu'en tout cas, derrière, l'idée de fond, c'est l'itération rapide.
Terry : Non, clairement. Donc avant d'aller vers mes deux questions de fin d'épisode, même s'il y en a une, tu pourras redonner ta réponse ou en trouver une autre si tu veux. Est-ce qu'il y a un sujet autour de la data qu'on n'a pas touché du doigt ou que tu aimerais accentuer ?
Corentin : Oui, je vais parler aussi de Castor parce que je l'ai utilisé en tant que client chez Vastirco, j'étais un des premiers clients de Castor. Et je pense que c'est justement un peu les outils qui vont être nécessaires pour revenir un peu au sujet initial, la question initiale de comment donner de la confiance aux utilisateurs. Et typiquement, c'est par de la bonne communication et par de la bonne documentation. Et du coup, l'étape d'après, une fois qu'on a chez Vestiaire Collective créé cet entrepôt de données, on a commencé à avoir de plus en plus d'utilisateurs et donc de plus en plus de personnes qui nous ont tout simplement posé des questions tous les jours sur comment utiliser cette donnée, est-ce que cette donnée était fiable ou non. Il y avait d'ailleurs quelque chose qu'à la fin on essayait de toujours éviter, c'était que l'utilisateur nous dise qu'il y avait un incident sur nos données. L'idée c'était toujours d'être capable de déceler l'incident avant, même si c'est très dur en pratique parce que vraiment on revient au problème initial, l'œil humain, l'expert humain est capable de voir immédiatement un problème alors que c'est beaucoup plus compliqué avec des algorithmes quand même là-dessus. Et donc ça a été un peu l'étape qui a très bien fonctionné je trouve chez Vestiaire et qui m'a convaincu de travailler pour Castor, c'est d'arriver à populariser cette donnée, à tout simplement la rendre visible et donc tout simplement de fournir un peu un moteur de recherche sur ces métadonnées pour que les utilisateurs comprennent comment l'utiliser, Tout simplement, moi c'est, et pourquoi j'en parle, c'est aussi que c'est une conviction que peut-être ça vient sur le côté un peu full stack, mais c'est que j'aime bien cette idée de généraliste. Et donc c'est important pour moi que les data engineers progressent sur l'aspect métier et comprennent les enjeux métiers derrière leur travail, mais aussi que les personnes côté métier progressent sur les aspects techniques pour être capables aussi d'identifier facilement des problèmes, de faire leurs propres requêtes et donc de progresser sur un aspect assez général. Et donc c'est tout simplement aussi ces solutions-là qui vont permettre d'accompagner les métiers, d'avoir des un peu une autre façon d'utiliser la donnée qui va être plus décentralisée et donc ça me permet de parler aussi du data mesh qui est un concept qui a pas mal explosé il y a quelques années et du fait que tout simplement on peut avoir une architecture data et donc des équipes qui sont décentralisées et qui partagent des mêmes pratiques ou des mêmes entrepôts. Et c'était, je dirais, pas 100% le cas chez Vesti-Arco parce que c'était pas tout à fait décentralisé. Il y avait une équipe de data engineer, data scientist, data engineer qui était centralisée. Mais derrière, il y avait des équipes de data analyst qui étaient très décentralisées, qui étaient capables de créer des tableaux de bord, capables de faire des requêtes. Et donc, c'est vraiment les débuts d'un data mesh. Donc voilà, c'est ce sur quoi je trouve qu'on doit aussi mettre l'accent en tant que producteur de données et donc on a des clients qui sont les équipes métiers, les business users et c'est quelque chose sur lequel on peut progresser et je pense qu'en tout cas des solutions comme Castor permettent de faire.
Terry : Très très clair du coup à l'importance d'évangéliser ça et puis de donner accès à d'autres à d'autres domaines métiers de la boîte sans se retrouver face au goulet d'étranglement que tu n'as pas autant de data scientist que tu vas avoir.
Corentin : Je trouve qu'il y a la même problématique chez les DevOps. Pareil, il y a plusieurs termes d'ailleurs, SRE, DevOps, mais dans la tech, je pense que tu pourrais faire un podcast entier avec des... Tu en as déjà fait un ?
Terry : DevOps, pas encore. On en a parlé un petit peu avec Rudy, mais c'est effectivement un bon sujet à creuser.
Corentin : Ah ouais, c'est un super sujet. Il y a ce même problème de... Il y a un problème identifié dans l'entreprise, c'est comment scaler quand même. On se l'est tous mangé quand même dans la tech à un moment donné, avec différentes solutions microservicielles versus monolithes, plein de choses. Est-ce qu'on fait des solutions managées ou pas ? Et finalement, je trouve, c'était le cas chez Vasterco, chez Conto, et ce sera le cas, à mon avis, chez Castor, quand on va escaler, d'évangélisation, c'est-à-dire que c'est le job d'une équipe centrale DevOps, d'évangéliser ça, de produire des outils qui vont permettre aux autres équipes de faire aussi du DevOps. Et c'est un peu ça, je pense, le cheval de bataille aujourd'hui, c'est d'être capable de produire des outils pour que, tout simplement, d'autres personnes s'y mettent. C'est aussi pas mal quelque chose de, une bonne problématique de Data Engineer, on a beaucoup d'offres de poste pour des créations de ce qu'on appelle la Data Platform avec vraiment du coup des utilisateurs de cette Data Platform qui seront des équipes plus business.
Terry : Très clair, du coup pour aller vers mes deux questions même si il y en a une que tu peux te répéter il n'y a aucun problème. La première donc c'est, est-ce que tu as une conviction forte, tu en as partagé plusieurs en tout cas, avec laquelle tu te retrouves en général en désaccord avec tes pairs ?
Corentin : Donc oui, je pense que c'est un peu l'importance des profils généralistes, des profils qui comprennent à la fois le métier, la technique, qui sont capables et intéressés de travailler sur différents secteurs. Moi, j'ai eu un peu des fois ce regret. C'est pour ça aussi que le deuil a été... J'ai rigolé tout à l'heure sur le deuil de la data science, mais finalement, il a été assez... Facile quand même parce qu'avant tout ce qui m'importe c'est de créer des choses qui ont de la valeur et avant de me spécialiser dans un domaine pour lequel je n'arriverai pas à créer de la valeur. Et donc je trouve qu'on a tous à gagner à évoluer, voir quels sont les secteurs qui vont permettre de créer de la valeur dans l'entreprise. Et pour ça, une bonne technique, c'est quand même de maîtriser plusieurs aspects. Je pense que le monde de la data est suffisamment jeune pour qu'il soit rare, à part dans une entreprise spécialisée en machine learning ou de prédiction, pour qu'on n'ait pas besoin de faire du trop compliqué pour apporter de la valeur. Et donc, dans ce genre de cas, typiquement, je pense qu'on peut briller avec un profil très généraliste parce qu'on sera capable d'intervenir sur des choses très différentes et de ne pas spécialement faire quelque chose d'extrêmement compliqué sur un domaine de niche.
Terry : Hyper intéressant. Vas-y, t'as un deuxième ?
Corentin : Est-ce que j'ai un deuxième ? Là, en ce moment, je suis en train de me creuser la tête sur tout ce qui est estimation. Voilà, c'est un sujet, je pense, que pour le coup, on partage avec toute la tech. Je commence à m'intéresser un petit peu sur ce que, justement, je vois pas mal Redi en parler, peut-être Mathieu aussi, sur le... Finalement, est-ce que ça vaut le coup d'estimer ? Donc je serai plus partagé que, ça sera moins une conviction forte, mais en tout cas ça m'interpelle pas mal et je me dis qu'effectivement est-ce que le principal c'est pas de découper assez petit, d'être capable d'y rétérer vite et finalement est-ce qu'on gagne à scorer. Je crois que t'en as discuté d'ailleurs avec Rudi dans son podcast, t'as été un peu plus tempéré justement, et j'ai bien aimé ce que t'as dit, je sais plus si c'était dans le podcast ou sur un de tes posts LinkedIn, mais pour dire justement, c'est quand même important pour une chose le scoring, c'est pour être capable de voir est-ce qu'on a progressé, est-ce qu'on va plus vite qu'avant sur certaines choses, et là je partage pas mal ton opinion.
Terry : Ouais et aussi j'ajouterais pour moi ce qui est important aussi la raison du scoring c'est pas tant est ce qu'on va réussir à maintenir ce qu'on avait dit mais effectivement de voir déjà si on a progressé et aussi en fait d'aligner les personnes sur du fait d'estimer tu réfléchis un peu plus avant de donner des chiffres et donc t'es sûr que tout le monde a bien compris les problèmes que tu veux estimer donc t'alignes plus facilement à mon sens les gens sur les problèmes sur lesquels il faut se concentrer.
Corentin : Comme quoi c'était pas une conviction forte. Estimaux.
Terry : Maintenant sur la deuxième question, les recos, lectures, articles, blogs ? Si t'as pas tous les noms, on les mettra dans les notes de l'épisode.
Corentin : Non mais j'aime beaucoup ça, j'avais préparé, si je capte. Alors en podcast, eh bien bien sûr, je recommande ton podcast que je trouve très intéressant.
Terry : C'est gentil.
Corentin : Dans le genre, j'aime bien, If This Then Death, j'écoute pas tous, mais j'aime bien, je trouve que c'est assez intéressant. Je crois que c'est les mêmes personnes derrière, de Génération de 8 sur 5. C'est pas Mathieu Stéphanie, mais c'est la même boîte. La génération de la vie sociale est assez intéressante pour le monde de la start-up, mais beaucoup plus high-level et politique, je dirais. En tout cas, j'apprécie quand même, on en discutait tout à l'heure, le fait d'interviewer des gens plus proches du terrain, et ça m'intéresse, je pense, un petit peu plus. Sur les podcasts, pour continuer, je vais parler plutôt des choses qui n'ont rien à voir. Moi, je suis complètement addict à Transfer, qui... Tu ne connais pas ? C'est un podcast de Slate, je crois, où globalement, c'est souvent des interviews qui durent entre 45 minutes et une heure. Ce ne sont même pas des interviews parce que je crois qu'on n'entend pas la personne qui interview. Je ne sais pas si la personne pose des questions ou pas, mais en tout cas, c'est vraiment une personne qui raconte son histoire. C'est un épisode de vie qui est souvent marquant. Et je trouve ça hyper passionnant de voir ce que les gens vivent. Et ça permet de s'ouvrir aussi sur les autres. Et donc, je pense qu'on a gagné aussi à la fois personnellement et professionnellement, bien sûr. C'est pour ça que je le cite là-dessus. Et puis bon, moi, je suis complètement addict à ça. J'écoute tous les épisodes. — Hyper intéressant. Déjà, je regarde.
Terry : Enfin, écoutez. — Ouais.
Corentin : Alors tous les épisodes ne se valent pas, c'est sûr. Mais souvent, il y en a quand même des très très très marquants. Il y en a aussi des très durs. Ce n'est pas toujours le cas. Je dirais que c'est souvent dur. Mais il y en a qui sont aussi très positifs. Mais quand c'est très dur, ils préviennent d'avance.
Terry : Ouais, histoire de pas écouter ça un vendredi soir avant de partir le week-end.
Corentin : Ah ouais, j'en ai écouté un dernièrement, c'était avant de m'endormir en plus, parce que des fois quand j'ai du mal à dormir j'écoute un podcast, et là c'était sur justement une personne qui avait un problème au niveau de sa grossesse et ça se terminait très très mal, et alors moi qui suis dedans là, j'ai pas réussi à dormir. Donc oui, effectivement, écoutez avec attention les warnings du début d'épisode pour dire que c'est dur. Et si c'est rare de vous coucher, ne les écoutez pas. Même si c'était passionnant à écouter, c'était vraiment dur. Dans le même genre, je suis un peu moins addict, mais j'aime beaucoup aussi, c'est les pieds sur terre. Comme moi, un épisode par semaine de transfert, ça ne vous suffit pas. Les pieds sur terre, un peu dans le même genre, j'aime bien. Ça permet de s'ouvrir un petit peu, je trouve. Et en article, là, je vais rester un petit peu plus... Des livres, honnêtement, je suis souvent un petit peu déçu quand je lis des livres sur le métier. En fait, c'est un peu dur de dire ça parce que j'ai des périodes où je vais lire beaucoup de livres sur le métier pour apprendre. Et en fait, j'apprends toujours des choses qui sont assez passionnantes. Mais souvent, je me dis toujours tout ça pour ça. Finalement, si je lisais un résumé, et moi je le fais souvent, quand je lis un livre, je ne peux pas m'empêcher de faire un résumé de ce livre. Et finalement, je me dis si j'avais lu que ça. Est-ce que ça ne m'aurait pas suffi ? Je ne sais pas. C'est toujours dur de savoir finalement qu'est-ce qu'on retire de tout ça. Il y a aussi un plaisir à lire un livre. Des fois, j'ai une frustration quand je lis juste un résumé de livre. Mais donc voilà, je n'ai pas forcément de livre à conseiller là-dessus. Qu'est-ce que j'ai en articles qui m'ont marqué ? J'ai ce Software Engineering Manager Handbook, plein de bons conseils pour manager si on est nouveau dans ça. Et un autre qui est « Engineer Guide to Career Growth », hyper intéressant. C'est Railin Yang qui a écrit ça. Désolé si j'écorche le nom. J'ai trouvé ça hyper intéressant. Elle donne plein de… Alors, c'est tous les deux des articles au type Medium. C'est peut-être pas sur Medium, mais les deux, c'est pas mal de billes. L'un qui est plus sur… vraiment pour le manager. Moi, je suis quand même assez nouveau dans le job, donc ça m'a pas mal aidé. Et l'autre qui est plein de conseils pour les différents types de postes pour la tech, j'ai trouvé ça hyper intéressant, je le conseillerais à vraiment tout le monde qui travaille là-dedans, que tu sois junior, tech lead, vraiment manager ou même CEO, plein de bons conseils pour arriver à trouver qu'est-ce qui est important et sur quoi se concentrer pour apporter de la valeur justement. Il y a un accent sur finalement c'est important d'apporter de la valeur et moi c'est quelque chose sur lequel je suis très aligné, c'est ce qui m'intéresse dans mon job en fait. Donc je conseille à tout le monde.
Terry : Super, merci pour tout ton partage, pour la bonne humeur qui je pense c'est bien entendu au son du micro et puis à une prochaine.
Corentin : Merci à toi, c'était très très intéressant de discuter, j'ai pas l'habitude et je sais pas si j'arriverai à écouter ce podcast là, je trouve c'est très dur de s'entendre parler. Mais voilà, j'essaierai quand même pour justement voir si j'ai réussi à être clair et pour progresser là-dedans. J'ai trouvé ça vraiment très intéressant en tout cas comme exercice et aussi super sympa de discuter avec toi sur ces sujets.
Terry : Merci Corentin.
