Transcription

• Speaker #0

  Bonjour et bienvenue à votre nouvel épisode de podcast Dectic Data. Aujourd'hui, on va parler plus du côté humain, comment structurer une équipe data autour de TBI et donner quelques pieds du succès. Et pour parler de ce sujet, j'ai un super invité qui vient du monde académique et il a... un background très costaud dans les stats, dans les choses qui, en général, ce n'est pas comme ça qu'on arrive dans le monde de la data d'entreprise. Donc, je vais redonner la parole à Anis pour te présenter un petit peu, me raconter qui es-tu et puis ton parcours, tes débuts dans la data.

• Speaker #1

  D'accord. Merci, d'abord merci Médéric, merci de m'avoir invité. Moi, c'est Anil Sadouche, je suis docteur en statistique. Et pendant les huit dernières années, comme tu l'as dit, j'ai occupé plusieurs postes très variés. Donc, je commençais d'abord par faire de l'enseignement. Et c'est là où j'ai découvert le monde de la data science ou du machine learning. Pendant mon cursus académique, je n'y étais pas du tout. prédestiné à faire de la data ou encore moins à faire du management. Pour l'anecdote, je faisais un poste d'ATR, attaché temporaire d'enseignement et de recherche. Puis, il y a un collègue qui vient me voir, c'était juste avant les vacances, un peu en mode panique, il dit « Écoute, l'année prochaine, on lance un master spécialisé en sciences des données. » C'était la période où ça commençait à devenir un peu en mode. Et un master spécialisé, c'est un public très, très marié. Il me dit, on avait un intervenant qui était cessé de faire le cours introduction au machine learning, mais en fait, voilà, il nous a lâchés. On n'a rien trouvé de personne. Il me dit, pourquoi tu ne le fais pas ? Ben non, je ne sais pas faire. Je n'ai jamais fait ça. Il me dit, bon, c'est ce que c'est une agression de l'IA ? Il me dit, oui. Tu sais faire la différence entre classification et clustering ? Ben oui, et tu as déjà fait un peu de piton. Je me dis oui, ben tu peux le faire.

• Speaker #0

  T'es sûr ?

• Speaker #1

  Oui. Bon, allez.

• Speaker #0

  C'est un peu comme ça que tu t'es retrouvé à te rapprocher de l'entreprise.

• Speaker #1

  Plus de la data au sens applicatif, de la data science au sens d'aujourd'hui. Donc voilà, je fais pareil pendant deux mois, pendant l'été de cours. Et j'ai fait ça pendant deux ans, ça s'est super bien passé. J'ai fini par adorer. Parce qu'en fait, c'était la théorie en pratique. C'était des cas complets, pas de pavés, mais qui devaient être valeurs ajoutées. Et j'aimais particulièrement le NLB. J'ai fini par faire aussi un post-doc sur le NLB.

• Speaker #0

  Est-ce que tu peux nous expliquer pour les auditeurs ce que ça a envers nous ? Oui, pardon. Ça fait aussi partie de la philosophie du podcast. On essaye de faire le moins de choses avant.

• Speaker #1

  Le NLB, c'est en gros du traitement texte.

• Speaker #0

  Alors, qu'est-ce que ça veut dire, le sigle ? Moi, je suis très curieux.

• Speaker #1

  Oui, c'est pour Natural Language Processing, un traitement du langage naturel. Je crois que c'est talon.

• Speaker #0

  Ok, d'accord.

• Speaker #1

  Les linguistes français, c'est bien talon.

• Speaker #0

  Ok, c'est bien. Et du coup, tu as fait ce premier pas de l'application. Tu as toutes tes connaissances, ton parcours académique. C'est ça. Comment tu es arrivé dans le monde de l'entreprise ?

• Speaker #1

  La transition n'a pas été simple parce que j'avais un parcours très, très académique. Et puis je crois que dans l'entreprise, recruter quelqu'un qui a fait toute sa carrière académique, nous avons une petite appréhension. Donc ce qui m'a beaucoup aidé, c'était le post-doc, où j'étais ingénieur de recherche à l'Unité de Compte de Brest. C'était un peu entre l'entreprise et l'académie. Ce n'était pas trop théorique et ce n'était pas trop pratique. C'était vraiment le juste milieu. Je me suis éclaté pendant deux ans. On a travaillé sur un superbe projet, qui s'appelle « Platforms of Learning Analytics » qui s'appelle Lab & Book.

• Speaker #0

  Comment la transition s'est faite dans le monde de l'entreprise plus classique ?

• Speaker #1

  C'est parti d'une volonté. Je voulais un environnement un peu plus stimulant.

• Speaker #0

  Des deadlines,

• Speaker #1

  etc.

