Scor rénove entièrement son système de gestion des transactions bancaires

le 19/04/2012 L'AGEFI Hebdo

Pour pallier la fin d’Etebac, Scor bascule sur le réseau de messagerie interbancaire Swift et adopte une nouvelle technologie de signature électronique.

A l’annonce du décommissionnement d’Etebac 5, nous nous sommes interrogés sur la possibilité de continuer à bénéficier d’échanges dématérialisés et sécurisés avec les banques, assortis d’une signature personnelle», raconte Martial Brouard, responsable de la trésorerie du hubde Paris chez Scor. Le protocole Etebac (Echange Télématique Banque Clients) servait aux échanges informatiques (virements, prélèvements, extraits de compte, relevés...) entre les établissements bancaires et leurs clients. Début 2009, France Télécom annonçait, pour 2011, l’arrêt de la maintenance du réseau télécom X25, également appelé Transpac. Cela signifiait l’arrêt de mort du protocole Etebac. Même si la date a depuis été repoussée à juin 2012, les 95.000 entreprises françaises utilisatrices d’Etebac n’ayant pu être prêtes à temps, la recherche de solution de remplacement apparaissait impérative. En novembre 2008, le CFONB (Comité français d’organisation et de normalisation bancaires) avait préconisé deux protocoles de communication banque/entreprise, Ebics (Electronic Banking Internet Communication Standard) et SwiftNet File Act, un service de messagerie dédiée et ultra-sécurisée de l’opérateur belge Swift.

«Lors de l’annonce du décommissionnement d’Etebac, il n’existait pas vraiment d’alternative à Swift, souligne Martial Brouard. Ebics, protocole franco-allemand, ne correspondait pas à notre périmètre d’activité.» Le hub de Paris de Scor assure en effet la gestion des flux de réassurance pour les zones de Paris, Zurich, Londres, Cologne, Milan ou encore Madrid. Scor décide donc d’opter pour la solution SwiftNet. Seul problème, lorsque Scor a lancé son appel d’offres en 2010 pour sélectionner un prestataire capable de basculer l’ensemble de ses flux financiers sur le réseau de Swift, celui-ci ne disposait pas encore d’une solution technologique permettant de signer et d’authentifier les messages échangés. «Le groupe ne voulait pas d’une nouvelle technologie qui aurait entraîné une régression du niveau de sécurité, à savoir la disparition de la signature personnelle remplacée par une validation directement dans le système d’information dédié, expose Martial Brouard. Une validation qui serait de fait unilatérale, car les banques ne peuvent alors plus exercer les mêmes niveaux de contrôle sur les transactions émises et notamment sur la validité des pouvoirs bancaires des personnes ayant approuvé les flux.»

Une technologie très récente…

La technologie de signature électronique de Swift, 3SKey, a été lancée après que Scor a sélectionné, à l’issue de son appel d’offres, l’éditeur suisse de solutions de connectivité bancaire Sterci (lire l’entretien). « La solution 3SKey est arrivée plus tard et n’était pas forcément maîtrisée par l’ensemble des banques de la place, rapporte Martial Brouard. Nous avons décidé de mener de front la migration vers SwiftNet et l’intégration de 3SKey. » Comme la solution technique de signature électronique 3SKey n’existait pas encore au sein des produits Sterci, un cahier des charges commun a été élaboré décrivant les processus, les écrans, les fonctionnalités, les différentes étapes de validation, les interfaces entre les différentes applications du système d’information de Scor. Celui-ci comprend les outils de comptabilité Psoft et Oméga, les outils de trésorerie KTP et des briques technologiques développées par Sterci, comme GTMatch, le logiciel de réconciliation, GT Frame qui convertit les fichiers au format XML et GT Exchange pour la validation avant l’envoi des fichiers aux banques. « En termes de fonctionnalités, par exemple, nous voulions pouvoir continuer à constituer des lots de règlements, relate Martial Brouard. Ainsi, pour une entité émettant 100 paiements sur un ‘request type’ (format de fichier, NDLR) identique, il devait être possible de voir le détail des transactions et de valider en une seule fois le lot. » Cela a été structurant dans le choix du type de messagerie Swift : l’outil Fin ne permettant pas cette mise en lots et ne supportant pas la 3skey, les équipes de Scor se sont logiquement orientées vers Fileact. « De plus, cette fonctionnalité était une demande des fondés de pouvoir Scor », confirme Martial Brouard.

Au début du projet, en 2010, Scor décide de travailler avec BNP Paribas et Natixis comme contreparties bancaires. Quatre types de flux doivent être traités : les flux de trésorerie, pour les virements de banque à banque, les flux Sepa (Single Euro Payments Area), pour les paiements en euros au sein de la zone Sepa, les flux internationaux, pour les paiements hors zone Sepa et les paiements en devises au sein de la zone Sepa, enfin les flux délocalisés correspondant aux paiements émis vers BNP Paribas « pour instructions sur nos comptes BNP Paribas Fortis à Bruxelles, cela nous évitant de faire des tests supplémentaires puisque cet établissement fait partie du groupe BNP Paribas », précise Martial Brouard.

… nécessitant des tests très poussés

Détail qui a son importance car les tests ont constitué une part très significative du projet. Six mois ont été nécessaires entre mars et septembre 2011, date des premiers tests en production. «La technologie mise en œuvre étant nouvelle, nous voulions des tests très poussés», explique Martial Brouard. Une des difficultés a été le manque de visibilité quant à la disponibilité des différentes plates-formes de tests fournies par les établissements bancaires. Celles-ci ne disposaient pas du même niveau de performance et de maintenance que les plates-formes de production bancaire. «La période estivale a été compliquée à gérer, raconte Martial Brouard. On envoyait un fichier qui n’arrivait pas et comme nous étions en phase de tests, l’identification de l’erreur générée pouvait être compliquée.» Dans un premier temps ont été testés la communication, les formats de fichiers, puis la signature 3SKey. Il a fallu, par exemple, valider le format des messages XML envoyés vers les banques comme étant conforme aux spécifications Sepa ainsi qu’à la norme ISO 20022 (norme mondiale d’échanges de messages dans le secteur financier). «Cela a nécessité un jeu de tests complexes car le format XML est d’interprétation variable entre les différentes contreparties bancaires», souligne Martial Brouard. Chaque flux a été testé de façon unitaire et par lots. En parallèle des tests, il a fallu mener des démarches administratives, comme l’obtention d’un code BIC (code d’identification bancaire au sein du réseau Swift) pour Scor. «Tout doit être géré de front. Ainsi, si l’enrôlement 3SKey des fondés de pouvoir n’est pas effectué suffisamment en amont dans le projet, il est impossible de continuer les tests impliquant la signature électronique, insiste Martial Brouard. Aujourd’hui, nous sommes en phase de production, tous les ‘penny tests’ (en conditions réelles pour un montant d’un centime, NDLR) ont été réalisés sur la quasi-totalité des flux et de nos comptes.» Une fois prise la décision de basculement en production, il n’y aura pas de période de transition entre Etebac et SwiftNet. «Elle serait trop difficile à gérer pour les équipes informatiques de Scor: aiguiller tel flux sur Etebac, tel autre sur SwiftNet», conclut Martial Brouard.

A lire aussi