Pourquoi les Mainframes restent importants à l'ère numérique bancaire – Entretien avec Jennifer Nelson

Jennifer Nelson est PDG d’izzi Software.

Découvrez les meilleures nouvelles et événements fintech !

Abonnez-vous à la newsletter de FinTech Weekly

Lue par des dirigeants de JP Morgan, Coinbase, Blackrock, Klarna et plus encore

Dans une industrie obsédée par la dernière vague de technologie, il est facile d’oublier que certains des piliers les plus solides de l’infrastructure financière existent depuis des décennies. Bien que l’innovation fintech soit souvent présentée comme une course vers l’avenir, l’épine dorsale de la banque mondiale reste silencieusement ancrée dans des systèmes que beaucoup rejettent à tort comme des reliques : le mainframe.

Ce n’est pas simplement une question de nostalgie ou d’inertie d’entreprise. Les mainframes traitent encore la majorité des transactions financières mondiales, avec une fiabilité et une échelle inégalées par de nombreuses plateformes plus récentes. Leur capacité à gérer d’énormes volumes de données en temps réel, sans compromettre la sécurité, les a rendus indispensables dans un système financier qui dépend à la fois de la rapidité et de la confiance.

Pourtant, malgré leur rôle critique, les mainframes sont souvent mal compris. Dans le climat actuel, où “cloud-first” est le mantra par défaut, il peut sembler contre-intuitif de défendre les technologies plus anciennes. Mais qualifier le mainframe de système hérité simplifie à l’extrême une vérité beaucoup plus complexe. Pour comprendre pourquoi, nous devons examiner l’équilibre entre les systèmes hérités et l’élan moderne vers des infrastructures hybrides.

Le cas de la modernisation avec prudence

Les institutions financières subissent une pression incessante pour se moderniser. Les investisseurs, les clients et les régulateurs s’attendent à des services numériques transparents, une sécurité renforcée et des performances toujours plus rapides. Pour de nombreux dirigeants, la tentation est de poursuivre le changement de manière agressive — de se débarrasser des anciens systèmes et de passer entièrement au cloud.

Mais la modernisation n’est pas simplement un projet technique. C’est une entreprise stratégique qui comporte des risques lorsqu’elle est réalisée à la hâte. Les données qui ont vécu en toute sécurité dans un environnement mainframe pendant des décennies deviennent exposées au moment où elles sont transférées ailleurs. Les applications optimisées pour le mainframe peuvent trébucher lors de la migration, ce qui entraîne des problèmes de latence coûteux. Ces risques ne sont pas hypothétiques — ils menacent les opérations quotidiennes, la conformité réglementaire, et même la confiance des consommateurs.

La leçon est claire : la vraie modernisation ne consiste pas à détruire l’ancien au profit du nouveau. Il s’agit d’intégrer les forces, de procéder à des mises à jour de manière minutieuse, et de garantir que la prochaine étape ne déstabilise pas ce qui fonctionne déjà.

Un fossé de compétences avec de réelles conséquences

La technologie évolue plus vite que l’expertise requise pour la maintenir. Nulle part cela n’est plus évident que dans le domaine des mainframes. Pendant des années, les banques et les institutions financières ont compté sur un pool d’ingénieurs ayant une connaissance institutionnelle approfondie des systèmes IBM Z et des plateformes connexes. Alors que beaucoup de ces experts prennent leur retraite, la prochaine génération n’a pas encore remplacé entièrement leur ensemble de compétences.

Cela crée un défi sérieux. Un vivier de compétences peu profond augmente le risque d’erreurs coûteuses, même lorsque des protections sont en place. La résilience des mainframes ne peut pas entièrement compenser le facteur humain. Tant que de nouveaux ingénieurs ne seront pas formés et mentorés, les banques seront confrontées à des vulnérabilités non pas à cause de la technologie elle-même, mais à cause du rétrécissement du pool de professionnels qui savent comment l’utiliser en toute sécurité.

La sécurité concerne toujours les personnes

Lorsque les conversations sur la cybersécurité surgissent, une grande partie de l’attention est portée sur les outils et les défenses. Pourtant, encore et encore, les vraies faiblesses proviennent du comportement humain. Dans le monde des mainframes, cela se résume souvent à la manière dont les autorisations sont accordées, gérées et révoquées.