• Speaker #0

  On ne nous t'en passe pas chiant tout le temps. Oui, c'est vrai. Je veux des deadlines. C'est ça.

• Speaker #1

  Ah bon,

• Speaker #0

  un peu plus sinon je m'ennuie un peu. T'as fait le tour de mon académique.

• Speaker #1

  Ce n'est pas que j'ai fait le tour, mais je m'ennuyais. Je m'ennuyais. Enfin, il y avait assez de travail, mais voilà. Je ne sais pas comment l'expliquer, mais je m'ennuyais et je voulais avoir l'expérience en entreprise. Donc, j'ai travaillé sur mon profil. J'ai eu quelques petites formations, beaucoup de mentorat pour justement apprendre la Data Science. D'ailleurs, je suis mentor sur Bell Classroom de la FUGUE. Puis, j'ai candidaté pour une offre sud-ouest. Et j'ai donc eu le poste de responsable adjoint chez Primva qui était disponible chez Condit at EU. Ça a bien marché. Et puis voilà, je me suis retrouvé à faire, peut-être pas du management la première année, mais facile un peu. Donc j'ai fait deux ans chez Primva, première année autant que responsable adjoint et deuxième année autant que responsable data de l'équipe data.

• Speaker #0

  Et la responsabilité nécessaire. Il y a une question qui me vient par rapport à ce parcours, c'est riche, c'est qu'est-ce que ton parcours de chercheur, dans mon académique, t'as apporté dans ta façon de comprendre une problématique data ?

• Speaker #1

  Ouais, ok. En fait, peut-être pas comprendre une problématique propre à la data, mais n'importe quel type de problématique, pour moi un problème, et ça, Peut-être que certains l'ont appris ailleurs, mais moi en tout cas face à un problème, il faut savoir le poser. Donc ça passe par poser les bonnes hypothèses et surtout derrière savoir mesurer la solution qu'on pose. Donc pour moi ces deux éléments c'est que tu as compris le problème, ça ne veut pas dire que tu l'as résolu, mais tu as compris le problème. Le problème il est bien posé et tu sais mesurer la solution. Faut que tu fasses focus d'abord sur ces deux principes là.

• Speaker #0

  La question que je voulais te poser c'est est-ce que tu as une idée où justement ce background t'a permis de travailler sur un sujet que d'autres ont trouvé insoluble ?

• Speaker #1

  Oui, je me souviens d'un sujet qui m'a vraiment marqué à mes débuts chez Primever. Je faisais mon parcours d'intégration et pendant ce parcours j'ai rencontré une personne et dans notre... premier échange. Il m'a balancé son problème au bout de cinq minutes. C'était pas du tout le sujet. On a dit,

• Speaker #0

  viens, j'ai besoin de toi, j'ai des problématiques. Et en fait,

• Speaker #1

  c'était un problème assez chouette et assez simple à résoudre en fin de compte, sauf qu'il était mal posé. En fait, c'était un jeu de sécré régulier, un jeu de palette entre trois tiers. Et l'idée, c'est que lui, il était responsable de l'emballage de Togo et il voulait mettre en place un système. qui permettait de mettre le solde à zéro entre deux tiers à n'importe quel moment, sous certaines conditions. Et en fait, c'était simple comme solution. J'avais fait ça avec Pipon, une application, une application Stimly super basique. Mais par contre, savoir poser le problème, le mesurer avec les bonnes hypothèses, c'est ça qui a été le challenge. Donc c'est un sujet qui m'a marqué toujours dans cet état d'esprit du chercheur qui voulait un peu bien poser les problèmes, mettre les hypothèses.

• Speaker #0

  En tout cas, il y a une approche que je trouve très enrichissante. Moi, j'ai eu la chance dans mon parcours académique d'avoir été passionné par les problématiques de Graf et par exemple tout ce qui permet d'optimiser un flux dans ces problématiques. de Graff et super enseignant Bernard Doucet. D'ailleurs, si on écoute Bernard, effectivement, souvent quand on aborde ces sujets-là dans un parcours académique, on se dit, ça peut être assez complexe, est-ce qu'un jour je vais avoir le cas de l'appliquer dans la vraie vie ? Et donc, oui, finalement, en entreprise, on a aussi des sujets qui sont pensés et qui nécessitent un background. scientifique, en tout cas, des fois même mathématique, assez solide pour pouvoir les traiter correctement, de manière efficace. Parce que c'est ça aussi, je pense, qui fait la différence. On peut résoudre des problématiques de manière satisfaisante, mais pas forcément de manière efficace, de manière qui va faire que la solution soit pérenne. Donc ça, c'est quelque chose d'intéressant. Il y a aussi un côté très pédagogue en fait, dans ton approche. Il y a un côté transmettre, monter une équipe en compétence. Quel principe toi tu utilises pour faire monter en compétence une équipe data ou pour former une équipe data ?

