IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

La pénurie de compétences mainframe représente un risque accru pour les entreprises
D'après une étude réalisée par LzLabs

Le , par Dominique Rey

235PARTAGES

13  0 
Selon une étude commanditée par LzLabs, plus de 63 % des responsables informatiques ne cachent pas leurs craintes quant à un éventuel manque de compétences mainframe. Un manque qui serait causé par les départs à la retraite et qui risque de compromettre l’ensemble de leurs activités. Cette étude, menée par le cabinet d’étude de marché indépendant Vanson Bourne, révèle que cette pénurie de compétences affecte grandement les entreprises qui utilisent toujours les systèmes informatiques mainframe. Une majorité des répondants considèrent encore les applications mainframe comme un moteur pour leur métier. C'est pourquoi ils redoutent tant cette pénurie.


Cette étude a été réalisée auprès de 650 décideurs IT dans plusieurs pays d’Europe, au Royaume-Uni, au Canada, dans les régions DACH et en Amérique du Nord. Elle regroupe le secteur de la télécommunication, l’informatique, les services financiers, le secteur public et les organisations gouvernementales, tant dans le domaine privé que public.

« L’ampleur du problème des compétences mainframe est évidemment inquiétante. Cependant, le fait de voir que les responsables informatiques reconnaissent la nécessité d’agir est encourageant. Ces résultats montrent que des efforts pour renforcer les compétences du personnel existant, ou attirer de nouveaux talents vers de vieilles plateformes ne suffisent simplement pas à résoudre cette crise. C’est maintenant le moment pour les organisations de migrer leurs applications clés pour leur métier vers des systèmes ouverts modernes et d’en récolter les fruits », dit Mark Cresswell, CEO de LzLabs

Les formations sont insuffisantes

Afin de remédier à ces problèmes, il a été décidé que des efforts seront faits pour enrichir les formations. Il ne faut pas oublier que les failles proviennent surtout des formations. Une proportion massive des directeurs des systèmes d’information interrogés ont avoué que les formations leur faisaient grandement défaut. Pour preuve, 14 % d’entre eux ont affirmé ne former leurs équipes que sur une base mensuelle tandis que 37 % déclarent le faire sur une base trimestrielle et enfin, 16 % ont admis qu’ils ne le font qu’une fois par an. Si cela ne suffisait pas, l’insuffisance de cursus répondant aux demandes des entreprises confrontées aux manques de personnes spécialisées en mainframe vient accentuer le problème. Selon Thilo Rokcmann, directeur des opérations de LzLabs : « les conclusions de l’enquête de l’année dernière soulignaient la frustration des responsables informatiques face au coût et à la rigidité de leurs applications. Ce que nous constatons cette année, c’est la prise de conscience du fait que la perte de compétences mainframe constitue une menace importante dans les années à venir et que des approches fragmentées ne suffiront pas à résoudre ce problème ».

Source : Lzlabs

Et vous ?

Croyez-vous que ce manque de compétence proviendrait du manque de formation ?
Que faut-il faire pour remédier à cette pénurie de compétence mainframe ?

Voir aussi
:

IBM lance une nouvelle génération z15 de mainframe conçue pour les environnements hybrides
94 % des chefs de grandes entreprises envisageraient d’abandonner le système mainframe

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Darkzinus
Expert éminent sénior https://www.developpez.com
Le 13/11/2019 à 9:05
Citation Envoyé par SimonDecoline Voir le message
Perso je ne connais rien à ce domaine mais ce genre d'affirmation, c'est vraiment n'importe quoi : aujourd'hui beaucoup d'interfaces utilisateur sont des appli web, donc si ça se trouve, 80 % "de toutes les transactions financières se font à l’aide de programmes écrits en JavaScript". Et au passage, la citation de Gary Barnett date de 2005 (https://www.theregister.co.uk/2007/0...systems_part2/)...
Ce n'est pas parce que ton interface est dans une technologie que le "moteur" de la transaction n'est pas en COBOL. Dans le domaine des banques/assurances en tout cas la majorité des applications fonctionne comme ça.
7  0 
Avatar de i5evangelist
Membre éclairé https://www.developpez.com
Le 11/11/2019 à 9:29
Effectivement, faire de l'assembleur ou du Cobol sur Z, de prime abord ce n'est pas très attrayant mais avis aux smicards du développement oueb' : ça paie un petit peu plus que de faire joujou avec des éditeurs de texte colorés ^^
Note : Il me semble que le manque de ressource vient simplement du fait qu'on dit depuis 40 ans, que c'est mort, c'est pour les vieux (l'IBM i ex AS/400 est un autre exemple de ce genre d'inepties)
8  2 
Avatar de
https://www.developpez.com
Le 11/11/2019 à 19:12
Nettement moins qu'une baie VMware ou chaque micro-appication demande son propre serveur avec 10 couches de virtualisation

