Résumé

  • Murex a annoncé le 23 septembre la certification de MX.3 sur Google Cloud. Cette destination s’ajoute à une trajectoire cloud déjà associée à Azure et AWS. Le communiqué mentionne des clients en phase d’exploration, sans nommer de mise en production, de délai de migration, de prix, de référence de performance ni de résultat de reprise.
  • La certification réduit le coût d’étude d’une autre infrastructure. Elle ne transporte pas automatiquement les positions validées, le collatéral, l’heure de marché, les droits, les acquittements d’interface ou l’ordre de clôture. La banque ne possède une véritable option de sortie que si elle sait restaurer et rapprocher ces éléments dans son délai admissible.

Une architecture de continuité peut accueillir une nouvelle case en quelques heures. Un livre de marché vivant ne se déplace pas aussi vite. Pour reprendre, il faut savoir quel lot de prix a servi aux valorisations, quelles opérations ont été confirmées, où se trouve le dernier mouvement de collatéral, quelles instructions de paiement ont franchi leur point d’irréversibilité et jusqu’où la chaîne de fin de journée a été acceptée. Deux environnements disponibles peuvent raconter deux histoires comptables différentes.

C’est à cette échelle qu’il faut lire le communiqué de Murex du 23 septembre. MX.3 est désormais certifié sur Google Cloud. L’annonce vise les activités de trading, de trésorerie, de risque et de post-marché, y compris des calculs exigeants de risque de marché, de contrepartie et d’analyse intrajournalière. Murex indique que plusieurs clients explorent cette possibilité.

L’information crée une option crédible. Elle ne constitue pas encore un trajet exécuté. Aucun client de production n’est identifié ; aucun calendrier, coût, RPO, RTO, couple de régions ni rapprochement après reprise n’est publié. La destination est supportée. La capacité d’une banque donnée à y arriver avec un état métier intact reste à démontrer.

Une troisième destination vaut d’abord comme option

Le cloud n’est pas nouveau pour MX.3. Murex a annoncé une certification Azure en 2017. Sa présentation actuelle du cloud décrit le support d’AWS et de Microsoft Azure, plusieurs modèles de déploiement et un chemin progressif de la preuve de concept aux environnements de développement, de test puis de production. En 2025, l’entreprise a aussi annoncé un accord pluriannuel avec AWS centré notamment sur les services managés.

Google Cloud ajoute donc une valeur d’option. Lors d’une nouvelle implantation, la banque peut mettre en concurrence davantage d’offres d’infrastructure, de régions, de sécurité et d’exploitation. Un client existant peut réexaminer l’emplacement de ses développements, de son secours ou de ses grilles de risque élastiques. Murex ouvre un canal de vente et de support ; Google accède à des traitements proches du cœur opérationnel des institutions financières.

Cette valeur peut exister avant tout basculement de production. La concurrence commerciale s’améliore, un environnement de test devient plus facile à créer puis à arrêter, un calcul de risque peut s’étendre ailleurs. Mais ces mobilités ne sont pas équivalentes. Déporter une grille n’échange pas automatiquement le système d’enregistrement complet. Ajouter un site de secours ne garantit pas que son livre soit ouvrable. Le choix d’achat et la faculté de sortie sont deux actifs distincts.

Le modèle de service doit lui aussi rester précis. Le communiqué AWS décrit MXSaaS comme une offre gérée par Murex depuis l’infrastructure jusqu’aux mises à niveau, et distingue XVA as a Service. Le texte sur Google Cloud parle du déploiement de MX.3 ; il n’annonce pas MXSaaS sur Google Cloud. Une certification, une infrastructure gérée par le client et un service managé industrialisé répartissent différemment l’exploitation et la responsabilité.

MX.3 est une séquence métier, pas un conteneur fermé

La description de l’architecture MX.3 présente plusieurs niveaux : interface, fonctions métier, orchestration et services techniques. Ce dernier niveau couvre notamment l’authentification, l’autorisation et le registre de services. Les calculs font appel à différentes technologies ; la valorisation complexe peut utiliser des grilles CPU ou GPU ; Kubernetes et les conteneurs interviennent pour le risque de marché et le reporting.

L’emploi de conteneurs sur certains calculs ne rend pas l’ensemble interchangeable. Une installation ancienne concentre des configurations de produits et de livres, des données de référence et de marché, des certificats, des clés, des habilitations, des interfaces, des dépendances de traitements, des seuils d’alerte et des files d’exception. Une partie de l’ordre opérationnel n’est inscrite ni dans le code ni dans un schéma : elle vit dans les contrats de données, les fenêtres de règlement, les procédures et l’expérience des équipes.

Il faut donc distinguer quatre portabilités. Celle de l’infrastructure permet de recréer calcul, stockage et réseau. Celle de l’application permet d’exécuter les composants et versions supportés de MX.3. Celle des données conserve un état complet, ordonné et doté du même sens. Celle de l’exploitation permet aux équipes de sécuriser, rapprocher, reprendre et gouverner le service dans le nouveau partage des tâches.

La certification renseigne fortement les deux premiers niveaux. Elle ne prouve pas les deux derniers pour un client. Ceux-ci dépendent des services natifs choisis, de la construction des interfaces, de la garde des clés et de l’historique d’observation, de la propriété des procédures et de l’existence d’un exercice réel sur la destination alternative.

