Transcription

• Speaker #0

  C'est que pour moi, le vrai usage en cible de l'IA générative, c'est le jour où ce sera suffisamment mature pour pouvoir construire des agents intégrés. Le drift, on a fait une étude en amont de comprendre quel était le concept optimal de réentraînement des modèles parce que par construction, les paiements, c'est mouvant. On a la capacité, en fait, on demande, si jamais on s'en rendait compte que le modèle ne fonctionne pas parce qu'il a besoin de données plus récentes, elle était très entraînée, on pourrait le faire tourner à n'importe quel moment. Nous, on utilise une carte qui est assez importante, c'est la transparence. C'est-à-dire, l'IA, ce n'est pas de la magie, ça a des défauts, ça a des qualités. Par exemple, nous, on a construit en temps réel des KPIs qui expliquent est-ce que notre modèle est en train de dévier dans sa qualité de prédiction ou pas. Aujourd'hui,

• Speaker #1

  j'ai le plaisir d'accueillir Pierre. Pierre est responsable Data et IA du département Finance du groupe Société Générale et va nous expliquer comment on peut créer une équipe IA Data from scratch et quelles sont les bonnes pratiques pour identifier les cas d'usage pertinents et les passer à l'échelle. Merci Pierre d'être avec nous.

• Speaker #0

  Bonjour à tous.

• Speaker #1

  Ça fait un moment qu'on s'en parle, je suis hyper content de te recevoir dans le podcast.

• Speaker #0

  Je suis très content de participer.

• Speaker #1

  Alors ce que je te propose c'est de commencer par une petite question brise-glace. Est-ce que tu peux nous dire, toi petit, qu'est-ce que tu voulais faire dans la vie ?

• Speaker #0

  Bah, vu que j'avais beaucoup de convictions dans la vie, je voulais devenir psychologue. je suis pas devenu psychologue loin de là mais parce qu'en fait j'ai toujours un intérêt assez fort dans la compréhension, la connaissance de l'autre et comment est-ce qu'en fait on réfléchit à des sujets je pense que ça a quand même justement un peu de lien avec tout ce qui est aujourd'hui l'intelligence artificielle un peu quelle est la relation entre l'humain et les algorithmes et ce genre de choses mais comme quoi on peut forcément se comprendre quand on est petit passionné

• Speaker #1

  par les interactions entre les personnes et surtout les leviers qui font que les

• Speaker #0

  personne pense d'une telle manière ou d'une autre. Donc c'est un peu la psychanalyse aussi, c'est pas que psychologie, mais c'est assez important et je pense que justement c'est à ses cœurs dans comment est-ce qu'on conduit l'ensemble des changements qui doivent en fait opérer quand on va vouloir faire en fait la mise en place par exemple de cas d'usage IA dans des entreprises.

• Speaker #1

  Merci pour ça Pierre, est-ce que tu peux nous parler un petit peu de ton parcours et t'as un parcours hyper intéressant, hyper dense et qui est assez marqué par l'empreinte du groupe Société Générale. Comment aujourd'hui toi t'es devenu responsable d'une équipe où on verra assez grande ? avec des profils hétéroclites en data. Comment t'en es arrivé là ? Est-ce que tu peux nous expliquer un peu ce que t'as fait ?

• Speaker #0

  Bien sûr. Donc pour faire simple, moi j'ai fait un parcours en maths financière universitaire, pour revenir un peu au début, assez classique, avec beaucoup de maths, beaucoup de finances. Et ma première expérience professionnelle a été à la Société Générale il y a maintenant presque 11 ans. comme j'ai toujours un peu born and raised société générale, j'ai commencé en tant que VIE en salle des marchés à New York, en fait en matière première, et je travaillais sur des outils de pricing et de backtesting sur le pricing des commodities en salle des marchés. Puis en fait, à la fin de mon VIE, je suis rentré en gros en tant que data scientist à l'inspection du groupe Société Générale, où j'ai participé en tant que data scientist à la création d'un data lab à l'époque, qui était en fait dans cette entité. où on a commencé à essayer d'expérimenter avec une équipe qui grossissait petit à petit, quelles étaient les applications de l'IA pour le cadre de l'audit et de l'inspection.

• Speaker #1

  Qui était, j'imagine, un des premiers data lab dans le groupe.

• Speaker #0

  Qui était un des premiers data lab dans le groupe et surtout, en fait, l'audit et l'inspection, c'est une très bonne école pour comprendre l'ensemble de l'entreprise, donc comprendre l'ensemble des processus, ça aide après dans la suite, mais surtout, en fait, où le mandat, c'est d'analyser les données pour vérifier et s'assurer que les choses fonctionnent bien. En fait, c'est un vrai terrain de jeu pour l'expérimentation et l'exploration de type de cas d'usage. Après, au bout de trois ans, trois ans et demi, en fait, il y a un sujet, c'est que c'est de l'exploration. Moi, j'ai eu une envie d'évoluer un peu vers la construction de quelque chose d'assez industriel. Et donc, j'ai eu la possibilité de rentrer à la direction financière du groupe Société Générale pour construire en fait un data lab au sein de cette entité qui devrait pouvoir construire des contrôles sur les processus financiers. Donc ça, ça a été la deuxième partie. Elle a duré à peu près trois ans, cette partie-là, où j'ai créé une équipe FromScribe. Donc j'ai été le premier à rejoindre cette équipe. Et elle a fini à peu près à une dizaine de personnes, 10-12 personnes. D'accord. Et en 2022, en fait, on a construit ce qu'on appelle aujourd'hui notre équipe DataIA au sein de la direction financière, qui est en fait un mandat plus large qu'uniquement des use cases de contrôle sur les processus financiers, mais qui est en fait à complètement l'ensemble des processus financiers pouvoir construire des cas d'usage. Donc aujourd'hui, on a environ 25 personnes. en France, en Inde et en Angleterre, avec des profils assez mixtes. C'est-à-dire qu'on a des data scientists, mais on a des tech leads, des mail leads, on a des DevOps et des mail ops attachés à l'IT, mais qui travaillent de manière dédiée pour nous. On a des développeurs full stack et on a des gens du métier qui sont en fait nos product owners internes chez nous, qui permettent de superviser l'ensemble des projets qu'on réalise.

• Speaker #1

  Donc vous avez en fait toute la panoplie pour livrer de façon quasiment en autonomie l'ensemble des use cases que vous avez dans votre mandat.

• Speaker #0

  Exactement, parce qu'en fait, si on se décrit un peu les axes qui nous gouvernent, en fait, ils sont en trois axes. Le premier, c'est le mandat. Donc, on est ce qu'on appelle une équipe end-to-end. Donc, c'est de l'idéation jusqu'en fait la livraison en production et les évolutions applicatives. La deuxième, c'est en fait, en gros, quels sont les KPIs sur lesquels on mesure notre efficacité. Donc, en fait, il y a le ROI de nos projets et il y a aussi en fait le ROI de nos coûts à nous. C'est-à-dire qu'on est extrêmement concentré sur combien on dépense pour ce qu'on fait. Et la troisième partie, en fait, c'est sur tout ce qui est autour, on va dire, de la gouvernance de notre équipe. Donc, en fait, on a une gouvernance au niveau top management, sur laquelle on présente toutes nos priorisations à six mois, pour faire simple. Et il y a une deuxième gouvernance qui est par cas d'usage, où le sponsor du projet a, entre guillemets, la liberté de pouvoir gérer son projet.

• Speaker #1

  C'est intéressant ce que tu dis, parce qu'en fait, là, tu décris une situation où vous avez, en fait... le devoir de monitorer vos coûts, ce que vous coûtez à l'entreprise, et du coup la valeur que vous mettez en face à travers les différents cadges d'âge, ce n'est pas quelque chose qu'on voit systématiquement dans toutes les équipes data, en tout cas qui ont la responsabilité d'avoir ces deux jambes-là. Du coup, dans quelle mesure, en fait, by design, dès le début de vos projets, vous vous assurez que ce que vous allez construire, vous pourrez le monitorer en termes de valeur générée ? Parce que ce n'est pas toujours évident, j'imagine.