1 de mes AS400 consommait 2000w pour gérer l'ensemble des applications pour environ 400 personnes.

Et pour ton information je travaille actuellement à la fusion d'application de dixaines d'AS400 sur... un AS400 (le plus gros de France) d'une enterprise d'état...

Au passage eteinds ton PC, il consomme pour rien
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 13/11/2019 à 8:46
Citation Envoyé par Pyramidev Voir le message
S'il y a besoin d'une semaine, alors ce n'est pas un problème de langage, mais un problème de process ou un manque d'automatisation des tests ou des déploiements.
Et si tout dépend de tout dans le code, c'est un problème d'architecture du programme. On peut programmer correctement en POO, en architecturant un programme dont les dépendances forment un graphe orienté sans cycles (ou bien avec uniquement de tout petits cycles).
On peut, mais c'est plus difficile. COBOL étant facile, on peut faire des choses fonctionnelles et efficaces sans pour autant avoir à recruter des cadors. Faire de la POO propre, c'est difficile. C'est plus élégant, mais plus difficile.

Citation Envoyé par SimonDecoline Voir le message
Perso je ne connais rien à ce domaine mais ce genre d'affirmation, c'est vraiment n'importe quoi : aujourd'hui beaucoup d'interfaces utilisateur sont des appli web, donc si ça se trouve, 80 % "de toutes les transactions financières se font à l’aide de programmes écrits en JavaScript". Et au passage, la citation de Gary Barnett date de 2005 (https://www.theregister.co.uk/2007/0...systems_part2/)...
L'un n'empêche pas l'autre. Du web coté client, du cobol/mainframe coté serveur. C'est vers ça qu'on se dirigeait à la BNP/Paribas quand j'y traînais mes guêtres, au début des années 2000. La partie client du COBOL(souvent, mais pas toujours, en CICS), elle, est bel et bien en train de disparaître. Mais coté serveur, ça reste gigantesque. Cette taille et cette ancienneté posent deux problèmes majeurs aux décideurs qui voudraient remplacer ça. Ca coûtera un bras et demie, et surtout, on perdrait 40 ans de fiabilisations massives(je dis 40 ans, j'ai bossé sur des codes de 1972, soit 47 ans). Refaire à zéro, c'est prendre un risque de fiabilité - pas le genre des banquiers.
5  0 
Avatar de i5evangelist
Membre éclairé https://www.developpez.com
Le 11/11/2019 à 11:16
J'ai du mal à saisir ce que signifie "mainframe" ici.
Je pense que l'article désigne les les ordinateurs issus de la gamme IBM 360 et 370, voir fiche wikipedia : https://en.wikipedia.org/wiki/Mainframe_computer
4  0 
Avatar de
https://www.developpez.com
Le 11/11/2019 à 11:34
Elles sont ou les annonces de poste ? Je pense aux postes sur AS400. A part les SSII qui cherchent par principe en publiant la meme annonce systematiquement depuis des années et surtout sans avoir aucun poste a pourvoir (une fois que le candidat se présente elle regardent, argent facile) il n'y a pas d'annonces (Sur Lyon) ! Alors pénurie surement mais ou ?!

Technick
4  0 
Avatar de Anselme45
Membre extrêmement actif https://www.developpez.com
Le 11/11/2019 à 12:26
Selon une étude commanditée par LzLabs.... Cette étude, menée par le cabinet d’étude de marché indépendant Vanson Bourne
LzLabs dont l'activité est ... le... "Mainframe migration project" nous informe qu'il y a une pénurie de compétence dans le domaine... Heureusement, on peut faire appel à... LzLabs!
4  0 
Avatar de Kapeutini
Membre actif https://www.developpez.com
Le 11/11/2019 à 19:29
J'ai travaillé pendants des années sur as400 en commencant par le 34/36 en rpg pui rpgle et en dernier en java.

Mon plus beau contrat était une mission en Inde de 9 mois en accompagnement de mirages 2000 pour l'armée Indienne,
l'escadron des tigres :-)

Cela fait une drôle d'impression de voir voler un de ces zincs au dessus de la caste la plus basse qui vit dans des sortes
d'igloos en branchages et chiffons dans un terrain vague, sans eau, sans électricité alors qu'avec un seul de ses avions on pourrait ....

Mais le monde est ainsi.

On s'occupait d'un logiciel de maintenance pour Dassault.

Je sais qu'ici au Canada, le gouvernement en cherche et meme les formes en cobol.
J'ai postulé mais les salaires sont inférieurs à ce que je gagne , 80.000, je gagne plus . Et le cobol heu .... pas très chaud pour
quoique cela me semble bien plus facile que de coder du web en javascript avec une pléthore de libraries.

Je me rappel, il y a bien longtemps, on pestait contre les cobolistes qui imprimaient des compiles à rallonges et bloquaient les imprimantes de l'école :-)

Si vous voulez que je fasse du cobol, payez moi $ cad 120.000/an:-)