Les développeurs qui ne comprennent pas pleinement les implications des autorisations élevées peuvent laisser des portes ouvertes, non pas par malice, mais par formation incomplète ou commodité. Les entreprises qui ne mettent pas à jour les accès lorsque les employés changent de rôle peuvent exposer des données sensibles de manière inutile. Même avec une technologie sophistiquée, les bases de l’hygiène de sécurité restent essentielles — et trop souvent négligées.

Présentation de Jennifer Nelson

Pour mettre ces défis et opportunités en contexte, nous nous sommes tournés vers Jennifer Nelson, PDG d’Izzi Software. Nelson a construit sa carrière autour des systèmes mainframe, passant 15 ans chez Rocket Software et cinq ans chez BMC avant d’élargir sa perspective à travers des rôles d’ingénierie senior en dehors de l’écosystème IBM Z. En 2024, elle a fondé Izzi Software, une entreprise dédiée à l’acquisition et à la croissance d’entreprises basées sur les plateformes IBM Z et IBM Power.

Son point de vue — englobant l’ingénierie mainframe traditionnelle et le leadership en logiciels modernes — en fait une voix rare dans la conversation actuelle sur la stratégie technologique dans les services financiers.

Profitez de l’interview !

1. Alors que la fintech se précipite vers tout cloud-natif, vous avez soutenu que le mainframe reste critique pour la stabilité bancaire mondiale. Que pensez-vous que la plupart des innovateurs se trompent sur le rôle des systèmes plus anciens aujourd’hui ?

La première chose qu’ils se trompent est de qualifier le mainframe de système hérité ; que parce qu’ils ont été lancés il y a plus de 60 ans, ils sont d’une certaine manière obsolètes. C’est comme qualifier le système d’exploitation Windows de plateforme héritée. Ce n’est tout simplement pas la réalité. Les mainframes sont plus pertinents aujourd’hui qu’au moment de leur invention.

Tout le monde veut des données à la vitesse de la lumière. Ils veulent que les données leur soient renvoyées dès qu’ils appuient sur le bouton, peu importe où ces données se trouvent. Et c’est tout à fait justifié car le consommateur final ne devrait pas connaître, et ne devrait pas avoir à connaître, les complexités de sa demande, comme l’endroit où se trouvent les données. Mais seuls les mainframes peuvent vous offrir la performance et la sécurité dans un environnement hybride.

Les mainframes peuvent ingérer des données où qu’elles se trouvent, les analyser et les renvoyer, avec des recommandations, mieux que toute autre plateforme, et plus rapidement. Montrez-moi un autre système qui peut ingérer des données de l’ensemble d’un réseau mondial, les analyser, détecter des anomalies en temps réel et les renvoyer immédiatement à l’appelant.

Celui qui connaît le mieux ses données gagne car les données sont aussi précieuses que le capital liquide. Lorsque les innovateurs rejettent les mainframes comme des systèmes hérités, ils rejettent leur vitesse et leur puissance, ainsi que leur capacité à traiter d’énormes quantités de données à la vitesse requise pour la détection des risques en temps réel.

Les gens pensent que le cloud a été révolutionnaire et moderne, et que les mainframes sont dépassés en comparaison. Le concept de cloud computing à travers un réseau est en effet moderne et révolutionnaire pour beaucoup. Mais si vous êtes familier avec la technologie mainframe, les utilisateurs reconnaîtront qu’elle possède de nombreuses caractéristiques similaires à celles du cloud. Par exemple, lorsque vous vous connectez au mainframe, vous vous connectez à TSO, abréviation de “time sharing option”. Vous avez votre propre session TSO, ou instance Microsoft Teams.

Vous utilisez tous les mêmes processeurs sur le mainframe. Mais lorsque vous n’exécutez pas un programme ou un travail par lot, la capacité est donnée à ceux qui en ont besoin. Vous vous connectez également à un LPAR, ou partition logique, complète avec un stockage, une sécurité et une confidentialité dédiés. Les utilisateurs d’un LPAR ne peuvent pas accéder aux données d’un autre LPAR, sauf si cela est configuré spécifiquement. C’est ce qu’est le cloud à sa base ; partager des ressources lorsque vous ne les utilisez pas et sécuriser des données dédiées à votre instance. Mais le mainframe utilise ces concepts depuis des années.

