A l’invitation d’Emmanuel Papadacci, je suis allé à la présentation à l’agence alpha de CAStor (CA Store) la marketplace d’applications que lance le Crédit Agricole et qui s’appuie sur un socle d’API donnant accès aux données bancaires.
Ce projet est un des premiers de la structure d’innovation récemment crée du Crédit, le Lab 1885 (de la date de création du Crédit Agricole).
Le Crédit Agricole va donner accès aux données bancaires via un SDK reposant sur le socle d’API utilisées pour le développement de son application “Mon budget ”. Cette application est la première de la catégorie bancaire sur mobile avec 300 à 500.000 clients uniques l’utilisant par mois.
CAStor comprendra aussi un “appstore” pour mettre à disposition les applications développées auprès des clients du Crédit Agricole, soit 20 millions de clients dont 6 millions d’internautes actifs.
Les applications développées et diffusées seront indépendantes de l’appstore ; ce seront des applications iOS, Android ou web exécutées dans leurs environnements respectifs. Des applications non bancaires (sans accès aux API de données) pourront aussi être développées et diffusées dans CAStor.
Les clients ne paieront pas les applications bancaires (les applications non bancaires pourront être payantes) mais seront prélevés sur leur compte d’un “pass” forfaitaire mensuel à deux niveaux (limité ou illimité a priori en fonction du nombre d’applications souscrites, voire de leur consommation) qui leur permettra d’utiliser librement les applications. L’application sera gratuite le 1er mois pour le client (il s’agit de l’application d’une règle Groupe généralisée sur les services : le client a 30 jours de droit à l’essai et de renonciation).
A CAStor est associé une coopérative qui regroupe les sociétés développant des applications qui assurera la gouvernance du système.
Les revenus générés par les prélèvements seront répartis entre la maintenance et l’évolution des API, le fonctionnement de la coopérative et les développeurs d’applications en fonction de l’utilisation. Les règles tarifaires sont en cours de finalisation.
Un qualification des applications sera effectuée par le Crédit Agricole pour s’assurer du respect des règles légales (protection des données) et de la charte de développement (agrégation de comptes tiers et concurrence étant interdites entre autres).
Une dizaine d’applications développées par le Crédit Agricole seront présentes au lancement orientées notamment consultation de compte et réalisées par des premiers partenaires tels que Widmee, Webzinemaker et Tikimove.
Cette initiative est une des première, voire la première expérience au monde de “Bank As A Service” dont le concept a mis du temps à murir (j’avais fait une présentation en 2007 sur le sujet consultable sur slideshare).
Elle permet d’apporter une réponse au problème des banques dans la capacité marketing à créer, tester et faire évoluer constamment de nouveaux services et s’adapter au mieux au besoins des utilisateurs dans leurs usages en évolution (voir cette présentation sur l’adoption utilisateur).
En même temps et à l’image d’Apple, le Crédit Agricole conserve la maitrise de son appstore et des conditions qui s’y appliquent et y introduit une dimension de “communauté” (via la coopérative réutilisant les valeurs mutualistes du groupe).
J’ai plusieurs fois eu la discussion sur la possibilité qu’émerge une approche “Bank As A Service” par rapport à l’incertaine capacité technique et la réticence des banques à aller dans cette voie.
Le modèle de pur “Bank As A Service” avec une simple mise à disposition des API bancaires par les banques contre facturation ne me semble pas réaliste. Cela ouvre la porte à une désintermédiation et à une concurrence antagonistes avec la culture des banques.
Le modèle inverse d’appstore interne uniquement alimenté par des équipes internes de la banque ou avec des applications achetées à l’extérieur mais rebrandées aux couleurs et aux formats internes ne me semble pas non plus une approche porteuse.
Ne reste que la solution de l’ouverture d’API dans le cadre d’un écosystème managé et au sein d’un appstore contrôlé qui associe, dans un cadre contraint mais existant, le potentiel complémentaire de chaque acteur.
Cette approche reste cependant focalisée pour le moment sur les usages clients en front-office. Les prochaines étapes à envisager seront :
- Le lien avec la vente de produits bancaires traditionnels à partir des applications (le commissionnement et les modèles de courtage)
- Des API transactionnelles notamment sur les opérations de paiement
- Les approches de verticalisation (reconstruire une expérience bancaire spécifique pour certains segments clients).
Je vous recommande l’article sur le blog C’est pas mon idée pour d’autres détails.
Les commentaires récents