• Speaker #0

  Non, en fait, déjà, à chaque cadrage, Donc après, on va revenir un peu plus tard quand on crée une équipe sur c'est quoi un peu les drivers et les éléments importants. Mais il y a le cadrage d'un projet qui, pour moi, en fait, est l'élément clé. En fait, dans un cadrage, on réalise ce qu'on appelle une note de cadrage. Et ça, j'expliquerai plus en détail. Mais dans cette note de cadrage, on va expliquer c'est quoi les drivers de valeur qu'on va générer. Et ça, ça doit être validé par le sponsor et c'est soumis à priorisation globalement du top management. Et dans cette création de valeur, en fait, il y a plusieurs axes. C'est soit des corrections impactantes pour l'entreprise sur lesquelles on n'attend pas forcément du ROI. mais qui coûte à l'entreprise beaucoup d'argent. Et donc, en fait, ça va forcément quand même mitiger des problèmes. Et donc, ça, ça a une valeur et c'est ça qu'on établit. Soit, en fait, il y a un héroïque qui doit se dégager. Parce qu'en fait, ce que je dis toujours, c'est qu'on ne fait pas de l'IA pour se faire plaisir. Et donc, si jamais on ne voit pas de valeur qui en ressort, en fait, on ne va pas prioriser le projet. Et ça, il faut l'accepter. Et c'est un peu toujours ce que je dis même dans mes équipes, c'est qu'il faut accepter à des moments d'arrêter de faire ce qui ne marche pas. Bien sûr. Parce qu'en fait, ça, c'est un biais qu'on a tous connectivement, si on revient un peu à la partie psychologique. C'est que quand on lance quelque chose, on a beaucoup de mal à l'arrêter. Et ça, en fait, nous, c'est pour ça qu'on a un pilotage un peu top niveau pour pouvoir dire, si quelque chose ne marche pas, on les priorise. Parce que peut-être qu'on n'est pas assez mature, peut-être qu'on n'a pas la capacité de le réaliser, peut-être que ceci, peut-être que cela. Et donc, c'est ça un peu, nous, notre, on va dire, by design, notre modèle de fonctionnement. Plus que de dire c'est combien en euros que ça rapporte. C'est que c'est un modèle by design qui établit... quels vont être nos drivers de réussite et de raté et comment est-ce qu'on peut de manière très objective et factuelle établir la qualité de ce qu'on fait.

• Speaker #1

  Et d'accepter en fait via ces process que l'organisation incentive les personnes à tester, prendre des actions et à la fin dans cette note de cadrage, comme tu dis, si en fait on a un proto que ça a l'air hyper stylé techniquement et qu'en fait on pense pouvoir s'amuser mais que derrière il n'y a pas l'assiette suffisante pour générer la valeur qui va être en face des coûts. D'accepter qu'on a peut-être appris des choses par ailleurs, en testant techniquement une approche, mais qu'on n'ira pas plus loin. Et ce n'est pas grave. La leçon de tout ça aussi, c'est d'encourager que ce n'est pas un échec d'arrêter un projet.

• Speaker #0

  Exactement. Et là où je vais mettre un petit curseur, c'est que nous, on n'appelle pas un projet tant qu'il n'y a pas eu la validation post-note de cadrage. Donc justement, pour ne même pas considérer que c'est un échec ou une réussite. C'est qu'en fait, dans la phase de cadrage où peut-être un data scientist à 30% va cadrer et voir un peu à quoi ça ressemble, en fait, ça, on ne va même pas le comptabiliser. En fait, c'est une poche qu'on a le droit d'utiliser et qui, en fait, est sur le fait que tant que le projet n'est pas démarré, ce n'est pas un projet.

• Speaker #1

  Super, très clair. Et pour revenir rapidement sur ton parcours, tu as parlé d'une expérience à New York dans un poste de commando. Est-ce que tu pourrais expliquer rapidement en quoi ça consiste et peut-être en quoi ça t'a préparé ? dans ce qui t'a derrière été un poste plus classique de data scientiste, parce qu'à l'époque où j'imagine je sortais d'école, il n'y avait pas encore ce type de poste. Et qu'est-ce qui toi te motive, en tout cas dans ces métiers de la data, de la data science, qu'est-ce qui te stimule ?

• Speaker #0

  De manière assez simple, un commando c'est quoi ? C'est un développeur dédié au trading, on va dire ça comme ça, et qui fait beaucoup de maths appliquées. C'est je pense la définition la plus vulgarisée possible. derrière en fait ce que ça veut juste dire c'est que un trader a besoin de construire certaines applications de practicing de pouvoir backtester un certain nombre de stratégies d'options de tout ce qu'il veut et donc le commando doit mettre en place un ensemble de briques applicatives avec un certain nombre de package de code qu'il utilise des quantes qu'il utilise des frontends qu'il utilise d'un certain nombre de personnes pour ensuite assembler ses briques et les déployer en production ça ressemble beaucoup à ce que fait un data scientist ou un machine learning engineer de comprendre en mathématiques appliquées qu'est-ce que fait un algorithme, de bien pré-processer ces données pour pouvoir ensuite les mettre en tant qu'input d'un modèle pour pouvoir prédire quelque chose. En fait, je fais toujours ce parallèle qui est que, entre guillemets, pour moi, la data science et les data scientists ou les ML engineers, en fait, c'est la version moderne de l'ensemble de ces types d'applications. Où c'était, par exemple, dans l'industrie, ce qu'on appellera la recherche opérationnelle, où j'ai fait une alternance, justement pour faire un peu le lien. Ou justement, tout ce qui était les développeurs en salle des marchés. Parce que c'est exactement le même principe cognitif qui est de prendre des briques des autres pour en construire quelque chose de robuste et d'applicable à son problème. Et ça, en fait, pour moi, quand on dit quel lien ça fait...

• Speaker #1

  C'est pour recommander aussi des décisions.

• Speaker #0

  Exactement, pour recommander des décisions, mais surtout, en fait, de se dire, nous, on utilise des briques que plein de gens font, sur lesquelles on doit avoir une confiance. Par exemple, pour donner un exemple concret en machine learning, si on utilise un réseau de neurones de Keras, aujourd'hui, qui va vérifier que la manière dont est construit le réseau de neurones fonctionne bien ? On le trust.

• Speaker #1

  Oui, tout à fait.

• Speaker #0

  C'est la même chose dans les briques quantitatives, c'est qu'on trust les outputs des calculs. Nous ce qu'on construit c'est des algorithmes qui permettent d'utiliser ces calculs pour construire des stratégies de trading. Et donc à quoi ça m'a préparé pour revenir à la question de départ ? C'est à construire des infrastructures robustes et résilientes. Parce que quand on va parler un peu de cas d'usage, nous on a des cas d'usage où il faut être robuste et résilient. Avec par exemple des cas d'usage presque temps réel. Et qui demandent donc des infrastructures très spécifiques qui fonctionnent. Et je pense que le côté salle des marchés. a beaucoup joué dans ma vision de comment on doit construire une infrastructure résiliente.

• Speaker #1

  Très clair. Et j'imagine, si on peut revenir sur la construction de l'équipe, parce que tu as construit une équipe from scratch qui aujourd'hui est, tu disais, 25 personnes. A peu près, oui. Donc comment, en fait, j'imagine que ce type d'expérience, ça aussi t'a conforté dans l'idée d'avoir une équipe pluridisciplinaire et de considérer que la data science est un pan de la solution, mais pas toute la solution, et qu'on a besoin, comme tu dis, pour avoir des architectures robustes, de DevOps. de développeurs full stack, d'avoir un peu toutes ces briques qui s'interfacent entre elles et qui communiquent au sein d'une même équipe. Comment toi, tu as commencé ton équipe ? Par quel type de profil ? Comment tu l'as structurée ?