• Speaker #1

  Moi ce qui m'anime c'est de voir les gens évoluer, transmettre, j'adore ça, voir les gens progresser, j'adore ça. Ça me fait vraiment plaisir et c'est ce qui m'anime, c'est ce qui me donne envie d'apprendre pour transmettre. Ensuite pour répondre à ta question, sortir un peu l'exemple du chercheur Calmi, en DB Test en tant que Je suis doctorant, j'ai mon encadrant. Peut-être que l'encadrant, il apporte beaucoup de calme au début, beaucoup de directives, et petit à petit, il commence un peu à se retirer. Et puis, au fur et à mesure qu'on avance, on se rend compte que l'étudiant connaît le sujet mieux que son encadrant. Et c'est souvent ça, c'est lui qui devient l'expert. C'est un peu pareil quand on manage des collaborateurs ou quand on veut faire évoluer un opérateur, moi, je suis de même principe. En début de projet, je suis là, je suis la progression, je me retire petit à petit et jusqu'à ce que le collaborateur devienne autonome. Et si le collaborateur devient autonome, en plus responsable du sujet, en fait bingo. Du coup,

• Speaker #0

  tu as ce côté mentor aussi, tu as un mentor que je trouve génial. Quels sont les erreurs qu'on fait souvent quand on est junior, quand on se lance dans la data ? Et comment peut-être les éviter ?

• Speaker #1

  En fait, moi, j'en vois deux. Peut-être que ce ne sont rien que... Ils sont liés, on parlait de deux problématiques. La première, de ce que j'ai remarqué, c'est que les gens ont vraiment beaucoup tendance à se focaliser sur la maîtrise des outils. Donc, je suis data engineer, je dois apprendre à faire du Kafka, je dois apprendre à faire du Docker, je dois apprendre à faire du Post, du machin, des trucs. et ils veulent maîtriser un maximum de technos. Or, je pense que c'est une erreur pour deux raisons. La première, c'est qu'on ne va jamais tout maîtriser. Je ne sais pas si tu as les dix dernières années, la vitesse à laquelle ça avance, le bilan sur l'artificiel, tous les sujets de data et tous les technos, c'est exponentiel. Sur cette partie-là, moi, ce que je recommande, c'est vraiment rester sur les basiques. Je suis data analyst, je me concentre sur les basiques. Les basiques, c'est quoi ? des notions en stack, comprendre ce que c'est une moyenne ou une médiane, c'est normal. Maîtriser SQL,

• Speaker #0

  bien sûr, c'est la rite.

• Speaker #1

  Maîtriser un outil BI et savoir faire un niveau de programmation du Python ou du VRPAP, ne pas trop s'éparpiller. La deuxième chose, ou deuxième grosse erreur pour moi, qui est encore plus problématique que la première, c'est de ne pas être assez business dans leur façon d'apprendre, dans leur façon de modeler les sujets. En fait,

• Speaker #0

  ils oublient ce qu'ils cherchent. Le cas de Spik, c'est vrai qu'il n'est même pas un de ceux que j'étais étudiant, ça pouvait m'arriver de rester pendant deux jours à nettoyer des données, à faire du dataset. C'est juste parce que tu cherches. C'est très intéressant d'avoir ce retour-là. Quand tu as commencé en poste responsable de l'équipe Data, c'était quoi les challenges que tu as eus au début ?

• Speaker #1

  Deux gros challenges ? C'était pas ça. La première, c'était de faire Vivre, faire en sorte que l'existant continue de vivre, même avec le changement responsable. Il y avait des process qui ont été faits pour les métiers qui étaient mis en place. Et en fait, il fallait que ça continue, que ça marche. Par rapport à ça, le plus gros problème, c'est qu'il y a eu un très grand manque de documentation sur les process qui étaient en place. Il y avait beaucoup de choses qui étaient dans l'esprit de ces deux. de certaines personnes. Et il fallait déjà connaître l'existence de ces process. Et c'est souvent... Ok, ça existe. Bon, allez, comment ça marche ? Ça marche comme ça. Bon, allez, on va le rédiger. On va rédiger un document. Comment ça marche ? Si jamais le process est en panne, voilà ce qu'il faut faire. Pour parler à ça, on va commencer petit à petit à mettre en place une petite doc.

• Speaker #0

  Pour faire cadrer les process de ton écran. Tu as une idée globale de ce que sont les process qui doivent tourner.