2. L’infrastructure hybride — mélangeant les mainframes avec des couches cloud plus récentes — devient la norme. D’après votre expérience, quels sont les véritables facteurs de risque introduits lorsque les organisations tentent de se moderniser trop rapidement ou superficiellement ?

Parmi les multiples facteurs de risque, je peux les réduire à deux.

Le premier risque est la consommation de données. Les données sur un mainframe sont parmi les plus sécurisées qui soient. Lorsque vous les retirez du mainframe ou que vous les rendez visibles à quelqu’un qui ingère ces données, il y a un risque pour la confidentialité des données et la réglementation. Qui les regarde ? Où vont-elles quand elles quittent le mainframe ?

Le deuxième risque concerne l’optimisation des applications pour fonctionner dans un environnement hybride. Les applications optimisées pour le mainframe peuvent finir par fonctionner de manière sous-optimale sur un autre serveur. Des problèmes de latence et de performance pourraient nuire à la productivité.

3. Vous avez tiré la sonnette d’alarme concernant un fossé de compétences en expertise mainframe. Quelle est la gravité du risque institutionnel lorsque moins d’ingénieurs savent comment faire fonctionner et sécuriser les systèmes sur lesquels les institutions financières dépendent encore ?

Le risque est grave. Les nouveaux développeurs — pas seulement les jeunes, mais ceux qui sont nouveaux dans l’industrie — apprendront et développeront leur expertise. Mais tant que la prochaine génération n’aura pas rattrapé son retard, il y aura une exposition dans les institutions financières pendant un certain temps lorsque la connaissance institutionnelle ne sera pas aussi approfondie qu’elle devrait l’être.

Les personnes ayant une profondeur d’expérience ou de connaissances limitée peuvent faire des choses de manière involontaire qui causent un risque pour les données ou pour un système d’exploitation. Ces systèmes sont résilients et disposent de plusieurs couches de protection contre l’erreur humaine, mais il existe encore un risque important tant que les compétences ne sont pas à niveau. Les banques sont déjà en train de lutter contre ce fossé de compétences aujourd’hui.

4. Les conversations sur la sécurité se concentrent souvent sur les outils, mais vous avez souligné que les personnes sont toujours en première ligne. Quels angles morts opérationnels avez-vous vu émerger le plus souvent dans la gestion des environnements mainframe ?

La gestion des environnements pertinents se concentre généralement sur les autorisations élevées. Lorsqu’un ingénieur logiciel écrit du code, il a parfois besoin d’une autorisation élevée pour faire quelque chose de spécifique sur le système d’exploitation, où il peut permettre au programme de faire quelque chose de plus sensible. Si l’ingénieur ne comprend pas les meilleures pratiques du développeur lors de l’écriture de logiciels, il ne saura pas quand entrer et sortir de cet état autorisé élevé. Cet état comporte plus de risques, donc les ingénieurs ne resteront pas assez longtemps pour comprendre pleinement les meilleures pratiques lors du développement pour ce système.

Il existe également des meilleures pratiques fondamentales en matière de sécurité à utiliser dans tout réseau informatique. Lorsque vous donnez une autorisation spéciale à quelqu’un dans un certain rôle, vous devez avoir un processus clair en place pour retirer cette autorisation lorsqu’il change de rôle, afin de vous assurer que vous retirez l’accès. La plupart du temps, ce n’est pas un problème, s’ils sont soit encore employés de l’entreprise, soit pas de mauvais acteurs. Mais il y a toujours un risque de laisser trop de données sensibles accessibles à des personnes qui n’en ont plus besoin.

De plus, les ensembles de données au niveau système mainframe permettent aux utilisateurs de faire des choses fondamentales à un système. Vous ne voulez que certains utilisateurs aient accès à ces fonctions. Par exemple, certains contrôles de sécurité ne peuvent être activés qu’aux niveaux les plus profonds du système d’exploitation. Vous seriez surpris de voir à quelle fréquence les entreprises laissent des principes de sécurité de base non vérifiés. Il existe des moyens pour les ingénieurs de faire leur travail sans avoir accès à ces ressources de niveau racine, mais il est plus facile de travailler avec ce niveau d’accès, donc les entreprises laissent souvent la porte dérobée ouverte plus qu’elles ne devraient.

La plupart des employés peuvent être dignes de confiance, mais ce sont des principes fondamentaux que certaines institutions financières laissent ouverts et oublient.

