Projets

Pithagore : gérer le réseau ferré de la RATP avec agilité

Marc Lhuillier, responsable d’équipe pilotage des chantiers et des incidents, a dû garantir l’adaptation des process aux différents métiers.

A la RATP, le développement agile s'est imposé pour Pithagore malgré des normes strictes pré-établies, cela à cause de la complexité du projet.

PublicitéLa Régie Autonome des Transports Parisiens (RATP) est, certes, opérateur de transport mais aussi gestionnaire d'infrastructures, en particulier d'un triple réseau ferré (métro, RER, tramway). Chaque réseau ferré dispose de normes extrêmement strictes pour sa construction, les circulations, la maintenance, etc. Ces normes sont bien connues et maîtrisées, portant sur des éléments tels que les voies, la distribution d'énergie, la signalisation et les espaces annexes (quais, escalators...). Pour assurer la maintenance et l'évolution des réseaux ferrés d'une part au quotidien (outils ad hoc), d'autre part sur le long terme (le plus souvent sous Excel ou sur papier), la RATP disposait d'outils épars et en voie d'obsolescence. En 2015, il a été décidé d'unifier tous ces outils dans un nouveau programme baptisé Pithagore, lancé effectivement en 2016. Depuis deux ans, les différents lots sont mis en production avec régularité, l'ensemble du périmètre prévu devant être couvert d'ici fin 2020 « en respectant délais et budgets prévus » comme le souligne Marc Lhuillier, responsable d'équipe pilotage des chantiers et des incidents depuis 2018.

Au sein de la DSI de la RATP, plusieurs sous-directions cohabitent, d'un côté pour les systèmes transverses, de l'autre pour les systèmes métiers. Côté systèmes métiers, l'organisation se calque sur celle des métiers. Le programme Pithagore est ainsi géré par le service SGM (système de gestion de la maintenance). Normalement, la DSI opère en maître d'oeuvre et sous-traite les développements à l'extérieur. Dans ce cas très sensible, les 25 membres des équipes de prestataires (conception, développement, qualité) ont été hébergées sur des plateaux RATP sous la coordination de la maîtrise d'oeuvre. Le projet est piloté directement au quotidien par Bastian Peghaire, maître d'oeuvre RATP depuis 2018.

Un fort besoin de sécurité

Comme le projet est d'une grande sensibilité en matière de sécurité des infrastructures ferroviaires, le logiciel est inaccessible de l'extérieur de la RATP et est hébergé sur les serveurs propres internes. « Toutes les applications métiers de la RATP sont hébergées sur nos propres serveurs et dans nos locaux : c'est une règle interne de sécurité » spécifie Bastian Peghaire. Assez classiquement, le développement s'opère en Java 8 avec une interface utilisateur en React.js. Deux bases de données sont utilisées : d'une part le SGBDR libre PostgreSQL et, d'autre part, la base de données orientée graphe Neo4J au code source ouvert de l'éditeur suédo-américain Neo Technology.

Bastian Peghaire précise : « certaines données sont répliquées entre les deux pour optimiser l'accès. La base sous Neo4J est parfaite pour stocker des plans (cartes des réseaux, des stations...) avec gestion des distances : c'est un référentiel qui bouge peu. » Bien entendu, l'usage de ce type de bases de données suppose d'employer un langage spécifique différent du SQL, en l'occurrence le Cypher Query Language.

PublicitéUn périmètre parfaitement maîtrisé

Dès le départ, le développement s'est opéré avec une approche agile. Si cette approche est normalement destiné à permettre au métier d'affiner progressivement son besoin voire de changer ses désirs en fonction d'opportunités, ce n'était pas le cas dans le projet Pithagore. En effet, les réseaux ferrés obéissent à des règles strictes parfaitement connues et que l'on ne peut pas modifier dans le cadre d'un projet informatique. Il pourrait donc sembler pertinent d'utiliser dans ce genre de cas un développement avec cycle en V traditionnel. « Le choix de l'agilité a été opéré au départ à cause des spécificités et de la grande complexité du projet » justifie Marc Lhuillier.

L'outil sert en effet à gérer des « chantiers » sur différents types de réseaux (RER, métro ou tramway), voies ou espaces connexes (quais, couloirs, escalators...). Un « chantier » renvoie à la mobilisation d'un certain nombre de ressources (humaines et techniques) pour réaliser une tâche à un moment déterminé en gérant une sécurisation de l'intervention (arrêt de la circulation, coupure électrique, etc.). Or les procédures varient selon les réseaux ou les espaces concernés. Et, de la même façon, le chantier doit tenir compte d'interactions variées avec des services différents selon les cas. Comprendre le besoin dans un cadre aussi complexe et variable supposait le recours à l'agilité.

Une méthode agile et toute en souplesse

« Comme toutes les entreprises adoptant les méthodes agiles, nous avons défini un cadre ad hoc propre basé sur les fondamentaux de SCRUM mais adapté à nos spécificités » explique Marc Lhuillier. Parmi celles-ci, la complexité du projet amène de temps à autres des remises en cause de l'expression des besoins. Surtout, il faut organiser une collaboration entre des équipes aux horaires décalés, certaines équipes métier ne travaillant que la nuit alors que les développeurs sont évidemment en poste de jour. Marc Lhuillier insiste : « il nous faut une grande souplesse d'organisation ».

Si les sprints sont d'une semaine et le principe des cérémonies conservé, le chiffrage est quotidien et non pas hebdomadaire. Et les démonstrations ont lieu toutes les deux semaines au lieu de chaque fin de sprint. Les sprints courts permettent des communications rapprochées et d'aboutir à un développement correspondant bien aux attentes. « En aucun cas il ne faut suivre un process pour la beauté du process » insiste Marc Lhuillier. « Il fait rester agile, souple et efficace. » Si les sprints sont sur une base hebdomadaire, les mises-à-jour en production sont, par contre, plutôt mensuelles.

Un déploiement progressif

Bastian Peghaire précise : « comme nous sommes plus aujourd'hui en phase de recette, nous avons basculé sur une méthode de type Kanban avec gestion de tickets au lieu des sprints. Bien entendu, les méthodes ont aussi évolué au rythme du changement des équipes. » Il faut en effet corriger rapidement selon les tickets et opérer des livraisons massives selon les priorités du métier. Pour Marc Lhuillier, « même s'il y a toujours des mécontents du changement lui-même ou à cause d'un choix différent de leur demande individuelle, nous avons clairement répondu à tout le besoin exprimé au départ. Les bascules en production se font par périmètres fonctionnels : quand ce qui concerne le RER est terminé, nous le livrons, pour le métro idem, etc. »

A ce jour, Pithagore a environ 1500 utilisateurs et en aura prochainement 2000 dès lors que les modules gérant les chantiers dans les « espaces » (quais, couloirs... par opposition aux voies avec leurs équipements) seront déployés. Le premier lot concernait la planification à long terme (celle qui était auparavant très manuelle) et a été livré en 2018. L'année suivante a été livré le lot consacré au court terme. Enfin, d'ici fin septembre 2020, sera livré le lot « espaces ». Les retours des utilisateurs du lot 1 ont bien sûr été pris en compte pour les lots 2 et 3. Marc Lhuillier conclut : « tout au long du projet, nous avons eu des fortes exigences en qualité car un bogue dans Pithagore pourrait entraîner des accidents potentiellement mortels (par exemple si la gestion des arrêts d'alimentation électrique donnait de fausses informations), ce qui serait inacceptable. »