Les assurances paramétriques au cœur des smart contracts : une révolution pour l'assurance

Imaginer un monde dans lequel après vous être tordu la cheville et après avoir été pris en charge par les services d'urgence, votre couverture d'assurance se déclenche, sans votre intervention, une fois le diagnostic établi et organise votre période de rétablissement : les rendez-vous pour les visites de contrôle, les rendez-vous pour les séances de kiné ou les éventuels trajets entre votre domicile et votre travail ou un support pour vos enfants, etc., telle est la promesse des assurances paramétriques et du smart contract.

Concrètement, il s'agit d'un contrat dans lequel le déclenchement de l'assurance et la mise en place des couvertures ou le paiement des indemnisations se font de manière transparente, automatique et automatisée au moment où l'événement assuré survient et non à la suite de votre déclaration de sinistre et de son traitement par l'assureur.

Un smart contract est un programme autonome qui exécute automatiquement des actions validées au préalable par les parties prenantes. Un contrat d'assurance est un lien juridique entre une compagnie d'assurance et son client par lequel la compagnie d'assurance promet, ex ante, de réaliser une prestation, pécuniaire ou non, en cas de réalisation d'un risque sous réserve de satisfaire aux droits et aux obligations décrits dans le contrat d'assurance.

Ces deux définitions ont en commun les événements déclencheurs définis ex ante et les actions réalisées en cas d'activation du contrat et une différence significative, l'automaticité de l'exécution du contrat. C'est ce que tente d'exploiter le monde de l'InsurTech.

La substitution des contrats traditionnels par des smart contracts fait face à trois types de challenges : construire l'événement couvert et vérifier l'appétence de l'assuré à cette nouvelle construction dans un cadre automatisé, trouver et gérer la donnée sous-jacente au smart contract, et organiser une profonde mutation dans le pilotage de son activité et son organisation.

L'EXEMPLE DE L'ASSURANCE VOYAGE AÉRIEN

Vous pouvez vous assurer contre le retard significatif ou d'annulation de votre vol et en cas de survenance d'un tel événement, recevoir une indemnisation pécuniaire.

Ces contrats sont souscrits lors de l'organisation du voyage ou inclus dans des certains services de paiement, mais le taux de réclamation des indemnisations reste faible. Est née alors l'idée de mettre en place un smart contract pour pallier à cette problématique de non-réclamation de la couverture.

Le produit proposé est une assurance qui vous indemnise automatiquement en cas de retard supérieur à deux heures ou en cas d'annulation. Le caractère automatique est lié au fait que votre assurance s'enclenche sans votre intervention une fois l'information sur le retard ou l'annulation connue.

Ces principales caractéristiques sont les suivantes : des événements générateurs et une indemnisation facilement modélisable, une donnée de qualité facile d'accès en temps réel et inaltérable, une automatisation complète de bout en bout grâce aux API1 et demain la blockchain2.

Les différences avec un contrat traditionnel sont nombreuses : pas de déclaration de sinistre, une automatisation éliminant toute intervention humaine, la donnée fait référence et se substitue au jugement d'expert potentiellement discrétionnaire.

L'assuré se trouve de fait impliqué dans l'exécution de son contrat d'assurance. Dans ce nouveau monde de l'assurance, la donnée et l'automatisation sont centrales. Les conséquences pour les compagnies d'assurance sont potentiellement énormes, tant du point de vue des offres que de l'organisation. En réinventant des offres existantes, mais aussi en créant des nouvelles offres, il faudra également trouver son marché, produit par produit, en convaincant les clients assurés de leur propre intérêt.

Du smart contract
à l'assurance paramétrique

Une relation de confiance à établir avec l'assuré

Il faut construire l'événement et ses conséquences de manière à ce qu'en cas de réalisation, la mise en jeu des couvertures n'appelle aucune analyse supplémentaire des causes et des conséquences de l'événement et donc aucune contestation de la part des parties prenantes (assuré, assureur et réassureurs notamment).

Cette absence d'analyse et de contestation est clé car elle est la base de la disparition de l'ensemble des opérations de gestion de sinistres (en particulier, analyse du dossier, expertise et contre-expertise le cas échéant, négociation ou contentieux, etc.).

Cela ne s'applique donc pas à tous les produits car il repose sur un principe d'automaticité entre l'événement et la prestation servie.

