Discussion :

[Kropernic]

En brut certainement sinon les informaticiens sont sacrément bien payés

Cool, ça veut dire que j'suis dans la catégorie bien payé (en prenant comme postulant que Bruxelles soit équivalent à Paris mais rien n'est moins sûr ).

En province où? Il y a province (Nice, Lyon, Lille, Bordeaux, Nantes) et province (petzouille-sur-nouille, ...).
Bac+5 / 8 ans d'XP en Java, ça veut dire expert java, c'est minimum 42K€ dans les grandes villes de province soit 3500€ brut (~2700€ net).
Donc si tu n'es pas a petzouille-sur-nouille et que tu gagne moins, il faudrait peut-être actualiser ton profil Linkedin et te laisser chasser.

Ca marche comment le net en France ? Car ici en Belgique, j'suis à 3725€ brut et en net ça me fait 2163€. Y a une sacrée marge par rapport à 2700€

[Darkzinus]

Ca marche comment le net en France ? Car ici en Belgique, j'suis à 3725€ brut et en net ça me fait 2163€. Y a une sacrée marge par rapport à 2700€

Ah non en France le delta est de l'ordre de 23% entre le brut en net (avant impôt évidemment). Du coup c'est difficilement comparable.

[Kropernic]

Ah non en France le delta est de l'ordre de 23% entre le brut en net (avant impôt évidemment). Du coup c'est difficilement comparable.

Ah ok ! En Belgique, on est déjà prélevé pour les impôts. Et une fois par an, avec la déclaration de revenu, on complète ce qui manque ou bien l'état nous rembourse ce qui a été pris en trop.

[Darkzinus]

Ah ok ! En Belgique, on est déjà prélevé pour les impôts. Et une fois par an, avec la déclaration de revenu, on complète ce qui manque ou bien l'état nous rembourse ce qui a été pris en trop.

Avec le prélèvement à la source on aura un système équivalent ici. Cela sera en vigueur en 2019.

[el_slapper]

Mais 23%, c'est sur le brut, pas sur le superbrut, pour lequel on en est quasiment à 50%.

Oui, le système Français est incompréhensible. Il y a 15 ans, mon père qui était dans le domaine me disait "nul en France n'est capable de faire une fiche de paye à la main, sans un programme qui va bien". Ca a largement empiré depuis.

[Invité]

Oui, le système Français est incompréhensible. Il y a 15 ans, mon père qui était dans le domaine me disait "nul en France n'est capable de faire une fiche de paye à la main, sans un programme qui va bien". Ca a largement empiré depuis.

Quand j'ai quitté la France ma fiche de paie tenait sur 3 pages. Au Québec, ça tient sur une demi page bien aérée...

[el_slapper]

