Discussion :

[Marc Lussac]

Emploi : une pénurie alarmante de compétences dans le domaine du « Mainframe » ?

Une étude européenne commandée par CA, révèle une pénurie alarmante de compétences dans le domaine du « Mainframe »

73 % des personnes interrogées en France, affirment qu’ils ne tarderont pas à être pénalisés par le départ à la retraite de leurs spécialistes du mainframe. Ce chiffre est supérieur de 7 % à la moyenne européenne.


Faits et chiffres clés :

1. 61 % des entreprises françaises consacrent moins de 20 % de leur budget informatique annuel au mainframe, ce qui reflète un coût total d’acquisition particulièrement faible.
2. S’il est connecté aux applications web et aux systèmes distribués, 70 % des participants indiquent que le mainframe présente un niveau de sécurité exceptionnel.
3. 70 % des personnes interrogées indiquent aussi que les niveaux de performance sont à leurs yeux « excellents », et 67 % déclarent que « le système n’est jamais indisponible ».

CA Expo (Paris La Défense), le 18 juin 2009 – CA (NASDAQ: CA), le plus important éditeur indépendant de logiciels de gestion des systèmes d’information, dévoile aujourd’hui, les résultats d’une étude mettant en évidence une pénurie alarmante de compétences dans le domaine du « mainframe » en Europe et plus particulièrement en France. Intitulée The Mainframe: Surviving and Thriving in a Turbulent World (Mainframe : Survivre et se Développer dans un Monde Instable), cette étude révèle que 73 % des personnes interrogées en France, contre 66 % pour la moyenne européenne, s’accordent à dire que les utilisateurs de mainframe ne tarderont pas à souffrir, si ce n’est pas déjà le cas, d’une diminution du nombre de professionnels dans ce domaine, les compétences nécessaires n’étant pas suffisamment disponibles.

Sécurité et performance

Par ailleurs, l’enquête révèle que lorsqu’un mainframe est utilisé en tant que ressource connectée aux systèmes distribués et aux applications web, les entreprises françaises mettent l’accent sur des avantages spécifiques par rapport aux autres utilisateurs européens. 70 % des participants indiquent que « cet environnement présente un niveau de sécurité exceptionnel » contre 65 % pour la moyenne européenne. 70 % des personnes interrogées affirment également que les niveaux de performance sont à leurs yeux « excellents » contre 63 % pour la moyenne européenne, et 67 % déclarent que « le système n’est jamais indisponible » contre 52 % pour la moyenne européenne.


Un coût total de possession très faible

Cette étude révèle également de manière tangible que les utilisateurs français de mainframe présentent un coût total d’acquisition (TCO) particulièrement faible par rapport aux autres pays. 61 % des entreprises françaises consacrent moins de 20 % de leur budget informatique annuel au mainframe. Parmi les pays ayant participé à l’enquête, seule l’Italie présente un chiffre aussi bas (65 %). En moyenne, 51 % des entreprises européennes ayant participé à l’enquête ne dépassaient pas ce maximum de 20 %de leur budget.

78 % des participants français à l’enquête reconnaissaient « être dans l’obligation de produire plus avec des moyens réduits », et il est intéressant, à cet égard, de relever que ces mêmes personnes accordent une importance toute particulière aux faibles coûts associés aux plateformes « mainframe ». 88 % de ces personnes sont restées attachées au mainframe en raison des coûts associés au passage à des environnements entièrement distribués, contre une moyenne de 76 % pour l’Europe. Dans le même temps, 30 % de ces mêmes personnes affirmaient que le coût par transaction était plus faible avec un mainframe qu’avec les autres systèmes.

Les entreprises françaises accordent une plus grande importance à la robustesse et à la sécurité de l’environnement mainframe que leurs homologues des pays européens. 58 % des entreprises françaises continuent à utiliser le mainframe en raison de sa fiabilité (moyenne européenne : 47 %), et 88 % d’entre elles font confiance au mainframe pour leurs grandes applications stratégiques contre une moyenne de 77 % au niveau européen. Inversement, 78 % des entreprises françaises s’en remettent à des systèmes distribués pour leurs applications les moins stratégiques (moyenne européenne : 69 %).