Ces machines étaient beaucoup plus stables, je le vois aujourd'hui dans mon travail.
4  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 12/11/2019 à 11:11
Je commence par un petit hors sujet :

Citation Envoyé par Dominique Rey Voir le message
(.../...)
Cette étude a été réalisée auprès de 650 décideurs IT dans plusieurs pays d’Europe, au Royaume-Uni, au Canada, dans les régions DACH et en Amérique du Nord. Elle regroupe le secteur de la télécommunication, l’informatique, les services financiers, le secteur public et les organisations gouvernementales, tant dans le domaine privé que public.(.../...)
C'est rigolo, ils ont entériné le brexit avant que celui-ci ne soit définitivement acté.

Bon, retour au sujet :

Citation Envoyé par i5evangelist Voir le message
Effectivement, faire de l'assembleur ou du Cobol sur Z, de prime abord ce n'est pas très attrayant mais avis aux smicards du développement oueb' : ça paie un petit peu plus que de faire joujou avec des éditeurs de texte colorés ^^
Note : Il me semble que le manque de ressource vient simplement du fait qu'on dit depuis 40 ans, que c'est mort, c'est pour les vieux (l'IBM i ex AS/400 est un autre exemple de ce genre d'inepties)
j'ai lu en 1986(j'avais 10 ans) que COBOL était mort. Il m'a nourri de 2000 à 2013(par intermittence, 8 and en cumulé, à peu près).

Citation Envoyé par defZero Voir le message
Absolument rien.
Il faudrait simplement arrêter d'utiliser ces architectures ultra proprio et les laisser mourir d'elles même.
Sérieusement, ça fait belle lurette que les entreprises en questions aurait dut migrer vers des serveurs sous archi x86/Power/BSD/Linux/Windows.
Si elles ne l'ont pas fait, depuis le temps, c'est que c'était un choix délibérer, à ce niveau là.
Le truc, c'est que
(0) L'existant en COBOL est immense, et la manière dont ça a été programmée est souvent soudée à l'architecture mainframe. L'investissement pour tout refaire des choses qui fonctionnent parfaitement serait immense.
(1) Le COBOL, ça marche. Entre 2010 et 2013, j'ai pu comparer activement notre équipe COBOL avec l'équipe JAVA à coté. Nos devis étaient moitié moins cher, et nos dépassements de budget deux fois moindre. Des estimations en 2000 trouvaient que le coût de passage à l'an 2000 était 30% inférieur sur COBOL par rapport à JAVA. Et pas avec des gens plus intelligents, hein. Et je ne parle même pas de consommation CPU; les ordres de grandeur n'étaient pas les mêmes. Fatalement, un langage conçu au début des années 60 se devait d'être économe en ressources.

