L’Open Insuring, quel intérêt pour les assureurs et les clients ?
Si l’on scrute le marché de l’assurance et plus particulièrement la distribution des produits, on constate que la tendance est à l’accélération de la « plateformisation » de la distribution d’assurance, via l’utilisation d’API. Face à la menace des géants du Web, ou à des start-ups qui redéfinissent les parcours, les acteurs traditionnels de l’assurance n’ont pas d’autre choix que de réinventer leur modèle de distribution... encore une fois !
L’Open Insurance : un nouveau relais de croissance pour les assureurs ?
Les assureurs l’ont bien compris : à plusieurs on est plus fort ! D’où une stratégie de distribution résolument tournée vers la mise en place de partenariats variés et le plus rapidement possible.
Mais il ne faut pas restreindre le périmètre des partenariats seulement à ceux des assureurs ! En 2021, les Assurtechs et plus particulièrement les courtiers nouvelle génération de la distribution en ligne sont à prendre en compte dans l’équation !
D’après une étude réalisée par Deloitte en 2018 sur les Français et les services financiers, 81% des français jugent les AssurTech comme étant innovantes, mais 78% ne souhaitent pas remplacer leur assurance par une AssurTech. De fait, cette situation représente une opportunité pour les assureurs traditionnels qui peuvent s’appuyer sur ces derniers pour proposer de nouveaux services aux clients.
Dans ce contexte, quelles opportunités offrent les API aux assureurs ?
Si une API est une façade par laquelle un logiciel offre des services à d'autres logiciels, alors il est possible d’utiliser des services d’un autre ? Ou même de fournir des services ? Affirmatif ! Cette démarche d’ouverture s’appelle l’Open Insurance !
De fait, 3 cas d’usage apparaissent :
1. Insurance as a platform (consommation d’API)
OBJECTIF : RESTER L’INTERFACE PRINCIPALE DU CLIENT
Dans ce cas, l’assureur conserve la relation avec le client via l’interface qu’il lui propose. Il met à disposition de sa clientèle, via ses partenaires et leurs API, des produits assurantiels ou non, qu’il ne possède pas dans son offre « cœur de métier ». Ceci dans le but d’enrichir l’expérience client en lui proposant des services durant les moments clés de sa vie. Pour sa clientèle, il devient le point d’entrée vers les partenaires.
Exemple d’usage : plateforme de services à la personne (déménagement, perte de mobilité, etc.)
2. Insurance as a service (exposition d'API)
OBJECTIF : SE POSITIONNER COMME UN FOURNISSEUR DE PRODUITS ET SERVICES
L’assureur n’est plus en frontal avec le client. Il distribue ses produits via des plateformes tierces et concurrentes. Le bénéfice pour le client est d’avoir un service sans couture. Il peut souscrire une assurance au moment de la transaction sur le site du partenaire, sans avoir à souscrire plus tard une assurance sur une autre plateforme.
Exemple d’usage : l’assureur propose une fonctionnalité de souscription à une assurance sur un site marchand au moment de l’achat du produit. Ici, le service de l’assureur vient s’intégrer dans la plateforme du site marchand.
Autre cas, l’assureur propose ses produits via des courtiers en ligne dont l’architecture du site est intégralement basée sur des API (ex : NOUGA).
3. Open-Insurer (exposition d’API)
OBJECTIF : DEVENIR UN FOURNISSEUR DE SOLUTIONS
Dans ce cas, l’assureur ne tire pas de revenus via la distribution de produit, mais en fournissant à d’autres des solutions IT propres à l’assurance (ex : évaluation du risque, identification et connaissance de la clientèle, lutte contre le blanchiment et le financement du terrorisme, etc).
En général, les services proposés permettent de mieux connaitre son portefeuille clients et de fluidifier la gestion, ce qui permet d’améliorer les processus de traitement et donc au final l’expérience client.
Exemple d’usage : l’assureur chinois Ping An propose un service d’évaluation de dommages auto par analyse IA d’une photo.
Ces 3 cas d’usage ne sont pas exclusifs, mais bien complémentaires. Le bon choix, c’est de choisir les 3 !
Quelques exemples de cas d’usage chez divers assureurs.
La définition d’une API, pour ceux qui ne sont pas « techniques »
Une API (Application Programme Interface) est un ensemble d'exigences qui régissent la manière dont une application peut communiquer et interagir automatiquement avec une autre. Dit autrement, c’est une façade par laquelle un logiciel offre des services à d'autres logiciels.
On distingue 2 types d’API :
1. L’API ouverte sur l’extérieur (publique)
Les API ouvertes sont des interfaces conçues dans la philosophie Open-Source pour être facilement accessibles et appelées par tous les développeurs au sein d’autres programmes ou applications. Elles doivent donc être documentées.
Ces API doivent être sur des portails accessibles depuis l’extérieur et sont généralement conçues pour répondre aux besoins de partenaires externes et de développeurs tiers.
2. L’API à usage interne (privée)
Les API privées permettent de faciliter l’intégration ou l’évolution rapide de briques au sein du SI. Elles sont le lien entre les données dites backend et les applications frontend.
Ces applications peuvent être diffusées publiquement, mais l'interface API elle-même n'est pas disponible pour quiconque externe à l’entreprise.
Les API permettent d’ouvrir une partie de son SI sur l’extérieur et augmentent l’agilité de ce dernier… MAIS ATTENTION, exposer ses données au sein de son entreprise, ou au reste du monde, implique de maîtriser ce que l’on diffuse !
Dans les faits, où en est-on en 2021 ?
Si l’on ne regarde que les communiqués de presse, nous sommes en droit de penser que l’API est la solution particulièrement adaptée pour mettre en place rapidement des partenariats. Et les assureurs qui n’ont pas « API-sé » leurs parcours ne doivent plus être très nombreux… Il n’en est rien ! Durant la réalisation d’une étude sur les bonnes pratiques d’ouverture du SI, que nous avons réalisée pour un de nos clients, nous avons pu constater que si certains sont bien avancés, comme Ping-An, WAKAM, ou encore FMA Assurances, pour beaucoup, le sujet n’est pas aussi simple. Côté technique en premier lieu - même si dans la théorie les API ignorent toute dette technique du SI - la sécurisation des connexions peut parfois représenter une contrainte forte et un frein à la mise en place. Côté fonctionnel en second lieu, tous n’ont pas la même maturité sur les parcours qu’il faut « API-ser », quelle granularité entre les services, quelles données à exposer, etc.
Beaucoup d’acteurs abordent ce chantier par la technique et en oublient l’essentiel : « Quelles sont les activités portées par mon partenaire ? De quoi a-t-il besoin ? »
En conclusion, l’API-sation est une approche qui ouvre de nombreuses perspectives « business ». La démarche à adopter est de penser d’abord cas d’usage, parcours, données, puis ensuite construire la solution technique et non l’inverse … comme toujours finalement !
