Au sein du SNCF Voyageurs, une des sociétés filles de SNCF holding, la branche TGV intercités prend en charge tous les transports ferroviaires longue distance, soit notamment 700 TGV par jour. Parmi les quelque 90 applications faisant partie de son portefeuille, sa DSI (environ 215 personnes réparties entre Nantes et Paris) pilote un actif critique pour la compagnie ferroviaire désormais soumise à la concurrence : le RCU, soit le référentiel client unique recensant toutes les informations des clients (données d'identification, coordonnées, services associés, trajets, cartes et abonnements, données de fidélité, réclamations ou encore codes promotionnels). « Une application de back office critique, qui doit fonctionner 24 heures sur 24, 7 jours sur 7 », résume Sébastien Chezeaux, responsable de la ligne de services référentiel client à la DSI TGV, qui s'exprimait à l'occasion d'un événement organisé par Cloudera, le 14 novembre, à Paris.

Ce référentiel, qui regroupe aujourd'hui 122 millions de fiches client, est donc en premier lieu un système de stockage, embarquant certaines fonctions de mise en qualité, de mise à jour des données ou de cloisonnement de l'information, seules les applications ayant contribué à enrichir une fiche pouvant ainsi utiliser cette information. Mais, comme l'indique Sébastien Chezeaux, le RCU est aussi « un objet transactionnel temps réel ». Via des API, une quarantaine d'applications du système d'information de la SNCF se connectent, en effet, au référentiel.

« Des temps de réponse surveillés comme le lait sur le feu »

Certaines des API qu'il expose sont de ce fait associées à de hauts niveaux de sollicitation : jusqu'à 40 millions d'appels par jour et des pointes à 1300 sollicitations par seconde lors des journées d'ouverture des ventes, par exemples. « Les temps de réponse du RCU sont surveillés comme le lait sur le feu, car ils conditionnent la qualité de l'expérience client sur les espaces numériques », souligne Sébastien Chezeaux.

Même si la SNCF a démarré un virage vers le cloud, le RCU est hébergé on-premise, sur 134 serveurs, dont 48 en production. La plateforme est née du choix du système de gestion de base de données non-relationnelles HBase il y a dix ans, puis d'une distribution Hadoop pour supporter ce choix, en l'occurrence Cloudera. « Nous avons opté pour cette solution en raison de sa scalabilité », dit Alain Belbeoc'h, architecte stratégique au sein de la DSI TGV. « Même si, en 2014, nous n'avions pas à faire face aux mêmes volumes qu'aujourd'hui, nous ne connaissions alors pas la limite que devait viser le système. »


Lors d'Evolve, l'événement organisé par Cloudera mi-novembre à Paris : Sébastien Chezeaux, responsable de la ligne de services référentiel client à la DSI TGV (à gauche) et Alain Belbeoc'h, architecte stratégique au sein de la DSI TGV. (Photo : R.F.)

Actuellement, le RCU associe des fonctions de stockage et de gestion des événements de l'éditeur américain à des développements Java permettant d'exposer des API. Autour de trois services principaux : le client, la commande - qui bénéficie d'un composant dédié du fait de sa criticité - et le data hub, qui sert aux restitutions et à la gestion des événements. Le RCU dispose, enfin, de toute une série de couches de messaging, permettant de sécuriser les données en traitement. « Dès que la donnée quitte le système émetteur, nous n'avons pas le droit de la perdre », souligne Alain Belbeoc'h.