• Speaker #0

  Déjà, pour remettre un peu dans le cadre, en fait, l'équipe, on s'est dit, on va investir pour essayer de construire quelque chose. Et ensuite, à la fin de cette première phase d'investissement, on va voir comment on doit évoluer. Donc en fait, on a eu une vision, je pense, à la base, qui était la bonne. C'est que toute attente de ROI en cible demande un investissement de départ pour pouvoir réellement qualifier ce qu'on doit faire. Donc au début, j'ai commencé comme tout le monde, j'ai pris 3 data scientists, mais avec dès le départ un profil métier et dès le départ un profil traité COS. Parce que j'ai toujours eu le principe que si on prend que des gens sortis d'école, on ne met que des photos, que des gens qui sont similaires les uns à côté des autres, qui sont probablement très bons les uns et les autres. mais qui, par contre, n'ont pas l'expérience ni le recul nécessaire sur qu'est-ce que ça demande de mettre en production. Et donc, l'idée reçue qui serait, en prenant des data scientists plus ou moins expérimentés, mais qui n'ont fait que de la data science, ça va permettre de construire quelque chose de robuste, je n'y ai jamais cru. J'y crois toujours de moins en moins.

• Speaker #1

  Surtout que là, on est dans une période où, en fait, tout le monde était un peu data scientist, parce qu'en fait, c'était un métier qui s'est structuré petit à petit. Et voilà, peut-être pour resituer, on est quoi, en 2020 ou... 2019.

• Speaker #0

  2019.

• Speaker #1

  2019, et donc... Et donc ouais, en fait on peut s'appeler data scientiste mais avoir un background plutôt métier, plutôt quantique, plutôt stat, etc.

• Speaker #0

  Exactement, et dans la majorité des endroits, dans toutes les entreprises quand j'ai changé avec des compères, en fait il y avait quand même beaucoup d'exploration. Et depuis le premier jour avec ma chef de l'époque et avec mon sponsor de l'époque, on a toujours voulu considérer que ce qu'on faisait c'était que pour de la production. Et c'est ça je pense qui est un peu le curseur de comment j'ai construit cette équipe. C'est qu'on s'est dit, en fait, on ne fait pas ça pour montrer que ça peut marcher. On fait ça pour déployer des usages chez les personnes qui utilisent ce que l'on fait. Et ça, c'est un point qui, en fait, je pense, dans le dogme ou dans l'idéologie ou dans les convictions, parce que je pense que c'est aussi une partie de conviction dedans, en fait, c'est de se dire, ce n'est pas les gens qui doivent adhérer à ce qu'on fait, c'est qu'en fait, on doit aller vers les gens sur ce qu'ils ont besoin et de déployer en fonction de ça. Donc, en fait, plutôt que de dire... En fait, par quel type de profil j'ai essayé ? Plutôt par quel type de cas d'usage ? Et en fait, au début, ce n'était pas forcément beaucoup de ML. C'était beaucoup de statistiques avancées, beaucoup de sujets sur des analyses de variances, sur des analyses un peu de séries temporelles, simplifiées, etc. Mais pour mettre un pied dans la porte de qu'est-ce que ça peut apporter l'analyse par la donnée, avancée, basée sur des modèles simplifiés. Puis ensuite, petit à petit, quand on construit une compréhension de comment ça fonctionne en production, quand on construit un certain nombre de cadres dans lesquels on a du confort,

• Speaker #1

  là on peut aller vers des choses de plus en plus évoluées et de plus en plus avancées ce qui est plutôt en fait notre approche au final top mais ça paraît en fait cohérent et ce qui paraît être la bonne chose de faire les choses c'est à dire identifier les problèmes et puis ensuite plutôt que d'imaginer des solutions des problèmes qui sont peut-être fictifs est-ce que du coup tu peux me parler un peu des grandes missions de ton équipe qu'est-ce que vous faites, quels sont les challenges aujourd'hui ?

• Speaker #0

  Bah peut-être pour expliquer les grandes missions, j'ai juste expliqué en quelques mots qu'est-ce que fait une direction financière pour tous les auditeurs parce que peut-être que des personnes seront moins financières que d'autres et c'est important. Donc une direction financière en fait ça... à peu près trois objectifs. Le premier, c'est d'accompagner les métiers, donc l'ensemble des métiers d'une entreprise. Donc ça va être sur tout ce qui est autour du contrôle de gestion et du forecast, de l'anticipation en fait des revenus futurs, que ce soit en termes réglementaires, en termes métiers, pour en fait mieux piloter là où il y a des coûts, là où il y a des revenus, etc. Ça, c'est le premier axe. Le deuxième, c'est autour de tout ce qui est lié en fait à la production réglementaire et comptable pour en fait faire des publications qui vont être ensuite validées par des auditeurs externes. par nos régulateurs, les rapports annuels, etc. Les états financiers, tout ce qui va avec, exactement. Et le troisième, c'est tout ce qui est la gestion de la trésorerie et de la gestion active-passive. Donc, c'est la gestion du bilan de l'entreprise. Donc ça, c'est plutôt métier, on va dire, entre guillemets. Ce n'est pas de la production ni de l'accompagnement. Et ça, c'est hyper important parce qu'en fait, c'est comme ça qu'on va pouvoir financer, refinancer, faire des vases communicants dans l'ensemble de l'entreprise. Et ça, c'est un aspect très, très, très, très data, justement. parce qu'en fait il y a beaucoup de choses qui sont en rapport avec la partie trésorerie, on en discutera un peu plus tard. Et donc nous, en fait quand on a commencé, on s'est dit, bon bah maintenant qu'on a un mandat de couvrir l'ensemble de la direction financière, selon ces trois grands axes, c'est quoi les grandes familles de cas d'usage ? Et donc les grandes familles de cas d'usage, en fait pour faire simple, il va y en avoir beaucoup autour du pilotage financier, il va y en avoir beaucoup autour de la compta et les reportings réglementaires, et en fait ce sera sur comment on peut accélérer et simplifier certains processus de production de reportings réglementaires. Et le troisième, il va y avoir justement sur tout ce qui est trésorerie. Parce qu'en fait, dans la trésorerie, on a un peu un flagship dedans sur la trésorerie, sur les liquidités intraday. Parce qu'en fait, il y a énormément de données. Et vu que c'est un aspect très métier, en fait, ça s'y prête beaucoup à pouvoir construire des cas d'usage sur ces types de sujets.

• Speaker #1

  Ok. Sur le deuxième pilier que tu as évoqué, on parle de rapport réglementaire uniquement financier ou la performance extra-financière qui est impactée par CSRD, c'est aussi dans votre...

• Speaker #0

  Bah... C'est aussi dans notre mandat, je ne rentrerai pas trop dans les détails parce qu'après ça rentre quand même dans des sujets trop spécifiques à l'entreprise, mais on travaille beaucoup sur la partie CSRD et on travaille beaucoup sur un certain nombre de reporting réglementaire. Ce qui pour moi est un peu une vision de fond, c'est que c'est quoi un reporting financier ? C'est des règles à appliquer sur un bilan. pour faire simple, ou sur des données de back-office, peu importe ce qu'on a. Et en fait, la question, c'est des règles, des modèles d'IA, ils savent très bien les appliquer, on peut apprendre toutes ces règles-là. La seule question, c'est sur quel périmètre le régulateur nous laisse construire nos reportings de cette manière. Parce qu'en fait, construire un reporting à partir d'une IA... En run, ça sera beaucoup moins cher qu'un processus de production compliqué. Par contre, est-ce que le régulateur sera confortable avec ce type d'approche ? Et c'est ça pour moi, en fait, une grande partie du débat. Le débat, il n'est pas forcément technologique.

• Speaker #1

  Dans la partie transparence,

• Speaker #0

  auditabilité, quels sont les garde-fous qu'on doit mettre en termes de backtesting, en termes de reproductibilité ? Et ça, en fait, pour moi, c'est des débats qui doivent avoir lieu et qui, en fait, ne sont pas qu'à mon niveau. C'est un débat de place. Mais je pense que... En tout cas technologiquement c'est faisable.

• Speaker #1

  Très clair. Et donc aujourd'hui parmi ces trois piliers, est-ce que tu veux partager peut-être un cas d'usage qui est un peu emblématique dans votre équipe ?

