IdentifiantMot de passe
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 !

Pourquoi les programmeurs sont-ils moins payés
Que les gestionnaires de programmes ? Manque-t-ils de pouvoir de négociation

Le , par Hinault Romaric
107 commentaires

219PARTAGES

7  0 
Dans le cycle de développement d’une application, le programmeur a principalement pour fonction l’écriture du code.

Ce spécialiste donc des langages de programmation bien qu’effectuant un travail qui nécessite une certaine passion et beaucoup d’engagement, est généralement moins payé que les autres métiers du domaine.

Dans plusieurs entreprises, les gestionnaires de programme et les analystes métier par exemple perçoivent une rémunération qui est bien supérieure à celle du développeur.

Un développeur se faisant appeler Dodgy Coder dans un billet de blog se demande : « Étant donné le fait que la programmation est généralement plus difficile, pourquoi les analystes métier et les gestionnaires de programme ont un salaire plus élevé que les programmeurs ? Qu’est-ce qui rend leur travail mieux rémunéré tandis que la plupart du temps, les programmeurs sont ceux qui rentrent tard chez eux ? »

Les gestionnaires de programme (PM) /analystes métier (BA) ont-ils plus de valeur pour l’entreprise, ou ont-ils un pouvoir de négociation accentué ?

Pour Dodgy Coder, le second choix explique le mieux cette différence de salaire. Les PM/BA disposent de bonnes aptitudes en relations humaines (qualité assez rare fournissant un avantage énorme dans n’importe quel emploi). Il est difficile d’externaliser ceux-ci, car ils sont amenés à rencontrer les clients. La rareté relative des gestionnaires de programme/analystes métier leur donne plus de force de négociation.

Les développeurs bien qu’étant des personnes assez intelligentes, manquent-ils de pouvoir de négociation ? Selon vous qu’est-ce qui peut justifier cette différence entre le programmeur et le gestionnaire de programme ou l’analyste métier ?

Source : Blog Dodgy Coder

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

107 commentaires
Commenter Signaler un problème
moritan
Avatar de moritan
Membre expert https://www.developpez.com
Le 14/03/2012 à 16:11
En France la grille sallariale est souvent calquée sur l'organigramme de la boite.
Et malheureusement pour les développeurs, ils se trouvent tout ne bas de cette pyramides...

De plus, même si ça commence à changer, le métier de développeur est très mal vu.
La pluspart du temps, ce n'est vu que comme une transition vers 'un vrai métier' qui lui sera correctement payé.

Le jour ou un développeur avec de l'expérience sera vu comme un atout et non pas comme un boulet qui coute cher, on pourra espérer être mieux payer.
23  0 
GeoTrouvePas
Avatar de GeoTrouvePas
Membre éprouvé https://www.developpez.com
Le 14/03/2012 à 17:48
Mon cas personnel ne reflète pas vraiment le sujet puisque je ne suis pas chez un éditeur ou une SSII. Je fais du développement pour une entreprise publique et je me rends compte que, si c'est mal payé, c'est essentiellement par méconnaissance de ce travail. Les "non informaticiens" (pour utiliser un terme assez large) n'ont pas conscience de la complexité, de l'investissement, de l'engagement et de l'intelligence qu'il faut pour arriver à pondre un code béton.

Grosso modo, dans ma boite, ce qu'on me rétorque 9 / 10 quand manifeste mon mécontentement c'est : "Ouais mais pour vous c'est facile de faire, vous êtes dedans depuis que vous êtes tout petit"...

C'est une caricature mais ça montre bien à quel point les gens n'ont pas conscience de la complexité de ce métier et des aptitudes nécessaire pour le faire correctement.
16  0 
bugsan
Avatar de bugsan
Membre confirmé https://www.developpez.com
Le 15/03/2012 à 23:20
L'expérience professionnelle n'est pas toujours un avantage. En fait, tout dépend la boite dans laquelle on a évolué. Certaines sociétés françaises glorifient les mauvaises pratiques, et sont remplies de gens qui ont "mal appris" la programmation et la conception. Tout débutant entrant la dedans en ressort totalement dislexique. On y apprend "mal" sur le tas ...

Sans vouloir paraphraser Martin Fowler, il y a une organisation du travail inadaptée dans la production de logiciel. On a imaginé qu'il existait une phase de réalisation distincte de la conception. C'est un peu comme si on avait voulu séparer l'écrivain de la capacité à formuler la pensée avec des mots et avec une syntaxe française plus ou moins correcte.

En fait au lieu de diviser le travail selon le savoir faire et les compétences, comme on le ferait dans tout autre domaine, on divise le travail selon un ordre chronologique supposé de création. Les décisions ayant le plus d'impacts étant prise au début, elles restent dans les mains de ceux qui sont le moins qualifiés. D'où le taux d'échec important des projets ...

