SNCF Réseau optimise les entraînements de ses algorithmes avec le cloud

Ariane : une politique de gouvernance de la donnée dédiée au réseau ferré

Cet exercice n’est pas nouveau. SNCF Réseau est issue de la réunification de réseau ferré de France (RFF) et de la SNCF, deux entités qui avaient jusqu’en 2015 des systèmes d’information distincts qu’il fallait faire communiquer. Mais dès 2013, le gestionnaire d’infrastructure avait constaté un manque de standardisation qui défavorisait les échanges avec les gestionnaires des pays voisins.

« SNCF Réseau a fait le choix de mettre en place une gouvernance de la donnée au niveau de l’entreprise. »

« SNCF Réseau a fait le choix de mettre en place une gouvernance de la donnée au niveau de l’entreprise par la mise en place d’un langage commun, que nous appelons Ariane. Il permet de définir l’ensemble des objets métiers que manipule l’entreprise. Nous avons défini de façon systémique ce qu’est une circulation, ce que sont des travaux, la maintenance, etc. pour un gestionnaire d’infrastructure », explique Samuel Descroix.

Ariane est basée sur un modèle systémique nommé RailTopoModel, partagé par plusieurs acteurs européens. Celui-ci décrit une infrastructure ferroviaire en s’appuyant sur la topologie du réseau à laquelle sont rattachés des objets, des installations, des distinctions multiniveaux classés par fonctionnalité : l’infrastructure, la signalisation, le réseau électrique, la circulation et les travaux. 

L’ensemble des données cartographiées de l’entreprise ont ensuite été mises en place dans des gisements, des réceptacles de données. « Nous y avons mis beaucoup d’intelligence », assure le directeur géographique et analytique chez SNCF Réseau. 

« Souvent, les entreprises versent les données brutes dans un data lake et essayent d’y appliquer une couche d’intelligence, comme des algorithmes, pour donner du sens à ces données. Chez SNCF Réseau, nous avons fait le choix inverse. Nous avons déjà défini les objets qui nous intéressent, nous les avons modélisés, mis à disposition dans des gisements, puis nous avons alimenté ces gisements de données ».

« Chez SNCF Réseau, on a pris le problème à l’envers », renchérit Pierre-Yves Bonnefoy, PDG et cofondateur chez Olexya et architecte décisionnel/Data Architect pour SNCF Réseau. « Nous avons décrit qui est le responsable de la donnée, qui décrit l’unicité de cette donnée, et les autres gisements de données profitent de cette unicité ».

Les systèmes transactionnels et opérationnels existants déversent les informations dans les gisements. « On découple le système traditionnel et on met les gisements au centre du SI. Tout le monde communique avec le même langage, en utilisant les mêmes objets (identifiés de façon unique par des GUID) », continue Samuel Descroix. Le modèle Ariane prend également en compte les données financières liées aux opérations de SNCF Réseau.

« On découple le système traditionnel et on met les gisements au centre du SI. Tout le monde communique avec le même langage, en utilisant les mêmes objets. »

Porter les efforts décisionnels via le cloud en réduisant les coûts

Cette politique a influencé la gestion des ressources informatiques. « Une entité comme la mienne a pour vocation de valoriser ces données sans pour autant en connaître réellement l’usage, que ce soit pour la réalisation d’un tableau de bord classique, de la géographie, du partage de données, de l’open data ou encore de l’intelligence artificielle », indique Samuel Descroix. « Notre problématique côté SI, c’est de mettre à disposition des systèmes qui peuvent répondre à n’importe quelle sollicitation de valorisation de données sans investir des sommes astronomiques ».

Rapidement, migrer l’infrastructure pour gagner en souplesse, en élasticité, en réactivité et en volume de calcul, est devenu un sujet important.

Résultat, après un appel d’offres, toute l’architecture décisionnelle et de traitement des données a été migrée sur AWS entre avril et début juillet 2019. « Ce n’est pas un choix purement technologique. C’est un choix d’entreprise, pris en corrélation avec les directions métiers et les experts cybersécurité de SNCF Réseau » justifie Samuel Descroix.

SNCF Réseau mène 80 projets décisionnels différents (BI, analytique et machine learning) : analyse financière, gestion opérationnelle de l’activité réseau, gestion des actifs et de leur maintenance, planification des travaux, gestion des retards, etc. Les sujets ne manquent pas.

Les données sont stockées dans des centres de données et des infrastructures IaaS différents, suivant les appels d’offres remportés et les besoins spécifiques. Les équipes de data science et analytique peuvent appeler les données via API, obtenir l’information nécessaire sans créer de doublon d’un jeu complet dans le cloud. « Nous faisons de l’économie de coût sur le stockage et sur la durée des traitements, qui est la préoccupation principale », estime Pierre-Yves Bonnefoy.

Des environnements de data science plus adaptés

