Un système d'information bâti sur une architecture multi-serveurs et le choix de la réplication de données en temps réel grâce à l'outil Transformation Server de DataMirror donne à Axa Banque les clés de sa disponibilité fonctionnelle.
Filiale du Groupe AXA, constituée depuis septembre 2002 à partir de l'infrastructure Banque Directe, AXA Banque est l'une des premières banques du paysage français à proposer ses services historiquement via le canal Internet. Depuis sa création en 1994, 330 000 clients ont été séduits par le modèle "zéro guichet" et par un accès multi-canal aux services bancaires d'AXA Banque. Telle est la carte que joue la banque en ligne pour appuyer une politique de proximité client.
Grâce à un SVI (Serveur Vocal Interactif), le Client accède aux services de Conseillers, spécialistes de l'offre bancaire, disponibles 24/24h du lundi au samedi, couverture largement supérieure à celle des banques offline. Le site web, interface personnalisée après identification, donne aux clients les moyens de traiter un éventail d'opérations simples : virement, ouverture de compte, demande d'envoi d'informations, impression de RIB, etc. Ces opérations sont en partie disponibles sur une application Minitel. Quant aux messages emails provenant du site web, ils bénéficient d'une aide automatique au traitement : une application logicielle route les messages vers une équipe de Conseillers en garantissant un suivi de qualité.
Ainsi, quel que soit le canal traité, "nos clients sont assurés d'une réponse pertinente et rapide, donc d'une qualité de service optimale", souligne Patrick Lepine, responsable systèmes, réseaux et DBA chez AXA Banque.
Et c'est sur ce point que la banque en ligne trouve son réel avantage concurrentiel.
AXA Banque doit donc ses récompenses pour sa qualité de service à une politique commerciale définitivement orientée Client. Et son objectif de réactivité vis-à-vis de ses clients ne pouvait qu'être relayé par ses applications informatiques.
Filiale du Groupe AXA, constituée depuis septembre 2002 à partir de l'infrastructure Banque Directe, AXA Banque est l'une des premières banques du paysage français à proposer ses services historiquement via le canal Internet. Depuis sa création en 1994, 330 000 clients ont été séduits par le modèle "zéro guichet" et par un accès multi-canal aux services bancaires d'AXA Banque. Telle est la carte que joue la banque en ligne pour appuyer une politique de proximité client.
Grâce à un SVI (Serveur Vocal Interactif), le Client accède aux services de Conseillers, spécialistes de l'offre bancaire, disponibles 24/24h du lundi au samedi, couverture largement supérieure à celle des banques offline. Le site web, interface personnalisée après identification, donne aux clients les moyens de traiter un éventail d'opérations simples : virement, ouverture de compte, demande d'envoi d'informations, impression de RIB, etc. Ces opérations sont en partie disponibles sur une application Minitel. Quant aux messages emails provenant du site web, ils bénéficient d'une aide automatique au traitement : une application logicielle route les messages vers une équipe de Conseillers en garantissant un suivi de qualité.
Ainsi, quel que soit le canal traité, "nos clients sont assurés d'une réponse pertinente et rapide, donc d'une qualité de service optimale", souligne Patrick Lepine, responsable systèmes, réseaux et DBA chez AXA Banque.
Et c'est sur ce point que la banque en ligne trouve son réel avantage concurrentiel.
AXA Banque doit donc ses récompenses pour sa qualité de service à une politique commerciale définitivement orientée Client. Et son objectif de réactivité vis-à-vis de ses clients ne pouvait qu'être relayé par ses applications informatiques.
Une architecture multi-serveurs garant d'une haute disponibilité fonctionnelle
Initialement, Banque Directe s'est appuyée sur les applications informatiques du groupe BNP. En 1998, un plan directeur informatique est mis en exploitation, et sonne l'émancipation informatique de la banque en ligne, dont le modèle économique justifie un tel investissement.
A cette époque, une architecture multi-serveurs, à haute disponibilité et asynchrone, apparaît comme l'argument clé dans la perspective de séparer les applications par grands pans.
L'architecture technique se compose alors de la manière suivante :
- Le moteur bancaire SAB, est situé sur une plateforme iSeries ;
- L'application CRM, développée en interne, est positionnée sur une machine Unix. Cette application est la pièce maîtresse de la stratégie orientée Client. Elle a comme vocation de simplifier et fluidifier les échanges des clients avec la banque. Le Client, grâce au SVI, est identifié et orienté vers le premier Conseiller disponible et compétent sur son besoin. Ce dernier accède instantanément à l'historique des échanges et des opérations grâce à un CTI (Couplage Téléphonie Informatique). Ce support informationnel lui permet d'être proactif envers le Client : conseils et offres commerciales ;
- Les applications e-business de présentation des données pour le web, dont les sources de programmation sont en partie identiques à l'application CRM, reposent sur Unix. Les entrées des données sont identiques à l'application CRM, sauf qu'elles sont servies vers un serveur Http ou vers l'application Minitel. Les applications e-business sont celles qui sont en interaction directe avec le Client : le Web, le Minitel et le SVI. Aujourd'hui, 70 % des opérations simples sont traitées via le Web (en majorité) et le Minitel ;
- Le datawarehouse, positionné sur une machine Unix, est le support d'une application décisionnelle (CRM analytique) qui génère des fichiers de ciblage pour actionner des campagnes d'emailing et de SMS, par courrier, ou encore des opérations de télémarketing.
Dans l'optique d'un fonctionnement en mode dégradé, soit en cas d'incident, soit dans une opération de livraison de nouvelle version des applications, l'indépendance forte entre les serveurs s'avère indispensable. Il est par exemple possible d'interrompre l'application à disposition des conseillers, sans interrompre la présentation des données vers le web. Ou bien, en cas de panne du serveur de présentation de données aux clients via le web, le Client peut contacter un Conseiller via le SVI, pour que ce dernier continue les opérations sur le moteur bancaire ainsi que le serveur CRM.
L'indépendance des serveurs est donc non seulement garant d'une continuité de service mais aussi de disponibilité des données.
A cette époque, une architecture multi-serveurs, à haute disponibilité et asynchrone, apparaît comme l'argument clé dans la perspective de séparer les applications par grands pans.
L'architecture technique se compose alors de la manière suivante :
- Le moteur bancaire SAB, est situé sur une plateforme iSeries ;
- L'application CRM, développée en interne, est positionnée sur une machine Unix. Cette application est la pièce maîtresse de la stratégie orientée Client. Elle a comme vocation de simplifier et fluidifier les échanges des clients avec la banque. Le Client, grâce au SVI, est identifié et orienté vers le premier Conseiller disponible et compétent sur son besoin. Ce dernier accède instantanément à l'historique des échanges et des opérations grâce à un CTI (Couplage Téléphonie Informatique). Ce support informationnel lui permet d'être proactif envers le Client : conseils et offres commerciales ;
- Les applications e-business de présentation des données pour le web, dont les sources de programmation sont en partie identiques à l'application CRM, reposent sur Unix. Les entrées des données sont identiques à l'application CRM, sauf qu'elles sont servies vers un serveur Http ou vers l'application Minitel. Les applications e-business sont celles qui sont en interaction directe avec le Client : le Web, le Minitel et le SVI. Aujourd'hui, 70 % des opérations simples sont traitées via le Web (en majorité) et le Minitel ;
- Le datawarehouse, positionné sur une machine Unix, est le support d'une application décisionnelle (CRM analytique) qui génère des fichiers de ciblage pour actionner des campagnes d'emailing et de SMS, par courrier, ou encore des opérations de télémarketing.
Dans l'optique d'un fonctionnement en mode dégradé, soit en cas d'incident, soit dans une opération de livraison de nouvelle version des applications, l'indépendance forte entre les serveurs s'avère indispensable. Il est par exemple possible d'interrompre l'application à disposition des conseillers, sans interrompre la présentation des données vers le web. Ou bien, en cas de panne du serveur de présentation de données aux clients via le web, le Client peut contacter un Conseiller via le SVI, pour que ce dernier continue les opérations sur le moteur bancaire ainsi que le serveur CRM.
L'indépendance des serveurs est donc non seulement garant d'une continuité de service mais aussi de disponibilité des données.
Le besoin de réplication de données en temps réel
Quand bien même, pour des raisons de disponibilité fonctionnelle, les serveurs étaient indépendants et asynchrones, il était nécessaire de synchroniser au plus près les données en direction de l'application CRM et e-business, dans le but, rappelons-le, d'assurer la satisfaction client. Ainsi, lorsqu'une opération de compte à compte était effectuée sur le serveur bancaire, l'opération devait être visible au plus vite dans les applications en interaction avec les conseillers et les clients. Cet aspect était moins critique concernant le datawarehouse, qui fonctionne toutefois quasiment à flux tendu (tableaux de bord quotidien).
Le choix de DataMirror
Initialement, le projet informatique a été confié à un intégrateur pour une mise en exploitation en 1998. A cette époque, la banque en ligne élabore une étude de marché sur les outils proposant de la réplication de données. Les outils disponibles sur le marché n'étant pas légion, deux outils adéquats se profilent : Datapropagator d'IBM et Transformation Server de DataMirror. Le produit de DataMirror est celui qui répond alors au mieux aux critères de sélection de la banque. Il est ainsi choisi pour sa pérennité, sa simplicité de mise en oeuvre, et son expérience éprouvée dans d'autres sociétés. En outre, sa fonctionnalité de "continuous mirroring", réplication de données en temps réel, est considérée comme un atout clé.
Les phases du projet
Composant du projet informatique global qui s'étend sur deux années, le projet DataMirror est développé concomitamment à celui de l'application CRM. Car à chaque fonctionnalité qui doit être intégrée dans l'application CRM, Banque Directe étudie si la présentation des données est nécessaire, et si ces dernières proviennent de iSeries.
L'installation et l'implémentation sont effectuées en interne, en collaboration avec l'intégrateur. Depuis, l'outil Transformation Server est utilisé pour répliquer les données de iSeries vers les bases de données Oracle des applications de CRM, e-business et datawarehouse. Plus qu'une simple réplication, le continuous mirroring synchronise le contenu des tables. Chaque mise à jour de la table source est répliquée sur la table cible, et ceci au fil de l'eau, de façon incrémentale.
Aujourd'hui, un tiers des données, toutes bases de production confondues, sont répliquées depuis Transformation Server. De nouvelles réplications sont effectuées environ une fois par an.
L'installation et l'implémentation sont effectuées en interne, en collaboration avec l'intégrateur. Depuis, l'outil Transformation Server est utilisé pour répliquer les données de iSeries vers les bases de données Oracle des applications de CRM, e-business et datawarehouse. Plus qu'une simple réplication, le continuous mirroring synchronise le contenu des tables. Chaque mise à jour de la table source est répliquée sur la table cible, et ceci au fil de l'eau, de façon incrémentale.
Aujourd'hui, un tiers des données, toutes bases de production confondues, sont répliquées depuis Transformation Server. De nouvelles réplications sont effectuées environ une fois par an.
Le bilan
Après une prise en main rapide et quelques années d'utilisation de Transformation Server, Patrick Lepine estime que "les objectifs initiaux sont largement atteints, tant sur le plan qualitatif (fiabilité, rapidité et quasi "zéro maintenance"), que quantitatif, puisqu'un tiers des données présentées dans les bases Oracle proviennent de la réplication en temps réel, volume supérieur à ce qu'il était prévu initialement".
A présent habituée à la rapidité de Transformation Server, AXA Banque se considère en dysfonctionnement lorsque le délai de présentation des données sur les outils CRM ou e-business suite à une opération effectuée sur le moteur bancaire, est supérieur à quelques secondes. Au final, le Client est le premier bénéficiaire de cette rapidité.
Les bénéfices tirés de la solution sont difficilement quantifiables, mais il est évident que la stratégie commerciale de proximité et de satisfaction Client divulguée par AXA Banque repose fondamentalement sur Transformation Server.
A présent habituée à la rapidité de Transformation Server, AXA Banque se considère en dysfonctionnement lorsque le délai de présentation des données sur les outils CRM ou e-business suite à une opération effectuée sur le moteur bancaire, est supérieur à quelques secondes. Au final, le Client est le premier bénéficiaire de cette rapidité.
Les bénéfices tirés de la solution sont difficilement quantifiables, mais il est évident que la stratégie commerciale de proximité et de satisfaction Client divulguée par AXA Banque repose fondamentalement sur Transformation Server.