L'exemple du voyage aérien s'appuie sur la réalisation de deux événements binaires exclusifs. Mais des événements de nature plus complexes peuvent être intégrés dans le smart contract et notamment la réalisation d'un événement dont les conséquences de la mise en jeu de l'événement vont dépendre de la gravité de l'événement garanti.

C'est, par exemple, le cas d'une assurance agricole qui s'appuierait sur le niveau de pluviosité ou encore d'une assurance catastrophe naturelle dont la couverture serait fonction des conséquences de cette catastrophe.

Ces assurances dites paramétriques ou indicielles peuvent être intégrées dans un smart contract3 si les conditions citées ci-dessus sont atteintes.

Contrat par contrat, il faut cadrer les événements garantis et définir les conditions d'éligibilité. Il faut enfin définir le service rendu en cas de mise en jeu qui doit être défini à la signature du contrat. Ce débat va être autant de nature technologique que touché la culture4 de l'assureur.

D'un point de vue technologique, il faut piloter la complexité des conditions de mises en jeu de l'événement garanti et définir les sources de référence des données pour mettre en œuvre ces clauses.

D'un point de vue culturel, l'assureur va informer ses clients qu'ils abandonnent leur libre arbitre en cas de sinistre au profit d'une automatisation contractuelle prédéfinie. Il convient aussi d'expliquer que l'assuré s'en trouve mieux couvert et qu'il ne perd rien en termes de garantie. Cela peut passer par la mise en place d'une grille de services explicites, acceptables pour l'assuré et correctement calibrés sur le plan actuariel.

La question du coût de gestion est centrale, avec un potentiel d'économie important, mais aussi de réduction du recours des partenaires externes. L'appréciation du risque connaît une évolution fondamentale car l'assureur ne peut plus « piloter » ni les assurés dans leur déclaration de sinistre, ni les experts par des consignes. Concrètement, il y a une forte probabilité d'une hausse du nombre d'événements garantis sur sa situation, avec des conséquences pour l'assureur, mais aussi le réassureur ou les marchés financiers à qui seraient transférés des risques.

Dans ce contexte, l'augmentation du nombre de sinistres ne s'oppose pas à la rentabilité, grâce à une tarification beaucoup sophistiquée, aux économies sur les coûts et des ventes de polices d'assurance intégrées à des packages, donc beaucoup moins coûteuses sur le plan de la distribution. Ce dernier point est à modérer dans le cas des grandes plateformes telles que Uber ou Expedia/Booking, qui sont en situation d'oligopoles et donc en position de dicter leur marge de distribution.

Le cas d'usage client reste donc essentiel : il doit être simple d'accès, mais compétitif car le client doit avoir le sentiment d'être gagnant. Cela est possible car l'assuré peut selon les cas se retrouver en position de comparer les contrats et d'utiliser la souplesse contractuelle offerte. En effet, les assurances paramétriques permettent d'aller beaucoup plus loin que les contrats conventionnels qui ne proposent que des plafonds de garantie.

C'est évidemment un sujet qui doit être contrôlé par les associations de consommateurs, mais aussi et surtout par les régulateurs, pour établir que cela est positif pour le client, même si certains se retrouvent moins bien compensés. C'est d'ailleurs ce point-là qui a limité la volonté des assureurs à accélérer, face aux débats potentiellement complexes avec le régulateur.

Le smart contract : un contrat à prestation définie

On peut représenter cet enjeu d'une manière schématique en indiquant le montant des prestations servies par le nombre de prestations servies, ce qui nous donne peu ou prou la situation de départ explicitée dans le schéma 1 (infra).

Source : SIA Partners.

Sont à la charge de l'assuré les montants sous la franchise et la partie excédent le plafond des prestations servies.

