Olivier Louis Monnier (CDO Matmut) : « Industrialiser, c’est un investissement. Il faut bien choisir les cas d’usage. »

Olivier Louis Monnier est le Chief Data Officer (CDO) du groupe Matmut. Il a rejoint le groupe d’assurance mutualiste en 2021, au moment de la création d’une direction Data & Analytics autonome. Pour CIO, il explique le rôle, l’organisation et le fonctionnement de cette direction, les différents enjeux rencontrés, ainsi que les sujets sur lesquels travaillent ses équipes.

CIO : pour commencer, pouvez-vous nous retracer ce qui a conduit à la création de la direction Data à la Matmut ?

Olivier Louis Monnier : auparavant, la Matmut possédait déjà un data lab, qui était alors hébergé au sein de la direction IT. Il s’agissait d’un vrai laboratoire, à vocation plutôt exploratoire, pas forcément prévu pour l’industrialisation. Comme il était rattaché à l’IT, il était un peu loin des métiers, ce qui entraînait une certaine latence entre l’expression d’un besoin et sa prise en compte.

Lors du comité stratégique 2021-2023, la Matmut a décidé de faire de la data une de ses priorités stratégiques. À ce moment-là, le groupe a décidé de créer une direction Data & Analytics, directement rattachée au comité exécutif plutôt qu’à l’IT ou aux métiers. C’est là que j’ai rejoint la Matmut, avec une feuille de route précise : définir et promouvoir la stratégie data, chercher des cas d’usage, les monter à l’échelle et les mettre en production.

Nous avons créé la direction, recruté, défini l’écosystème technique ainsi qu’une méthodologie pour identifier et sélectionner les cas d’usages au sein de la Matmut.

Quelle organisation avez-vous mise en place ?

À l’époque de sa création, la direction comptait trois départements, qui couvrent toute la chaîne de valeur de la donnée : data analytics, data sciences et data engineering. Le département data analytics écrit la roadmap. Les sujets qui nécessitent de la modélisation passent au département data sciences, qui travaille de façon assez classique, en mode laboratoire, mais dans une optique d’industrialisation. Cela signifie que dès ce stade, il faut déjà intégrer des éléments de data engineering. Ensuite, les projets passent à l’équipe de data engineering, qui réalise l’industrialisation, mais pas la montée en production. Cette dernière étape reste dans le périmètre de l’IT, qui gère tous les aspects liés à l’ingestion des flux et à la production.

Il y a six mois, nous avons ajouté un quatrième département de data management. Celui-ci s’occupe de la gouvernance de la donnée et assure également la chefferie de projet, afin de s’assurer que les trois piliers précédents soient bien coordonnés.

C’est une recette qui a bien pris. Aujourd’hui les sujets analytiques sont largement promus au sein du groupe.

Selon vous, qu’est-ce qui fait que cette organisation fonctionne bien dans le contexte de la Matmut ?

Deux points : d’abord, le fait qu’il s’agisse d’une direction à part, autonome. Nous sommes une petite équipe comparée à l’IT, mais nous avons toutefois du poids, nous sommes très visibles et agiles.

D’autre part, le fait de fonctionner comme une petite start-up au sein d’un grand groupe. Cela permet d’absorber les écarts de rythme entre métiers et IT, qui autrement peuvent entraîner des frictions, avec d’un côté le métier qui avance très vite, avec des variations importantes, et de l’autre l’IT qui a une trajectoire plus constante et lente, avec le besoin de sécuriser les choses. Nous avons un premier département, analytics, proche de la mentalité métier. Les data scientists ralentissent un peu le rythme, et les data engineers ralentissent de nouveau. L’IT retrouve ainsi en sortie un rythme plus absorbable. Nous amortissons et évitons les coups de stress sur la DSI. Nous atténuons les frustrations liées au fait d’avoir 1000 cas d’usage d’un côté, et l’IT qui ne peut en déployer que 2 de l’autre.

Mais la réussite d’une telle démarche repose aussi sur la personnalité des différents acteurs. Mon N+1 est absolument convaincu et sponsor de la démarche, et nous nous entendons également très bien avec l’IT. Les échanges sont très fluides avec le CIO et le CTO, c’est aussi une clef de succès.

Comment avez-vous monté vos équipes ? Le recrutement a-t-il été un enjeu ?

Sur le plan RH, nous avons entamé les recherches dès septembre 2021, avec l’objectif d’avoir pour chaque département un lead, un senior, un junior et un alternant. Nous avons recruté à la fois en interne et en externe. Les profils data ne sont pas forcément simples à recruter, en raison du marché, de la concurrence avec les startups… Qui plus est quand notre siège est à Rouen. Mais nous avons réussi à pourvoir tous les postes et l’équipe tourne aujourd’hui à pleine capacité.

Pouvez-vous nous expliquer de quelle façon vous choisissez les use cases que vous allez traiter ?

