Décideurs it

Pascal Dalla Torre (RATP Dev) : « si je gère de l’infra, je ne mets pas l’argent au bon endroit »


Filiale du groupe RATP, RATP Dev opère des transports publics à travers le monde. Pascal Dalla Torre, son DSI, explique ici sa stratégie et ses approches.

Pascal Dalla Torre est DSI de RATP Développement.  - © Républik IT / B.L.
Pascal Dalla Torre est DSI de RATP Développement. - © Républik IT / B.L.

Pouvez-vous nous présenter RATP Dev ?

RATP Développement est un groupe filiale de droit privé de la RATP qui génère un chiffre d’affaires de l’ordre de deux milliards d’euros. Il opère et maintient des transports publics (tramways, bus, lignes fluviales…) avec un focus particulier sur les métros automatiques, le tout en dehors d’Île-de-France. Nous avons une business unit France importante et nous opérons dans une quinzaine de pays étrangers avec des lignes emblématiques, par exemple, à Ryad, au Caire, à Sidney, à Hong-Kong… sans oublier des bus inter-urbains aux Etats-Unis.

A chaque contrat, nous créons une société dédiée, filiale de RATP Dev.

Au contraire, notre maison-mère, la RATP, est dans une situation inverse avec un client unique, Ile-de-France Mobilités, dans une seule région, la région parisienne.

Comment est organisée votre IT ?

Notre IT est totalement séparée de celle de notre maison-mère. Nous négocions quelques contrats en commun avec des fournisseurs partagés et nous recourons aussi à leur expertise sur des applications métiers développées par la RATP. Nos collaborateurs viennent d’ailleurs souvent de notre maison-mère.

Selon leur taille, nos filiales locales peuvent avoir un DSI ou, lorsqu’elle est plus petite, un IT Leader avec un pilotage plus direct par le groupe.

Je suis rattaché, comme le CDO, au membre du comité de direction en charge du digital. Le CISO, lui, m’est rattaché. Tant que le CISO est opérationnel, je pense qu’il faut qu’il soit rattaché au DSI.

Quels sont vos grands choix d’architecture ?

La RATP a, comme je le disais, un client unique sur une zone géographique unique et peut donc avoir un SI sur cloud privé. RATP Dev a une présence mondiale. Nous avons une obligation d’assurer un service numérique à l’échelle dans toutes nos filiales. Cela ne peut, aujourd’hui, se faire que dans le cloud public en ayant recours aux hyperscalers. A l’heure actuelle, des acteurs comme OVH ou Scaleway ne sont pas en mesure de nous proposer du PaaS à l’échelle.

La sécurisation du cloud est garantie par chaque hyperscaler et, moi, j’ai la responsabilité de la sécurisation de mon instance. Nous avons recours au chiffrement des données par les hyperscalers et, donc, c’est vrai, nous ne nous prémunissons pas vis-à-vis du Cloud Act. Mais l’enjeu pour les etats-Unis est-il de connaître notre taux de marge sur la concession de Lyon ? Il faut se poser la question de savoir quelle information est réellement soumise à un risque.

Notre stratégie, c’est de nous reposer sur un cloud public industrialisé. Si je gère de l’infrastructure, je ne mets pas l’argent au bon endroit.

Je sais que plus ou moins la moitié de mon parc applicatif est sur la voie de l’obsolescence technique. Pour l’heure, la vraie question est celle de la cartographie applicative. Et, pour chaque application, même SaaS, il faut un business owner.

Notre parc logiciel est assez vaste et peut varier selon les filiales. Côté RH, nous avons par exemple du Cegid et du Success Factor. Pour la finance, nous avons du Sage, du Kariba… Nous utilisons IBM Maximo pour la gestion des actifs industriels. Côté cybersécurité, nous utilisons du SentinelOne, du Proofpoint, du Zscaler, etc. Côté collaboratif, nous utilisons Microsoft Office365. Et, pour le Cloud, nous avons évidemment du Microsoft Azure pour les produits Microsoft et de l’AWS pour le reste.

Vous disposez de multiples sociétés correspondant à des concessions dans divers pays. Quelles sont les conséquences IT ?

Pour assurer un service numérique à l’échelle dans toutes nos filiales, nous nous reposons donc sur une démarche de standardisation et d’industrialisation, avec, pour les infrastructures, du cloud public.

A cela s’ajoute la mise en place de communautés de pratiques entre responsables homologues dans tout le groupe.

Quelle est votre vision, votre feuille de route ?

RATP Dev a un plan stratégique métier qui se décline bien sûr en IT. Pour l’IT, le plan stratégique repose sur cinq piliers.

Le premier pilier est le focus sur le métro automatique. Aujourd’hui, nous en gérons 1200 km de lignes et nous avons un objectif de 4000 km en 2030. L’enjeu du métro automatique est de collecter et traiter la data autant des rames que des équipements de station pour garantir l’excellence opérationnelle.

En deuxième, nous avons le développement global. Aujourd’hui, il y a 65 villes dans le monde disposant de métros automatiques. Le marché a un potentiel énorme. En Amérique du Sud, il n’y en a aucun par exemple. Assurer ce développement global passe, au niveau IT, par la gouvernance de la data, la mise à l’échelle du SI et la création d’une culture digitale dans toute l’entreprise. Il faut aussi animer la filière digitale partout dans le monde.

