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é ?
Les autres articles qui peuvent vous intéresser
Règlementation risques – Perspectives 2017 au regard du chemin parcouru
Règlementation risques – Perspectives 2017 au regard du chemin parcouru
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 !
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.
Le reporting AnaCredit sera prochainement obligatoire pour chaque institution de crédit d’un pays de la zone euro, cela inclut aussi leurs succursales quel que soit leur lieu d’implantation.
Ainsi, sont concernées :
Etablissement de crédit résident ainsi que leurs succursales étrangères hors zone euro
Les filiales d’établissement de crédits étrangers résidentes
Les succursales des établissements de crédit à condition que celles-ci soient résidentes dans un Etat membre de la zone euro
La déclaration s’effectuera auprès de la banque centrale nationale (BCN) compétente (qui ensuite va transmettre ces données à la Banque centrale européenne).
Par exemple, pour une succursale italienne d’une banque française, les données de la succursale devront être déclarées dans le reporting de l’entité juridique à la Banque de France mais aussi auprès de la Banque d’Italie dans le cadre du reporting de la succursale.
En conséquence, lorsque l’entité juridique et sa succursale étrangère résident dans la zone euro, cela représente une problématique pour les institutions :
Un « Double reporting » certain
Un risque de déphasage des deux déclarations tant du point de vue du nombre de données à fournir (95 données demandées par la BCE mais 79 données après mutualisation au minimum) que sur la qualité de la donnée (Définition différente dans le contenu de certains champs selon le pays. ex : calcul du Forborne)
Afin d’éviter ce « double reporting », la BCE prévoit des possibilités de contournement afin de minimiser ou supprimer cette charge pour des établissements de crédits internationaux :
La Banque Centrale nationale compétente de l’entité juridique pourrait décider de ne pas collecter, ou seulement une partie, des données listées dans le template 1 de l’entité juridique quand ces « instruments » sont détenues par la succursale.
La Banque centrale nationale compétente de la succursale peut décider de ne pas collecter, ou seulement une partie, des données listés dans le template 2 depuis la succursale.
Par ailleurs au niveau français, la Banque de France lance des actions de rationalisation : sur les collectes de succursales zone euro ou des suppressions de duplication entre les données BCBS 239 et AnaCredit (en cours).
D’autres évolutions AnaCrédit à suivre dans nos prochaines publications…
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 :
