Le mirage de la blockchain dans l'assurance

Le lancement prochain de la vente initiale de tokens d'Etherisc (ne parlez pas d'ICO !), déjà considérée comme l'événement de l'année pour le secteur de l'assurance, m'offre une occasion de tenter de relativiser la promesse de ces nouveaux entrants qui voient dans la blockchain le moyen ultime de résoudre tous les maux des modèles traditionnels.
Le procédé commence à être éprouvé : trouvez un domaine dans lequel l'intermédiaire habituel a une mauvaise image et proposez de le remplacer par le mécanisme de confiance distribuée d'une blockchain. Dans le cas d'Etherisc (qui n'est pas seule sur ce marché), la cible est particulièrement vulnérable, tant les compagnies d'assurance sont mal aimées des consommateurs, qui haïssent les frustrations qu'elles leur imposent et les soupçonnent toujours de conflit d'intérêt dans la gestion des sinistres.
Face à ces défauts, qui ne rêverait pas d'une solution transparente, fiable et instantanée ? Grâce à des contrats intelligents (smart contracts), c'est possible ! Le produit d'assurance est traduit sous la forme de code informatique, lisible – donc vérifiable, aussi bien dans ses caractéristiques que dans la qualité de sa réalisation – par n'importe qui. En cas de sinistre, les conditions de déclenchement de l'indemnisation sont automatiquement évaluées et le paiement peut donc intervenir sans délais.
Un tel concept n'a rien de futuriste. En réalité, il est mis en œuvre depuis quelques mois par AXA, avec sa garantie contre les retards de vol Fizzy. Malheureusement, ce que semble oublier Etherisc dans la présentation de son approche, c'est qu'un contrat d'assurance ne se résume pas à la souscription et à la gestion des sinistres. En arrière-plan, une multitude d'autres fonctions, extrêmement importantes, sont nécessaires… et beaucoup moins susceptibles d'être transposées sur une blockchain.

En premier lieu, un produit d'assurance repose sur le travail précis et complexe d'une équipe d'actuaires. Ce sont eux qui déterminent la probabilité d'un risque et les coûts associés, dans le but de fixer le montant de la prime qui, statistiquement, permet à l'offre d'être rentable (ou, a minima, d'atteindre l'équilibre). D'autre part, même si l'acte « technique » de paiement peut être automatisé, il suppose qu'un tiers dispose des fonds nécessaires, y compris quand les probabilités sont prises en défaut et que les indemnisations dépassent les prévisions et le cumul des primes engrangées.
Enfin, quand survient un sinistre, il est des contrats simples dans lesquels la vérification de la réalisation du risque est simple et incontestable, par exemple un retard d'avion ou des conditions météo prédéterminées (pour la couverture d'une récolte). Mais ce ne sont évidemment pas les cas dans lesquels les litiges sont les plus fréquents. Les frustrations des clients interviennent dans des situations complexes (telles que l'estimation des dommages à un véhicule…) où le potentiel d'automatisation est limité et les contestations infinies, imposant des interventions humaines parfois délicates.
Ces différentes fonctions sont aujourd'hui prises en charge par un assureur, certaines s'inscrivant dans un cadre réglementaire strict, et, a priori, Etherisc n'offre rien qui puisse s'y substituer (à moins de devenir elle-même une compagnie). Alors, si l'ambition de la startup se résume à la création d'une plate-forme technique sur laquelle seules des acteurs historiques, intermédiaires indéboulonnables du marché, pourront distribuer leurs produits, cela vaut-il d'y engloutir un investissement de 30 millions de dollars ?
Fondamentalement, quel est l'apport d'une blockchain pour ce type d'usage, sachant que les assureurs n'ont pas attendu son apparition pour explorer les opportunités de l'assurance paramétrique ? La transparence des contrats est le seul qui résiste à l'analyse. Encore faut-il admettre qu'il ne constitue qu'un argument marketing pour les milliards de personnes qui ne liront jamais une ligne de code. Quant aux demandes des clients en termes de fiabilité ou de réactivité et aux exigences de rationalisation internes, des technologies classiques devraient suffire à les satisfaire…