Bonjour
Nous continuons notre voyage dans le passé, en ce qui concerne les perturbations majeures qui ont marqué le RER B
Surtout quand l’application de Paul Courbis (courbis.fr) vous offre cette chance incroyable de disposer en ligne, pour les RER A à E, de toutes les notifications officielles des incidents depuis 2006
RAPPEL : Cet article fait aussi écho à l’article publié dans le journal Le Parisien du 06 Novembre 2016, où le site Citymapper avait publié, pour Octobre 2016 et 2017, un palmarès des temps moyens de retour à la normale, où le RER B avait obtenu les résultats suivants :
2h09 minutes et 56 secondes pour Octobre, avec 33 incidents
2h20 minutes 21 secondes pour Novembre, avec 22 incidents
Les réactions de la RATP et de la SNCF ne s’étaient pas faites attendre, et je cite Le Parisien :
« La RATP et la SNCF se montrent en tout cas sceptiques sur la méthode de calcul employée par l’application Citymapper concernant le nombre d’incidents et les temps d’attente correspondant. « Seule une analyse des données sur une longue période, couplée à une analyse fine des causes, est pertinente » souligne-t-on du côté de la régie. Tandis que la SNCF estime ces chiffres « fantaisistes » et « impossibles à vérifier ».
La SNCF n’a pas été extrêmement prudente quant au fait de chiffres fantaisistes et impossibles à vérifier
La RATP a été un peu plus finaude sur sa réponse
Que la RATP et la SNCF se rassurent, au Blog d’En Face, nous avons donc repris et considéré les incidents aux Jours Ouvrables et Heures de Pointe, en prenant en compte l’application Courbis.fr, qui indique les heures de début d’incident, de fin d’incident mais où le trafic « reste perturbé », et de retour à la normale
Côté fantaisie, ce n’est pas vraiment le genre de Courbis, puisqu’il s’agit des données de la RATP-SNCF! Et si la RATP-SNCF émettent des doutes sur la fiabilité de leurs données…
J’ai effectué et corrigé certaines erreurs dans le report manuel de données, mais cela ne passe pas inaperçue, certains calculs de temps moyens divergeaient et sortaient de la norme
Ce qui m’a posé le plus de problèmes : les incidents qui se finissent après minuit, les calculs de durée de temps n’étant pas très souples avec Excel
L’application Courbis.fr remonte les incidents que la RATP-SNCF jugent digne d’intérêt à prendre en compte. Et ce n’est pas la faute du site Courbis.fr si tous les incidents ne font pas l’objet d’une notification D’un autre côté, cela peut les arranger
Twitter permet aussi et depuis quelques mois de remonter des informations de perturbations, souvent à la suite de réclamations d’informations formulées par les twittos, mais certains incidents semblent ponctuels, où l’information de durée est absente
Comment quantifier la durée « d’un problème suite à la préparation d’un train » ?
La tendance actuelle, toujours observée fin septembre 2017 sur Courbis, étant que la journée est « normale » alors qu’il y a des perturbations, 2 mesures de sécurité suite à la manifestation du 21 Septembre 2017, par exemple, ont été passées sous silence
Quand nous n’avons pas l’incident notifié dans Courbis.fr, nous ne les avons pas pris en compte dans les tableaux ci-dessous. D’où le décalage observé avec le nombre total d’incidents, surtout pour 2017
Autre gentillesse : nous avons enlevé les mouvements sociaux Mais ces jours-là les incidents ont bien été pris en compte dans les reportings journaliers
Nous traiterons ce point des mouvements sociaux un peu plus tard
Nous faisons bien la distinction entre l’heure de fin de l’incident et l’heure de retour à une situation normale, à savoir qu’il n’y a plus de message relatif aux perturbations suite à la fin de l’incident
Nous avons fait ce travail de reprise des données entre 2007 et 2012, pour avoir justement du recul, et des données
Ce qui nous donne ce premier tableau récapitulatif entre début 2007 et à fin 2012, par ordre décroissant des N perturbations notifiées (temps exprimée en heures:minutes) , pour les incidents s’étant produits aux heures de pointes (7h00-9h30 et 17h00-19h30) et en Jours Ouvrables (lundi à vendredi)
Un graphe, pour donner une échelle de grandeur, entre les incidents
Deux types d’incidents sautent aux yeux : « Immobilisation maintenance », en 2011 et « Réduction offre » en 2012 Pour celles et ceux qui s’en souviennent, il s’agit des épisodes « Amiante »
Nous avons et aussi des « Fortes affluences voyageurs » : ils ne le sortent plus, ce motif de perturbation !
En détails cette fois-ci par année et sous forme de tableaux
Pour 2007 :
Pour 2008 :
Pour 2009 :
Pour 2010 :
Pour 2011 :
Pour 2012 :
Distinction SNCF-RATP : il y a-t-il une différence au niveau des temps d’incidents et de retour à la normale ?
SNCF :
RATP :
Note : certains incidents sont comptabilisés à la fois côté RATP et côté SNCF, il se peut que nous n’ayons pas la localisation détaillée, ou que l’incident perturbe toute la ligne Ce qui a été le cas pour les réductions d’offre et les immobilisations maintenance
Le Tronc Commun, comptabilisé à la fois côté RATP et SNCF, présente les incidents qui perturbent toute la ligne
Bon, ces histoires de Réduction d’Offres et d’Immobilisation Maintenance grèvent (oups !) bien les stats Nous les enlevons provisoirement!
Ce qui donne, pour l’intervalle 2007-2012 :
Contribution SNCF :
Contribution RATP :
Commentaires : Cela semble un peu mieux pour la RATP, par rapport à la SNCF, ce qui était l’inverse par rapport à la période 2013 à 2017
Nous retrouvons aussi des valeurs de temps moyens de perturbation et de retour à la normale cohérents par rapport à notre premier article pour 2012 à 2017
N’oublions pas qu’il s’agit d’un temps moyen et qu’un gros incident type rupture de caténaire ou rail qui casse peuvent avoir leurs poids sur ces temps moyens
Un peu plus de courbes ?
Par mois cette fois-ci, le temps moyen par incident (aux HDP et JO)
En 2007 :
En 2009
En 2011
En 2012
Et les temps de retour à la normale ? Toujours aux Heures de Pointes et Jours Ouvrables
En 2007 :
En 2008 :
En 2009 :
En 2010 :
En 2011 :
En 2012 :
C’était la deuxième partie
Et ensuite on essaierait de regarder les premières causes de perturbation, comment cela évolue sur 5 et 10 ans !
Par exemple, si nous regardons si les incidents sont du matin ou du soir ?
Sur 10 ans :
Entre 2013 et 2017 :
Etonnant non, ce 50-50 ?
Bref, nous avons un réservoir de données, constitué à partir des données officielles de la RATP-SNCF, et nous allons pouvoir nous en servir !
Il y aura aussi la possibilité de faire la distinction entre zone SNCF et zone RATP, bien que la ligne soit unifiée, voir comment le nombre d’incidents évolue, du moins lorsque nous avons les renseignements au niveau des heures
Mais ça, ce sera pour plus tard ! Ah ah ah!
Cordialement