• Speaker #0

  Bien sûr. Le cas d'usage qu'on a présenté dans plusieurs conférences et qui pour moi est vraiment un peu emblématique sur en fait qu'est-ce que peut apporter la data science dans une direction financière. Donc c'est un cas d'usage sur la liquidité intraday. Donc pour tout le monde la liquidité intraday c'est quoi ? En fait c'est tous les jours, les banques doivent réaliser pour le compte de leurs clients Et pour eux-mêmes, en fait, des paiements aux autres banques pour pouvoir, en fait, entre guillemets, régler l'ensemble des transactions que tous les clients réalisent. D'accord ? Donc, en fait, il y a des comptes dans les banques centrales. Par exemple, il y a un compte à la Banque Centrale Européenne. Et donc, Société Générale a un compte là-bas et réalise un ensemble de paiements. Et ce qui se passe, c'est qu'en fait, tous les jours, il y a de la volatilité sur ce compte parce qu'on reçoit des crédits et on paye des débits. à d'autres banques. Et tout l'enjeu, c'est comment est-ce qu'on aligne au mieux les crédits et les débits. Parce qu'en fait, la volatilité sur ce compte entraîne un besoin de pilotage serré parce qu'en fait, la Banque Centrale Européenne, qui est en fait un régulateur, nous demande de minimiser nos risques vis-à-vis de cette volatilité. Parce que ce qui se passe, c'est que quand on a un niveau de crédit et de débit qui est aligné, c'est-à-dire qu'on a autant de crédit et de débit, mais qu'en fait, on gère mal nos débits,

• Speaker #1

  la volatilité, donc la fluctuation.

• Speaker #0

  La variance, la variabilité, exactement. C'est qu'en fait, quand nos crédits et nos débits ne sont pas alignés, par exemple, on peut consommer de manière, entre guillemets, je vais dire vraiment de manière, entre guillemets, artificielle sur notre balance, donc sur notre compte, parce qu'en fait, on n'a pas attendu de recevoir les crédits pour payer nos débits. Et ça, en fait, on a, entre guillemets, un coussin, un buffer, ça s'appelle dans le jargon, pour pouvoir, en gros, mettre de l'argent pour pouvoir faire face à cette variabilité. Le but du cas d'usage, c'est quoi ? C'est d'identifier les zones de risque, c'est-à-dire identifier quand il y a des stress.

• Speaker #1

  Je rebondis là-dessus parce que c'est super important d'un point de vue réglementaire, parce que les crises qu'on a connues dans le secteur bancaire il y a maintenant plus de 15 ans, c'est aussi lié en fait... à ces risques de liquidité où les banques avaient des engagements qu'elles ne pouvaient pas couvrir parce que par ailleurs elles finançaient...

• Speaker #0

  Exactement. Et en fait, si on regarde, je fais un tout petit aparté, qui est en fait si on regarde un peu la gestion de la liquidité pour le système bancaire, en fait avant on ne faisait que de la gestion long terme de la liquidité. Après on est passé à ce qu'on appelle la gestion court terme, c'est en J plus 1, J plus 2, J plus 3. Et en fait aujourd'hui, en fait le régulateur commence à mettre en place... Une gestion très très forte de la gestion même intraday, parce qu'en fait ce qui se passe c'est qu'il y a des très grandes volatilités de paiement tous les jours, parce qu'en fonction de situation, il peut y avoir des grandes fluctuations, et donc il y a un besoin, comme tu dis, de pouvoir en fait mettre des garde-fous, ou en tout cas mettre un cadre à minima. Et donc nous, le principe du cas d'usage c'est comment est-ce qu'on optimise ce cadre ? En minimisant nos risques, pour faire très simple. Donc minimiser nos risques, ça veut dire quoi ? C'est identifier quand il y a des journées, est-ce qu'on est dans une journée atypique ou pas de consommation de liquidités intraday ? C'est d'identifier les drivers qui permettent de savoir qu'aujourd'hui, attention, on va peut-être avoir beaucoup plus de débit que de crédit. Et donc on risque de creuser notre balance et ne pas pouvoir la compenser si on ne fait pas d'action de management. Du coup,

• Speaker #1

  d'altérer le coussin dont tu parlais.

• Speaker #0

  D'altérer le coussin, exactement. Et donc en fait, ce qui se passe, C'est que quand on voit qu'on altère, il y a un certain nombre d'actions. Par exemple, on a d'autres comptes, nos comptes de sécurité, nos comptes de titres, etc. On peut rapatrier du cash temporairement pour pouvoir compenser justement toutes ces étapes-là. Ça, c'est la première partie, c'est identifier les risques. La deuxième, c'est ensuite, une fois qu'on a identifié nos risques, c'est de se dire est-ce que d'ici une demi-heure, une heure, deux heures, combien j'attends de crédit pour pouvoir savoir comment j'ordonnance mes débits ? Moi, je suis ce qu'on appelle pilote de flux. Pilote de flux, c'est les gestionnaires du compte en temps réel. Ceux qui en fait font les paiements back office au-delà d'une certaine activité. Et donc avec les trésoriers intraday et les pilotes de flux, c'est comment on optimise au mieux en fait tous ces paiements. Et nous ce qu'on donne en fait c'est un modèle de machine learning, on pourra rentrer en détail un peu sur comment il fonctionne, qui prédit à une demi-heure, une heure, deux heures comment va évoluer la balance en banque centrale par typologie de paiement et aussi combien de crédits on attend. Avec des montants, comme ça en fait les pilotes de flux peuvent savoir est-ce que par exemple ils ont besoin de rapatrier du cash de votre compte, est-ce que des paiements qui sont plus ou moins sensibles, ils peuvent les retenir quelques minutes. C'est jamais plus que quelques minutes parce qu'en fait on a des engagements vis-à-vis de nos clients. Donc la question n'est pas de changer nos habitudes de paiement pour les clients, mais c'est plutôt quand c'est à quelques minutes près, de pouvoir avoir une meilleure action que si jamais on n'avait pas l'information. Donc en gros nous on est quelqu'un qui apportons une aide. à l'information, pour pouvoir avoir des actions qui seront correctrices.

• Speaker #1

  Et du coup, vous venez vous intégrer dans ces systèmes qui existent déjà, où tu parles de gestionnaires qui vont derrière prendre les décisions de paiement.

• Speaker #0

  Exactement. Et tout ça, c'est faisable parce qu'en fait, depuis très longtemps, Société Générale a construit un système temps réel de gestion des paiements, qui est en fait un peu, nous, notre golden source, mais qui est construit, utilisable, de bonne qualité, en temps réel. Pour en fait pouvoir gérer tout ça, parce qu'en fait, la source de tout ce qu'on fait, c'est la donnée. Et donc, cette donnée est disponible et c'est ça qui est extrêmement important pour nous. C'est ça qui a permis de construire le cas d'usage. Et à titre d'information, en fait, ce sujet contient 8 modèles, je crois, si je ne dis pas de bêtises, qui tournent à peu près toutes les 5 minutes pour faire des prédictions. Donc, en fait, c'est une volumétrie assez importante de modèles. Je crois que 8, je suis peut-être même un peu en dessous du chiffre, pour pouvoir en fait tout prédire.

• Speaker #1

  8 modèles, est-ce que c'est par... type de produit, par horizon de temps ?

• Speaker #0

  C'est par typologie de paiement. Et en fait, il y a par typologie de paiement à 30 minutes, 1 heure, 2 heures.

• Speaker #1

  D'accord.

• Speaker #0

  Et en gros, comment est-ce qu'on fonctionne ? Pour expliquer, parce que si les gens sont intéressés, c'est qu'en fait, on construit des probabilités théoriques de paiement pour chacun des paiements qui existent dans le stock dedans. Et en fait, à partir de ces probabilités de paiement, on applique un modèle de machine learning qui regarde entre la probabilité théorique et l'instant de paiement et la réalité. Est-ce qu'on est dans un moment normal ou pas normal ? Et en fait, le modèle de machine learning, c'est utiliser cette erreur entre le théorique et le réel et les paiements en attente pour savoir comment vont être tous les crédits qu'on va recevoir, tous les débits qu'on va devoir faire, etc.