« Beaucoup d’entreprises voient, dans le mainframe, la plateforme stratégique incontournable pour l’informatique d’entreprise de demain, » explique Patrick Bojko, Directeur des Solutions, Ventes Mainframe chez CA. « Cette enquête montre que les départs à la retraite des spécialistes les plus compétents en matière de systèmes mainframe est inéluctable. Pour répondre à ce problème, CA a mis en œuvre son initiative Mainframe 2.0 afin d’aider les organisations à recruter une nouvelle génération de professionnels, moins aguerris aux systèmes mainframes, mais par ailleurs familiers d’outils de développement plus conviviaux tels que C++ ou Java ».

L’étude indépendante « The Mainframe: Surviving and Thriving in a Turbulent World » (Mainframe : survivre et se développer dans un monde instable) a été commandée par CA et réalisée par le cabinet d’études Vanson Bourne. 180 directeurs et hauts responsables informatiques ont été interviewés au total au cours de mois de février et mars 2009. L’échantillon comprenait 40 personnes par pays au Royaume-Uni, en France et en Allemagne, et 20 personnes par pays en Italie, au Bénélux et dans les pays nordiques.


À propos de CA | CA, Inc. (NASDAQ : CA), est le plus important éditeur de logiciels indépendant dans le domaine de la gestion des systèmes d’information. L’Enterprise IT Management (EITM) qui concrétise la vision et l’expertise de CA, permettent aux entreprises de gouverner, de gérer et de sécuriser leurs systèmes d’informations afin d’optimiser leur performance et d’accroître leur avantage concurrentiel.

Sites web : http://www.ca.com ou http://www.ca.com/fr

Qu'en pensez-vous ?

[kedare]

En fait aujourd'hui je me demande un peut quel est l'intérêt d'un mainframe plutôt qu'une solution en cluster avec des blades par exemple ?
Pourquoi choisir un mainframe de nos jours ?

[Pierre Louis Chevalier]

Déjà l'intérêt c'est de faire tourner des énormes applications existantes qui ont été développées pendant des années.

Ensuite des solutions mainfraime comme Cobol/CICS peuvent êtres encore très efficaces pour des traitements gestion très lourds et répétitifs, comme par exemple les traitements bancaire sur un très grand nombre de comptes et d'opérations....

[rberthou]

Déjà l'intérêt c'est de faire tourner des énormes applications existantes qui ont été développées pendant des années.

Oui, des applications critiques qui sont le cœur du SI de l'entreprise .

Ensuite des solutions mainfraime comme Cobol/CICS peuvent êtres encore très efficaces pour des traitements gestion très lourds et répétitifs, comme par exemple les traitements bancaire sur un très grand nombre de comptes et d'opérations....

