[Aedymo]

Bonjour à tous,

Je suis actuellement en pleine réflexion de reconversion professionnelle, ancien Ingénieur Commercial en SSII, j'ai accompagné de nombreux projets Cobol CICS et je me rend compte que le potentiel sur cette techno parait énorme.

Aujourd'hui, on me propose une formation et intégrer les équipes d'une très grosse SSII sur un forfait banque.

Je me dis que je peux éventuellement accepter le poste, et dans 3ans je passe en indépendant, les tjm sont de 280/350euros par jours...

Qu'en pensez vous ? Le potentiel métier est-il là ?

Merci d'avance

[LordYu]

Il y a 4 ans de ça un prof jurait que par le Cobol, affirmant qu'en l'apprenant maintenant et qu'en se spécialisant on serait les rois du pétrole étant donné que beaucoup de gros (et anciens) systèmes sont basés sur cette techno. Dans le fond il n'a pas tord, il semble que pas mal de banques et autres grosses structures s'en servaient il y a quelques années et ne comptent pas se débarrasser d'un système éprouvés et sécuriser.

Je ne connais pas vraiment le marché autour de cette techno, l'offre et la demande, mais en théorie s'orienter dans ce sens n'est pas une mauvaise. Essaye quand même de te diversifier un peu, ça fait pas de mal.

[Aedymo]

Merci LordYo, je suis avant tout un gestionnaire, j'ai été Chef de Projet, manager, contrôleur de gestion, donc je veux ajouter une composante technique à mon profil de façon à pouvoir intervenir comme chef de projet SI.

[Kathandro Jourgensen]

Tout dépend des entreprises clientes en fait.

Le Cobol a l'avantage d'avoir des variable numériques où on peut implémenter 30 chiffres, ce qui veut dire que ça peut compter en millier de milliard de milliard de milliard (et c'est le langage capable de faire ça de façon "naturelle").
Il faut voir aussi que les banques et autres sociétés financières sont plutôt frileuses à l'investissement technologique (elles utilisent beaucoup de Visual Basic par exemple, alors que c'est un langage vraiment peu pratique).

Du coup, les SSII se débrouillent pour choper des contrats des banques qui n'externalisent pas leur informatique. Pour les banques qui ont un service info interne, assez peu de programmeurs suffisent, donc c'est pas non plus l'extase au niveau des contrats en indépendants.

[Aedymo]

Oui je pensais proposer mes services au indépendant, je bossais avec de nombreux indépendants quand j'étais IC en SSII

[Yeuse]