Le passage à l’échelle constitue justement le troisième pilier. Je n’ai pas plus de boule de cristal que n’importe qui. Je ne sais pas ce que sera le monde dans cinq ou dix ans. Malgré tout, il me faut anticiper les changements, savoir adapter l’IT à la situation. Et pour cela, il nous faut disposer du SI le plus modulaire possible, le plus composable possible.

Quand on adopte un cloud comme Azure, l’avantage n’est-il pas au contraire de disposer d’un écosystème nativement intégré ?

Reposer son IT sur un écosystème de type Microsoft, tout intégré, n’est pas l’avenir : c’est le passé. Il faut tout découpler. L’avenir, c’est l’APIsation, les microservices, la modularisation. C’est cela notre cible. Pour y arriver, il nous faut tout industrialiser, tout gérer en mode produit.

Au lieu de mettre des pansements sur des jambes de bois, comme sécuriser un active directory, il faut investir en mode projet sur des technologies modernes.

Les applications peuvent être on premise, hébergées sur un IaaS ou en SaaS. Mais le but est qu’elles soient toutes en accès web. A partir de là, l’architecture est fortement simplifiée. Il n’y a plus besoin de sécuriser de multiples agents sur un PC lourd : il suffit d’un navigateur sécurisé.

Pour les applicatifs de fonctions supports, le SaaS s’impose. Pour les applications métiers, là où nous avons une valeur différenciante, nous développons les outils en full web dans notre Digital Factory.

Sur cinq piliers, il en manque deux. Quels sont-ils ?

Notre quatrième pilier, c’est donc de disposer de produits numériques différenciants pour l’excellence opérationnelle métier. Nous avons nommé cela « opserve ». Il s’agit en particulier d’utiliser l’IA pour « augmenter » les opérations mais aussi les employés. D’ici la fin de l’année, nous aurons un portail IA/IAG avec une interrogation sécurisée (notamment RAG) de tout le patrimoine informationnel, de la messagerie à la documentation technique en passant par les informations contenues dans les applications. Il s’agit bien de s’assurer que tout fonctionne dans des instances privées sécurisées. Nous devons saisir les opportunités comme l’IA. Si nous ne le faisons pas, il y a un risque évident de shadow IA avec des usages non-sécurisés d’outils publics pouvant entraîner des risques sur la confidentialité des données.

Enfin, le dernier pilier est l’excellence opérationnelle IT. Au niveau applicatif, nous la pilotons au travers de contrats de service avec le métier. Le 24/7 a un coût mais ne se justifie pas toujours. Ce pilier intègre la dimension cybersécurité qui repose sur une approche Zero Trust. Nos actifs sont dans le cloud : il n’y a donc plus de périmètre à protéger. Il faut protéger les actifs eux-mêmes ainsi que les identités et les identifications.

Chaque utilisateur ne doit avoir qu’une seule identité utilisable en SSO pour toutes les applications. La gestion des identités, c’est aussi la gestion du cycle de vie du salarié (entrée, mutations, sortie) et la gestion du cycle de vie des terminaux qui doivent être managés. Et nous avons fait le choix que tout développement d’applicatif soit en « Secure by design ». A terme, je pense qu’un développement se terminera par un bug bounty.

L’empreinte environnementale est un sujet important dans le domaine du transport. Est-ce que cette question a un impact sur votre IT ?

Nous sommes moteurs sur le sujet du Green-IT.

Nous devons challenger nos partenaires, en particulier les hyperscalers. Ils doivent être vertueux, notamment sur le PUE ou la réutilisation de la chaleur fatale de leurs datacenters. Mais, avant de travailler sur des optimisations, il faut déjà commencer par connaître l’empreinte environnementale de nos services numériques. Nous avons tendance à choisir les fournisseurs les plus vertueux.

Il ne faut pas se limiter à la seule empreinte carbone. Il faut aussi prendre en compte l’eau, l’utilisation de terres rares, etc. Et il faut intégrer toute l’IT, notamment les terminaux dont 80 % de l’impact est lié à la fabrication (et au recyclage). Il faut donc évidemment étendre le cycle de vie, recycler, etc. Dans l’ordre, l’impact environnemental de notre groupe repose sur les déplacements, l’immobilier et les terminaux IT ! Adopter une architecture full web, c’est aussi éviter de devoir changer un terminal uniquement pour passer à Windows 11.

Quand on provisionne une ressource chez un hyperscaler, la console indique l’empreinte et on peut donc l’optimiser. En France, l’énergie est essentiellement nucléaire mais, ailleurs, elle peut être issue des centrales à charbon.

Pour terminer, quels sont les défis que vous devez relever ?

Le premier reste le passage à l’échelle. Il nous faut embarquer toutes nos filiales, dans tous les pays dans notre démarche. C’est une vraie question de culture.

De même, il y a un autre changement de culture important à mener, c’est de s’inscrire dans une logique de produits. Notre groupe est actuellement trop centré sur l’opérationnel, l’exécution.

Enfin, comme je l’expliquais, le défi technique est la modernisation avec la modularisation et le passage au full web.

Podcast - RATP Dev recourt aux hyperscalers sans hésitation

RATP Dev est une filiale du groupe RATP. Il opère des transports publics dans de nombreux pays et, comme le rappelle ici Pascal Dalla Torre, DSI du groupe, il doit relever le défi du passage à l’échelle d’un SI délivrant le même service partout. Cela n’est possible aujourd’hui qu’en recourant aux hyperscalers. Pascal Dalla Torre explique ici pourquoi ce n’est pas un problème dans un groupe parapublic comme RATP Dev.