Sous l’impulsion du Système européen des Banques centrales, la réglementation AnaCrédit entrera en vigueur dans sa première phase au 1er janvier 2018.
Cette réglementation a pour ambition d’harmoniser les dispositifs de collecte des données de crédit et de créer une base de statistiques européennes de référence. Celles-ci accompagneront les missions de la Banque Centrale, telles que la prise de décisions dans le cadre de la politique monétaire et de la surveillance macro prudentielle.
Toutes les banques de la place vont devoir répondre à cet objectif ambitieux avec tous les impacts d’organisation métier et SI que cela impose.
AnaCrédit c’est quoi ?
La BCE cherche à bâtir une base de données sur les crédits dans la zone Euro et MSU afin d’être mieux informée, de comprendre et de surveiller (grâce à un système de données et d’indicateurs uniformes) ses membres.
En d’autres termes, la BCE demande aux banques membres les data pour assurer sa nouvelle mission sur les crédits d’une somme égale ou supérieure à 25 000 €. L’objectif est de centraliser à un niveau de granularité fin (Prêt par prêt / Loan by Loan), les encours de crédits accordés par les institutions financières de la zone euro : (découverts, cartes de crédit, titres de créances, …)
Les data supplémentaires par rapport aux obligations réglementaires actuellement en vigueur (COREP notamment) sont le cœur d’ANACREDIT.
Qui est impacté par AnaCrédit ?
AnaCrédit est portée par la BCE, et sera donc applicable en Europe.
Au début des réflexions, étaient soumis à la réforme, les établissements G-SIBS (Global Systemically Important Bank => les 25 banques systémiques dont le défaut entrainerait automatiquement les autres banques de leur zone géographique dans le chaos). Aujourd’hui, en Europe, cela s’applique à tous les établissements au niveau groupe (pour l’Europe) mais aussi au niveau des filiales de groupes étrangers.
Les règles AnaCrédit ne seront applicables qu’à certaines entités et succursales des organismes bancaires. Le reporting est obligatoire pour chaque institution de crédit résidente d’un pays de la zone euro. Ceci inclut les succursales de ladite institution de crédit, indépendamment de leur lieu d’implantation. Les règles AnaCrédit s’appliquent également aux succursales d’institutions de crédit étrangères. Ainsi, par exemple, une succursale d’une banque britannique ou américaine installée dans un pays de la zone euro tombera dans le champ d’application des règles. Un reporting consolidé pourra être introduit dans une phase ultérieure.
Ces règles AnaCrédit ne s’appliquent pas aux filiales d’entités constituées dans la zone euro, par exemple, lorsqu’une banque constituée en France possède une filiale constituée au Royaume-Uni, cette dernière n’est pas soumise à l’obligation de reporting AnaCrédit.
Quels sont les défis d’AnaCrédit ?
Les règles étant différentes d’un pays à l’autre, les institutions financières vont devoir identifier et/ou résoudre les risques de double reporting,
AnaCrédit est une nouvelle étape clé pour les obligations de reporting des institutions financières, du fait de l’étendue du périmètre des produits couverts et de la granularité requise.
La production d’une centaine de données de crédit par ligne d’engagement à une fréquence a minima trimestrielle et le seuil de déclaration très bas des transactions vont nécessiter une refonte des plateformes permettant la collecte, l’agrégation, les calculs et la production des reportings réglementaires,
Pour les établissements de crédit, l’enjeu concerne toutes les étapes de la chaîne de valeur, à savoir : La collecte, le traitement, l’analyse, le stockage et la restitution de l’information (très dense car seuil de déclaration très bas = volumétrie importante).
Ainsi, l’objectif d’harmonisation nécessitera des métiers qu’ils adoptent des concepts et des définitions ayant des sens différents selon les pays (types de prêts, « mauvaises créances »…).
Enfin, des questions de conformité aux réglementations locales risquent de se présenter
Et concrètement ?
Le type de données à collecter concerne :
La définition de la contrepartie, la définition du produit (de crédit) et de son montant au sens Bâlois (capital restant dû, EAD, RWA, …)
La granularité de données imposera aux banques de revoir leur stratégie de stockage de données (Big Data ?), ainsi que leur mise à disposition (fin des Datawarehouse monolithique servant surtout à l’archivage des données).
Finalement, les banques vont très certainement ouvrir leurs SI Risques/Bâlois pour intégrer les besoins d’AnaCrédit.
Les impacts lors de la mise en place d’Anacrédit
Les délais ?
Une première collecte de données est prévue pour le 31/03/2018, avec une fréquence de reporting trimestrielle.
DORIAN
C’est l’acronyme pour DOnnées RIsques ANacrédit, la déclinaison du projet portée par la Banque de France.
En synthèse, L’effort sera surtout d’étendre la collecte de données au-delà de COREP, d’appliquer les calculs Bâlois et de mettre en forme un rapport « DORIAN ».
C’est aussi une opportunité pour les banques de poursuivre l’urbanisation de leur SI Risque, la fiabilisation des données et une trajectoire pour aller dans la direction des nouveaux challenges qui attendent les banques et qui requièrent une utilisation optimale des données et des indicateurs que la BCE réclame.
Il s’agira donc non seulement de répondre aux exigences du régulateur mais surtout d’utiliser cette réglementation comme un accélérateur de performance.
L’expression « SI Agile » revient régulièrement dans les articles récents. Si son sens premier se comprend bien, quel est le rapport entre SI Agile et Entreprise Agile ?
Nous avons vu dans notre chapitre 1 que le terme « Agilité » était employé pour des moyens, des organisations, des méthodes et des techniques utilisés à différents niveaux dans l’entreprise. Mais rien sur le Système d’Information… Pour le SI, le terme de « flexible » semble plus approprié.
Définition du si « agile » ou « flexible » ?
La définition communément admise est un SI dont la capacité de « time-to-market » a été fortement accélérée.
On rajoutera à cette définition, 2 capacités supplémentaires :
Pouvoir réagir à l’inattendu : arrivée d’un nouveau concurrent (Exemple : Free Mobile pour la téléphonie)
Pouvoir s’adapter facilement aux évolutions métiers (réglementaire, uberisation, digitalisation) et exploiter les nouvelles technologiques (Cloud computing, Big Data).
Cette définition est calée sur les résultats attendus des projets agiles : accélération du Time-to-Market, réagir à l’inattendu et s’adapter aux évolutions en cours. Il est donc tentant d’utiliser le même adjectif « Agile » pour désigner les 2.
Pourquoi distinguer agilité de l’entreprise et flexibilité du si ?
Les projets / organisations / entreprises agiles ont besoin d’un SI qui leur permette de délivrer toute leur valeur ajoutée et notamment l’accélération du « time-to-market ».
A l’inverse, les travaux / investissements réalisés pour rendre un SI plus urbanisé et interopérable peuvent pousser l’entreprise à aller vers des projets agiles afin de profiter de tous les avantages de son SI et de rentabiliser ses investissements.
La mise en agilité de l’entreprise pousse à aller vers un SI flexible. Et réciproquement.
L’agilité de l’entreprise et la flexibilité du SI sont corrélés mais pas identiques. Pour étudier la dynamique entre les 2, il est préférable à mon sens de les distinguer : agilité pour l’entreprise et flexibilité pour le SI.
Comment construire un si flexible ?
Le SI s’est construit par accumulation de couches au fur et à mesure de son histoire. Malheureusement le SI résultat n’est pas naturellement flexible au sens où on le souhaite aujourd’hui. Le rendre flexible nécessite des projets et donc des coûts. Alors comment le construire ? Tout le SI doit-il être flexible ? Est-il possible de n’avoir qu’une partie du SI flexible ? Voilà des questions auquel un Architecte d’Entreprise doit être capable d’apporter son concours pour y répondre.
Retour d’Expérience : la tentative du Bi modal
La notion de SI bi-modal a été introduite il y a quelques années par le Gartner. Elle permettait de différencier 2 pans du SI et donc 2 vitesses de transformation différentes. Un SI flexible qui pouvait évoluer très vite pour des problèmes de concurrence, de stratégie commerciale et d’évolutions des clients et des technologies. Et à l’opposé, un SI non flexible, qui pourrait évoluer à une vitesse moindre car il ne serait pas soumis à ces pressions de « time-to-market ». Le problème de cette analyse était qu’elle opposait le front office (la partie distribution / commerce) avec la partie back office (mainframe souvent), en oubliant que les évolutions du premier avaient des impacts sur le second et donc que leur évolution devait être conjointe.
Une réflexion souvent entendue : « je peux bien faire des évolutions sur mon Front client tous les 15j mais quand je demande une évolution sur le mainframe (ouverture d’un flux) il faut 3 à 6 mois de délai »…. Cette notion de SI Bi-Modal a depuis été revue par ses concepteurs
Le SI des sociétés est composé de plusieurs parties qui peuvent évoluer à différentes vitesses grâce aux travaux menés par les architectes et les urbanistes. Ils ont préconisé la mise en place des systèmes d’échanges, des référentiels etc. Le couplage faible et l’interopérabilité entre les différentes parties du SI prennent maintenant tout leur sens.
Le SI est multiple et composite. Ses contraintes et interactions autant internes qu’externes, sont nombreuses et variées. C’est dans l’étude de ses différentes dimensions que nous allons pouvoir dégager des idées pour le rendre plus flexible.
Rendre à la fois toute l’entreprise agile et tout le si flexible?
Certaines entreprises ont lancé de grands programmes de transformation afin de rendre l’ensemble de l’entreprise agile et de rendre le SI flexible (Axa par exemple). Cette révolution est liée au besoin de transformation digitale, à la concurrence des start-ups (Uber, AirBnB) et des GAFA.
Quand cette transformation est impulsée par la Direction (métier pas uniquement la DSI) sur l’ensemble de l’entreprise, cela engendre un changement de culture global de l’entreprise. La mise en agilité est alors facilitée par les moyens mis en œuvre au niveau des directions, des métiers et de l’IT.
On retrouve néanmoins dans ces plans de transformation les 2 dimensions :
Changement de culture d’entreprise et de méthodes pour aller vers l’agilité de l’entreprise
Fortes évolutions architecturales et investissements pour rendre le SI flexible.
Pour des facilités de communication, les 2 sont alors identifiés sous le terme « Agilité ».
Mais cela n’est pas toujours possible, pour des raisons de budget, de culture d’entreprise, de technologie etc. Avant de lancer un tel programme, il peut être intéressant de ne rendre qu’une partie seulement de l’entreprise agile ou une partie du SI flexible. Cela permettra de tester et de valider la démarche avant de la déployer à l’échelle / sur tout le périmètre.
Un si flexible est un si opérationnel bien architecturé et une usine logicielle en place
Pour que le SI soit flexible, 2 axes sont à prendre en compte :
Le SI opérationnel doit être construit sur des bases solides. Ces bases sont connues : points de référence identifiés pour les données, pas de redondance applicative, couplage faible et interopérabilité entre les applications / services / domaines, Maitrise des flux etc.. Les grands principes de l’urbanisation des SI sont bien présents.
La mise en place « d’usines logicielles » permet l’accélération effective du « Time-to-market », pour développer, tester, recetter et mettre en production (devops – du développement jusqu’à la maintenance) dans les meilleurs délais les applications dans le SI opérationnel.
L’usine logicielle est bien un des moyens qui permet de construire et de mettre en place un SI opérationnel répondant aux critères de la flexibilité.
Traditionnellement les architectes interviennent sur la 1ère composante, le SI Opérationnel. Pour des raisons de cohérence d’ensemble, les architectes pourraient aussi avoir un œil sur la mise en place des usines logicielles.
Quelques outils autour du DevOps … qui ont besoin d’architecture
De l’intérêt de la vue d’ensemble du si et de l’architecture
Pour comprendre le SI opérationnel, il faut en avoir une vue d’ensemble et voir ainsi qu’elles sont les parties qui sont plus « étanches » ou « indépendantes » les unes par rapport aux autres. Celles qui peuvent (éventuellement) évoluer indépendamment d’autres parties.
La cartographie du SI est un point d’entrée essentiel de cette analyse. La cartographie doit prendre en compte plusieurs dimensions du SI : fonctionnelle, technologique, flux et données principalement. Mais peut aussi prendre en compte les processus, la finance, les utilisateurs …
Comme on l’a vu, il faut que cette analyse prenne en compte obligatoirement la dimension métier dans sa transversalité par rapport au SI, car c’était bien le défaut initial du SI bi-modal.
Si flexible sur quel périmètre et pour quels critères ?
Dans la réflexion, il est essentiel de bien réfléchir aux 2 aspects du SI que nous avons déjà identifiés : l’usine logicielle et le SI opérationnel pour garder une vue d’ensemble du SI et de sa construction.
Ci-dessous, nous proposons une base de questions pour identifier un périmètre d’amorce de flexibilité du SI :
Définir le rythme des évolutions demandées, le « time-to-market » : Des évolutions rapides demandées avec des livraisons régulières ? Alors la flexibilité s’impose pour cette partie du SI.
De nouveaux projets ? De nouveaux terrains à défricher ? Il faut en profiter pour mettre en place une nouvelle architecture SI et une usine logicielle adaptée. Attention toutefois à bien définir le périmètre du projet : un périmètre trop restreint ne permettra pas de démontrer les bénéfices et un périmètre trop large aura des risques de rejet.
Profiter des innovations technologiques ? Bien sûr mais attention aux risques liés aux nouvelles technologies et leur pérennité notamment.
Quel périmètre métier ? Distribution ? Cœur de métier ? ou au contraire fonction support ? L’efficacité, le besoin métier, le risque opérationnel mais aussi les facteurs humains doivent rentrer en ligne de compte du choix de périmètre
Il est important, dans ces phases, de faire intervenir les architectes d’entreprise pour garantir la cohérence globale du SI et donc sa future flexibilité.
Construire un SI flexible est un vrai challenge. Souvent lié en plus à un changement de culture avec l’agilité en point de mire.
Par leur connaissance globale du SI et les projets transverses qu’ils peuvent identifier (référentiel, systèmes d’échanges, interopérabilité etc.), les architectes peuvent aider l’entreprise à rentrer dans ce nouveau monde de l’entreprise agile et de son SI flexible.
Coach Professionnelle, Team Leader Transformation Agile des Organisations
Cela fonctionne par ce que les membres de l’équipe s’entendent, participent et communiquent entre eux.
Interview Timothée L.
Sérénité, collaboration, fluidité, l’équipe de Timothée L (Manager dans une Grande Banque Française), est beaucoup plus enthousiaste depuis qu’elle a adopté la méthode Agile Scrumban. Comment ont-ils réussi cette transformation Agile ? Quelles ont été les étapes de mise en œuvre et quels en sont les premiers résultats ? Timothée, revient sur la transformation Agile de son équipe, composée de 3 Business Analystes, 4 Développeurs et 1 support.
Comment as-tu connu les méthodes agiles ?
Lors de ma précédente expérience dans une autre banque, j’ai travaillé dans une équipe en mode Scrum.
Qu’est-ce que le lean management t’a apporté ?
Le Lean Management pose un cadre ce qui nous a permis de mettre en place une démarche d’amélioration continue.
La gestion de la capacité nous a permis de mieux gérer les priorités et de nous rendre compte du temps passé sur d’autres tâches que la réalisation de nouvelles fonctionnalités.
Egalement, la mise en place de la matrice de compétence a permis de mieux se rendre compte des compétences présentes dans l’équipe et de celles à développer.
Pourquoi avoir décidé d’évoluer vers l’agile ?
L’amélioration de notre efficacité est une de nos préoccupations principales.
La gestion de la capacité introduite par le Lean Management nous a fait prendre conscience des freins qui nuisaient à notre efficacité.
Nous avions besoin d’un mode de fonctionnement nous permettant de mieux estimer les tâches, de livrer plus fréquemment pour éviter le rush de fin de cycle et de mieux gérer les goulets d’étranglement entre nos différentes étapes de réalisation.
Comment as-tu géré la transformation vers l’agile ?
Après plusieurs ateliers de PSS (Problem Solving Sessions), nous avons choisi la méthode Scrumban (une combinaison des méthodes Scrum et Kanban) qui permet d’avoir le côté visualisation et gestion du flux, mais aussi la limitation du travail en cours de Kanban et le côté itératif de Scrum.
Quel est ton nouveau mode de fonctionnement ?
Notre white board est le cœur de l’information de l’équipe. D’un coup d’œil il est possible de visualiser où nous en sommes.
Ce support de management visuel est composé de 2 parties :
une partie concerne les projets en cours. Ceux-ci sont estimés en taille de T-shirt (S : réalisable en une semaine, M : réalisable en 1 ou 2 sprints, L et plus : ne rentre pas dans une release, doit être découpé).
L’autre partie permet le suivi du sprint, avec visualisation des tâches et des User Stories par étape.
Quels sont les rôles dans l’équipe ?
La priorisation est faite par le Product Owner (PO)
Pendant les phases de cadrage et d’analyse, le PO découpe les projets en User Stories. Et lors des Kick Off de Sprint, nous estimons les User Stories par priorité et nous les rentrons dans le Sprint.
Le PO, si besoin avec les Business Analyste (BA) ont donc en charge des étapes de cadrage, d’analyse et également des tests fonctionnels.
Les développeurs découpent les User Stories en tâches techniques et les réalisent.
Quels bénéfices en tires-tu ?
Grâce à l’estimation collective de la charge de travail en Story points (évaluation en fonction de l’effort, de la complexité et des incertitudes), les tâches sont mieux estimées. Toutes les personnes de l’équipe réfléchissent à la façon de réaliser les choses, aux éventuelles difficultés et incertitudes
En ajoutant la limitation du travail en cours (WIP) à chaque étape, nous avons également beaucoup fluidifié le flux de nos réalisations. Nous arrivons dorénavant à terminer plus de tâches qu’auparavant. Nous appliquons le mode « Stop starting, Start finishing ».
D’ailleurs, les résultats sont là : notre productivité a augmenté entre 25% et 30%, ce qui nous permet de traiter d’autant plus de sujets par release.
Avec une couverture de tests unitaires de 90% nous sommes beaucoup plus sereins dans nos réalisations, refactorings et changements.
Nous allouons également dans chaque sprint 10% du temps à l’amélioration technique ou à la réduction de la dette technique.
Il s’agit un cercle vertueux : la pression est bien moindre et surtout diluée entre les sprints. Nous sommes sortis du « mode panique ». Cela fonctionne aussi parce que les membres de l’équipe s’entendent, participent et communiquent entre eux.
Quelles sont les prochaines étapes ?
Nous continuons à nous améliorer chaque jour et nous souhaitons aller vers du Continuous Delivery pour améliorer notre rapidité de livraison (Time to Market).
Il est donc nécessaire d’automatiser plus encore les tests fonctionnels, et de mettre en place l’outillage et les environnements qui nous permettront de livrer en production automatiquement à chaque release dans un premier temps, et ensuite après chaque sprint.
Que conseilles-tu aux équipes qui souhaitent commencer à travailler en agile ?
Suivre une formation d’acculturation Agile en amont est important, car cela permet de bien comprendre ce que l’Agile peut apporter, et échanger sur des retours d’expérience.
En outre, il est essentiel de se faire accompagner par un coach quand l’équipe démarre sans réelle expérience en Agile.
Aussi, il faut avoir conscience que passer en Agile ne résout pas tous les problèmes, d’autant plus si le métier ne souhaite pas s’impliquer. En conséquence, il sera difficile de s’assurer de la valeur de ce qu’on produit.
Grâce à son fonctionnement, l’Agile permet de mettre en lumière et de traiter plus rapidement les points épineux.
Enfin, il est nécessaire pour la cohésion, d’impliquer toute l’équipe pour que ça marche, notamment sur le choix de la méthode (scrum, kanban, scrumban, xp…).
Du 30 mai au 5 juin 2017, les équipes de Rhapsodies conseil se sont mobilisées pour la 2ème fois lors de la semaine Européenne du Développement Durable.
Rythmée par des échanges quotidiens, cette semaine était pour nous l’occasion de promouvoir les différentes initiatives lancées en France et à l’étranger autour du développement durable.
Découvrez les moments forts de notre semaine :
Une campagne d’information
Internet, Alimentation, Déplacements, Consommation Énergétique et Recyclage, c’est autour de ces thématiques que nous avons abordé nos collaborateurs au quotidien en rappelant à chacun les défis et les gestes simples à adopter et à transmettre pour être acteur du changement.
Un déjeuner bio
Sur le thème d’une alimentation saine et équilibrée, un déjeunerd’équipe a été organisé au restaurant le Pain Quotidien, et a permis de partager une cuisine basée sur des ingrédients biologiques et d’échanger sur les enjeux d’une alimentation plus respectueuse pour la planète.
2 cleaning days
2 sessions de rangement ont été organisées lors de cette semaine. Cela fut l’opportunité de trier et de recycler ses affaires de bureaux ainsi que sa boite email. Ranger, trier, recycler et améliorer son espace de travail le temps d’une journée !
Un atelier cuisine
Egalement pour sensibiliser les collaborateurs à l’alimentation, cet atelier a été l’occasion de cuisiner tous ensemble dans nos locaux et d’échanger avec le chef cuisinier de Rutabago.
Cet atelier s’est poursuivi par un quizz sur l’alimentation, l’agriculture biologique et la saisonnalité des fruits et légumes. Le gagnant a pu repartir avec un panier prêt-à-cuisiner ! Et pour finir la soirée, nous avons dégusté nos préparations.
Un 2ème RDV qui a suscité beaucoup d’intérêts auprès des collaborateurs car l’entreprise est aussi un espace d’actions et d’engagement.
L’agilité défend 4 valeurs principales. Dans certains cas, on constate des équipes dites agiles mais qui ne sont plus en phase avec les valeurs. Pourquoi ?
En quoi les valeurs de l’agilité et de l’architecture devraient-elles se rejoindre ?
Les 4 valeurs de l’agilité
L’agilité se base sur 4 grandes valeurs qui sont tirées du Manifeste Agile, complétées par 12 principes.
Des valeurs et pas des dogmes
Pour commencer, rappelons que ce sont des valeurs et non des règles. Cela signifie qu’il s’agit d’une vision partagée, chacun ayant la liberté de décider des mécanismes à mettre en place pour y arriver.
Ces valeurs présentent une nouvelle façon de faire, par opposition à l’ancienne.
En effet, quand la valeur prône « la collaboration avec les clients plutôt que la négociation contractuelle », cela ne veut pas dire la mort de tous les contrats. La contractualisation à outrance a eu tendance à éloigner les gens, à les faire se retrancher derrière des clauses comme derrière des barrières infranchissables. La nouvelle façon de faire met en avant la collaboration, le partage d’information, la confiance comme des moyens d’avancer plus efficacement. Les contrats existent toujours mais sont faits différemment, sur d’autres bases.
A l’identique de ces valeurs, pour l’Architecture d’Entreprise, un Framework comme TOGAF pose les bases et bons principes de comment faire de l’Architecture d’Entreprise. Chaque entreprise doit s’approprier ces principes, les décliner dans son contexte et les appliquer suivant sa culture et sa maturité. Il ne s’agit pas d’appliquer l’intégralité du Framework sans une réflexion préalable.
Pour illustrer à quel point les valeurs de l’Agilité peuvent être détournées par les projets ou sont mal comprises par des collaborateurs, j’ai choisi 2 phrases. Elles reviennent régulièrement dans la bouche de collaborateurs et elles nous montrent le chemin restant à parcourir pour la compréhension des bénéfices de l’agilité.
En agile, on ne fait pas de documentation !
Nous allons essayer quelque chose appelée
« Développement Agile »
Ce qui signifie qu’il n’y a plus de plannings et plus de documentation. On commence directement à programmer et à se plaindre
– Je suis content que cela ait un nom.
– C’était votre formation.
La valeur prônée par l’agilité est « des logiciels opérationnels plutôt qu’une documentation exhaustive ». Historiquement, les logiciels disposaient d’une documentation abondante (Spécifications générales, détaillées, etc.) qui n’était pas lue, peu utilisée, pas adéquate et très peu maintenue.
Le but principal d’un projet informatique est bien d’avoir un logiciel opérationnel qui répond aux besoins des utilisateurs. La documentation est un sous-produit du logiciel. Elle doit servir aux utilisateurs, aux personnes qui vont en faire la maintenance, etc. mais elle n’est pas un but en soi.
Beaucoup de projets « classiques » semblaient avoir oublié ce but et donnaient l’impression de livrer plus de documentation que de code à la fin des projets, un comble !
Qu’en est-il pour les projets en Agile ? Etant donné la proximité des participants, il n’est pas nécessaire de formaliser tous les échanges par de la documentation in extenso. Les échanges ayant lieu en direct, et verbalement, ils ont moins besoin d’être complètement décrits. Seul le résultat est conservé, les principales décisions, les règles métier et les choix faits. La documentation est réduite au juste nécessaire et une partie est parfois même stockée dans le code directement. Certains projets agiles en ont-ils profité pour ne pas faire de documentation du tout ? Possible. Les responsables des maintenances ont-ils été surpris de ne pas avoir autant de documentation qu’avant ? Fort probable. Que certains développeurs n’aiment pas faire de la documentation in extenso ? On les comprendrait presque. Mais la documentation ne s’adresse pas qu’aux développeurs. La documentation sur les choix métiers, les données et certaines règles de gestion peut avoir son utilité.
La bonne documentation est bien celle qui va servir par la suite et qui sera maintenue…
L’architecture ne fait que de la documentation ?
A l’inverse, les architectes ont souvent été « accusés » de ne produire que de la documentation. De ne produire que des règles et des normes, pas toujours facilement applicables, que le projet doit ensuite se justifier d’utiliser, ou pas.
Les projets penseraient même que l’architecture les contraint à remplir des dossiers et à passer par des comités qui ralentissent leur bonne marche. Que ces étapes coutent chers et n’apportent rien (ou presque).
Ce n’est bien sûr pas comme ça que nous concevons l’Architecture d’Entreprise. Elle se doit d’être au service et en accompagnement des projets. Leur fournir une aide et non être un frein.
Comme pour les projets, l’architecture doit être documentée utilement et sans excès. Elle apporte la vision d’ensemble du SI dont chaque projet a besoin. Il est essentiel de connaître les règles de construction, pourquoi elles ont été définies et pourquoi certaines dérogations ont été accordées… car la règle est la conséquence d’un besoin et la remise en cause de ce besoin doit remettre en cause la règle.
La bonne architecture est bien celle qui est opérationnelle et donc proche des projets…
Le problème avec l’agilité c’est qu’il n’y a pas de planning
Avant de de faire notre business plan pour l’année prochaine, regardons comment nous avons réalisé celui de l’année passée.
Finalement, nous n’avons rien fait de ce qui était prévu. Comme les autres années
– Pourquoi fait-on l’exercice alors ?
– Cela n’aurait aucun sens de de ne pas avoir de plan
La valeur prônée par l’agilité est « l’adaptation au changement plutôt que le suivi d’un plan ». Avant, le plan était roi et devait être suivi, parfois jusqu’à l’absurde. La planification « à la soviétique » (détaillée sur 5 ans et sans changement possible) en était la parfaite illustration.
Maintenant et dans un monde qui change si vite, les projets doivent s’adapter à l’évolution des besoins et des exigences. Plus question de faire des projets avec des « tunnels » de plusieurs années. Plus question de s’entendre dire, les spécifications sont validées, plus rien ne peut changer avant la prochaine version, l’année prochaine au mieux.
Pour autant et pour des besoins de cohérence et de synchronisation entre les livraisons des produits, il est essentiel d’avoir une certaine visibilité sur les projets. Une vision détaillée à court terme et une vision plus globale à moyen / long terme (les notions de court et moyen terme restent à adapter à chaque situation) sont nécessaires. Des outils agiles existent pour réussir à se projeter sur ces échelles de temps, comme le Burn-Up Chart par exemple. Ils utilisent les données issues des itérations complétées pour alimenter des éléments de pilotage permettant de prendre des décisions.
Car les plannings doivent servir à dégager des trajectoires et des orientations sur le long terme. Ils rendent possible la synchronisation entre les différentes évolutions en cours dans le SI.
Les architectes font des plannings sur 5 ans qui sont irréalisables
Les architectes d’entreprise, garants de la vision d’ensemble du SI, se doivent de dégager une trajectoire globale, long terme, du SI. Ce faisant, ils donnent parfois l’impression de figer les évolutions à plus court terme. Tout semble déjà prévu d’avance et sur 5 ans ! Il semble ne plus y avoir de place pour de nouvelles initiatives ou pour des changements. Les projets ont alors l’impression d’être mis devant le fait accompli et de devoir respecter des échéances qui leur sont imposées sans concertation.
C’est une vision de l’architecte que nous ne partageons pas du tout.
Oui, l’architecture d’entreprise doit bien dégager une vue d’ensemble sur le long terme et essayer de « mettre en musique » les différentes évolutions du SI. Pour autant, il n’est pas question de figer cette trajectoire et de ne pas être en capacité de réagir à court et moyen terme aux événements qui ne manqueront pas de survenir.
La cible du SI ainsi que sa trajectoire sont nécessaires pour consolider les évolutions, donner de la visibilité et apporter de la transversalité. Mais ils doivent être adaptés dès le départ aux contraintes projets et être revus régulièrement en fonction des avancées des projets et de tout ce qui peut avoir un impact (stratégie de l’entreprise, concurrence, avancement / retard des projets, technologies etc.).
La trajectoire du SI constitue un outil d’aide à la décision, d’une part en démontrant que l’évolution du SI répond aux enjeux métiers et d’autre part en mettant en évidence les dépendances entre les différents projets.
Le détournement des valeurs de l’Agilité, nous ramène aux reproches qui sont faits aux architectes : trop ou pas assez de documentation et de normes, trop ou pas assez de planification.
Certains sont trop loin des réalités et d’autres trop proches ?
La convergence de l’architecture et de l’Agile vers un (juste) milieu de documentation et de planification semble donc la solution permettant à chacun d’avoir les outils nécessaires.
Parlons-en et travaillons ensemble seront les maîtres mots des prochains chapitres.
Suite de la série : les solutions arrivent
Chap 3 : Comment l’architecture d’entreprise doit-elle aider à « agilifier » le SI ?
Chap 4 : Comment les architectes (d’entreprise mais aussi les autres) peuvent interagir avec l’agilité ?
Règlementation risques – Perspectives 2017 au regard du chemin parcouru
Règlementation risques – Perspectives 2017 au regard du chemin parcouru
10 avril 2018
– 4 min de lecture
Jean-Luc Vergne
Perspectives 2017 au regard du chemin parcouru
Vous ne pouvez pas avoir échappé aux publications bâloises (les 3 piliers de Bâle 2 … Bâle 3 avec notamment LCR et NSFR … BCBS 239 …) mais savez-vous ce qui a marqué chaque étape de ce long chemin depuis le « Ratio Cooke » ? Avez-vous suivi tous les enjeux qui ont marqué chaque nouvelle directive majeure ? Et avez-vous une idée claire de ce qui est déjà inscrit à la liste des exigences réglementaires pour 2017 ?
Si vous êtes un peu perdus dans tous ces sigles (NPE/FBE, SA CCR, FRTB…), suivez-nous pour les repositionner sur ce long chemin de la maîtrise des risques !
Les principaux jalons
Sans entrer dans le détail des nombreuses directives intermédiaires, nous vous proposons ci-dessous une synthèse des principales étapes, avec leurs objectifs et leurs débouchés :
1988 – Bâle I
Objectif : Assurer la stabilité du système bancaire international en fixant un ensemble d’exigences de fonds propres minimales pour les banques (afin de faire face à d’éventuelles pertes). Principalement axé sur le risque de crédit (risque de non remboursement associé à un prêt accordé par une banque) : Ratio Cooke : les banques doivent financer 8% de leurs actifs pondérés avec des fonds propres.
2004 – Bâle II
Objectifs : Elargir la gamme des risques couverts. Améliorer la méthode de calcul des coefficients de pondération des risques, pour refléter plus finement la nature (et l’importance relative) du risque. Mise en place des 3 piliers : Pilier 1 – Exigences minimales de fonds propres Ratio Mc Donough : nouveau ratio qui affine le précédent en imposant aux établissements de crédit de détenir un niveau de fonds propres minimum d’avantage en adéquation avec les risques encourus (prise en compte des risques de marché et opérationnel, en plus du risque de crédit). Exigences supplémentaires en matière de composition et de qualité des fonds propres. Pilier 2 – Procédure de surveillance prudentielle Organiser un dialogue structuré entre les superviseurs bancaires et les établissements financiers placés sous leur contrôle. Pilier 3 – Discipline de marché Instaurer des règles de transparence financière sur l’état des risques et la façon de les mesurer.
2010 – Bâle III
Objectif : Tirer les conséquences des insuffisances de la réglementation Bâle II face à la crise financière de 2007/2008. Modifications apportées aux 3 piliers : Pilier 1 – Exigences minimales de fonds propres Renforcement des exigences de fonds propres : composition du noyau dur des fonds propres de base définie plus strictement et mise en place de mesures contra-cycliques (globalement, le ratio minimum passe de 8 à 10,5%). Introduction d’un ratio d’effet de levier : plafond de 3% (fonds propres Tier 1 / Total des actifs non pondérés du risque). Pilier 2 – Procédure de surveillance prudentielle Gestion du risque de liquidité avec mise en place de 2 ratios de liquidité (afin de disposer de suffisamment d’actifs liquides pour couvrir les besoins en cas de difficultés de financement) : un ratio de liquidité à court terme (LCR = Liquidity Coverage Requirement), un ratio de liquidité à long terme (NSFR = Net Stable Funding Ratio). Pilier 3 – Discipline de marché Renforcement de la communication financière.
2013–BCBS 239
Objectifs : Renforcer la capacité des banques à agréger les données risques. Améliorer les pratiques de reportings des risques à l’intérieur des établissements. 11 principes concernent les établissements d’importance systémique, sur les 3 domaines suivants : Gouvernance et infrastructure è bénéficier d’un dispositif solide. Capacités d’agrégation des données sur les risques è donner une représentation fiable des risques. Amélioration des pratiques des reportings risques è présenter les bonnes informations aux bons destinataires au bon moment. 3 principes concernent les régulateurs, sur le domaine suivant : Surveillance prudentielle, outils et coopération entre autorités de contrôle è assurer le respect et l’application des principes précédents par les banques systémiques (G-SIBs).
Et maintenant ?
Force est de constater que les réglementations dépassent à présent la définition des ratios, pour affiner les méthodes de calcul en fonction des enjeux, mais aussi s’intéresser à la pertinence des données et des processus de production des reportings.
Dans cette double perspective, le chemin se poursuit à l’horizon 2019, avec une liste bien fournie (non exhaustive) de jalons :
Poursuite de la mise en place de Bâle III, dont NPE/FBE (Non Performing Exposure / Forborne Exposure) : contrôle que les actifs les plus risqués, comme les créances douteuses ou non performantes, soient correctement valorisés et que les provisions soient suffisantes pour faire face aux impayés ;
Poursuite de la mise en place de BCBS 239 et de BCBS 242 (exigences de marge pour les dérivés sans compensation centrale) ;
Finalisation de SA CCR (Standardized Approach for measuring Counterparty Credit Risk exposure) : refonte de la méthode standard pour le calcul du CCR ;
Finalisation de FRTB (Fundamental Review of the Trading Book) : réforme majeure du dispositif de la mesure du risqué de marché ;
IFRS 9 (International Financial Reporting Standards) : mise en place de nouvelles normes de comptabilisation ; cette nouvelle façon de comptabiliser les instruments financiers (du crédit aux produits structurés) va avoir un impact sur les stratégies de gestion des risques, bien au-delà du département comptable des Banques ;
ANACREDIT (Analytical Credit Datasets) : mise en place d’un registre central de risque de crédit des banques européennes, afin d’analyser le processus de crédit et l’exposition du secteur financier européen.
Pour en savoir plus sur le Comité de Bâle…
Contexte
A la suite des différentes crises financières, de nombreuses évolutions d’ordre réglementaire se sont imposées aux établissements financiers. C’est dans ce cadre qu’est né le Comité de Bâle, en 1974.
Composition et fonctionnement
Comité de Bâle sur le contrôle bancaire, en anglais Basel Committee on Banking Supervision (BCBS).
Il s’agit d’une institution créée en 1974 par les gouverneurs des banques centrales des pays du « groupe des Dix » (le G10).
Le comité est hébergé à Bâle par la BRI (Banque des Règlements Internationaux), en anglais BIS (Bank of International Settlements).
Missions
Les objectifs principaux du comité sont les suivants :
Renforcement de la sécurité et de la fiabilité du système financier.
Etablissement de standards minimaux en matière de contrôle prudentiel.
Promotion de la coopération internationale en matière de contrôle prudentiel.
Diffusion et promotion des meilleures pratiques bancaires et de surveillance.
Le comité de Bâle ne possède pas d’autorité, ses conclusions n’ont pas force de loi : l’accord ne contient que des recommandations, à charge de chaque état de les transposer dans son droit propre et de les appliquer (engagement moral de la part des membres du comité).
Couverture géographique
Le comité est aujourd’hui composé de représentants des autorités de supervision bancaire et de banques centrales de 27 pays développés ou émergents.
Ses recommandations sont devenues « un standard prudentiel », adoptées par plus de 100 pays dans le monde.