1) les développements/maintenances des applis gros système font de plus en plus l'objet de contrats avec des SSII qui ont le minimum de personnel en France, l'essentiel étant par exemple au Maroc
2) forte tendance à une diminution drastique du nombre de SSII et surtout plus d'indépendants, chez nous il y a eu contrat avec une SSII pour garder certains indépendants mais sur le contrat c'était un presta comme un autre.
3) forte tendance à vouloir se défaire du cobol (sachant qu'on a encore de l'assembleur c'est pas pour demain)

[Aedymo]

j'ai bossé dans une SSII du top 5 Francais, effectivement on passait des freelance, par contre jamais entendu parlé du Maroc, mais ca doit être une solution oui vu que c'est très courant les dev externalisés en europe.

[Yeuse]

ben une des plus grosse banque française a fait sa propre filiale et les SSII qui ont encore un contrat ont "accepté" de faire de même...

[Caniveau Royal]

SN-Seign,

J'ai fait du Cobol pendant dix ans sur IBM AS/400 pour l'abandonner il y a une douzaine d'années et passer à Java rapidement.

Le Pour:
Les premiers informaticiens à partir en retraite sont ceux sur mini-systèmes et gros systèmes où Cobol est très présent. N'était la crise, le manque serait déjà important. D'autant que tout ce qui est banque et assurance est en Cobol. Et ne peut pas trop bouger parce que c'est très mastoc, et que on va être clairs: "Certains trucs tiennent debout, on ne sait pas pourquoi et on n'y touche surtout pas...". Bref, ces secteurs vont appeler du monde pour des modifications au jour le jour. Pour qu'ils réalisent des expédients.

Le Contre:
C'est pour autant un langage parfaitement moribond. Mais alors: absolument, totalement et complètement.

Si une entreprise a la possibilité d'abandonner des traitements en Cobol, elle le fait dès qu'elle le peut.
Le langage est vieux, il connaît les procédures mais pas les fonctions, les variables globales mais pas celles locales, se modularise mal, ignore les transactions, offre peu d'outils pour produire des sorties xml, html. Il n'a pas été capable d'évoluer.

Et une entreprise peut très bien décider voyant ses collaborateurs partir qu'elle va tout ficher à la poubelle pour partir sur une autre solution. Relativement hasardeuse de prime abord, mais qu'elle passera de force:
Durant le passage an 2000 et euro, par exemple, bien qu'il leur en ait coûté, beaucoup de sociétés ont abandonné leur moyen ou gros système impossible à faire migrer tant le code était profus, délicat à comprendre ou même parfois in-recompilable: des sources pouvaient avoir été perdus! Et pour mon expérience, à l'issue de cette période, le parc AS/400 - grand détenteur de Cobol - a été divisé par cinq: tout simplement parce que les entreprises avaient décidé de faire table rase et de jeter brutalement (en trois ans) leurs vieux traitements Cobol qui avaient un coût de maintenance abominable et qui ne pouvaient supporter les changements majeurs.

Ma conclusion: tu peux profiter d'un effet d'aubaine,
mais Cobol n'est pas pérenne.

P.S.: Un tjm à 280€ = tu joues du violon sous les ponts.
P.S. n°2: En freelance, tu trouveras peut être des missions dans des compagnies d'assurances mais plus dans les banques. Depuis deux ans, la plupart d'entre-elles refusent tout net les free-lance.

[kermo]

Tu peux te spécialiser en transfert des applis Cobol vers des langages plus modernes, j'imagine.

[Dworkin]

Je ne sais pas pour Cobol, mais je travaille dans une grosse entreprise à la technologie vieillissante (informatique du moins), et quand le seul employé spécialiste d'une de ces technologies quitte la boite ... on est dans la merde
Donc je pense qu'il y aura toujours un besoin pour ces vieilles technologies, le tout est de pouvoir quantifier le besoin et se restreindre au entreprises connus pour utiliser des vieilles infrastructures (les banques, l'administration ...)

Mais je m'étonne plus de rien, récemment un collègue nous a quitté pour aller bosser dans une start-up spécialisé dans l'AS400 ...

[Jyharl]

A chaque fois que je vois COBOL écrit, je repense sans cesse que pendant de longues années d'adolescence, j'ai cru que le langage s’appelait le KOBOLD.

[Dez]

Si c'est un calcul sur le CV, pour te vendre sur des missions particulières, c'est un bon plan. Par contre, ça va demander une vrai maîtrise ; le but ne sera pas de vendre des applications en COBOL, mais de comprendre des applications (tentaculaires) déjà existantes, pour les maintenir et/ou les migrer.

Et c'est pas une partie de plaisir. Être capable de relire et d'intégrer le code d'autrui (surtout quand les commentaires laissent à désirer) demande une bonne maîtrise du langage en général. Que ce soit pour le COBOL ou autre.

Je ne vois pas ça non plus comme un frein pour une évolution. Quand tu sais développer, tu maîtrise l'algorithmie, passer d'un langage à un autre est une question d'entrainement et de pratique de la sémantique et de la grammaire. Quelques nouveaux concepts à intégrer selon les langages, aussi. Mais un bon développeur dans un langage donné (ie, COBOL) saura s'adapter.

Après, oui, c'est pas un langage d'avenir. Utilisé, mais à contre-coeur.

[Eno]

Travailler sur des trucs pareil c'est s'ennuyer toute la journée, en dehors de l'argent il n'y a pas d'intérêts

[Bjorn]

Citation :

Publié par Caniveau Royal

Le Contre:
C'est pour autant un langage parfaitement moribond. Mais alors: absolument, totalement et complètement.

C'est exagéré et pas totalement vrai.
Ce qui est vrai, c'est que les entreprises n'ont plus pour cible de faire évoluer leur systèmes en cobol.
Pour autant, et c'est principalement vrai pour les banques et assurances, mais aussi pour une bonne partie de grande distribution / grands commerces, l'existant est TRES, TRES lourd, et n'est absolument pas en phase d'abandon.
Le langage serait moribond si le but avoué était de remplacer les programmes à court terme. C'est pas le cas.

