Lettre RePeGlio  Février 2009   

Les lignes sont elles en train de bouger?

Selon le consultant Robert Tipton dans un article paru dans Systemi News US, il y aurait 80% des projets informatique de gestion qui rencontrent des problèmes une fois mis en production. Un tel niveau de malfaçons serait tout simplement mortel pour n’importe quel autre secteur de l’industrie. « Imaginez que le maire d’une grande ville commande un pont et que l’ingénieur lui réponde qu’il y a 80% de chance que le pont se fissure dangereusement une fois fini ? » interroge fort justement Robert Tipton.

Mais ces défectuosités semblent ne pas devoir incommoder le lobby des « nouvelles technologies ». A ce propos, le site Voyages-SNCF.com est toujours cité en exemple pour contredire ceux qui, comme nous, émettent de sérieux doutes.  Nous partageons cet enthousiasme à propos de l’informatisation de la SNCF qui est vraiment l’une des plus grandes réussites mondiale, mais il conviendrait de nuancer un peu.

Le système de réservation « Mosaique » de la SNCF est un projet gigantesque qui repose sur une architecture « moderne » de type Client/Seveur. Ce site reçoit 700 000 visites par jour avec 38 millions de billets vendus en 2007, soit le quart des tickets SNCF. Cependant, il est de notoriété publique que le site internet Voyages-SNCF.com connaît régulièrement des problèmes dus aux montées en charge lors des vacances scolaires. Ce site se plante lors des affluences record comme le jour de l’ouverture des réservations de Noel où il y a un million de visites. La SNCF parle alors de bug informatique au sens large. Ces pannes qui surviennent souvent en plein mois de Juillet durent généralement 30 heures. Pour faire face à ce genre de bug, une cellule de crise de 80 personnes est toujours sur le pied de guerre prête à intervenir de jour comme de nuit. En renfort, «nous avons même fait venir des experts informatiques d’autres pays » raconte Christophe Léon directeur du Marketing du site qui conclut : « le site est un outil complémentaire au service des usagers qui n’a pas vocation à remplacer les guichets à la gare. » Traduction : tant que l’informatique de gestion sera disséminée sur de nombreux serveurs nous ne basculerons pas dans le 21ième siècle.

Selon nous, le problème n’est pas du à la fiabilité des programmes de gestion qui ont été testés par 25 personnes avant leur mise en production, mais à un problème d’architecture Client/Serveur qui engendre une complexité. Il est triste de ne pas pouvoir compter sur l’informatique lors des pics de charge, là où la SNCF réalise le plus gros de ses profits et de son chiffre d’affaires. Les « nouvelles technologies » marchent quand tout va bien et cèdent lorsque l’on aurait le plus besoin d’un traitement informatisé de l’information !

Parfois, ce sont les terminaux connectés en simultané qui flanchent comme la panne de la Toussaint en Octobre 2007. « les échanges saturent et bloquent lorsqu’ils franchissent la barre des 2800 postes connectés sur 4000 » ajoute la SNCF. Les techniciens s’activent donc pour limiter et maintenir le réseau sous le seuil des 2800 postes ! il fallait y penser… il suffit de brider artificiellement la charge pour que le système se remette à fonctionner au moins partiellement, même avec des temps de réponse catastrophiques, mais cela donne un peu d’air, le temps de tenter de réparer...« heureusement que les clients avaient réservé d’avance sur internet » Autrement dit, un système qui tourne sur 3 pattes couvre l’autre qui tourne aussi sur 3 pattes, les deux s’épaulant mutuellement afin de prévenir une paralysie totale.

Etant donné les coûts faramineux engendrés par l’informatique et les risques encourus, certains consultants aux US se sont même demandés (avec une pointe d’humour) s’il ne serait pas plus rentable de revenir au travail manuel ! Il est vrai que recourir à l’architecture Client/Serveur pour faire de l’informatique de gestion c’est comme seller une vache et prétendre ensuite avoir un cheval de course flambant neuf.

Pour en revenir à la SNCF, Didier Fontaine, secrétaire général de Sud Rail se plaint des problèmes de fiabilité où même en temps normal il faut rebooter les serveurs 3 à 4 fois par jour. « Trouvez vous normal de rebooter un serveur 3 à 4 fois par jour ? » demande le représentant syndical. « c’est un peu comme si un cycliste sur le tour de France dont la chaine sauterait tous les 2 kilomètres dans les étapes de montagne disait que c’est un comportement tout à fait normal, de nature à améliorer les performances. »

L’architecture de type Client/Serveur n’a pas été conçue à l’origine pour faire de l’informatique de gestion de sorte qu’il est indispensable de multiplier à l’infini le nombre de serveurs interconnectés pour faire semblant de tenir la charge. Cependant, le système d’exploitation de ces serveurs est imprédictible car ce ne sont pas des OS « business class » comme dirait Frank Soltis contrairement à l’ IBM i et aux gros systèmes. Ainsi, un système rebooté n’est plus le même système d’exploitation avant qu’après. Imaginez des milliers de serveurs interconnectés les uns aux autres, chacun ayant un comportement différent de l’autre, et s’échangeant sur le réseau d’énormes masses d’informations quotidiennement. Cela donne une idée de la monstruosité cauchemardesque de ce type d’architecture. Intervenir sur de tels systèmes ultra complexes et non prédictibles ce n’est plus de la science, c’est du bricolage. « Faire du service » aurait changé de sens. Comme le résume un développeur sénior qui connaît bien le problème : « modifier les applicatifs sur ce type d’architecture est aussi dangereux que tenter de modifier les ailes d’un avion en plein vol avec les passagers dedans. »