• Speaker #1

  Ok, intéressant. Et je vois beaucoup de challenges dans ce type de projet. La faible latence que tu as expliqué, on parle de l'intraday, il y a des décisions assez fréquentes qui doivent être prises sur l'output de ces modèles-là. Le fait que ça doit renaître en production avec des données qui se rafraîchissent continuellement. Bien sûr. J'imagine que ça a été un challenge aussi pour pousser en production, qui a dû avoir une phase de parallèle run, de test, parce qu'au-delà d'entraîner des modèles et de montrer offline quelle est l'accuracie. Il a fallu démontrer la valeur. Est-ce que tu peux expliquer un petit peu quelles ont été les grandes étapes vers le déploiement de ce projet ?

• Speaker #0

  La première, ça a été, et là je pense que c'est le moment pour en parler, ça a été la note de cadrage où en fait, on s'est réunis avec le métier et avec l'IT pendant un certain nombre de workshops pour vraiment cadrer qu'est-ce qu'on veut faire, pourquoi et comment. On n'avait pas encore la vision exacte de comment ça s'opérationnaliserait en production, mais par contre, le sponsor, et c'est ça pour moi le deuxième axe très important, c'est d'avoir un sponsor qui est exigeant et investi. Donc là, c'était en fait l'adjoint de la Treasury Group qui lui a... qui investit de son temps pour montrer l'importance et s'intéresser à comment ça allait être fait. Et il nous a dit deux choses. Il nous a dit, un, moi, je veux quelque chose qui peut s'opérationnaliser. Et deux, je veux qu'on fasse un raci avant même de commencer le projet pour comprendre quels seraient les impacts opérationnels du projet une fois livré. Et ça, en fait, ça nous a beaucoup forcé à réfléchir sur comment on se projette. Une fois que le cas d'usage sera livré, parce que même si on commence à l'utiliser, quelles sont les actions de management ? Donc en fait, on disait, par exemple, comment est-ce qu'on transfère les balances entre les différents comptes ? Combien de temps ça prend entre chaque compte ? Les mesures, en fait, pour savoir est-ce que c'est instantané, est-ce que ça prend 5 minutes, etc. Pour pouvoir savoir quel type d'action, à quelle échelle de temps on a besoin d'avoir la prédiction pour être sûr de pouvoir faire les actions de mitigation quand elles sont nécessaires. Et tout ça, en fait, on l'a construit. Et ça, en fait, c'était avant le lancement du projet. Et ça a permis de se mettre un cadre de travail qui se dit, si jamais on déroge de ça, est-ce qu'on va toujours livrer ce qui a été attendu ou pas ? Et ça a été, en fait, le premier vrai projet où on a fait ça. Donc, en fait, le projet a démarré en 2022, à peu près. Et il a été livré en 2023. Il a mis pas mal de temps, celui-là, parce qu'en fait, comme tu l'as bien dit, il y a beaucoup de cadres techniques. On a dû faire une grande phase du AT. On a dû faire beaucoup de choses. Mais globalement, en fait, dès début 2022, on savait où on voulait arriver. Ouais.

• Speaker #1

  Et ça c'est assez fort comme tu dis l'implication d'un sponsorship qui est assez haut dans l'organisation, qui est investi et avec lequel en fait on définit la vision de comment, quelle est la valeur qui va être produite et comment ça va être opérationnalisé, utilisé. C'est pas dans toutes les organisations qu'on voit l'implication assez haute d'un sponsorship, j'imagine parce que c'est aussi un projet stratégique. Comment derrière vous avez impliqué les personnes qui allaient justement utiliser, tu as parlé de l'implication dans la note de cadrage de l'IT, du business, est-ce que derrière vous aviez, parce que je crois que le Product Owner est chez vous, comment vous assurez que derrière les gens allaient utiliser les recommandations, les prédictions qui sont...

• Speaker #0

  Le Product Owner en fait n'est pas chez nous, j'emploie Product Owner parce qu'en fait c'est comme ça que les gens disent dans le jargon, mais moi je appelle ça Use Case Leader chez nous, en fait c'est des gestionnaires de projet plus plus qui sont une bonne relation métier. Toute la PMO... Toute la PMO, mais pas que. En fait, c'est même toute la gestion des data scientists sur la priorisation des tâches, etc. Et en fait, c'est vraiment le terme que j'emploie qui, pour moi, représente le plus leur rôle, c'est use case leader, même si ce n'est pas un terme vraiment employé, mais parce que je pense que ça établit bien leur rôle chez nous. Et donc, justement, le Product Owner a été très investi. Enfin, il y en a eu deux, et ils ont tous les deux été très investis parce qu'en fait, nous, on utilise une carte qui est assez importante, c'est la transparence. C'est-à-dire... L'IA, ce n'est pas de la magie, ça a des défauts, ça a des qualités. Et donc, quand on va aller dans une direction, c'est toujours d'expliquer c'est quoi les risques, ce que l'on prend. Et comme ça, en fait, quand on dit qu'on prend des risques, on ne les prend pas seuls, on les explique. Et si les gens ont besoin d'être assurés, en fait, on leur donne suffisamment de possibilités. Et si jamais à la fin, ils ne sont toujours pas convaincus, il vaut mieux ne pas faire que de faire avec des gens non convaincus.

• Speaker #1

  Mais du coup, est-ce que vous avez rencontré des freins à l'adoption et même en amont du projet ?

• Speaker #0

  Sur ce projet-là, à l'adoption, non, parce que le cadre était vraiment bien mis en place. Parfois, l'adoption est un peu plus difficile parce qu'en fait, je ne rentrerai pas forcément dans les détails de tous, mais parfois, ce qui peut se passer, c'est que sur certains projets, on commence avec un périmètre, puis ensuite, quand c'est étendu aux autres, l'adoption est plus difficile parce qu'ils n'ont pas fait partie de la genèse. Pas qu'ils ne veulent pas. Mais vu qu'ils n'ont pas été à la jeunesse du projet, en fait, ils le voient un peu comme quelque chose qui leur arrive depuis une contrainte. Et ça, c'est une réalité. Et ça, je pense que c'est quelque chose où on peut toujours s'améliorer. Là, le vrai sujet, ça a été comment est-ce qu'on construit une infrastructure résiliente qui soit capable en temps réel d'intégrer l'ensemble des paiements, l'ensemble des paiements en attente, l'ensemble des réceptions de crédits et qui soit capable aussi d'interagir de manière sécurisée avec un système qui est lui considéré comme très, très, très, très, très important pour le groupe. Et donc, nous, on ne peut pas mettre en risque la production de cet écosystème. Et donc, en fait, c'est tout ça qui a fait que, entre guillemets, globalement, au bout de 12 mois, 13 mois, nous, on avait à peu près fini la première version de ce qu'on faisait. Il y a eu environ six mois sur celui-là de phase d'industrialisation et de mise en production. Mais, par exemple, sur la majorité de nos autres cas d'usage, si jamais ils sont plutôt sous forme de batch ou sous forme d'API, etc., le temps d'industrialisation est plutôt autour d'un mois. et en fait c'est un peu plus court celui-là c'est parce que 1 c'était la première fois qu'on faisait vraiment un projet aussi structurant et 2 parce qu'en fait vu qu'il était très structurant il y a eu un certain nombre de choses qu'on a dû mettre en place vous avez essuyé les plâtres moi ça me choque pas un an pour un projet de cette envergure est-ce que malgré

• Speaker #1

  tout parce que l'humain reste décisionnaire de ce que je comprends dans... les transactions de paiement et tout le balancing des bicrédits. Est-ce que vous observez que la solution est déployée et en tout cas un certain nombre d'opérateurs qui ont accès à ces prédictions ? n'utilisent pas ou en tout cas dans les actions qui sont prises ne suivent pas les recommandations ? Est-ce que ça a été un sujet pour vous ?

