Une société du CAC 40 réalisait récemment un audit de son contrat mondial de TMA & projets applicatifs, dont le back office se trouve en Inde. Au programme, des difficultés opérationnelles et des conséquences financières sérieuses, mettant en doute le bien fondé du modèle Offshore.
Cet exemple en rejoint d’autres…
Les métiers ont à peine remarqué le changement. La qualité n’est donc pas si mauvaise que cela. Pourtant, les « maîtrises d’ouvrage » métiers sont formelles : « les indiens sont nuls ! » Et après des mois de démarrage laborieux, la DSI a tout essayé : task force, plans d’actions, voyages coûteux pour développer la proximité avec les équipes distantes, formations des collaborateurs pour travailler différemment, etc. Sans compter l’équilibre entre Front office et Back office, révisé avec davantage de proximité, au détriment bien sûr des objectifs financiers.
Après plus d’un an d’efforts de la part du client et de son prestataire, les équipes sont amères, voire dépitées. La relation de confiance, pourtant si précieuse pour travailler efficacement à distance, n’existe pas, ou alors, seulement sur des « ilots » spécifiques.
Mais qu’en serait-il si des erreurs majeures n’avaient pas été commises ?
Le prestataire ne dit pas la vérité lors de la phase d’avant-vente
A quand un discours commercial enfin mature ?
Les prestataires connaissent pourtant « TRES BIEN » les difficultés rencontrées. Que de temps pourrait être gagné, de sueur et de larmes évitées, si le prestataire exerçait enfin son devoir de conseil, au-delà de celui de gagner un dossier ! Nous pensons qu’un discours mature sur le sujet est indispensable, alors que ce n’est un « deal breaker » que pour celui qui ne connait pas les vrais points forts de son offre.
Le client doit pouvoir mieux comprendre qu’il a un rôle clé dans la chaîne des services
Nous voyons encore trop souvent des candidats timides sur certains facteurs de succès d’un programme offshore (ou nearshore). Par leur passivité, ils encouragent le raccourci intellectuel de l’expertise = la qualité des livrables. La vérité c’est que l’expertise est rarement suffisante au départ, notamment sur le plan fonctionnel, et que même si elle l’était, les malentendus resteraient innombrables, si le client ne s’assurait pas activement et régulièrement que ses besoins sont compris.
La question est donc posée aux prestataires, qui devraient adapter leur discours, en rapprochant les équipe de vente des managers de tels programmes.
Les commanditaires internes du projet disent rarement la vérité aux collaborateurs
Il ne faut pas sous-estimer les conséquences d’une mauvaise communication : des managers métiers en défiance avec les choix qui ont été faits, des pratiques de « shadow sourcing » sur des contrats parallèles coûteux, des messages négatifs et déformant les faits, qui tendent à miner toute chance de réussite. Parmi les écueils en matière de communication, nous voyons l’angélisme, qui crée d’emblée un malentendu durable, et nous voyons aussi l’absence partielle ou totale d’information, vécues comme une forme de mépris.
Nous préconisons la clarté sur les objectifs d’un tel projet, même douloureux. Nous recommandons de responsabiliser et de préparer les collaborateurs à travailler davantage, au moins sur certaines activités. Autre point d’attention majeur, celui de préparer les collaborateurs à accepter les différences culturelles, sources de nombreux malentendus.
Le plan de communication interne aux différentes parties prenantes est un incontournable du projet, dès le T0.
Ce plan sera porté par la direction informatique, voire, la direction générale.
Les conditions opérationnelles d’éligibilité ne sont pas remplies
Les conditions d’éligibilité à l’Offshore constituent un inventaire à la Prévert, mais c’est la partie la plus facile du sujet. Un simple diagnostic d’éligibilité qualitatif et quantitatif, relativement rapide et peu coûteux, permet de porter un jugement pertinent sur un niveau de maturité. Il permet d’analyser :
Le niveau de documentation du périmètre, qui doit être suffisant,
Les pratiques des collaborateurs, qui doivent être suffisamment formalisées et référencées,
Le niveau de maîtrise de la langue de travail (souvent l’anglais),
La complexité technique,
La qualité de l’existant au regard des bonnes pratiques,
La complexité fonctionnelle, et la part du spécifique,
Les outillages de gestion des demandes (leur stabilité, la maturité de leur paramétrage),
Le niveau d’activité sur le périmètre. Par exemple un périmètre trop stable ne permet pas de monter en compétence grâce aux demandes de changement,
La pérennité relative du besoin,
L’offre alternative, en matière d’optimisation des processus et d’automatisation
Les collaborateurs ne sont pas assez formés, ni assez impliqués
Deux publics devront faire l’objet de toute l’attention de la conduite du changement projet:
– Les functional designers / business analysts, qui souvent ne maitrisent pas assez l’expression de leurs besoins.
– Les managers, qui ne sont pas forcément formés aux besoins spécifiques d’un tel contrat. Nous pensons au capacity planning, qui permet l‘adéquation entre l’offre et la demande, dans la flexibilité, et la maîtrise des coûts de l’équipe de delivery. Autre sujet majeur, les pratiques « à distance » de quality control, qui posent la question du juste équilibre entre une bonne collaboration client-fournisseur et un bon suivi via des indicateurs (KPI/SLA) de service. Dernier sujet essentiel du management, la mise en place d’un véritable management de programme, c’est-à-dire, transverse, permettant de sortir des silos fonctionnels. Ce management doit être à la fois opérationnel ET contractuel. Une question à ce sujet : connaissez-vous le contenu de vos contrats d’infogérance ? Un contrat bien conçu comporte des outils de gestion efficaces ; charge ensuite au client de les mettre en œuvre dans le cadre de son activité de « contract management » quotidienne.
A adresser dès le T0 du projet, par un diagnostic (« Fit gap analysis ») puis, par les actions nécessaires dans le plan de conduite du changement de projet.
Plus c’est critique et complexe, plus cela risque de mal
La « trajectoire de migration » signifie que tout ne devrait pas basculer dès le « go live » du nouveau contrat. Une trajectoire permet de prioriser les sujets, selon des critères de complexité et de volumes. Pour certains périmètres, l’expérience montre que cela risque de ne jamais marcher. Car, l’expertise y est trop critique, les délais trop courts, et de plus, la mutualisation des ressources (inhérente aux centres de services à bas coûts) deviendrait un facteur de risque trop important.
Des objects financiers ambitieux sont rarement compatibles avec une montée en charge progressive et sélective. pourtant c’est un « key success factor » d’un programme offshore.
Et si on arrêtait de faire n’importe quoi ?
Se lancer dans un marathon en ayant produit un faux certificat médical, sans s’être renseigné sur les risques d’un tel effort, et surtout, sans s’être entrainé correctement, voilà qui comporte une bonne dose de bravoure…ou d’inconscience ! C’est un peu ce que font nombre de décideurs avant de démarrer un projet Offshore. Il y a 2 types de contre-vérités sur le sujet du sourcing offshore : (1) c’est mature et cela va marcher ; il suffit pour cela de choisir le bon partenaire et (2) cela ne marche pas, d’ailleurs beaucoup de clients reviennent après l’avoir expérimenté à leurs dépens. Un projet offshore réussi offre des bénéfices opérationnels et financiers à la fois durables et importants. Il n’y a qu’à constater l’importance de l’offre et des contingents recrutés sur place pour le comprendre. Cependant un tel projet doit s’inscrire dans une véritable stratégie d’entreprise, qui aura su évaluer les autres leviers de la productivité (tels que l’optimisation des processus et l’automatisation). Cette stratégie aura confirmé le périmètre éligible, et révisé les objectifs financiers, en intégrant une mise en œuvre complexe et donc coûteuse.
25 juin 2025
Pilotage & Performance Opérationnelle et Contractuelle
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.
