Changer de plateforme marchés sans gripper le front-to-back : les signaux faibles à traiter tôt

Dans un remplacement d'outil front-to-back, le dérapage ne commence presque jamais au moment du cut-over. Il apparaît plus tôt, dans les angles morts d'un pilotage de projet SI en banque de financement, quand la trajectoire semble propre sur le papier et déjà fragile dans les faits.

Les premiers symptômes d'un programme mal engagé

Un projet de Murex, de Calypso ou de Summit ne déraille pas seulement parce que la technologie est lourde. Il déraille quand on confond installation de solution et transformation de chaîne opérationnelle. C'est un biais classique. Le planning affiche des lots, des jalons, des dépendances. Mais personne n'arrive encore à décrire, avec une précision tranquille, ce que devient une opération complexe entre le front, le middle, le back office, le risque, la comptabilité et les référentiels.

Premier signal faible : le business case parle surtout d'obsolescence. C'est recevable, bien sûr, mais insuffisant. Si la justification ne relie pas clairement la cible aux processus, aux contraintes réglementaires, aux impacts de contrôle permanent ou aux coûts de support, le programme manque déjà d'ossature.

Deuxième signal : les ateliers de cadrage restent trop génériques. On parle produits, grandes fonctions, architecture cible. En revanche, les exceptions - novations, restructurations, corrections tardives, reprises de données sensibles, gestion des breaks - sont repoussées à plus tard. Or, c'est souvent là que se logent les vrais risques d'une migration Calypso ou d'un projet Murex qui dérape.

Troisième symptôme, plus discret : la gouvernance est complète sur l'organigramme et incomplète dans la décision. Les sponsors existent, les comités aussi, mais les arbitrages entre métiers, opérations et IT restent flous. En pratique, cela produit des validations tardives, donc des reconfigurations coûteuses.

Ce qui se casse entre les équipes avant même la bascule

Le front-to-back n'est pas une ligne droite

Dans la banque de financement, une plateforme marchés n'est jamais seule. Elle vit dans un tissu dense : référentiels de contreparties, données de marché, moteurs de calcul, outils de risques, comptabilité, reporting réglementaire, parfois solutions locales héritées de plusieurs vagues d'organisation. Parler d'intégration de solution marchés comme d'un simple sujet d'interfaces est, disons-le franchement, une erreur de cadrage.

Le point sensible n'est pas seulement le nombre de flux. C'est la cohérence fonctionnelle des événements. Une même transaction doit être comprise, enrichie, valorisée, rapprochée et comptabilisée sans perdre son sens en route. Quand les équipes n'ont pas aligné très tôt le dictionnaire de données, les statuts de cycle de vie et les règles de gestion des exceptions, le projet avance avec une sorte de buée sur le pare-brise.

C'est précisément ce que nous regardons dans des missions de gestion de projet et de Corporate & Investment Banking : non pas la seule conformité du plan, mais la qualité des coutures entre métiers, fonctions et technique.

Les opérations découvrent trop tard la cible réelle

Beaucoup de programmes associent correctement le front office et l'IT. Les opérations, elles, arrivent souvent au moment des recettes détaillées ou de la préparation au changement. C'est trop tard. Le back office n'est pas un simple point de passage, et le middle office encore moins un sas administratif. Ce sont des lieux de contrôle, d'interprétation et parfois de rattrapage. Si leurs irritants quotidiens n'ont pas été pris en compte au cadrage, la cible sera théoriquement élégante et opérationnellement bancale.

On le voit vite dans les ateliers : personne ne sait chiffrer le volume d'exceptions, les corrections manuelles sont mal documentées, les SLA implicites ne sont écrits nulle part. Pourtant, ce sont eux qui absorbent les chocs de migration.

Quand les référentiels bloquent une trajectoire pourtant bien financée

Une banque d'investissement avait validé un programme de remplacement progressif, avec budget sécurisé et sponsor solide. Sur le papier, le plus dur semblait fait. Le point de friction est apparu ailleurs, presque banalement : un référentiel d'instruments vieillissant, enrichi par couches successives, ne portait pas les attributs attendus par la nouvelle plateforme. Les opérations continuaient d'ailleurs à compenser ce manque à la main, un champ ajouté dans un fichier, une règle tacite, rien de très visible.

La difficulté n'était pas technique au sens noble. Elle était organisationnelle et fonctionnelle. Tant que ce référentiel restait hors périmètre, la trajectoire de migration tenait en apparence. Dès qu'il a fallu préparer les tests de bout en bout, la chaîne s'est grippée : valorisation incohérente, contrôles de booking incomplets, écarts en aval. Nous sommes intervenus sur le pilotage de projet pour requalifier le périmètre utile, puis sur le séquencement des chantiers dépendants. Le programme n'a pas été relancé par un miracle méthodologique, simplement par un retour au réel. C'est souvent plus efficace.

Ce qu'il faut arbitrer avant de choisir entre évolution et remplacement

L'arbitrage entre faire évoluer l'existant et remplacer complètement la plateforme ne devrait jamais se limiter au coût du projet ou à la dette technique visible. Il faut comparer au moins cinq dimensions.

1. La couverture fonctionnelle réelle, y compris les cas dégradés et non les seules opérations nominales.
2. La soutenabilité opérationnelle : volume de corrections manuelles, dépendance aux experts clés, capacité de support.
3. La robustesse des données : qualité des référentiels, traçabilité, gouvernance de la donnée.
4. La dépendance aux interfaces : chaque contournement réduit la valeur de la cible.
5. La capacité de décision du programme : sans arbitrage rapide, même une bonne cible se décompose.

Un cadrage sérieux doit aussi intégrer le contexte réglementaire et de contrôle. Les attentes des autorités, qu'il s'agisse de l'ACPR ou de l'AMF, renforcent la nécessité d'une chaîne explicable, documentée et gouvernable. Ce n'est pas un supplément de conformité. C'est une condition de pilotage.

À ce stade, l'apport d'un acteur indépendant compte vraiment. Sur des programmes sensibles, nous voyons souvent qu'un regard extérieur permet de distinguer ce qui est compliqué de ce qui est confus. Les deux se traitent différemment, et l'erreur de diagnostic coûte cher.

Le bon cadrage ne cherche pas à tout prévoir

Avant le lancement, il faut une cible assez claire pour décider, mais assez honnête pour laisser apparaître les inconnues. Les programmes qui tiennent sont rarement ceux qui promettent une trajectoire lisse. Ce sont ceux qui rendent visibles, très tôt, les points de tension sur les données, les rôles, les contrôles et les dépendances. Si vous préparez une évolution de plateforme marchés, nous pouvons vous aider à objectiver ces risques, du cadrage jusqu'au pilotage d'ensemble, avec une lecture indépendante des enjeux métier et SI. C'est souvent là que se joue la suite, bien avant la migration elle-même.