Reprise du message précédent :

 
Pour plein de raisons :
Car ces systemes ont été montés dans les année 80, tu as plusieurs generations qui sont passés dessus et que c'est devenu inmaintenable et pas du tout evolutif
Que tu as des limitations techniques importante et cela necessite un cout du run très important
Que la compétence Cobol disparait progressivement du marché avec les dinosaures et celle qui la remplace ce sont souvent des reconversions et ils n'ont aucune vision d'ensemble de ce genre de système donc ca accentue le point n 1.
Que les SI sont de plus en plus interconnectés et qu'en mainframe c'est plus complexe a mettre en oeuvre.
Car derriere ces systemes il y a des end users (gestionnaire, commerciaux) et que leur filer un minitel comme outil de travail c'est pas sexy
Que la productivité de ces ressources (formation à l'outil et l'utilisation en lui meme) est très faible et que tu te retrouves avec des plateaux de plusieurs dizaine / centaines de gestionnaire back office sur un minitel alors que la prise en main et la productivité serait bien meilleur sur un outil plus moderne.
 
Je dois encore oublier pas mal de choses

Je constate donc que tu ne connais rien au Mainframe. Alors déjà les écrans en noir et blanc vu à Conforama et la FNAC c’est fini vu que l’IHM est en Java donc côté prise en main c’est le jour et la nuit.
Je ne vois pas en quoi le cobol est moins maintenable qu’une application C# codée avec les pieds.
Le cobol comme d’autres langages est capables de se connecter à des bases de données donc à plusieurs SI.
Conclusion : le seul argument valable est bien le manque de spécialistes mainframe. Le mépris de ce qu’on ne connaît pas doit cesser. Je ne crache pas sur les nouvelles technologies.

Mouais toutes boîtes que je connais essaient de bazarder leur mainframe. En partie pour les raisons indiquées par Gugus mais comme tu le dis la technologie a bien évolué depuis.

Par contre IBM est bien en train de finir de tuer la technologie en rendant ses prix illisibles : "donc vous payez le hardware, mais avons nous parlé du prix des licences des softs indispensables calqués sur le nombre de requêtes/seconde maximum chaque mois ? Comment ça c'est pas du cloud et vous êtes propriétaire du hardware ?  Si deux personnes sont en mesure de se connecter au système (en même temps ou pas) c'est forcément du cloud et on peut en répliquer le business model !"

Oracle joue au même jeu avec son système de licences

Je pense qu'on peut encore bosser une carrière de 30/40 ans sans voir la fin du mainframe mais la tendance est bien de le dégager partout où c'est possible. Ça concerne aussi le Cobol qui est formidable question algorithmes/ stabilité mais qui meurt petit à petit aussi.

J'ai eu qu'une seule fois dans ma carrière une boîte (grosse structure située au Mans) qui m'a indiqué avec un grand sourire que la montée de version de Cobol s'est bien déroulée et qu'ils n'avaient aucun projet de migration. Tous les autres essaient de dépouiller l'application existante petit à petit pour pouvoir la bazarder dès que possible

Je travaille dans le Mainframe depuis 16 ans et je n’ai connu qu’une seule boîte d’assurance qui voulait se débarrasser du cobol. Et à chaque décennie on nous parle de la mort du cobol. Mais ce langage reste increvable. Il nous enterrera tous.

Jamais entendu dans mes clients assurance/banque que ça parlait de dégager le Mainframe. Trop compliqué et trop critique. On continue à se faire plein de blé en leur vendant des softs pour optimiser les mips et gérer les liens avec le monde distribué

 
Je pense que dire que ça fonctionne "bien" est un biais qui est créé par le fait que c'est inmaintenable et que personne n'ose y toucher.
 
En banque par rapport à des applis "modernes" java par exemple, il y a des problèmes de perfs absurdes, par exemple les rapport de réconciliation qui ne remontent pas du tout passé un certain seuil, parce-que quelqu'un a jugé à une époque, que rendu à une certain seuil, il valait mieux ne rien remonter.
 
Peut être que ce seuil était la car fonctionnellement ça devenait humainement impossible à traiter, ou alors parceque le système tombe.
On sait pas, ceux qui bossent dessus savent pas, et ce truc maintenu par un presta couterait 100 man days à investiguer changer, et un délai de 6 mois peut être.
 
