Développeur : un métier largement méprisé en entreprise

C’est une triste réalité : le métier de développeur est parfois encore largement méprisé en entreprise encore. Avec va hélas aussi parfois le salaire, ce qui a notamment été confirmé par le CNISF il y a quelques années. Nous voyons dans l’article le pourquoi de ce mal et des moyens de s’en protéger.

Débloque les + belles offres tech en 10 mins

L’informatique en entreprise : un centre de coûts

La culture française fait que les métiers techniques sont vus comme des centres de coûts, contrairement à ce qui se passe dans le milieu anglo-saxon. Il se trouve que la plupart des écoles de management forment leurs étudiants à réduire les coûts par tous les moyens tout en maximisant les profits comme illustré dans le livre J’ai fait HEC et je m’en excuse, parfois au-delà du raisonnable. Or en informatique, l’essentiel des coûts se résume aux salaires, donc ça signifie que la tendance est de baisser les salaires.

Cette considération pousse par ailleurs les entrepreneurs à mépriser tous ces centres de coûts et donc presser au maximum les équipes qui y travaillent dans l’optique de diminuer les dépenses. De même dans la mesure du possible ces mêmes employeurs préféreront se séparer de salariés expérimentés, devenus trop chers, et les remplacer par des jeunes fraîchement diplômés et formés aux nouvelles technologies. La baisse du niveau d’expérience mène hélas souvent à une baisse de qualité car les juniors tendront à répéter des erreurs que leurs aînés. Et quand ils seront expérimentés ou n’accepteront plus la pression on leur montrera gentiment la porte. À force la qualité des logiciels devient abysmal, comme disent les Anglais, ce qui renforce auprès des chefs d’entreprise l’idée que les développeurs sont tous mauvais et ne font que des logiciels bogués. Bref dans ce cas, perdu pour perdu, autant prendre les moins chers, et faire perdurer le cercle vicieux.

Il va de soi que c’est un mauvais calcul à long terme mais les dirigeants d’entreprise s’en moquent. Ils seront partis depuis bien longtemps et auront entretemps montré aux actionnaires qu’ils auront réduit les coûts. Ces derniers seront donc contents et tentés d’augmenter leurs émoluments. J’ai d’ailleurs entendu il y a quelques temps le DSI d’une banque déclarer qu’il était bien conscient que la qualité était en baisse, mais pour l’instant c’était acceptable donc il pouvait continuer à réduire les coûts. Cette banque allait délocaliser ses bureaux de Mumbai en Inde, devenus trop chers, vers Chennai.

En fait il n’y a qu’en SSII où les informaticiens en mission ne sont pas considérés comme un centre de coûts, mais comme la marge de la société se fait directement sur les taux journaliers et que les clients cherchent à payer de moins en moins cher, ceux qui en pâtissent sont les développeurs. Il ne faut pas oublier que pour le client un prestataire de SSII travaille dans son service informatique et est donc un centre de coûts.

La résistance des développeurs

Bien évidemment de nombreux salariés ont compris que leur direction les considère comme des ressources interchangeables. C’est d’autant plus facile que le taux de chômage reste relativement élevé, 10% officiellement en France, mais il semblerait que ce soit en fait beaucoup plus. Tout ceci pèse là encore sur les salaires. Pour tenter de lutter contre ce phénomène en informatique on trouve deux types de résistance : active et passive.

La résistance active : ou comment se rendre « indispensable »

Le salarié en résistance active tentera par tous les moyens de se rendre « indispensable ». Alors certes il ne l’est jamais dans l’absolu mais son employeur sait qu’il a intérêt à le garder. Dans le cas contraire il serait très compliqué et coûteux de le remplacer, même si ça reste possible. Côté salarié, l’intérêt est double : d’un côté il est davantage respecté par l’employeur, et de l’autre il peut plus facilement négocier son salaire.

Pour un développeur il y a deux manières de se rendre indispensable :

• Soit en rendant son code illisible par un tiers, on appelle ça de l’obfuscation.
• Soit en pratiquant une technique de flooding.

On va passer rapidement sur le cas du développeur qui rend son code illisible tellement c’est évident. J’ai par exemple connu un développeur C++ qui avait mis tout son code dans un seul fichier de 60000 lignes. Évidemment il était le seul à s’y retrouver là-dedans. Et il était très grassement payé par l’employeur qui savait qu’il ne pourrait s’en séparer facilement…