Après que tous les MOA et fonctionnels aient brassés du vent pendant des mois, le vrai travail de conception peut enfin commencer, sous Eclipse.
Et sinon oui, c'est essentiellement un problème franco-français. Mais je ne me fais pas trop de soucis je sais que tout cela changera un jour car la méthode la plus efficace gagne toujours sur le long terme.
11  0 
transgohan
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 14/03/2012 à 16:17
Je rejoins l'avis de moritan, on compare souvent les développeurs à tout autre technicien ou ouvrier de bas niveau (cherchez pas le niveua moyen ou haut, j'utilise juste ce terme pour "hyperboler" le fait qu'on nous situe en bas de l'échelle).
Le développeur c'est celui qui va charger la brouette de terre et mettre en place les boulons.
Donc si on le payait plus, il faudrait payer plus tous les ouvriers non ?
9  0 
skywaukers
Avatar de skywaukers
Membre émérite https://www.developpez.com
Le 14/03/2012 à 16:38
Pour moi c'est essentiellement la délocalisation vers les pays emergeant qui a donné une image du programmeur comme l'ouvrier de l'informatique. On l'a carricaturé comme "pisseur de code", d'ailleurs en grande partie par ces gestionnaires de programmes qui se ont vendu l'éconnomie (toute relative) du coût du programmeur pour négocier leur salaire.
Mais ceci n'est pas un phénomène propre à l'informatique. Comme le dit ce programmeur, les PM/BA ont un côté relationnel plus développé que le programmeur, et dans la vie ce n'est pas le plus intélligent qui sort le mieux son aiguille du jeu, c'est celui qui sait le mieux se vendre (souvent au détriment des autres).

@++
Dany
10  1 
el_slapper
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 15/03/2012 à 14:18
Je ne sais pas si mon profil est courant(en tous cas, sur MVS/cobol, en Ile-de-France, il ne reste plus que des gens comme moi, il en reste d'ailleurs un paquet, et le "montage simple" est l'exception qui confirme la règle). En théorie, pas forcément, mais dans les faits, presque toujours.

Je dirais qu'il y a 3 niveaux d'initiative :

1)l'opérateur qualifié(ah, le cable à cassé, voyons ce que dit le petit manuel pour remettre le cable dans la machine).

2)le technicien(ah, le plan du paquebot indique qu'il faut mettre un tube droit ici, or manifestement il faut le courber, je connais mon boulot, je vais le courber, et le refroidissement du paquebot sera correctement distribué(exemple lu dans courrier international il y a quelques mois, d'un syndicaliste italien qui se vantait de connaitre son boulot)).

3)L'ingénieur(ah, en surveillant les niveaux de productivité des machines, je constate qu'il y a 10% des seaux injectés par la presse numéro 17 qui finissent au rebut, je met en place une surveillance de la presse, je trouve le défaut de conception du robot de récupération, et j'en conçois un nouveau. Mon patron ne sait même pas qu'il y a eu un problème sur la presse numéro 17 - il sait juste que j'ai installé un nouveau robot).

En théorie, un BAC+2 est au niveau 2, un BAC+5 est au niveau 3. La clownerie commence quand on met en place un waterfall, avec donc des gens dont on attend une réactivité de niveau 1, mais qu'on veut des BAC+5. Donc, soit on jette l'argent par les fenêtres, soit, et c'est plus probable, on se doute inconsciemment que ce n'est pas du vrai niveau 1. Mais on fait comme si, parceque c'est ce qu'on a appris en école de commerce, et puis tous ces techos, ce ne sont que des inférieurs, tout juste bon à suivre à la lettre les consignes qu'on leur donne. Et qui, même bac+5, sont quand même des imbéciles infoutus de lire dans nos pensées. Mais on va prendre des BAC+5 parceque c'est le standard - il leur faut bien 5 ans pour apprendre les 3 mots de la syntaxe de leur langage de dégénérés.....

Je m'énèrve, je sais. Simplement, il y a toujours des trous grands comme la raquette dans les specs(dans mon premier cas, peu, la plupart du temps, plein), et c'est toujours au programmeur de rattraper le coup. Et c'est pour ça qu'il faut des gens de niveau 3, dans la plupart des cas(j'ai vu des bac-2 de niveau 3, d'ailleurs).