Donc voilà problème de maintenance, de scalabilité, de compétences qui n'existent plus, absence de documentation, délai éffarrants.
Ils voulaient utiliser des uuid, et les champs existants n'étaient pas assez grands.
Ils avaient estimé que ça couterait genre 10000 man days pour faire les changements qui impactent énormément de choses.
Résultat ils utilisent des uuid tronquées qui forcément risquent de créer des effets de bords imprévus.
 
Mais comme tu dis, "ça marche bien", pourquoi changer ?

Sur quoi vous basez-vous pour dire que ça n’est pas maintenable ? Parce que vous avez vu une seule application cobol de toute votre carrière ? J’en ai vu au moins 6 avec certes sur certaines un manque de documentation mais sur d’autres avec des sachants encore présents et de la documentation. C’est fou que sur HFR on dénigre une technologie alors que c’est de l’informatique, la passion d’une majorité de forumeurs. Et franchement le smiley est mal venu ici.
Vous encensez les nouvelles technologies alors que vos témoignages montrent clairement que des développeurs font des usines à gaz incompréhensibles. Mais c’est tellement mieux de cracher sur un truc qu’on ne connaît pas.
Et vous croyez que les applications n’évoluent pas ? On se torche le cul avec le règlementaire et on paye des amendes à l’état ? Le taux de CSG des gilets jaunes ça n’est pas implémentable sur une application Cobol ?

 
C'est vrai que ça dépend de comment c'est codé, mais en général la façon dont c'est codé est déterminée par les investissements de la boite et la considération qu'elle a pour l'informatique.
 
Donc justement, j'ai bossé sur l'IHM magasin d'une boite dans la veine de celles que tu cites, et c'était une vraie farce.
Le développement avait été out-sourcé en Inde, ils ont explosé le planning, et rapatrié l'appli en catastrophe pour que du dev français travaille dessus.
On rigolait de désespoir, genre tu cliquais ça passait 100 fois dans le même listener.
Pour récupérer une valeur dans une Map, le type avait fait une itération sur la liste de clef valeur, avec un break quand la valeur matchait la clef.
On comptait plus le code mort dans if then else sur 7 niveaux, je ressortais les méthodes d'élagage de branche vues en fac.
 
J'avais aussi bossé sur une pauvre appli java swing tournant sur un serveur windows avec session locale ouverte, qui permettait de transférer les données de stock de bases mainframe db2 je crois, vers du oracle.
J'avais dit que ça servait à rien de le faire en java,  que ça serait plus performant avec des dblinks, et quelques triggers, et j'avais presque réussit à me mettre les anciens mainframiste dans la poche, qu'un "manager" m'avait dit "ha mais t'aime pas le java en fait ?", j'ai répondu "si, mais j'aime bien la base de donnée aussi".
T'imagine le niveau des types en fait qui croient que BDD et Java c'est des univers qui s'affrontent ???
Bref j'ai du me plier à leur truc, et là où ça prenait 1 heure de transfert ça en prenait 5mins à la fin.
J'ai jamais eu de remerciement bien entendu
 
Bref à la fin, il y a juste trop de gens à la ramasse qui savent pas ce qu'ils font, et ceux qui savent ce qu'ils font deviennent une menace
 

En attendant, ils sont payés 100k et toi?
 

Voilà. Merci. Enfin un vrai informaticien avec une vision globale et non méprisante. Chez mon client actuel on devait livrer une nouvelle version de l’IHM en java au début de ce mois-ci. Elle a été repoussé à cause de problèmes de performance propre au java. Chez un ancien client il y avait des bugs après chaque MeP sur l’IHM en NSDK car il n’y avait pas de véritable recette. Dans ces deux cas c’est de la faute des cobolistes et les développeurs IHM sont tous des êtres parfaits ?

Bref, hors redface, le problème principal c'est souvent pas le langage sauf quand c'est du full js non typé au lieu de TS ou du python sur une partie où la perf est importante par ex . Bref, le problème est que souvent on fait confiance à la mafia plutôt qu'aux passionnés souvent. Combien d'IT de banque vous voyez faire des conf Devoxx par ex?

Plus facile de brasser du vent que de se remettre en question. J’en ai vu des gens se prendre pour des cadors.

