Recevez chaque jour toute l'actualité du numérique

x

[Podcast] Data Guru : Joel Farvault, Head of Augmented Claims at AXA Group Operations

Podcast Il y a des femmes et des hommes qui innovent ou transforment leur organisation grâce à la data. Ils font un métier jeune, parfois mal compris, à la croisée du business, de la statistique et de l’informatique. Sébastien Garcin, CEO de YZR, les appelle les "data gurus". Au travers d'un podcast dont nous vous offrons ici une retranscription, il les fait parler de leurs parcours, de leurs projets et de leurs retours d’expérience. Aujourd’hui, il reçoit Joel Farvault, Head of Augmented Claims at AXA Group Operations.
Twitter Facebook Linkedin Flipboard Email
×

[Podcast] Data Guru : Joel Farvault, Head of Augmented Claims at AXA Group Operations
[Podcast] Data Guru : Joel Farvault, Head of Augmented Claims at AXA Group Operations © adriana duduleanu, licensed via EyeEm Mobile

Sébastien : Bonjour Joel ! Un grand merci de participer à notre podcast, Data Guru. On se connait un peu et je connais un peu ton parcours. Depuis le temps que je rencontre des data gurus, je remarque qu’il y a 3 catégories : ceux qui viennent des maths et de l’économétrie, ceux qui viennent du business et ceux qui viennent de l’informatique. Toi, tu viens de l’informatique.

Joel : Bonjour ! Oui voilà exactement, je viens de la troisième catégorie. Après, il peut être intéressant de savoir laquelle des catégories est considérée comme meilleure que les autres.

Sébastien : Il n’y en a pas, ce sont des métiers assez récents et il n’y a pas d’écoles de data gurus ni de data officers donc c’est comme les chief digital officers d’il y a quelques années : il n’y a pas d’écoles, mais des gens qui ont eu des parcours très particuliers. Tu peux nous résumer ton parcours en quelques mots ?

Joel : Dans mon cas, j’ai commencé ma carrière avec du consulting dans le domaine de l’IT, pour ensuite évoluer en tant qu’architecte de systèmes d’information et enterprise architect. C’était intéressant, parce que j’ai été impliqué, courant des années 2000, dans l’urbanisation du système d’information, dans tous les sujets autours de l’organisation et la structuration du système d’information, la finition de plan stratégique, mais avec toujours le point d’orgue d’urbaniser le système d’information.

J’ai eu l’occasion de travailler au sein de banques françaises (Société Générale, BNP, Crédit Agricole) avant d’intégrer Axa en 2012. J’ai d’abord eu un rôle de responsable d’architecture, pour évoluer de fil en aiguille sur la data. Bien sûr, la data était aussi une chose importante dans mes rôles précédents et en tant qu’architecte, car c’est une dimension structurante au sein du système d’information, mais elle y était considérée comme un élément transversal.

C’est surtout à Axa que je me suis plus particulièrement spécialisé dans la data. Dans un premier temps en commençant par du cross sell, surtout sur une activité axée sur le digital et la distribution digitale. Puis, j’ai évolué sur un rôle de chief data officer qui comprend trois aspects : la data gouvernance, la partie architecture, et la partie data science. J’ai évolué au sein d’Axa en tant que CDO, puis CDO régional, avant de rejoindre le groupe pour me spécialiser dans la data product. Je suis actuellement responsable des data products dans le domaine des claims, qu’on appelle augmented claim.

Sébastien : Je te poserai plus de questions sur ton job d’aujourd’hui par la suite. Je voudrais qu’on creuse sur ton parcours et je me disais, pendant que tu parlais, que je devrais peut-être inventer une quatrième catégorie de data gurus : ceux qui viennent de l’architecture. Tu serais peut-être le premier de cette catégorie ! Dans les problématiques data auxquelles j’ai fait face dans mes dernières années, les architectes étaient mes premiers interlocuteurs, et souvent ceux avec qui la conversation a créé le plus de valeur.

Joel : Alors j’initierai cette catégorie ! C’est intéressant, et pour rebondir la dessus, l’architecture nous impose de prendre du recul et de penser les problématiques en multi-dimensionnel. C’est à dire qu’on a la data mais en quoi impacte-t-elle aussi les applications, la partie process ; comment ça s’inscrit sur l’infrastructure, sur la mise en œuvre, sur les référentiels ? Effectivement, la pensée architecture nous amène à penser en multi-dimensions, ce qui est souvent un élément important pour un CDO.

