Alors que le groupe SNCF mène une ambitieuse stratégie de transformation numérique, Raphael Viard, Chief Transformation Officer & Chief Technology Officer, doit moderniser le socle numérique qui porte cette stratégie. Un véritable défi lorsqu’il faut jongler entre cloud, IoT, big data et applications legacy.
Raphael Viard, CTO, groupe SNCF
Qu’est-ce qui vous a poussé à lancer un vaste programme de modernisation du socle numérique du groupe SNCF ?
Raphael Viard. Lorsque nous avons commencé à nous intéresser à l’IoT et au big data, tout comme pour les applications mobiles, nous avons rapidement compris que notre système d’information ne serait pas assez agile pour aborder ces nouvelles technologies. Nous avons mené de nombreux proofs of concept (PoC) qui fonctionnaient bien, mais dès qu’il fallait réinjecter de nouvelles données dans nos processus métier, c’était plus problématique.
Illustration de ces freins liés à notre existant, nous savons créer des applications mobiles très performantes sur de nouvelles technologies, des applications capables de faire face à de très fortes charges. Mais face à ces applications, notre back office n’était pas capable de répondre au flux de demandes, ce qui nous posait un véritable problème en termes d’agilité.
Le programme que nous avons mis en place vise à transformer notre socle technologique afin d’accélérer la transformation numérique de nos métiers, disposer à la fois d’un socle agile et à l’état de l’art technologiquement.
Quels sont les principaux axes de cette transformation ?
Raphael Viard. Il est possible de résumer cette transformation en cinq piliers. Il s’agit, d’une part, de pouvoir délivrer un environnement de travail adapté à nos collaborateurs afin de leur apporter bien plus de souplesse au quotidien. Le deuxième point consiste en une adoption significative du cloud public allant de pair avec une automatisation des tâches liées aux data centers. Nous avons besoin d’être une entreprise étendue qui doit pouvoir travailler avec des start-up et des prestataires externes. Nous avons besoin de haut débit depuis le poste de travail au sens large jusqu’à nos data centers software-defined.
Le troisième point est plus transverse : il s’agit de doter le groupe de plateformes digitales mutualisées. Nous avons ainsi mis en place, à ce jour, trois plateformes de ce type, l’une pour l’IoT, une deuxième pour le big data et une troisième dédiée à notre portefeuille d’API et à l’exposition de nos données. Le quatrième pan de notre stratégie porte sur ce que l’on appelle la cybersécurité « by design ». Cela consiste à intégrer des outils de sécurité dans nos chaînes d’intégration continue afin d’analyser le code produit par les équipes DevOps. Ces outils doivent nous aider à éviter les vulnérabilités. Enfin, le dernier et 5e point concerne l’hébergement de la data. Pour ce volet, nous répondons par des capacités d’hébergement dans le cloud public tant pour notre plateforme big data qu’IoT, ainsi qu’en « APIsant » notre système d’information.
« En termes de gouvernance de la donnée, nous avons plusieurs niveaux de classification. Une donnée au niveau de classification le plus élevé n’est pas éligible au cloud public. »
Aller vers un SI 100% porté par le cloud public, est-ce un objectif atteignable pour une entreprise de la taille du groupe SNCF ?
Raphael Viard. Notre objectif n’est pas d’aller vers le 100% cloud public, mais de privilégier un modèle hybride. Il faut bien distinguer l’objectif de ce qu’il est possible d’être fait. Nous allons vers le cloud public pour les applications qui sont à la fois techniquement éligibles au cloud et qui peuvent aussi tirer bénéfice du cloud, notamment en termes d’élasticité. Pour d’autres applications, c’est parfois trop compliqué soit pour des contraintes de sécurité, de temps réel, soit parce qu’il s’agit de systèmes qui ne sont pas éligibles. Une partie du patrimoine IT sera de toute manière préservée en interne et nous visons aujourd’hui un ratio 60/40, avec 60% d’applications qui iront dans le cloud public et 40% qui resteront dans nos data centers internes, tout en sachant que dans ces data centers internes, nous aurons deux grandes parties. Une partie pourrait être assimilée à ce que certains appellent du cloud privé, même si c’est un terme que je n’aime pas car on n’aura jamais élasticité et paiement à la consommation dans un data center privé. Néanmoins, nous cherchons à automatiser au maximum ce qui peut l’être dans l’exploitation de nos data centers, et préserver une partie de ce patrimoine qui correspond aux applications pour lesquelles cela ne fait pas sens de réécrire le code et qui ne sont ni éligibles à la virtualisation, ni au cloud public.
Quelles règles de gouvernance avez-vous établi afin de décider si une donnée peut aller ou non sur le cloud public ?
Raphael Viard. En termes de gouvernance de la donnée, nous avons plusieurs niveaux de classification, et pour résumer, une donnée qui est au niveau de classification le plus élevé n’est pas éligible au cloud public. Classifier la donnée est un exercice complexe car nous manipulons des masses de données au quotidien. D’ailleurs, nous menons plusieurs politiques de front vis-à-vis de ces données. Nous menons une stratégie open data depuis plusieurs années, ce qui explique qu’une partie de nos données sont publiques et à l’autre extrémité, nous gérons des données confidentielles que nous gardons en interne. Entre les deux, nous avons beaucoup de données qui sont chiffrées sur nos messageries, sur nos postes de travail, avec une large palette de moyens de protection de nos données.
Par ailleurs, nous sommes bien évidemment très attentifs aux réglementations relatives aux données qui s’appliquent à nous. La plus connue est le RGPD, mais nous sommes soumis à bien d’autres.
Quelles sont, selon vous, les applications où le cloud public est incontestablement plus adapté que l’approche on premise classique ?
Raphael Viard. Pour une application mobile, par exemple, qui doit faire face à de très fortes charges comme les connaît fréquemment l’application SNCF aujourd’hui, il est bien plus simple de faire tourner son back-end dans le cloud public afin de bénéficier de son élasticité. Sur l’IoT, l’approche a été un peu différente. C’est un domaine où finalement il est assez rapide de mettre en place des PoC. On arrive à démontrer des gains assez rapidement et à trouver des pistes d’optimisation, mais aller au-delà de ces démonstrateurs implique de modifier les processus business et la mise en œuvre de ces optimisations demande beaucoup plus de temps au quotidien.
Le cloud est excessivement important car il permet de commencer petit mais de penser grand. Si nos métiers ont besoin de mener un PoC sur de l’IoT, le ticket d’entrée doit être faible et, sur ce plan, le paiement à l’usage est primordial. D’un autre côté, il ne faut pas mener un PoC sur une technologie et devoir en changer lorsqu’on veut aller vers le « run ». Il est important que l’on puisse monter des prototypes puis passer en production sur une même plateforme et, sur ce plan, le cloud est parfait pour ça !
Via l’IoT, le groupe SNCF collecte de plus en plus de données dans son exploitation des trains. Comment ces données viennent-elles enrichir votre stratégie data ?
Raphael Viard. C’est dans notre data lake hébergé sur Microsoft Azure où nous consolidons toutes ces informations et réalisons nos analyses. Selon moi, l’IoT est avant tout une problématique d’acquisition de données. Tout le volet analytique, intelligence artificielle est plutôt du ressort de notre plateforme big data. L’IoT est pour nous une source d’enrichissement de données dont nous disposions déjà en partie. Nous recueillons des informations qui proviennent des trains depuis longtemps, pas nécessairement sous la forme d’IoT. Un train est un système communicant qui remonte des alertes que nous analysions. La pose de capteurs supplémentaires va nous fournir des informations complémentaires.
> Cette interview est extraite du carnet « DSI Stratèges et Infrastructures » : téléchargez-le ici.