• Speaker #1

  Donc ça c'était le premier challenge, mais j'avais de superbes collaborateurs, on a fait du bon travail là-dessus. Et le deuxième, c'était de gérer deux mains. Il fallait qu'on mette sa place. Ce genre de choses, ça passe par d'avoir beaucoup d'hypnomatie, savoir parler aux gens. Par rapport à l'humain, le challenge auquel j'ai été confronté, c'est gérer la frustration. J'avais des d'accord avec l'équipe, avec des doctorats et des masters spécialisés. Leur journée, c'est de faire de l'Excel. Donc les gars, à un moment, ils s'ennuyaient un peu. Donc il fallait travailler sur ça. Il fallait leur expliquer que, en fait, les gars, notre travail, c'est de résoudre des ennemis au service du métier. En fait, si c'est problématique, on peut le résoudre avec un Excel. On fait un Excel, on peut faire un Python. Donc il fallait un peu jongler vers, OK, il faut que ça avance, donc il faut faire en sorte. de répondre rapidement aux besoins du métier, quitte à faire de l'excel tout le temps. Et en même temps, il fallait prendre en compte la frustration des collaborateurs et les mettre sur des sujets qui, au final, correspondent à plus leur profil ou leur scope de compétences.

• Speaker #0

  Intéressant. Dans une équipe d'attente, on va prendre plusieurs pôles. Aujourd'hui, en 2026, c'est quoi les différents profils qu'on va avoir dans une équipe d'attente et quel va être un... le rôle dans dans une équipe parce que enfin entre moi quand je commençais la BIA en 2012 et aujourd'hui il y a eu beaucoup beaucoup beaucoup de nouveautés beaucoup de nouveaux profils aussi est-ce

• Speaker #1

  que tu peux nous éclairer sur ces profils et de leur rôle alors ce qu'il faut savoir c'est que donc j'étais dans le service d'Alta qui était relativement jeune Et puis, c'est une qualité sur une équipe très, on va dire, très standard. Donc, on n'avait pas des data stewards, des data bars, des ingénieurs en ML Ops ou ce type de choses. On avait des data analystes, des data scientists avec casquettes data engineers ou plus data engineers avec casquettes data scientists.

• Speaker #0

  C'est quoi l'intégralité en son travail ? Data analyst,

• Speaker #1

  data scientist. Oui. Alors, je vais peut-être commencer par les data analystes. Leur champ d'accent, les analystes étaient principalement pour faire de la BI, du dashboard, des extractions sur nos applicatifs et éventuellement créer quelques modèles de données. Data engineer, c'était plus pour créer des modèles de données. En gros, en fait, le data analyst, il a besoin d'en faire un tableau de bord, ses données, il va les chercher quelque part. Et en fait, souvent, c'est une data engineer qui le prépare. Donc, le data engineer, il se connecte à plusieurs sources de données, il les prend, il les nettoie, il les agrège, il les fait en sorte qu'elles soient accessibles et nettoyées, et que la donnée soit affichée à une fréquence x ou égal. Le data scientist, c'est un peu le cycle de vie. Le data scientist, pour moi, c'est un peu une double casse-tête. Et... data engineer quand il le faut et data analyst quand il le faut. Moi, le data scientist que j'avais dans mon équipe, il a un sacré personnage. En fait, lui, il adorait travailler sur des sujets où la solution n'était pas, où il fallait creuser, où il fallait faire du R&D, où il fallait aller par un métier. où il fallait aller remettre en question du métier. Il a vraiment ce besoin d'avoir une compréhension très profonde. C'est un test. Il doit avoir une meilleure compréhension business qu'un data analyst et être aussi calé techniquement.

• Speaker #0

  C'est très intéressant. Là, on parle vraiment du contexte du liquid data qui est déjà assez grand, donc qui gère des problématiques là. Souvent, dans le contexte de la... PME ou de TI, on va avoir quelqu'un qui va être data analyst, mais qui va tout faire. Il va faire tout le site de vie, depuis l'extract, depuis... Mais en fait, ce dont tu parles, je pense que c'est important, c'est dans le contexte de ces grandes structures où il y a déjà beaucoup de problématiques et donc effectivement, ce besoin d'expertise est vraiment très simple. Les sujets sont tellement vastes et tellement complexes que... parce qu'elle tient bien à ce rythme. Ça, c'est intéressant. Par rapport justement à cette structuration d'équipe, pour toi, quels sont les piliers d'une équipe data ? C'est fondamental pour que l'équipe data soit cohérente, qu'elle soit fonctionnelle et qu'elle puisse tout simplement être vraiment au service du métier.

• Speaker #1

  Donc, en gros, si je comprends bien, qu'est-ce qui fait que ça soit une bonne équipe data ?

• Speaker #0

  Voilà, quelles sont les clés du succès d'une équilibre d'interférences ?

• Speaker #1

  C'est mon avis,

