Pourquoi les grands systèmes restent importants dans l'ère numérique bancaire – Entretien avec Jennifer Nelson

Jennifer Nelson est PDG d’izzi Software.

Découvrez les meilleures actualités et événements fintech !

Abonnez-vous à la newsletter de FinTech Weekly

Lue par des cadres chez JP Morgan, Coinbase, Blackrock, Klarna et plus encore

Dans une industrie obsédée par la nouvelle 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. Alors que l’innovation fintech est souvent présentée comme une course vers l’avenir, la colonne vertébrale de la banque mondiale reste discrètement ancrée dans des systèmes que beaucoup rejettent à tort comme des reliques : le mainframe.

Ce n’est pas seulement 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 beaucoup de plateformes plus récentes. Leur capacité à gérer d’énormes volumes de données en temps réel, sans compromettre la sécurité, en fait des éléments 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 contexte actuel, où « cloud-first » est la règle par défaut, il peut sembler contre-intuitif de défendre des technologies plus anciennes. Mais qualifier le mainframe de système hérité simplifie à l’excès une vérité bien plus complexe. Pour comprendre pourquoi, il faut examiner l’équilibre entre systèmes patrimoniaux et la poussée moderne vers des infrastructures hybrides.

Le cas de la modernisation avec prudence

Les institutions financières sont sous une pression incessante pour se moderniser. Les investisseurs, clients et régulateurs attendent des services numériques fluides, 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 migrer en masse vers le cloud.

Mais la modernisation n’est pas simplement un projet technique. C’est une démarche stratégique qui comporte des risques si elle est menée à la hâte. Des données qui ont vécu en toute sécurité dans un environnement mainframe pendant des décennies deviennent exposées dès qu’elles sont transférées ailleurs. Les applications optimisées pour le mainframe peuvent trébucher lors de leur migration, entraînant 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 : une véritable modernisation ne consiste pas à détruire l’ancien pour faire place au nouveau. Il s’agit d’intégrer les forces, de phaser les mises à jour avec soin, et de s’assurer que la prochaine étape ne déstabilise pas ce qui fonctionne déjà.

Un déficit de compétences avec de vraies conséquences

La technologie évolue plus vite que l’expertise nécessaire pour la maintenir. Cela est particulièrement évident dans le domaine des mainframes. Depuis des années, les banques et institutions financières comptent sur un vivier d’ingénieurs possédant une connaissance approfondie des systèmes IBM Z et des plateformes associées. Alors que beaucoup de ces experts prennent leur retraite, la nouvelle génération n’a pas encore complètement remplacé leur savoir-faire.

Cela crée un défi sérieux. Un vivier d’expertise limité augmente le risque d’erreurs coûteuses, même si des protections sont en place. La résilience des mainframes ne peut pas compenser entièrement le facteur humain. Jusqu’à ce que de nouveaux ingénieurs soient formés et encadrés, les banques seront vulnérables, non pas à cause de la technologie elle-même, mais à cause du pool de professionnels capables de l’utiliser en toute sécurité qui se réduit.

La sécurité repose toujours sur les personnes

Lorsque l’on parle de cybersécurité, l’attention se porte souvent sur les outils et défenses. Pourtant, encore et encore, les véritables failles proviennent du comportement humain. Dans le monde du mainframe, cela se résume souvent à la façon dont les permissions sont accordées, gérées et révoquées.

Les développeurs qui ne comprennent pas pleinement les implications des permissions élevées peuvent laisser des portes ouvertes, non par malveillance, 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 inutilement. Même avec une technologie sophistiquée, les principes fondamentaux de l’hygiène de sécurité restent essentiels — et trop souvent négligés.

Présentation de Jennifer Nelson

Pour mettre en contexte ces défis et opportunités, nous avons consulté 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 développées sur les plateformes IBM Z et IBM Power.

Son point de vue — qui couvre à la fois l’ingénierie traditionnelle mainframe et le leadership en logiciel moderne — fait d’elle une voix rare dans la conversation actuelle sur la stratégie technologique dans les services financiers.

Bonne lecture de l’interview !

1. Alors que la fintech se précipite vers tout cloud-native, vous avez soutenu que le mainframe reste essentiel à la stabilité bancaire mondiale. Quelles erreurs pensez-vous que la plupart des innovateurs commettent à propos du rôle des systèmes plus anciens aujourd’hui ?

La première erreur qu’ils font est de qualifier le mainframe de système hérité ; qu’il a été lancé il y a plus de 60 ans et qu’il est donc obsolète. C’est comme appeler le système d’exploitation Windows une plateforme héritée. Ce n’est tout simplement pas la réalité. Les mainframes sont plus pertinents aujourd’hui qu’à leur création.

