Dans le cadre de missions d’organisation des activités de Run, je m’intéresse souvent – au delà du modèle opérationnel – aux différents domaines de gouvernance à structurer.
Dans ce contexte, la gestion de la relation aux métiers (business relationship management) est un besoin important qui revient régulièrement et peut se définir comme le processus responsable de maintenir une relation positive avec les métiers, en identifiant au préalable leurs besoins et en garantissant la fourniture de service sur la base d’un catalogue de services approprié. Sur ces bases, le processus de gestion de la relation métier s’incarne généralement via le déploiement d’un ou plusieurs gestionnaires de relation métier (GRM). J’ai pu noter un certain nombre de prérequis qui doivent être pris en compte afin de réussir la mise en œuvre d’une telle fonction. J’en partage quelques uns dans ce billet.
Confiance des métiers dans le GRM et dans le dispositif de fourniture de services
Pour réussir la mise en oeuvre d’un GRM avec les métiers, il est impératif que les métiers
acceptent le principe de travailler avec un GRM
aient confiance dans le dispositif de fourniture de services de la DSI.
Ainsi, un GRM efficace établira non seulement de bonnes relations avec les métiers, mais véhiculera aussi l’image du dispositif de fourniture de services. En conséquence, si les métiers font confiance au GRM, ils auront également confiance dans le dispositif de fourniture de services. Les métiers comprennent en effet assez vite que le GRM dépend dans une certaine mesure du dispositif de services, mais doivent être également être convaincus que le GRM a les intérêts du métier à cœur.
Finalement, le GRM souhaitant asseoir sa crédibilité sur la base de la confiance des métiers doit être en mesure de démontrer la valeur ajoutée concrète apportée, et non être vu comme une surcouche du dispositif de fourniture des services.
Collaboration du GRM avec le dispositif de fourniture de services
Le rôle du GRM n’est pas seulement d’être l’interface avec le métier. En effet, le GRM faisant partie intégrante de l’organisation de services de la DSI, doit certes à ce titre regarder vers l’extérieur en direction de ses clients métiers, mais également s’engager auprès de ses collègues du dispositif de fourniture des services afin de s’assurer que les métiers obtiennent le meilleur service possible.
Dans ce rôle essentiel, les compétences et attitudes indispensables au développement de la relation avec les métiers seront également déterminantes pour établir des relations au sein de l’organisation du dispositif de fourniture de services.
Faire partie de l’organisation de services de la DSI ne garantit pas en effet au GRM que ses collègues du dispositif de fourniture de services répondront toujours comme il le souhaiterait. L’une des raisons est que plus le GRM prendra son rôle à cœur et plus il est possible qu’il soit considéré par les collaborateurs du dispositif de services comme faisant partie intégrante de l’organisation métier (et donc potentiellement vu comme « passé à l’ennemi »).
Si cela se produit, le GRM pourra faire face à des tensions continuelles dans ses relations avec les membres du dispositif de fourniture de services.
Clarifier les rôles et responsabilités ainsi que les interfaces
La mise en œuvre d’un nouveau rôle de GRM se créera inévitablement à partir de parties de rôles existants au sein de la DSI. La création du rôle peut signifier que les canaux de communication déjà actifs entre les métiers et les différents acteurs de la DSI soient interceptés par le GRM et que les tâches qui ont déjà été la responsabilité d’autres rôles deviennent la responsabilité du GRM.
Ces changements créent généralement des difficultés : les parties prenantes sont naturellement réticentes à rompre les relations de travail et à perdre des responsabilités importantes pour eux. Ainsi, la capacité du GRM à nouer des relations fructueuses avec les parties prenantes de la DSI peut être tout aussi importante que l’établissement de relations avec les métiers.
Inévitablement, il pourra donc y avoir de nombreuses interfaces et recouvrement avec des rôles couverts par d’autres fonctions et processus. C’est pourquoi une attention toute particulière devra être apportée à la définition des rôles et responsabilités des GRM ainsi qu’aux interactions avec les différentes parties prenantes sous peine de courir un risque de confusion / de manque de clarté et parfois de conflits.
Distinguer activités de Service Management centrées sur l’IT de celles centrées sur les services métiers
La tentation peut être forte de combiner les rôles de GRM avec d’autres rôles de Service Management plus centrés sur des services IT spécifiques (gestion des changements, gestion des problèmes, …). Bien que cela puisse contribuer à optimiser les coûts et simplifier les interfaces, force est de constater que les inconvénients ne sont pas neutres.
En effet, si le GRM s’enlise dans la performance spécifique de certains services IT, il lui sera plus difficile de superviser globalement la relation aux métiers et moins simple de s’engager auprès des métiers au bon niveau pour une gestion pertinente et efficace de la relation.
Pour conclure, et étant donné qu’il est très rare d’avoir des métiers prêts à payer directement pour les services du GRM, il est indispensable d’optimiser le ratio coûts-valeur de ces activités en ne limitant pas la performance attendue à la seule mesure de la satisfaction des métiers.
Les autres articles qui peuvent vous intéresser
Rupture douce 05 : les individus et les interactions d’abord !!
Rupture douce 05 : les individus et les interactions d'abord !!
Les individus et les interactions d’abord !!
Les Individus et les interactions d’abord !! Le nouveau Tome de Rupture Douce est disponible !!! 40 textes, 30+ auteurs, de nombreuses illustrations pour remettre les pendules à l’heure en matière d’agilité et de transformations agiles.
Auto-édition sur lulu.com, 15€ HT (coût de fabrication 10€ + 5€ qui seront reversés aux resto du coeur. Pour mémoire 536€ = repas pour une famille de 4 pour tout l’hiver.
Quel plaisir pour moi d’avoir fait partie de cette aventure collective, capable d’accoucher d’un livre en quelques semaines. J’ai immédiatement plongé dans le projet avec quelques pages qui proposent ma vision d’une agilité agnostique des frameworks, mais centrée sur l’humain, le (bon) sens et la recherche de simplicité. Et ça aussi, ça fonctionne « à l’échelle ».
Séverin Legras
4ème de couverture
Durant toutes ces années, l’agilité a connu de beaux succès, et encore trop d’échecs. Dans tant d’endroits, les transformations agiles sont encore asservies par une descente de processus agiles (Scrum, Kanban, Safe, etc) sur les individus. Heureusement, nous pouvons savourer des initiatives comme Agnostic Agile ou bien Heart of Agile, cultivées par des anciens de l’agilité, ceux qui ont donné naissance au Manifeste Agile en 2001.
Ce tome 05 s’inscrit dans cette mouvance : ici, les contributeurs entendent rappeler que notre manifeste précisait dès sa première valeur « les individus et les interactions plus que les processus et les outils ». Vues les confusions constatées, autant simplifier en « les individus et les interactions d’abord !! ».
Dans vos mains, vous tenez une nouvelle collection d’histoires épatantes, pour remettre les pendules à l’heure. Retours d’expériences authentiques, approches pragmatiques : vous disposerez d’un beau matériel pour espérer que les 10 prochaines années soient encore meilleures.
Il fut un temps où, pour être un bon architecte d’entreprise, il suffisait de maîtriser la modélisation (BPMN, UML, Archimate…), les activités d’architecture (TOGAF, Club Urba-EA notamment), les 4 couches (les processus, le POS, etc.), et bien sûr une bonne vision des technologies.
Un article à ce sujet, de CIO, m’a interpelé récemment. Sur les 12 certifications présentées pour un architecte d’entreprise : 5 sont orientées infrastructures et cloud, 3 sur la méthode, une sur le réseau, une sur l’open source, une sur la sécurité et la dernière sur Salesforce.
Rien, pas un mot, sur la posture de l’architecte ?
Notre contexte a évolué
Or, l’architecte évolue désormais dans un écosystème différent : plus mouvant, plus incertain et plus collaboratif. Si l’environnement de l’architecte évolue, son spectre de compétences aussi. C’est devenu une combinaison à la fois de savoir-faire techniques (voir plus haut) et des savoir-être spécifiques à ces nouvelles manières d’organiser le travail : production en cycle court, décloisonnement des métiers, bref : l’architecte TOGAF se doit aussi d’être un architecte agile. Et parce que les certifications peuvent être utiles comme gage de confiance envers votre employeur ou vos équipes, je vous propose un tour d’horizon des 6 formations devenues indispensables selon moi, pour notre métier d’architecte.
1 : Poser les bases de l’agilité – scrum master ou product owner
L’architecte d’entreprise doit impérativement connaître les bases de fonctionnement des projets Agile (les cérémonies et les daily meetings, back-log, MVP, planification, etc.). Une formation Scrum Master ou Product Owner permet de se familiariser avec les essentiels. Une petite expérience pratique dans l’un ou l’autre ne nuirait pas !
2 : Appréhender l’agilité à l’échelle – safe
Pour passer à une dimension supérieure, il faut alors s’intéresser aux cadres d’agilité à l’échelle. LeSS, DA, Scrum of Scrum sont des bons cadres. Connaître les avantages des uns et des autres permettra d’en discuter en connaissance de cause.
SAFe est le cadre qui intéresse le plus les entreprises en ce moment.
Discuter des avantages et inconvénients de ce cadre est intéressant ; en attendant il est devenu un incontournable. Une certification serait alors utile (en tant que responsable d’une équipe de consultants, je pense que nos clients vont nous le demander de plus en plus).
3 : Adopter une posture agile – management 3.0
Connaître des cadres d’agilité à l’échelle ne fait pas de nous des agilistes. Il faut comprendre la posture agile et ce qui va avec. Une formation de type Management 3.0 est un bon exemple pour comprendre les vrais fondements de l’agilité et de l’auto-organisation.
Les principes du management 3.0 sont basés sur : faire les choses justes de la bonne manière. Quelques principes que l’on peut citer : manager le système plutôt que les individus, prendre en compte les inter-actions sociales dans les relations de travail et simplifier les règles de collaboration entre individus.
Cette formation, comme son nom ne l’indique pas, s’adresse à tous, manager ou non.
4 : Savoir animer des ateliers – design thinking et lean start-up
Avec l’avènement de l’agile et aussi du digital, de nombreux types d’ateliers pour inventer / construire des solutions et des plannings, travailler l’intelligence collective, bâtir des équipes, etc. sont maintenant disponibles.
Avec un collègue coach agile, j’avais recensé plus de 40 ateliers ! Il est important pour un architecte d’entreprise, qui est amené à dialoguer avec nombre de personnes différentes dans l’entreprise, de maîtriser la pratique de ces ateliers pour les mettre en œuvre quand le besoin s’en fait sentir. Le Design Thinking et le Lean Start-up sont des essentiels de nos jours, mais les autres méritent de s’y intéresser.
Vous verrez même qu’à force, vous pourrez aussi créer / inventer vos propres jeux et animations !
5 : Savoir jouer / construire la solution – lego
Savoir présenter une synthèse des travaux, réconcilier plusieurs points de vue (merci TOGAF de nous avoir rappelé ce bon principe), construire les solutions les plus simples possibles, sont dans les fondamentaux de l’architecture. Au-delà d’une formation à la « facilitation graphique », nous pouvons même aller vers les bases du scripting et de la présentation de vidéos pour « vendre » nos solutions.
Dans les nouvelles techniques de construction de solutions, notons le Lego Serious Play qui prend une certaine importance et peut s’avérer très utile pour faire parler et converger différentes populations.
6 : Devenir un coach – process communication
Dans son/ses (nouveau(x)) rôle(s), l’Architecte d’Entreprise aura sûrement besoin d’être coaché pour l’aider dans son changement de posture et trouver sa place dans les nouvelles organisations. Mais il peut lui aussi profiter des techniques de coaching pour aider des projets, des équipes, des chefs de projet ou tout simplement des collègues architectes !
La process communication, mais aussi la PNL, sont des voies intéressantes à maîtriser.
Pour les architectes, les équipes en agilité (Product Owner, Scrum Master, membres) et aussi pour les parties prenantes. Une vue d’ensemble de l’agilité (de SCRUM à l’entreprise, en passant par les cadres d’agilité à l’échelle), une vue d’ensemble des travaux de l’architecture (selon différents référentiels), des exemples concrets de mises en œuvre et surtout un jeu participatif pour découvrir les interactions entre les architectes et les projets agiles (à une certaine échelle) font de cette formation une synthèse de l’évolution de l’architecture et des projets agile. Au-delà de la technique nous évoquons aussi les soft-skills nécessaires.
Conclusion
Voilà mes idées de méthodes et certifications d’animation, de facilitation et de co-construction pour faire évoluer notre métier complexe vers les enjeux d’aujourd’hui.
Il y a une journée mondiale de la protection des données et c’est aujourd’hui, lundi 28 janvier 2019.
C’est le Conseil de l’Europe qui a, le premier et dès 2007, proclamé une journée européenne de la protection des données à caractère personnel.
Dernièrement, et au-delà de GDPR (oui je fais le pari qu’il n’y a plus besoin de dire ce que c’est), l’actualité nous a montré à quel point les données personnelles étaient un enjeu énorme et qu’il y avait encore une longue route à parcourir. La liste des « évènements » liés aux données personnelles ne cesse de s’allonger : Amende Google, Facebook et Cambridge Analytica, vol des données d’élus Allemands, piratage « Collection #1 »… et ce ne sont que les plus emblématiques (il y en a de multiples rien qu’avec Facebook).
Au-delà du fait de mettre en place des responsabilités, des procédures et des outils pour se conformer à GDPR, il me semble important de mettre en avant quelques éléments-clés :
La finalité de GDPR c’est de protéger les individus : oui, il ne s’agit pas juste de protéger des données et de mettre en place des procédures,
GDPR ne peut être vue comme une simple approche de protection et de sécurité : le cycle de vie des données personnelles concerne quasiment tous les acteurs des organisations,
On parle beaucoup des « clients » lorsqu’il s’agit de GDPR : n’oublions pas que les « collaborateurs » d’une organisation sont également à traiter avec, a minima, la même sensibilité,
C’est la « finalité » des traitements sur les données personnelles qui permet de justifier ces traitements : cela milite pour une approche orientée « usages » pour avoir la bonne maille d’étude.
Dès lors, c’est au sein de la culture même de chaque organisation qu’il faut intégrer la protection des données personnelles et, plus largement, la valeur des données. D’un côté, nous avons la culture d’une organisation qui peut se caractériser par ses valeurs partagées, ses croyances et convictions, ses pratiques, ses comportements. De l’autre, nous avons une Culture Data qu’il devient de plus en plus nécessaire de partager le plus largement possible.
Il faut donc diffuser une Culture Data à tous les étages des organisations : C’est cela qui va permettre de prendre la mesure, à l’échelle de l’organisation, de la protection des données personnelles mais aussi de la valeur des données (qualité, disponibilité…). Mais il faut faire cela en s’insérant dans la culture en place, pour venir l’étendre et l’enrichir, et pour s’assurer que cela est fait de façon durable. En effet, penser qu’il suffirait de mettre en place un plan « Culture Data pour tous » générique et sans personnalisation est probablement voué à l’échec.
Et comme il ne faut pas rester sur un « échec », espérons que cette journée de protection des données personnelles permettra de faire avancer la Culture Data à tous les étages de la société.
Data scientist, data analyst, data cruncher,… ces dernières années, le nombre d’intitulés de postes relatifs au traitement, et plus particulièrement à l’analyse, de données a explosé.
Data scientist, data analyst, data cruncher,… ces dernières années, le nombre d’intitulés de postes relatifs au traitement, et plus particulièrement à l’analyse, de données a explosé. On constate également la popularité croissante des compétences inhérentes à ces postes via divers tops ‘in-demand skills’, publiés annuellement sur LinkedIn. Ces postes ont tous une compétence requise en commun, l’analyse de données, aujourd’hui jugée primordiale dans le monde professionnel par le cabinet Gartner, jusqu’à l’élever au rang de norme.
Mais ne sommes-nous pas déjà entrés dans une nouvelle époque, durant laquelle les composantes basiques de ces compétences vont peu à peu migrer dans le ‘savoir commun’ et devenir des pré-requis pour un scope plus large de métiers ? Ne sommes-nous pas entrés dans l’ère de la ‘data democratization’ ?
Pourquoi une explosion de de la demande relative à ces compétences ?
A l’heure où plus de la moitié de l’Humanité a quotidiennement accès à Internet et où 90% des données disponibles ont été créées dans les deux dernières années, toute entreprise collecte et stocke une quantité importante de ces données. De formats et types variés, ces dernières sont également transversalement issues de la totalité des métiers de l’organisation. Les capacités de traitement (stockage et puissance de calcul, ‘asservis’ à la loi de Moore depuis des décennies) ont elles aussi explosé, passant d’un statut de facteur limitant à celui de non-sujet.
Traditionnellement, ces données étaient propriétés de la DSI. Certes, les décisions des BU métiers et du top management s’appuyaient déjà sur ces données. On ne pouvait toutefois pas se passer d’un intermédiaire pour leur consultation et traitement, augmentant les risques de non compréhension de la donnée ainsi que les temps de traitement des demandes. Aujourd’hui, de plus en plus d’organisations transversalisent leur entité ‘data’, afin de rapprocher les données des métiers, porteurs de la connaissance de la donnée, et des usages, délivreurs de valeur.
Car il est évident que, bien qu’elle soit complexe à déterminer précisément et instantanément, la donnée a une valeur évidente qu’il convient d’exploiter. Pour cela, une capacité d’analyse, plus ou moins poussée, est nécessaire à tous les niveaux de l’entreprise, au plus proche de la donnée et ce pour ne pas en perdre la signification.
Mais il existe encore des freins à cette démocratisation. En entreprise, le nouvel analyste peut se heurter à une mauvaise compréhension de la donnée. Même si la tendance est au partage et à la “transversalisation”, les données sont encore parfois stockées et gérées en silo, rendant difficile l’accès et la transparence de la signification métier de cette donnée.
Mais multiplier les analystes peut aussi représenter un risque de multiplier les analyses…identiques. Aussi, un sujet apparaît lorsque la donnée est rendue accessible plus largement : celui de la protection des données personnelles, récemment encadré par la nouvelle réglementation GDPR. En effet, la finalité d’un traitement de données doit aujourd’hui être systématiquement précisée, tout comme la population de personnes accédant aux données en question. Cette dernière doit par ailleurs être réduite au strict minimum et justifiable.
Cette data democratization est donc porteuse, dans le monde de l’entreprise, d’un message supplémentaire : une gouvernance bien établie agrémentée d’une communication efficace sont nécessaires et catalyseront la démocratisation.
Et concrètement, analyser des données ?
Avant toute chose…
Il existe une règle d’or dans le monde de l’analyse de données et elle s’appliquera également aux nouveaux analystes issus de la data democratization. Cette règle, éprouvée et vérifiée, stipule qu’en moyenne 80% du temps effectif d’un analyste sera consommé par la collecte, le nettoyage l’organisation et la consolidation des données, ne laissant que les 20% restants pour les analyser et en tirer de la valeur. Il faut donc que les nouveaux analystes prennent conscience de cette contrainte et aient une base de connaissances sur les réflexes de vérification à avoir lors de la réception d’une nouvelle source de données.
Visualiser
On peut définir la visualisation de données (ou dataviz) comme une exploration visuelle et interactive de données et leur représentation graphique, indépendamment de leur volumétrie, nature (structurées ou non) ou origine. La visualisation aide à percevoir des choses non évidentes en premier lieu, répondant à deux enjeux majeurs du monde de l’entreprise : la prise de décision et la communication.
Mais attention, un graphique mal utilisé peut faire passer un message erroné, laisser percevoir une tendance peu fiable ou maquiller une réalité. C’est donc pour cela qu’il convient de donner à tous une base méthodologique permettant d’exploiter la puissance de la dataviz tout en évitant les écueils.
La force de la visualisation réside en l’aperçu instantané qu’elle permet d’avoir sur une large quantité de données, pour peu que son créateur ait fait le bon choix de représentation. Plusieurs paramètres sont à considérer lorsque l’on souhaite choisir une visualisation : quel phénomène je souhaite mettre en évidence ? de combien de variables ai-je affaire ? ma représentation doit-elle être continue ou discrète ? …
Ci-dessous, une cheatsheet sous forme de visualisation, avec pour thème : “Quel type de graphe pour quel usage ?”
Avec quels outils, pour commencer ?
Une des raisons d’occurrence de cette ‘data democratization’ est l’émergence de technologies facilitatrices, permettant à un plus grand nombre d’interagir avec les données, à l’aide de frameworks de code ou d’interfaces graphiques accueillantes pour une expérience guidée et visuelle :
Logiciels de ‘data federation’ et dataviz : des interfaces graphiques simples, guidant la manipulation de l’import des données de formats et de sources différentes jusqu’à leur visualisation, intégration dans des dashboards et publication de rapports. On peut citer les solutions leaders du marché : Tableau Software, QlikView, Microsoft Power BI,…
Solutions “all included” et plateformes : dans une unique application, la possibilité est donnée de mener des analyses automatiques jusqu’à de la modélisation complexe, le tout sans avoir à toucher (ou peu) une ligne de code (exemples de solutions : IBM Watson Analytics, Dataiku, Saagie,…)
Frameworks et librairies : s’adressant à un public plus averti, il s’agit là de fonctions et méthodes prêtes à être ré-utilisées et adressant des problématiques et utilisation bien particulières (exemples : librairies NumPy et Pandas en Python pour faciliter la manipulation de données, librairie D3js en JavaScript pour la dataviz, …)
Mais il est toutefois un outil encore très majoritairement utilisé pour des cas simples de reporting, visualisation, agrégation et modélisation simple. Il s’agit du tableur on-ne-peut-plus-classique : Excel et l’ensemble de sa cour d’alternatives (GSheets, LibreOffice Calc,…). Et il est évident que l’on ne peut pas parler de démocratisation sans citer cet outil.
L’utilisation du tableur est aujourd’hui un pré-requis pour un grand nombre de métiers, dont certains sans aucun rapport à l’informatique. Aussi, le niveau de compétence en la matière n’a fait que s’élever d’années en années et c’est une tendance qu’il convient d’accompagner. De son côté, Microsoft ne cesse d’enrichir les fonctionnalités et, paradoxalement, de simplifier l’utilisation de son outil, en ajoutant des suggestions basées sur une analyse intelligente des contenus.
Notre conviction
Bien que nous n’ayons aujourd’hui pas le recul pour l’affirmer, on peut avoir bon espoir que cette démocratisation révolutionne la prise de décision en entreprise, en permettant aux employés à tous les niveaux de l’organisation d’avoir accès à des données et d’en tirer conclusions, plans d’action et projections.
Et nous pouvons espérer que cette démocratisation ne se cantonne pas au périmètre de l’entreprise traditionnelle : quid du travailleur indépendant, du petit commerçant ou du restaurateur ? Il est évident que ces individus également, dans l’exercice de leur activité, génèrent ou reçoivent des données qu’ils pourraient exploiter et valoriser (optimisation des stocks, analyses de résultats,…). Pour ces professionnels, un minimum de compétence internalisée mènerait à des économies en prestations et en temps passé, mais également à un éventuel ROI issu de l’analyse et de l’exploitation de leurs données.
Forts de ces constats, nous nous sommes aujourd’hui forgé la conviction suivante :
MREL [1] et TLAC [2], nouvelles exigences réglementaires, vont alimenter l’abondant portefeuille de projets réglementaires, à l’occasion du package CRD II – CRR V. De quoi s’agit-il ? Ce sont des mécanismes d’absorption des pertes qui visent à mettre les contribuables à l’abri d’une faillite bancaire.
Ils ont pour objectif de :
Constituer un coussin de fonds propres utilisable dans la logique du bail-in [3],
Limiter un éventuel recours aux fonds publics bail-out [4], en cas de défaillance d’un établissement bancaire.
Ces deux dispositifs se sont construits parallèlement, par des autorités différentes :
MREL est porté par l’EBA [5] et le SRB [6]. Il s’applique aux groupes bancaires et transfrontaliers établis dans l’Union bancaire en Europe. Il est entré en vigueur au 1er janvier 2016 ;
TLAC est porté par le FSB [7] et s’applique aux grandes banques internationales (G-SIBs [8]). Sa mise en application est prévue au 1erjanvier 2019.
MREL, sécuriser un coussin de capital de plus 8% des passifs éligibles
Transposée dans l’Union bancaire par la directive BRRD [9], MREL impose aux banques européennes de respecter une exigence minimale de fonds propres et de passifs éligibles. Dans son rapport final, l’EBA a exigé que le ratio MREL soit fixé pour chaque banque à un niveau permettant la mise en œuvre de la stratégie de résolution.
Au 1er janvier 2016, la Commission européenne a entériné le ratio MREL, définissant bien au cas par cas pour les banques de l’Union, un nouveau coussin de capital à hauteur d’au moins 8 % des passifs.
TLAC, sécuriser progressivement de 16 à 18 % du RWA
Dès 2019, les Banques Systémiques (G-SIBs) devront afficher un ratio de solvabilité total équivalent à au moins 16% de leurs RWA [10] et 6% de ratio de levier au titre du pilier 1.
Au 1er janvier 2022, elles devront présenter 18 % de leurs RWA et 6.75 % de ratio de levier au titre du pilier 1.
Les instruments financiers éligibles au TLAC sont principalement des capitaux constitués des fonds propres durs (CET1 [11]), des instruments de capital hybride (AT1 [12], Tier 2) ainsi que quelques dettes seniors.
Le nouveau régulateur international, le FSB a ainsi décidé de doubler au minimum les exigences de fonds propres des banques systémiques, par rapport aux exigences actuelles.
Ce niveau d’exigence doit éviter une crise de liquidité fatale (cas de la crise des subprimes et de la chute de Lehman Brothers), en obligeant les grandes banques à puiser dans leurs réserves en cas de défaillance.
Tableau de comparaison MREL et TLAC
Harmonisation du MREL avec le TLAC
Dans le cadre du package CRD II – CRR V, l’EBA préconise une harmonisation entre les deux dispositifs, en adoptant pour le MREL, la même base de calcul, en pourcentage de RWA et non en pourcentage de fonds propres.
Pour les G-SIBs européennes, concernées par les deux réglementations, cette harmonisation leur évite de subir deux réglementations distinctes de capacité d’absorption de pertes.
Quelles conséquences pour les banques ?
Face à ces nouveaux dispositifs, les établissements bancaires doivent :
Mettre en œuvre les outils de résolution et de production de reporting, permettant un suivi efficace des ratios MREL et TLAC;
Adapter leurs structures de fonds propres : plusieurs banques, notamment européennes, ont ainsi procédé, avec un franc succès, à des émissions de dettes subordonnées Tier-2 à échéance 10 ans. À titre d’exemples, Crédit Agricole a reçu une demande cumulée d’environ 16,5 milliards d’euros sur son placement de 3 milliards de Tier-2 (plus grosse émission européenne de Tier-2 jamais réalisée). Société Générale a levé 1,25 milliard d’euros et BNP Paribas plus de 1,5 milliards d’euros.
En conclusion, ces deux réglementations imposent un effort significatif pour les banques, en mise en oeuvre et surtout en gestion de bilan. Leur efficacité devra être jugée, en prenant également en compte les impacts sur la stratégie des actionnaires et de leurs créanciers, impactés au premier rang dans la résolution de crise par bail-in.
[1] MREL : Minimum requirement for own funds and eligible liabilities est une norme européenne d’exigence de fonds propres et de passifs éligibles lors des renflouements internes.
[2] TLAC : Total Loss Absorbing Capacity est un mécanisme d’absorption des pertes en cas de défaillance des banques.
[3] Bail-in : Pratique financière qui impose à certains créanciers d’une banque en difficulté une diminution du montant des créances qu’ils possèdent sur l’établissement de crédit ou une conversion de celles-ci en actions de capital. Le bail-in permet ainsi aux banques de se recapitaliser en cas de crise.
[4] Bail-out : Renflouement d’un établissement financier en difficulté, en général par un état, par injection de capitaux propres afin de permettre sa survie et de protéger les déposants et les prêteurs.
[5] L’European Banking Authority est l’autorité bancaire européenne.
[6] Le Single Resolution Board est l’autorité de résolution au sein de l’Union bancaire européenne.
[7] Le Financial Stability Board est un groupement économique international créé lors de la réunion du G20 à Londres en avril 2009.
[8] Global systemically important banks, sont des banques dont les activités sont tellement importantes et variées qu’une hypothétique faillite aurait nécessairement un effet très négatif sur la finance mondiale.
[9] La Bank recovery and resolution directive est une directive européenne qui permet aux banques de procéder au renflouement interne en cas de crise.
[10] Les Risk-Weighted Assets, ou actifs à risques pondérés, correspondent au montant minimum de capital requis au sein de banques ou d’autres institutions financières en fonction de leurs niveaux de risque.
[11] Les Common Equity Tier 1 sont des composants du capital de catégorie 1 constitués principalement d’actions ordinaires détenues par une banque ou une autre institution financière.
[12] Additional Tier 1 consiste en des instruments de fonds propres continus, en ce sens qu’il n’ya pas d’échéance fixe, notamment les actions privilégiées et les titres convertibles à fort contingent.