Bah comme je disais dans mon exemple, on le constate quand on fait une demande en amont, en aval la réponse en aval c'est "holala non on va éviter, car ça prend 50 man days a changer", alors que chez nous c'est 1 ou 2 lignes à changer, un commit, testé automatiquement devops par bdd tdd cucumber jenkins sonar ansible et mis en prod dans la journée, voir l'heure si il faut, c'est devops quoi
Ca prend 2 ou 3 clicks pour mettre en prod, le plus long c'est l'administratif et les validations à obtenir des n+x.

Eux je crois qu'ils ont même pas d’environnement de test, c'est peut être pas le cas partout bien entendu, mais ils font les modifs en prod direct, donc évidement tout devient plus risqué, plus long, car c'est pas que la technologie qui est obsolète, c'est aussi toute la méthodologie qui est en place qui a 30 ans de retard.

 
100k en sortie d'école ?

C'est souvent ça. Ils ont aucune industrialisation. Dans certaines COGIP, c'est le feu. J'ai entendu des témoignages. T'as un freelance, il fait un changement, il doit attendre 2j avant de pouvoir livrer. Donc tu continuais à mettre son 500 TJM en squattant internet, le temps de se faire débloquer par les OPS, DBA  

Ah mais ça c’est propre à leur méthode de travail et ça rejoint ce que dis Alpachinois. Je demande simplement à ce que des gens comme Gugus soient honnêtes et disent qu’ils haïssent le cobol parce que l’inconnu leur fait peur.

C'est ce que Dante touche au Luxembourg pour être manager IT dans une banque

Faut mieux faire un truc propre en JS/Cobol ou ce que tu veux plutôt qu'un truc dégueulasse en Java. Il y a des mesures simples qui permettrait de virer tous les mecs qui se prennent pour des cadors mais qui puent la merde en fait. Pull Request avec 2 validateurs minimum, outils style Sonar, calcul complexité cyclomatique, etc.
 
Si le mec sort 1 pull request tous les 3 mois, c'est qu'il pue la merde. Actuellement en démission, je fais une PR par semaine, j'ai l'impression d'être la dernière des merdes et de rien produire (ce qui est vrai )

Pour raccrocher les wagons avec le thème du topic :
Le code/applis existants est rarement remis entièrement en question.

Les admins/dev pour mainframe/AIX se mettent en consultants indépendants quand ils arrivent à un certain niveau de seniorité (et s'en mettent plein les fouilles sans parvenir à remplir 220 jours par an tant les projets sont lents et espacés chez les clients qu'ils gèrent suite à leur expérience).