Après, je ne remets pas en cause le principe des prélèvements obligatoires. C'est juste et utile de financer la sécu, le chômage, la retraite, et autres détails importants. C'est juste que le mode de calcul est hallucinant(au sens premier : les mecs qui ont pondu ça étaient sous champis, c'est pas possible autrement).

[MC2]

Très intéressant cette étude car pour les « anciens informaticiens » (tout le monde n'est pas passé chef malheureusement), cela donne des pistes de reconversion. J'ai commencé à apprendre R, j'ai eu raison. Merci à vous !

[Invité]

Après, je ne remets pas en cause le principe des prélèvements obligatoires. C'est juste et utile de financer la sécu, le chômage, la retraite, et autres détails importants. C'est juste que le mode de calcul est hallucinant(au sens premier : les mecs qui ont pondu ça étaient sous champis, c'est pas possible autrement).

Moi non plus, je ne remets pas en cause les impôts ! Au Québec, je paie autant d'impôt qu'en France, mais sur la feuille de paie, c'est bien plus simple. Et en plus, on est prélevé à la base...
Il n'y a pas de taux Z0 qui s'applique sur le prélèvement t1 avec le taux Z1 moins l'humeur du comptable plus le taux directeur du delta entre le jour 1 et le jour 31...
C'est possible de faire plus simple mais ça à l'air qu'en France, on n'est pas satisfait quand c'est simple et transparent et comme on ne veut pas vraiment de changement...

[kilroyFR]

Tu oublies les lambdas/linq, et les async/await (qui à ma connaissance n'ont toujours pas d'équivalent).

Enfin les lambdas/linq c'est plus des facilités d'ecriture qu'autre chose. Rien d'essentiel; on s'en passe ailleurs et ce ne pose pas plus probleme que ca.
Pour les autres je suis d'accord

Il n'en reste pas moi que cette force est également sa faiblesse. Quid du suivi long terme? Dans tous les cas Microsoft a bien pris le virage et préfère tout ouvrir pour réduire ses couts tout en maximisant ses gains.Puis il n'y a pas que des mauvaise chose, meme avec tout le mal que tu dis de WPF, tu te dois de reconnaitre que MVVM à le vent en poupe bien en dehors de wpf.

Ben le suivi microsoft sur ses errements c'est pas mieux que de l'OpenSource (Silverlight, Lightswitch, linqSql, WPF (plus rien depuis 2012 je le rappelle), webapi maintenant etc. toutes ces technos en '...' desormais chez microsoft).
Et OUI concernant WPF, on a abandonné ces anciens projets dans ma boite actuelle (Xerox) car c'est une techno du passé; nos clients veulent du client léger pas des trucs qui fonctionnent que sur des environnements PC Windows. Abandon de WCF egalement; tout est REST/Json/Protobuf et rien d'autre.
MVVM ca n'engage que toi. c'est un concept du passé egalement (et une belle usine a gaz pour deboguer - j'y ai passé presque 5 ans de ma vie je sais de quoi je parle).

J'espère que tu vas pas trop pleurer quand tu vas devoir passer à Kotlin .

Non, pas peur du changement contrairement a d'autres qui restent collés sur leur sacro-saint Windows. Ca les rassure.

[kilroyFR]

C'est un peu sous-estimer l'environnement Microsoft.
Question qualité IDE : Visual Studio (pour C#, .NET) est supérieur aux IDE pour le java.

C'est toi qui le dit. Visual Studio sur les dernieres versions est devenue assez lourd et donc android studio n'a pas a rougir. J'ai autant de plaisir a bosser sur l'un comme sur l'autre.

Et concernant les choses "novatrices", tu mélanges un peu tout, Java/Linux. Déjà je vois pas le rapport entre java et linux. Et je vois pas en quoi les ORM / Container / ... sont à l'origine des éléments fait par ou pour java/linux.
Côté innovation, si Microsoft va pas dans ton sens, c'est autre chose mais ils innovent beaucoup et une partie en open-source : Azure, TypeScript, Visual Studio Code, ...

non je ne melange rien c'est toi qui essaie de pondre un pseudo raisonnement.
Dans le monde pendant tres longtemps il y avait la stack java/linux d'un coté (accessoirement un embryon de C# avec mono mais je parle d'applis en production) et de l'autre coté le monde Windows (open source = niet).
hibernate, log4j, spring, junit, composer etc. toutes ces briques que tout le monde utilise de partout maintenant ont d'abord fait leur preuve sur Linux/Java puis portées vers le monde C# (mais toujours avec du retard dans les fonctionnalités entre ces 2 mondes).
Les containers si tu en avais fait sur Linux et maintenant ce qui est disponible sur windows tu vois le gap enorme qu'il existe entre ces plateformes, ca arrive avec du retard que microsoft essaie de combler mais c'est assez peu concluant. Un docker de quelques Mo sur Linux c'est possible, la moindre appli docker sous windows c'est de 600 Mo a 6 Go (aspnet)!).

PS: je ne suis pas un vendu Microsoft, je fais du PHP.

Moi non plus je te parle de choses que j'utilise au quotidien, pas quelque chose lu sur internet. Je fais du Linux/Java (et php) a titre perso mais windows/C# au taf. Oui l'environnement linux/java reste plus pour les techos que l'environnement Windows je reconnais. La ligne de commande c'est pas inné pour certains devs.

[ciliaris]

Bonjour, Je ne vois pas 4D dans cette liste. Mais je vois WindDev. 4D est-il si marginal ?

[flyeric]

Merci pour l'étude.

[fiduce]

Il faut se méfier comme de la peste des corrélations cachées dans ce genre d'étude.
Il y a des corrélations langage-cycle de vie du logiciel (moins de nouveaux projets en Cobol aujourd'hui ;-) ).
Il y a des corrélations langage-bétise du client (celui qui a encore du Cobol aujourd'hui, il a raté quelque chose, alors on sait qu'on peut le saigner).
Il y a des corrélations langage-compétences annexes (exemple criant : le R).
Il y a des corrélations entre le langage et l'age des pratiquants, donc un peu aussi leur paye (tu peux toujours essayer de choper un coboliste débutant).
Il y a des corrélations entre le langage et la taille des projets (et donc le tarif des boites qui attaquent ce marché, etc).
Il y a des corrélations entre le langage et le domaine métier (et donc un biais salarial à compétences égales).
Il y a une non-corrélations entre le langage des offres d'emploi et la quantité de travail disponible dans ce langage. Ainsi, par exemple, un indépendant fait du clé en main et ensuite assure le suivi sans limitation de durée : il n'y aura jamais eu d'offre d'emploi pour son projet. S'il code le truc en Perl, limace, Java, VB, C, C++ ou C#, ces "petits" projets (pourtant très nombreux) ne sont jamais visibles dans les offres d'emplois.
Les offres d'emploi correspondent aux demandes des employeurs, pas à celles des donneurs d'ordres. On peut travailler sans être un employé : on peut être un indépendant et très bien gagner sa vie sur des niches où plus personne ne prend le risque d'embaucher.
Ensuite, vous croyez quoi ? Qu'un client demande du Java ou du C++ ? Rarement, et quand ça arrive, c'est le plus souvent en maintenance (d'où le Cobol quarantage).
Il y en a pas mal qui veulent un produit clé en main avec une maintenance sur X années. Le reste ils s'en fichent. Pour tous les "petits projets" démarrant avec 3 à 6 mois.homme de développement, tout le monde cherche du "clé en main" sans se soucier du langage. Or ces projets sont nombreux et totalisent un "certain volume global", mais n'arrivent jamais sur le marché de l'emploi. Ils arrivent sur le marché des affaires. Et c'est celui qui répond à l'appel d'offre qui traduit l'affaire en langage, pour ensuite, éventuellement, embaucher. Actuellement, ce stratif là, il tire la couverture vers "ce qui marche", ce qu'il peut facilement réutiliser sur d'autres projets. Pas forcément sur ce qui est bon pour le projet précis.

La conclusion, c'est que les petits projets sont sous-représentés dans l'étude (1) et que, pour les petits projets, il vaut toujours mieux s'adresser aux petites structures, ou indépendants, qui ne travaillent jamais sur autre chose (2). D'abord parce que ces gens sont des spécialistes des projets plus modestes (réalisables par une ou deux personnes), ils maitrisent les outils adaptés et savent démarrer d'une page blanche en garantissant un résultat. Ensuite parce qu'il n'y pas de turn over chez un indépendant. Enfin, s'il est correct, ses tarifs seront bien plus prévisibles que ceux du manager "du moment" qui vous rendra visite en pleurant parce qu'il a du mal à garder les ressources adaptés à votre projet.

Vous avez compris que j'étais moi même développeur indépendant. Je n'ai jamais cherché de mission. J'ai quelques clients qui m'appellent, d'autres ont eu ma carte ou vu un produit tourner. Je pourrais bosser en sous-traitance pour des SSII, mais les fois où j'ai été contacté le tarif reversé était ridicule et les specs, collectées par d'autres, indigentes.
Mes clients n'auront qu'un seul interlocuteur joignable h24/j365 par mail et téléphone, directement, pour tout problème, demain ou dans 10 ans (si je ne meurs pas prématurément : personne ne peut rien garantir mais on peut comparer l'espérance de vie d'une SSII, l'espérance de présence d'un salarié, et celle d'un indépendant).

Coté "assurance qualité" des SSII, j'ai remarqué que plus les boites avaient de labels, plus les docs étaient dégueulasses. Le label qualité est un diplôme d'entreprise ayant du turn over. Un diplôme de bonne taylorisation. L'indépendant a ses diplômes personnels, et ils lui collent au derrière toute sa vie.

Pour finir, les offres d'emploi, c'est aussi des stats un peu gonflées pour les profils qu'on ne trouve pas autrement ... donc les technos moisies que personne ne veut pratiquer, sont toujours un peu surestimées.

[softeur]

Merci pour cette étude, mais je pense que cela ne reflète pas la réalité.
Par exemple, je gagne 6000€/brut mois et développe en VB.net
Malheureusement ce genre d'étude risque d'orienter les jeunes vers l'apprentissage d'un langage en particulier. Et le pire ... JAVA.
Les 'informaticiens' demandés aujourd'hui doivent résoudre des problèmes, se connecter à n'importe quelle sources de données etc. Pas écrire pour écrire du code comme on tricote un pull. XML, XSLT, FRAMEWORK et autres APIs sont bien plus important a maîtriser que le langage.

Pour VB.net (la version BASIC pour dotNet) je lis souvent que c'est pas pro, c'est pour les enfants, les petits programmes, les débutants bref .. dénigré.
Personnellement je développement des solutions de toutes tailles, dont une grosse (un ERP complet). BASIC est un langage de programmation éprouvé, probablement le plus connu, un des plus vieux et, le plus utilisé sous Word, Excel (qu'on l'on ne présente plus)... Oui parce que qui comprend BASIC, comprend VBA (d'ou pourquoi les distinguer dans cette enquête ?)

En passant, BASIC c'est la base de l'histoire de Microsoft et Windows c'est 90% de l'informatique. Il y a des milliers de PME qui aimerai embaucher des gens qui jongles entre les données d'Office. Je pense que la com sur C# à bien fonctionné, pour faire venir les amoureux de l'accolage et des points virgules vers dotNet. Il fallait bien récupérer les développeurs C et ++ (et pourquoi pas +++).

Bref, je ne suis pas certain que ce genre d'enquête servent la cause de l'emploi en France. Au mois de vouloir rentrer chez Larry Ellison et c'est pas en France.

[bathrax]

Merci. C'est très édifiant.

[fiduce]

Je pense que la com sur C# à bien fonctionné, pour faire venir les amoureux de l'accolage et des points virgules vers dotNet. Il fallait bien récupérer les développeurs C et ++ (et pourquoi pas +++).

Je suis d'accord sur l'essentiel, mais sur le passage particulier que je cite, je dirais que le C# propose tout de même quelques syntaxes fabuleuses et que le point-virgule permet d'écrire des appels de fonction sur plusieurs lignes sans caractère de continuation. C'est maigre comme consolation, mais tout de même bien réel.

[netchose]

reptile venimeux

Non Python ne pique pas

[patrick72]

L'offre et la demande ne justifie pas tous : il faut prendre en compte aussi l'age et l'expérience des développeurs : c'est net avec le Cobol, où il s'agit de personne en fin de carrière, avec, en province, des primes d'ancienneté (moins de tourne-over que sur la région parisienne)

[François DORIN]

Ben le suivi microsoft sur ses errements c'est pas mieux que de l'OpenSource (Silverlight, Lightswitch, linqSql, WPF (plus rien depuis 2012 je le rappelle), webapi maintenant etc. toutes ces technos en '...' desormais chez microsoft).
Et OUI concernant WPF, on a abandonné ces anciens projets dans ma boite actuelle (Xerox), car c'est une techno du passé; nos clients veulent du client léger pas des trucs qui fonctionnent que sur des environnements PC Windows. Abandon de WCF egalement; tout est REST/Json/Protobuf et rien d'autre.
MVVM ca n'engage que toi. c'est un concept du passé egalement (et une belle usine a gaz pour deboguer - j'y ai passé presque 5 ans de ma vie je sais de quoi je parle).

Attention : dire qu'une technologie n'évolue plus et dire qu'elle est abandonnée, ce sont deux choses différentes. Microsoft abandonne rarement les technos lorsqu'elles ont été officiellement publiée en version stable (exit donc les proof of concept dans ce qui suit).

Lorsqu'une technologie atteint une maturité suffisante, est-il nécessaire de la faire encore évoluer ? Exemple avec les winform. Microsoft fournit un ensemble de fonctionnalités et de composants de base. Est-ce à lui d'ajouter encore et encore de nouveaux composants, ou doit-il laisser un écosystème se développer et laisser une place aux composants tiers ? Pour information, des technos comme Winform ou WPF (pour lequel je pourrais tenir exactement le même discours) ne sont pas abandonnées. Elles n'ont pas de date de fin de support et donc, malgré l'absence d'évolution, ce sont des technologies pérennes pour une utilisation.

Par contre, il y a bien des technologies abandonnées, comme Silverlight. Mais est-ce la faute de Microsoft, si avec le HTML5 et ses nouvelles fonctionnalités, les technos externes aux navigateurs sont petit à petit abandonnées ? Pour rappel, on a vu une baisse drastique de Flash, de Java ces dernières années. En 2007, quand est sortie la première version de Silverlight, il était très difficile de savoir que les navigateurs prendraient ce tournant. Donc oui, Microsoft a abandonné sa techno, car le contexte allait dans le sens d'un abandon progressif de toutes les technos de ce genre.

Et encore, ici on pourrait mettre en avant la bonne volonté de Microsoft, qui a annoncé classer cette technologie comme "abandonnée" en 2012, et qui maintient malgré tout un support jusqu'en 2021 !

On peut reprocher beaucoup de choses à Microsoft. Il a fait des erreurs par le passé (et en fera sans doute encore à l'avenir), mais les technologies qu'il développe ont une pérennité et permettent de mettre en place des visions à long terme.

-------------


Pour en revenir à l'étude elle-même, j'ai envie de dire : attention aux biais ! Est-ce que la section emploi est suffisamment représentative du marché ? Est-ce que les startup n'auraient pas tendance à être plus représentées que les ESN par exemple (ou inversement) ? Car cela pourrait changer assez radicalement la vision du marché. De même, il faudrait prendre en compte la localisation des offres. Cela a été fait pour le salaire, où le choix s'est porté sur la France Paris/Province.

Pour en revenir à la position de C#, je pense que la lente régression est liée au manque de portabilité initiale du langage. Pendant (trop) longtemps, l'environnement .NET était cantonné officiellement à un environnement Windows. Il existe bien des projets comme Mono mais qui sont des projets communautaires non officiellement supportés.

Aujourd'hui, la donne a changé. .NET Standard (et .NET Core) a vu le jour comme initiative pour mettre en place un environnement portable et multi-plateforme. Aujourd'hui, il est possible de réaliser des bibliothèques, des applications consoles et des applications web de manière portable. Il reste les applications lourdes qui sont encore à la traîne, mais des travaux sont en cours.

Cette techno est encore jeune. Je la suis de près par exemple, sans encore y être passé formellement, car j'attendais qu'on ait un peu plus de recul pour le faire. Et j'ai envie de dire que c'est maintenant utilisable depuis .NET Standard 2.0 (la 1 était encore trop restrictive en terme d'API disponible). Je suis donc certains que cette technologie va permettre un déploiement plus large du C# dans les années à venir.