Tout le monde veut des données à la vitesse de la lumière. Ils veulent que les données leur soient retournées dès qu’ils appuient sur le bouton, peu importe où ces données se trouvent. Et c’est légitime, car le consommateur final ne saurait, et ne devrait pas, connaître la complexité de sa requête, comme l’emplacement des données. Mais seul le mainframe peut offrir la performance et la sécurité dans un environnement hybride.

Les mainframes peuvent ingérer des données où qu’elles soient, les analyser, et les rapporter, avec recommandations, mieux que toute autre plateforme, et plus rapidement. Montrez-moi un autre système capable d’ingérer des données provenant d’un réseau mondial, de les analyser, de détecter des anomalies en temps réel, et de 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 en cash. Quand les innovateurs rejettent les mainframes comme systèmes hérités, ils rejettent leur vitesse, leur puissance, et leur capacité à traiter d’énormes quantités de données à la vitesse requise pour la détection de risques en temps réel.

Les gens pensent que le cloud a révolutionné et modernisé, et que les mainframes sont dépassés en comparaison. Le concept de cloud computing sur un réseau est en effet moderne et révolutionnaire pour beaucoup. Mais si vous connaissez la technologie mainframe, vous reconnaîtrez qu’elle partage de nombreuses caractéristiques avec le cloud. Par exemple, lorsque vous vous connectez au mainframe, vous vous connectez à TSO, pour « time sharing option ». Vous avez votre propre session TSO, ou une instance de Microsoft Teams.

Vous utilisez tous les mêmes processeurs sur le mainframe. Mais lorsque vous n’exécutez pas un programme ou un travail batch, la capacité est allouée à ceux qui en ont besoin. Vous vous connectez aussi à une LPAR, ou partition logique, avec stockage dédié, sécurité et confidentialité. Les utilisateurs d’une même LPAR ne peuvent pas accéder aux données d’une autre LPAR, sauf configuration spécifique. C’est ce que le cloud est à sa base : partager des ressources quand on ne les utilise pas, et sécuriser les données dédiées à votre instance. Mais le mainframe utilise ces concepts depuis des années.

2. L’infrastructure hybride — mêlant mainframes et couches cloud plus récentes — devient la norme. D’après votre expérience, quels sont les véritables facteurs de risque lorsque les organisations tentent de moderniser trop rapidement ou de manière superficielle ?

Parmi les nombreux risques, je peux en résumer 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. Lorsqu’on les sort du mainframe ou qu’on les rend visibles à quelqu’un qui les ingère, il y a un risque pour la confidentialité et la conformité réglementaire. Qui regarde ces données ? Où vont-elles lorsqu’elles quittent le mainframe ?

Le second 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. La latence et les problèmes de performance peuvent nuire à la productivité.

3. Vous avez lancé l’alerte sur un déficit de compétences en expertise mainframe. À quel point le risque institutionnel est-il sérieux lorsque moins d’ingénieurs savent comment exploiter et sécuriser ces systèmes dont les institutions financières dépendent encore ?

Le risque est grave. Les développeurs plus récents — pas seulement les jeunes, mais aussi ceux qui débutent dans l’industrie — apprendront et développeront leur expertise. Mais jusqu’à ce que la prochaine génération rattrape son retard, il y aura une vulnérabilité dans les institutions financières, car la connaissance institutionnelle ne sera pas aussi approfondie qu’elle devrait l’être.

Les personnes avec une expérience ou une connaissance superficielle peuvent, sans le vouloir, causer des risques pour les données ou le système d’exploitation. Ces systèmes sont résilients et disposent de plusieurs couches de protection contre l’erreur humaine, mais il y a toujours un certain risque tant que les compétences ne sont pas au niveau requis. Les banques luttent déjà contre ce déficit aujourd’hui.

4. Les discussions sur la sécurité se concentrent souvent sur les outils, mais vous avez souligné que ce sont toujours les personnes qui sont en première ligne. Quelles sont, selon vous, les zones d’ombre opérationnelles qui apparaissent le plus souvent dans la gestion des environnements mainframe ?

La gestion des environnements pertinents tourne généralement autour des permissions élevées. Lorsqu’un ingénieur logiciel écrit du code, il a parfois besoin d’une permission élevée pour faire quelque chose de spécifique au système d’exploitation, comme activer une fonction plus sensible. Si l’ingénieur ne comprend pas bien les bonnes pratiques lors de l’écriture du logiciel, il ne saura pas quand entrer ou sortir de cet état autorisé élevé. Cet état comporte plus de risques, donc les ingénieurs ne restent pas longtemps dans cette situation pour bien comprendre les bonnes pratiques.

