Comment expliquer le dysfonctionnement informatique sur un poste d’aiguillage qui a entraîné l’interruption total du trafic dimanche 3 décembre en Gare Montparnasse ?
On sait que l’incident, d’une nature différente de celui survenu en juillet, a été causé par un dysfonctionnement informatique sur un poste d’aiguillage, détecté à l’issue de travaux réalisés sur ce poste durant le week-end qui a paralysé le trafic à la Gare Montparnasse. Mais quoi d’autre ? Que SNCF Réseau a annoncé « lancer immédiatement un audit de ses programmes de tests et de remise en service à la fin des grands chantiers ». Et que la ministre a demandé à Patrick Jeantet, le PDG de SNCF Réseau, de lui présenter rapidement une nouvelle organisation et un nouveau management de la gestion des grands travaux et de l’ingénierie, qui permettent de fiabiliser la réalisation de ces programmes de travaux et la reprise des circulations. Cela s’arrête là. Nous avons voulu en savoir plus auprès du président du Comité Français des Tests Logiciels (CFTL), Olivier Denoo. Quelles pourraient être les causes d’un test inopérant ? Quelles sont les bonnes procédures à mettre en place ? L’ampleur des chantiers complexifie-t-elle les opérations ? Nous avons également demandé à Olivier Denoo s’il avait des conseils d’ordre général à donner et/ou des interrogations à formuler.
« Premier élément : de façon générale, on est dans une recherche constante de la vitesse. Il faut développer, et livrer de plus en plus vite, avec de plus en plus de pression, et cela généralement au détriment de la qualité« . Deuxième élément : une informatique qui se complexifie, qui s’intègre de plus en plus à d’autres, avec « de la sous-traitance, des modules extérieurs que l’on ne maîtrise pas nécessairement« . Ici, on est vraisemblablement sur une communication qui se fait entre deux mondes différents, indique Olivier Denoo. « Vous avez le monde de l’embarqué avec la signalisation, les relais pour les aiguillages qui fonctionnent de façon différente du codage, du développement classique avec des logiciels présentant une interface homme-machine. Chaque élément de la chaîne devient de plus en plus un élément critique. Un bug quelque part, et toute la chaîne est impactée, car les maillons ne sont pas toujours doublés « . Et les tests ? « Même un test exécuté peut laisser passer un certain nombre de choses« . Il y a ce que l’on couvre, ce que l’on connaît de l’application ou de l’ensemble des applications que l’on teste : c’est l’étendue de la couverture, explique le spécialiste. Et puis il y a la profondeur de test, c’est-à-dire la quantité ou la variété de tests que vous assignez à un scénario donné. « On peut en oublier, ou en laisser de côté, si la pression du temps ou la pression financière se font trop fortes. Il est tout à fait possible que la SNCF ait une couverture impeccable, un jeu de tests relativement correct et des oublis… » Par ailleurs, faire des tests transverses qui parcourent tous les systèmes qui communiquent entre eux est compliqué. « Des environnements de tests difficiles à reproduire de manière interne, car coûteux et faisant intervenir briques logicielles et matériels« .