J’ai démarré ma carrière avec le big data et la grande époque des proof of concept (POCs), où l’on cherchait à vérifier la faisabilité des sujets. Mais aujourd’hui, avec les technologies actuelles, les POCs ne servent pas à grand-chose, car la réponse sera systématiquement : « oui, on peut le faire ». En réalité, la vraie question à se poser, c’est : « est-ce que ce sujet est rentable ? » Nous avons décidé d’arrêter les POCs et de ne prendre que les sujets apportant de la valeur.

Pour recueillir les besoins, nous avons des data analysts  au sein du département Data analytics, qui se reposent sur un réseau de relais data dans chaque direction utilisatrice. Ces relais métiers sont des sachants, ils connaissent leurs données, leur localisation, leur qualité. Ainsi, les besoins ne viennent plus du haut, mais des opérationnels.

Mes équipes interviennent ensuite pour cadrer les sujets de façon stricte. Nous posons trois questions aux métiers qui nous soumettent des cas d’usage, et s’il manque une réponse, nous ne prenons pas le sujet. Ces questions sont les suivantes : pourquoi traiter le sujet ? Quelle est la valeur apportée par ce cas d’usage (qui n’est pas obligatoirement un retour sur investissement) ? Quel est le risque à ne pas faire le projet ? En procédant ainsi, nous avons structuré le processus de sélection des cas d’usage, en partant d’un existant très abondant, où les besoins étaient peu structurés et comportaient des biais – par exemple, on pouvait trouver une demande de reporting hebdomadaire là où une étude annuelle suffit, les données n’étant nécessaires qu’une fois par an.

Pour hiérarchiser les demandes retenues, nous avons deux comités principaux. Le premier est un comité opérationnel, piloté par l’équipe data analytics. Il réunit les relais data de toutes les directions, qui apportent l’ensemble des use cases et fournissent ainsi la roadmap brute. Celle-ci est ensuite discutée et challengée. Nous établissons un scoring à froid sur chaque sujet, en faisant un ratio entre différents facteurs, comme la visibilité, la complexité, le processing de la data, etc. Cela débouche sur une première roadmap, qui comporte environ une trentaine de sujets par an. Nous évaluons aussi les sujets en fonction de notre capacité à faire, en faisant des estimations avec chaque département. Nous savons que nous ne pourrons traiter qu’une douzaine de sujets.

Un second comité, stratégique, discute alors la première roadmap avec tous les membres du Comex et l’IT. Il valide la roadmap et l’arbitre. Cette roadmap est ensuite validée et revue tous les trimestres, pour suivre l’état d’avancement des projets, examiner les nouveaux use cases et ceux en attente et voir si certains des nouveaux cas doivent passer avant les autres.

De cette façon, la roadmap qui remonte à l’arbitrage du Comex est une roadmap pragmatique et crédible. Une industrialisation, c’est long et compliqué, c’est un investissement, il faut bien choisir les uses cases. S’il n’y a personne entre les métiers et l’IT pour challenger ceux-ci, l’entreprise se lancera dans le reporting précédemment évoqué.

Enfin, nous avons un dernier comité avec l’IT, qui examine la roadmap arbitrée. Nous discutons avec eux de la montée en production, en fonction des ressources dont ils disposent.

Vous avez évoqué la valeur, que vous distinguez du ROI. Que mettez-vous derrière cette notion ?

Quand le sujet s’y prête, nous parlons de ROI, mais celui-ci n’est pas forcément la finalité dans un groupe mutualiste. Pour la Matmut, la valeur renvoie avant tout à la plus-value apportée, et celle-ci n’est pas que financière. Traduire des gains d’efficacité en euros n’est pas forcément le plus pertinent, il s’agit plutôt de voir ce que le projet peut apporter en termes d’optimisation, de confort… Nous choisissons des sujets qui seront avant tout utiles pour les sociétaires, ainsi que pour les collaborateurs.

Pouvez-vous nous donner quelques exemples de cas d’usages sur lesquels vous travaillez ?

Nous traitons de nombreux sujets différents. Certains avaient été initiés en mode exploratoire dans l’ancien data lab, nous les retravaillons et nous les industrialisons. D’autres sont de nouveaux sujets que nous prenons depuis le début. Nous avons également quelques sujets plus complexes, que nous examinons sur plusieurs années.

Nous travaillons pour toutes les directions du groupe Matmut, aussi bien les RH que la direction IARD, la santé, la bancassurance… Nous avons des sujets de scoring classiques, par exemple sur l’appétence ou l’attrition. Nous avons également des sujets sur les risques climatiques, notamment sur les fissures des bâtiments liées à la sécheresse et sur les inondations. Ces deux exemples sont intéressants, car la façon dont arrive le risque est très différente : dans un cas, le phénomène survient de façon brutale, dans l’autre il s’ancre dans la durée, avec des impacts plus difficiles à relier à une cause précise.