• Speaker #0

  Il y a eu un sujet de change management qui a été fait, mais en fait on a onboardé tout le monde depuis le début, et justement dans la phase de 6 mois, on a fait beaucoup de temps avec l'ensemble des opérationnels, et sur celui-là on a des calls hebdomadaires quand même aujourd'hui, pour suivre en fait ce qui se passe, parce qu'en fait le cas d'usage n'est pas fini, il y a encore des évolutions en cours, il y a pas mal de choses qui sont encore là, parce que par exemple... travaille sur est-ce qu'on ne pourrait pas justement proposer quels sont les débits à ordonnancer à quel moment etc. Aujourd'hui, plus planification c'est un problème d'optimisation sous contrainte si on le pense d'une certaine manière et donc voilà ça, ça fait partie des choses en cours mais sur ce type de cas d'usage si jamais en fait on fait le travail de transparence et c'est vraiment pour moi le sponsorship et la transparence c'est les deux éléments clés qui font que on ne peut pas considérer qu'on a encore des obstacles si jamais eux deux sont vraiment bien faits.

• Speaker #1

  Ok. Donc sponsorship et transparence vis-à-vis des utilisateurs.

• Speaker #0

  Voilà. Pour expliquer, par exemple, nous on a construit en temps réel des KPIs qui expliquent est-ce que notre modèle est en train de dévier dans sa qualité de prédiction ou pas. Donc en fait, en temps réel, on monite et on le restitue à l'utilisateur. Ok. C'est partagé. C'est partagé. Et donc ce n'est pas juste dans un MLflow, ce genre de choses. Ce n'est pas mis dans un MLflow loin de tout le monde. C'est mis en temps réel, restitué à l'utilisateur. Et en fait, on lui a expliqué quels sont les ordres de grandeur au-delà duquel il ne doit plus faire confiance au modèle. Parce que là, ça veut dire que ça dévie.

• Speaker #1

  Et du coup, vous avez, j'imagine, dans ce process de monitoring des performances du modèle, vous avez un process de retraining des modèles, d'identifier.

• Speaker #0

  Oui, automatique.

• Speaker #1

  S'il y a des problèmes de qualité.

• Speaker #0

  On identifie les drifts automatiquement via des métriques qu'on a construites.

• Speaker #1

  Ok.

• Speaker #0

  Sur celui-là, il y a tout ça.

• Speaker #1

  Et dans les drifts que vous avez identifiés, est-ce que c'était plutôt lié à un changement juste de l'environnement, dans les comportements de paiement, etc. Ou est-ce que vous avez des sujets de qualité de données où les prédictions n'étaient pas bonnes, mais plus du fait de la qualité que de la réalité du comportement ?

• Speaker #0

  Sur les paiements, la qualité de données est bonne. Je ne pense pas que ce soit un sujet où là... Parce que globalement, les paiements, c'est ce qui représente l'activité client. Et donc, on ne peut pas faire de ratés sur ce type de sujet. Et ça, c'est important de le préciser. Par contre, le drift, en fait, on a fait une étude en amont. de comprendre quel était le concept optimal de réentraînement des modèles. Parce que par construction, les paiements c'est mouvant. Ça dépend à ce qu'on est dans une phase de pression, par exemple dès le début de l'inflation, la guerre en Ukraine, quand c'est un certain nombre d'éléments avec un contexte géoéconomique, les comportements changent. Mais même au quotidien, les comportements changent en fonction des périodes, en fonction de s'il y a un problème de croissance, s'il y a plus d'activité économique ou pas. Et donc... On a défini une période de réentraînement fixe qui en fait est un peu liée à, selon nos observations statistiques, un cycle de changement de régime et qui permet de garder le modèle avec un bon niveau de précision. On a la capacité en fait, on demande, si jamais on s'en rendait compte que le modèle ne fonctionne pas parce qu'il a besoin de données plus récentes et d'être réentraîné, en fait on pourrait le faire tourner à n'importe quel moment. Parce qu'on a construit une pipeline industrielle de réentraînement, c'est pas on prend le modèle, on le met à côté et on les donne, c'est vraiment en fait totalement industrialisé. À un moment, en batch, on recrée le modèle, on le repoute dans MLflow avec un nouveau registrier et puis après, il est accessible.

• Speaker #1

  Ok. Et du coup, j'imagine, vous regardez, est-ce que vous avez des critères d'acceptance ? Est-ce que le modèle atteint à minima tel niveau de performance ? Et si oui, il peut passer dans une phase de déploiement, etc.

• Speaker #0

  Exactement. Mais ça, en fait, par construction, aujourd'hui, on n'a pas encore rencontré des moments. où le modèle n'a pas passé, pour être assez transparent. Probablement, un jour, ça va arriver, parce que peut-être qu'il faudra qu'on change les types de variables qu'il y a eu dans le modèle pour l'apprentissage, parce que peut-être que ce sera plus valable. Mais aujourd'hui, on est encore dans une phase où pour l'instant, on n'a pas rencontré ces cas-là. Dans d'autres cas d'usage, on a eu ce sujet. C'est intéressant.

• Speaker #1

  Donc, ce que tu dis, c'est qu'aujourd'hui, j'imagine que c'est un modèle ML basé avec du feature engineering. Vous avez créé des features, donc pas des modèles non plus complètement... où on déporte le feature engineering au modèle type de Rhone, etc. Il y a aussi la visibilité, peut-être des contributions, peut-être des variables à la position.

• Speaker #0

  Et surtout, si je reviens sur comment est fait le modèle, c'est qu'on a construit des modèles théoriques qui sont basés sur des probabilités. Et en fait, nos modèles de ML s'adaptent entre la réalité de la théorie et le jour donné. Et donc, en gros, son inférence est très balancée. En gros, il ne peut pas être octogone. très très mauvais de manière facile parce qu'on n'est pas avec du feature engineering où on dit est-ce qu'on prend les valeurs moyennes de je ne sais pas quoi etc on est vraiment dans du feature engineering centré sur la réalité vs la probabilité théorique oui

• Speaker #1

  Et oui, j'imagine qu'est-ce qu'on a des énormes fluctuations à 30, à 1h, ou c'est relativement un problème qui est relativement prévisible, en tout cas sur un horizon de temps qui est proche ?

• Speaker #0

  Si on a fait une demi-heure, une heure, deux heures, c'est parce qu'en fait, on voit qu'il y a des paliers de précision, bien sûr. Et globalement, plus on va loin dans le temps, moins c'est prévisible, ce qui paraît jusque-là assez tautologique. La tendance, justement, qu'est-ce qui est important, c'est que parfois, on va observer qu'à une demi-heure, ça monte, à une heure, ça baisse. Et c'est vraiment comme ça que ça va se passer. C'est-à-dire que les modèles ont la capacité d'inférer ces sujets-là. Et c'est ça, nous, qui est important. C'est pour ça qu'on met des paliers. Parce qu'en fait, si on faisait qu'à une heure, on devrait faire des simulations. C'est quoi tous les chemins possibles jusqu'à une heure ? Et en fait, le chemin possible principal, ce serait le chemin médian.

• Speaker #1

  C'est un peu négatif si on ne peut pas imaginer que ça augmente et ça va continuer à augmenter.

• Speaker #0

  Exactement, exactement, exactement. Et c'est pour ça qu'on a fait par palier une demi-heure, une heure, deux heures. C'est pour donner une trajectoire avec un semblant de courbe plutôt que des points fixes et sur lesquels on ne pourrait pas forcément donner le chemin. Top,

• Speaker #1

  top. On va se parler un peu d'IA générative. Je pense que ça reste un sujet notamment sur... sur les deux premiers piliers dans votre mandat. Est-ce que tu as... Tu peux partager en tout cas ce que tu peux partager, quelles sont les initiatives ou en tout cas la stratégie, le positionnement autour de cette opportunité, autour de l'IA générative, éventuellement des cas d'usage que vous avez identifiés et là où vous imaginez ou percevez peut-être déjà à travers certains protos ou certains cas d'usage de la valeur pour le groupe ?