5. Les attaques par ransomware ciblent non seulement les points d’extrémité, mais aussi l’infrastructure centrale. Qu’est-ce qui rend les systèmes hérités à la fois particulièrement vulnérables — et, dans certains cas, plus résilients — que les plateformes plus récentes ?

Les mainframes ont des couches de sécurité intégrées que la plupart des serveurs n’ont tout simplement pas. Ce n’est pas parce que vous pouvez vous connecter au mainframe que vous avez maintenant accès aux données critiques pour l’entreprise, ce que le ransomware verrouille généralement. Vous devez ensuite savoir où se trouvent les données et comment y accéder. Et ensuite, les données peuvent être compartimentées, donc un envahisseur n’a accès qu’à un segment des données et non à tout ce dont il a besoin pour une attaque par ransomware réussie. Et si vous n’avez pas accès au dispositif de stockage, vous ne pouvez pas voir les données sur ce dispositif.

6. D’après votre expérience, à quoi ressemble réellement une modernisation efficace pour les institutions financières qui ne peuvent pas se permettre de “détruire et remplacer” mais doivent être à l’épreuve du futur ?

La modernisation signifie des choses différentes dans différentes entreprises en fonction de l’état des applications qu’elles exécutent. Que ce soit B2B ou B2C, les entreprises se modernisent continuellement, mettant à jour les serveurs et les ordinateurs portables.

La même chose se produit avec les applications critiques pour l’entreprise. Une entreprise pourrait périodiquement mettre à jour ces applications, mais parce que les applications mainframe traditionnelles ont été développées il y a des générations, la meilleure chose que les entreprises puissent faire est d’évaluer pleinement ce que chaque application fait de bout en bout. De cette manière, elles peuvent procéder à leur modernisation par étapes gérables.

Les entreprises peuvent compartimenter une application, la décomposant en morceaux afin que les différentes fonctionnalités et fonctions soient mises à jour et réécrites lentement au fil du temps, selon ce qui est abordable. Si vous considérez la modernisation comme un processus continu, l’envie d’améliorer et d’itérer devient continue.

Les dirigeants doivent toujours avoir un état d’esprit proactif. Les questions doivent être : “Que pouvons-nous faire maintenant ? Que pouvons-nous contenir cette année ? Que pouvons-nous contenir dans les deux prochaines années ?” C’est une meilleure approche que “comment réécrivons-nous tout cela ?”

Vous devez itérer sur les systèmes et les développer au fil du temps. Commencez par réécrire une fonctionnalité d’une application critique pour l’entreprise, puis construisez dessus en ajoutant le reste des fonctionnalités au fur et à mesure que vous le pouvez. Introduisez les changements progressivement.

Détruire et remplacer est une option. Cela semble brut et brutal, mais tout ce que cela signifie vraiment, c’est d’arrêter d’utiliser un système pour en utiliser un autre. Mais la direction doit avoir le courage d’un grand changement d’un coup, et doit approuver le budget. La vérité est que c’est plus juste un “remplacer”, car cela peut prendre des années pour compléter la procédure.

7. Pour les dirigeants technologiques venant d’un état d’esprit cloud-first, que diriez-vous est le changement de mentalité le plus important lors de l’engagement avec des systèmes mainframe critiques pour la mission ?

Apprenez ce que le mainframe fait réellement. Le serment d’Hippocrate dit de ne pas nuire d’abord, donc apprenez ce dont le mainframe est responsable pour éviter de commettre des erreurs nuisibles. Une fois que ceux ayant un état d’esprit cloud-first comprennent l’ensemble des transactions qui entrent dans le mainframe, la nature de ces transactions, et combien les revenus de leur entreprise dépendent de ces transactions, ils comprendront et sauront comment éviter d’endommager la performance et la rentabilité de leur entreprise.

À propos de Jennifer Nelson

Jennifer Nelson a passé la majeure partie de sa carrière dans l’espace mainframe, y compris 15 ans chez Rocket Software et cinq ans chez BMC. En 2019, elle a transitionné vers des rôles d’ingénierie senior dans des entreprises technologiques mondiales en dehors de l’écosystème Z Systems, élargissant sa perspective et son ensemble de compétences. Au début de 2024, Nelson a commencé à poser les bases de ce qui deviendrait Izzi Software, une entreprise axée sur l’acquisition et la croissance d’entreprises logicielles basées sur les plateformes IBM Z et IBM Power.