• Speaker #0

  après je suis pas expert en management, voilà, je donne toujours à... Justement, ce qui se trouve, c'est que c'est intéressant d'avoir le retour de quelqu'un qui a pratiqué, parce que moi je crois pas que c'est les experts en management qui sont les mieux placés, par contre ceux qui ont eu l'extérieur. Ouais, ok. Et je pense que tu as le retour justement dessus.

• Speaker #1

  Donc du coup ? Moi, chose indispensable, c'est pour n'importe quelle autre équipe, que ce soit une équipe de foot ou une équipe de rugby ou n'importe quoi, c'est l'esprit d'équipe. S'il n'y a pas d'esprit d'équipe, il n'y a pas d'équipe. Il n'y a pas d'équipe. C'est vraiment l'aspect solidarité, être tous derrière un seul objectif. Notre objectif, c'est de faire tourner l'Amérique. Quitte à ce que le data scientist ou le data engineer lâchent un peu son Kafka et qu'il fasse de l'essai.

• Speaker #0

  J'aime beaucoup cet état d'esprit. Pragmatique, on est une entreprise, il y a un business derrière.

• Speaker #1

  Oui.

• Speaker #0

  Mais pas pour faire de la data.

• Speaker #1

  Pour faire de la data, oui. Donc, pour moi, c'est l'indispensable. Le deuxième, je ne sais pas comment le dire, mais c'est faire en sorte que, et ça, ça passe forcément par définir des rôles et des responsabilités. Définir les rôles pour responsabiliser les gens. Parce que... Quand tu responsabilises quelqu'un, déjà, bon, voilà, avec le temps, il apprend, il m'entend quelque chose. S'il devient autonome, toi, ton co-manager, s'il est autonome, tu n'as rien à faire. Ton travail, c'est de faire faire. Donc là, tu n'as plus besoin de faire faire. C'est fait. Donc, tu peux faire autre chose.

• Speaker #0

  Donc, d'abord, c'est super d'économiser, sauf qu'il se rend compte au moins.

• Speaker #1

  Et tu es responsable. Responsable, responsable sur un sujet. Ça ne veut pas forcément dire que c'est à moi de le faire. Quelqu'un d'autre de l'équipe peut le faire. Par contre, c'est un mois de vieillis que ça soit fait. Par contre, si j'ai une demande du métier sur ce sujet, c'est moi le... Pour moi, c'est les deux. C'est tout ce que je vois. Bon, il y a autre chose. Mais s'il n'y a pas l'estrée d'équipe, s'il n'y a pas cette autonomie, responsabilité, engagement des collaborateurs, tout ça,

• Speaker #0

  j'ai un peu de problème. En termes d'organisation, pour toi, pour bien structurer les deux piliers, c'est ce côté... L'esprit, la base, le mindset quelque part, et le partage des responsabilités, une structuration par une organisation où chacun sait ce qu'il a à faire. Et donc, quelque part, ça revient à me souvenir, parce que comme dans une équipe de rugby ou de foot, il y a un tacot, il y a un raccord, c'est fou. Il faut que chacun tienne bien son poste et qu'il trouve bien ce qui va se dérouler. En fait, c'est du bon sens. Je pense que quand on a un peu ce recul et que cet état d'esprit justement est partagé au niveau de l'équipe, il y a beaucoup plus de chances que ça aille bien. Maintenant, pour creuser un peu plus comment équilibrer, on va dire, la vie quotidienne d'une équipe data, comment toi tu as fait pour équilibrer ces deux contraintes qui sont un peu antagonistes, parce que maintenir le système et répondre aux nouveaux challenges, ce n'est pas toujours évident.

• Speaker #1

  En fait, pour maintenir le système, c'était la responsabilité de tout le monde. Il n'y avait pas une personne qui était... On appelait ça support interne de l'équipe. Faire du support interne, c'est par exemple, quand il y a un ETL qui tombe, c'est la personne qui est destinée à faire le support cette semaine qui va.

• Speaker #0

  Donc, ça tourne. Ça, c'est que le...

• Speaker #1

  D'abord, ça passe par une documentation, ce que je t'ai dit tout à l'heure. En fait, on avait... On avait recensé tous les processus un peu sensibles. On les a écrits noir sur blanc. On a fait des mots d'opératoire. Comme ça, tout le monde est apte à déjà comprendre le problème et à le résoudre.

• Speaker #0

  Oui, mesurer aussi la criticité. Thomas, tout est critique. Il y a peut-être des trucs plus critiques que d'autres.

• Speaker #1

  Donc, tout ce qui concerne le client.

• Speaker #0

  Bien sûr, tout ce qui concerne le client est plus critique. C'est ce qui est en frontal avec le client. Plus critique, bien sûr.