Sébastien : Oui, et puis on a également une vision globale de l’ensemble du système d’information. Comment passe-t-on de data architect à data scientist ? Tu t’y es mis toi-même ou tu manageais des équipes de data science ?

Joel : Je n’étais pas que data architect, j’étais aussi responsable d’architecture. Initialement, c’était sur un projet plutôt à vocation digitale. Il consistait à mettre en place une plateforme pour la distribution digitale de produits life and savings, en mode direct, et en multi-canal. On est arrivés à mettre en place, dans notre stratégie IT, un data warehouse. Il nous a permis de nous rendre compte qu’un certain nombre de données portant sur les interactions qu’on avait avec nos clients et partenaires étaient collectées.

Il n’y avait pas seulement des données structurées ; il y avait aussi un certain nombre de données non-structurées. On s’est donc dit, à l’époque, que ce serait intéressant de créer de l’insight à partir de toutes ces données. Cela nous a amenés à réfléchir aux prémices de ce que pourrait être un data lake.  On était au tout début de cette approche-là, avec hadoop et la plateforme Cloudera. La réflexion nous est venue de l’architecture : nous nous disions qu’il fallait collecter ces données et les stocker quelque part. C’est ce besoin qui nous a poussé à créer ce data lake.

Puis vint la question "qu’est ce qu’on en fait ?" Il était là, il y avait de l’investissement, j’étais ravi d’avoir eu cette opportunité. Or, dans le même temps, le groupe Axa lançait ses premières initiatives du data innovation lab, tandis que nous avions ce data lake que nous venions de créer. C’est le moment où l’on s’est demandé ce que l’on allait en faire, quels étaient les cas business qui nous permettaient de créer de la valeur sur les données qu’on stockait.

On en est arrivés à monter notre premier use case, en mettant en place un modèle de cross sell, même de targeting. Dans le business direct, c’est très important puisque tout va ensemble. Quand on est dans un business direct, il est important de cibler le bon client, celui sur lequel on a le plus de chance d’avoir un intérêt. On s’est donc dit qu’avec ces données, on pouvait capitaliser et entraîner un modèle pour pouvoir affiner notre targeting, cibler nos campagnes marketing ou mieux définir les clients qui avaient potentiellement le plus d'intérêt pour ce type de produit.

Le résultat étant très positif, j’ai été conforté sur le fait que c’est un sujet très intéressant à développer. L'expérience souligne l’importance d’allier l’architecture et la data science. En effet, les deux vont de paire, car il nous faut de l’architecture pour stocker des téraoctets de données, mais également une réflexion stratégique et business pour créer de la valeur sur ces données qu’on stocke.

Sébastien : Ça c’est sûr. Les compétences de data science tu les avais sous la main, tu les as trouvées dans l’organisation ?

Joel : Je les ai trouvées dans l’organisation. On avait recruté un data scientist externe, en mode consultant dans les équipes du lab d’Axa. En travaillant avec lui, j’ai pu mieux comprendre la méthodologie. Dans mes études, j’avais fait de la recherche opérationnelle donc je voyais bien le principe d’utiliser des algorithmes pour chercher à avoir une optimisation, soit une approche beaucoup plus ciblée.

J’avais des bases de statistiques, et c’est pour ça que j’ai aussi appris moi-même, en travaillant avec le data scientist. Autre point dans mon approche, qui a aussi été une approche de learning, c’est que j’ai un peu tendance à vouloir mettre les mains dans le cambouis, car c’est la meilleure façon de m’approprier le sujet et de mieux comprendre la thématique.

Sébastien : Je me pose une question au sujet de la data dans l’assurance : pourquoi est-ce que vous allez chercher des compétences à l’extérieur, pour de la statistique, alors que c’est votre cœur d’expertise ? C’est un peu un mystère.

Joel : Bon déjà, c’était en 2014-2015 donc depuis les choses ont bien changé, mais c’est un très bon point ! De mon point de vue, il est vrai que nous avons les experts en actuariat aujourd’hui, mais je pense qu’à l’époque, même les actuaires découvraient encore cette approche. Un certain nombre d’actuaires étaient déjà familiarisés aux régressions logistique ou de classification, mais ils l'utilisaient surtout en gestion de risques.