Passons maintenant à la technique du flooding.

Le flooding

Le flooding est une technique particulièrement retorse. Cependant elle ne peut être menée proprement que par un développeur chevronné. En effet, la technique consiste à faire un code irréprochable techniquement, mais très rapidement. C’est-à-dire que le code doit être correctement couvert par des tests automatisés, correctement documenté et j’en passe. Jusque là vous me direz, ce que je suis en train de dire est totalement bidon.

Sauf que l’astuce est d’inonder littéralement l’application de nouveau code et de nouvelles fonctionnalités. Dès lors même avec la documentation les autres membres de l’équipe ne s’y retrouveront pas, car ils ne sauront plus par où commencer et ce même si le développeur adepte du flooding les aiguille. Ensuite il suffit à ce développeur de partir en vacances quelque temps, par exemple aux vacances de Pâques, pour que la direction s’aperçoive que la personne est devenue totalement indispensable car sans elle la productivité chute littéralement. Le tout est de bien choisir la période d’absence de façon à ce que les effectifs de l’équipe ne soient pas trop diminués. Il faut aussi faire attention au burn-out avec cette technique.

Cette technique est bien plus redoutable que celle consistant à « simplement » obfusquer son code. Dans ce dernier cas un bon développeur motivé pourra réussir à venir à bout des choses en quelques semaines. Cela dit il ne faut pas oublier que les bons développeurs sont chers. Un bon indépendant pourra facturer facilement 700 ou 800 euros par jour par exemple.

La résistance passive

La résistance passive consiste à résister passivement, comme son nom l’indique. Elle ne peut fonctionner que si tout le monde est soudé dans l’équipe face à un chef qui prend ses effectifs pour des imbéciles. Un autre cas serait celui du chef qui cherche à challenger ses équipes en envoyant le même chiffrage à faire à plusieurs personnes, et ensuite prendre le moins élevé. Bref bien souvent dans ce cas les gens finissent par résister passivement, à savoir :

• Suivre des horaires stricts jusqu’à l’absurde. Par exemple si les gens finissent à 18h30 et que le serveur tombe à 18h31, personne n’intervient.
• Suivre les ordres du chef en mode absurde, façon réfléchir c’est commencer à désobéir. Et dans certains cas ne prendre en compte que les ordres écrits.

Il va de soi qu’un tel mode de résistance peut rapidement rendre folle toute personne tentant d’encadrer une telle équipe. Dès lors soit le chef en question saura se remettre en question, soit il cherchera à renforcer la pression, ce qui en retour renforce la résistance. On appelle un tel mode de résistance une attitude passive agressive. Une telle équipe finit rapidement par ne plus rien produire, ou du moins des logiciels de si faible qualité qu’ils en sont inexploitables.

En bref…

Une entreprise dans laquelle les gens seraient rentrés en résistance est généralement une entreprise à fuir. Et encore je ne parle pas des start-ups créées par des commerciaux sans scrupules qui cherchent au maximum à presser le citron des gens pour ensuite revendre leur société au plus offrants.

Heureusement toutes les entreprises ne sont pas comme ça, même si question salaire elles ont tendance à s’aligner sur le marché, c’est-à-dire en nivelant les salaires vers le bas. Eh oui depuis 30 ans le salaire d’un informaticien débutant a tendance à diminuer : dans les années 80 il était de l’ordre de 250000 francs alors que maintenant c’est plutôt 35000€ en région parisiennne. Comme quoi l’informatique a rapporté, mais ce n’est plus le cas.

Toujours est-il que le meilleur moyen de tomber dans une entreprise qui respecte ses développeurs est d’avoir des contacts dans cette dernière pour savoir comment ça se passe, de l’intérieur. Et ne vous faites pas piéger par la communication cool, c’est généralement un miroir aux alouettes.

Le mot de la fin s’adresse aux employeurs : ne méprisez pas vos développeurs, vous risquez de le payer cher…

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

1. La dictature du bonheur en entreprise
2. Bien gérer un chef toxique
3. Les profils de développeurs à fuir

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn