JDNet Solutions. Quelles sont les problématiques techniques d'un projet de migration vers SwiftNet ?
Hervé Deschamps. Une migration de Swift vers SwiftNet et les évolutions techniques qui l'accompagnent, l'abandon du protocole X.25 pour IP notamment, nécessitent en premier lieu de s'adosser à une architecture différente. Ce qui demande de faire des choix à la fois en termes de logique applicative (logiciels et serveurs), et de solutions matérielles. Sur le terrain de la sécurité, le passage à IP engendre également des questions qui ne se posaient pas avec un réseau X.25. Comment s'intégrer au système existant ? Doit-on ou non isoler les connexions IP ? Si un filtrage est mis en place, par le biais d'un pare-feu par exemple, comment définir la politique en la matière (règles d'autorisation, etc.) ? Enfin, ce projet peut être l'occasion pour les banques de centraliser leurs accès au réseau SwiftNet en un seul point.

[voir également l'interview de Caroline Khechen de BIS Finance].

Le déploiement des services commercialisés par Swift lors du lancement de SwiftNet est-il une priorité ?
Il est vrai que certaines banques prévoient d'ores et déjà de tirer partie de ces nouveautés. Mais, cette préoccupation est loin d'être prioritaire pour la plupart d'entre-elles. L'élément à privilégier restant la migration des services existants. Si l'on prend l'exemple du Continuous Linked Settlement - qui offre des garanties autour des transactions sur les échanges de devises -, seule une quarantaine de banques dans le monde ont choisi d'y souscrire. Parmi elles, figurent pour l'heure quatre établissements français.

Quelle est la méthodologie que vous préconisez dans le cadre d'un tel projet ?
Nous conseillons d'abord de réaliser une étude préalable. Ce travail à pour but de faire le point sur l'existant informatique de l'entreprise, puis de cerner ses besoins. Il aboutit à la définition de plusieurs solutions d'architecture possibles - qu'elles soient matérielles et logicielles. L'examen des avantages et inconvenants de chacune d'elle permet aux clients de faire son choix...

Ensuite vient la phase d'intégration, chantier qui peut donner lieu dans certains cas à des adaptations nécessitant des développements significatifs.

Quant à la phase de tests...
Elle se découpe principalement en deux étapes. Purement technique, la première vise notamment à éprouver la capacité des plates-formes à faire face à des montées en charge sans souffrir de baisses de performance significatives. Sur ce point, les banques affichent la plupart du temps des pré-requis clairement définis. Comme cela est classiquement préconisé pour ce genre d'architecture, nous conseillons de sur-dimensionner les capacités machine (mémoire et processeur) en vue d'amortir d'éventuels pics de trafic. Mais aussi de déployer un système évolutif afin de pouvoir s'adapter aisément en cas d'augmentation du nombre de transactions.

La seconde étape concerne les tests fonctionnels. Il s'agit ici d'accompagner la prise en main opérationnelle de la solution. Une tâche qui passe notamment par la mise en conformité des procédures de la banque (au regard de la nouvelle solution), et la formation des utilisateurs finaux.

...et pour finir l'étape de mise en production ?
Idéalement, cette dernière phase doit être définie dès l'étude préalable sous la forme d'un plan de migration. Un document qui détaille aussi bien le planning que l'organisation à mettre en oeuvre. En général, il se décline selon deux stratégies possibles : soit un basculement de type "big bang", soit une migration étalée dans le temps - qui peut s'effectuer par points d'accès ou par adresses Swift (BIC). Cette deuxième option peut se révéler indispensable dans le cas d'une banque possédant des dizaine de passerelles réparties sur plusieurs implantations.