Dans notre cas, nous avons abordé la chose un peu différemment: nous avons utilisé les mêmes méthodes que les actuaires mais en les appliquant à d’autres domaines. En dehors du domaine de l’assurance, quand on parle de targeting à des spécialistes du marketing, cela va tout à fait leur parler. Si je ne me trompe pas, tu étais dans le secteur du luxe, donc je pense que toutes ces méthodes - le targeting, la segmentation - étaient des sujets dans lesquels tu as dû baigner.

Mais pour un assureur de l’époque, ce n’était pas forcément quelque chose d’acquis, du moins parmi la population des statisticiens. On a donc fait bouger les lignes en faisant prendre conscience que l’application de ces méthodes de statistique pouvait s’appliquer à d’autres domaines. D’ailleurs, selon moi, il devrait y avoir une fusion de plus en plus grande entre les actuaires et les data scientists, du moins dans le milieu de l’assurance.

Sébastien : Je te confirme pour un de mes clients canadien. J’ai réussi à mettre autour de la table l’équipe marketing digital, qui faisait du targeting toute la journée, avec des actuaires de la même entreprise, et ç’a fait des étincelles, dans le bon sens du terme. Ils se sont rendu compte qu’ils parlaient exactement la même langue.

Joel : Tout à fait. De notre côté, j’ai vu cette évolution ces dernières années, et c’est pour cela que lorsqu’on a initié le sujet, c’était encore un peu trop jeune. Il a fallu, au début, prendre des compétences externes. Il a fallu quelque temps pour que la population d’actuaires comprenne cette approche-là et l’intérêt qu’elle pouvait avoir. De plus en plus d’actuaires évoluent sur ce type de rôles. Et vice versa d’ailleurs ! Des data scientists qui n’ont pas de formation en actuariat, se forment à l’actuariat et au fur et à mesure évoluent sur des rôles d’actuaire.

Sébastien : Il y a même un autre mouvement : les gens du digital se sont longtemps fondés sur des outils analytiques tels que le data mining par lesquelles il est possible d’analyser de la data très large et produire de la statistique. Ç’a été mon propre parcours, je suis devenu chief data officer le jour où j’ai découvert la statistique. Ça change complètement la vision des choses. On croit qu’on peut s’en passer parce qu’on croit qu’on a des analytics qui sont propres, et assez vite on se rend compte que, puisqu’il n’y a pas eu de gouvernance de données sur toutes ces données, les données sont déstructurées, et que seules des approches statistiques permettent d’en tirer de la valeur.

Joel : Il y a un autre sujet qui m’a fait découvrir le job et en comprendre toute l’importance. Quand j’étais architecte, je le considérais comme annexe, je n’ai saisi l’importance des sujets comme la data gouvernance et de la protection des données. Devenir CDO m’a fait prendre conscience de toute la valeur de cette activité qui est souvent perçue comme secondaire, mais qui en fait est clef. Elle est essentielle pour la sensibilisation sur l’importance de la qualité de la donnée sans laquelle on ne peut rien extraire de la data. La partie de protection de la donnée est aussi primordiale, car elle permet de respecter notre client et les valeurs qu’on porte au sein d’Axa. Ce sont deux dimensions dont j’ai pris conscience.

Sébastien : Souvent on voit, dans les grosses organisations, que la partie protection n’est pas assumée par les mêmes personnes que la partie valorisation et gouvernance. Généralement ça crée un peu des luttes de pouvoir parce que les gens ont des opinions contradictoires. Comment l'as-tu géré dans ta carrière ?

Joel : Dans mon rôle de CDO, j’ai toujours eu le data protection officer qui ne m’était pas rattaché. Il était rattaché à la compliance, et donc je voyais bien la dichotomie des deux rôles. C’est très bien qu’on ne soit pas juge et partie. C’est très bien que le dépositaire légal, juridique, qui définit le guideline, le framework sur lequel on peut travailler, nous donne les préconisations sur ce qu’on peut faire et ne pas faire.

