Hervé Deschamps
(Steria) : "
"SwiftNet engendre des problématiques de sécurité qui n'existaient
pas jusqu'alors""
Par le JDNet
Solutions (Benchmark Group)
URL : http://www.journaldunet.com/solutions/itws/020919_it_steria.shtml
De début avril à mi-mai 2003 ainsi que les
trois premières semaines de septembre la même année. Telles sont les
fenêtres définies par le consortium Swift pour le basculement des
banques françaises vers la nouvelle version du système de transactions
interbancaires du même nom. Rebaptisée pour l'occasion SwiftNet, cette
édition se caractérise, rappelons-le, par l'adoption de XML
comme format d'échange de données, mais également par le passage
du protocole X.25 à IP. Dans cette interview, Hervé Deschamps, responsable
de l'activité Messagerie bancaire de la SSII Steria, pointe les principaux
enjeux techniques relatifs à cette migration, et les quelques règles
à mettre en uvre pour y faire face.
Propos recueillis par Antoine Crochet Damais le 19/09/2992
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.
Steria: les outils
proposés pour la gestion des transactions Swift
Pour répondre aux problématiques d'échanges
de données financières, Steria propose un middleware
d'intégration baptisé Stelink. Basé
sur des mécanismes de transformation et de routage de messages,
cet outil est conçu pour connecter des applications diverses
(autour de la gestion des paiements, de l'échange de
titres ou du crédit documentaire) à divers systèmes
de gestions de transactions financières - tels que SwiftNet
ou encore les réseaux SIC et SECOM. "Nous commercialisons
également une solution de Gateway permettant de
partager un accès à SwiftNet entre plusieurs applications",
complète t-on chez Steria. Objectif de ces offres :
fournir des produits alternatifs à ceux de Swift... pour
faciliter les déploiements et renforcer les performances
d'exécution notamment. "Sans compter les capacités
d'adaption de ces solutions en fonction des besoins client",
pointe pour finir Hervé Deschamps. |
Pour tout problème de consultation, écrivez au Webmaster
Copyrights
et reproductions . Données
personnelles
Copyright 2006 Benchmark Group - 69-71 avenue Pierre Grenier
92517 Boulogne Billancourt Cedex, FRANCE
|
|
|