Après, je ne suis pas aveugle. Plus personne ne veut faire ça, et le coût des licences est hallucinant. Et ce sont des coûts beaucoup plus faciles à mesurer que les frais de maintenance logicielle(qui sont pourtant bien supérieurs). Ca finira par crever quand même. Mais ça va prendre encore quelques décennies.

Citation Envoyé par defZero Voir le message
-1, Les gens qui dictent aux autres ce qu'ils/elles devraient faire .
Vas y toi, faire de l'ASM/COBOL pour AS400, AIX et compagnie.
On me souffle dans l'oreille, que même si tu voulais te former, il te faudrait avoir accès à ces petite bêbêtes .
Sans parlé des docs soumise à licence pour l'intégration système.
Et puis Java/C/Fortran/...etc sont tout à fait disponible sur Mainframe (pour peut qu'on est acheter une licence compilateur pour le langage, auprès du fabriquant généralement), je ne voit pas le rapport avec COBOL & l'ASM pour le coup.(.../...).
le COBOL seul, tu peux te former sur OpenCobolIDE. Le souci, c'est plus ce qui va avec : les JCL, les formats de fichiers exotiques, l'éditeur de textes ISPF, FILEAID, etc... des outils très puissants, mais qui demandent une longue initiation. Le COBOL, en soi, c'est assez facile, à écrire, et, plus important encore, à lire. Tout le savoir faire, c'est l'environnement ultra-sécurisé des mainframes. Qui est en totale contradiction avec ce qu'on apprend aux jeunes de nos jours.

Citation Envoyé par Kapeutini Voir le message
(.../...) Si vous voulez que je fasse du cobol, payez moi $ cad 120.000/an:-)(.../...)
Voilà. Je n'aurais aucun scrupule à m'y remettre, mais c'est payé au lance-pierres, surtout ici à Montpellier. Je gagne 10k€ de plus à faire des scripts de test automatique. Pourquoi revenir?
3  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 12/11/2019 à 15:04
Citation Envoyé par Darkzinus Voir le message
D'ailleurs les systèmes I sont devenus des machines de guerre sur lesquels il est plaisant de travailler ! (L'AS400 est un brin plus "convivial" que le mainframe)
C'est pas du Web, donc ça va faire fuir les jeunes..... J'ai eu des échos de gens dans divers domaines(blog pour chats, jeux vidéo), et les deux seuls critères de succès sont "j'ai mis du pognon pour que ça soit beau", et "j'ai mis du pognon pour faire de la pub". C'est la nature humaine. l'AS400, ça rete du mode texte, et ça suffit à faire peur, surtout dans un monde ou les graphismes sont omniprésents.

Citation Envoyé par Darkzinus Voir le message
C'est indéniable ça, les coups de développement sont beaucoup moins élevés en COBOL (et on rencontre très peu de mauvaises surprises sur les processus de livraisons, mise en production).
Une des raisons pour lesquelles on était si performants par rapport aux malheureux javaistes, c'était les temps de livraison. Java étant un langage essentiellement objet, tout dépend de tout. Donc, quand on relivre, on recompile tout, sinon, ça ne colle pas. Ils avaient des processus de livraison délirants qui leur prenait parfois jusqu'à une semaine. Moi, il me fallait une minutes pour livrer dans chaque environnement - on en avait 4, jusqu'à la prod. Donc, livrer une correction à chaud en prod, 4 minutes(contre une semaine). Fatalement, les gens des métiers préféraient avoir à faire à nous.

Citation Envoyé par Darkzinus Voir le message
Sinon on sent bien la volonté de vendre la solution de migration dans l'article. Car des ressources MAINFRAME on en trouve (même si actuellement c'est plus tendu que ça l'a été).
J'étais moins bien payé que les Javaistes. Je ne sais pas si c'est toujours le cas.
3  0