Mainframe IBM : faire le pont entre deux mondes
Sur les environnements IBM, je n’arrive pas comme un ingénieur système z/OS — ce métier a ses spécialistes et je ne prétends pas les remplacer. J’arrive comme celui qui sait lire les applications, former ceux qui en héritent, et parler aux deux camps quand un projet met en face un patrimoine mainframe et une équipe qui n’en a jamais vu.
Ce que je couvre
Le niveau applicatif, c’est-à-dire ce qui porte la valeur métier : les programmes COBOL et leurs copybooks, les chaînes batch et leur langage de commande, les fichiers et leurs organisations, le transactionnel et sa logique d’écran, les accès à la base. C’est là que se trouvent les règles de gestion, et c’est là que se joue la reprise comme la migration.
Ce que je ne fais pas, et je préfère le dire : l’administration système, le paramétrage des sous-systèmes, l’optimisation de la consommation machine. Si votre besoin est là, il vous faut un spécialiste z/OS, et je vous le dirai plutôt que de tenter le coup.
Ce qui pose problème aujourd’hui
Une culture qui ne se transmet plus
Le mainframe a sa manière de découper le travail : traitements par lots enchaînés, jeux d’essai, reprises sur incident, séparation stricte entre environnements. Une équipe habituée au développement continu et aux services web ne manque pas de compétence, elle manque de ce modèle. Sans lui, elle lit chaque programme sans comprendre l’ensemble.
Le coût pousse à la décision, pas la panne
Contrairement à d’autres plateformes héritées, le mainframe ne tombe pas et ne manque pas de support. Ce qui déclenche les projets, c’est le coût d’exploitation et la rareté des compétences. La décision est donc financière, et elle mérite d’être instruite sur des faits techniques vérifiés plutôt que sur une promesse d’éditeur.
Le mélange des générations
Un parc mainframe a rarement une seule couche : du COBOL ancien, des surcouches plus récentes, des interfaces ajoutées au fil des besoins, parfois des ponts vers des applications réparties. La complexité réelle est dans ces coutures.
Ce que j’apporte
Lecture et cartographie applicative
Reconstituer ce que fait un ensemble de programmes et de chaînes, retrouver les règles de gestion, identifier ce qui est encore appelé et ce qui ne l’est plus, documenter les dépendances. Le livrable sert à maintenir comme à décider.
Formation aux fondamentaux
Donner à une équipe moderne les repères qui lui manquent : organisation d’un traitement par lots, lecture d’un enchaînement, structure des fichiers, logique transactionnelle, vocabulaire. Quelques jours suffisent à rendre lisible ce qui paraissait opaque, et cela change tout dans un projet de reprise.
Traduction entre les deux camps
Dans un projet de migration, le fournisseur cible connaît sa technologie et pas votre existant ; votre équipe historique connaît l’existant et pas la cible. Les malentendus qui coûtent cher naissent exactement là. Faire ce pont est le travail le plus utile que je puisse fournir sur ces environnements.
Pourquoi un consultant venu d’ailleurs
J’ai commencé dans l’informatique de gestion sur gros systèmes Bull et IBM, avant de passer à l’informatique industrielle sur matériel DEC puis sur ce qui a suivi — quarante ans en tout, dont quinze à Fos-sur-Mer. Ce parcours dans les deux sens est ici un avantage : ayant pratiqué OpenVMS, Bull GCOS et le COBOL sous plusieurs compilateurs, je repère vite ce qui relève d’une plateforme particulière et ce qui relève d’un principe commun. C’est ce qui permet d’expliquer un mainframe à une équipe qui n’en a jamais vu.
Pour qui
Les DSI qui préparent une décision sur leur patrimoine mainframe, les sociétés de services qui reprennent une TMA applicative, et les équipes modernes à qui l’on confie un existant qu’elles ne savent pas lire.