Je sors de 4 ans auprès d'une banque. Le principe est encore aujourd'hui le suivant : le métier, les traitements sensibles, restent en cobol. Seule la partie présentation à l'utilisateur est faite en nouvelle techno. Toutes les bases sensibles (donc en gros toutes les bases sauf quelques unes) sont sur gros système, et sont donc interrogées en cobol. Le traitement des données est en cobol, et on remonte juste les données à une interface web pour affichage.
J'ai donc écrit des programmes cobol à partir de rien pendant 4 ans. Certes pas régulièrement, on est beaucoup plus sur de la maintenance, mais quand meme.

Bref, tout ca pour dire que dans 20 ans, des programmes cobol, il y en aura encore. Et le gros problème de ces entreprises, c'est qu'aujourd'hui, plus aucun (jeune) programmeur ne veut faire du cobol, c'est super compliqué de recruter.
Donc, même si évidemment pour un débutant, s'orienter uniquement cobol c'est pas la chose à faire, il faut se dire que ceux qui ont des compétences cobol ont un avenir, sans trop de problème. Il va réellement manquer de compétences dans ce langage et sur gros système.



Par contre, en tant qu'indépendant, ca me parait mal barré. Ces grosses entreprises travaillent plutôt avec de grandes SSII, très peu directement avec des indépendants. Et comme, en plus, en prestation les missions sont de maximum 3 ans, si tu trouves une fois une boite en tant qu'indépendant, elle ne te gardera que 3 ans. Les clients avec du cobol sont pas non plus légion, je doute que tu arrives à t'établir en indépendant là-dedans.

[Aedymo]

Il y a deux ans, une très grosse banque internationale à refondu son SI, et elle a développé une bonne partie de son SI sur du COBOL (Unix).

Et effectivement, je pense travailler avec les SSII pour travailler en indépendant. Lorsque je bossais en SSII comme IC, je travaillais en collaboration avec des indépendants qui encaissaient 80% du TJS et moi 20%, ils travaillaient donc pour moi chez le client (banque / assurance)... MMA était mon principal client.

[Caniveau Royal]

Citation :

Publié par SN-Seign

Merci LordYo, je suis avant tout un gestionnaire, j'ai été Chef de Projet, manager, contrôleur de gestion, donc je veux ajouter une composante technique à mon profil de façon à pouvoir intervenir comme chef de projet SI.