Traitement de gestion très lourds... J'ai un doute, je ne pense pas que les transactions de gestion TP puissent etre lourde. Par contre CICS supporte parfaitement les gros nombre d'acces concurent (c'est un moniteur transactionnel...)

Les machines ont énormément monté en puissance ces dernières années et aujourd'hui je pense que dans bien plus de 50% des cas les mainframes peuvent etre remplacé par des serveurs de type "Intel". Le problème restant alors la ré-écriture des applications (des solutions complète de re-hosting existe - MicroFocu, Clerity, ..)

[chenel80]

En fait aujourd'hui je me demande un peut quel est l'intérêt d'un mainframe plutôt qu'une solution en cluster avec des blades par exemple ?
Pourquoi choisir un mainframe de nos jours ?

En effet ta solution est moins cher à mettre en place, mais tu te rendras vite compte qu'il est plus rentable d'investir dans le mainframe quand tu vois la place qu'il prend et la consommation en énergie très faible par rapport à ce que tu proposes.

Pour palier au manque de compétences sur cette technologie, des mesures ont été mises en place déjà.
Par exemple, des formations sont proposées dans le domaine du mainframe aux étudiants en fin de cursus, les places proposées ont été rapidement prises. Je ne pense donc pas qu'il y aura de problèmes de remplacement.

[CyberChouan]

Par exemple, des formations sont proposées dans le domaine du mainframe aux étudiants en fin de cursus, les places proposées ont été rapidement prises. Je ne pense donc pas qu'il y aura de problèmes de remplacement.

Le problème n'est pas seulement de remplacer les départ en retraite, mais de remplacer les compétences.

Or une formation de fin de cursus n'a rien à voir avec 30 années d'expérience, ou la connaissance pointue d'une application particulière sur laquelle on a travaillé pendant plus de 10 ans...

[Invité]

Les entreprises ne doivent elles pas prendre des mesures en internes pour préparer ces départs à la retraite ?

Pourquoi n'embauchent-elles pas des juniors et les faire se former avec l'aide d'un tuteur qui est dans les 5 dernières années avant sa retraite ? Cela coûte cher, mais cela ne vaut-il pas la peine de s'y mettre ?

Le problème aujourd'hui est que pour faire des économies, on diminue les coûts de formation des nouveaux arrivants. Avant, un employé avant de partir à la retraite prenait le soin de former les suivants. Maintenant, on attend qu'il soit à la retraite pour commencer le processus de formation.

[millie]

Pourquoi n'embauchent-elles pas des juniors et les faire se former avec l'aide d'un tuteur qui est dans les 5 dernières années avant sa retraite ? Cela coûte cher, mais cela ne vaut-il pas la peine de s'y mettre ?

Bah 5 ans... Je connais pas beaucoup de jeune qui reste 5 ans dans la même boite au début...
Il y a quand même un fort risque que le jeune se sauve avant d'être rentable.

[zecreator]

Le problème n'est pas seulement de remplacer les départ en retraite, mais de remplacer les compétences.

Or une formation de fin de cursus n'a rien à voir avec 30 années d'expérience, ou la connaissance pointue d'une application particulière sur laquelle on a travaillé pendant plus de 10 ans...

Je n'y connais rien en mainframe, je ne connais pas du tout le domaine, mais vous ne croyez pas qu'il aurait peut-être fallut se réveiller un peu plus tôt avant de tirer la sonnette d'alarme.

Perso, tant pis pour ceux qui vont se retrouver dans la mouize. Une entreprise, d'autant plus informatique se doit d'être au courant des tendances technologiques et savoir prévenir quelques années avant, les problèmes à rencontrer dans l'avenir, afin de mettre en place une solution.

ça me fait marrer moi, les boites qui veulent pas changer leur techno parce que ça coûte cher, et qu'ensuite ça pleure parce qu'il n'y a plus personne pour pouvoir administrer leur parc.

Tiens autre manque, il reste quelques écoles qui sont bien embêtées car y a personne pour pouvoir gérer du nano-réseau sur un parc de Thomson MO5.

Pareil, faut pas pousser...

[julien-blaise]

Salut,
Perso j'étais très intéressé par le Cobol quand j'ai commencé à travailler. J'ai même suivit une formation dans ce langage.
Par contre après ma formation, j'ai eu un appel de mon responsable :
"Bonjour, en faite t'as bien suivit ta formation et c'est génial, par contre on n'arrive pas à te positionner sur des projets Mainframe/Cobol. En faite le client veut des personnes expérimentés donc je te propose plutôt du Java". Et ça date de 3 ans même pas !!!
Conclusion ça démotive un peu. Ok y'a une pénurie, mais si les clients ne sont pas près à prendre des juniors pour assurer la maintenance de leurs systèmes et la formation des jeunes pour remplacer les départs en retraite, je dirais tant pis pour eux.
Ils font des choix qu'ils devront un jour ou l'autre payer. (Désolé si je suis un peu sec, mais certaines choses m'énerve un peu)

[Luc Orient]

En fait aujourd'hui je me demande un peut quel est l'intérêt d'un mainframe plutôt qu'une solution en cluster avec des blades par exemple ?
Pourquoi choisir un mainframe de nos jours ?

Je suis rentré dans une salle informatique (salle blanche) où se trouvaient, entre autres, deux mainframes d'IBM (des z10, le dernier cri en la matière). Place occupée faible, consommation électrique raisonnable (dixit notre guide) et dégagement thermique limité. Notre hôte nous montre ensuite tout au bout de la salle une série de serveurs "lames" HP (fort nombreux d'ailleurs), destinés à des calculs financiers "en grille".
Un véritable radiateur, c'était impressionnant !

Il nous avoue que cet équipement provoquait un déséquilibre thermique de la salle avec une consommation électrique telle, que, malgré une place au sol encore disponible, il n'était plus possible d'installer de nouveaux équipement informatiques dans la pièce, la limite de l'alimentation électrique étant atteinte.

Voilà une raison (parmi d'autres) qui peut justifier le mainframe ...

[jabbounet]

En fait aujourd'hui je me demande un peut quel est l'intérêt d'un mainframe plutôt qu'une solution en cluster avec des blades par exemple ?
Pourquoi choisir un mainframe de nos jours ?

Le cout d'une migration serait probablement prohibitif et assez risqué.
On parle de porter des applis qui ont 20 ans de vie derrière elle dans une nouvelle techno (cluster/java par exemple).


Ne pas oublier que pour porter ce genre d'appli comme souvent on aura:
- Une partie de code n'est pas décrite (comme souvent la doc n'est pas exhaustive)
- tout un tas de fonctionnalités n'ont pas évolué mais personne ne sais plus ce qu'il y'a dedans.
- certains sources peuvent avoir disparu (et la c'est boite noir que plus personne ne touche de peur de tout casser)
- remplacer l'équivalent de 20 de codage qui a fait ses preuves par un code neuf (qui ne se fera pas en claquant des doigt)

Bref c'est un risque d'indisponibilité très important du système et le temps c'est souvent de l'argent pour ceux qui utilisent ce type de système.

même si c'est techniquement faisable je ne crois pas q'un décisionnaire prendra cette décision ou alors il est bien fourni au niveau du pantalon, car le risque est énorme, sans parler du cout.

[rberthou]

Ne pas oublier que pour porter ce genre d'appli comme souvent on aura:
- Une partie de code n'est pas décrite (comme souvent la doc n'est pas exhaustive)
- tout un tas de fonctionnalités n'ont pas évolué mais personne ne sais plus ce qu'il y'a dedans.
- certains sources peuvent avoir disparu (et la c'est boite noir que plus personne ne touche de peur de tout casser)
- remplacer l'équivalent de 20 de codage qui a fait ses preuves par un code neuf (qui ne se fera pas en claquant des doigt)

Bref c'est un risque d'indisponibilité très important du système et le temps c'est souvent de l'argent pour ceux qui utilisent ce type de système.

même si c'est techniquement faisable je ne crois pas q'un décisionnaire prendra cette décision ou alors il est bien fourni au niveau du pantalon, car le risque est énorme, sans parler du cout.

Si on est dans cet état là :
- Une partie de code n'est pas décrite
- certains sources peuvent avoir disparu

Le système va déjà très mal, car je pense que la moindre modifications des chaines de traitement est très pénible, longue et parfois même impossible (si absence des sources d'origines).
Il est largement temps de faire un état des lieux et de re-documenter/cartographier son SI.

[jabbounet]

Si on est dans cet état là :
- Une partie de code n'est pas décrite
- certains sources peuvent avoir disparu

Le système va déjà très mal, car je pense que la moindre modifications des chaines de traitement est très pénible, longue et parfois même impossible (si absence des sources d'origines).
Il est largement temps de faire un état des lieux et de re-documenter/cartographier son SI.

"Le système va déjà très mal" c'est parce que je suis pessimiste de nature .

Je me souviens avoir débuté sur une tma de plusieurs applications en fortran/lisp en 1999 ou les les docs des applis étaient entassées dans une armoire et ou je devais faire de la spéléologie pour retrouver celles qui m'intéressaient.
Un jour alors que je cherchais des infos sur une des dites applis, je suis tombé sur un bout de spec et un listing (en assembleur) datant des années 70. mais rien entre les deux, alors que l'appli elle avait pas mal bougé (changement d'os de langage, ...).

Ceci dit c'était une expérience rigolote cette tma, j'avais une bonne partie de l'histoire de l'informatique devant moi celle comprise entre les années 1970 et 2000.

[el_slapper]

Tiens, c'est un peu mon projet qui va finissant, ça.....sauf qu'on a migré de COBOL vers COBOL. En explicitant un tas de trucs qui n'étaient pas documentés, en refactorisant partout ou c'était possible, en sortant un maximum de choses......mais il y a malgré tout des éléments que j'ai retranscrits tels quels, car nul ne sait pourquoi c'est là, mais chacun sait que sans, ça ne marche pas.

Je les ai quand même adaptés à du COBOL "moderne", c-à-d que j'ai remplaçé les horreurs du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 MOVE 0 TO I
A22.
 ADD 1 TO I
 IF I > LIMITE GO TO  A21.
 (.....traitement fonctionnel illisible.....)
 GO TO A22.
A21.

par des

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 PERFORM VARYING I FROM 1 BY 1 UNTIL I > LIMITE
    (.....traitement fonctionnel retravaillé et correctement indenté.....)
 END-PERFORM
 .

(je préfèrerais qu'il y aie des FOR/NEXT en COBOL, mais bon, ça y ressemble fortement, et ça suffit)

Mais ça en reste là, parceque même retravaillé et indenté, le code fonctionnel, je ne sais pas ce qu'il fait ni surtout pourquoi. Alors transférer le bidule sur une autre technologie, je veux bien, mais bon courage. Ca sera sans doute plus facile à partir de ma version que de l'ancienne, mais reste qu'il y a des blocs imbitables. Qu'il faudra traduire quand même dans le nouveau language. A l'aveugle.

Donc c'est compliqué. J'ai passé 1 mois de ma vie sur 2 programmes de 5000 lignes chacun, juste à rétrodocumenter. Et encore, les 2000 premieres lignes du premier programme, qui consistent en des traitements comptables(tous sur le format que j'ai cité au dessus, avec des labels aussi explicites que A1, A11, A22, A21, A12, A12, le tout dans cet ordre), j'ai fait comme les autres : j'ai renoncé et on garde, parceque ça marche. Rien que nôtre appli, la gestion de contrat, ça représente des milliers de progs de 2000 lignes en moyenne. Certains plus modernes et mieux commentés, m'enfin pas plus de la moitié.....

Et on ne doit pas faire 20% du SI COBOL.

Je ne dis pas que c'est pas possible, je dis plutôt que c'est énorme. Et qu'il faut accepter une certaine dose de pertes. Perte de données, perte de savoir-faire, perte de précision. Perte aussi dans le fait que les gens(les utilisateurs) savent se retrouver dans l'existant, et gueulent dès qu'ils ont un bel écran JAVA à la place - devant lequel ils sont perdus.

Mais si on commence à migrer tout ce qui est interface vers des langages "modernes", c'est parceque l'on peut découper en série d'écrans cohérentes. Pour ce qui est du noyau "referentiel/batch", c'est infiniment plus complexe. Et budgetivore. Tout ça pour arriver à des solutions JAVA ou les gens ne peuvent même plus bosser tellement la taille du projet met leur machines de compèt' à genoux à la moindre compil/remise à niveau.....

Si COBOL met autant de temps à mourir dans les très grandes entreprises, ça n'est pas un hasard.....evidemment, en PME, tout ce que je viens de dire n'a aucun sens.

[rberthou]

CA est un éditeur très important dans le monde Mainframe je ne suis donc pas certain de l'objectivité de l'enquête ().

1. 61 % des entreprises françaises consacrent moins de 20 % de leur budget informatique annuel au mainframe, ce qui reflète un coût total d’acquisition particulièrement faible.

Je pense que c'est 61% des entreprise équipées d'un Mainframe : Car il existe aujourd'hui de moins en moins d'entreprise conservant ce type de matériel (principalement pour des raisons de cout, de disponibilité de compétences, et de manque progiciel). Depuis mon début de carrière plus de 50% des sociétés que je connaissais équipées d'un mainframe l'ont abandonné.

2. S’il est connecté aux applications web et aux systèmes distribués, 70 % des participants indiquent que le mainframe présente un niveau de sécurité exceptionnel.
3. 70 % des personnes interrogées indiquent aussi que les niveaux de performance sont à leurs yeux « excellents », et 67 % déclarent que « le système n’est jamais indisponible

Entièrement d'accord avec cela si on parle d'environnement MVS (dans le cas de VSE, je pense que les perfs et el niveau de fonctionnalité est très faible - a cause de la version de DB2 qui n'évolue presque plus).
Par contre je pense qu'un système Unix/Linux administré correctement fournis également une excelemente qualité de service.

« Beaucoup d’entreprises voient, dans le mainframe, la plateforme stratégique incontournable pour l’informatique d’entreprise de demain, » explique Patrick Bojko, Directeur des Solutions, Ventes Mainframe chez CA.

Je ne suis pas d'accord, cela resteras vrais pour certaines très grandes entreprises (banque , distribution, assurance, ...) mais globalement je pense que le nombre de site mainframe continua de chuter . La fin de certain produit comme PacBase accélèrera je pense le mouvement.

« Cette enquête montre que les départs à la retraite des spécialistes les plus compétents en matière de systèmes mainframe est inéluctable. Pour répondre à ce problème, CA a mis en œuvre son initiative Mainframe 2.0 afin d’aider les organisations à recruter une nouvelle génération de professionnels, moins aguerris aux systèmes mainframes, mais par ailleurs familiers d’outils de développement plus conviviaux tels que C++ ou Java ».

En plus de 20 ans d'expériences Mainframe je n'ai presque pas vu évoluer l'environnement de développement pour ces plateformes (SDF pour remplacer les macros BMS, et je crois qu'il existe un produit IBM pour developpement déporte dans Eclipse mais uniquement sur MVS et d'un cout important)
Le reste des évolutions reste très techniques (APPC => CPIC, SNA => TCP/IP, généralisation des connecteurs CICS CTG, DB2 - DRDA, ...) cela à bien ouvert le mainframe au monde extérieure mais pas facilité véritablement le développement.


-----------------
Concernant la disparition des compétences je pense que c'est surtout un problème de perception, le Cobol, le PL1 le mainframe c'est l'informatique de "grand père" produisant des écrans noir et vert ...

Le Cobol c'est, comme tout langage, relativement simple à apprendre mais l'environnement lui est complexe (CICS, BMS, DL1, DB2, 3270, ...) et avec l'absence complète de support pour les émulateurs (de type Hercule) de la part d'IBM aucune (ou presque) école ne propose de reel formation dans ce domaine.

[aballarin]

Il faudait que l'on arrête d'opposer le Mainframe aux autres technologies. Sur le ZOS d'IBM, car c'est de cela qu'il s'agit, on peut TOUT faire: du Linux, de l'Unix, du Windows si l'on veut... On peut installer des serveurs d'applications sur des partitions Linux, installer des plate-formes d'échange sur d'autres partitions Linux ou Unix et des SGBD sur le ZOS. Ceux qui travaillent dans les Datacenter savent très bien qu'une machine de ce type peut remplacer des dizaines d'autres serveurs Unix qui consomment énormément d'énergie.
Pour un développement durable, le mainframe est une solution écologique.
Abal

[Invité]

Il faudait que l'on arrête d'opposer le Mainframe aux autres technologies. Sur le ZOS d'IBM, car c'est de cela qu'il s'agit, on peut TOUT faire: du Linux, de l'Unix, du Windows si l'on veut... On peut installer des serveurs d'applications sur des partitions Linux, installer des plate-formes d'échange sur d'autres partitions Linux ou Unix et des SGBD sur le ZOS. Ceux qui travaillent dans les Datacenter savent très bien qu'une machine de ce type peut remplacer des dizaines d'autres serveurs Unix qui consomment énormément d'énergie.
Pour un développement durable, le mainframe est une solution écologique.
Abal

Ce n'est pas un problème d'opposition des technologies, c'est un problème de connaissances de base des mainframes. Très peu d'école proposent à leurs élèves des cours sur du Mainframe, et très peu d'entreprises font le pas vers la formation des jeunes.
La technologie du mainframe est une bonne technologie, mais si personne ne sait s'en servir, ça ne sert à rien.

[j.peg]

ouais... quand on parle de mainframe , généralement on pense à MVS et consorts (CICS, DB2, etc....) , pas vraiment à la machine côté hardware.
et sur ces environnements les compétences se font rares, les jeunes n' y étant pas formés (parce que ça fait 20 ans que certains annoncent la mort du mainframe pour demain... vu ce qui reste encore, ne serait-ce que dans les banques, y a encore du taff pour pas mal de monde...)