• Speaker #0

  Pour le groupe, en fait le groupe est en train de travailler une stratégie sur l'IA générative assez ambitieuse. Avec un certain nombre de sujets emblématiques dedans, les premiers étant comment pouvoir en effet faire de l'onboarding client, comment pouvoir faire un certain nombre de choses de manière plus automatisée mais sécurisée en termes de qualité. Parce qu'une des valeurs qu'apporte l'IA générative, c'est de pouvoir avoir une meilleure intégration et compréhension de l'information qu'on lit dans des documents. Parce que c'est ça que ça apporte, parce qu'en fait, si on simplifie, avant, il y avait le NLP, puis après, il y a eu les Transformers, puis après, il y a eu les LLM. Et les LLM, c'est juste la couche un peu ultime, pour le moment, de cette capacité où la contextualisation permet une régénération de l'information. Ce n'est pas juste un Transformers qui te dit, j'ai compris le contexte, demande-moi ce que tu veux dans ce contexte. Là, c'est j'ai compris le contexte et je te le restitue. Et donc ça, ça apporte en fait une grande capacité si on y réfléchit à faire des choses. Par exemple, au sein de la direction financière, il y a un certain nombre de sujets où on doit définir des éligibilités à un certain type de traitement, par exemple comptable ou des choses comme ça. Donc en fait, il y a des questionnaires, des choses comme ça et on doit dire est-ce que ce contrat est éligible ou pas ? Est-ce que ceci est éligible ou pas ? En fait, on pourrait imaginer qu'en customisant bien et en faisant des bonnes hyperparamètres, des bonnes hyperparamètres optimization, pouvoir construire des IA génératives proposant la réponse au questionnaire et surtout en donnant la piste d'audit de pourquoi il a formulé ces réponses-là. Donc en fait, on commence à réfléchir un peu au concept des agents. C'est pour ça que je venais là. C'est que pour moi, le vrai usage en cible de l'IA générative, c'est le jour où ce sera suffisamment mature pour pouvoir construire des agents intégrés où ils pourront ingérer des informations, puis ensuite... répondre à un certain nombre de sujets et à la fin en fait faire les actions sous jacentes des réponses qu'ils auront généré parce qu'aujourd'hui la limitation si on parle beaucoup du rack c'est très bien pour pouvoir aider les personnes je suis d'accord mais en fait il ya un certain nombre de cas où en fait aider n'est pas le sujet c'est pas d'une augmentation ce qu'on a besoin c'est de pouvoir en fait générer le process de bout en bout par une machine parce qu'en fait il y a des difficultés de pouvoir seulement faire une augmentation et de pouvoir, via cette augmentation, apporter une efficacité réelle.

• Speaker #1

  Ok. intéressant et donc dans votre contexte l'idée ce serait d'être capable de générer tout le rapport qui serait bien sûr revu, amendé, corrigé, validé par un humain mais en tout cas d'être en capacité de digérer du contenu notamment via des documents pour être en capacité par exemple de générer un rapport pour le régulateur qui permettrait de...

• Speaker #0

  Je pense que toujours il y a une question de risk acceptance. Pour moi je pense qu'il faut faire attention tout ce qui est régulateur par exemple. il y a un cadre et en fait ça doit être discuté en amont, validé par le régulateur. Il y a par exemple l'IA Act qui est en place, etc. pour le cadre global de l'usage de l'IA. Mais il y a aussi même nous, les risques qu'on accepte de prendre dans notre fonctionnement. Je pense qu'en tant que banque, c'est comme si on dit je vais générer, on va dire en IA générative, quelque chose que je fais avec un client directement. On a vu dans la presse des procès et des choses comme ça qui se passent quand on le fait. Et je pense que ça, c'est un axe. on va dire, important de réflexion pour se dire est-ce qu'on veut aller jusque là ? Et si on va jusque là, qu'est-ce qu'on met comme garderelle ? Qu'est-ce qu'on met comme protection ? Qu'est-ce qu'on met comme, on va dire, ensemble de choses pour être sûr que ça marche ? Moi, je parle plutôt sur des process internes. Ok. Sur lesquels, en fait, parfois ça peut être assez lourd à produire et sur lesquels, en fait, la valeur ajoutée des personnes sous-jacentes n'est pas forcément très importante. Mais pour autant, on doit le faire. Et donc sur tous ces sujets-là, pourquoi pas avoir une automatisation, qui ne dit pas en fait validation automatique, il vient juste une automatisation de la complétion d'une première version d'un document. Et sur ça, je pense que ça apporte beaucoup de valeur. Parce qu'après le débat sur est-ce que ça va vraiment changer l'ensemble du travail, etc., je pense que c'est comme toute révolution ou évolution, peu importe le niveau qu'on y met, en fait ça apporte des changements. Est-ce que ça va réellement changer fondamentalement les méthodes de travail ? Je pense qu'aujourd'hui, on le sait un peu trop parce qu'en plus, quand on lit un peu la presse, on voit qu'il y a un peu quand même un push-back de beaucoup d'acteurs sur ces sujets-là. Parce qu'en fait, on a vendu que ça allait être rapide à être déployé. Aujourd'hui, il faut se constater que peu d'entreprises ont vraiment de manière systématique dans leur usage.

• Speaker #1

  Et donc, pour faire le lien avec ce que tu dis, est-ce que sur la première mission, qui est plus la partie de ce que j'en comprends, contrôle de gestion, suivi budgétaire, forecast des prévisions, est-ce qu'il y a des identifications de cas d'usage qui pourraient... l'Everage lié à Générative, justement, pour par exemple expliquer des différences de coûts, de budget entre deux années, etc. Est-ce que sur la partie plus analytics, c'est-à-dire être capable de digérer la donnée en interne et comme tu dis, produire une forme d'interprétation de la donnée, est-ce que c'est des sujets qui sont d'intérêt chez vous ou pas ?

• Speaker #0

  Alors, c'est des sujets qui sont clairement en étude chez nous. On discute souvent de ça, on cadre, on a un petit peu de travaux, justement, sur ce type de cas d'usage. La vraie question, c'est qui garantit la bonne réponse lorsqu'il va y avoir des opérations mathématiques faites par cette IA. Parce qu'on sait tous que même GPT-4O n'est pas parfait sur ces sujets-là. Et donc...

• Speaker #1

  Comment s'assurer que le modèle délègue bien...

• Speaker #0

  Délègue bien...

• Speaker #1

  Les fonctions dont c'est le rôle de calculer.

• Speaker #0

  Dont c'est le rôle de calculer, exactement. Et que chaque chiffre qu'il va restituer sont bons. Parce que globalement, on sait qu'il y en a qui seront bons. Globalement, on sait qu'il va comprendre un certain nombre de choses. Mais par exemple, si on parle sur les coûts ou si on parle de résultats ou de PNB ou de revenus, si une IA se trompe et produit une mauvaise valeur et que quelqu'un n'a pas vérifié ce chiffre...

• Speaker #1

  Et que ça finit dans le rapport annuel.

• Speaker #0

  Même si ça finit dans le rapport annuel dans certains endroits, ça pose question.

• Speaker #1

  Bien sûr.

• Speaker #0

  Et je pense que ça, c'est quelque chose qui aujourd'hui n'est pas encore garanti. Donc on travaille dessus. Nous, on fait des expérimentations pour pouvoir faire des premiers prototypes et potentiellement mettre des premiers cas d'usage sous contrainte sur ce type de sujet. Mais on y va de manière très précautionneuse.

• Speaker #1

  Merci Pierre. Si on devait revenir un peu sur les conseils, même si tu l'as déjà évoqué, à des leaders qui sont dans cette aventure de livrer des projets d'IA, de mettre l'IA dans la main d'utilisateurs pour créer de la valeur, qu'est-ce que toi tu conseillerais ? de ton expérience, de mettre en place les bonnes pratiques, peut-être les risques à éviter, qu'est-ce que toi tu mettrais en avant comme conseil ?