« Cette manière de travailler nous permet d’avoir une vision systémique du fonctionnement de l’entreprise. Nous sommes capables de faire de la restitution cohérente et de qualité, sur l’ensemble des domaines fonctionnels de l’entreprise », affirme Samuel Descroix.

« Et l’architecture que nous avons mise en place avec AWS nous permet d’obtenir des performances que nous n’avions pas jusqu’alors pour le traitement en réel, le reporting ou le machine learning ».

« Maintenant nous pouvons proposer aux métiers d’aller plus loin avec de vrais projets de machine learning et d’IA. »

Ce gain provoque des changements d’activité et de possibles reconversions pour les métiers du pôle géographique et analytique chez SNCF Réseau. « Avec cette nouvelle architecture, les membres de l’équipe vont changer de rôle. Ils vont arrêter de passer du temps sur la collecte et l’intégration de données pour, désormais, se focaliser sur l’accompagnement des métiers et la compréhension de leurs problématiques », se réjouit Samuel Descroix.

Ces étapes étaient, semble-t-il, nécessaires pour atteindre les performances opérationnelles voulues. « Maintenant, nous pouvons proposer aux métiers d’aller plus loin avec de vrais projets de machine learning et d’IA », ajoute le directeur.

Accélérer les projets de computer vision

Ces projets d’IA avaient commencé avant l’adoption des services AWS. Par exemple, le cabinet Olexya a accompagné SNCF Réseau pour migrer un modèle de computer vision, déployé il y a trois ans sur huit ordinateurs mis en parallèle. Ce modèle sur le framework de réseau de neurones Caffe2 a été adapté pour être entraîné et déployé depuis les environnements managés AWS via SageMaker, Athena et Amazon S3. Il permet de détecter des anomalies sur les voies grâce à l’analyse du flux vidéo d’une caméra placée sur une motrice.

« J’ai créé des notebooks par état du modèle où je propose aux data scientists de remplir les paramètres les plus importants pour eux. J’ai organisé un bucket S3 dans lequel ils peuvent déposer les images pour l’entraînement et les fichiers de configuration, entre autres », explique dans le détail Pierre-Yves Bonnefoy. « Ces éléments sont incorporés en tant que variables au sein des notebooks ; les data scientists n’ont plus qu’à lancer une commande via les API SageMaker pour la souscription d’une machine montée à la volée qui récupère les données dans S3 et qui réalise l’entraînement, puis qui fournit un résultat directement dans un bucket S3 ».

Aujourd’hui, les data scientists de l’entreprise sont totalement autonomes pour modifier le code et le rejouer. Cette étape de migration a pris environ trois semaines. SageMaker permet depuis de surveiller les activités de l’entraînement sur la machine allouée au calcul.

« Les data scientists n’ont plus qu’à lancer une commande via les API SageMaker pour la souscription d’une machine montée à la volée qui récupère les données dans S3 et réalise l’entraînement. »

Dans le cas du modèle développé avec Caffe2, il s’agit d’une instance EC2 ml.p3.2xlarge dotée d’un GPU Nvidia Tesla V100 (5 120 cœurs Cuda et 16 Go de VRAM HBM2). Le gain de temps est jugé très appréciable. L’entraînement prenait auparavant trois jours d’affilée, il ne dure plus que dix heures.

Avec l’aide d’Olexya, SNCF Réseau a également optimisé les coûts liés à cet algorithme. Les équipes ont configuré des instances Spot Amazon EC2 et le code du modèle dans une image Docker selon les spécifications de SageMaker. De cette manière, le coût d’entraînement aurait été réduit de 71 % par rapport à SageMaker à la demande.

Pour mémoire, Spot est un service qui détecte les instances EC2 non utilisées et qui les alloue à des workloads dits « flexibles » pour des clients sensibles à la question du coût. Cette solution peut également être utilisée à l’inférence du modèle. La même API SageMaker est utilisée dans les deux cas.

D’autres optimisations sont prévues par l’équipe d’Olexya avant que l’algorithme soit embarqué dans des motrices. Les équipes cherchent encore le bon matériel informatique pour supporter ce cas d’usage.

Au total, ce sont une petite dizaine de projets algorithmiques qui sont actuellement développés depuis SageMaker. Pierre-Yves Bonnefoy cite par exemple l’analyse de la consommation électrique des motrices et celle du fonctionnement des caténaires, ou encore l’analyse de facturation.

« C’est un vrai succès », assure aujourd’hui Samuel Descroix qui regarde vers l’avenir. « Nous avons deux étapes majeures. La première, c’est de passer les algorithmes des environnements de data science en production, dans le cadre d’un processus opérationnel et d’aide à la décision. Nous avons brisé la frontière entre les environnements d’innovation et de production. La deuxième, c’est que tous ces algorithmes soient classifiés et certifiés. Un algorithme de détection de défauts doit être cartographié et documenté, afin d’être disponible pour l’ensemble des métiers de l’entreprise ». Bref, il reste encore des chantiers importants, mais le Machine Learning est en tout cas sur de bons rails chez SNCF Réseau.