Ce genre de panne récurrente SNCF a paralysé 800 terminaux sur 4000 en 2004 après une autre panne majeure survenue 6 mois plus tôt. « C’est inquiétant, remarque le Syndicat Sud Rail, à chaque fois que l’on touche au système il tombe en panne. »

Selon Frank Soltis, seuls deux systèmes d’exploitation « business class » sont capables de faire de l’informatique de gestion centralisée fiable et pérenne : le système IBM i et les gros systèmes IBM. Cependant, ces deux systèmes d’exploitation souffrent d’un manque évident : ils ne sont pas capables de gérer en natif des interfaces autres que les interfaces en mode caractères. Par exemple, une webisation des écrans, même sophistiquée, ne suffirait pas pour développer le site Voyages-SNCF.com ou les bornes de réservation dans les gares avec les écrans tactiles. Afin de parvenir à une informatique de gestion fiable multi interfaces, il faudrait que l’IBM i, qui possède selon nous l’ architecture la plus avancée, puisse gérer en natif aussi bien des interfaces en mode caractères pour le BackOffice, que des interfaces Web, des interfaces tactiles, des interfaces pour les téléphones portables Blackberry, iPhone etc… Cela serait selon nous tout à fait possible sans même devoir modifier les programmes RPG.

Si vous passez en revue le code d’ un programme RPG ou COBOL sur la plateforme i, vous constaterez qu’il n’y a pas de code relatif à la présentation. En effet, l’écran en mode caractères est conçu et compilé à 100% en dehors du programme avec un outil de design, généralement SDA. Le programme RPG ne gère que les données des transactions de la mémoire tampon des écrans et non la présentation totalement indépendante. Tant que les données des écrans restent de même nature et dans le même ordre dans la mémoire tampon des écrans et du programme, il serait possible avec des outil de design dans un environnement runtime dédié,  d’ajouter aussi bien des interfaces web pour le site Voyages-SNCF.com que des interfaces tactiles pour les bornes SNCF dans les gares en plus de nos interfaces en mode caractères pour le BackOffice. Après tout, une liste de trains pour effectuer une réservation n’est ni plus ni moins qu’un sous-fichier avec sélection. La saisie des références de l’usager revient à une suite de formulaires contrôlés. Nous savons gérer la logique applicative multi-utilisateurs depuis toujours avec l’IBM i. Selon nous, seul le Laboratoire Rochester pourrait procéder à la refonte de son OS afin de permettre la compilation d’autres type d’écrans que le DSPF dans un environnement runtime dédié.

Dans les années 80, une équipe de deux développeurs était capable de gérer tout le système d’information d’une PME et des centaines d’utilisateurs avec le Système S/38. Beaucoup de ces programmes qui ont souvent plus de 20 ans fonctionnent toujours. Il est donc démontré que les applications RPG centralisées sont  pérennes contrairement à l’architecture éclatée de type Client/Serveur qui risque de se scratcher dès que l’on touche quelque chose. Les IBM i  sont 600 fois plus puissants que du temps de l’AS/400 (de 10 CPW à 6000 CPW pour un petit POWER) et ils tiennent la charge depuis toujours.

Le 16 décembre 2008 nous avons participé à un chat mondial animé par Barbara Morris d’IBM, destiné aux développeurs RPG à propos des évolutions futures du langage RPG et de la version 6.1. Tout à la fin du Chat, j’ai posé la question à Barbara Morris (question from JeanMikhaleff) à propos des interfaces Web natives avec l’instruction RPG EXFMT (lecture/écriture des formats d’écran). Vous trouverez l’intégralité de la retranscription du chat ci-après et vers la fin la réponse de Barbara Morris :  « …that’s a known requirement and high on the list » traduction : « c’est une demande connue et en haut de la liste. » Par le passé, le management d’IBM ne s’avançait jamais lorsque quelqu’un posait ce type de question. Au risque de nous tromper, nous en déduisons donc que quelque chose est sorti des cartons pour l’ IBM i.

En tout cas, on peut dire ce que l’on voudra à propos de la stratégie d’ IBM et épiloguer longuement sur les errements qui ont pénalisés la plateforme i ces dernières années.  Cependant pour être tout à fait honnête, nous devons reconnaître qu’IBM reste la seule société au monde a proposer aux clients deux OS centralisés « business class » comme dirait Frank Soltis, entièrement dédiés à l’informatique de gestion avec l’IBM i et les mainframes. A notre connaissance, les concurrents d’IBM n’ont pas d’ OS multi-utilisateurs centralisé de qualité à mettre en face, ce qui est une lacune autrement plus pénalisante pour les clients.

Nous connaissons l’excellence de la société de services qui a développé le système d’information de la SNCF et la volonté de la Direction SNCF de mettre à la disposition des usagers ce qu’elle pense être le meilleur de la technologie du moment. Dans le jargon marketing « nouvelles technologies », ce qui n’est pas un échec total est considéré comme étant une réussite éclatante. De notre point de vue d’informaticien de gestion, ce projet prouve qu’il n’est pas possible de faire mieux avec une architecture éclatée, même en y déployant des moyens considérables, hors de portée de l’immense majorité des entreprises.

Dans ce contexte de crise technologique aigue, il y a  de la place pour le RPG et la plateforme i. Comme le répètent les Responsables Informatiques de la plateforme i pour justifier leur choix auprès des décisionnaires : « Au moins, quand un programme RPG marche, il marche ! »

Jean Mikhaleff