Et c'est là qu'arrive la question : si on a besoin de gens de haut niveau, pourquoi ne pas se servir tout le temps de leurs capacités, et pas seulement quand tout se casse la figure? Pour justifier leur paye basse?
9  0 
egautier
Avatar de egautier
Membre régulier https://www.developpez.com
Le 20/03/2012 à 17:34
Citation Envoyé par Dhafer1 Voir le message
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é).
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+
9  0 
SurferIX
Avatar de SurferIX
Membre chevronné https://www.developpez.com
Le 28/03/2012 à 17:00
Citation Envoyé par tp1024 Voir le message
Sauf qu'un maçon ne fait pas les mêmes études qu'un architecte.
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).
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...
9  0 
zelegolas2
Avatar de zelegolas2
Membre habitué https://www.developpez.com
Le 14/03/2012 à 18:54
Citation Envoyé par osouleymane
A mon avis la situation peut être analysée sous deux angles différents.
1. Angle économique :
Comme toute activité économique soumise à une rude concurrence, le développement est naturellement gagné par la délocalisation. Le monde n'a jamais été aussi cohérent. Le coding est l'une des activité humaine qui est sans frontière, ouverte, accessible à tous. Imaginez un temps peu soit-il la dynamique au niveau des pays comme l'Inde. Ce pays a la capacité de mobiliser 1 million de codeurs et à des tarifs défiants toute concurrence pour une qualité standard. Pour 1 codeur en France, vous en aurez 10 en Inde.
C'est vrai ce que tu dis. Par contre quand pour un codeur en Inde t'es obligé d'avoir un gas à plein temps dans la boite pour le surveiller, sinon il fait n'importe quoi, tu fais plus d'économie du tout ! (Vécu dans une grosse boites !!!). On oublie de parler aussi de la différence de mentalité : Quand tu es face à un pb et que tu es obligé de jouer à cache cache avec ton Indou par ce qu'il a fait une connerie et qu'il essaye de te la cacher là aussi c'est galère (encore du vécu). Et il faut arrêter de croire que plus tu met de monde sur quelque chose plus ça ira vite ! Ça devient juste plus le bordel à gérer et tu as intérêt à mettre en place un contrôle qualité sinon tu as des surprises !!! Voire même dès fois on est obligé d'envoyer un gas en Inde pour éviter les dérives de l'équipe là-bas. J'ai travaillé avec un collègue à qui c'est arrivé, il a pas rigolé. Il faut plus lui parler des programmeurs en Inde !!! Si on fait vraiment les comptes je suis certain que l'entreprise est loin d'être gagnante !!!
Citation Envoyé par osouleymane
2. la seconde raison à mon avis est une question d'attitude. Le bon codeur, peut être qualifié selon moi d'artiste, dans son ensemble. L'artiste est le plus mal payé. l'histoire de l’Homme l'a prouvé. Pour vivre votre passion de codeur, vous êtes obligé de faire une croix sur la monnaie.

La solution : continuer à coder, car un jour...
8  0 
el_slapper
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 15/03/2012 à 11:13
Citation Envoyé par souviron34 Voir le message
(.../...)Dans les cycles traditionnels, en V ou Waterfall, le programmeur est le bas de l'échelle, il est l'ouvrier à la chaîne, puisque ces modèles ont voulu copier une chaîne de montage.
(.../...)
Mais justement, même en Waterfall, l'activité réelle n'est presque jamais du montage(j'ai fait du vrai montage dans un atelier d'aviation, je sais ce que c'est dans la vraie industrie).

"presque" parceque j'ai vu un client CMMI qui spécifiait chaque poil de cul qu'il voulait faire, chaque assignation de donnée, chaque message d'erreur, chaque détail de chaque algorithme. Evidemment, ça leur coutait un pognon absolument monstrueux, mais au moins, ils n'avait pas besoin de programmeurs intelligents. Sauf le jour ou ils ont oublié un programme, et ils m'ont demandé de trouver une solution pour faire en 2 jours ce qui nécéssitait 10 jours de charge(ils n'ont pas été demeurés au point de mettre 5 gugusses dessus). J'ai trouvé, mais pour le coup, c'est moi qui ai monté une chaine d'assemblage pour que toutes les "traductions" passent par le même code générique, et non pas, comme ils avaient pensé, faire un bout de code différent par "traduction".

Mais, en général, mon boulot, c'est "1_tiens, démerde-toi pour regrouper les clients
2_T'est vraiment con, il fallait prioriser les pros, tu sais même pas ça?
3_T'est carrément en retard, et tout est faux!!!"

Tout ça pour se terminer par la MOA qui se rend compte que son algorithme pour tester les regroupements est faux, qu'elle me demande mon algo(qui lui a fini par être juste, une fois que je leur ai arraché la vraie règle des regroupements), et qui au lieu de s'excuser elle m'a accusé de ne pas maintenir les spécifications techniques à jour.

Dans ces circonstances, l'aspect "chaine de montage" est une vaste blague. Une gamme de fabrication en usine, ça ressemble à ce que j'ai décrit au début(ça peut aller jusqu'à), et quand il y a un cheveu, on ne demande pas à l'opérateur de bosser 80 heures en deux jours.....

Donc, nous sommes des ingénieurs de R&D, on nous demande d'être des ingénieurs de production, et on nous traite comme des opérateurs.
8  0 
Commenter Signaler un problème