• Speaker #0

  Si jamais je dois parler sur la partie d'abord leader, la première chose c'est de ne pas spécialement uniquement en fait, quand je dis ça je vais faire exprès de faire un propos un peu embêtant mais de ne pas aller uniquement en parler sur des endroits mais aussi d'y passer du temps En fait pour réellement comprendre comment ça fonctionne parce que et ça je l'ai vu sur un certain nombre de personnes qui vont superviser en fait ce qui est important c'est qu'ils comprennent et qui donc derrière ils ont les bonnes intuitions pour pouvoir en fait après faire confiance à la personne qu'ils vont choisir pour exécuter leur vision.

• Speaker #1

  Ou c'est les manches, tétés...

• Speaker #0

  essayer de comprendre et après tester soi-même pas forcément mais au moins d'accorder du temps pour lire un certain nombre de documents par exemple attention is all you need ok des papiers de recherche mais même s'ils le lisent en diagonale de comprendre l'intuition qui est derrière c'est pas magique comme tu disais parce que c'est pas magique et en fait si jamais il n'y a pas ça il y a un moment où la vraie discussion d'une fois qu'on construit en fait notre ambition ensuite il faut avoir la vision de ce à quoi ça va ressembler puis ensuite il faut avoir la capacité d'exécution et si jamais la personne qui va superviser ça en tant que leader n'a pas la capacité de pouvoir avoir un peu un challenge un effectif challenge de ce que la personne en dessous va faire en fait c'est là où ça va créer des différents et en tout cas ça va créer potentiellement des tensions quand les choses vont bien marcher alors que si jamais la personne au dessus elle comprend les problématiques elle y passe un peu de temps bah en fait derrière Justement quand il va y avoir des challenges, il va pouvoir réellement avoir une force de proposition et pouvoir même si ça dévie lui-même dire attention là c'est pas exactement là où on voudrait aller.

• Speaker #1

  On a parlé de pas mal de choses. Est-ce qu'il y a des sujets là aujourd'hui dans l'équipe ou si vous avez du temps d'expérimentation, à quoi vous aimeriez les dédier justement pour être prêt dans les quelques années à venir vis-à-vis de l'évolution que tu vois émerger ?

• Speaker #0

  On va dire, chez nous, il y a deux sujets parce qu'en fait, on est une équipe qui travaille beaucoup sur des modèles de séries temporelles. La finance, c'est des données quantitatives et donc la quantitative et le temps, ça donne des séries temporelles, pour faire simple. Et il y a deux grands domaines sur lesquels j'aimerais beaucoup… pouvoir avancer et j'ai même essayé à un moment de pouvoir trouver un partenariat mais pour l'instant ça n'a pas été couronné de succès. C'est un en fait l'application des modèles de Transformers à des problématiques de série temporelle parce qu'en fait avec les encodeurs et décodeurs de pouvoir voir à quelle mesure ils sont capables d'inférer un certain nombre de complexités de drivers en gros automatiquement via ce type de méthode et la deuxième partie c'est en fait il y a beaucoup de domaines financiers où il y a peu de points l'historique parce que par exemple les arrêtés comptables c'est tous les trimestres, tous les mois, certains reporting c'est toutes ces périodes là et donc on a peu de points mais par contre ces reporting sont très riches en termes de données c'est à dire qu'il y a des millions d'instances pour chaque point qui représente tous ces reporting et donc la question ce serait comment on peut construire des modèles de séries temporelles très avancées ou très bons qui sont capables d'identifier des drivers un peu implicites mais avec peu de pas de temps, mais par contre beaucoup d'instances par pas de temps. Oui,

• Speaker #1

  c'est-à-dire une granularité plus fine.

• Speaker #0

  Voilà, une granularité plus fine. Le signal du revenu. Le revenu, exactement, parce qu'en fait, où il n'y a pas que de l'autocorrélation en fait. Et ça, en gros, c'est un sujet qui aussi dans la recherche a quelques cas, mais en fait, il y a quelques papiers, mais ce n'est pas encore extrêmement important parce qu'en fait, ce n'est pas le sujet majeur dont ils sont passés dedans.

• Speaker #1

  Pierre, on arrive à la fin de cet entretien. Merci beaucoup pour ton temps. J'aimerais que je vais te poser quelques questions qui sortent un petit peu du cadre de ce qu'on vient de discuter. Mais est-ce que tu aurais un livre ou un film qui t'a marqué au cours des six derniers mois que tu voudrais partager et qu'on mettra dans les notes ?

• Speaker #0

  Je suis très documentaire et donc je vais partager un truc qui m'a donné un peu de nostalgie. C'est le reportage sur DJ Mehdi qui s'appelle Made in France sur Arte.

• Speaker #1

  Je suis en train de le voir en fait.

• Speaker #0

  Il est extrêmement bien. Il y a beaucoup de choses que j'ai vu que j'ai bien aimé. ou que j'ai lu, mais celui-là m'a à part de faire retoucher.

• Speaker #1

  Top, je valide complètement. Et est-ce que tu veux partager peut-être une ou deux habitudes que tu mets en pratique au quotidien et dont tu penses que ça participe à l'efficacité que tu as dans ton boulot ou d'un point de vue perso ?

• Speaker #0

  Alors, la première chose que je mets en place dans mon quotidien, c'est un truc très bête. très bête mais assez important, le repassage de ma chemise le matin. Non mais parce qu'en fait c'est bête mais c'est un moment pour démarrer sa journée, donc quand on va au travail. Et je vois la différence par exemple parfois quand je suis en télétravail et que je le fais pas. Et donc souvent quand je suis chez moi, j'essaie de faire quand même maintenant de plus en plus une routine avant de travailler aussi le matin pour justement mettre en place la journée. Et bon c'est un truc un peu bête mais malgré tout, je trouve quelque chose d'assez important. Après si je vais sur un sujet plus professionnel et qui pour moi est assez important et c'est peut-être plutôt pour toutes les personnes qui sont en train de créer des équipes et ce genre de choses, en fait à chaque fois que j'ai un one-to-one avec mon chef, je le prépare. C'est bête de dire ça mais je prends un petit document et je m'écris tous les sujets, je les prépare en fait sur qu'est-ce que je veux dire, pourquoi et je lui partage. Donc en fait en amont du point j'ai déjà envoyé tout ça. Et donc après, ça permet de balayer les sujets qui, soit sont de moindre priorité rapidement, soit qui doivent être portés de le faire un peu plus tard. Mais ça organise le temps d'échange.

• Speaker #1

  Bien sûr.

• Speaker #0

  Et c'est assez important.

• Speaker #1

  Et ce n'est pas parce que le meeting est récurrent que finalement, on va rentrer dans une forme de... Exactement....déattente de se voir pour se parler, imaginer de quoi on va discuter.

• Speaker #0

  Exactement. Et ça, pour moi, c'est assez clé parce qu'en fait, ça met un cadre d'échange qui fait qu'on doit être productif.

• Speaker #1

  Yes.

• Speaker #0

  Et je trouve que ça, c'est hyper important. Et peut-être le dernier point qui est aussi assez important, et ça c'est quelque chose que je voulais vraiment partager, c'est qu'en fait, c'est pas quotidien mais c'est plutôt fréquent, c'est j'organise avec tous les membres de mon équipe des échanges en bilatéral, même ceux qui ne me sont pas rattachés directement, par exemple s'il y a des manières intermédiaires, c'est pas grave, je continue à les voir au moins tous les deux mois, une demi-heure pour savoir comment vont les personnes, pour en gros créer du lien. Et je pense que c'est important parce que quand on est dans des situations où il y a des tensions, où il y a des obligations de résultats, où il y a beaucoup de travail, en fait ce lien... que l'on crée entre les différentes couches de l'équipe permet aux personnes de faire le petit miles supplémentaire d'effort au moment où c'est nécessaire garder le lien avec les personnes et comprendre les mécanismes de comment ce qui les motive,

• Speaker #1

  ce qui les stimule et si on fait le lien et la boucle avec ta vocation de psychologue probablement ça doit jouer à mon approche merci beaucoup Pierre pour ton temps, on a appris beaucoup de choses et j'espère te revoir dans un prochain épisode merci beaucoup et je souhaite une bonne journée à tout le monde Merci Pierre.

• Speaker #0

  Merci.