Je ne comprends pas par ailleurs comment après un tel parcours tu accepterais une telle régression. Redémarrer analyste-programmeur Cobol... j'ai débuté ainsi il y a plus de vingt ans: trois semaines de formation: c'était large, et un salaire au SMIC derrière. (mais c'était il y a vingt ans).
AP Cobol, c'est le niveau le plus bas de l'informatique. Que peux-tu gagner à aller t'y perdre que tu ne peux pas atteindre avec tes autres capacités qui m'ont l'air bien supérieures?

[Actarus78]

Je bosse dans le secteur automobile, il y a beaucoup d'applications historiques MVS en Cobol, et il y a 2 ans certaines étaient encore en PL1 (fear) avant de migrer en Cobol. Les environnements de développement sont maintenant sous Eclipse, donc c'est infiniment plus confortable qu'un écran 3270.

Bon d'accord, MVS, COBOL, DB2, c'est monolithique et pas sexy pour deux sous, mais c'est costaud, fiable et pérenne. Cela dit, vu le peu de temps que j'ai passé dessus, j'ai rayé ces technos de mon CV, je préfère m'occuper de projets en Linux Java Oracle (avec toutes les merdes qui vont avec ha ha ha)

[Jabba]

Modéré par Fio'

[Caniveau Royal]

Citation :

Publié par Actarus78

Bon d'accord, MVS, COBOL, DB2, c'est monolithique et pas sexy pour deux sous, mais c'est costaud, fiable et pérenne.

C'est bien le contraire.
DB2 est la base de données qui a été la dernière a soutenir SQL, et qui de plus, le soutien mal: IBM a inventé ses propres règles, a tenté de les imposer et a échoué à la Iznogoud.

Cobol, c'est des sources souvent obscurs, mal commentés, où la moindre maintenance corrective ou évolutive se compte en jours ou en dizaines de jours. Tu associes à cela des environnements où la gestion de configuration n'existe pas, où les tests unitaires n'existent pas, où les tests d'intégration intégrant des saisies automatiques de données n'existent pas, où les transactions n'existent pas et tout doit être rétabli à la main, si on y pense seulement...!

Le problème des vieux langages et des vieux OS c'est qu'ils n'ont pas évolué pour suivre l'évolution des techniques de conduite de projet d'aujourd'hui.
L'explication que j'en donne, c'est que IBM a bien veillé à ne rien faire évoluer pour éviter que les développeurs Cobol s'inquiètent de passer d'un IBM 36 à un 38, à un AS/400...
Et ce qui est très sensible chez les programmeurs Cobol, c'est qu'il ne veulent surtout rien apprendre de nouveau. Que le Cobol reste en version 74 et 82 (respectivement 38 et 30 ans d'âge) ne les gêne pas. Ils n'ont pas du tout envie de voir des versions apparaître tous les deux ans comme avec Java, par exemple. Ni de nouvelles API.

Le monde Cobol, c'est d'abord un monde de fossiles. Qui se meut difficilement. Qui réussit peu et très très lentement.

Il suffit de voir à titre d'exemple ceci, que l'on peut observer sur la totalité - ou peu s'en faut - des programmes Cobol existants:
Bien que SQL fonctionne depuis 15 ans (sur IBM), les développeurs Cobol continuent à faire du:
- j'ouvre une fichier/table, je lis en séquence sur une clef,
- je sauve un contenu dans des variables et je fais une boucle,
- j'ouvre un deuxième fichier, je lis sur clef,
- j'ouvre un troisième fichier, je lis sur clef,
au lieu d'utiliser l'unique requête SQL qu'il faudrait pour remplacer du code qui plus il grandit en taille, plus il est propice aux erreurs.

Et ce dont tu t’aperçois vite, c'est que des programmeurs Cobol ne le font pas, parce qu'ils ne connaissent pas SQL, parce qu'ils ont eu la paresse de l'apprendre.

Quand j'écris le développeur Cobol est le niveau zéro dans l'échelle des informaticiens, c'est à cause de tout cela.
Et il le doit autant à IBM qu'à lui-même.

[odyssee]

Dev cobol c'est une niche, il y en a pas beaucoup mais on en a pas beaucoup besoin.

Je trouve ça risqué de miser la dessus, je pense que l'avenir c'est plutôt dans le web 3.0 avec des appli sur serveur web (même si dans les faits c'est le même principe)

[Hourk]

Ayant travaillé 5 ans sur du cobol, je ne pense pas que cela soit une bonne idée de se lancer la dedans. Tout le monde pense que c'est une niche et que les ressources vont valoir chère mais c'est totalement bidon.

Il n'y a rien de plus simple que de faire du développement cobol (au sens strict du terme). Par contre, si tu commence à maitriser les techno qui tournent autour (rexx, assembleur, mvs, db2, cics, pour citer les plus importantes), oui tu deviens une ressource importante mais pour cela, non seulement cela demande du temps (je dirais une dizaine d'année pour commencer à bien tater) mais en plus trouver la boite qui a besoin de cette compétence et ça il y en a pas tellement ...J'ai uniquement une expérience de 5 ans sur un projet national mais les quelques personnes possédant une grande partie des compétences citées précédemment se comptaient sur les doigts de la main pour une population d'environ 300 personnes.

En ce qui concerne la philosophie des entreprises par rapport à ce langage, je tiens juste à signaler que le SI des systèmes de retraite est en cours de refonte depuis environ 2006 et que la technologie retenue est le langage cobol orienté objet (pour faire new technologie), ce qui a amené plus de problèmes qu'autre chose...

Malgré ces détracteurs, le cobol reste le langage privilégié pour le traitement de volume. Actuellement, faisant de la perf sur les SI, je n'ai pas encore eu l'occasion de voir un langage informatique proposant des batchs aussi performant que le cobol...D’où le fait que banque, assurance, and co reste sur le cobol au détriment de leur application TP, car d'un point de vue TP, même si le cobol reste performant, ce n'est pas le langage le plus adéquat pour ce type de traitement...

[Aedymo]

tu es chez Alcara Hourk ? :d

[Hourk]

J'y étais

[16906]

Citation :

Publié par SN-Seign

les tjm sont de 280/350euros par jours...

Juste par curiosité, pour le salarié, il reste combien de ces 280/350 par jour ? Quelle part pour l'employeur ?