Et puis c’est le rôle du CDO de mettre en oeuvre ces guidelines, de les appliquer concrètement, d’être celui qui cherche à valoriser la donnée, tout ceci dans un cadre qui est respectueux à la fois sur un plan juridique, et à la fois sur les valeurs où l’approche qu’on veut mettre en avant sur le respect de nos clients. Je pense que c’est très bien qu’on soit sur des périmètres différents. A titre personnel, je n’ai jamais vécu ça comme un conflit, parce que justement, la façon dont je l’ai décrit à toujours été ma façon de fonctionner.

J’ai toujours vu le DPO plus comme un allié, celui qui définissait mon cadre de jeu. Si dans un projet, je me rends compte qu’on va un peu dépasser de ce cadre de jeu, je vais travailler avec lui pour voir ce qu’il est possible de faire, voir comment on peut respecter les lois, ou si je dois revoir mon approche. Je vois plus cela comme une collaboration constructive plutôt qu’une approche conflictuelle ou une lutte de pouvoir.

Sébastien : Est ce que ça t’a amené à renoncer à des projets parce que ça sortait du cadre ?

Joel : Pas renoncer, mais ç’a rendu la tâche ardue sur certains projets. Un sujet, par exemple, auquel je pense que beaucoup d’entreprises sont confrontées est que nous sommes de plus en plus confrontés à devoir travailler sur des environnements cloud publics fournis par différents providers. Quand on est amenés à gérer des volumes de données très importants, on ne peut plus s’appuyer sur nos infrastructures privées.

Un autre exemple qui me vient en tête, c’est que dans certains cas, on doit utiliser de la puissance de calcul quand on manipule des images GPU, sur lesquelles nos infrastructures privées n’ont pas ces puissances de calcul. Donc, on n'a pas d’autre choix que de passer sur des infrastructures publiques. Bien sûr, les providers fournissent toutes les solutions de sécurisation, mais sur un plan de protection des données, on commence à rentrer sur un sujet sensible qui appellent à la mise en place d'architectures un peu complexes. Je confirme d’ailleurs la quatrième catégorie.

En tant que CDO, quand on a un background d’architecte, on est beaucoup plus à même de mieux appréhender certains challenges. Quand le DPO nous dit que ce n’est pas possible, effectivement, je suis amené moi même à me dire qu’on va repenser un peu l’architecture et essayer de voir quelles sont les solutions qu’on peut mettre en place pour pouvoir mieux gérer cette contrainte réglementaire. Que ce soit des sujets d’anonymisation ou de pseudo anonymisation. C’est à dire qu’au moment où on passe les données sur le cloud, on anonymise, et puis quand elles sortent du cloud, on dé-anonymise. Toutes ces mécaniques apportent parfois une certaine complexité, et effectivement, c’est là que j’ai pu percevoir le challenge.

Sébastien : Je suis convaincu que cette anonymisation va devenir un métier à part entière. C’est un savoir faire très spécifique, et je suis sûr que c’est un champ d’innovation infini. C’est ça qui apporte de l’agilité, je pense que ma prochaine start-up sera dans l’anonymisation.

Joel : Tout à fait ! C’est une très bonne opportunité !

Sébastien : Parle moi un peu de ton métier d’aujourd’hui. Tu parles de claim, c’est certainement un peu obscur pour certaines personnes.

Joel : C’est vrai, j’emploie le terme anglais, je suis désolé. Ce que j’entend par claim est un sinistre, malheureusement. Ça peut être un accident de voiture, une fuite de machine à laver, tout élément qui peut arriver au quotidien. Cela marche aussi dans la santé : dans de nombreux pays il n’y a pas de système de santé public comme en France, ce sont des systèmes de santé privés. Dans ces pays, lorsqu’on va chez le docteur, on doit notifier son assurance et on appelle ça un claim aussi. Donc voilà, le mot claim regroupe toutes ces situations.

Sébastien : Ok. Et du coup qu’est-ce que tu fais ?

Joel : Mon rôle, dans ce périmètre, c’est de permettre de transformer cette expérience client sinistre, en utilisant toutes les solutions de type IA ou machine learning. Donc, utiliser toutes les solutions data science - dans son sens large - pour permettre cette transformation de l’expérience client dans ces situations. Ce que j’appelle transformation d’expérience client, ça peut être, pour certains cas de sinistres, une prise en charge en quasi temps réel.