• Speaker #1

  Donc, on a commencé par faire d'abord une documentation, des modes opératoires. Après, on a fait des semaines d'astreinte, mais on faisait tourner le support. Semaine A, ce premier, semaine 6 mois, je faisais du support avec mes équipes. Les premiers temps, bon, excusez, parce qu'à la fin,

• Speaker #0

  je n'avais plus le temps,

• Speaker #1

  mais on faisait tourner. Les alternantes faisaient du support, les data scientists faisaient du support, les data analysts faisaient du support. Tout le monde fait du support.

• Speaker #0

  J'aime bien cette idée d'esprit, en fait, C'est la... Il n'y a pas de tâche qui dit « Ah non, ça, ce n'est pas mon boulot. » Je pense que c'est hyper important. Oui,

• Speaker #1

  en fait, c'est ce qui crée la solidarité. Si ça se trouve, un intermode qui fait une tâche, c'est pénible. En fait, les data scientists, ils ne se rendent pas compte forcément que c'est pénible. Sauf que quand ils le font, ils savent que c'est pénible.

• Speaker #0

  Oui, ça crée de la compassion.

• Speaker #1

  Ça crée de la solidarité, de la compassion, et je trouve que c'est super important. Donc voilà, la première chose, c'était Et... C'est ça. On l'avait documenté par avant, documenté le processus, et on faisait tourner le support. Et pour répondre par rapport à ta deuxième question sur l'automatisation... Il y avait des nouveaux sujets qui arrivaient. En fait, tu n'as pas le choix, tu les prends. On les prend. Nous, on était organisé. On n'était pas au monagé. C'est un peu classique. En gros, une demande typique chez nous, c'est qu'on avait un donnant. Ça passait par un outil ou ça passait en direct ou ça passait par mail. Mais je faisais en sorte... d'être la porte d'entrée de la demande, surtout si c'est un nouveau sujet, si c'est un sujet que les collaborateurs maîtrisent, dont je n'interfère même pas directement au contact. Donc, je qualifie si faisable ou pas faisable, si faisable, qui peut le prendre dans l'équipe, et dans ce qui peut le prendre dans l'équipe, c'est d'abord la compétence, deuxièmement, la disponibilité, et troisièmement, l'appétence du collaborateur à faire ce genre de sujet. Parce que si tu bombardes un collaborateur pendant un mois et que des sujets qu'il n'a pas fait, tu as un burn-out assuré au bout de deux mois. Si c'est tous ces sujets, tu les étales un peu dans le temps, ça va.

• Speaker #0

  Donc les sujets les plus, on va dire, challengeants, il faut savoir aussi les confier aux bonnes personnes qui vont avoir l'appétence pour le sujet. Et sinon, il faut savoir aussi les garder. à 12 euros on va dire qui est acceptable qu'est-ce qui fait que selon toi une équipe d'Atta va devenir vraiment performante au quotidien ?

• Speaker #1

  les clés c'est la performance pardon je vois ma question de tout à l'heure une équipe de foot qui n'a pas un seul objectif comment c'est de gagner le match En fait, ce n'est pas une équipe. Si le défenseur, son objectif, c'est son record personnel, ou l'attaquant, son objectif, c'est de marquer le maximum de buts, en fait, on n'est pas tous animés par un seul objectif. C'est un peu pareil dans une équipe. Il faut qu'on soit tous derrière un seul objectif. En fait, par rapport à ça, moi, ce que j'ai remarqué au prix de mes collaborateurs, c'est qu'ils sont productifs, qu'ils sont... plus épanouis dans leur travail quand ils ne sont pas un peu chacun dans son coin, quand ils travaillent en bilan, ils travaillent en équipe. Et donc, pour moi, c'est super important de faire vivre ces habitudes que je cherchais par ces habitudes. Et en fait, le responsable, il faut que je fasse suivre un certain rite et rituel pour l'équipe. Donc nous, par exemple, on se voyait une fois par semaine. Chaque équipe, c'était de faire une sorte de rétro-week sur ce qu'on a fait pendant la semaine, ce qui a marché, ce qui n'a pas marché. Est-ce que vous partagez des sujets que vous avez trouvés intéressants ? Est-ce qu'il y a un sujet qui ne vous plaît pas ? Est-ce que vous avez des idées pour faire améliorer l'équipe ? Voilà, c'est toute cette synergie qui est super importante si on n'a pas d'équipe.

• Speaker #0

  Oui, en fait, il y a un côté un peu agil dans ce que tu dis. Est-ce que du coup, tu penses que le mode agile est quelque chose qui est adapté à une équipe d'altar ?

