Pour la même raison qu'un footballeur peut être payé des centaines de fois une infirmière ?Pourquoi les programmeurs sont-ils moins payés que les gestionnaires de programme et les analystes métier ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Pour la même raison qu'un footballeur peut être payé des centaines de fois une infirmière ?Pourquoi les programmeurs sont-ils moins payés que les gestionnaires de programme et les analystes métier ?
Tu as tout à fait raison. En France, et seulement en France, on te met dans des grilles. En fonction de cette grille tu rentre avec tel diplôme et tu vas gagner X et dans 20 ans en fonction de cette même grille tu auras tant. Et quand tu arriveras à 50 ans tu vaux plus rien ! Les entreprises Françaises considèrent que le talent et l'expérience n'existe tous simplement pas quand on parle d'un développeur, seul le fonctionnel compte réellement.Envoyé par moritan
Les anglophones sont moins con car eux ont compris qu'une belle voiture sans un moteur ça sert pas à grand chose !
Ce qui est regrettable c'est qu'en France on décourage ainsi les gens qui seraient intéressés par une carrière au niveau technique. On a ainsi de moins en moins de gens expérimentés et on a un niveau technique qui baisse d'année en année.
La qualité des projets s'en ressent grandement et par voie de conséquence la productivité et la compétitivité des entreprises Françaises. Car les entreprises Françaises ont de moins bon outils que leurs homologues anglophones.
J'ai peut-être une vision fausse, mais en France, on a une espèce de grosse boite développeur, aucune échelle dedans (à par entre les développeurs eux-même).
La pluspart du temps un développeur expérimenté c'est un chef de projet
Donc on se retrouve avec salaire de base = développeur, tu veux plus tu change de métier.
De bons outils, ce sont des outils efficaces, et qui servent réellement. L'utilisateur final, lui il s'en fout que tu ais mis toute ton intelligence pour pondre un algorithme, un code élégant etc..
Lui ce qu'il veut c'est un outil qu'il saura utiliser et lui fera gagner quelque chose ( temps, productivité..etc).
Faut pas oublier que l'informatique est un outil. La technique au service de la technique ne sert à rien. Alors que celui qui saura faire le pont entre le technicien et le client avec ses exigences métiers, est bien plus utile (et donc forcement plus valorisé).
Un exemple, dans un projet ERP, un consultant métier, qui a à la fois beaucoup d'expérience en gestion de stocks et qui saura modéliser exactement les bonnes règles métiers en un langage compréhensible pour le codeur, qui lui devra pondre un nouveau module, est la personne qui fera que ton nouveau module soit: -utilisé (oui lorsqu'un outil informatique te fait perdre plus de temps que ton crayon papier, ou te fait désorganiser ta chaine logistique, ca arrive plus qu'on ne le croit)
- te fait gagner une valeur ajouté (temps, productivité, centralisation de l'information, reporting..etc).
-que les règles métiers soient en cohérence avec les autres processus de l'entreprises.
Tout cela demande plus de polyvalence, et plus de compétences. C'est à dire comprendre à la fois, ton client, mais aussi la technique sous-jacente, à son souhait, pour que ton développeur puisse faire son travail.
D'ailleurs les bons consultants métiers, sont généralement diplômés en informatique appliquées à la gestion. Et leur bagage théorique à la fin de leur cursus est bien plus polyvalent que celui du developpeur.
Tout à fait d'accord avec ceci
(à la nuance près exprimée ailleurs que je doute de la "MOA" en tant que telle, qui est elle-même une spécialité très française)
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
oui mais
Dans l'informatique de gestion (80% des offres), c'est exact
Dans l'informatique embarqué/industriel : non puisque la performance et la maintenance redeviennent critique.
Dans la TMA au forfait : non (même s'il y a des difficulté à l'admettre) puisque les contrat sont sur plusieurs années et que les "raccords" mal ficelé de l'incident X du mois de janvier te reviennent en boomerang 6 mois après MAIS ton crédit jour lui ne bouge pas.
Pour un éditeur/fournisseur de service : c'est leur coeur de métier ... il faut que le produit ait des fonctionnalités attractives (voir même utile) mais il est nécessaire qu'il soit aussi robuste ... donc en général ils sont mieux considérés.
A+
Perso suis loin d’être intelligent: quand il s'agit d’écrire des algo optimal de tri ou recherche (les arbres par exemple ^^) ou réfléchir sur des solution complexes, c'est pas trop ma tasse de thé.Les développeurs bien qu’étant des personnes assez intelligentes
Bref, suis juste un passionné, professionnel tout de même, et qui aime l'informatique et toutes les nouvelles technologies de développement surtout mobile en ce moment, déçoit rarement le client, sauf retards de livraison
Après j'en voit qui sont très intelligent mais qui ne savent pas coder proprement et utiliser un outils efficacement, pire, quand on leur demande de créer des applications assez riches, il y arrivent pas parce que eux, sont très doué pour taper des algos assez bien compliqués, afficher pleins de résultats style debug dans la console... mais, pas concevoir un produit fini et fonctionnel au clientconstat dans ma promo, simple constat
Bon ca ma suciter une tel remarque en lisant cette phrase, je retourne glander va
Cette discussion peut se généraliser un peu partout :
- est-ce qu'il faut un architecte pour monter une maison ou seuls un ou deux maçons suffisent ?
- est-ce qu'il faut un architecte pour faire une voiture ou seuls un ou deux assembleurs suffisent ?
Etc.
La question de fond ressemble vraiment à : quand on construit une maison, les architectes sont bien mieux payés que les maçons, pourtant, il y a pas mal de maçons qui font bien leur métier et ont même souvent plus de connaissances que les architectes. Ces gens là, qui sont payés comme des maçons "classiques", ne devraient-ils pas être payés au moins à la hauteur des architectes, qui, eux, finalement, ne mettent jamais les mains dans le cambouis ?
Personnellement je répondrai que "oui".
.I..
Moi je n'arrive pas à me faire embaucher alors je ne demande pas trop un salaire elevé.
en France il vaut mieux un beau costard ou un diplome qui t'a couté cher que d'avoir du bon sens...
Bien (se) presenter est aussi important que les competences (sauf niveau exceptionnel, et encore), de meme que de ne pas demander un salaire extravagant par rapport a ses qualifications.
L'embauche, c'est un tout : il ne suffit pas de remplir une condition pour etre embauche.
Sans fonctionnel inutile, plus de projet partant en vrille à rattraper donc plus de développeur senior free-lance qui en vit plutôt bien
Tout cela demande plus de polyvalence, et plus de compétences. C'est à dire comprendre à la fois, ton client, mais aussi la technique sous-jacente, à son souhait, pour que ton développeur puisse faire son travail.
D'ailleurs les bons consultants métiers, sont généralement diplômés en informatique appliquées à la gestion. Et leur bagage théorique à la fin de leur cursus est bien plus polyvalent que celui du developpeur.
Je bondis quand j'entends cela! C'est n'importe quoi, il faut "surtout" ne rien comprendre pour pondre ce genre d'analyse.
Un consultant, ou toute entité managériale n'est rien sans le produit. Si le produit n'existe pas, on peut certes le vendre mais il faut le coder ensuite et faute de "technicien" on a vendu du vent.
Le consultant métier sait de moins en moins de quoi est capable une technologie, se contentant de faire confiance à 2 lignes en gras dans un magazine où tel framework vend la lune et tel autre les étoiles.
Excusez du peu, mais si coder une application revient - selon les paroles même d'un polytechnicien peu ragoutant - à "pisser du code", alors oui, le consultant est sans doute celui qui prend le plus de risque dans l'affaire et mérite certainement son salaire et les coups de batons qui suivront.
Malheureusement pour ces consultants, et le cas du dvt des ERP en est un très bon exemple, les développeurs sont de plus en plus polyvalents, à même de critiquer, évaluer, développer les solutions eux-même et se passant parfaitement des quelques "globalités" qu'un manager non avancé lui prodiguera. On n'ajoute pas une fonction dans un ERP sans en connaître la logique métier et donc sans connaitre ce à quoi la fonction est destinée.
Allez dire aux concepteurs d'ERP que leur collègue présent depuis 10 ans dans la boite et responsable exclusif - par économie sans doute - de X modules s'en va ... qui va le remplacer sans devoir se taper la lecture du code à l'heure où les managers ne veulent pas entendre parler de surcout pour cause de mise à jour de la doc technique?
Analyse {fonctionnelle, d'impact}, design, estimation de cout, division du travail, code, tests {unitaires, de régression, d'intégration}, documentation, intégration, analyse des états des {bases, logs, mémoire système, connexions réseaux, profils de synchro, etc ...} => sans compter l'aspect "modulable" et "réutilisable" des solutions.
-> on veut encore parler de la polyvalence ?
à bon entendeur...
Sauf qu'un maçon ne fait pas les mêmes études qu'un architecte.La question de fond ressemble vraiment à : quand on construit une maison, les architectes sont bien mieux payés que les maçons, pourtant, il y a pas mal de maçons qui font bien leur métier et ont même souvent plus de connaissances que les architectes. Ces gens là, qui sont payés comme des maçons "classiques", ne devraient-ils pas être payés au moins à la hauteur des architectes, qui, eux, finalement, ne mettent jamais les mains dans le cambouis ?
Pour coder, il faut apprendre le métier d'informaticien.
Pour faire fonctionnel, être ingenieur voir avoir de l'experience dans le domaine suffit. Bref, un développeur avec un peu d'experience peut très bien remplacer l'expert fonctionnel, s'il en a envie.
En voulant reprendre ta caricature, le PB de l'informatique, c est qu'actuellement on demande au maçon de construire les plans et à l'architecte d'empiler les blocks (et corriger les plans pour que la construction ressemblement à ce qui a été vendu au client).
Ben voyons..
C'est peut-être pour ça que les ingénieurs Arts et Métiers sont si cotés
Moi Super-Programmeur peut faire n'importe quel boulot, car Moi Seul ait eu besoin de faire des études
Te rends-tu compte de ce que tu dis ????
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Je pense qu'il parle des MOA, alors que toi tu parles des utilisateurs finaux. Pour les MOA il a souvent raison(sauf que ce n'est pas le niveau d'études qui fait le programmeur, mais passons). Les vrais gens du métier, eux, ont souvent des années de bouteille et/ou d'études pour arriver à une compréhension correcte de leur domaine.Ben voyons..
C'est peut-être pour ça que les ingénieurs Arts et Métiers sont si cotés
Moi Super-Programmeur peut faire n'importe quel boulot, car Moi Seul ait eu besoin de faire des études
Te rends-tu compte de ce que tu dis ????
Les agents back-office avec qui j'ai bossé par le passé n'avait d'ailleurs en général pas plus que le bac(quand ils l'avaient). Mais ils avaient quasiment tous plus de 30 ans de maison, et il était hors de question de leur apprendre leur boulot. La MOA, elle, soit a elle aussi 30 ans de maison(et tout se passe bien), soit vient du coté programmation(ce que les devs apprécient, mais ça pose des problèmes culturels de l'autre coté), soit sort d'école de commerce, et c'est, hum, aléatoire.
Ce qui pose problème, aussi, c'est quand la MOA se permet de définir des éléments techniques (exemple vécu récemment, et qui a posé plein de problèmes : voici les données que va recevoir votre batch, et voici les formats de fichiers. Ma réponse : euh, c'est pas possible, il faut un format de données unique, en plus c'est plus facile aussi pour vous, sinon on va quadrupler les couts de maintenance. Leur réponse : ta gueule, sombre vermisseau, tu n'as pas droit à la parole. Conclusion de ma hiérarchie : arrête d'embeter la MOA, s'il te plait). Leur métier, à mon sens, est de nous dire le quoi(ici, nous allons recevoir des éléments marketing, et devons en faire quelque chose d'utilisable, selon des règles définies par leurs soins). Le notre, c'est de définir le comment.
Quand tu parlais de polyvalence, mon problème ici est que la MOA se croit polyvalente. Elle prétend comprendre l'essentiel du métier des markéteurs(c'est possible, mais je ne suis pas en mesure de le vérifier). Elle prétend savoir homologuer nos traitements(c'est faux, j'ai été homologateur, je n'étais pas forcément le meilleur, mais ils ne m'arrivent pas à la cheville). Elle prétend dicter nos choix techniques, et c'est une catastrophe. Elle est payée beaucoup plus que nous, et a tous les droits.
A ce titre, j'ai de la sympathie pour le message de TP1024 : si il a rencontré le même genre de zigotos que moi, il peut avoir un sentiment légèrement négatif vis-à-vis de ce genre d'imposteurs. Même si il faut savoir rester à sa place, et ne pas inventer les besoins du client parceque c'est plus facile à coder(erreur qu'il m'est arrivé de commettre, je l'avoue).
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
ce qui confrme ce que je disais dans les autres threads : la MOA ou AMOA est non seulement une inventon et spécificité française, mais une aberration.. et due en grande partie à l'influence gigantesque des banques et assurances/mutuelles sur le dev informatique en France..
"Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".
Consultant indépendant.
Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
C, Fortran, XWindow/Motif, Java
Je ne réponds pas aux MP techniques
Pas seulement. La mainmise des SSII sur le marché y est aussi pour beaucoup, je crois. Elle-même liée à l'extrême rigidité du marché du travail. Il est quasiment impossible pour une banque de dégraisser, dans ce pays, donc pour tous les travaux en démarche "projet", on externalise. Ca coute plus cher, mais on s'en fout : le jour ou on veut sortir 800 prestataires parceque c'est la crise, on sort 800 prestataires(et on les reprend dans la foulée parcequ'on ne peut pas tourner sans eux).
Seulement, comme on a plus les compétences en interne, de gens à la fois "métier" et capables de parler avec les informaticiens, on recrute des MOA(en interne ou en SSII). Parfois, on tombe sur des gens acceptables, voire excellents. Mais, globalement, je suis d'accord avec toi : cette fonction a bouffé plein de choses. L'homologation(qui n'a rien à voir), souvent, est la première cannibalisée. L'urbanisme, l'architecture technique, le sont parfois aussi. (outre mon exemple de format de fichier, j'ai vu un exemple de choix de machine "parceque le développement est moins cher" sur MVS, mais avec des couts cachés prohibitifs, parceque les transferts MVS-UNIX, c'est toujours compliqué).
Etre plus facilement virable, je prends. C'est la mort des SSII. Et la mort lente des MOA.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Votre exemple est juste biaisé.
Un developpeur qui à des années d'expériences aura plus que des notions de code.
Il aura aussi acquis une culture fonctionnelle et il pourra sans problème prendre la place d'un consultant au niveau de la traduction des règles MOA vers une découpage MOE.
C'est sur que si vous prennez comme exemple un centre de developement en offshore on ne va pas aller bien loin...
Bref ce sont deux métiers différents mais dans les deux cas c'est simplement une traduction :
- pour le 1er : langage MOA vers MOE
- pour le 2eme : MOE vers code
Je ne vois pas bien quelle personne à plus de valeur ajouté dans ce cas de figure.
Excuse moi, mais je ne vois pas la chose de la même manière :
En voulant reprendre ma caricature, le problème de l'informatique, c'est qu'actuellement on se demande comment il est possible qu'un bon maçon qui a de l'expérience puisse construire lui même tout seul ses maisons en se passant d'un ingénieur, et qu'à l'inverse, les architectes, effectivement, pètent un câble, parce qu'après avoir grossièrement (et en informatique le terme est faible) dessiné une caricature de maison au fusain sur une planche de bois et avoir été payé des dizaines de milliers d'euros, ils ne comprennent pas (et en informatique le terme est une réalité concrète sur le terrain) que le maçon, qui en a ras la casquette d'être payé au RMI à travailler 12 heures par jour pour cet architecte, se barre en plein milieu du chantier.
Dans ce genre de cadre qui, ramené à l'informatique, n'est presque pas de la caricature, l'architecte qui ne comprend rien parce qu'il est tout simplement incompétent techniquement (et le terme est faible), essaie systématiquement de tout ramener à la faute du maçon, et va vite en chercher un autre qui acceptera, comme le précédent, le cinéma "RMI à travailler 12 heures par jour".
Et dans tous ça le client voit quoi ? Bah c'est simple : il ne discute qu'avec les architectes. Donc inévitablement, le client croit l'architecte lorsque ce dernier lui dit que les maçons sont des incompétents, voire de crétins, qu'ils ne comprennent rien à leurs directives, et qu'à l'inverse, les architectes des demi-dieux qui pensent toujours à tout.
Donc je comprends parfaitement le ras-le bol des maçons compétents.
Et j'insiste sur ce dernier mot, parce que lorsqu'ils ne le sont pas, effectivement, tu as raison.
Petit HS : vas demander à la plupart des manuels qui font du béton ciré pour les grosses boites, ce qu'ils pensent des architectes, et tu verras que finalement, cette caricature n'est pas si éloignée de la réalité que ça...
.I..
Je rejoins l'avis de punkoff.
Un dev sur une plateforme ERP va nécessairement accumuler de la connaissance fonctionnelle avec les années et pourra, à terme, prendre son propre envol sur certaines définitions des besoins métier.
Après tout, une des caractéristiques du métier de développeur (en Gal), c'est de chercher à assouvir régulièrement son besoin de connaissance.
Définir des règles métier, ça va bien pendant un temps: penser test et qualité, évolutivité, coût de réa et centralisation des outils/données (ou pas), ça demande un certain recul technique, que n'ont pas forcément les gens qui se cantonnent au spec métiers.
Actuellement, on parle de déporter du besoin IT vers le "Cloud" et on voit certains consultants métiers/gestionnaires de projet/comme on veut les appeler, se manger méchamment avec leur définition de besoin. Inutile ici, d'évoquer les effets de tels choix de solutions, si elles ne sont pas envisagées côté technique très rapidement et certainement, avant toute mise en œuvre. Ce n'est qu'un exemple...
A mon sens, plus tu évolues dans ta carrière de développeur, plus tu prends du bagage de tous les côtés et plus tu amènes de valeur à ta fonction. A la base, difficile de dire qui doit être payer plus que l'autre, mais assez vite, c'est le développeur qui va bouffer le gars métier, en terme de compétence.
Enfin ici, je pense, comme vous autres, que c'est un problème franco-français, qui tiens plus à la manière de segmenter les fonctions. ça n'est pas réservé au dev info d'ailleurs. Je dirais plutôt que ça tient à la manière dont on considère les gens dans leur travail, par chez nous.
Ca dépend des programmeurs
Il y a un grand écart entre un programmeur qui fait juste de l'assemblage dans une SSII ou chez un Grand Compte et un programmeur chez Apple ou Google ou des startups qui font des produits grands publics.
Il y a aussi un grand écart entre un jeune diplômé qui est nommé chef de projet sans aucune réelle expérience ou une personne mono-projet mono-domaine mono techno et une autre qui a fait des dizaines et des dizaines de projet sur x projets, domaines, technos.
Il y a donc des programmeurs des vrais qui seront mieux payés que des chefs de projet débutants mais la plupart ne sont que des assembleurs non parce qu'ils ne sont pas capables d'en faire plus mais parce qu'avec les frameworks d'aujourd'hui on ne leur en demande finalement pas plus.
J'ai connu une époque ou un centralien devenait et restait programmeur toute sa vie. A l'époque ce n'était pas que de l'assemblage sans doute.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager