L’évolutivité efficace repose sur une planification prédictive et des stratégies de maîtrise des coûts.
L’évolutivité consiste à savoir quand et où la charge arrive, et à mettre en place des systèmes intelligents pour la gérer avant qu’il n’y ait des problèmes. Les plateformes financières telles que Chase.com sont confrontées à des pics imprévisibles, liés à la demande des clients ou à des menaces telles que les attaques DDoS. Dans ces cas-là, vous ne contrôlez ni le timing ni le volume, c’est pourquoi vous avez besoin de flexibilité et de prévoyance dans votre architecture.
L’analyse prédictive joue un rôle majeur à cet égard. En analysant les habitudes des utilisateurs, comme les augmentations de trafic liées à la paie ou les activités saisonnières, vous pouvez allouer des ressources sur la base de signaux réels, et non pas après que le système a commencé à tousser. La mise à l’échelle élastique vous offre une flexibilité à la demande, mais elle n’est pas instantanée. Il faut du temps, parfois quelques minutes, pour mettre les instances sous tension, les connecter aux services dorsaux et leur fournir des réponses. C’est dans ce délai que les choses peuvent se gâter. Pour y faire face, vous avez besoin de ressources de calcul pré-allouées (réservées) pour couvrir les périodes à haut risque. Vous évitez également le chaos qui résulte d’un trop grand nombre de ressources mises en service trop tard.
Le contrôle des coûts est une question plus importante que la plupart des gens ne l’admettent. Le cloud vous offre une puissance et une échelle incroyables, mais si vous ne l’optimisez pas en continu, chaque semaine ou même chaque jour, vous dépasserez rapidement vos dépenses. C’est là que les organisations doivent appliquer une discipline FinOps permanente. La mise à l’échelle pour la résilience doit se faire, mais pas au prix d’une spirale d’opérations financièrement incontrôlables.
La mise en forme du trafic est une autre mesure intelligente. Identifiez les fonctions exactes dont vos utilisateurs dépendent le plus (connexion, soldes, paiements). Concentrez-vous sur la mise à l’échelle des capacités autour de ces fonctions. Ne mettez pas tout à l’échelle de manière uniforme. C’est paresseux et inefficace.
D’après les données de l’article, JPMorgan Chase est régulièrement confronté à des pointes de trafic légitimes qui dépassent de plus de 10 fois le niveau de référence. C’est un défi de taille si votre infrastructure n’est pas réglée pour réagir rapidement et proprement. La mise à l’échelle prédictive et l’optimisation des coûts vous permettent de survivre et de prospérer lorsque la demande est inattendue.
Il est essentiel de ne pas se contenter de dimensionner les serveurs pour gérer les performances des services en cas de stress.
L’ajout de serveurs ne résout pas les problèmes de dépendance. La plupart des dirigeants l’ont déjà appris, souvent à leurs dépens. Si un service backend, peut-être une base de données ou une API interne, commence à prendre du retard, il crée un arriéré. Les fils d’attente s’accumulent, la pression de la mémoire augmente et votre autoscaler se met en marche en pensant que le problème vient de la charge. Il fait donc tourner plus d’instances. Cela augmente la pression sur le même service défaillant et ne résout en rien le problème principal.
C’est pourquoi vous devez construire en pensant à l’échec. Mettez en place des disjoncteurs. Il s’agit de mécanismes légers qui indiquent à votre application : « Si le service n’est pas rétabli dans les X millisecondes, passez à autre chose ». Ne gaspillez pas de threads. Ne surchargez pas les systèmes en attendant une réponse perdue.
En l’absence de disjoncteurs, un seul service dégradé peut entraîner l’ensemble de votre environnement dans sa chute. Il s’agit d’une fuite d’efficacité à l’échelle du système, qui coûte de l’argent en temps d’informatique Cloud, en utilisation des ressources et en expérience client médiocre.
Pour les dirigeants, il s’agit d’un point essentiel : vous n’évoluez pas pour répondre à la demande ; vous évoluez pour masquer la douleur. Les équipes d’entreprise doivent comprendre quand il faut faire évoluer l’entreprise et quand il faut interrompre rapidement les services malsains et se rétablir rapidement ailleurs.
La mise à l’échelle élastique n’est pas intelligente en soi. Elle suit des signaux. Si ces signaux sont causés par des retards de performance et non par la demande réelle des utilisateurs, vous résolvez le mauvais problème. L’architecture basée sur des disjoncteurs permet d’éviter cette erreur coûteuse. Elle limite la consommation inutile de CPU, de mémoire et de bande passante en aidant votre système à savoir quand il doit s’arrêter et se rétablir rapidement. Cette approche permet également d’éviter que les dépendances en aval ne soient inondées en cas de baisse des performances.
Ce qui compte ici, c’est la précision. Travaillez avec les équipes de produits et d’ingénierie pour vous assurer que les ralentissements en aval ne se traduisent pas par des augmentations d’échelle mal informées. Vous voulez des systèmes intelligents, pas réactifs, réactifs, pas aveuglément élastiques.
Une résilience élevée est obtenue grâce à une hiérarchisation de l’infrastructure et à un basculement stratégique.
Tous les systèmes n’ont pas besoin du même niveau de disponibilité. Essayer de tout rendre à l’épreuve des balles n’est pas seulement coûteux, c’est aussi inefficace. Au lieu de cela, décomposez l’infrastructure en niveaux basés sur l’impact. Certains composants doivent toujours être opérationnels. D’autres peuvent tolérer de brefs temps d’arrêt sans perturber le service. Établissez des priorités en fonction de l’impact réel sur l’entreprise.
Par exemple, les services de noms de domaine (DNS) doivent être considérés comme critiques. Si le DNS tombe en panne, rien d’autre n’a d’importance car les utilisateurs ne peuvent pas se connecter. Ces services doivent être conçus pour rester disponibles à tout moment. D’un autre côté, les systèmes de journalisation ou les rapports internes peuvent fonctionner même en cas de panne occasionnelle. Ils ne sont pas en contact avec les clients et n’affectent pas directement les transactions.
La stratégie de cloud de Chase segmente les composants en quatre niveaux : critique, gérable, tolérable et acceptable. Le niveau « critique » peut nécessiter une disponibilité de 100 %. Le niveau « gérable » vise quelque chose comme 99,99 %, soit environ 52 minutes de temps d’arrêt total par an. Les systèmes tolérables s’appuient sur des éléments tels que les sessions en cache ou les jetons, de sorte que les pannes mineures ne sont même pas enregistrées au niveau de l’utilisateur. Les composants acceptables peuvent perdre des données par intermittence sans conséquence.
Les dirigeants doivent s’efforcer d’aligner le budget et les ressources d’ingénierie sur ces niveaux. Les systèmes critiques bénéficient d’une redondance et d’un basculement complets. Les systèmes acceptables bénéficient d’un soutien plus léger. Cette approche permet de maintenir une résilience élevée sans dépassement de budget ou d’ingénierie. Elle permet également aux équipes de se concentrer : elles savent ce qui doit rester disponible quoi qu’il arrive et ce qui peut attendre.
L’aptitude au basculement est importante à tous les niveaux. Les systèmes doivent détecter rapidement les problèmes et y répondre sans attendre l’intervention de l’homme. Qu’il s’agisse d’un réacheminement automatisé du trafic, de services de secours à chaud ou d’une réplication d’une région à l’autre, le basculement doit être décisif et fiable. Mais il n’est pas nécessaire de tout faire basculer. Certaines défaillances sont acceptables. Les dirigeants doivent savoir clairement ce qui est acceptable, avant qu’un problème ne survienne.
La performance est directement liée à l’expérience de l’utilisateur et à la rentabilité.
La rapidité est essentielle. Les clients attendent des résultats instantanés. Ils n’attendent pas et ne tolèrent pas les retards, surtout sur mobile. Une expérience lente n’est pas seulement une source de frustration, elle pousse les utilisateurs à se tourner vers la concurrence. Pire encore, elle vous oblige à dépenser davantage en infrastructure pour tenter de répondre aux attentes des utilisateurs qui auraient pu être satisfaites grâce à de meilleurs choix architecturaux.
L’optimisation des performances est bénéfique pour les clients et permet d’économiser de l’argent. Lorsque les transactions s’effectuent plus rapidement, l’infrastructure est utilisée moins longtemps, ce qui se traduit par une réduction des coûts d’exploitation. Cela permet également de réduire l’encombrement cumulatif du trafic au sein de votre plateforme. La solution n’est pas simplement d’avoir des serveurs plus grands, mais une diffusion plus intelligente : héberger le contenu à proximité des utilisateurs, mettre en cache de manière agressive, n’impliquer les serveurs d’origine que pour les opérations qui en ont vraiment besoin.
Chez Chase, ces stratégies de performance ont permis de réduire la latence de 71 % entre le test initial et le déploiement complet. Il ne s’agit pas d’un gain mineur. Il s’agit d’un avantage structurel. Le contenu a été déchargé vers des systèmes périphériques (points de présence) capables de gérer des réponses statiques à proximité des utilisateurs. Les serveurs d’origine se sont alors concentrés exclusivement sur les opérations critiques, la connexion, les paiements, les soldes, où les données doivent être en temps réel.
L’emplacement a une grande importance. Si vous servez des clients internationaux ou nationaux à partir de quelques serveurs centraux, ils attendent. Rapprochez les données grâce à une distribution géographique intelligente. Les actifs mis en cache sur ces sites périphériques se chargent en moins de 100 millisecondes, alors que les appels d’origine peuvent prendre plus de 500 millisecondes. Multipliez cela par des millions d’interactions avec les clients, et l’avantage est évident.
Google et les autres moteurs de recherche récompensent la rapidité des sites. Elle influe sur le classement. Les sites plus rapides attirent davantage l’attention, suscitent plus d’engagement et améliorent la confiance. Pour les mobiles, qui sont plus sensibles au décalage du réseau, il est essentiel d’optimiser l’utilisation de la mise en cache locale, de l’extraction préalable de la configuration et de la réduction du temps d’installation.
Pour les dirigeants, il ne s’agit pas d’une décision technique. Il s’agit d’une stratégie fondamentale en matière d’expérience client, qui se traduit par des avantages directs en termes de coûts d’infrastructure. Des expériences plus rapides permettent de fidéliser les clients et la fidélisation est l’un des leviers de croissance les plus rentables qui soient.
Une stratégie architecturale reposant sur cinq piliers permet de fournir des services robustes et évolutifs.
Les déploiements à grande échelle exigent une stratégie et non une improvisation. L’architecture cloud de Chase s’articule autour de cinq piliers fonctionnels, le déploiement multirégional, l’optimisation des performances, l’automatisation, l’observabilité avec des capacités d’autoréparation et une sécurité robuste. Ce ne sont pas des mots à la mode. Chacun d’entre eux conduit à une échelle prévisible, à une grande fiabilité et à un contrôle opérationnel.
Le déploiement multirégional garantit que même si l’infrastructure tombe en panne dans une zone, l’accès des clients reste ininterrompu ailleurs. Les systèmes à haute performance traitent plus de transactions par seconde en utilisant moins d’infrastructure. L’automatisation élimine les erreurs humaines et accélère le déploiement et la réponse. L’observabilité permet de détecter et d’isoler les problèmes à un stade précoce. La sécurité protège l’intégrité, les données et la confiance des clients dans l’ensemble de l’environnement.
Cette structure donne de la clarté aux équipes. Elles n’ont pas à se demander ce qui compte le plus ou si les principes s’appliquent de manière incohérente d’une application à l’autre. Ces principes établissent des modèles de conception, et non des améliorations optionnelles. Pour les dirigeants, cela élimine une grande partie du bruit opérationnel. Les équipes n’expérimentent pas ; elles suivent une stratégie claire au niveau du système, étayée par des méthodes éprouvées.
La mise en œuvre de ce modèle à cinq piliers implique d’investir là où cela compte. Chaque système n’a pas besoin de la même profondeur dans les cinq domaines, mais chacun d’entre eux doit faire partie du tableau d’ensemble. Vous vous concentrez sur l’automatisation pour accélérer les livraisons à grande échelle. Vous utilisez l’observabilité pour détecter et atténuer les problèmes immédiatement. Vous mettez en œuvre des stratégies de performance pour répondre aux demandes des utilisateurs sans dépassement de budget. Enfin, vous ne faites jamais de compromis sur la sécurité, quelle que soit l’évolutivité ou la rentabilité d’un système.
Ces cinq domaines, correctement mis en œuvre, permettent de réduire les temps d’arrêt, de diminuer les coûts et de soutenir des systèmes qui s’adaptent au trafic réel, et non aux conditions d’essai.
L’architecture multirégionale est la clé de la tolérance aux pannes, mais elle introduit de la complexité
Le déploiement multirégional permet aux services de continuer à fonctionner en cas de problèmes locaux ou régionaux, mais il introduit également une réelle complexité opérationnelle. Cette complexité doit être abordée directement, car le fait de ne pas planifier l’orchestration augmente le risque de défaillances en cascade ou de routage inapproprié.
Dans la pratique, cela signifie gérer des composants redondants à travers les régions et s’assurer que les changements sont synchronisés. Le DNS devient plus qu’une simple consultation, il est au cœur de la manière dont les systèmes résilients acheminent le trafic. Différents équilibreurs de charge dans différentes régions doivent refléter le temps de fonctionnement de leurs propres services, mais aussi la santé en aval. Si un service dans une zone spécifique tombe en panne en interne (par exemple, l’application fonctionne mais la base de données derrière elle ne répond pas), le trafic pourrait continuer à circuler vers une zone en panne à moins que les contrôles de santé ne soient intégrés correctement.
Chase, par exemple, utilise des sondes de préparation et de vivacité non seulement pour mesurer l’état de l’application, mais aussi pour inclure la santé de ses dépendances, des systèmes dorsaux, des caches ou des API. Ces informations sont transmises en boucle au DNS et aux équilibreurs de charge, ce qui permet de prendre des décisions en temps quasi réel sur l’acheminement des utilisateurs. Cette boucle de rétroaction est essentielle pour maintenir le temps de fonctionnement sans acheminer accidentellement les utilisateurs vers des systèmes partiellement opérationnels.
Les défaillances régionales sont différentes. Une région entière peut tomber en panne. Dans ces situations, un système de vérification par impulsion entre en action, des vérifications uniformes toutes les 10 secondes guident les décisions de basculement. La plateforme doit déterminer si elle doit continuer à fonctionner en mode dégradé ou basculer complètement vers une autre région. Et lorsqu’un basculement se produit, le transfert de trafic lui-même peut provoquer des pics de charge ailleurs. C’est pourquoi la préparation au basculement et la planification de la capacité doivent être réalisées de manière préemptive.
Le partage des clients et le maintien de l’état dans les différentes zones est un moyen de limiter les frais généraux liés à la réplication des données. La cohérence régionale reste importante, mais une segmentation minutieuse et la connaissance des services qui ont besoin d’une précision à la milliseconde près vous permettront d’éviter de répéter les mêmes données dans plusieurs régions lorsque cela n’est pas nécessaire.
Pour les décideurs, il s’agit de limiter le rayon d’action et de préserver la disponibilité opérationnelle sans tolérer de duplication ou de complexité inutiles. Les systèmes multirégionaux bien mis en œuvre augmentent la fiabilité. Ceux qui sont mal mis en œuvre augmentent la surface de défaillance. La différence tient à la qualité de la surveillance de chaque région et à la rapidité avec laquelle la détection des défaillances se traduit par une réponse automatisée.
L’automatisation renforce la fiabilité et la cohérence des opérations dans le cloud.
L’automatisation n’est pas facultative à grande échelle. Les processus manuels introduisent des retards, des erreurs et des incohérences, rien de tout cela n’étant acceptable lorsque vous exécutez des plateformes cloud-natives en production. Ce qui compte, c’est une automatisation complète : la construction du code, le déploiement, le provisionnement de l’infrastructure, les contrôles de santé du système et les décisions de routage doivent être intégrés et réactifs.
Chez JPMorgan Chase, l’automatisation a été intégrée directement dans le cadre architectural. Les équipes se déploient à l’aide de modèles basés sur des manifestes qui définissent toutes les configurations et les attentes du système, ce qui permet aux applications d’hériter par défaut de la sécurité, de l’évolutivité et des normes opérationnelles. Cela réduit la variabilité et les problèmes d’alignement entre les équipes. La vraie valeur ici est la cohérence, chaque service se comporte comme prévu dans les environnements de développement, de test et de production.
L’infrastructure est continuellement repensée en tant que mesure de sécurité standard. Cela signifie que les systèmes sont intentionnellement démantelés et reconstruits à des intervalles définis, hebdomadaires ou bihebdomadaires, afin de garantir l’application des correctifs, la correction de la dérive des ressources et l’élimination des anciennes versions du système. Cela permet également d’éliminer l’accumulation de la dette technique avant qu’elle ne devienne un risque réel pour la production.
Le repavage automatisé est chirurgical. Il n’y a pas d’interruption de la circulation. Le trafic est acheminé en douceur, par étapes. Les demandes existantes sont traitées avant que les instances ne soient mises hors service. De nouvelles instances, propres et à jour, sont mises en place. Les cycles de vie sont surveillés. Les déclencheurs d’expiration sont appliqués. Il n’y a pas d’approximation.
L’avantage pour les dirigeants est la réduction de l’exposition. Le repavage permet d’éviter les scénarios dans lesquels des configurations inconnues ou des instances obsolètes créent des vulnérabilités. Cela est directement lié aux performances du système, à la conformité et à la confiance. En intégrant l’automatisation dans le cycle de vie de la plateforme, les équipes peuvent se concentrer sur la logique métier plutôt que sur les opérations, tout en veillant à ce que les normes de sécurité et de fiabilité soient appliquées en permanence, sans avoir besoin d’équipes d’exploitation importantes.
L’observabilité et l’automatisation déclenchée permettent des opérations en temps réel et résilientes.
L’observabilité en soi ne résout pas les problèmes. Les tableaux de bord sont utiles mais insuffisants. Ce qui compte, c’est l’action. Les systèmes doivent détecter les défaillances et s’en prémunir automatiquement, en temps réel, avant que les utilisateurs ne soient affectés. C’est ce à quoi Chase a donné la priorité : une observabilité étroitement intégrée à une automatisation tenant compte de l’état du système.
L’entreprise a mis en place des contrôles de santé en couches qui fonctionnent au niveau de l’application, de la zone, du cloud privé virtuel (VPC) et du routage global. Ces contrôles renvoient des résultats binaires simples « sain » ou « malsain », dérivés de critères sous-jacents complexes tels que la connectivité de la base de données, l’intégrité du cache et la réactivité du service. La simplicité au niveau le plus élevé permet de prendre des décisions de routage rapides et précises.
L’automatisation est intégrée dans la pile d’observabilité. Ainsi, lorsque la latence d’une région augmente au-delà du seuil ou qu’un nœud ne répond plus, les fonctions sans serveur s’exécutent immédiatement. Elles réaffectent le trafic, initient des arrêts ou déclenchent un rééquilibrage de la charge. Si une base de données tombe en panne, un autre processus automatisé gère le changement de réplique. Pas de pause, pas de révision manuelle.
Les défaillances grises, ces problèmes ambigus, parfois intermittents, où les services restent techniquement opérationnels mais se comportent de manière erratique, font également partie du modèle. Les systèmes d’observabilité détectent ces irrégularités et introduisent des données dans les critères de décision qui évaluent l’état des zones et des applications. En fonction de l’impact et des priorités des accords de niveau de service, le trafic peut rester sur place avec des performances dégradées ou être déplacé immédiatement vers des zones plus saines.
Pour les dirigeants, cette intégration directe entre le signal et la réponse est un atout pour la gestion des risques. Elle réduit le délai d’intervention de quelques minutes ou heures à quelques secondes. Elle garantit la continuité sur la base d’une logique définie, et non d’une réaction. Enfin, l’observabilité combinée à l’automatisation déclenchée protège l’expérience de l’utilisateur et les normes de gouvernance sans nécessiter d’intervention humaine excessive, ce qui permet d’alléger et de contrôler les opérations.
La sécurité en couches basée sur les principes de la confiance zéro protège l’écosystème des applications.
La sécurité doit être proactive. Avec les systèmes natifs du cloud, la sécurité ne peut pas reposer sur un périmètre ou une politique unique. Les menaces proviennent de partout, par le biais d’appareils compromis, de vulnérabilités logicielles ou même de mauvaises configurations sur des plateformes tierces. L’architecture doit refléter cette réalité en partant du principe que rien n’est intrinsèquement sûr.
C’est exactement ce que fait un modèle de confiance zéro. Chez JPMorgan Chase, la sécurité est structurée en plusieurs couches indépendantes, chacune étant conçue pour résister seule aux compromis. À la périphérie, le filtrage et les pare-feu bloquent le trafic Internet indésirable avant qu’il n’atteigne l’application. En profondeur, les contrôles d’accès, les politiques de moindre privilège, les communications cryptées et l’isolation des informations d’identification sécurisent les opérations internes.
Les conteneurs sont scannés et vérifiés. Les applications doivent valider tous les utilisateurs et toutes les actions par le biais de flux d’authentification et d’autorisation. Les données sont cryptées à la fois en transit et au repos. L’architecture fait la distinction entre les systèmes internes et externes, ce qui permet une segmentation qui limite la portée en cas de violation. Une défaillance ne compromet pas l’ensemble de la plateforme.
Pour les chefs d’entreprise, cette approche stratifiée réduit la responsabilité et garantit l’alignement réglementaire. Il ne s’agit pas seulement de prévenir les violations, bien que cela soit essentiel, mais aussi de maintenir l’intégrité opérationnelle dans des conditions à haut risque. Les systèmes cloud évoluent. Il en va de même pour la surface des menaces. Une stratégie statique perd rapidement de sa pertinence. Les modèles de confiance zéro fournissent une posture de défense dynamique, vérifiée en permanence.
C’est l’automatisation qui permet d’assurer la pérennité de ce système. L’application manuelle de la sécurité n’est pas évolutive. Lorsque les politiques sont codifiées et appliquées par la plateforme elle-même grâce à l’infrastructure en tant que code, la sécurité devient un comportement fondamental plutôt qu’une surcouche. Il en résulte non seulement des systèmes plus sûrs, mais aussi une réduction du temps de réponse aux incidents et une amélioration de la confiance avec les régulateurs, les partenaires et les clients.
Une migration efficace vers le cloud implique des changements de culture organisationnelle et une gestion progressive du changement
La transformation cloud n’est pas un simple remplacement d’infrastructure. Il s’agit d’un changement stratégique dans la manière dont les équipes construisent, déploient et exploitent les produits numériques. De nombreuses migrations échouent parce que les organisations considèrent le processus comme technique et statique, alors qu’en réalité, il est itératif et organisationnel.
Chez JPMorgan Chase, la migration a nécessité un changement de propriétaire. Les équipes chargées des applications sont responsables des systèmes qu’elles construisent, de la conception au déploiement, en passant par la maintenance. Cette structure oblige à rendre des comptes et encourage à prendre de meilleures décisions en matière d’ingénierie. Elle exige également l’automatisation, et beaucoup d’automatisation. Les opérations manuelles ne peuvent pas suivre la fréquence des changements et la complexité des environnements cloud.
Les services évoluent constamment. Les fournisseurs de cloud mettent à jour les API et modifient fréquemment les politiques. Le comportement du réseau change. Les navigateurs évoluent. Vous construisez sur une plateforme en mouvement. Vos équipes internes doivent s’adapter en permanence, ce qui signifie que vos processus de développement, de sécurité et d’exploitation doivent intégrer l’automatisation, l’observabilité et les modèles de conception en libre-service. Les mises à jour continues, le ciblage des régions et les contrôles basés sur l’état de santé sont nécessaires.
Le processus de migration est également échelonné. Les grands systèmes comme Chase.com servent des millions d’utilisateurs et ne peuvent pas être transférés du jour au lendemain. Les équipes internes valident d’abord les changements. Ensuite, le trafic des clients est introduit lentement, petit pourcentage par petit pourcentage. Les tests sont effectués en production, dans des environnements de trafic réel, dans des conditions contrôlées.
L’entreprise a mis en œuvre une méthodologie DevOps personnalisée appelée TrueCD, inspirée des listes de contrôle de l’aviation. Elle fait passer les applications par un pipeline automatisé en 12 étapes qui comprend la vérification du déploiement, la préparation au retour en arrière et les portes d’approbation. Ces étapes permettent de maintenir la stabilité tout en accélérant le changement.
Pour les dirigeants, la clé est de permettre aux équipes de travailler sans compromettre la gouvernance. La lenteur de la prise de décision du haut vers le bas étouffe la vélocité du cloud. Mais trop de liberté crée de l’incohérence. Le succès de la migration dépend de l’équilibre, en équipant les équipes distribuées d’outils et de cadres qui renforcent les garde-fous tout en favorisant l’autonomie. Lorsqu’elle est exécutée correctement, la transformation n’est pas seulement réussie, elle est aussi évolutive dans les lignes de produits et les unités d’affaires.
Les couches d’abstraction réduisent le couplage entre l’infrastructure et les services commerciaux pendant la migration.
Les migrations vers le cloud introduisent une complexité qui peut facilement perturber les systèmes d’entreprise si elle n’est pas gérée avec précision. Lorsque les plateformes passent du sur site au cloud-natif, l’un des principaux défis consiste à découpler la logique métier des dépendances de l’infrastructure. Sans cette séparation, de petits changements dans les plateformes sous-jacentes peuvent créer des problèmes à l’échelle du système qui altèrent l’expérience de l’utilisateur, introduisent de l’instabilité ou provoquent des pannes inattendues.
JPMorgan Chase a fait face à ce risque en incorporant des couches d’abstraction dans son architecture. Ces couches séparent les fonctionnalités essentielles de l’entreprise des préoccupations spécifiques au cloud ou à l’infrastructure. Cela permet aux équipes d’ingénieurs d’adopter les meilleurs outils pour le réseau, le stockage, le calcul ou la messagerie, qu’ils fonctionnent dans un seul cloud, dans un déploiement multi-cloud ou dans un environnement hybride.
Cette souplesse de conception est importante. À mesure que les fournisseurs de cloud font évoluer leurs services, les couches d’abstraction réduisent la quantité de travail nécessaire dans les applications. Elles garantissent que les mises à jour des services de la plateforme ne se répercutent pas sur les opérations de base. L’un des cadres libres mentionnés dans la stratégie est Dapr, une plateforme qui permet une communication de service, une gestion d’état et une gestion d’événements adaptées au cloud, toutes distinctes des implémentations spécifiques des fournisseurs.
Pour les cadres de haut niveau, cette approche permet d’exercer un contrôle. Elle évite l’enfermement. Elle réduit les risques de migration. Plus important encore, elle préserve la continuité de l’activité pendant que l’infrastructure évolue en arrière-plan. Les équipes peuvent moderniser les composants en parallèle au lieu d’attendre la fin des migrations complètes, et les applications deviennent plus portables, plus extensibles et plus faciles à maintenir. Dans un environnement réglementé comme la finance ou la santé, cette forme de contrôle favorise également la conformité en garantissant un comportement prévisible, même lorsque des changements interviennent au niveau de la plateforme.
Des stratégies de performance bien pensées permettent d’obtenir des avantages concurrentiels et de satisfaire les clients.
Les performances ont une incidence directe sur la perception du client et sur le chiffre d’affaires. Lorsque les systèmes réagissent lentement, les clients remettent en question leur fiabilité. Lorsqu’ils reçoivent des résultats instantanément, ils restent fidèles. Les plateformes performantes ne sont pas un luxe technique, c’est une nécessité commerciale.
Chez Chase, l’optimisation des performances a été traitée comme une initiative stratégique, et non comme une simple préoccupation de backend. L’équipe chargée de l’infrastructure a mis en œuvre l’informatique de périphérie et la mise en cache aux points de présence pour traiter les contenus lourds à proximité de l’utilisateur, tout en ne laissant que les activités critiques, basées sur les transactions, acheminées vers les systèmes centralisés. Cela a permis de réduire le temps de latence pour les chargements de contenu à moins de 100 millisecondes. Sans ces changements, les appels aux systèmes d’origine prenaient plus de 500 millisecondes, soit cinq fois plus longtemps.
Le résultat était mesurable : une réduction de 71 % de la latence après le déploiement complet de leur stratégie de performance. Ce type d’amélioration n’est pas subtil, c’est un changement radical. Elle concerne des millions d’interactions avec les clients, en particulier sur les téléphones mobiles où la variabilité du réseau peut amplifier les retards.
La vitesse des pages a également une incidence sur la visibilité. Google intègre des mesures de performance dans son algorithme de classement. Les sites plus rapides semblent plus dignes de confiance et sont mieux classés. Pour les plateformes financières, où la confiance des consommateurs est essentielle, cet aspect est important tant sur le plan technique que commercial.
L’équipe de Chase a également utilisé l’optimisation du stockage mobile pour réduire le volume d’appels et accélérer le chargement des applications. La mise en cache locale des paramètres de configuration, des données utilisateur et des ressources prédéfinies permet aux applications mobiles de se lancer plus rapidement et de réduire la dépendance à l’égard des appels en direct pour chaque interaction.
Pour les dirigeants, le principal enseignement à tirer est l’alignement. La performance n’est pas seulement une caractéristique du produit, c’est un outil stratégique. Elle permet de réduire les coûts, d’améliorer la satisfaction des clients, de renforcer la perception du public et d’accroître l’efficacité opérationnelle. Les investissements dans la performance sont mesurables et directement liés à l’expérience de l’utilisateur, à la conversion et à la fidélisation. Si le système fonctionne plus rapidement, l’entreprise gagne en attention, en confiance et en croissance.
Tester les systèmes de manière proactive et réactive permet une planification solide de la résilience.
La fiabilité des systèmes n’est pas le fruit d’hypothèses ou de modèles théoriques. Elle nécessite de vérifier, dans des conditions contrôlées et non contrôlées, comment les systèmes se comportent lorsque des composants tombent en panne ou lorsque les dépendances ne répondent pas comme prévu. JPMorgan Chase a adopté deux approches de test fondamentales pour valider la résilience : l’analyse des modes de défaillance et de leurs effets (AMDE) et les outils d’injection de fautes tels que Chaos Monkey.
L’AMDE est un moyen structuré et proactif d’identifier où les défaillances peuvent se produire, quel impact elles peuvent avoir et comment le système doit se rétablir. Elle permet aux équipes de concevoir des plans d’atténuation pour des modes de défaillance spécifiques avant qu’ils ne posent de réels problèmes en production. Cette forme d’analyse prédictive s’applique à toutes les couches de l’application, de l’infrastructure et des bases de données aux points d’intégration et aux API externes.
Du côté réactif, des outils comme Chaos Monkey introduisent intentionnellement des événements de défaillance, tels que l’arrêt d’instances ou le blocage du trafic, afin de voir comment le système réagit en temps réel. Cela permet de valider les hypothèses et de révéler les faiblesses de la logique de basculement ou des processus d’alerte qui n’apparaissent que sous la pression. Bien que les deux approches soient utiles, l’AMDE est préférée pour sa stratégie de prévention structurée et basée sur la conception. Elle favorise les améliorations continues plutôt que les correctifs réactionnels.
Pour les dirigeants, cela devrait servir d’indicateur de confiance dans les performances. Des tests réguliers, intégrés au cycle de développement et d’exploitation, garantissent que la résilience du système n’est pas laissée au hasard, en particulier dans les secteurs soumis à des pressions en matière de réglementation ou d’expérience client. Ils permettent également de réduire le temps de reprise lors d’incidents réels, puisque les équipes sont déjà formées et que les systèmes sont déjà configurés pour réagir correctement. Les tests proactifs apportent de la prévisibilité dans la manière dont les services critiques réagissent aux perturbations, ce qui n’est pas négociable pour la confiance et la conformité des clients.
Le succès de la migration dépend de la mise en œuvre progressive et de la segmentation fonctionnelle.
Les migrations de systèmes de grande envergure, en particulier celles qui impliquent des plates-formes publiques, doivent être effectuées en phases claires et gérables. Tenter de migrer des systèmes entiers en une seule fois introduit un risque qui ne peut pas être rapidement atténué. Au lieu de cela, Chase a segmenté sa stratégie de migration en fonction des dépendances internes et des groupes d’utilisateurs.
En interne, les systèmes ont été divisés en ensembles d’applications fonctionnelles plus petits. Chaque ensemble a été validé de manière isolée, en veillant à ce que les fonctionnalités de base restent intactes et que les configurations, les autorisations et les crochets d’observabilité nécessaires soient actifs. Une fois la validation interne terminée, le trafic des clients a été progressivement introduit. Ce déploiement s’est fait en pourcentage, en commençant par un petit nombre, puis en augmentant au fur et à mesure que la fiabilité était confirmée. Cela a permis d’observer les schémas d’utilisation réels et de corriger les anomalies de performance avant l’adoption complète par la population.
Certains services, en raison de leur complexité ou de leur ampleur, n’ont pas pu être entièrement reconstruits dans la fenêtre de migration. Dans ces situations, des versions partielles ont permis à la plateforme de maintenir sa stabilité tout en décomposant et en remplaçant progressivement les éléments hérités en coulisses.
Les résultats de cette approche se sont traduits par une optimisation des coûts et des performances. Au lieu d’être adoptée à la hâte, la plateforme a mûri pendant la transition, ce qui a permis de la régler et de l’améliorer à chaque étape.
Pour les dirigeants d’entreprise, le déploiement progressif est une discipline. Il permet de quantifier et de gérer les risques à chaque point de contrôle, d’éviter les échecs en cascade et d’isoler les problèmes lorsqu’ils surviennent. Il améliore également la vélocité de l’équipe au fil du temps, car les apprentissages validés sont réutilisés dans les systèmes adjacents. La migration n’est pas un changement, c’est un processus qui, lorsqu’il est géré correctement, produit une valeur opérationnelle à long terme et une valeur pour le client.
Les choix stratégiques doivent tenir compte des coûts, des performances et de la complexité.
Les plateformes d’entreprise fonctionnant à grande échelle ne peuvent pas se permettre d’optimiser une seule dimension. La rentabilité, les performances et la simplicité architecturale vont souvent dans des directions différentes. Les décisions que vous prenez, ce qu’il faut répliquer, ce qu’il faut automatiser, ce qu’il faut mettre en cache, ont des implications à long terme pour le risque opérationnel et l’agilité de l’entreprise.
Chez JPMorgan Chase, ces compromis ont été abordés directement, et non évités. Par exemple, la mise en cache multirégionale offre des performances et une redondance, mais introduit une complexité en matière de cohérence des données et de latence de réplication. Le fait de tout synchroniser dans plusieurs zones ou régions ajoute à la fois des frais généraux d’ingénierie et des coûts d’infrastructure. En revanche, la mise en cache dans une seule région réduit les dépenses et simplifie la synchronisation, mais peut augmenter le temps d’accès ou exposer la plateforme à des défaillances régionales.
Il en va de même pour l’automatisation. L’automatisation à l’échelle du système réduit les efforts manuels, améliore la vitesse de déploiement et minimise les échecs dus à l’erreur humaine. Mais une trop grande complexité automatisée, sans une gouvernance et une visibilité claires, peut créer ses propres angles morts opérationnels. Une automatisation excessive sans transparence empêche les équipes de comprendre les causes profondes des pannes.
La capacité à effectuer des évaluations de compromis est essentielle. Les équipes d’ingénieurs de Chase ont évalué chaque stratégie en comprenant clairement les objectifs de niveau de service, les attentes des utilisateurs et l’impact attendu. Il s’agit notamment d’évaluer si certaines régions ou certains composants ont besoin d’une prise en charge complète du basculement ou si un service dégradé est tolérable lors de perturbations de courte durée.
Les résultats quantitatifs ont contribué à ces décisions. Selon les rapports de benchmarking de Dynatrace, la plateforme Chase s’est classée parmi les banques américaines les plus performantes, atteignant des temps de réponse inférieurs à une seconde, considérés comme le seuil optimal pour les services bancaires numériques. Ces niveaux de performance ne sont pas le fruit du hasard ; ils ont été obtenus grâce à des choix architecturaux qui ont donné la priorité à la réactivité tout en maintenant le coût total et la complexité dans des limites acceptables.
Pour les cadres supérieurs, il ne s’agit pas seulement d’un exercice d’équilibre technique. Chaque décision en matière d’architecture a une incidence sur la planification budgétaire, l’évolutivité, la dépendance à l’égard des fournisseurs et la résilience opérationnelle. Évaluer les compromis avec clarté garantit la continuité de l’activité, permet des prévisions plus précises et donne aux équipes les moyens d’effectuer des changements en toute confiance au fur et à mesure de l’évolution des exigences de la plateforme. Une architecture intelligente ne consiste pas à tout rendre parfait, mais à aligner votre infrastructure sur une valeur commerciale mesurable.
Réflexions finales
La mise à l’échelle des systèmes cloud et distribués ne consiste pas à acheter plus d’infrastructure ou à suivre toutes les tendances. Il s’agit de faire des choix délibérés qui relient les performances techniques aux résultats de l’entreprise, à la résilience, à la rapidité, à la rentabilité et au contrôle. L’architecture doit refléter ce que l’entreprise valorise le plus : la disponibilité sous pression, la sécurité qui ne compromet pas l’agilité et les performances qui renforcent la confiance des clients.
Ces systèmes ne reposent pas sur les meilleures intentions. Ils fonctionnent grâce à l’automatisation, à l’observabilité et à des cadres structurés qui éliminent les conjectures. Lorsque les mesures guident les décisions et que la résilience est conçue et non improvisée, les équipes fonctionnent plus rapidement et plus intelligemment. Cela a des effets en aval, sur l’expérience des clients, l’alignement réglementaire et l’efficacité opérationnelle.
Pour les dirigeants, la conclusion est claire. Si vous voulez une échelle fiable, des performances élevées et des coûts à long terme plus faibles, vous ne vous demandez pas à quoi ressemblera l’infrastructure au prochain trimestre, vous définissez comment les décisions prises aujourd’hui soutiennent des systèmes qui ne s’effondrent pas sous l’effet de la croissance ou du stress. Et vous donnez aux équipes les outils, la structure et l’autonomie nécessaires pour exécuter les tâches avec cohérence et responsabilité.
Les systèmes tomberont en panne. C’est normal. Mais la façon dont vous vous préparez à l’échec et la rapidité de la reprise définissent la confiance que les utilisateurs et les parties prenantes accordent à l’entreprise. Les entreprises qui sont à la pointe de la performance numérique n’évitent pas la complexité. Elles la gèrent avec précision.
