C'est une « mise en prod' » cauchemardesque que la SNCF a connu dimanche. Alors que les équipements techniques de la gare étaient en chantier entre le samedi 20h et le dimanche 12h, en vue de leur modernisation, une « panne s'est déclenchée à la fin des travaux et a interdit toute circulation pour garantir la sécurité des trains », déclare la SNCF à l'Usine Nouvelle.
Cette panne informatique a immobilisé la gare de 13h30 au lendemain matin. Elisabeth Borne, la ministre chargée des transports, dit s'interroger sur la survenance d'une telle panne à la suite d'une opération pourtant prévue de longue date.
SNCF Réseau de son côté doit présenter d'ici la fin de la semaine « une nouvelle organisation et un nouveau management de la gestion des grands travaux et de l’ingénierie ».
Commentaires (15)
#1
Encore la faute de Jean Kevin, le Stagiaire
#2
J’imagine qu’il est difficile de simuler un environnement de test :)
#3
J’imagine surtout que le retour en arrière a été cauchemardesque … Merde ça ne fonctionne pas ….
#4
Ce qui est presque sûr, c’est que des tas de salariés ont déjà dû voir le crash arriver, ont alerté, et des crânes d’œuf ont décidé malgré tout d’y aller comme ça et BOUM :)
#5
“Presque sûr”
#6
#7
C’est quand même impressionnant de la part de la sncf, une mise en prod foireuse ça arrive, mais ils n’ont pas anticipé une solution de secours.
Un TGV n’a quasiment pas d’instrument à bord, tout est envoyé en temps réel via les rails (un truc du genre), ça permet d’avoir une précision diabolique dans la gestion du train (les vitesses sont limitées, les zones de travaux prises en compte,…).
Mais forcément, si la sncf pète ce système en oubliant que si ça marche pas après, plus rien ne marche, c’est qu’ils sont doués… Et accessoirement, que si des terroristes arrivent à s’intégrer dans ce système télécommandé à passoire, il va y avoir des problèmes…
#8
Ce sont les stagiaires et juniors si font les tests, après on s’étonne que ça marche pas.
Ensuite y’a le directeur de projet si veut absolument mettre en prod sinon il tient pas sa deadline.
La convergence des contraintes fait que ça pète en vol !
#9
Je suis étonné que le nom du systémier responsable (Alstom, Siemens, etc) n’ait pas été communiqué.
#10
Pas exactement, mais oui beaucoup de choses sont envoyées au train.
Par contre tout le programme interne est “hermétique” quand tu connecte 2 TGV ils mettent presque 5 minutes à se “synchroniser”. Tu ne peux rien faire en attendant.
Les problèmes sont divers, l’avantage c’est que le train est géré par des programmes et des “ordinateurs” séparés pour ses fonction (elec de puissance, elec contrôle, pneumatique, fonction pilotage, option intérieur, …) ça plus la redondance rendent le tout très robuste, rare sont les problèmes à imputer à l’informatique du train. Une grosse partie est aussi gérée à distance et le TGV le reçoit par radio.
#11
Merci pour le complément :-)
Mais si je comprends bien, ce système hermétique dépend forcément d’un extérieur qui est hiérarchiquement plus important, du coup le système est hermétique mais facilement perméable…?
#12
C’est marrant comme les commentateurs croulent sous les infos sur le déroulement interne de projet auxquelles la presse n’a pas eu accès.
#13
Peut-être des cheminots ou de la famille de cheminots simplement, ou des passionner de ferroviaires.
#14
#15
Je pense qu’il faut remettre dans le contexte aussi. Une mise en prod sur un systeme si complexe est compliqué, même avec tous les tests fait en avance. Tout est interconnecté, le moindre bug (et il y en aura toujours) peut tout faire tomber.
D’après ce que j’ai compris, les systèmes sont sous Windows 2.0 (oui).
Par contre, qu’il n’y est pas de procédure de rollback, ça, c’est pas normal. Que le système soit fait par un prestataire plutôt qu’en interne, c’est pas normal non plus.
Ecoutez https://www.franceculture.fr/emissions/linvite-des-matins-2eme-partie/sommes-nou… pour plus d’infos.