• Speaker #1

  Je ne sais pas. Je ne sais pas. Je n'ai pas essayé de le faire parce que j'avais d'autres combats sur d'autres fronts. Mais oui, je connais des équipes où ça marche, ça marche super bien. Par contre, pour moi, pour que ça marche, il y a une condition indispensable, c'est maîtriser le flux entrant. Si tu ne fais pas une bonne qualification des demandes et ne prends que les demandes qui sont vraiment des demandes, tu ne t'en sort pas. Une bonne maîtrise, une bonne qualification, un process clair, on communique à tout le monde, que ce soit au métier ou à l'IT, il nous s'agit de faire ça, ça, ça et ça. Et puis nous, vous en interne, vous avez un process pour qualifier les demandes en fonction des priorités, les cites et cités, ça me fait une cataune. Pour moi, il faut passer.

• Speaker #0

  Alors, il y a un truc, finir peut-être sur cette partie un peu process, pour voir, quoi ressemble à un workflow ou un processus idéal de la demande du métier ? On a une demande métier sur un sujet data, jusqu'à la livraison.

• Speaker #1

  Alors, idéal, je vais te dire comment on faisait, nous.

• Speaker #0

  Toi, tu fais le marché, ouais, de toute façon, on est jamais dans l'idéal, mais il y a quand même une vision.

• Speaker #1

  Ou est-ce... Euh... En fait... nous, comment on marchait.

• Speaker #0

  Donc, le métier, il a une demande, il fait un ticket, un rand ticket, ou il te fait une demande dans la machine à café, puis ensuite il fait un ticket. Il faut qu'il y ait un ticket pour que ça soit formalisé. Il faut que ça soit formalisé, il faut qu'il y ait une trace pour tout le monde. Pour estimer l'achat, enfin, plein de raisons, il faut qu'il y ait un ticket. Pour la bonne organisation de l'équipe, il faut qu'il y ait un ticket. Donc, le ticket, il est créé. Ça passe par une première qualification du restaurant de sable ou pas. Parfois, quand je sais que c'est un sujet qui peut être utilisé par quelqu'un, je ne regarde que le titre et je ne bosse.

• Speaker #1

  C'est le côté autonomie en termes de...

• Speaker #0

  Exactement. Et en fait, si tu as des collaborateurs autonomes, c'est bien gros. Mais le plus important dans tout ça, et hyper important dans tout ça, c'est de garder toujours un contact avec le client. Il ne faut pas laisser dans le flou. Je ne te fais pas indiquer au mois de janvier. et puis je n'ai pas de nouvelles jusqu'au mois de mars, alors que peut-être que derrière vous êtes en train de travailler et que le sujet nécessite trois mois. Par contre, si vous ne me dites pas, je pense que vous ne faites rien.

• Speaker #1

  Est-ce que dans une équipe, ou en tout cas dans ton expérience, que le côté, on va dire, projet, le mode projet, est facilement compatible avec le mode run ? Comment concilier les deux, peut-être ? Est-ce que c'est possible pour toi ? Est-ce que ça a du sens ?

• Speaker #0

  Concilier les deux, je ne sais pas. C'est compliqué. Mais encore une fois, je te partage mon expérience. Nous, on a tenté plusieurs choses.

• Speaker #1

  On a essayé de faire des équipes,

• Speaker #0

  des personnes dédiées au run et d'autres personnes qui ne font que du projet. Et on a essayé l'autre méthode où tout le monde fait un peu de tout. Et c'est là. Ça a plus marché. Nous on était, ça dépendait des périodes, mais il y avait des périodes où on faisait beaucoup de runs, c'était genre 70% de run, 30% de projet. On prenait ça, alors qu'on était là pour faire du projet. On est d'accord, donc l'équipe, t'as valeur ajoutée, elle est dans le projet, elle est pas dans le run. Donc il y a eu des périodes de rush, on faisait 70% de run, mais le reste du temps, c'était l'inverse. Moi, dans mon équipe, tout le monde faisait tout. Physique que ce soit les alternants ou les data scientists ou les data analysts, les plus expérimentés, tu fais du run et tu fais du projet. L'idée, on avait fixé un objectif, c'était de faire 30% de run, 70% de projet. Si on dépasse ces proportions-là, on va être en retard sur les projets, il faut alerter les différentes parties prenantes du projet.

• Speaker #1

  Du coup, en fait, c'est intéressant, c'est-à-dire que c'est aussi quelque chose que je peux partager à partir de ce que j'ai. plus expérimenté en entreprise, c'est que la partie RUB, on essaie de minimiser ça au maximum. Du coup, la partie à valeur ajoutée pour l'entreprise, c'est les nouveautés. Même des fois, je trouve que c'est intéressant aussi d'aborder le côté RUN en mode projet. Je ne sais pas, on a un système qui tourne depuis 20 ans, mais en fait, il n'est pas stable sur certains côtés. En fait, c'est intéressant, c'est de dire on va faire un projet de stabilisation. du système en tant d'avoir comme objectif de remplacer un truc comme ça je pense qu'en termes aussi de maîtrise et de sérénité par rapport à la gestion du projet c'est intéressant ouais et je termine avec ça moi