IBM essaie de former tous les ans des alternants (3 ou 4 en parallèle) pour alimenter les clients importants (BNP à l'époque de BP2I en particulier) et les partenaires consultants "essentiels"  mais si il y a quelques dizaines de juniors par an qui arrivent sur le marché COBOL / Z OS / System I / AIX c'est bien le bout du monde de ce que j'ai constaté.

Depuis qu'HP UX / SUN sont morts et qu'on retrouve peu de fournisseurs concurrents du mainframe le racket par IBM ulcère tous les clients : un nouveau projet (refonte de front-ends, nouvelle application qui exploite le mainframe existant) sont demandés spéciquement en Java (avec Tomcat si c'est du web / REST) mais il est souvent hors de question d'alimenter les environnements existants de nouveaux usages (sauf si c'est juste une petite évolution / peu d'impact sur les MIPS).

Pour moi c'est tous les signes d'un écosystème mature. Qui rend l'âme petit à petit et qui finira par disparaître. Probablement pas dans les 10ans. Il est encore possible de se construire une belle carrière pepouze sur ces environnements mais attention ce sera pas ambiance GAFAM avec les salaires qui vont avec et une guerre de salaire pour s'offrir vos services. Plutôt un environnement feutré où l'on gagne bien sa vie mais loin des départements "innovation et R&D" et plutôt proche du legacy indispensable mais qui est un poil à gratter des DSI / CTO / CIO / responsables métier

Le problème c'est que c'est extrêmement difficile à faire passer.
Ca ne marche que si tu passes sous la masse critique de mecs nazes.
Donc ca passe par une recrutement plus rigoureux.

Ou je bossais t'as une équipe c'était impossible de leur faire utiliser git correctement avec des rebase, et le code review "ça sert à rien il y a pas le temps on peut pas tout vérifier".

Les conflits humains engendrés par les gens qui veulent pas faire de rebase etcetera, d'autant que le management ne virera jamais quelqu'un parce-qu’il fait pas de rebase
Donc les gens qui produisent du "code qui marche" arrivent toujours à s'en sortir, même si derrière c'est inmaintenable.
Il n'y a jamais vraiment de calcul du coût de l'inmaintenabilité.
Faut vraiment des grosses conneries en prod pour que quelqu'un soit dégageable, ou alors profiter d'une "baisse de budget"

Le problème avec les anciennes techno c'est que ça ne peut pas suivre les nouveaux concepts.

Par exemple si tu restes en java 1.4, tu pourrais pas utiliser plein de trucs, comme la programmation réactive, parceque les librairies n'existent pas pour les anciennes versions.
Donc tu perds un outil de scalabilité, et à un moment le gap devient trop important, et c'est un peu comme avoir une usine obsolète.

En fait je me suis toujours demandé pourquoi les GAFAM n'allaient pas plus sur le secteur financier.
Je pense que c'est parce-que c'est pas assez rentable déjà, et ils ont pas assez de compétences fonctionnelles, mais si ils s'y mettaient ça serait un peu des arcs et des fleches contre des fusils

Le cobol c’est plutôt du procédural donc on s’en fiche des évolutions de l’algorithmie. Il n’y a même pas de programmation orientée objet. On laisse l’IHM s’adapter à la sécurité de l’application.
Concernant le free-lance, je n’ai jamais vu ça. Mon client souhaite justement réduire le TJM des prestataires. Je ne suis pas prête d’être la reine du pétrole.

Java est un langage orienté objet, mais il a su évoluer vers une syntaxe fonctionnelle, qui rendent syntaxiblement bitable le concept de streams, qui sont importants pour la programmation réactive.

Ca me parait être un autre sujet, mais avec les IHM javascript la sécurité ne peut plus vraiment être gérée que côté client, sinon c'est open bar
Mais bon c'est un peu le même problème avec les IHM lourdes, qui sont en fait revenues en force avec IOS et Android.
Bref tu dois plutot passer par du webservice, et donc un serveur avec technos modernes.
Attaquer la base direct depuis une appli mobile ce n'est pas possible Enfin techniquement si, mais bon tu vas pas faire un user base par utilisateur de l'appli.

Tu as raison. C’est le serveur qui doit gérer. Et c’est bien normal que le langage a évolué.

Déjà ils doivent avoir quelques fonds qui détiennent des parts chez eux mais surtout ils ont aussi des services fi déjà style Apple Pay . Après c'est large la finance donc on verra

Osef des applis.
Seul l euro compte.

 
Apparament le payement ça permet aux banques surtout de capter des clients.
 
Il y a un moment où on pourra ouvrir des comptes chez google amazon apple
 
Après il y a la partie finance de marché.
Fonctionnellement c'est très compliqué, mais quelque part le métier de google ce n'est même plus l'informatique, c'est la pub, le targetting publicitaire, donc je pense que petit à petit ils peuvent s'attaquer à tout en fait ...
 
A la fin ça devient E Corp

 
De ce que je vois en 2019 c'était 1,6 millions d'euros soit donc un rapport de 1 à 8 donc. La même différence qu'entre le smicard et le top 1%.
 
Perso je touche 160K aux US, à Dallas en tant que Principal Engineer (dev senior) et je compte bien dépasser les 200K à terme. Je suis mal payé, mais faut bien avoir son visa.  
 
J'étais à 70K en France y'a encore un an, C'est moitié mois mais c'était en province et si j'étais pas parti, c'était 80K dans la boite d'à coté, toujours en province...  
 
Un pote un poil plus jeune est dans les 140K sur Paris. Il est pas PDG ou CTO non plus ni même manager.
 
Par le même raisonnement que le tien je peux pas immaginer que moi, grouillot et mon N+4/N+5 on touche le même salaire ou même qu'il ai juste 30% de plus.
 
150-300K en France et encore bien  plus aux US (ou certains dev touchent 500K par an) ça me choque pas.

 
L'Etat est actionnaire d'Orange, comme pour EDF ou la SNCF le salaire du CEO est limité à 500K environ.
 
Par contre je t'invite à regarder les rémunérations des PSG de boites françaises privées et on en reparle
 

 
Les écoles d'ingénieur sont pour la plupart gratuite en France et certaines des meilleures t'es payé. Ta aussi de plus en plus d'apprentissage ou tu alterne école et travail avec des salaire type smic ou 1.5 smic. C'est donc pas un probléme d'argent de pas faire d'école d'ingénieur.
 
 Si mon pére ou le tiens payent l'école d'ingé et la FAC d'ailleur c'est via leur impots et on leur demande pas leur avis.

 
Netscape a voulu tout refaire car code dégueux sans doute à raison. Du coup Internet explorer est passé devant (oui à une époque IE était le nouveau navigateur au top) et Netscape qui avait décidé de tout refaire à fait faillite.
 
Dans la réalité, je n'ai toujours vu quasiment que 2 types de codes:
- les code bien désignés et propre qui marchent pas et correspondent à de nouveaux développements. Par marche pas je veux dire que même si le code marche bien, il ne réponds pas vraiment aux besoin clients. La plupart des fonctionnalités sont pas encore implémentées.
- les vieux codes pourris qui fonctionnent bien.
 
C'est carricatural, mais assez vrai. Au début si les gens sont bon, ta du bon code, facile à comprendre. Par ce qu'il est petit, par ce qu'il a pas 20 ans de maintenance, évolution et débuggage deriére lui et par ce que l'équipe qui la conçue est la. Non seulement elle trouve son propre code bien, mais elle le comprends.
 
Et la techno choisie lui plait car c'est qui l'a choisie et qu'elle est à la mode du jour.
 
Mais ce code neuf en fait, il fait pas grand chose. Y'a peu de fonctionnalités, beaucoup de limitations.
 
Quand le code vieillit, on ajoute de plus en plus, on change. L'équipe à l'origine du design est partie promue ou à pris des job ailleur. Le code est de plus en plus gros, de plus en plus difficile à maintenir. Plusieurs générations de design, de façon de coder se mélangent et plus personne sait pourquoi les choses sont comme elles sont.
 
Prendre des bon aide, tu fais surtout des codes plus petits (les fameux micro services) et tu prend le temps de mieux faire, mais au final, quand même quand la code base est devenue 10X plus grosse et 10X plus vieille et traite enfin la plupart des besoins client correctement, le code est depuis longtemps beaucoup moins beau et clair.
 
S'occuper d'une vieux code en gérant la pression c'est ce qu'arrivent à faire les meilleurs et ce qui demande le plus de professionnalisme. Mais personne n'aime faire ça. Donc les bon vont faire des truc facile et amusant en faisant une V1 d'un nouveau projet ou ils seront considérés comme des rock star car il maitrisent tout. Normal: c'est eux qui ont tout fait. Encore heureux qui comprennent leur propre code.
 
Bien vu, les gus vont aller ailleur prendre une promotion ou quitter le navire dés que çá devient un peu plus chiant et leur super code devient un vieux code pourri en quelques années.

 
Réve pas les GAFAM c'est beaucoup de vielles code bases, des entreprises qui ont des disaines de milliers d'employés ou centaines de milliers pour quelques applications phares.
 
Tu croit vraiment que la code base de microsoft windows, du search engine de google ou de facebook est ultra clean, moderne et que tu carbure à fond ?
 
On compte plus les témoignages de gens désabusés qui ont fait quelques années chez des GAFAM, particuliérement Google et en sont revenus réalisant quíl étaient qu'un tout petit rouage dans une grosse machine avec une énorme innertie.  
 
Les GAFAM sont leader sur leur domaines, mais y arrivent en mettant des milliers de personnes sur chaque sujet. Y'a quelques années déjà, on disait que le module photo des iphones employait 800 personnes.
 
Les GAFAM sont d'énormes cogip, sur des marchés juteux. Et la priorité c'est la continuité du business. Et le mec trés bon a qui ont déroule le tapis rouge, c'est juste le grouillot de base là bas et il fait un boulot chiant.

Augment de mi année validée (passage de "sous grade" )
 
110K fixe + 40% bonus + 12% I/P
 
Malheureusement je veux quitter le conseil maintenant.

Pour quelles raisons ?

Marre de la vie de débile à finir après 22h pour des deadlines arbitraires, marre de l'éternel recommencement sur des projets de 3 à 10 semaines, marre du caractère scolaire de l'évaluation permanente

C'est pas le topic souffrance ici

On m'a demandé

Et en restant dans du conseil mais dans une autre boite ?