Aliados Conseils rejoint Rhapsodies Conseil pour consolider l’expertise Risk, Regulation & Compliance (2RC). La nouvelle entité sera co-animée par nos deux Seniors Managers Lionel Andreu et Patrick Rose, au sein du pôle Expertise Paiements et Risques.
« Dans le cadre de notre expansion et afin de répondre à la demande de nos clients, soumis à l’évolution croissante de la réglementation dans le secteur financier : BCBS239, Anacredit, IFRS9, FATCA/CRS, 4ème Directive TracFin…, l’arrivée d’Aliados Conseils, avec qui nous avions déjà une relation de partenariat, complète notre capacité d’intervention, de la veille réglementaire jusqu’aux procédures opérationnelles et à la production des reportings. » déclare Patrick Rose, Senior Manager de Rhapsodies Conseil.
« Le rapprochement et la fusion des équipes Aliados & Rhapsodies sur les thèmes majeurs du Risques et du Cash Management va permettre d’élargir notre offre auprès de nos clients et de proposer une diversité d’intervention à nos collaborateurs. Aliados était à la recherche d’un partenaire sérieux mais audacieux depuis plusieurs mois, avec l’équipe Rhapsodies nous sommes désormais parés pour faire face à une forte demande dans le domaine bancaire et des interventions de transformation des SI.» déclare Lionel Andreu, Fondateur d’Aliados Conseils.
« Le Rapprochement avec Aliados Conseils représente une étape importante dans notre stratégie de croissance et affirme notre position sur nos segments de marché. Par l’apport d’expertises complémentaires, ce rapprochement nous permet de proposer une offre complète autour des Risques, du Réglementaire et de la Conformité, laquelle améliore encore notre proposition de valeur pour procurer à nos clients compétences et capacités d’innovation dans ce domaine hautement stratégique à l’ère numérique. » déclare Olivier Barthélemy, Président de Rhapsodies Conseil
A propos d’Aliados Conseil Aliados Conseils est un cabinet de conseil spécialisé en Corporate Finance, Cash Management, Capital Market, Regulatory Reporting, Risk – Ratios. Basé à Paris, Aliados Conseils fournit aux directions financières et aux lignes métiers des établissements Private Banking, Middle Banks et Corporate internationaux, les compétences d’experts indispensables aux exigences réglementaires et commerciales.
A propos de Rhapsodies Conseil Rhapsodies Conseil, cabinet indépendant de conseil en management créé en 2006, accompagne les programmes de transformation stratégiques de ses clients et leur mise en œuvre opérationnelle dans 3 pôles d’expertise choisis :
Architecture & Transformation,
Expertise Paiements & Risques,
Sourcing & Performance Economique.
Forts de nos 80 collaborateurs et de notre large expérience, nous intervenons au quotidien auprès des Grands Comptes dans différents secteurs d’activité, banques, assurances, industrie, luxe…
Le service Cloud d’Amazon, AWS, a été victime récemment d’une panne majeure de son service de stockage simple nommé S3. Cette brique technique est très populaire et répandue pour implémenter des applications ou services hébergés chez AWS. Pour vous donner une idée de l’ampleur de son utilisation depuis son lancement en 2006, ce service permet aujourd’hui de stocker des dizaines de milliards d’objets. D’autres briques techniques chez Amazon peuvent s’appuyer sur ce stockage pour fonctionner comme le service Elastic Compute (EC2), Elastic Block Shop et Lambda. Cette panne de service a eu donc pour effet d’engendrer des perturbations majeures pour plusieurs applications hébergées chez AWS :
La messagerie instantanée Slack
Le service de stockage en ligne Box
Le service de livraison des pizzas Dominos
Les sites web communautaires Reddit et BuzzFeed
Heureusement la cause de l’incident a vite été repérée et corrigée par l’hébergeur. En revanche, elle a tout de même engendré des indisponibilités de plusieurs heures pour certaines de ces applications. Est-ce que les entreprises ayant pris la décision de faire appel à du Cloud Public doivent pour autant entrer en mode panique et rapatrier leurs applications et données chez eux ? La réponse est NON bien entendu. Amazon a rapidement communiqué que la nature de la panne du service S3 était due à une erreur humaine déclenchée par un employé ayant toutes les autorisations et qui aurait soumis une commande manuelle avec de mauvais paramètres. De plus, l’impact de la panne se limitait uniquement au « datacenter » de la région Virginie située sur la côte Est des Etats-Unis. Une telle erreur aurait pu donc se produire n’importe où, chez n’importe quel fournisseur d’hébergement y compris dans vos propres « datacenters ».
Cet incident nous rappelle seulement qu’il ne faut pas se fier uniquement à la résilience de la couche infrastructure Cloud, même chez le leader du marché, pour garantir une haute-disponibilité. Il est bon de rappeler ici que les engagements de service (SLA) pour la brique S3 ne sont que de 99,99%. Ceci signifie tout de même une indisponibilité potentielle de 87,5 heures pour une année ! Le fournisseur de service de vidéo en ligne Netflix est aussi hébergé chez AWS et il a pourtant été épargné par la panne du service S3. Une étude réalisée en interne en 2014 avait permis d’estimer une perte de 200 000$ de chiffre d’affaires pour une heure d’arrêt de la plateforme. Nous pouvons donc estimer qu’en 2017 le coût total d’une panne de 4 heures aurait pu leur coûter plus d’1 million de dollars. Ceci est sans compter l’impact négatif sur la réputation et image auprès de leurs usagers qu’une telle panne aurait pu occasionner . En tenant compte de ces besoins, les architectes techniques de Netflix ont conçu une architecture cloud résiliente basée sur plusieurs zones AWS. Ceci leur permet donc d’éviter toute perte de service en cas de panne ou incident et d’avoir un meilleur SLA que les 99,99% promis par le fournisseur.
L’impact financier de l’arrêt de votre application métier est probablement moindre que celui de Netflix. Vous n’avez peut-être pas non plus un fournisseur Cloud ayant plusieurs « datacenters » dans différentes régions comme peut l’offrir AWS. Pour autant déployer vos applications sur du Cloud Computing ne vous affranchit pas du tout des services d’un architecte technique, au contraire ! Celui-ci, s’il déroule une démarche prenant compte des besoins métiers et des exigences non fonctionnelles, saura vous proposer des scénarios d’architectures résilientes. L’architecture finale sera plus chère et complexe sans doute. Il ne faut pas oublier dans ce cas d’estimer l’impact et la probabilité d’une perte de service avant d’évaluer si ces coûts supplémentaires en valent la chandelle.
Sources d’information pour incident AWS S3 survenu en mars 2017 :
Déployer des applications Saas sur Cloud Public est devenu très populaire chez certaines Directions Métiers en France. Tout ceci pourrait être amené à changer avec la nouvelle directive Européenne (GDPR) sur la protection des données personnelles qui entrera en vigueur en 2018. En effet cette réglementation exige une très forte gouvernance des fournisseurs hébergeant ces données. Le risque de recevoir une pénalité de 4% de son chiffre d’affaire mondial en cas de non-conformité pourrait donc inciter certaines Entreprises à demander à leur DSI de reprendre l’initiative.
Ce n’est donc pas un hasard de calendrier si l’ANSSI (Agence Nationale de la sécurité des systèmes d’information) a créé conjointement avec son homologue allemand (BSI) un nouveau label nommé European Secure Cloud (ESCloud). Une première version du référentiel des exigences a été publiée en décembre 2016. Elles couvrent les aspects suivants :
Mener une politique de sécurité en regard d’analyse de risques. Celle-ci devant être faite périodiquement pour une même application.
Avoir un responsable de sécurité de l’information, un responsable de la donnée personnelle et un responsable de la sécurité physique de ses installations.
Avoir un plan de sensibilisation à la sécurité au niveau ressources humaines : charte éthique, formation, gestion et capitalisation de la connaissance.
Avoir une politique de contrôle et droits d’accès pour ses bâtiments et certaines zones plus sensibles.
Avoir une cartographie de son SI au niveau infrastructure à jour.
Encrypter les données sensibles et chiffrer les flux. Hacher les mots de passes pour ne pas qu’ils soient accessible en clair.
Avoir une politique de sécurité pour prévenir et surveiller les failles: journaux d’évènements horodatés, analyse du code source si possible, tests d’intrusion fréquents, …
Avoir une politique de gestion des incidents de sécurité y compris de manière préventive.
Avoir une convention et un respect des engagements avec les sous-traitants participants à la mise en œuvre du service.
Garantir une localisation, un traitement des données et une gestion des opérations du datacenter au sein de l’Union Européenne.
Autoriser un organisme certifié par l’ANSSI à venir l’auditer et vérifier le respect de ses exigences.
Pour ceux qui douteraient de l’importance d’avoir un fournisseur de confiance, voici quelques chiffres 1 :
81% des entreprises françaises se sont dit victimes d’une cyberattaque en 2015.
Se remettre d’une violation de sécurité coûte en moyenne 800 000€.
9 semaines sont nécessaires en moyenne pour corriger une faille de sécurité.
35% des incidents de sécurité auraient été généré (parfois malgré eux) par les collaborateurs de l’hébergeur de ces données.
La plupart de ces exigences étaient déjà incluses dans les principales normes de sécurité reconnues par le marché : ISO-27001, SOC1, SOC2, CSA-CSM. L’effort à fournir pour obtenir ce label (GDPR) est donc faible pour les fournisseurs qui avaient déjà obtenu les principales certifications. C’est cependant une bonne chose d’avoir créé un label Européen pour rassurer les entreprises du vieux continent. En effet, que veulent les Directions Générales et les DSI ? Avoir l’engagement que le fournisseur de l’hébergement pourra assurer la sécurité de leurs données et que celles-ci ne vont pas se retrouver aux mains d’un concurrent, d’un gouvernement étranger ou d’une organisation malveillante. Ces entreprises veulent maîtriser le droit d’accès à ces données et ont besoin de partenaires qui accepteront d’être transparents et de partager la responsabilité de conformité sur la protection des données.
Au moment où nous rédigeons ces lignes, seuls 3 fournisseurs de services cloud ont fait la demande du label. Cependant il est fort à parier que tous les principaux acteurs du marché tenteront à moyen terme de décrocher ce précieux Graal qui leur facilitera l’accès au marché des entreprises européennes. Les entreprises françaises utilisaient jusqu’à maintenant très peu le Cloud et principalement pour du stockage ou des services de messagerie en mode SaaS. La plupart d’entre elles mettaient en avant les risques liés à la sécurité comme frein à son utilisation. L’obtention de ce nouveau label Européen est donc un pas en avant pour permettre de gagner la confiance des décideurs.
Pour conclure, il est fort à parier que nous devrions observer une hausse de part de marché des offres IaaS et PaaS sur Cloud Privé et voir une baisse de celui sur Saas déployé sur Cloud Public. Les DSI n’ont plus d’autre choix que de reprendre le contrôle de ces environnements. La part de « Shadow IT » dans les entreprises devraient donc diminuer aussi significativement. Le risque de recevoir une pénalité de la CNIL étant trop grand en cas de non-conformité à la GDPR.
1 : D’après l’article « Cybersécurité : Cinq chiffres clés à connaître »
Les autres articles qui peuvent vous intéresser
Développer le leadership en agissant à contre-courant des usages traditionnels
Développer le leadership en agissant à contre-courant des usages traditionnels
Je suis intervenu le 10 octobre dans une grande banque française à l’occasion de leur « Agile Day » annuel. On m’a demandé d’intervenir sur l’impact de la transformation agile sur le management.
Mon constat est que la transition managériale dans les grands programmes de transformation agile n’est pas efficace. Ce constat commence à être partagé et mes réflexions m’ont amené à identifier une approche différente de celle traditionnellement mise en œuvre.
Pour développer les Hommes, travaillez sur l’environnement en premier
Quand vous souhaitez amener une entreprise vers un leadership plus agile, il ne suffit pas de décréter qu’elles doivent devenir agiles. Il est nécessaire de rénover le système, qui dans la quasi-totalité des cas, n’est pas compatible en l’état.
Supprimer les silos entre les métiers, les équipes de développement et les équipes de production (approche que j’appelle BIZDEVOPS) est une première étape d’une transformation agile. Modifier les mécanismes contre-productifs, comme les systèmes d’objectifs orthogonaux entre DEV et PROD par exemple, devrait être l’étape suivante. On peut même imaginer une gouvernance d’entreprise basée sur une information transparente, fraîche et honnête, générant des prises de décisions décentralisées et efficaces.
Pour travailler sur le système, vous pouvez démarrer par :
identifier clairement et communiquer beaucoup sur la vision de l’entreprise : son but, sa raison d’être. Finalement, le rôle du dirigeant pourrait se résumer à cela : répéter encore et encore la raison d’être de l’entreprise. C’est d’ailleurs une constante dans les organisations « libérées » qui surperforment dans leurs domaines d’activité.
décentraliser les prises de décisions en donnant plus d’autonomie. Cela signifie en corollaire de garantir un accès transparent à l’information, de développer les compétences, de bâtir des interactions basées sur la confiance mutuelle et de donner le droit à l’erreur dans une approche « fail fast, learn fast ».
Former n’est pas assez
Une fois la prise de conscience et les modifications réalisées au niveau de l’organisation, accompagnez vos managers dans le changement nécessaire de posture. Car en modifiant l’organisation et les interactions entre les différentes parties prenantes, l’impact sur le manager est plus important qu’il ne pourrait y paraître. J’ai déjà rencontré des chefs de projets qui venaient se plaindre de l’agilité parce que leurs équipes parlaient désormais directement avec le Product Owner pour la priorisation des sujets, alors que c’était leur prérogative quelques mois plus tôt.
D’une approche où le manager est traditionnellement un sachant promu pour sa compétence technique (et pas forcément sa compétence en leadership !), nous évoluons vers une approche où le manager s’oriente plutôt vers une posture d’hôte (Host Leadership) ou de coach, avec comme objectif de faire émerger de nouveaux leaders dans son équipe.
Plutôt que d’envoyer les managers en formation pour leur apprendre des recettes qu’ils ne pourront/sauront pas appliquer dans la plupart des cas, préférez un accompagnement sur le terrain. La formation peut être envisagée comme un apport complémentaire si nécessaire et dans un second temps. Le coaching des équipes et des individus amène des résultats bien plus probants car les acquis sont ancrés dans le concret, et surtout, l’apport régulier du coach sécurise la montée en compétences opérationnelle. L’expérience du coach va aussi aider à gérer des situations délicates qui ne manqueront pas d’arriver, et également à identifier les ajustements nécessaires aux modifications réalisées sur le système, dans une approche d’amélioration continue.
En tant qu’architecte d’entreprise, l’agilité fait partie intégrante de ma vie et des projets depuis déjà quelques années. Mais qu’il est difficile de s’y retrouver dans tout ce qui est, ou se prétend, Agile. Alors comme tout bon architecte d’entreprise, j’ai commencé par faire un état des lieux : une cartographie.
Attention : ici je ne parlerai pas de technologies (chaque chose en son temps) mais bien de méthodes et d’approches.
Agilité, vaste monde !
L’agilité tout le monde en parle mais qui en fait vraiment ? De quelle agilité parle-t-on ? De méthodes Agile ? Plutôt que méthode, les termes utilisés sont plutôt culture, approche, mouvement ou courant Agile. L’agilité est mise à toutes les sauces : pour faire de l’innovation, de la gestion de projet, des modes de déploiement mais aussi pour le management d’entreprise.
Et l’agilité s’appuie sur des techniques plus anciennes comme le Lean, qui intègre Kanban et Kaizen.
Certains ont imaginé une carte de l’ensemble des pratiques Agile (voir ci-dessous) ressemblant au métro de Londres. J’avoue qu’avant j’étais un peu perdu, maintenant je suis complètement noyé !
Donc afin de simplifier et de présenter les pratiques d’un point de vue « Externe » à l’agilité, j’en propose une autre :
4 catégories pour s’y retrouver :
Le niveau entreprise : l’agilité a pour vocation de conquérir toute l’entreprise et de proposer de nouveaux modes de management
L’innovation : comment s’organiser pour trouver des solutions innovantes, des produits adaptés aux utilisateurs ?
Equipes et Projets : le Manifeste Agile et la méthode Scrum notamment rentrent dans cette catégorie, pour les projets de petite et moyenne taille. Utilisables par tous les projets mais surtout appliqués dans les projets IT à ce jour
Build et Opération: ensemble des méthodes et des techniques permettant d’implémenter dans le SI les produits délivrés par les projets
En parallèle, une catégorie « Techniques et Ateliers » est identifiée pour rassembler l’ensemble des techniques d’animations proposées dans le cadre de l’agilité et définir leur utilité.
Nous avons choisi de présenter ces 4 catégories dans un ordre qui part de l’innovation, puis des équipes et projets pour aller vers l’implémentation de leurs produits dans le SI en finissant par le déploiement de ces approches au niveau de l’entreprise.
L’innovation
Avec les nouvelles technologies et les nouveaux usages, sont apparues des techniques permettant de faire émerger l’innovation. Ces techniques mettent au centre de ces approches les utilisateurs des futures solutions et produits. Ces démarches sont souvent itératives et donc correspondent bien à la gestion des projets en agilité.
L’apport de ces démarches est de « se mettre à la place de ». Le concepteur de solution doit apprendre à penser comme la personne pour laquelle il doit bâtir une solution. Tous les concepteurs ou les MOA se sont plaints un jour que « le métier » ou « le client » ne savait pas exprimer son besoin. Le problème se résout de lui-même avec ces techniques. Basées sur les interactions avec les futurs utilisateurs, les personnes dont le métier est de concevoir peuvent comprendre voire anticiper leurs attentes.
L’innovation ne peut pas être encadrée ou commandée. Des principes d’innovation et les conditions pour créer de l’innovation peuvent être identifiées et donc mis en place rapidement pour sortir des anciens modes de conceptions de solution.
Méthodes et approches : Human-centered design, Design Thinking, Innovation game
Equipes et projets
Un changement de paradigme complet dans la manière de gérer les projets est apparu avec les approches Agile. SCRUM est la méthode de gestion de projet Agile la plus connue mais il en existe d’autres.
Cette approche a radicalement changé la manière de conduire des projets, le traditionnel « cycle en V », et de produire des résultats. On avance par itération, par incrément. Finis les effets tunnels. Les résultats sont rapidement concrétisés et il est possible de réagir au fur et à mesure.
Les projets en mode agile permettent d’adapter les produits au fur et à mesure de l’avancement du projet et de la réflexion.
Ces approches ont apporté de grands changements dans les méthodes de travail avec des réunions plus courtes mais plus fréquentes (tous les matins !), du management visuel, des capacités d’adaptation et d’auto-organisation qui sont à l’inverse des habitudes de management des anciens projets et de tous leurs travers.
Mais surtout ces approches ont entamé une révolution culturelle car elles font travailler ensemble de manière régulière et rapprochée des équipes, des spécialités qui ne se côtoyaient que peu ou rarement. Ces différents métiers ne se comprenaient pas ou mal. Les faire collaborer est toujours un challenge mais qui conduit à des résultats très concrets.
Méthodes et approches : Scrum, eXtreme Programming, Rapid Application Development, Domain Driven Design, Disciplined Agile Delivery, Dynamic systems development method (DSDM), Crystal Clear, le Manifeste Agile
Build et opération
Un des principes des projets en agilité est de pouvoir livrer régulièrement des incréments de valeur. Le but premier est de pouvoir tester ces incréments au fur et à mesure et de vérifier qu’ils satisfont l’utilisateur final. Dès lors, ces produits partiels (fonctionnels) peuvent être mis en production sans attendre la fin de l’ensemble des sprints.
Encore faut-il que le SI soit prêt à supporter ces mises en production régulières. Il est nécessaire de mettre en place des usines logicielles permettant de produire, tester, mettre en production et maintenir en fonctionnement les produits dans les meilleurs délais. Pas question d’attendre plusieurs semaines ou mois avant de mettre en production un produit prêt.
Les phases de validation, tests, recettes, peuvent être très consommatrices de temps. Elles doivent donc être anticipées et automatisées au maximum pour atteindre une vraie industrialisation. Les gains de temps et de qualité atteints grâce aux équipes et projets ne sont ainsi pas perdus dans les étapes de tests et de mise en production.
Les équipes IT ont mis en place des stratégies qui permettent, dès le début des projets, de prévoir ces futures étapes. Les tests sont identifiés dès le départ et sont automatisés. On parle d’intégration continue, de déploiement continu, de livraison continue.
Et une fois les produits en production, il faut les maintenir et les exploiter. L’approche DevOps (qu’on peut définir en quelques mots par l’agilité pour les opérationnels) devient de plus en plus utilisée aujourd’hui. Cette approche illustre bien le passage sans heurt de la conception des solutions vers leur mise en production et leur exploitation. Les équipes d’opération et de développement travaillent ensemble, et non plus en campant sur leurs positions respectives : « je n’ai pas les documents pour assurer la maintenance », dixit la maintenance, « je ne sais jamais quels documents ils veulent », dixit les développeurs.
Méthodes et approches : Le test-driven development (TDD), Behavior Driven Development (BDD), Continuous delivery, Continuous deployment, Mikado Method, devops
Le niveau entreprise
Faire travailler des équipes en mode agile suppose de la responsabilisation et de l’autogestion. Le reste de l’entreprise, et notamment le management, ne peut continuer à fonctionner comme avant au risque d’être contre-productif.
En agile, c’est l’équipe (via notamment le Product Owner) qui est responsable de son produit, le rôle du manager n’est plus alors de décider ce qui doit être fait.
Le manager change de rôle et c’est un vrai changement culturel. Les hiérarchies actuelles n’ont pas du tout été formées à ces approches. Le manager devient un facilitateur, celui qui met dans les bonnes conditions, c’est aussi un vrai relai d’information dans les 2 sens (vers l’équipe mais aussi vers le reste de l’entreprise).
Comme tout changement, il entraine des pertes de repère, de la résistance au changement et donc il doit être maitrisé et accompagné. Plusieurs méthodes, modèles et approches démontrent les bénéfices que l’on peut en tirer sans en nier les difficultés.
Méthodes et approches : Agilité à l’échelle (SAFe, LeSS, Spotify, Nexus), Management 3.0
Les ateliers
Un des principes fondateurs de l’agilité est la co-construction. A ce titre de nombreux types d’ateliers de travail existent. Ils ont pour but de faire réellement travailler ensemble les personnes au sein des équipes, de développer les « softskills » (compétences humaines) mais aussi produire des résultats : produits, plannings, études d’impacts etc. Le nombre d’ateliers et de variantes est infini, même si environ une quarantaine de techniques d’animation se détachent. Nous proposons un regroupement sur 8 thématiques :
Icebreaker : idéal pour se lancer quand les gens ne se connaissent pas ou peu.
Intelligence collective : démontrer la force de la collectivité mais aussi ses manières particulières de fonctionner
Planification (et volumétrie) : construire ensemble des plannings, faire des estimations
Définition de cible : vers où voulons nous aller ensemble, qu’est-ce qu’il est réaliste de proposer ?
Impacts et trajectoire : comment aller vers la cible, quels sont les impacts des changements proposés ?
Priorisation des travaux : décider ensemble de ce qui est prioritaire
Conception de produit : orienter vers l’innovation et la recherche de solutions
Team building : construire des équipes qui savent travailler ensemble et communiquer efficacement
Ces ateliers peuvent être utilisés individuellement mais surtout en combinaison pour atteindre encore plus rapidement et efficacement l‘effet recherché. La durée varie de 15mn à 3j.
Intenses et efficaces, ces ateliers permettent de débloquer des situations et de remettre du lien dans des équipes, de les remotiver pour leur travail : un icebreaker, puis un teambuilding avant de faire de l’innovation et de la priorisation. Le tout en une journée. L’équipe en ressort non seulement remotivée mais surtout avec des résultats concrets et directement utilisables dès le lendemain
Une fois ce paysage posé, l’agilité peut effectivement être identifiée un peu partout dans l’entreprise.
Les architectes d’entreprise en tant que garants de la vision d’ensemble du SI doivent accompagner ce mouvement et y prendre part. Plusieurs niveaux vont être abordés dans notre série « Architecture d’entreprise et Agilité » :
Chapitre 2 : détournement de valeur. Toutes les fausses ou contre-vérités entendues à propos « des projets Agile »
Chapitre 3 : comment l’architecte d’entreprise peut aider à concevoir et entretenir un « SI Agile »
Chapitre 4 : comment les architectes d’entreprise (mais aussi les autres) peuvent interagir avec les projets en agilité.
Les autres articles qui peuvent vous intéresser
L’industrialisation des paiements européens : un long chemin déjà parcouru
L’industrialisation des paiements européens : un long chemin déjà parcouru
Les banques, sollicitées par la Commission européenne et la Banque Centrale Européenne, ont été les maîtres d’œuvre des nouveaux moyens de paiements dont le cahier des charges était à construire sous la surveillance du régulateur européen.
L’ambition de créer un espace unique de paiement en euros est venue s’ajouter aux nombreux défis du vaste projet qu’est la construction de l’Union Européenne. Elle s’insère entre la volonté d’un marché européen libre et concurrentiel – notamment dans le domaine des paiements – et la construction de la zone euro.
Les banques, sollicitées par la Commission européenne et la Banque Centrale Européenne, ont été les maîtres d’œuvre des nouveaux moyens de paiements dont le cahier des charges était à construire sous la surveillance du régulateur européen.
Bien que certains aspects restent à améliorer, le SDD et le SCT sont harmonisés, automatisés, plus simples, plus rapides et moins chers.
Tout au long de cet article, nous reviendrons sur les différentes phases de construction des premiers paiements européens, ainsi que les défis à venir, à savoir :
la création de l’EPC,
l’harmonisation des messages de paiement sur un standard ISO,
de nouveaux services proposés par les chambres de compensation au niveau de chaque Etat et au niveau Européen,
les organes de gouvernance,
les prochains défis qui restent à relever.
La création de l’EPC, organe pan européen pour la conception et le suivi de la mise en œuvre des paiements SEPA
Les établissements bancaires ont créé un organe autorégulateur commun – l’EPC – composé de collaborateurs des différentes banques de l’Union Européenne, facilitant ainsi le travail collaboratif et la communication avec la Commission et le Parlement Européen.
Un des premiers livrables de l’EPC a été de spécifier les opérations bancaires et leurs règles homogènes à appliquer au sein de l’espace SEPA.
Les principales caractéristiques structurantes du SEPA qui en découlent sont:
Un cycle de vie des opérations avec un début et une fin
Jusque-là, en France, une opération pouvait faire l’objet de plusieurs échanges (effet ping-pong : émission, rejet, rejet du rejet, rejet du rejet du rejet, OCR/ODR voire AOCT). Cet aspect a d’ailleurs affecté les opérateurs français qui ont eu des difficultés à supprimer ces usages (ex. : rejet du rejet Minos sans R-Message équivalent).
La définition claire des rôles et périmètres des acteurs : A titre d’exemple, dans le cas du SDD, ce n’est plus aux banquiers qu’incombe la responsabilité du débit au compte de son client. En effet, le client ne communique plus à sa banque les autorisations de débit par un tiers identifié par un NNE (numéro national d’émetteur), mais signe un mandat de prélèvement auprès de son créancier qui a ensuite l’obligation de le stocker et d’apporter la preuve en cas de contestation.
L’harmonisation des messages sur un standard ISO
Une fois le modèle SEPA construit, l’EPC a demandé à Swift de travailler sur l’adaptation du standard ISO 20022 pour supporter les échanges des messages de paiement de la zone euro. Cette norme s’appliquait déjà à d’autres domaines tels que titres et les fonds et le commerce international.
Le standard ISO 20022 a pu être adapté au cycle de vie défini pour les opérations SEPA, en raison de la méthode de modélisation des échanges de données à partir des processus métier.
Par ailleurs, il a été décidé d’adopter la syntaxe XML, notamment par SWIFT qui l’avait choisie dès 1999 puisque considérée plus souple, facile à maintenir.
Des nouveaux services proposés par les chambres de compensation
D’un point de vue macro, la solution retenue a été de capitaliser sur l’expérience ABE, chambre de compensation pan européenne, via l’ouverture d’un nouveau service (STEP2) pour les paiements de masse en euros échangés entre banques des différents pays de la zone SEPA ou à l’intérieur d’un même pays.
D’un point de vue micro, il a été nécessaire que chaque partie prenante (banques, éditeurs, gros remettants, chambres de compensation…) reconsidère ses infrastructures de paiements afin d’éliminer les différences nationales au niveau des technologies de l’information et des dispositions commerciales utilisées par les systèmes de paiement de chaque pays membre de la zone SEPA.
Dans le cas des CSM nationaux, comme CORE en France, des travaux d’adaptation ont été menés sur les systèmes d’information, dans l’objectif de permettre l’acquisition et la restitution des paiements SEPA entre banques du même pays uniquement.
Finalement, chaque participant direct est libre d’adhérer aux services (dès lors qu’ils sont proposés dans le pays où l’opération est échangée) et aux CSM de son choix. A partir du moment où ils y ont souscrit, leur BIC est atteignable pour un service donné.
Les organes de gouvernance
Le principe d’autorégulation qui caractérise la mise en place du SEPA par les banques n’a pas suffi et a nécessité une intervention normative par le législateur européen pour dynamiser l’avancement du projet.
Aussi, les règlements relatifs aux dates butoirs de 2012 ont permis de donner un caractère obligatoire à la migration des paiements nationaux vers le SEPA. De plus, ils ont mis fin à la période de transition où les dispositifs de chaque Etat cohabitaient avec les nouveaux moyens de paiement.
Ensuite la création d’un organe de gouvernance pan-européen, le Conseil SEPA, est venu renforcer le mécanisme. Il a permis une implication plus formalisée des représentants de haut niveau. En effet, cet organe est coprésidé par des représentants de la Commission européenne et de la Banque Centrale Européenne. Depuis, le conseil SEPA a été remplacé par l’Euro Retail Payments Board, présidé par la BCE et composé des représentants du marché des moyens de paiement, du côté de l’offre et de la demande.
Au niveau national, chaque Etat s’est doté d’un comité national pour coordonner au niveau de chaque pays les différents acteurs. En France, le Comité national SEPA a coordonné la migration, conjointement avec la Banque de France et la Fédération Bancaire Française.
Les prochains défis à relever
Plusieurs sujets sont à l’ordre du jour, en commençant par la nécessité de réaliser des économies d’échelle pour rentabiliser les investissements.
A titre d’illustration, depuis 2013, STET, société française, est devenue l’opérateur de paiement de la communauté bancaire Belge, mutualisant l’infrastructure.
Au-delà, il convient à court terme de :
Mieux gérer les codes rejets qui sont aujourd’hui mal appréhendés par les utilisateurs,
Clarifier un certain nombre de règles opérationnelles,
Maintenir l’effort d’adaptation des équipes projet : en effet la séquence first du SDD devient facultative à la fin de l’année des améliorations de traitement des R-Messages en insistant sur le STP, débouchant sur une réduction du traitement manuel.
Combattre la fraude aussi bien dans un cadre national mais également européen.
Sans parler des défis posés par la DSP2, de l’instant payment,et du Blockchain, à décrire dans un prochain article.
Glossaire : ABE : Euro Banking Association AOS : Additional Optional Services BCE : Banque Centrale Européenne BIC : Business Identifier Code CORE : COmpensation REtail CSM : Clearing and Settlement Mechanism DSP : Directive des Services de Paiement EPC: European Payments Council ERPB : Euro Retail Payments Board IBAN : International Bank Account Number MINOS : Manuel Interbancaire des Normes d’Opérations NNE : Numéro National D’Emetteur ODR : Operation Débit Rédressement OCR : Opération Crédit Redressement SCT : SEPA Credit Transfer SDD : SEPA Direct Debit SEPA : Single Euro Payments Area STEP2 : Système géré par l’ABE, permettant l’échange d’opérations de masse en euro STET : Systèmes Technologiques d’Echange et de Traitement SWIFT : Society for Worldwide Interbank Financial Telecommunication TIP : Titre Interbancaire de Paiement UE : Union Européenne XML : eXtensible Market Language