En termes de pilotage de son activité, avec les contrats actuels, l'assureur peut modifier la forme de la courbe en jouant sur deux paramètres, les événements garantis et les montants servis, et atteindre de ce fait le montant moyen cible correspondant à l'objectif de profitabilité ou à tout le moins être en dessous du montant maximal pour lequel la prime est égale au montant des prestations servies et des coûts (sauf à considérer que ce produit est un produit d'appel).

Dans le cas où le smart contract conduirait à indemniser tous les assurés de manière identique (cas très théorique, mais illustratif), l'assureur doit définir quel montant va remplacer cette courbe des sinistres. En gros, la courbe va être remplacée par une droite verticale. La question est donc où la placer sur le schéma 2. Il faut bien prendre conscience qu'une fois la droite placée, il n'est pas possible de la modifier et donc l'assureur perd des degrés de liberté dans la gestion de son activité.

Source : SIA Partners.

Le schéma 2 (infra) illustre plusieurs phénomènes :

• l'introduction d'un smart contract et l'automatisation associée devraient conduire à un déplacement vers la droite du point d'équilibre du contrat5 par la réduction des coûts de gestion des contrats et des prestations versées ;

• le remplacement de la courbe par un point va conduire à ce que certains assurés voient augmenter leur prestation servie et d'autres vont voir une réduction ; la question ici va donc être de gérer le mécontentement de cette dernière classe d'assurés.

Par ailleurs, un grand nombre de déclarations rejetées lors de l'analyse initiale pourrait être en grande partie réintégré. Cela aura pour conséquence que le montant des prestations servies pourrait baisser en moyenne pour l'ensemble des assurés si le nombre de dossiers rejetés est significatif.

Enfin, un autre phénomène lié à l'automatisation devra être pris en compte. Certains sinistres sont le résultat d'une négociation. De fait, pour un même événement, deux assurés ayant la même couverture peuvent se voir servir deux prestations différentes. Avec un smart contract, ce ne sera plus le cas et cela va conduire à revoir la courbe avant de commencer l'analyse conduisant à définir le montant de la prestation servie via ce canal.

Les principales étapes pour définir un smart contract

L'assureur va dérouler une démarche en quatre étapes :

• définir le portefeuille d'événements garantis. Pour ce faire, il devra repartir de son portefeuille d'événements survenus et déclarés, réanalyser les motifs de rejets de certains événements et décider d'en réintégrer tout ou partie6 ;

• découper son portefeuille d'événements garantis selon différents axes afin de définir des classes de risques homogènes présentant des prestations servies similaires7 ;

• remplacer chaque classe de risques homogènes par un montant8 ;

• tester la robustesse de la nouvelle proposition tant d'un point de vue de la solidité financière de l'entreprise que de la capacité à vendre son produit.

Cette approche mêle des analyses à réaliser une fois lors du passage au smart contract et des analyses récurrentes. Ces analyses ne sont pas présentes de difficultés particulières d'un point de vue mathématique pure, mais le nombre d'analyses à réaliser et le nombre de simulations à produire pour s'assurer de la robustesse du produit nécessiteront de développer de nouveaux modèles et probablement de travailler dans des environnements nécessitant l'usage de l'intelligence artificielle.

LA DONNÉE AU CENTRE DU JEU

Dans le cas de l'assurance voyage aérien, l'assurance vendue repose sur la condition suivante : un avion est en retard ou annulé. Il s'agit d'une donnée facile à collecter et à certifier.

De façon plus générale, l'assureur va donc avoir pour objectif de trouver, puis de sélectionner cette source de donnée notamment sur les critères suivants : la qualité de l'information produite au regard de la collecte de récupération de l'information et le coût associé.

Cette donnée constitue la base du déclenchement de l'indemnisation, la compétitivité du produit et la profitabilité du contrat.

Les assureurs vont donc procéder à une campagne fondée sur quatre grandes opérations :

• des vérifications de l'information produite sur la base d'échantillons soit manuellement, soit en comparant n fournisseurs de données et en les classant ;

• une analyse des procédures de production de cette information ainsi que des contrôles autour de cette chaîne de production ;

• une analyse des procédures de gestion d'incidents sur cette chaîne de production ;

• la mise en place d'un service level agreement qui va gérer le processus de qualité de données et la réponse aux cas exceptionnels.

À la suite de cette phase, le fournisseur de données pourra être qualifié de source de référence faisant autorité sur la donnée recherchée.

La remise en cause des assureurs dans la maîtrise de la donnée

Dans un monde où les platesformes internet ou les constructeurs automobiles de nouvelle génération prennent le pouvoir grâce aux données. Pour ces acteurs, développer ou plutôt faire développer des assurances paramétriques constituent une opportunité importante de monétisation en étant au cœur de la relation client.

Historiquement, l'assureur est un formidable accumulateur de données de nature et d'origine différentes :

• des données internes produites : données de gestion issues sur les polices, des processus de gestion des sinistres ou des paiements, etc. ;

• des données externes achetées ou échangées : données sur les assurés (qu'elles portent sur leur identité, leur projet, leur santé financière ou médicale, etc.), données sur les biens couverts ou en relation avec les événements couverts ou encore données sur les événements conduisant à une mise en jeu de la garantie.

Ces données sont récoltées selon différents processus construits au fil du temps.

Elles irriguent toute la chaîne de valeur de l'assureur en particulier (sans ordre particulier, ni volonté de complétude) : design produit, tarification, vente, gestion des sinistres et provisionnement, gestion de l'appétence aux risques, partage des risques, finance ou encore investissement.

Enfin, elles peuvent éventuellement être transférées à d'autres parties prenantes telles que les régulateurs (registres réglementaires ou états sur le capital réglementaire) ou les réassureurs de l'assureur ou les prestataires auxquels l'assureur fait appel dans le cadre de l'exécution de ses obligations (par exemple, expert ou réassureur automobile).

Pour traiter cette donnée, l'assureur a construit différents systèmes informatiques pour la récolter, la stocker ou l'utiliser.

Dans le monde des smart contracts, tout peut être remis en cause, avec une obligation potentielle pour l'assureur de repartir de zéro, ou presque.

En effet, les données sous-jacentes au smart contract ne sont en général pas présentes dans son système informatique, parfois pour des raisons internes, parfois parce que c'est le partenaire qui gère la relation client qui la possède.

Pour faire face à ces nouveaux acteurs, les compagnies doivent être exemplaires dans leur propre écosystème interne. En effet, il existe énormément de données existantes, mais non structurées et non exploitées. Pour profiter de ces nouvelles opportunités, l'assureur doit se remettre en cause et se transformer, dans son système interne et dans sa gestion de la donnée.

Repenser sa relation à la donnée

De nouveaux rôles et approches en termes de collecte de la donnée vont apparaître. Les fonctions de contrôle de la donnée vont être étendues. Enfin, le système informatique supportant la donnée devra être amendé en profondeur.

Tout d'abord, l'assureur va devoir renforcer ses capacités à découvrir les données disponibles. Ces données peuvent être disponibles en interne ou en externe. Elles peuvent nécessiter une opération pour être traitées dans le système informatique. Ou encore elles peuvent nécessiter des analyses complémentaires pour être transformées en données utiles.

Pratiquement, l'assureur va devoir se lancer à la chasse aux données. Et de ses capacités de chasseur va dépendre sa capacité à créer des smart contracts. Il va devoir « parcourir différents terrains de chasse » et avoir en tête l'objectif de lui permettre le stockage d'un maximum d'informations. Parmi ces terrains de chasse, on peut noter :

• chasse à la donnée interne, à transformer ou non ;

• chasse à la donnée externe qu'elle soit packagée ou qu'elle nécessite une analyse interne avant d'être utilisée.

Il est illusoire de croire que l'assureur a stocké et/ou structuré toute l'information qui passe entre ses mains, que ces données soient au format papier, de la voix, des images. À titre d'exemple, un assureur significatif admettait récemment n'avoir une adresse mail que pour 85 % de ces clients et surtout ne pas avoir de certitude que toutes ces adresses mails étaient valables.

Par chasse à la donnée interne, on entend une revue systématique des données présentes dans les dossiers des assureurs et non encore structurée dans une base de données, phase qui sera suivie par un exercice de stockage de ces données. Le cas le plus simple va se traduire par une modification des outils de saisie qui vont intégrer de nouveaux champs. Dans des cas plus complexes, on peut imaginer devoir recourir à des techniques de traitement d'images ou d'enregistrements vocaux.

Par chasse à la donnée externe, on entend une analyse systématique de la donnée produite par de nombreux acteurs de l'écosystème entourant l'assureur. Cela nécessitera de répondre à de nombreuses questions, parmi lesquelles :

• quelles entreprises sont dans mon écosystème9 ?

• quelles sont les données disponibles ?

• à quelle échéance cette donnée sera-t-elle utile ?

• doit-elle être transformée ?

• quelle profondeur d'historique sera-t-il nécessaire d'avoir ?

• comment peut-on récupérer cette donnée ? et à quel coût ?

• peut-on considérer le propriétaire de la donnée comme un oracle ?

Une fois cette étape de stockage réalisée, il est probable que l'assureur procède à différents projets de structuration de ces données. Des projets car différentes équipes pourront avoir envie de traiter la même information brute de manière différente pour recueillir des informations différentes. On peut imaginer, par exemple, qu'à partir de la même image satellite, une équipe cherchera des informations sur les risques d'inondation en cas de forte pluviométrie, une autre sur la couverture des risques agricoles et une troisième couverture de catastrophes naturelles (séisme, tempête, etc.). Toutes feront appel à des technologies de traitement d'images identiques, mais en auront d'autres applications. Et ces trois types d'informations seront stockés dans la base de données.

Le contrôle des données portera autant sur les processus internes que sur les programmes de qualification des oracles partenaires et de qualification des programmes de récupération et d'enregistrement des données dans les bases de données. Il s'inspirera de ce qui a été mis en place pour les contrôles de la validité des comptes ou des chiffres entrant dans les calculs de besoin en capital réglementaire. Mais faisant appel à de nouvelles technologies, il faudra créer de nouveaux contrôles et renforcer les équipes de contrôle interne ou d'audit interne de nouvelles compétences informatiques.

Revoir sa stratégie de collecte et de stockage de la donnée

Avec les changements induits par les opérations de chasse de la donnée, l'assureur va devoir faire évoluer son système pour enregistrer toutes données qui pourraient être de nature pertinente non pas maintenant, ni demain, mais dans trois, cinq ou dix ans.

Différentes solutions existent pour permettre le stockage de plusieurs pétaoctets10. Ces solutions représentent cependant des sauts technologiques importants qui vont profondément modifier les assureurs tant sur les aspects alimentations de ces bases, maîtrises de ces bases que d'utilisation de la donnée stockée.

Au-delà de ces évolutions technologiques, cette chasse à la donnée va nécessiter que l'assureur définisse quel est le meilleur coût pour lui pour lui permettre de récupérer et stocker ce volume massif de données.

Le meilleur coût n'est pas forcément le coût le plus bas d'un point de vue monétaire. Il peut en effet être pertinent d'acheter une information (si elle est disponible) plutôt que de la demander à l'assuré et de risquer de le perdre en lui donnant l'impression de donner trop d'informations ou de lui donner une image trop administrative de l'assureur. Une première version de ce débat sur le meilleur coût de récupérer l'information a déjà eu lieu entre marketing et actuaire lors de l'émergence des quotations de couverture d'assurance en ligne ; le marketing visant un processus léger et les actuaires une complétude d'information pour avoir le meilleur prix. Et différents modèles de quotations en ligne ont émergé. Nous allons assister à un nouveau round de discussions sur ce thème de la donnée et du meilleur coût de sa récupération.

Et le meilleur coût va aussi devoir intégrer de nouveaux éléments dans la discussion tels que le coût environnemental de la donnée, le coût de la protection de cette donnée tant d'un point de vue informatique que d'un point de vue réglementaire.

OPÉRER UNE PROFONDE TRANSFORMATION

L'automaticité du smart contract va réduire les possibilités
de piloter le résultat technique de la compagnie d'assurance

Du fait de l'automaticité de l'exécution du contrat en cas de survenance de l'événement assuré, la compagnie d'assurance perd différents degrés de liberté dans le pilotage de son activité.

Tout d'abord, elle perd un degré de liberté à la déclaration du sinistre. En effet, elle n'a plus la main sur l'acceptation ou non des sinistres. Aujourd'hui, la compagnie peut être plus ou moins tolérante sur l'acceptation de ses sinistres lors de leur déclaration. Et elle ne peut plus compter non plus sur la non-déclaration des sinistres par l'assuré.

Ensuite, elle perd un degré de liberté en bout de processus de gestion des sinistres en perdant la gestion du coût des prestations servies qui sont définies automatiquement par le contrat. En comparaison avec les systèmes de retraite, le smart contract est un contrat à prestation définie, alors que le contrat traditionnel est un contrat à cotisation définie.

Enfin s'ajoute la perte d'un troisième degré de liberté car l'automatisation et la simultanéité de l'événement et la déclaration réduisent à peau de chagrin la nécessité d'avoir une réserve dite « IBNR » qui est là pour couvrir les sinistres ayant eu lieu, mais non encore enregistrés dans le système de gestion de l'assureur parce qu'ils n'ont pas encore été déclarés ou traités par l'assureur. Or ces réserves peuvent constituer un moyen de piloter son résultat en étant plus ou moins prudent sur sa prévision de sinistres « ayant eu lieu, mais non encore enregistrés ».

Les conséquences opérationnelles de l'automaticité vont concerner
l'ensemble de la chaîne de valeur de la compagnie d'assurance
et vont être aussi bien de nature organisationnelle que culturelle

La section sur la définition de l'événement garanti identifiait un certain nombre de changements organisationnels, opérationnels ou culturels sur les équipes commerciales et de tarification.

Par effet de domino, ces changements vont impacter les autres équipes actuarielles au sein de la compagnie (provisionnement, fonction actuarielle). Mais pas seulement. Les équipes de gestion de sinistres, les équipes de réassurance ainsi que les fonctions de contrôle sont également touchées.

L'équipe la plus impactée par le passage à un smart contract est celle dont la fonction est de gérer les sinistres. Elles ne devraient pas disparaître, mais elles perdent une partie significative de leur attribution et se retrouvent à ne devoir gérer que les cas particuliers et/ou les bugs de programme, ce qui va nécessiter une connaissance potentiellement significative du code ou de la logique sous-jacente aux smart contracts.

Par ailleurs, la fonction réassurance pourrait elle-même connaître une nécessité de se réformer car nous pourrions imaginer que la réassurance de smart contract pourrait être elle-même faite à base de smart contract afin de tirer parti de l'automaticité de la chaîne avale.

En raisonnant aux limites, il serait d'ailleurs possible d'imaginer que les smart contracts conduisent à terme à modifier les équilibres de partage des risques entre assureurs (co-assurance) et assureurs et réassureurs (réassurance).

Le smart contract en assurance a un double objet : un contrat d'assurance et un vecteur technologique.

Les réassureurs couvrent aujourd'hui le premier risque et non le second. Sera-t-il toujours possible avec le smart contract de continuer à démutualiser ces deux composantes du risque alors que contrat et technologie ne font qu'un ?

Ensuite, parmi les équipes impactées par cette automaticité, il faut intégrer les équipes de contrôle de premier niveau, second niveau/contrôle interne ou troisième niveau/audit.

L'automaticité va nécessiter de repenser la logique de contrôle qui ne peut plus être sur pièce, mais sur écran. Et surtout ce contrôle peut être en parti automatisé, nécessitant de doter ces équipes de contrôle de compétences informatiques nouvelles.

Enfin, il y a un point commun à l'ensemble de ces changements opérationnels : la nécessité de doter ces équipes de compétences informatiques avancées tant pour ne pas dépendre d'une équipe informatique potentiellement rapidement saturée et surtout pour certaines pour satisfaire à des exigences d'indépendance.

En contrepoint, cela signifie aussi qu'il faudra probablement repenser le rôle de la fonction informatique. Cette évolution s'accompagnera d'un changement culturel important : la fonction informatique et le monde opérationnel vont devoir travailler ensemble et non cohabiter au travers de cycles en V et de méthodes agiles. Ce changement culturel aura un préalable important au sein des équipes informatiques : mettre en place une politique de qualité de développement des smart contracts qui soit de très bon niveau et extrêmement bien respectée afin que plusieurs équipes puissent travailler simultanément.

L'identité exécution du contrat et machine informatique
va nécessiter de repenser intégralement la gestion de la continuité
de l'activité en cas d'incident informatique sévère

Chaque assureur est tenu d'avoir un plan de continuité d'activité pour faire face à un événement interne ou externe tel qu'un incendie, une inondation, une panne informatique ou encore une cyber-attaque. L'objectif de ce plan est double : gérer les activités de l'assureur en mode dégradé en se concentrant sur les activités critiques et travailler à un retour à la normale le plus rapidement possible.

En cas d'une panne informatique ou d'une cyber-attaque, certaines sociétés ont continué à gérer leur activité de manière manuelle avec du papier, quitte à mobiliser auprès des équipes métiers d'autres équipes.

Une telle solution a été possible car la machine informatique n'est qu'un support à la gestion du contrat qui peut être géré manuellement, certes de manière dégradée et car il y a des équipes métiers.

Dans le cas d'un smart contract dans lequel le contrat et la machine ne font qu'un et dont on peut imaginer que son implémentation a conduit à réduire la dimension des équipes, l'approche précédente n'est pas réaliste.

Dans le pire des cas, la compagnie d'assurance pourrait être dans une complète incapacité de servir les prestations à ses assurés (quand un assureur avec un contrat classique pourrait fonction en mode (très) dégradé) avec toutes les conséquences réputationnelles ou réglementaires qui vont en découler.

Le niveau d'automaticité du smart contract va conduire à devoir repenser intégralement le plan de continuité pour répondre à cette nouvelle situation d'identité contrat/machine.

Enfin l'assureur va devoir gérer de nouvelles situations

La multicouverture de certains événements11

La difficulté réside dans le choix du contrat à faire jouer en cas de présence d'un événement multigaranti qui est aujourd'hui à la main de l'assuré. Des solutions d'arbitrage automatisé lors de la réalisation de l'événement pourraient être mises en œuvre, la technologie existe pour le faire. Mais il faudrait se mettre d'accord ex ante sur les règles d'arbitrage. Et cela pourrait être ex post une source de conflits légaux supplémentaires à gérer par l'assureur.

Et la situation devient d'autant plus complexe lorsque les contrats ont été signés chez des assureurs différents.

Le risque de fraude ne disparaît pas, voire se déplace

Étant donné qu'il existe des assurances contre les malversations des employés, on peut très bien imaginer qu'un assureur soit victime de la fraude initiée par un employé de l'oracle. Et on peut imaginer bien d'autres formes de fraude.

Les défis liés à l'introduction de l'oracle, en tant que nouvel acteur
de la chaîne de valeur assurance

Tout d'abord, l'oracle est un partenaire dans la prestation service. Or l'oracle peut faire défaut ou arrêter de produire la donnée pour des raisons techniques ou économiques. Ou la qualité de la donnée produite par l'oracle peut varier dans le temps. Ou encore, l'oracle peut faire l'objet d'une cyber-attaque avec comme objectif l'assureur. L'assureur va de fait devoir gérer cette nouvelle situation et anticiper ces nouveaux cas. Certes il a l'habitude de travailler avec des partenaires externes et donc d'anticiper des situations difficiles. La nouveauté dans certains cas réside dans le fait que le nombre d'oracles peut être extrêmement restreint.

Enfin, l'introduction d'un oracle dans le schéma assurantiel nécessite potentiellement que celui-ci soit agréé par le réassureur qui accepte en partie les risques portés par l'assureur. En effet, le réassureur, en signant le contrat de réassurance, donne à l'assureur une délégation12 pour la prise du risque en son nom. Pour valider cette délégation, le réassureur réalise un certain nombre de due diligence dont la revue des produits et des règles d'arbitrage et de décision du risque. Ces due diligences, lors de la revue du smart contract, intégreront la revue de la qualité de l'oracle.

En conclusion, pourquoi les assureurs
doivent-ils introduire des smart contracts
dans leur portefeuille ?

Tout d'abord parce que les champs d'application des smarts contracts
en assurance sont nombreux, que ce soit dans le domaine de l'assurance
du particulier que dans celui de l'assurance de l'entreprise

Quelques exemples pour s'en convaincre :

• toute couverture d'assurance complémentaire/supplémentaire. L'oracle est l'assureur lui-même. Cela pourrait être le cas pour les rachats de franchise, des extensions de garantie, etc.

• tous les produits de co-assurance ou réassurance. L'initiative B3I montre clairement la voie au travers de la mise en place d'une blockchain entre assureurs et réassureurs et le développement de solution de partage de risque ;

• les garanties d'ordre financières. Axa a mis en place en Suède une expérimentation de transfert d'information par blockchain avec le service public de l'emploi. L'une des conditions (présence d'un oracle) est atteinte. On peut aussi l'imaginer avec les banques et autres organismes financiers ;

• quand l'expertise déterminant la portée de l'événement est « automatisable ». Un grand groupe mutualiste travaille actuellement sur l'identification des épaves non réparables à partir de clichés pris après un accident de voiture. Il faudra probablement d'autres informations pour éviter la fraude. Mais on peut imaginer que cette technologie apporte l'une des briques importantes à la définition d'un smart contract dans l'assurance automobile.

Enfin, on peut aussi imaginer que l'introduction de smart contract ne couvre qu'une partie des prestations servies par le contrat :

• la reconnaissance automatique des épaves pourrait, par exemple, être intégrée dans le contrat d'assurance automobile dont une partie (le dommage au bien en cas d'épaves reconnues) serait un smart contract et le reste serait un contrat nécessitant une intervention humaine ;

• de même, si la prestation servie intègre une avance en trésorerie ou des prestations initiales. Ce peut être le cas en cas de catastrophe naturelle ou d'assistance aux personnes en voyage. Il y aurait certainement un transfert vers un autre métier qui serait le recouvrement des sommes trop perçues. Mais globalement, cela ne pourrait qu'améliorer la qualité de la prestation et l'image de partenaire en cas de sinistre de l'assureur.

Pour l'opportunité offerte par le smart contract d'atteindre deux objectifs
significatifs : améliorer l'expérience client en termes de contrat d'assurance
tout en contrôlant son appétit au risque, et réduire les coûts de gestion
d'un contrat d'assurance

Les avantages d'un smart contract sont évidents :

• transparence dans les prestations servies définies ex ante et du niveau de primes associé à cette prestation ;

• prestation servie plus rapidement à l'assuré en cas d'événement garanti ;

• réduction des coûts de gestion ;

• sécurisation des opérations d'assurance ;

• gain d'image pour l'assureur.

Parce que les challenges auxquels est confronté l'assureur
ne sont pas si complexes que cela

Ensuite, même si la mise en place d'un smart contract nécessitera de relever différents challenges de la part de l'assureur, challenges qui impactent profondément son organisation et sa culture, ces challenges ne sont pas particulièrement compliqués d'un point de vue technique. Ils nécessitent surtout un peu de temps et de courage.

Tout d'abord de manière défensive parce que d'autres assureurs, ou non,
s'y intéressent

Certes il y a d'autres expérimentations dans l'assurance comme, par exemple, le paiement à l'utilisation13, l'assurance collaborative14.

Mais elles vont moins loin que le smart contract en n'étant que des alternatives limitées ou des compléments.

Enfin, parce que l'environnement technologique qui entoure l'assureur
est en pleine mutation

Il crée ou va créer les conditions de nouveaux smart contracts et « au hasard » :

• les IoT (internet of thing) qui vont créer de nouvelles données et permettre de suivre en temps réel de nouveaux événements garantis (un dégât des eaux créé par un lave-linge, une panne sur une machine, une rupture de chaîne du froid dans la production alimentaire, un choc sur une voiture synonyme d'accident, etc.) ;

• l'automobile autonome et la cohorte d'informations et de modèles d'autonomie ;

• l'extension des calculs réalisés par des HPC (high performance computings) qui pourraient réaliser des simulations pour déterminer la gravité d'un événement ;

• le traitement de l'information par la Data Science que ce soit du texte, de l'image, de la voix, que ce soit pour le fond, la forme, la formulation, l'intonation.

Le smart contract reste avant tout un objet technologique qui a vocation à disrupter l'assurance et à la rendre plus attrayante pour l'assuré.

Le grand concurrent du smart contract à ce jour est une autre technologie : l'intelligence artificielle qui viendrait en appui des contrats traditionnels.

Le chemin à parcourir est encore long même si des pionniers comme Lemonade15 montrent que c'est une solution viable. L'intelligence artificielle devrait permettre d'atteindre un objectif similaire en termes d'expérience client, à savoir la gestion automatisée et autonome de l'événement et de la prestation servie. Il est par ailleurs totalement possible d'imaginer de combiner les deux technologies. Cependant, le smart contract risque à ce stade de partir avec un double avantage : la technologie pour le supporter existe alors que beaucoup de choses sont à inventer avec l'intelligence artificielle. Enfin, il y a l'aspect coût : est-ce que les coûts de développement de cette intelligence artificielle ne seront pas prohibitifs dans l'atteinte des gains atteints par un smart contract ?

Cette « compétition » entre ces deux approches va être passionnante à suivre.