[Assurancetourix]

Citation :

Publié par Hourk

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...

Hum, il y a une raison à ces perfs? Par rapport à du C par exemple (ou du C++ sans faire le gorêt dans les création/deletions indirectes d'objets)?

[huhuh]

Citation :

Publié par Hourk

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...

J'ai jamais vu de Cobol ou traité avec des gros SI donc tout ça reste un peu abstrait ; mais pourquoi il n'y aurait pas un coeur du traitement des opérations en Cobol avec une/des couche(s) utilisant d'autres langages faisant appel à ces opérations ? Voire même carrément pourquoi ne pas générer du Cobol à partir d'autre chose, si c'est si chiant à faire ?

[Aedymo]

Citation :

Publié par 16906

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

Si on part sur un 280 euros par jour (ce qui est VRAIMENT super bas).

Un AD Cobol débutant est payé entre 27ke et 29Ke brut annuel. Prenons donc un salaire de 28500 BA.

28500 x 0.77 / 12 = 1830 euros net mensuel.

Hors pour la société un salaire de 28500 représente un coût global de

28500 x 1.81 ( 1.47 de charges et le reste représente l'ensemble des frais administratifs) = 51585.

Lors d'une bonne année nous allons pouvoir facturer les services de cet AD 210 jours.

soit 51585 / 210 = 246 euros.

Donc la société fait une marge unitaire de 280-246 = 34euros par jours soit un taux de marque (ou taux de marge) de 12%

Imaginons que le client demande une seule journée de gratuité, l'entreprise va mettre 246 /34 = 7jours pour ne pas perdre de l'argent...

sur 6mois la société va faire un chiffre d'affaire de 280 x 6 x 20 = 33600 euros pour un bénéfice de (34 x 6 x 20) - 246 (jour de gratuité) = 3834.

Sur la même période le développeur à gagné 1800 x 6 = 10800 euros

[Hourk]

Citation :

Publié par Assurancetourix

Hum, il y a une raison à ces perfs? Par rapport à du C par exemple (ou du C++ sans faire le gorêt dans les création/deletions indirectes d'objets)?

Je serais incapable de te dire pourquoi mais c'est la raison que j’entends régulièrement pour vanter les mérites du cobol. Je n'ai plus les chiffres en têtes mais en cobol, traiter des millions d'enregistrements ne prend que quelques minutes.

Un début d'explication avancée sur developez.com :

Citation :

Ensuite, il faut revenir aux sources COBOL signifie COmmon Business-Oriented Language. Il est orienté business et est principalement utilisé dans les gros traitements de business. Et là, partout le cœur des réflexions est loin d'être technique mais surtout très axé business et donc gros sous. Et même si il pourrait être intéressant (enfin ça reste à démontrer) financièrement sur le long terme de migrer un SI reposant sur COBOL/mainframe vers des langages et systèmes plus récents, personne dans les réels décisionnaires n'osera lancer un tel projet qui aurait un coût immédiat faramineux.

Citation :

Publié par huhuh

J'ai jamais vu de Cobol ou traité avec des gros SI donc tout ça reste un peu abstrait ; mais pourquoi il n'y aurait pas un coeur du traitement des opérations en Cobol avec une/des couche(s) utilisant d'autres langages faisant appel à ces opérations ? Voire même carrément pourquoi ne pas générer du Cobol à partir d'autre chose, si c'est si chiant à faire ?

Le cobol peut très bien communiqué avec d'autres langages (notamment grâce à l'option Langage Environnement) mais comme je l'ai déjà dit, il est intéressant que pour des opérations simples. A en croire l'article (donné en lien en fin de message) 60 à 80% des applications d'entreprises internationales reposent sur du cobol.

Citation :

Le COBOL a de nombreux atouts. Il a été conçu à l’origine pour simplifier la programmation logicielle afin de la rendre accessible à un plus grand nombre de personnes et de l’adapter à des approches orientées métier. Sa syntaxe est proche de celle de la langue anglaise, elle utilise des mots anglais, et le processus d’encodage a été simplifié. […] L’une des principales forces de COBOL est en effet sa capacité à être intégré et interopéré avec les autres langages informatiques, y compris les plus récents : on a eu du COBOL avec les assembleurs mainframe, puis avec du C++ pour les systèmes ouverts et aujourd’hui avec .Net, les JVM et le cloud. Le COBOL tourne aussi sur toutes les machines (mainframes, zOS, micro ordinateurs, terminaux mobiles). Il est compatible avec tous les environnements d’exploitation fixes et mobiles, et supporte tous les types d’architecture, jusqu’au cloud. Les développeurs peuvent donc moderniser des applications COBOL pour les porter dans des environnements comme Azure, .Net comme les intégrer avec les JVM écrites en Java

Source : Développez

[punkoff]

Si tu te lance la dedans, plutot qu'indépendant, j’essaierai de me faire recruter par le milieu bancaire directement.

Salaire plus que correct + packaging super interessant...

Pour ca suffit de rester 3-4 ans dans la SSII affilié directement à la banque (i-bp par exemple) et ça devrait passer si t'es pas une brèle totale.

[Cthulhu]

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.

J'ai du mal à comprendre comment tu peux vouloir devenir développeur, mais encore plus cobol ... à la limite essaye de devenir architecte ou de bosser étroitement avec l'architecte sur tes projets.
Mais si t'as pas développé avant ça va te faire bizarre après X années d'expérience de te manger les specs et les fichiers pourris des MOA qui font nawak, gagnent plus que toi et s'en cognent assez souvent pas mal des détails (qui te font perdre des heures).

[Aedymo]

Citation :

Publié par Cthulhu

J'ai du mal à comprendre comment tu peux vouloir devenir développeur, mais encore plus cobol ... à la limite essaye de devenir architecte ou de bosser étroitement avec l'architecte sur tes projets.
Mais si t'as pas développé avant ça va te faire bizarre après X années d'expérience de te manger les specs et les fichiers pourris des MOA qui font nawak, gagnent plus que toi et s'en cognent assez souvent pas mal des détails (qui te font perdre des heures).

Je veux devenir développeur par reconversion professionnelle, dans le but de passer CDP à moyen terme je ne souhaite pas être dev ad vitam eternam

[Yeuse]

je te rassure de nos jours pour être CDP plus besoin de savoir programmer... Même la revue de code ce ne sera pas ton boulot...

[Aedymo]

pourtant mes clients qui souhaitaient des CDP étaient très regardant vis à vis du coté technique des CDP, sauf biensur sur un cdp moa

[Caniveau Royal]

Oui mais ceux-là qui sont tatillons ne seront jamais content même si tu faisais deux ans de programmation: ils diraient que ça ne suffirait pas. Et les autres s’interrogeraient sur ce choix - quasi suicidaire, à mon sens - de se rétrograder brutalement.

Il n'y a rien, mais alors: rien du tout à obtenir de la connaissance de la programmation Cobol pour une personne qui a déjà un parcours professionnel.
C'est simplement contreproductif. Je l'ai effacé de mon CV, personnellement, pour que l'on ne vienne plus jamais me chercher dessus. Car tout le temps que je pourrais y être affecté serait du temps à rebours, de la dégradation de pratiques et de connaissances. Il y a beaucoup de boulot à faire en Cobol, j'en conviens. Mais si les volontaires manquent, dis-toi bien qu'il y a une raison.

[Yeuse]

chez nous on a même des responsables d'applications qui n'ont jamais vu une ligne de code... dans le quotidien je reconnais que c'est pas cool surtout quand c'est une appli sensible dans tous les sens du terme, mais ça n'effraie pas une partie de nos chefs.

A toi de savoir vendre le fait que pour faire un bon chef de projet il n'y a pas besoin de savoir lire le code

[Aedymo]

Je vous remercie pour tous ces messages, ça me permet de ne pas faire cette erreur, je viens d’être accepté comme dev cobol dans une très grosse SSII française, mais je refuse, je vais essayer de rentrer en tant que cdp junior.

Je suis un bon gestionnaire, du moins je l’espère, et effectivement je pense qu'un bon cdp doit savoir s'appuyer sur ses équipes qui EUX ont l'expertise technique.

[VaN]

Citation :

Publié par SN-Seign

Je suis un bon gestionnaire, du moins je l’espère, et effectivement je pense qu'un bon cdp doit savoir s'appuyer sur ses équipes qui EUX ont l'expertise technique.

En gros tu diriges un truc dont tu n'as aucune connaissance/compréhension, on peut dire ?

Désolé, mais moi ça me hérisse les poils. Je suis actuellement dev php dans une petite SSII, et nos chefs de projet n'ont absolument aucune connaissance technique, et cela se ressent tous les jours, dans leur manière de gérer les projets. Au final, ils font de la relation client, pas de la gestion de projet. Je ne demande evidemment pas à un chef de projet d'avoir fait 10 ans de PHP, ni de faire mon boulot à ma place, mais connaitre les bases et comprendre un minimum ce que fait le mec que tu gères, c'est je trouve un peu obligatoire.

[Aedymo]

Oui c'est exactement ca... non plus sérieusement j'ai quand même de belles bases de prog, méthodologies, outils de tests, etc... Mais je pense que le plus important c'est le management, la planification et la gestion d'un budget. Un cdp doit avant tout assumer ses choix et directions.

Finalement c'est comme le développeur qui veut devenir chef de projet qui ne sait pas gérer un budget, faire de la planification, manager une équipe, faire de la conduite du changement, motiver ses troupes, animer une réunion, négocier avec le client... bref je pense qu'un technicien est AUSSI un mauvais CDP.

[Yeuse]

Citation :

Publié par VaN

En gros tu diriges un truc dont tu n'as aucune connaissance/compréhension, on peut dire ?....

Le langage de développement le cdp s'en moque c'est pas son boulot. Et le cobol c'est ultra basique et ça se lit quasi dans le texte. Au pire se faire expliquer les subtilités pour les ordres un peu technique, mais normalement il n'a même pas à aller voir dans le code

[Bjorn]

Citation :

Publié par VaN

En gros tu diriges un truc dont tu n'as aucune connaissance/compréhension, on peut dire ?

Ce qu'il faut avoir, en tant que CdP, c'est un bagage générique large. Le langage, on s'en fout.
Pour etre CdP sur des projets php par exemple, il faut connaitre ce que c'est que l'orienté objet, avoir des notions d'ergo, d'interrogation de BDD, du fonctionnement d'un serveur web, etc...
Par contre, savoir comment se crée un tableau, osef un peu.

CdP et dev, ce sont deux métiers différents. De manière très malheureuse trop mélangés aujourd'hui. Les dev DOIVENT passer CdP s'ils veulent évoluer, et les CdP, du coup, ont souvent du boulot de dev (chiffrage précis, spécifications détaillées) parce que personne n'est là pour le faire. C'est là que ca blesse, parce qu'effectivement, quand le chiffrage est fait par un CdP qui n'a rien compris à ce qui est demandé, c'est le dev qui galère derrière.
Mais c'est pas la faute du CdP, c'est juste pas son boulot.

[Actarus78]

Citation :

Publié par Bjorn

CdP et dev, ce sont deux métiers différents. De manière très malheureuse trop mélangés aujourd'hui. Les dev DOIVENT passer CdP s'ils veulent évoluer, et les CdP, du coup, ont souvent du boulot de dev (chiffrage précis, spécifications détaillées) parce que personne n'est là pour le faire. C'est là que ca blesse, parce qu'effectivement, quand le chiffrage est fait par un CdP qui n'a rien compris à ce qui est demandé, c'est le dev qui galère derrière.
Mais c'est pas la faute du CdP, c'est juste pas son boulot.

C'est difficile de dégager des règles,il y a tant de projets et de contextes différents, la fonction de PM est tellement générique et peut radicalement changer d'un projet à l'autre. Ce qui change rarement est que la responsabilité du PM est souvent engagé quand le projet se barre en couille,donc c''est toujours mieux que le PM comprenne par lui même voire maîtrise tous les aspects du projet, techniques et organisationnels.
Toutefois, il est existe des projets qui arrivent chez le PM déjà tout chiffré, budgetisé, staffé, spécifié,planifié, jalonné en amont et le rôle du PM est uniquement d'assurer le suivi de l'avancement, ce qui est souvent un casse-tête quand les équipes sont dispersés au 4 coins du globe.

[Hourk]

Citation :

Publié par Actarus78

C'est difficile de dégager des règles,il y a tant de projets et de contextes différents, la fonction de PM est tellement générique et peut radicalement changer d'un projet à l'autre. Ce qui change rarement est que la responsabilité du PM est souvent engagé quand le projet se barre en couille,donc c''est toujours mieux que le PM comprenne par lui même voire maîtrise tous les aspects du projet, techniques et organisationnels.
Toutefois, il est existe des projets qui arrivent chez le PM déjà tout chiffré, budgetisé, staffé, spécifié,planifié, jalonné en amont et le rôle du PM est uniquement d'assurer le suivi de l'avancement, ce qui est souvent un casse-tête quand les équipes sont dispersés au 4 coins du globe.

Je suis d'accord avec toi. Chez Alcara, vu que le nom a été cité, ne vaut mieux pas penser être pris en tant que Cdp Cobol si tu as peu de connaissance cobol. A moins de viser la MOE, mais dans ce cas la ils n'ont pas besoin de toi

Et la MOE connait très peu le cobol. Si tu souhaites un métier bien payé basé sur le cobol, tu dois être dans la technique et connaitre de façon approfondie ce langage et ce qui tourne autour. Si tu souhaites un métier bien payé mais type MOE, MOA, cela ne sert à rien de connaitre le langage. Il faut connaitre la législation tournant autour de ce métier.

Dans tout les cas, tu seras obligé de faire tes preuves.

[Jyharl]

Bah si la MOA t'intéresse, tu pourrais tenter la MGEN en CDP. Ma mère y bosse.

Ils sont pas super techniques là bas anyway et n'ont pas l'air très regardants sur leur recrutement.

Après pour du Cap G (Sogeti, Transiciel, etc) c'est déjà plus compliqué.

J'ai mentionné la MGEN mais question con, tu as tenté la fonction publique ?
Parce que niveau vieillerie là bas...

[odyssee]

De mon expérience je trouve que chef de projet c'est un poste particulièrement difficile et pas très bien rémunéré par rapport aux responsabilités.

Des postes en MOE, MOA, BA, expert technique voir commercial sont plus sympas imho.

[Aedymo]

Mais il existe des chef de projet MOA comme des chefs de projet MOE

[odyssee]

Oui en effet mais le chef de projet MOA c'est un peu une dérive non?

Quand je dis poste MOA c'est ceux qui font l'expression de besoin.

[Bjorn]

Ben là aussi, MOA et MOE les définitions sont multiples en fait.