Il existe aussi des principes fondamentaux de sécurité à appliquer dans tout réseau informatique. Lorsqu’on donne une autorisation spéciale à quelqu’un dans un rôle précis, il faut un processus clair pour retirer cette autorisation lorsqu’il change de rôle, afin d’assurer la suppression de l’accès. La plupart du temps, ce n’est pas un problème, s’ils sont encore employés ou si ce n’est pas un acteur malveillant. Mais il y a toujours un risque si l’on laisse 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 du mainframe permettent aux utilisateurs d’effectuer des opérations fondamentales sur un système. On ne veut donner accès à ces fonctions qu’à certains utilisateurs. Par exemple, certains contrôles de sécurité ne peuvent être modifiés qu’au niveau profond du système d’exploitation. Vous seriez surpris de voir combien d’entreprises laissent des principes de sécurité de base non respectés. Il existe des moyens pour les ingénieurs de faire leur travail sans avoir accès à ces ressources racine, mais il est plus facile d’avoir ce niveau d’accès, donc les entreprises laissent souvent la porte dérobée ouverte plus que nécessaire.

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’accès, 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 disposent de couches de sécurité intégrées que la plupart des serveurs ne possèdent pas. Juste parce que vous pouvez vous connecter au mainframe ne signifie pas que vous avez accès aux données critiques de l’entreprise, qui sont généralement ce que le ransomware verrouille. Il faut alors savoir où se trouvent ces données, et comment y accéder. Et ces données peuvent être compartimentées, de sorte qu’un intrus n’a accès qu’à un segment, et pas à tout ce dont il aurait besoin pour réussir une attaque par ransomware. 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 une modernisation efficace pour les institutions financières qui ne peuvent pas se permettre de « déchirer et remplacer » mais doivent se préparer à l’avenir ?

La modernisation signifie différentes choses selon les entreprises, en fonction de l’état de leurs applications. Que ce soit B2B ou B2C, les entreprises modernisent en continu, en mettant à jour serveurs et ordinateurs portables.

Il en va de même pour les applications critiques pour l’entreprise. Une entreprise peut mettre à jour périodiquement ces applications, mais comme les applications mainframe traditionnelles ont été développées il y a plusieurs générations, la meilleure chose à faire est d’évaluer complètement ce que chaque application fait de bout en bout. Ainsi, elles peuvent phaser leur modernisation en morceaux gérables.

Les entreprises peuvent compartimenter une application, la diviser en parties pour que ses différentes fonctionnalités soient mises à jour et réécrites lentement, au fil du temps, selon leur budget. Si vous voyez la modernisation comme un processus continu, l’envie d’améliorer et d’itérer devient constante.

Les dirigeants doivent toujours adopter une mentalité proactive. Les questions devraient ê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éécrire tout cela ? »

Il faut faire évoluer les systèmes et les construire progressivement. Commencez par réécrire une fonctionnalité d’une application critique, puis ajoutez le reste au fur et à mesure. Phaser les changements petit à petit.

Le « déchirer et remplacer » est une option. Cela peut sembler brutal, mais cela signifie simplement arrêter d’utiliser un système pour en utiliser un autre. Mais la direction doit avoir le courage d’un changement majeur d’un seul coup, et approuver le budget. En réalité, c’est plus une question de « remplacement », car cela peut prendre des années pour achever la procédure.

7. Pour les responsables techniques issus d’une mentalité cloud-first, quelle serait, selon vous, la transformation la plus importante dans leur façon de penser lorsqu’ils abordent des systèmes mainframe critiques ?

Apprenez ce que le mainframe fait réellement. La règle d’or, selon le serment d’Hippocrate, est de ne pas faire de mal, donc comprenez ce dont le mainframe est responsable pour éviter de commettre des erreurs nuisibles. Une fois que ceux qui ont une mentalité cloud-first comprennent la totalité des transactions qui entrent dans le mainframe, leur nature, et combien le chiffre d’affaires de leur entreprise dépend de ces transactions, ils comprendront et sauront comment éviter de nuire à la performance et à la rentabilité de leur société.

À propos de Jennifer Nelson

Jennifer Nelson a passé la majeure partie de sa carrière dans le domaine du mainframe, dont 15 ans chez Rocket Software et cinq ans chez BMC. En 2019, elle a évolué vers des rôles d’ingénierie senior dans des entreprises technologiques mondiales en dehors de l’écosystème Z, élargissant ainsi sa perspective et ses compétences. Début 2024, Nelson a commencé à poser les bases de ce qui deviendrait Izzi Software, une société axée sur l’acquisition et la croissance d’entreprises de logiciels bâties sur les plateformes IBM Z et IBM Power.