Nous avons soulevé à plusieurs reprises des incohérences entre les règles annoncées et écrites et les décisions prises lors du choix de l’environnement de production. Ces volte-face nous inquiètent.
Plate-forme IBM - z/OS quel avenir ?
Question que les techniciens de cet environnement se posent de plus en plus souvent.
Au printemps 2003, la décision d’implémenter WebSphere Application Server (WAS)sur IBM-z/OS a été prise. WebSphere permet d’exploiter des applications Java dans un environnement SUN-Unix ou IBM-WAS-z/OS. Cela permet la portabilité totale des applications indépendamment de l’environnement de production ! Les entreprises ne sont plus dépendantes d’un seul constructeur.
Des règles, établies par l’architecture en septembre 2003, définissaient les choix d’implémentation d’une application sur la plate-forme z/OS ou sur Unix. L’architecture préconisait la plate-forme SUN-UNIX dans tout les cas sauf pour 5 cas où elle recommandait la plate-forme IBM-WAS-z/OS [1].
Des règles changeantes selon le temps !
Après l’épisode TOPASE en 2003, le même revirement s’est produit en décembre 2004 pour MEDOC, prévu être exploité sur IBM- z/OS à Toulouse. Après une reconvocation, à la veille de la mise en production, le comité d’architecture a changé d’avis : ce sera sous SUN-Unix .
L’architecture a tout simplement retirer 3 recommandations ne laissant sur z/OS uniquement les applications de type transactionnel et l’accueil de l’outil de webisation (Crysalid).
Quand on sait, qu’aujourd’hui, il n’existe aucune application de type transactionnel avec la règle du commit à 2 phases et que l’architecture elle-même ne recommande pas l’écriture de ce type d’appli, il ne restera que l’outil de webisation sur le WAS z/OS.
Que de gâchis ! (fric, investissement en matériel, personnel ...)
Depuis 5 ans, les équipes systèmes MVS de DPI sont en pointe dans la mise au point de ces nouveaux environnements développés par IBM. AF est dans les toutes premières entreprises européennes dans l’utilisation opérationnelle du Sysplex , du CICSplexs, et du MQplex . DPI obtient ainsi un très haut niveau de fiabilité et de disponibilité pour les applis critiques AF. Pourquoi DPI n’utilise t-elle pas pleinement cette expérience avec tous les investissements réalisés en formation et matériel depuis 5 ans ?
Quel gâchis, alors que nos dirigeants nous bassinent avec leur réduction des coûts de 10 % !!! Comment la direction peut-elle, à ce point, ne pas tenir compte des compétences reconnues sur les différents sites, compétences qui permettraient à la DGSI de mettre en œuvre une informatique moderne, fiable répondant aux exigences de nos utilisateurs.
La DGSI nous a habitué à ces changements de stratégies à 180° sans véritable raison rationnelle si ce n’est politique ! Mais ces changements selon le sens du vent ne nous rassurent pas. Ils peuvent conduire à une désorganisation de la DGSI qui servirait de prétexte à une externalisation totale DPI et DSA quelques années après.. En l’absence de plan « industriel cohérent » du projet Latitude, nous nous méfions de toutes les décisions qui peuvent sembler aller dans l’intérêt à court terme des salariés mais une fois connu l’ensemble des décisions risquent de révéler un beau bazar !
Nous le constatons en ce moment. Alors que les ateliers de travail viennent juste de commencer et que leur conclusion n’est prévue que fin mars. Nous apprenons incidemment qu’une application GV STAR, colorisée AF dans les synergies AF-KLM, reste à Vilgénis. Les salariés concernés seront certainement rassurés mais pour combien de temps ? Cette appli devait migrer de Vilgénis vers Toulouse pour compenser la migration vers Valbonne ou la perte de très nombreuses activités DSA (50 postes en tout soit 1/4 de l’activité) annoncées dans le projet Latitude. Pourquoi ce changement soudain ? Serait-ce alors Socle Vol ou Socle PN qui migrerait à Toulouse pour compenser ? Ce n’est pas ainsi que la DGSI va construire un projet industriel cohérent et crédible pour tenter de faire avaler le projet Latitude et ses suppressions d’emplois.
Bien au contraire, elle multiplie les inquiétudes. Si pour garder nos emplois, la direction ne comprend que le rapport de force, nous n’hésiterons pas à vous mobiliser rapidement pour défendre nos emplois et nos activités DPI et DSA.
Que dire des propos tenus par un responsable, pilote de l’atelier de travail « Equipe Système Unix », dans le cadre du projet Latitude : « Donner un coup de pied dans la poubelle, il en sortira 3 ingénieurs z/OS »
Quand on sait que cette personne est aussi responsable des équipes système donc de celle du système z/OS, on mesure tout le manque de considération que porte la hiérarchie sur l’ensemble du personnel. Comment les équipes systèmes zOS, qui dépendent de ce responsable, peuvent continuer à le respecter quand il fait preuve d’une attitude si méprisante ? La Direction doit en tirer les conséquences si elle souhaite que son organisation fonctionne bien.
[1] L’utilisation de z/OS avait été retenue dans les cas suivants :
[2] D’après la devise de la ville de Paris « Fluctuat nec mergitur » : il flotte mais ne coule pas. Nous vous laissons traduire Fluctuat et mergitur !
