Accueil La SNCF transforme sa production IT

La SNCF transforme sa production IT

Lauréat DSITROPHEES_2ndXcoPRIX


Toutes les DSI du groupe confient leurs changements systèmes et réseaux à la production informatique. Le service partagé vient de se réorganiser pour offrir un support unifié de qualité.

 

Issue de vingt-cinq années de développements successifs, la production informatique de la SNCF est hétérogène et complexe. Elle traite 1 500 demandes de changement par mois, dont une moitié concerne des transformations d’infrastructure et l’autre des évolutions applicatives. Le projet Mars permet de mieux coordonner les actions réparties sur trois datacenters en France. Le suivi des incidents s’appuie sur l’outil BMC Remedy Action Request System (ARS).

Samuel Hurtel,  directeur de la production informatique de la SNCF
Samuel Hurtel,
directeur de la production informatique de la SNCF

Un seul outil de support

« Le projet Mars s’inscrit dans le cadre du rapprochement des équipes et des activités de trois datacenters, à Lille, Paris et Lyon. Comme avec un datacenter virtuel, les agents partagent tous la même information. Selon l’incident, ils fournissent des services d’intégration en production, d’ingénierie des systèmes Unix et Windows, re-configurent les réseaux ou d’autres services », précise Samuel Hurtel, directeur de la production informatique de la SNCF.

Les DSI chargées de la réservation des titres de transport en gares, des bornes ou de la maintenance des trains s’en remettent aux activités centralisées de la production IT, au sein de la direction des services partagés.

Jusqu’en septembre 2015, les trois sites avaient chacun un outil distinct pour suivre les incidents. Une remise à plat des procédures devenait nécessaire afin d’harmoniser les bonnes pratiques. « Chacun parlait ITIL, mais à sa manière. Après un incident, la procédure n’allait pas jusqu’au même point de résolution. Il fallait un vocabulaire commun, revoir nos processus et choisir un seul outil de support unifié. »

Réussir une migration sans défaut

Le choix d’un standard ITSM (IT Service Management) est structurant. Il permet aux équipes de gagner en cohérence et d’intervenir partout de la même façon.

« Mon critère principal ? Je voulais une solution zéro défaut, qui ne perturbe pas la vie des agents », souligne Samuel Hurtel, avant de mentionner le soutien de l’intégrateur Cap Gemini pour créer les interfaces nécessaires, entre ARS et l’outil de supervision Tivoli notamment.

La personnalisation d’ARS a été volontairement restreinte. Sa mise en production retient un cluster dédié. « Nous n’avons aucune perte d’informations à déplorer. La continuité de services a été assurée grâce à une récupération des flux et des incidents en cours. »

L’essentiel du travail a été mené durant les dix-huit mois qui ont précédé la bascule. Cette phase préalable a permis aux équipes de s’entendre sur les processus et sur un workflow résultant des meilleures pratiques identifiées.

A présent, une réunion en visio-conférence rapproche quarante experts des trois sites, chaque matin. C’est l’occasion de faire le point sur les incidents et changements du jour, puis de la semaine. ARS met en évidence les risques de dépassement de délai. « L’outil nous accompagne, mais c’est toujours à nous de prendre la décision. ARS favorise le dialogue. Nous identifions quatre catégories de changements, les plus critiques sont menés la nuit pour ne pas perturber les applications métiers », conclut le directeur de la production informatique.

 


 

Quatre facteurs clés de succès

A la SNCF, l’industrialisation de la production informatique exigeait une cohésion entre les équipes chargées du soutien aux DSI du groupe. Le logiciel BMC Remedy Action Request System (ARS) a remplacé trois outils de suivi des incidents distincts. Il facilite l’aide à la décision pour 1 400 utilisateurs, dans un contexte où, quotidiennement, un à deux milliers de tickets d’incidents sont émis. La conduite du projet Mars jusqu’à la bascule fait apparaître quatre facteurs clés de succès :

  •  Une méthode efficace : un travail mené en amont a permis d’unifier le langage entre agents et de définir des processus commun. Cette étape indispensable a duré 18 mois.
  •  Une infrastructure robuste : pour soutenir le logiciel exploité en interne, un cluster à haute disponibilité prévoit des bascules automatisées.
  •  Une migration sans douleur : pour basculer sans douleur ni perte d’information vers ARS, le déploiement a été planifié en deux temps, en septembre puis en décembre 2015.
  •  Une formation motivante : l’accompagnement des agents a pris la forme de sessions d’e-learning et de 45 ateliers avec la mise en place d’un permis ARS.