Nous avions aussi des sujets autour des constats amiables, pour étudier si des algorithmes peuvent lire ces documents. Nous savons traiter les zones de texte et les cases à cocher. En revanche, l’interprétation des schémas est plus complexe. Or, c’est avant tout sur les schémas que se prend la décision finale. Sur de tels sujets, il faut être pragmatique, l’automatisation par des algorithmes n’est pas forcément pertinente si nous ne gagnons pas en efficacité par rapport au traitement par un humain.

Enfin, nous explorons également quelques sujets autour de l’informatique quantique avec notre CTO, notamment sur la cybersécurité .

Un enjeu que rencontrent la plupart des organisations concerne la mise en place d’une culture data. Est-ce le cas pour vous et de quelle façon l’abordez-vous ?

Au sein du groupe, les niveaux de maturité sont assez divers. Certaines directions sont très matures sur la data et l’IA ; d’autres ne savent pas encore ce que l’on peut en faire, avec les deux extrêmes en termes de perception : l’IA perçue comme une solution magique ou, au contraire, comme une menace. Nous avons encore un gros travail d’évangélisation à mener, à la fois auprès des dirigeants et des opérationnels.

L’évangélisation est un volet que les CDO modernes placent assez haut dans leur liste de priorités. Il faut absolument expliquer aux décideurs et opérationnels ce qu’est la data, le machine learning, l’IA ; expliquer que le temps n’est pas le même entre un POC et son industrialisation, qu’un MVP (minimum viable product) monté en 3 mois demande 9 mois pour être industrialisé. Pour les métiers, un MVP ça marche. Il faut expliquer pourquoi faire une chaîne CI/CD, pourquoi prévoir des tests unitaires…

Pour y parvenir, j’aime bien m’appuyer sur des exemples simples. Lorsqu’un data scientist prend un échantillon de données pour faire son modèle, il ne se demande pas si celui-ci va fonctionner sur les années bissextiles ou non. Mais si le modèle passe en production, il ne faut pas que l’application tombe tous les quatre ans. En production, il faut aussi que les données arrivent tous les jours, de façon fiable et automatisée. Tout comme on ne va pas utiliser des seaux pour convoyer l’eau dans sa maison, mais des tuyaux installés par un plombier. Il faut donc prévoir la tuyauterie. Auprès de mes équipes, j’aime aussi parler de « budget café », afin que mes collaborateurs aillent à la machine à café expliquer leurs métiers aux autres, les différences entre un data scientist et un data engineer, la façon dont ils travaillent avec l’IT…

Enfin, il faut aussi veiller à l’acculturation des équipes techniques. Quand on veut industrialiser un modèle de machine learning, les compétences nécessaires ne sont pas forcément présentes dans des équipes habituées à travailler sur du legacy. Les trouver est compliqué, mais c’est possible. Et pour y parvenir, les CDO et CTO doivent faire du team building ensemble. J’ai la chance de très bien m’entendre avec mon CTO, mais si ces deux profils ne s’entendent pas, l’industrialisation sera un calvaire. Le volet technique ne représente qu’une petite partie de l’enjeu.

Sur quel écosystème technique vous appuyez-vous?

La Matmut possède un système d’information décisionnel (SID) historique, qui est directement alimenté par le système d’information global. Pour le data lab, un datalake à vocation exploratoire avait été créé à la suite du SID. Quand la direction data a été créé, nous avons changé de paradigme, en mettant en place une nouvelle plateforme datalake, possiblement cloud, directement alimentée par le SI global. Nous migrons progressivement les données, en fonction des use cases.

Nous avons déployé la plateforme DataRobot sur une infrastructure interne, afin d’avoir une solution unique sur toute notre chaîne de valeur. Le fait d’avoir la data science et le MLOps sur la même plateforme nous permet d’être beaucoup plus fluides et agiles. Cette année, nous réfléchissons à basculer cette plateforme dans le cloud.

Nous avons déjà fait plusieurs ateliers pour voir les données qui peuvent aller dans le cloud, en tenant compte des enjeux liés au Cloud Act, et nous avons aujourd’hui atteint une bonne maturité quant à la prise de décision sur ce sujet.

Aujourd’hui, on parle beaucoup des possibilités apportées par diverses technologies d’intelligence artificielle. Est-ce un domaine que vous et vos équipes investiguez ?

Nos data scientists font de la veille technologique, mais l’idée n’est pas d’essayer de trouver un cas d’usage chaque fois qu’un nouveau type d’algorithme apparaît. Nous sommes au service des métiers : nous partons de leurs problématiques, que nous essayons de résoudre. Si l’on part de la technologie, on risque de créer des solutions à des problèmes qui n’ont pas été identifiés.

Pour l’année en cours, hormis le sujet du cloud, avez-vous d’autres sujets sur votre feuille de route ?

Nous commençons à travailler sérieusement sur les enjeux liés à l’IA Act. Il faut réfléchir à qui sera chargé de tous ces sujets.

chevron_left
chevron_right