Par exemple, on prend une photo du dégât des eaux, et automatiquement, tout est pris en charge presque dans la minute. On permet à notre client d’avoir soit un rendez-vous, soit une prise en charge financière ; on lui simplifie la vie au maximum. J’ai souvent tendance à dire que quand j’étais CDO, j’avais souvent des clients internes, qui étaient dans différents départements, avec lesquels on travaillait pour valoriser la donnée.

Là, dans mon rôle actuel, je me sens encore beaucoup plus proche du client final, car l’objectif est d’utiliser et même de développer et concevoir toutes ces solutions pour transformer cette expérience client et effectivement simplifier la vie du client. Ce qui implique effectivement de s’assurer que l’ensemble des informations données par le client sont vraies, pour pouvoir prendre des décisions très rapidement et l’aider dans sa situation, lui fournir le meilleur service possible.

Sébastien : D’accord. Sans révéler de secret industriel, cela veut dire que dans certains cas, si je suis assuré chez toi et que j’ai un sinistre chez moi, ce seront les différents échanges qui vont être analysés par une IA et qui vont faire une aide à la décision ?

Joel : Alors, évidemment on ne traque pas toutes les informations. Ce que j’entend par "différents échanges" c’est de permettre au client d’envoyer une photo qui nous permettra de rapidement évaluer et décider des modalités de la prise en charge ; plutôt que d’avoir à remplir un formulaire papier, appeler un service client et attendre plusieurs minutes. C’est ce que l’on essaye d’utiliser pour poser le moins de questions possible.

Honnêtement, j’ai eu la chance de ne pas avoir vécu d’accidents importants à titre client, juste des petits accidents sur des places de parking par exemple. Quand on appelle son assureur, on n’a pas envie d’être dans le stress et de répondre à plein de questions. Alors je me mets à la place de gens qui ont des accidents graves, et si on peut simplifier la démarche au maximum, et capter les informations sur le moment, en ne posant que très peu de questions et en demandant des photos, c’est notre objectif !

Sébastien : D’accord. C’est intéressant car c’est une application qui est vraiment au cœur du business, et puis derrière, j’imagine qu’il y a des enjeux de productivité pour les équipes clients ?

Joel : A propos de la productivité, je vais être très transparent. L’objectif dans ce que l’on appelle productivité, c’est de permettre à nos agents et nos équipes en relation client de passer plus de temps à accompagner nos clients pour des situations structurantes dans l’hypothèse où il y a des blessés d’accidents, ou des situations vraiment critiques.

C’est important que nos agents soient disponibles pour bien accompagner le client, et permettre, de ce fait, que tout soit géré le plus rapidement et simplement possible, surtout si on parle d’un dégât qui n’est pas très grave. Notre objectif c’est que tout puisse être automatisé et traité dans la journée. C’est là où l’IA apporte un gain de productivité et permet aux agents d’avoir toute la disponibilité nécessaire pour accompagner les situations critiques.

Sébastien : C’est vraiment intéressant, et au cœur de ce que vous faites.

Joel : Tout à fait, et j’ai tendance à dire que la situation de sinistre est le moment de vérité dans la relation entre le client et l’assureur. On paye tous des primes d’assurance, et lorsqu’on est confrontés au sinistre, c’est à ce moment qu’on a vraiment besoin de de notre assureur, de sa présence, de son écoute et de sa prise en charge. En fait, on a soit besoin de l’écoute, soit que les moyens mis en place pour nous facilitent la vie rapidement.

Personne ne souhaite passer deux heures au téléphone pour une situation simple, pouvant être réglée très rapidement. Si on peut s’appuyer sur l’IA pour se faciliter la vie, concourir à la satisfaction du client et améliorer la qualité de service, on le fait. De cette manière, si l’un de nos clients vit une situation particulièrement compliquée, nous sommes là pour l’aider et le soutenir dans les démarches nécessaires.

Sébastien : Super ! On arrive à la fin de cette interview. En conclusion, je dirais que je vais définitivement créer une quatrième catégorie de CDO : ceux qui viennent de l’architecture. Tu vas clairement l’inaugurer ! Merci pour cet échange, on a appris beaucoup de choses. A très bientôt.

Joel : Avec grand plaisir ! C’était très intéressant, à bientôt !

Réagir

* Les commentaires postés sur L’Usine Digitale font l’objet d’une modération par l’équipe éditoriale.