Le bien rare est le dernier état métier accepté

Redémarrer des processus ne suffit pas. Une opération importée deux fois gonfle l’exposition. Un transfert de collatéral reconnu d’un côté mais absent de l’autre provoque un litige. Une photographie de marché prise au mauvais instant change la valorisation et les limites. Un paiement déjà relâché ne peut pas être traité comme une instruction encore en attente.

Le paquet de sortie doit contenir davantage que des fichiers de base de données : un point de reprise déclaré, des journaux ordonnés, l’origine des objets, l’état des messages en transit, les acquittements externes, les dépendances de traitements et les règles de rapprochement. Il faut nommer la source faisant autorité pour chaque objet et la personne habilitée à trancher un conflit. Version logicielle, configuration, droits et preuve d’approbation font partie de l’état.

Une banque peut donc savoir recréer des machines équivalentes sans savoir rétablir un service exploitable. Les bases, identités, files, outils d’observation, clés ou contrôles réseau propres au fournisseur améliorent souvent la production courante tout en agrandissant la surface à reconstruire. Renoncer à toute fonction native serait parfois coûteux et moins fiable. Le bon arbitrage consiste à documenter, chiffrer, attribuer et tester chaque dépendance.

Un premier exercice crédible peut rester limité. L’établissement choisit un service important et un scénario de rupture, restaure l’application et ses dépendances sur l’autre destination, reconnecte un ensemble contrôlé de données et d’interfaces, puis rapproche positions, espèces, collatéral, sensibilités, confirmations et sorties comptables avec une référence approuvée. Le temps, les gestes manuels, les pertes, les exceptions et l’autorité qui accepte le résultat doivent être consignés.

Le règlement exige une sortie, pas seulement une adresse de repli

Pour les entités financières européennes concernées, l’article 28 de DORA donne une portée concrète à cette distinction. Lorsque des services TIC soutiennent une fonction critique ou importante, l’entité doit prévoir une sortie sans perturber ses activités, sa conformité ni la continuité offerte aux clients. Les plans doivent être complets, documentés, suffisamment testés et revus périodiquement. Ils doivent prévoir des solutions alternatives ainsi qu’un transfert sûr et intégral des services et données, ou leur réinternalisation.

DORA ne certifie ni MX.3 ni un dessin Google Cloud. Il n’impose pas non plus l’exécution permanente de chaque charge chez plusieurs fournisseurs. Il maintient la responsabilité chez l’établissement financier. Le support d’une autre destination par l’éditeur facilite le travail, mais ne remplace pas la preuve de sortie du client.

Les travaux de la Banque d’Angleterre sur la résilience opérationnelle rappellent par ailleurs que l’externalisation et la dépendance à un petit nombre de tiers créent des interconnexions dans le système financier. Une certification supplémentaire réduit la concentration sur une carte d’achat. Elle ne réduit la concentration réelle que si le service peut être déplacé ou restauré dans un délai tolérable.

Chaque modèle d’exploitation redessine la responsabilité

Murex maîtrise la certification logicielle, les schémas supportés, les versions et une partie de la méthode technique. Google Cloud exploite ses régions, sa capacité, son réseau et ses produits managés. Un intégrateur peut construire l’environnement, automatiser le déploiement et prendre en charge une partie de l’exploitation. Dans une offre managée, le fournisseur porte encore davantage de tâches courantes.

La banque conserve pourtant la définition du service métier. Elle classe sa criticité, fixe les objectifs de reprise, approuve les architectures de données et d’identité, contracte les liaisons vers les marchés, valide les rapprochements et rend compte à son conseil et aux superviseurs. Externaliser le travail ne délègue pas le sens d’une position restaurée.

Une matrice doit donc couvrir le régime normal et la sortie. Qui maintient le code d’infrastructure ? Qui exporte la configuration, les journaux et les preuves ? Qui fournit les licences pendant la transition ? Qui ouvre les flux, change les clés et valide les données de marché ? Qui autorise la reprise des transactions ? Quelle assistance subsiste après résiliation ? Le communiqué de partenariat ne répond pas à ces questions propres au client.

Le choix peut d’abord renforcer le verrouillage

Une destination certifiée crée un paradoxe. Les équipes l’adoptent parce que ses fonctions natives accélèrent la livraison ; les données, la sécurité et la surveillance deviennent ensuite plus étroitement liées au fournisseur. La production peut gagner en qualité tandis que sa reproduction ailleurs devient plus chère. Cet échange peut être rationnel, mais le nombre de certifications mesure mal le coût de sortie.

L’effet inverse est possible si Murex fournit des artefacts de déploiement portables, plusieurs choix de base, des frontières claires entre composants et des preuves opérationnelles communes. Chaque certification peut alors standardiser la route. Les migrations répétées nourrissent un marché de partenaires compétents et des outils réutilisables. Les reçus d’exécution valent plus que la collection de logos.

La portée des premiers cas sera le meilleur révélateur. S’agit-il du développement et du test, d’une grille de risque, du secours, de la production ou de toute la chaîne front-to-back-to-risk ? Une reprise devrait nommer le service, le point de retour, le temps écoulé et le résultat du rapprochement. Une sortie devrait ajouter les formats, l’assistance contractuelle, les effectifs, les interfaces et le coût complet.