Topic des salaires et des carrières : Les SouSous dans la popoche

[davyyy86]

selon vous qui est le mieux payé un développeur ou un chef de projet ?

[vv221]

selon vous qui est le mieux payé un développeur ou un chef de projet ?

En France, un chef de projet. Un chef de projet débutant a même de bonnes chances dʼêtre mieux payé quʼun développeur expérimenté.
Cʼest très con, mais cʼest comme ça.

[Anonyme20240202]

Extrêmement con et dans la plupart des autres pays s'pas vraiment le cas (ou alors le chef de projet est justement un mec très solide qui pourrait être lead dev s'il le voulait, donc c'est normal)

[Neo_13]

Ca va beaucoup dépendre du niveau de rareté de la compétence spécifique du CP ou de la compétence spécifique du dev senior (et l'apport de sa seniorité sur la performance globale).

Ca vaut pour tous les jobs, de fait. En temps que CP et manager, il est déjà arrivé que je sois le moins bien payé de mon équipe (jusqu'à ce que j'embauche du JD, après l'amorçage, ce qui indique un apport de plus des seniors : former les armées de JD).

En clair, on retombe sur la question que j'ai déjà posé dans ce fil : qu'est-ce-que le senior fait mieux que le junior et ça rapporte combien de plus ? Si un senior va 2x plus vite pour produire le code fonctionnel et sans erreur que le junior, c'est normal qu'il soit significativement mieux payé. Si l'écart est de 10%, faut voir les autres apports (gain en maturité, si ça se trouve, les juniors vont plus vite que la normal grace à l'aura +10 du senior,... formation, ...) mais c'est moins clair.

[ook4mi]

selon vous qui est le mieux payé un développeur ou un chef de projet ?

C'est quoi l'objectif de cette question ?

[William Vaurien]

Un autre avantage du senior c'est la stabilité... ça à l'air con comme ça mais généralement le senior (pas le mec de 30 ans avec 5 ans d'XP) est posé: souvent une famille, des enfants, un crédit immo.
Donc il n'a pas envie ni de changer de crémerie tout les 6 mois ni de "perdre son temps" à explorer des trucs. Ca va se traduire pas quelqu'un efficace dans ce qu'il fait, qui va peut être prendre son temps pour mettre en place quelque chose, parce qu'il sera sûrement aussi celui qui devra en faire la maintenance. Un JD va vouloir essayer la dernière techno à la mode et risque de ne plus être là 6 mois plus tard quand il faudra recoller les morceaux..
Si tu n'as que des "seniors" ça risque de pantoufler un peu (aucune prise de risque, pas de remise en question) su tu prends que des juniors ça risque d'aller droit dans le mur...

Après pour les chefs de projets je dirais qu'en théorie il devrait être mieux payé car ils sont responsables (ou devraient l'être): responsable des choix techniques, responsable de la qualité du livrable, responsable de l'adéquation de la solution avec les besoins, responsable de protéger son équipe des aléas politiques extérieurs, ... Après la différence devrait être minime et surtout que les 'pistes' de salaire soient au niveau de la compétence. En gros dans certains pays tu peux suivre une carrière technique et avoir un bon salaire si tu es bon dans ta branche.

En France, dans le dev informatique, c'est un peu trop souvent: "dev junior" < "dev senior (loser)" < "chef de projet junior" < "chef de projet" avec en plus le côté "si t'es dev a +35 ans t'es un gros loser".
Avec peu de valorisation de l'expertise technique et mise sur piédestal des chefs de projet, même quand ceux-ci sont nuls et qu'ils sont plus un fardeau pour l'équipe...

Par le prisme de mon expérience, je trouve que la plus grande imposture ce sont les 'Business Analystes', eux aussi mieux payé que les dev et que j'ai souvent trouvé arrogants et incompétents... Ils devraient être l'interface entre le métier et les devs, mais bien souvent ne comprennent absolument rien à la technique tout en étant assez souvent médiocre sur l'analyse fonctionnelle. Quand j'ai commencé sur mes premier gros projets à bosser avec des BA, j'étais content et soulagé: je pouvais me focaliser sur la technique.
Mais en fait non, j'ai plus eu de bâton dans les roues qu'autre chose et au final je suis content de retrouver des projets sans BA avec l'équipe de dev qui fait son analyse en direct avec le client.
J'imagine que c'est comme les chefs de projet et les chasseurs... Il y a les bons, et les mauvais...

Après c'est du ressenti et ça reste lié au tout petit périmètre de mon expérience pro.

[Anonyme20240202]

J'ai exactement le même ressenti (pour la France)

[ook4mi]

J'ai été BA pendant plusieurs années et no idea si j'étais un bon ou un mauvais mais j'en ai croisé plusieurs et souvent j'aimais pas comment ils bossaient : tordre le métier car il faut pas travailler comme ça + taper sur les devs car la spec est claire c'est toi qui comprends pas, le top du top étant le "non non non me montre pas le code, je suis pas dev".

Perso, je n'étais presque jamais à mon bureau : je faisais toujours la navette entre l'équipe de dev et le métier.

Coté dev : On m'a montré des codes dont je connaissais pas la syntax, j'ai fait des tutos pour comprendre un peu et je posais des questions débiles mais bon ça va j'étais pas rejeté ni perçu comme un relou. Au mieux, on m'a dit "c'est cool que tu t'intéresses"

Côté métier : Je vivais la vie du service avec eux, à tien qu'est-ce que tu fais ? Comment tu le fais ? Quand tu entends un bon gros "putain l'outil me fait chié", ah bon ? Pourquoi ? Comment ? Ok on ouvre un ticket (pour que ton chef derrière te sort un "on n'a pas le budget" ou "on peut pas le faire"...). Faire aussi un peu de fausse "UX", on va faire un dessin sur un bout de papier de comment on organise la page / qu'est-ce que tu veux dedans pour être sur qu'on oublie rien (puis petit photo à mettre en annexe dans la spec) ?

Bref, le cul entre deux chaises et entre deux mondes qui se comprennent pas : surtout des deux côtés tu es un peu le cheveux sur la soupe. Tu te sens chez toi que dans ton équipe de BA ou chacun est sur un domaine différent et avec lesquels tu présentes ce que tu fais en réunion d'équipe : une fois par semaine/sprint/mois/année.

C'est bien résumé non?

[William Vaurien]

j'en ai croisé aucun qui s'intéressait même de loin à la technique... Et en plus généralement les utilisateurs devaient être trop cons pour eux donc ils ne prenaient pas la peine de leur parler non plus...
Au final les specs pondus c'étaient des mockups d'écran sans réflexion ni sur le fond, ni sur la forme (l'UX c'est quoi ?) et surtout une communication unidirectionnelle: c'est moi le BA, toi t'es le grouillot...

Pourtant je suis persuadé que c'est un rouage essentiel d'un bon projet; mais que j'ai souvent vu ce rouage tourner à l'envers... et générer plus de problèmes qu'autre chose...

L'équipe la plus efficace que j'ai connue c'était avec des anglais. Avec une gestion de projet agile très simple, 2 consultant UX, 3 dev front, 3 dev back, 1 architecte (un vrai pas un mec qui a pris du galon en jouant au golf),1 expert métier et une douzaine de testeurs basés en Inde qui changeait tous les jours...

Au final on était tous très spécialisé, chacun savait ce qu'il devait faire et j'ai presque eu peur tellement le projet allait vite !

En France pendant mes années SSII c'était plutôt "tout le monde est expert de tout", chacun pondant des bouts d'IHM plus ou moins dégueu, le BA qui vient directement parler au dev en lui filant son fichier excel avec sa demi analyse et ses mockup moisis et le chef de projet qui n'est jamais là sauf pour venir gueuler quand la livraison est en retard...

C'est très grossièrement caricaturé, mais c'était un peu l'essence de ce que j'ai connu: par contre en discutant avec d'autres dev, notamment lors des recrutements, j'ai vu que c'était quand même très fortement lié à la culture d'entreprise.
Je crois que les dev en industrie était beaucoup moins bien loti que ceux dans les banque par exemple.

[Anonyme20240202]

T'as l'air de bien faire ton boulot. (@ook4mi)

Le truc c'est qu'à l'étranger, le scénario fabulé selon lequel le développeur ne comprend aucune logique que celle du code et qu'il est nécessaire d'avoir un intermédiaire n'existe pas (ou moins).

Et attention je ne dis pas que la position intermédiaire comme celle que tu décris n'a pas d'intérêt, mais qu'il est parfaitement normal d'avoir un développeur expert non seulement en terme de "Software Development" et sur les aspects techniques de la programmation, mais également expert """métier""" (comme on dit en France, je n'aime pas cette expression), autrement expert dans le domaine concerné par l'application.

En France j'ai ressenti une espèce d'hyper compartimentation avec un certain dédain pour le développeur comme le disait William.

Reconnaitre le développement comme une vraie compétence est une bonne chose mais il ne faut pas que ça devienne restrictif et le mec "ne peut faire que ça". C'est particulièrement frustrant en France où il n'y a pas encore vraiment (ça arrive doucement) de formation "software development" mais beaucoup de jeunes ingénieurs qui font des maths, de l'électronique, mais une fois que t'acquiers la casquette de dev t'es limite dans la merde

[William Vaurien]

Autre exemple à la décharge des équipes de BA hors équipe des dev, c'est que bien souvent après un certains temps ils se tournent vers les devs pour les questions métiers.
La connaissance métier restent chez les dev, dans le code. Les utilisateurs ont perdu la connaissances des règles avec l'automatisation, et les BA ont perdu le savoir au grès des évolutions du soft et des promotions.

J'ai juste le souvenir d'une BA allemande qui avait des classeurs et des classeurs avec toutes les versions de tous les processus métier (BPMN), des règles métier et des IHM de son domaine en version arbre mort.
Là c'était clairement un plaisir de travailler avec elle (bon on souffrait un peu quand même avec toute cette rigueur...) et surtout c'était elle l'interface entre nous et les utilisateurs: on n'avait jamais de ticket de support avec des questions métiers 'pourquoi untel a du valider tel doc' ou 'pourquoi bidule ne voit pas le champ 'top secret' du formulaire ?' C'était elle qui s'en occupait.

[Anonyme20240202]

Ouaip, la nature même du code et de son exactitude fait que si c'est du bon code au final la connaissance métier s'y trouve (TDD, BDD) de manière assez lisible. Du coup doublement frustrant quand tu connais le truc bout en bout, que t'es aussi à l'aise avec le client directement que n'importe qui d'autre, mais qu'on t'impose 10 intermédiaires pour intéragir avec qui que ce soit.

M'enfin c'est connu depuis des lustres, déjà critiqué en long et en large dans le culte Office Space

[ook4mi]

Je pense qu'il y a une autre casquette au BA : éviter les dérives.

Un métier peut choisir de faire des actions qui sont mauvaises voir illégale.
Un dev peut pisser du code et l'envoyer en test sans que cela répondent vraiment au besoin.

J'ai vu les deux et c'est prendre le temps de parler et de rationnaliser, de rappeler le pourquoi on fait ça et le comment on doit le faire. Préserver l'harmonie au global et pas laisser un nouveau dev partir en live pour nous pondre une usine à gaz ou partir dans l'exotisme. Je ne parle directement des technos et de leur choix car c'est général plus le tech lead qui est là pour orienté ces choix mais le BA doit aussi se faire entendre. "Vous voulez faire un POC pour qu'on se fasse mousser un peu, ok no problem mais pas sur ça => trop risqué ou à l'inverse, ici on peut se faire un peu plaisir les impacts sont limités et on saura corrigé".

Pas oublier aussi que si un bateau coule technique ou métier, le BA doit pas rester au sec sinon la cohésion va en prendre un coup... Le BA fait aussi du run et souvent les sujets de merde qui collent tous ce qui touche... Je me suis retrouvé à devoir faire des cadrages et des reprises de données à cause de filtre pourri de la tech ou pour aider le métier à diriger sa barque lors de la tempête migration / cloture annuel...

Mais c'est aussi une casquette de la frustration : y a tellement à apprendre partout, métier, domaine, technique, si...

[zatura]

J'avais jamais trop entendu parler de ce terme qu'est le business analyst. De ce que j'en comprends en lisant vos discussions c'est une sorte de responsable fonctionnel/product owner non ? Madame est UX designer et le PO de sa boîte est une caricature du principe de Peter.

Le mec est infoutu de rédiger des specs compréhensible par des dev ou un designer, il n'est au courant d'aucunes des spécificités de chaque produit dont il est responsable, ma nana est obligé de retenir elle même comment fonctionnent les produits et leurs fonctionnalités vu qu'elle fait les maquettes et que tous les devs viennent vers elle dès qu'ils ont une question vu que les specs sont soit pas à jour soit fausse.

Et je parle même pas des fois où il écrit littéralement des erreurs l'obligeant à revoir plusieurs écrans comme la fois où il décrivait un espace perso où il a dit qu'on pouvait uploader "un document" alors qu'il fallait dire "des documents"

A croire que la notion de cardinalité lui est étranger alors qu'il est sensé avoir 15 ans d'xp dont 10 en dev

[Anonyme20240202]

Hahaha j'ai eu exactement le même PO c'est incroyable, à se demander si on parle pas de la même personne, ouais ça arrive malheureusement. En général tous les collaborateurs finiront par se rendre compte de la situation et finiront par contacter directement le membre de l'équipe (UX Designer ici) sans passer par le PO, ce qui est la situation que tu commences à décrire. C'est pas facile mais il faut être patient et rester rigoureux.

Par exemple dans le cas du "un document" vs. "des documents" il faut documenter ce qui avait été dit et ne pas tomber dans le piège du "oui mais c'est ce que je voulais dire, évidemment". Certaines personnes n'ont aucun souci de rigueur et d'exactitude, en plus d'être incompétent, mauvais mélange.

[zatura]

J'ai oublié de préciser que le type en question veut tout le temps faire des "points à l'oral" quand ma copine lui dit que ses documents ne sont pas clairs.

Je pense qu'il n'a pas compris que le principe d'écrire des specs c'est qu'on a pas besoin de se souvenir de tout ce qui a été dit et que si on a un trou de mémoire c'est pas grave on va lire les specs

Mais bon à ce niveau là c'est pas de l'incompétence c'est de la flemmingite aïgue.

[Anonyme20240202]

Ouais ouais, tout pareil, extrêmement malsain, et souvent devient agressif quand tu demandes de commencer à rédiger/documenter. "Oui mais la confiance" "Oui mais la loyauté"
J'espère pour elle que ça se passera bien, mais bon elle est dans son droit et agit de manière professionnelle, donc ultimement si une partie tierce intervient et regarde la situation elle gagnera, ça devrait aller.

[zatura]

Oui de ce côté là pas de soucis. Elle a flippé quand elle est arrivé dans la boîte quasiment en même temps que le mec parce qu'elle ne le supportait pas. Elle se demandait si c'était elle qui faisait une fixette sur lui. Maintenant que les devs doivent aussi bosser avec lui elle n'est plus le seul à le détester

Tout le monde se demande un peu pourquoi le type est gardé alors qu'il fait clairement de la merde et qu'il commence à se faire taper dessus même par la hiérarchie. C'est un gros mystère.

[bellakill]

Petite question :
Quel salaire puis-je demander pour un poste d'admin infra et cloud ? Sachant que je ne suis pas en Ile de France.
J'ai travaillé pendant 9 ans dans l'IT que ce soit en tant que technicienne, team leader et admin poste de travail.
Donc là j'aurais un profil plutôt junior.

Je crains de demander moins que je ne devrais.

[gros_bidule]

Ca me fait réaliser que c'est une question récurrente.
Idée : on se crée un GoogleSheet partagé où l'on inscrit notre salaire pour une fonction donnée + des détails comme nombre d'années d'xp, poste en province ou ville, le pays, l'année de négo, ce genre de chose. De façon anonyme, donc en mentionnant un pseudo différent du fofo (mais un pseudo quand même pour que l'on ne se marche pas dessus si l'on veut corriger sa propre entrée, ou créer plusieurs entrées si l'on a déjà un long parcours).

Je pense à cela car dans ma boite actuelle on a fait ça, et même si on a l'info qu'une fois embauché ^^ ça permet au moins de se placer et d'avoir une idée des évolutions possibles en fonction de pas mal de critères tels que l'xp et les compétences clef.

[Praetor]

Idée : on se crée un GoogleSheet partagé où l'on inscrit notre salaire pour une fonction donnée + des détails comme nombre d'années d'xp, poste en province ou ville, le pays, ce genre de chose. De façon anonyme, donc en mentionnant un pseudo différent du fofo (mais un pseudo quand même pour que l'on ne se marche pas dessus si l'on veut corriger sa propre entrée).

1er message de ce topic:

Cliquez ici si vous souhaitez voir le salaire des canards google doc , et n’hésitez pas à partager votre situation!

[gros_bidule]

Je ne suis pas là. Lalala....

(merci pour le rappel !)

[Sariyah]

J'étais passé à côté aussi. Je viens de le remplir et pfiouuu vous avez quasi tous des putains de salaires ! Ok et l'expérience qui va avec mais bon.

[sosoran]

Mon petit mandat, de 2 semaines, de migration d'un code java legacy (1.4) en 15 se passe bien. j'avais déjà terminé une première fois mercredi avant qu'on se rende compte qu'on m'avait donné le mauvais code, puis j'ai reterminé vendredi avec le bon. L'équipe est contente de moi, et sous réserve qu'ils trouvent un projet + un financement, ils voudraient me garder. (et pour rester sur le thème des derniers messages, j'en suis à 40chf de l'heure sur cette mission).
Que cela se concrétise ou non, ça fait quand même sacrément plaisir de voir que dans des conditions normales, j'arrive à effectuer le travail demandé Ça redonne confiance !

(pas la moindre idée pour ta question Bellakill, désolé)

[bellakill]

Merci !

J'ai regardé le tableau et j'ai pu avoir des infos.
Cela m'a donné envie de retourner travailler en Suisse !

[OneCkm]

Bon il faudrait mettre en relation avec les coûts de la vie, de jolis salaires mais aussi plus de dépenses / charges.

[bellakill]

Oui c'est sur, mais quand je travaillais en Suisse j'étais frontalière donc un peu plus avantageux.
Mais il est vrai que quand j'ai voulu habiter Génève, j'ai vu que le coût de la vie était élevé.

[Chataigne]

Salut les canards.

Je ne sais pas si c'est le bon topic pour ça mais j'aurais quelques questions sur le passage de technicien à cadre.

En gros je suis technicien dans une boite de prestation en maintenance industrielle (maintenance conditionnelle). Dans les faits, en plus du boulot de technicien (intervention sur site + rapport) je fais un peu un boulot de chargé d'affaire : je gère des contrat, surtout le coté technique, je fais des visites commerciale, je rédige des offres, je gère les sous-traitant (CDC et gestion des chantiers), et depuis quelques temps j'ai une mission de développement commerciale même si elle n'a pas été super fructueuse à cause d'une certaine pandémie (je ne sais pas si vous en avez entendu parler...), mais aussi d'un manque de temps disponible pour cette mission vu ma charge de travail.

Mon chef m'a contacté pour me proposer de passer cadre et vu que je n'y connais rien, j'aimerai bien connaitre un peu ce que ça implique

De ce qu'il m'a dit:
- Ça ne changerait absolument rien au boulot que je fais actuellement, les mêmes missions et responsabilités.
- Je vais devoir faire un projet de cadrage avec mini-mémoire et soutenance. Ce projet se fera en très grande partie sur mon temps libre.
- Augmentation de 150 € brut. C'est une augmentation fixée par le groupe avec très peu de marge de manœuvre
- Probablement de meilleures augmentations annuelles.
- Passage en forfait. Aujourd'hui j'ai un contrat horaire, je ne pointe pas mais je dois faire 7h30 par jour. Ma boite ne paie pas les heures sup', du coup quand je bosse 1h de plus un jour, le lendemain je bosse 1h de moins. Apparemment, en forfait, je ne pourrai plus le faire, sauf pour les grosse récup (genre une journée de 12h).


Dans les points positifs je vois
- un salaire un peu mieux, et encore...
- une meilleure cotisation retraite pour dans 30 ans
- potentiellement, des meilleures augmentations annuelles (mais j'insiste sur le potentiellement parce qu'il n'y a rien d'officiel, de ce que je sais les augmentation sont souvent des enveloppe par service à répartir à la discrétion du manager)
- ça peut faire bien sur le CV

Dans les points négatifs :
- 150€ brut ça me parait peu, surtout que j'imagine qu'on cotise plus tous les mois. J'ai lu sur le net qu'il fallait au minimum 100€ brut de plus par mois pour compenser
- perte des récups d'une heure par ci par là. C'est un gros point négatif car vu que j'interviens chez mes clients, je fais énormément d'heures supplémentaires que je rattrape les jours suivants.


Voilà, si des canards ont déjà été dans ce cas, je suis preneur de leurs conseils. J'avoue que je suis un peu perdu. Sur le papier être cadre ça parait bien et ça fera plaisir à ma maman, mais j'ai un peu l'impression que je vais me retrouver à travailler plus pour gagner autant.

Merci d'avance .

[mathwern]

Pour résumer, il te paiera toutes tes heures sup' 150€ brut. Tu peux facilement calculer combien d'heures par mois ca fait, et donc à partir de combien d'heures t'es perdant (ca se compte probablement sur les doigts d'une main).
Projet + soutenance sur ton temps libre ça paraît très bizarre. Il veut te former ou cocher une case sur la description de poste?
Probablement de meilleures augmentation annuelles, comme tu le dis c'est du vent puisqu'il s'engage à rien de plus qu'aujourd'hui.

Je connais pas la différence cadre/techicien en France mais ca ressemble quand même vachement à un entubage en règle (le fait que ça vienne de ton chef est déjà un bon indicateur de qui serait gagnant).

[Hargun]

La différence cadre/technicien, c'est l'écart entre ton brut et ton net qui passe de 22 à 25%.
Il n'y a plus de différence de cotisations depuis la fusion agirc/arrco.

Selon moi, comme le dit également mathwern, ils te proposent 150€ pour que tu ne récupères plus tes heures sup.