La réforme initiée du cadre prudentiel de Bâle provoque déjà des tensions, entre régulateurs et institutions financières, sur une question en apparence de forme : comment la nommer ?
Les régulateurs parlent d’une « finalisation de Bâle III », alors que beaucoup d’institutions financières y voient déjà « Bâle IV »…
Derrière cet antagonisme de vocabulaire, quels sont les enjeux ? Quelles positions/intérêts s’affrontent ?
En effet, ce débat révèle la préoccupation quant à la continuité ou la rupture du cadre prudentiel en vigueur (Bâle III). L’enjeu pour les institutions financières étant de savoir si les efforts consentis depuis 2010 ne seront pas réduits à néant par l’instauration d’un nouveau cadre prudentiel radicalement différent. Pour les régulateurs, l’objectif est de rassurer le marché sur le maintien du cap actuel.
Un air de déjà-vu !
Ce débat rappelle la longue hésitation au tournant de l’année 2010 entre « réforme de Bâle II », « Bâle 2.5 » ou « Bâle III ». La suite est connue de tous, finalement Bâle III a été bien différent de Bâle II : composition (aspect qualitatif) et niveau (aspect quantitatif, différents coussins compris) des fonds propres, ratios de liquidité…
L’histoire se répéterait-elle ?
Quelques indices
Il est vrai que les nouvelles réformes ne sont pas encore dans le droit positif. Toutefois, le comité de Bâle a publié, à la suite des consultations menées auprès des parties prenantes, un document[1] fixant les principales orientations de la réforme. Il est fort probable que les instances européennes retiennent l’essentiel de ce document, notamment :
La refonte de l’approche standard du risque de crédit: il s’agit de l’épicentre de la réforme. Celle-ci est motivée par une volonté d’accroissement de la granularité des expositions, en vue du renforcement de la sensibilité au risque.
La révision de l’approche de notation interne: les banques ne pourront plus utiliser l’approche interne avancée pour une part importante de leurs contreparties ; elles devront se limiter à l’approche fondation[2]. Le Comité introduit également des floors concernant la perte en cas de défaut et/ou la probabilité de défaut.
La mise en place d’un nouvel « output floor »: il complète les deux mesures précédentes en limitant les avantages tirés par les banques qui utilisent les modèles internes. Concrètement, les RWA calculés par les modèles internes ne pourront être inférieurs à 72,5% de ceux calculés par les approches standards.
Le ratio de levier : la nouvelle réforme introduit un volant supplémentaire au ratio de levier (constitué des fonds propres Tier 1) applicable aux établissements bancaires systémiques mondiaux. Il est fixé à 50% des exigences supérieures de capacité additionnelle d’absorption des pertes.
La revue de la méthode de calcul de la CVA: l’objectif évoqué par le Comité est le renforcement de la sensibilité, de la solidité et de la cohérence de la part des fonds propres qui protège les banques contre les pertes liées aux prix de marché des instruments dérivés, dans le cas d’une dégradation de la solvabilité des contreparties.
L’unification de la méthode de calcul du risque opérationnel: le Comité vise une rationalisation du traitement de ce risque[3], en remplaçant les quatre approches existantes par une seule approche standard. Celle-ci tient compte de l’historique de pertes internes sur 10 ans et facilite la comparabilité des RWA d’une banque à l’autre, en supprimant la possibilité de recours à des approches multiples.
Ces mesures peuvent engendrer deux types d’impacts :
L’alourdissement des exigences en fonds propres: les nouvelles réformes entraineront une hausse des besoins en fonds propres de beaucoup de banques, essentiellement en Europe. Ceci se traduira par des coûts supplémentaires, ou de manière équivalente une baisse de la rentabilité des institutions concernées. Au-delà, le risque peut s’étendre à des effets macroéconomiques négatifs, à une incitation des institutions financières à revoir leurs business modèles ou aux deux en même temps.
Des pertes sèches sur des investissements précédents: outre les coûts futurs précédemment décrits, les grandes institutions financières subiront des pertes sèches relatives à une partie de leur infrastructure opérationnelle développée et mise en place pendant plusieurs années. Ces pertes sont dues à leur incapacité future à utiliser des systèmes qu’elles ont développés pour la méthode interne (notamment l’approche avancée) et le savoir-faire/capital humain qui lui est associé. Les répercussions de ces changements ne se limitent pas à l’aspect financier mais risquent de produire des effets sur les parts de marché et rapports de force entre les différentes institutions au sein des économies et entre elles (notamment entre Europe et Etats-Unis).
Alors, « finalisation de Bâle III » ou « Bâle IV » ?
Regardons juste le calendrier de mise en application des nouvelles réformes (voir Illustration 1) : il s’étend jusqu’en 2022 et même 2027 pour les dispositifs transitoires ; 4 ans pour un simple recalibrage du modèle ? Pour rappel, le passage de Bâle II à Bâle III avait duré moins longtemps (de juillet 2009 à janvier 2013)…
Dans tous les cas et quelle que soit sa dénomination, cette réforme a été entérinée dans ses principales orientations par les gouverneurs des banques centrales des pays membres de la BRI, les banques doivent se préparer à sa mise en place…
[1] Comité de Bâle sur le contrôle bancaire, Bâle III : finalisation des réformes de l’après-crise, décembre 2017. [2] La méthode interne de notation du risque de crédit se compose d’une approche fondation et d’une approche avancée. [3] Comité de Bâle sur le contrôle bancaire : Finalisation de Bâle III en bref, document non daté.
Pour les « habitués » de RPA et/ou des Shared Services, la lecture pourra sauter les deux premiers paragraphes introductifs.
RPA
L’automatisation des processus avec des robots, ou automates, vise à remplacer tout ou partie de tâches répétitives, qu’un employé exécute depuis son poste de travail. Lorsque le processus est entièrement automatisé, sans intervention humaine, on parle de Robotic Process Automation (RPA) et lorsque l’automate assiste l’humain, plutôt en mode « collaboration », on parle de Robotic Desktop Automation (RDA).
RPA ou RDA ne sont pas nouvelles. Simuler, automatiser l’exécution de « scénarios » comprenant des activités manuelles d’un utilisateur d’un poste de travail, se faisait déjà dans les années 90, avec des outils du marché effectuant des tests d’applications. L’opérateur avait le loisir de lancer 100 fois un enchaînement d’un ou plusieurs scénarios de test, et se souciait essentiellement d’analyser et de gérer les exceptions, c’est-à-dire, les cas particuliers qui pouvaient se produire. Le reste, c’est la machine qui le gérait et enregistrait les résultats.
Aujourd’hui les outils se sont certes améliorés, et couvrent avec efficacité des processus métiers. Mais les cas d’usage de la RPA, restent toujours essentiellement dans l’esprit de ce que je viens de raconter :
Pour traiter des activités :
dans un processus bien cadré,
non ambiguës,
et si possible, parfaitement documentées
A relativement moindre valeur ajoutée :
C’est-à-dire avec des ressaisies entre différents outils,
En fort volumes, répétitives
Avec des données numérisées (accessibles via le poste de travail)
Et même si une étape préalable de numérisation des données est nécessaire de nombreux outils RPA incluent aussi des services de capture / numérisation des données dites « non structurées (scan de facture, images, etc.)
…Sans rien modifier des systèmes en place. Comme le dit l’éditeur Contextor, le terrain de jeu du RPA, c’est la surface de l’existant : il clique à votre place. Vous ne modifiez pas les systèmes, vous ne développez pas de gateway d’un système A à un système B, l’outil RPA se charge de « faire la lecture et la recopie des données entre les systèmes ». Vous pouvez donc fonctionner de manière non intrusive, voire temporaire. (Gare au projet de mise en œuvre toutefois, qui peut représenter quelques mois).
Shared Services Centers
Les centres de services partagés, ou Shared Services Centers (SSC) ont été créés pour répondre à des besoins d’une manière mutualisée, en traitant des volumes suffisants pour pouvoir faire des économies d’échelle, et bien souvent, en étant installés dans des pays où la main d’œuvre est bon marché. Parfois aussi, les SSC ont vocation à garantir une expertise pour différents « clients » de l’entreprise – on parle plutôt dans ce cas de centres d’excellence, ou Centres Of Excellence (COE). C’est un cas un peu différent des SSC. Les COE répondent aussi à une problématique de compétence et ne sont pas forcément localisés dans un pays offshore. Sans autre précision, les SSC et les COE sont des entités internes des entreprises. Par opposition aux SSC et COE dits Externalisés, c’est-à-dire délivrés par un prestataire, le plus souvent dans ses propres locaux. La comparaison entre interne et externe présente des différences majeures, qui correspondent à des choix stratégiques différents sur la gestion des connaissances et compétences, les aspects CAPEX/OPEX, etc. Mais outre ces différences, les SSC (plutôt que les COE), qu’ils soient internes ou externes, ont sensiblement la même vocation principale : relocaliser à moindre coût.
RPA vs SSC ?
Nous venons de voir que du point de vue des services concernés, une comparaison des « approches » RPA et SSC peut avoir du sens : lorsque appliquées à des travaux répétitifs, en volumes importants, avec une valeur ajoutée limitée, utilisant le poste de travail. Cette comparaison est donc l’objet de cet article.
Mais ces deux approches peuvent aussi être combinées l’une à l’autre. Et la comparaison doit aller au-delà des gains, car les contraintes et les prérequis ne sont pas toujours les mêmes. Se pose également dans les deux cas la question de l’existant : la performance des processus, la culture, le social (le rôle des IRP, etc.), et la hauteur de la marche à franchir pour mettre en place une solution ou l’autre.
…alors, la RPA et les shared services (ou services externalisés) : concurrents ou complémentaires ?
1. Choisir entre 2 solutions concurrentes
J’ai pu voir chez un client un cas où l’offre disponible en matière d’automatisation a conduit celui-ci à renoncer à un projet « SSC » alors qu’il s’apprêtait pourtant à le présenter en comité d’entreprise. Cette situation vécue m’avait enseigné deux choses : (1) automatiser chez soi est moins douloureux (et moins visible) que de relocaliser/ externaliser, mais (2) les « savings » potentiels ne sont pas forcément meilleurs avec l’automatisation, car le périmètre automatisable est inférieur au périmètre transférable en SSC.
Voici un résumé des avantages et des inconvénients des 2 options :
2. Viser la complémentarité des deux approches
Les SSC existent déjà dans nombre d’entreprises. Les services délivrés en SSC sont bien souvent éligibles pour partie à l’automatisation.
« Ce qui est automatisable le sera tôt ou tard »
L’automatisation ne présente pas en soi un véritable avantage concurrentiel. Mais appliquée aux SSC, elle permet d’améliorer l’efficience, et donc la performance de l’entreprise. Il serait parfois préférable d’automatiser « nativement » c’est-à-dire sans recourir à l’artifice de la RPA, mais cela implique des transformations des process et des systèmes, qui peuvent être finalement trop longues et coûteuses. Pour améliorer des process en partie relocalisés, il est plus simple d’améliorer de part et d’autre de l’interface entre le client et son SSC. Côté SSC il est déjà possible « de faire la même chose » mais mieux, plus vite et moins cher, pour libérer et/ou pour redéployer des ressources : c’est exactement la valeur ajoutée des outils de type RPA.
Automatiser dans les SSC offre deux possibilités :
Soit, faire le même travail dans le SSC, avec moins de personnes
Soit, redéployer des ressources du SSC, en transférant davantage de travail depuis les entités clientes
La deuxième option, lorsque possible, est la plus intéressante économiquement. Car il est plus avantageux de gagner sur une ressource en entité cliente que sur une ressource dans le SSC (simple effet de levier lié aux différences de rémunération).
Mais cette option nécessite de pouvoir faire évoluer les missions des personnels dans les SSC. Par exemple, de transformer le SSC en COE, ce qui implique :
d’avoir des profils évolutifs : une exigence au moment du recrutement qui implique un coût de personnel moins attractif
de manager le centre de service d’une manière adaptée, c’est-à-dire, pas seulement comme une centre industriel. Les managers doivent favoriser la valeur ajoutée, l’amélioration continue et l’initiative, et mettre en place une vraie dynamique de collaboration avec les entités « clientes ». Les outils collaboratifs et certaines méthodes de management (Agile) y contribuent
3. …vers quelle conclusion ?
A court ou à moyen terme, il faut analyser chaque situation séparément avant de pouvoir conclure. Lorsque les Shared Services existent déjà, la complémentarité des deux approches est intéressante. L’automatisation dans un pays à bas coûts peut apporter un gain de productivité très important, sans avoir forcément à gérer la délicate question sociale propre aux pays occidentaux.
Pour l’automatisation comme pour shared services, maîtriser la mise en œuvre
La mise en place des shared services est un projet complexe, mais c’est un sujet plus mature que l’automatisation, sur lequel l’article ne s’attardera pas.
Pour pouvoir bénéficier des améliorations de la productivité d’un SSC grâce à l’automatisation, a fortiori quand il est externalisé, il faut le prévoir dans le cadre « contractuel » et dans la gouvernance.
Aujourd’hui les contingents de ressources offshore sont nombreux chez les leaders du marché. Il faut comprendre qu’un fournisseur ne souhaite pas a priori réduire ses effectifs car cela revient à réduire son revenu et à lui poser des problèmes de sous-emploi. Les critères de choix devraient donc comprendre :
Choisir des fournisseurs qui sont matures vis-à-vis des projets RPA pour leurs clients et qui implémentent déjà l’automatisation dans leurs propres opérations,
avec des outils du marché, comme par ex. Contextor, Automation Anywhere, …
…ou avec leurs propres outils, comme par exemple la suite Assist Edge d’Infosys
Mettre en place des engagements évolutifs dans le temps sur les délais et sur la productivité
Prévoir le coût des projets et de maintenance de la RPA
Définir un modèle de rémunération qui encourage l’automatisation. Par exemple, via un système de partage attractif des gains induits.
Souvent, les entreprises ne disposent pas des compétences requises en interne pour mener des projets d’automatisation. Certains cabinets de conseil présentent une réelle expertise indépendante des éditeurs et des intégrateurs. Cette indépendance nous parait indispensable.
La première étape d’une démarche d’automatisation est constituée de l’audit des processus, nécessaire pour caractériser les meilleures opportunités, c’est-à-dire, les processus métiers et supports à la fois suffisamment simples et non ambigus, et ayant le potentiel d’amélioration le plus effectif et le plus rentable. Cet audit tient également compte du marché des éditeurs. En effet, certaines opportunités, comme par exemple, certains processus comptables, correspondent à des solutions marché éprouvées, alors que dans d’autres cas, une analyse plus fine est nécessaire.
Nous recommandons de faire une étude d’impact pour éclairer les décideurs qui intègreront dans leurs choix, outre les gains induits, les coûts générés, et les conséquences RH et organisationnelles de l’automatisation.
La planification de la mise en œuvre pourra résulter d’une approche projet « classique », comprenant par exemple un appel d’offres pour choisir le meilleur éditeur, ou d’une approche plus agile, commençant par exemple avec un ou plusieurs pilotes dans des régions à moindre impact, avec quelques éditeurs pré sélectionnés. Il peut être tentant de mener un pilote dans un SSC localisé dans un pays à bas coût. L’impact social y est souvent moindre. Mais le niveau de maitrise que vous aurez sur le projet risque de l’être aussi. Le choix du pilote ne sera pas anodin, car vous voulez produire du résultat et convaincre les stakeholders de l’entreprise avant un déploiement plus large. Et en cas d’échec, il faudra pouvoir rebondir (choisir un autre éditeur, un autre processus…).
Enfin, la mise en œuvre est plutôt celle d’un projet d’organisation avec une dimension technique, et non l’inverse. La réussite reposera également sur la maintenance du service sur la durée, c’est-à-dire, intégrant par exemple, la maintenance des automates, et permettant de capitaliser (via un dispositif dédié pérenne) et de monter en maturité.
Plusieurs questions se posent aujourd’hui, alors que de nombreux environnements Hadoop sont en production depuis quelques mois / années :
Le Data Lake est-il aussi utile/utilisé que prévu ? et ne l’utilise-t-on pas, à défaut d’avoir trouvé un usage pertinent, à des fins qui n’étaient pas prévues au départ ( exemple courant … GPP : Gros Passe Plat ou encore EDDC : Extracteur De Données Centralisé … )
Comment structurer les données dans le Data Lake ? Si c’est pour mettre un Hadoop chez soi et structurer sa donnée dans quelques parquets et des tables hive, mais avec la même logique que nos bonnes vieilles tables SQL normalisés 3NF, à part de dire « Youhou, hadoop on l’a fait, on en a une belle maintenant ! » Quel intérêt ? C’est comme s’acheter une console Switch en ne la décrochant jamais de son socle (pardon pour l’image pour ceux qui ne connaîtraient pas la dernière console de Nintendo…).
Comment on rend la valeur de l’outil palpable par l’utilisateur final ? Que ce soit pour du reporting quasi temps-réel / journalier / mensuel, de la Data Viz ou de l’analyse de données avancée (un super Random Forest, un neural Network au top en production…) qu’est ce qui fera la différence pour l’utilisateur final ? Par rapport à ce qu’on lui donnait déjà avant…
J’essaie de donner des éléments de réponses ci-dessous et ce n’est que mon humble avis. Si vous avez vos expériences à partager n’hésitez pas.
1 – Le data lake est-il aussi utile/utilisé que prévu ?
Les environnements distribués naissent un peu partout au moment ou j’écris ces lignes. 2 cas caractéristiques existent qui peuvent être problématiques :
Cas 1 – Etre gourmand, trop gourmand : De nombreuses entreprises se sont ruées vers la tendance sans même vraiment avoir eu une réflexion de fond sur la valeur que devraient leur apporter ces nouvelles capacités dans leur contexte, elles se retrouvent aujourd’hui avec des téras stockées qui ne leur apportent pas autant qu’elles l’auraient espérées. On a voulu en mettre beaucoup, on n’a pas pris le temps de travailler sur la description de ce qu’on y a mis (meta data), et peu de gens comprennent vraiment ce qu’on peut y trouver et si c’est vraiment fiable.
Leur Data Lake devient petit à petit un passe-plat facilitant préparations et fournitures de certaines données bien spécialisées, même sur des volumes qui ne justifient en rien son usage, opérant quelques croisements ici et là entre sources originales qui n’étaient pas avant dans le même environnement technique. Elles font face à des bi-modes Hadoop VS Entrepôt Oracle/SAS (pour ne donner qu’un exemple). Certaines données sont dans les deux types de système et l’utilisateur Analyste ne sait pas vraiment lequel utiliser. Alors les Data Scientist, statisticiens – vieux de la vieille continuent à bosser dans SAS parce qu’ils n’ont pas le temps d’apprendre Python, et les petits jeunes qui sortent d’écoles pensent pouvoir changer le monde avec leur modèle de churn codé en Python / Spark mais qui a en réalité déjà été implémenté il y a 10 ans par un Data Miner expert SAS avec une méthode et des résultats similaires… Ce n’est qu’un rien caricaturale.
Pour prouver sa valeur et justifier son coût, ce Data Lake là va devoir se recentrer sur des usages clés porteur de valeur (et de gain euros…) pour l’entreprise, qui justifie son existence, ou mourir de désillusion ou rester un gros GPP (gros passe plat…).
Cas 2 – Etre timide, trop timide : D’autres entreprises plus prudentes, fonctionnent en petites itérations, à base de POC Big Data sous Microsoft AZURE, AWS et autres google cloud, en sélectionnant des cas d’usages qui justifient l’utilisation de telles plateformes. Parfois, le risque est d’être dans l’excès inverse du premier cas, en priorisant trop et en ne montrant rien.
Trouver 3 usages coeur de métier pour commencer est une excellente chose, mais les cas d’usages doivent être assez complets pour montrer l’étendue des possibilités que peut apporter un environnement comme hadoop et tous ses petits (la multitude d’outils d’intégrations, d’analyses, de traitements qui se basent sur hadoop).
Toutefois, faire un vrai POC métier est la clé pour les entreprises qui en sont à ce stade, montrer que Hadoop traite très très très vite un très très très gros volume de données, n’apporte rien au métier. Faire une démo d’un outil métier qui illustre un vrai cas métier en mettant en valeur :
La performance ressentie par l’utilisateur (des jolis diagrammes qui s’affiche rapidement quand l’utilisateur clique sur la carte 🙂 « C’est beau, ca va vite, c’est utile ! ouaouh ! »
La valeur/connaissance apportée en plus en allant au bout de l’usage : On sait détecter un problème, une fraude, etc…et ça génère une alerte en temps réel dans l’outil de l’opérateur qui lui recommande l’action à faire ! Ouaouh merci c’est ce qui fallait ! c’était possible alors ? dingue…)
Dans tous les cas, encore une fois allez au bout de l’usage ! On a tendance à s’arrêter juste un peu avant ce qu’il faudrait (par manque de temps, de connaissance métier, de courage). Ne faites pas un POC IT, ayez le courage de faire un vrai POC business pas juste à moitié parce que vous ne connaissez pas assez le métier, allez jusqu’au bout de la démonstration, jusqu’à la jolie petite interface interactive qui fera la différence. Sinon vous n’aurez pas votre Waouh. Faites collaborer les Data Scientist avec les développeurs des appli métiers pour avoir un vrai résultat.
Si vous ne faites pas cela, les gens comprendrons peut être la théorie « D’accord vous faites une grosse boîte où vous mettez toutes les données et puis ça tourne vite comme une machine à laver, c’est ça ? 🙂 ».
Non ! vous voulez un : « Ah, mon opérateur ne va plus devoir scruter toutes les logs à la mano pour essayer de trouver les problèmes, et je vais multiplier par 10 ma productivité donc…En fait…Ai-je toujours besoin d’un opérateur ? » OUI, là on est bon.
2 – Quelques principes pour structurer le data lake
Ne traitez pas votre Data Lake comme une poubelle à données qu’on recyclera peut être un jour en cas de besoin (le fameux « on prend, on sait jamais » du Data Lake, anti GDPR par dessus le marché). Mais traitez le bien comme un lac nourrissant, abreuvant et vital ! Moins de quantité, plus de qualité.
Structurer vos Données intelligemment. Ce n’est pas parce que vous avez beaucoup de place que vous pouvez en mettre de partout et n’importe comment (que dirait votre mère franchement?). Votre Data Lake doit normalement séparer :
Les données sources (Raw Data)à l’image des données du système sources
Les données sources (Raw Data) retraitées uniquement par applications de règles purement techniques (votre format de date standard, types de données, etc…). Pas de règles métiers ! Pas ici, le but est juste de récupérer la donnée brute ! C’est d’ailleurs un sage principe que vous trouvez aussi dans la philosophie DataVault de Dan Linstedt. Vous n’appliquez des règles métier qu’au moment de la construction de vues métiers qui répondent à un usage donné. C’est aussi surtout du bon sens…Cela apportera bien plus d’agilité à l’ensemble du système.
Une Historisation structurée et intelligentedes données du Data Lake. « OH Non ! Il a dit « structuré » et « Data Lake » dans la même phrase le monsieur, c’est pas joli ». Malheureusement, beaucoup d’entreprises oublient cette étape. Mais pourquoi donc ? Suivez par exemple ici (encore désolé…) la modélisation Data Vault 2.0, je parle principalement des concepts de Hubs, Links, Satellites, ou au moins la philosophie pour cette partie. Vous pouvez éventuellement exclure de cette phase certaines données exceptionnelles (par exemple si ce sont des données vraiment peu utilisées très spécialisées, que vous savez ponctuelles comme des données externes one shot (que vous n’achetez pas tous les mois…).
!!! Attention je ne dis pas qu’il faut faire un Data Warehouse d’entreprise dans le Data Lake (je ne rentrerai pas dans ce débat). Le Data Lake doit couvrir un certain nombre de cas d’usage spécifiques, qui nécessitent d’historiser (avec agilité !) un certain périmètre de données, qui tend à grandir au fur à mesure que les nouveaux cas d’usages apparaissent.
Si vous vous arrêtez aux Raw Data et aux business View et que vous ne mettez rien entre les deux, que vous ne faites pas ce travail de structuration fonctionnelle, au bout d’un moment vous aurez un gros sac de données applicatives, et les Data Scientists et autres utilisateurs devront eux même comprendre la logique de recoupement de toutes les sources (notamment le grain, la définition des clés techniques/métiers, etc.). Faites ce travail de structuration de l’historisation (DataVault 2.0 recèle de bonnes idées).
Les données préparées pour être prêtes à l’Usage (Business View), requêtables rapidement pour usages business. C’est dans la consolidation de chacun de ces socles que les règles métiers sont appliquées ! Ici, On ramène les données au plus proche de l’usage et structurées pour l’usage en question. Et n’hésitez pas à dé-normaliser vos Business View! Vous n’êtes pas dans mysql… Plein de lignes et plein de colonnes ? C’est fait pour ! Vous pouvez même aller (dans certains cas) jusqu’à pré-calculer dans une grosse table adaptée tous les indicateurs sur toutes les combinaison de segments (dimensions), de périodes, de dates… (attention, intérêt à mesurer par rapport à votre propre usage de consommation de la donnée), mais ça se fait : « ouahou ! comme les graphiques s’affiche vite… »
Les métadonnées : leur intégration peut se faire de diverses manières, mais faites en sorte que les gens ait confiance aux données qu’ils utilisent (C’est quoi cette donnée ? d’où vient la donnée ? quelle application, quel fichier source ? Qui l’a saisie ? Quand l’a-t-on intégré au Data Lake ? quelle fréquence de mise à jour ? etc.)
3 – Comment on rend la valeur de l’outil palpable par l’utilisateur final ?
Ne croyez pas (et je suis sûr que vous ne le croyez pas) que votre Data Lake se suffit à lui même
S’il est déjà bien structuré (c’est déjà un gros avantage), il a quand même besoin de belles décorations :
je ne vous apprendrai rien : un outil de Data Viz/report qui plaît au métier (parce qu’il a été impliqué dans son choix…). Je ne ferai pas de pubs ici…
Une bonne intégration avec les systèmes opérationnels et dans les deux sens (un savoir faire sur le sujet), pas qu’en collecte. Par exemple : Lancer des simulations directement depuis mon application de gestion qui va lancer un job spark sur la business view associée qui elle va renvoyer des résultats en un rien de temps sur l’application de gestion : L’utilisateur est heureux, il ne connaît pas Hadoop ou Spark, il ne veut rien en savoir, mais vous avez amélioré significativement sa façon de travailler. C’est ce qu’il faut viser. C’est cela aller au bout de l’usage.
Un environnement complet d’analyse pour vos Data Scientist (Data Viz, développement IDE, collaboration/gestion de version, notebooks, les bonnes librairies de dev !) parce qu’ils en ont besoin. Impliquez réellement les principales personnes concernées dans ce choix !
Pour conclure, les idées clés :
Les usages doivent toujours driver la construction itérative de votre Data Lake
Ne cherchez pas à refaire un/des Data Warehouse 2 sans vraiment savoir par qui, pour quoi ce sera utilisé, ne cherchez pas à manger un maximum de données pour devenir le plus vite possible la plus grosse base de données et justifier le nom de votre équipe, BIG Data, j’imagine…
Si on vous pousse un usage auquel on pourrait répondre sur une base mysql, redirigez gentiment le destinateur…A moins que vous soyez force de proposition pour faire évoluer son usage pour justifier l’utilisation d’une telle plateforme.
Si vous êtes assez matures, ne voyez plus votre Data Lake comme un Lab collecteur qui se suffit à lui-même, si vous allez au bout des usages, vous serez obligés de l’intégrer avec des applications métier (vous savez, l’utilisateur qui clique dans son appli et ça lui sort toute sa simulation en 0.5 secondes…).
Inspirez-vous de la philosophie de monsieur Data Vault 2.0 (Dan linstedt) (je ne dis pas qu’il faut tout prendre, mais au moins inspirez vous des concepts de Hub / Links / Satellites qu’un enfant de 4 ans peut comprendre pour une structuration agile de l’historique de vos données). Cela évitera bien des noeuds au cerveau à vos utilisateurs, Data Engineer et Data Scientist, et cela apportera de l’agilité au bout du compte.
Dé-normaliser vos vues métiers ! Dénormalisez vos étoiles, vos 3NF, ça ira bien plus vite !
Le Data Scientist « Stateu » doit ouvrir les yeux au Data Scientist « Informaticien » sur ce qu’il est vraiment en train de faire tourner. Le Data Scientist « informaticien » doit apprendre au Data Scientist trop « stateu » à produire du code industrialisable et réutilisable. Recrutez les deux types de profils (Ecoles de stats, et école d’ingé informatique)
Si vous faites collaborer vos Data Scientist avec les équipes de développements des applications métiers, alors c’est que vous êtes sur les bons usages…
Décider de son rythme et le tenir. Les accros du running savent que maîtriser son endurance est fondamental pour progresser. Mais parfois difficile selon le terrain choisi. Celui de Rhapsodies Conseil, le conseil en management, s’avère à la fois dynamique et complexe. Bonne nouvelle, nous avons tenu notre rythme, à savoir une croissance de 16% qui a porté notre CA à 10 M€ en 2017 et devrait nous conduire à 11,6 M€ en 2018. Cette maîtrise de notre rythme de croissance nous la devons à notre stratégie, au business modeling associé, mais pas seulement.
100 collaborateurs en 2018
Notre volonté de privilégier la qualité de nos prestations s’est traduite par un recrutement ciblé et une augmentation de notre effectif de 26 collaborateurs entre fin 2015 et mai 2018. En parallèle, l’augmentation de nos investissements RH, de notre budget formation et d’autres actions (RSE, innovation) ont contribué à la fidélisation de nos collaborateurs. En cohérence avec une préoccupation clé : construire dans la durée l’évolution de nos consultants. C’est dans cette dynamique que nous allons franchir cette année le cap symbolique des 100 collaborateurs.
Une indépendance renforcée
A l’instar des modèles slow startups, notre objectif est à la fois de prendre notre temps pour réduire les risques d’erreurs et d’éviter la dispersion en dehors ou à la limite de nos expertises. Cette maîtrise a également des conséquences financières importantes qui permettent de préserver notre indépendance et renforcer notre solidité financière. Depuis plusieurs années, Rhapsodies Conseil a fait le choix de diminuer ses financements externes contractés notamment lors d’opérations de croissance externes à la fin des années 2000 et au début des années 2010.
Résultat : une réduction de notre endettement de 62% au cours des deux dernières années. L’équilibre entre la maîtrise de notre besoin en fond de roulement, le maintien de la croissance et l’amélioration de notre rentabilité se traduira en 2018 par une progression de nos fonds propres de 500 K€. Quant à nos ressources financières, nous les concentrons désormais sur les investissements humains et notre environnement de travail.
Une organisation agile
Le rythme de notre développement s’accompagne également de l’évolution de notre modèle de management et de la structuration rigoureuse de nos moyens humains, techniques et financiers. Dans ce contexte, Rhapsodies Conseil privilégie la mise en place d’une organisation agile promouvant l’autonomie, la délégation, l’engagement et la responsabilité.
Il ne s’agit pas ici d’édicter de grands principes mais de faire de cette agilité une réalité quotidienne pour le bien-être de nos salariés comme pour la satisfaction de nos clients. Et ce sans perdre le cap : rester maître de notre croissance et devenir un acteur de référence du conseil en management sur chacun de nos domaines d’expertise.
Et vous ? A quand remonte votre premier souvenir de paiement « sans contact » ? Une première transaction ? Un projet ? Un son ?
2010 : Nice, Ville Sans-Contact
Personnellement, il s’agit de l’événement qui s’est déroulé le 21 mai 2010 : le lancement de « Nice Ville Sans Contact » sous le patronage de M. Estrosi, alors Ministre de l’Industrie et déjà Maire de Nice. A l’époque, je travaillais pour le compte d’un « scheme » bien connu. Nous avions organisé avec l’ensemble des partenaires un parcours millimétré pour le Ministre qui devait le conduire à effectuer 3 paiements sans-contact en des points stratégiques de la ville devant un parterre de journalistes et d’invités. Enormes retombées médiatiques et début de la courbe de notoriété… et d’expérience.
C’était en 2010 et promis, 2011 serait l’année du sans-contact : téléphones mobiles sans-contact, tags, étiquettes flashcode, cartes bancaires sans-contact et TPE sans-contact. Les applications porteraient à la fois sur le paiement, les transports, la culture et le patrimoine ! Tout était prêt mais il avait dû manquer quelque chose puisque finalement il aura fallu attendre 2017 pour constater une adoption massive de l’usage.
2017 : l’année du sans-contact en France (enfin)
Finalement, quand on regarde le graphique ci-dessous repris en mars 2018 sur le site du GIECartes Bancaires, on notera avec humilité que l’année 2011 n’y figure même pas.
Mais l’essentiel est ailleurs car tous ces efforts ont payé : l’année du sans-contact est validée ! C’était 2017 : plus d’1 Md de transactions en France selon le GIE CB. Et encore, ce chiffre devrait être complété par
le volume des transactions non CB, dont la plupart sont des transactions paiement mobile. Et ce n’est pas fini : on évoque même les 3Md de transactions pour la fin de l’année 2018.
Un des enseignements, c’est que déployer c’est bien, mais faire utiliser c’est mieux etque cette fameuse valeur d’usage passe évidemment par l’adoption de standards et de parcours clients qui doivent convaincre les utilisateurs avant tout.
C’est le moment de placer une petite citation relevée lors des 5e Rencontres du Club Sepa en février 2018 : « Gardons en tête que le pays le plus innovant du monde est aussi le premier utilisateur de chèques au monde ce qui montre bien que les habitudes ont la vie dure. Ce sont les USA. ». Yves Mersch, membre du directoire de laBCE.
Autrement dit : en 7 ans, que de chemin parcouru ! Et maintenant, où en sommes-nous ? Aujourd’hui, 1 paiement de proximité sur 10 est effectué en sans-contact en France en 2018. Belle tendance !
Des évolutions au service de l’usage
Revenons sur ce qui a convaincu les porteurs d’utiliser leur(s) carte(s) bancaire(s) en mode sans-contact :
Un effet push tout d’abord, avec l’évolution de l’équipement des porteurs qui disposent non seulement de cartes sans-contact (plus de 70% du parc de cartes CB est compatible) mais également de plus en plus de smartphones compatibles et, de façon plus anecdotique, de « wearables » et autres objets connectés nomades comme les montres, bracelets, bagues et bientôt voitures…
Un effet pull au niveau de l’acceptation et des TPE, ensuite, avec du matériel sans-contact de plus en plus présent et « mobile » grâce aux mPOS notamment. Se profile également l’arrivée des smartPOS : cette nouvelle génération de TPE nous encouragera à faire des transactions de paiements les plus courtes possibles (et donc sans-contact) pour libérer du temps et pousser des services connexes (mini-sondage, programme de fidélité…).
Une évolution de l’image du sans-contact auprès du grand public qui a visiblement mis de côté ses réticences historiques, liées principalement à la sécurité, pour être jusqu’à 60% en juin dernier à réclamer une hausse des plafonds de paiement.
Et n’oublions pas l’augmentation du plafond unitaire de transactions sans-contact à 30€depuis le 1er octobre qui permettra de couvrir environ 60% des paiements de proximité annuels en France*.
Projections instantanées
La carte, aussi forte que le mobile ?
Cas pratique : imaginez-vous au moment de l’addition dans un restaurant de choix. Vous sortez votre carte sans-contact de votre portefeuille pour payer la note de 160€. Vous la posez sur le TPE qu’on vous tend et la remettez dans votre poche. Evidemment, le code doit être saisi et vous le faites directement sur le pin-pad du TPE, sans insérer la carte.
Magique ? Non, PIN online. Vous préférez une authentification biométrique, cela sera bientôt possible grâce au capteur inséré dans votre carte. Allons plus loin et admettons l’industrialisation du prototype de Dynamics qui ne propose rien de moins qu’un wallet dans une carte!
N’allons pas jusqu’à dire que la CB devient un mobile comme les autres mais admettons que la carte plastique a encore de l’avenir.
La convergence pour rendre le paiement invisible
Petit rappel théorique : le paiement sans-contact est une évolution du paiement contact qui est une transaction de proximité, par nature. Cette relation de proximité est par ailleurs de plus en plus concurrencée par le e-commerce.
Mais quand on y réfléchit, ces moyens de payer ne sont que des points d’accès différents qui s’appuient sur les mêmes infrastructures et les mêmes flux : pour l’essentiel du paiement par carte. Tout est bien en place pour une convergence totale !
Pour preuve, le développement des wallets (avec des succès divers) proposant de réaliser à la fois des transactions de proximité et à distance. Avec un parcours toujours plus fluide et de plus en plus indifférencié selon le canal grâce au mobile, des marques comme PayLib, PayPal ou ApplePay sont en position pour « prendre le lead » de la convergence.
Cette évolution ultime où le paiement se fait invisible : un point d’entrée (marque du wallet) et c’est payé, quel que soit le canal (VAD, proxi), le type de paiement (récurrent, ponctuel) ou le support (smartphone, smartcar, smartband) sous réserve des bonnes autorisations et sécurisation.
Ce qui n’avait pas été promis bien longtemps à la suite de Nice en 2010, cette CONVERGENCE UNIVERSELLE, peut-on l’envisager comme un standard en 2018 ?
Préparer la bataille de la confiance
Aujourd’hui, il existe un sport pratiqué par les grands groupes bancaires et industriels : l’intégration d’acteurs innovants, en rupture : les Fintechs. Que cela se fasse par inspiration, juxtaposition, absorption ou « lab’orisation ». Ce n’est pas nouveau de travailler avec des partenaires mais l’ampleur et la médiatisation de ces échanges ont pris une dimension inédite.
En 2017, j’ai accompagné un groupe bancaire français dans l’intégration de Fintech à son offre réseau. Ces projets sont encore confidentiels mais je vous garantis que c’est une expérience fabuleusement enrichissante, pour tous les acteurs concernés.
Mais comme sur tout marché, seuls les meilleurs vont survivre ! Une chose est sure, la bataille des wallets et des parcours clients toujours plus fluides ne fait que commencer.
La plus belle des solutions ne s’imposera jamais sans convaincre ses clients de rester et, encore une fois, la capacité à bâtir (ou maintenir) une marque forte pour gagner la confiance de l’utilisateur final sera un facteur clé de succès.
Et ensuite ?
Comment maintenir un niveau de sécurité élevé avec la multiplication des technologies, des acteurs et l’exigence toujours plus forte d’un parcours client « sans couture » ? Après la fusion de certaines offres, quels devront être les regroupements permettant d’atteindre une taille critique ?
Ma conviction, est que ces puissants acteurs bancaires et industriels « classiques » ont raison de s’armer face à l’arrivée de la vraie disruption, celle des GAFAM et des BATX**(pour faire très simple). Ces acteurs américains et chinois arrivent avec une force de frappe financière exceptionnelle permise par leur marché historique, leur capacité d’adaptation et la masse de leur clients existants. Ils ont déjà commencé à poser les bases de leur arrivée en Europe… Et quand le bon modèle aura été défini, contact ou sans-contact, la France des paiements entrera dans une nouvelle ère
Votre avis ?
Cet article est la restitution mise à jour de mon intervention au PayForum 2018 sur l’état du paiement sans-contact en France.
*Pour les cartes émises à partir du 1er octobre **Les GAFAM américains (Google, Apple, Facebook, Amazon, Microsoft) et les BATX chinois (Baidu, Alibaba, Tencent et Xiaomi) sont considérés comme les leaders hégémoniques du secteur des nouvelles technologies.
A l’aube de la « période transitoire » qui s’ouvre le 13 janvier, avec l’entrée en vigueur de la directive DSP2, on a un peu le sentiment de pénétrer en territoire inconnu !
Jusqu’ici, la communauté des paiements s’est concentrée sur la cible des normes techniques sous la conduite de l’Autorité Bancaire Européenne et plus particulièrement sur le débat entre API et « Web Scraping ».
A trop regarder la cible de mi-2019, en aurait-elle oublié les exigences à respecter dès le 13 janvier 2018 ?
En effet, c’est bien dès janvier que débute la « période transitoire » prévue à l’article 115 de la Directive, entre la prise d’effet de la DSP2 transposée en droit national et l’application, mi-2019, des normes techniques de réglementation concernant l’authentification et la communication (RTS SCA & CSC).
Certains travaux sont en cours pour préparer cette échéance, tels que :
L’information du client, notamment la mise à jour des conventions de comptes et contrats cartes,
La mise en place et la diffusion de la procédure de réclamation, avec des exigences resserrées de délai et de complétude de réponse et la révision de la franchise (50€ au lieu de 150€),
La mise à jour des tarifs (gratuité des demandes de recherche…) et la gestion partagée des frais entre Prestataires de Paiements,
Le monitoring des incidents et le reporting à la Banque de France sur les incidents majeurs,
L’information du client en cas d’incident susceptible d’avoir des répercussions sur ses intérêts financiers…
Toutefois, il sera compliqué de respecter les exigences de janvier sans remise en cause ou adaptation du « web scraping », actuellement utilisé par les Agrégateurs et Initiateurs de Paiement :
Comment concilier cette solution, basée sur l’appel aux sites de Banque en Ligne des Gestionnaires de Comptes, et les exigences de Janvier ?
Sécuriser les données de sécurité personnalisées de l’utilisateur (identification / authentification),
Limiter l’accès aux informations provenant des comptes de paiement uniquement,
Identifier le Prestataire de Paiements dans les échanges avec le Gestionnaire de Compte.
Les solutions ont certes déjà été discutées dans la communauté, au cœur même des débats sur les RTS SCA & CSC (Open API ou « Web Scraping sécurisé »), mais elles ne s’imposeront aux acteurs que dans 18 mois…
Alors, quelle sera la stratégie des acteurs à partir du 13 janvier ?
C’est donc bien une part d’incertitude qui plane sur la période transitoire, avec sur le fond, la question de l’attitude choisie par les acteurs, Banques et Fintech :
Tolérance et anticipation de la mise en œuvre des solutions discutées, sans attendre l’échéance réglementaire des normes techniques ?
Ou affrontement sur la base des exigences non respectées ?
Les décideurs y répondront, sans doute en revenant à l’esprit de la Directive : créer les conditions d’un nouveau marché, avec de nouveaux services rendus possibles par l’apport de tous les acteurs, dans le respect des conditions de sécurité et de protection pour l’utilisateur.
ls devraient alors y voir de nouveaux territoires à conquérir et privilégier l’initiative, la créativité et la capacité d’adaptation. En un mot : l’esprit de conquête !