• Speaker #0

  je mettais toujours l'accent sur le fait que ok on fait du projet les gars pensez toujours qu'il y aura un projet on est en train de faire des développements il faut penser dès maintenant, qu'est-ce qu'on peut avoir comme problématique par rapport à ce qu'on est en train de faire, pour essayer d'anticiper au maximum. Donc déjà, si tu pars avec cet état d'esprit-là, tu en as besoin. Mais il faut qu'on se mette d'accord aussi, c'est que plus on livre de projets, plus on va dans le lard, sauf si tu fais que des projets 120, des gens qui ne le font pas trop. Mais plus tu lis, plus on lit,

• Speaker #1

  plus on a de projets, plus on a de projets à maintenir. La maintenance ne va pas.

• Speaker #0

  Je pense à un moment, il faut penser aux ressources derrière.

• Speaker #1

  C'est super. Alors, peut-être pour finir, il y a un sujet qui te fait avancer, le sujet IA. Pour toi, quelle est la place de l'IA ? Comment tu vois ça pour le futur ? Et comment tu vois en fait l'évolution d'une équipe data avec tout ce qui arrive aujourd'hui comme technologie d'IA ?

• Speaker #0

  Oui, je pense que c'est une vision qui est propre à... Tous les services de l'IT, l'IA, c'est un monde de l'équipe. D'accord. C'est un manque de liquide. Tout le monde utilise de l'IA, c'est un boost pour l'utilité. Tu ne peux pas dire qu'ils n'utilisent pas l'IA juste parce que tu vas oublier à importer des librairies. Enfin voilà, petit à petit, avec le temps, ta qualité à produire du code va diminuer. En fait, avec l'arrivée de Google, on ne va pas aller reprocher aux gens de ne pas chercher dans l'index. En fait, ce qui compte, c'est d'avoir l'information. Donc pareil, ce qui compte, c'est de produire. On est d'accord. Produire. Donc pour moi l'IA ça doit être un support.

• Speaker #1

  Un membre c'est pas un membre, c'est quelqu'un qui est là, mais c'est pas une alternative. Ah bah non. Donc ça veut dire que pour autant on va pas abandonner le fait de s'aborder du SQL.

• Speaker #0

  Peut-être que le SQL sait faire aussi... Mais... Par contre, Sophie de la comptabilité, l'IA elle ne va pas le faire. Il faut l'écouter, il faut comprendre sa problématique, il faut la comprendre, il faut la formuler et que peut-être l'IA derrière peut le résoudre. Donc il y a l'aspect humain en amont et en fin de projet. En fait, il est remplacé, je ne crois pas, enfin peut-être, je ne sais pas.

• Speaker #1

  On peut se concentrer plus sur peut-être le côté humain. de notre métier qui est effectivement comprendre le métier, comprendre les enjeux métiers et d'accompagner le business plus, on va dire, comme partenaire du business parce que justement on a un super outil qui nous permet de nous décharger de la partie plus on va dire opérationnelle. J'aime bien cette vision de... sur science sans conscience, ou en tout cas, technologie sans conscience, n'est que le ruine de l'âme. Donc, quelque part, notre conscience et notre regard, nos choix, ils deviennent d'autant plus importants que les outils et les technologies qu'on va avoir peuvent être impactants. Plus notre conscience, elle est importante. Alors qu'on ne peut pas se dire « Ah non, mais on n'est pas responsable. » Comme le patientiste qui va peut-être juste livrer une solution qu'il a fait avec le lien mais qu'il ne comprend pas. Pour moi, ça, c'est quelque chose qui est... qui est important, garder cette capacité de comprendre est important. Aujourd'hui, on a parlé avec un outil comme Cursor ou un outil comme Google, on peut coder des choses qui avant, seul un architecte logiciel avec 20 ans d'expérience, pourtant, ce n'est pas parce qu'on a l'IA qui le fait qu'on est capable de comprendre. Attention, c'est important, même des fois, de demander à l'IA de faire les choses de manière à plus... compréhensible, de telle sorte que ce soit maintenu, maintenable par un humain qui est responsable en tant que professionnel par rapport à ce qu'on livre et ce qu'on déploie dans le monde. Merci beaucoup, Aziz, pour avoir accepté cette invitation et pour cet échange très intéressant. Je mettrai tes coordonnées LinkedIn pour ceux qui, dans nos auditeurs, souhaiteraient prendre contact avec toi ou continuer cet échange. Bientôt pour un nouvel épisode d'Equipe Data.