Discussion :

[Anomaly]

Emploi développeur 2017 : les langages les plus demandés et les mieux payés
Java, JavaScript et PHP sont les plus demandés, mais R, Perl, Go et Scala les mieux rémunérés.

L'année dernière, nous avons fait plusieurs études sur les offres d'emploi postées sur Developpez.com. Il est temps de les actualiser en prenant en compte les offres d'emploi postées en 2017, sur un total de 19 000 offres d'emploi. 

Cependant, cette année, plutôt que de diviser l'étude entre popularité et salaire, nous avons choisi de diviser l'étude entre langages d'une part et bases de données d'autre part, et aborder la popularité et le salaire dans chacune.  C'est pour cela aussi que vous ne trouverez pas SQL dans celle-ci ; les bases de données feront l'objet d'une autre étude. 

Voici tout d'abord la popularité des différents langages dans les offres d'emploi de 2017, c'est-à-dire la proportion d'offres d'emploi postées sur Developpez.com mentionnant chaque langage.



Et voici l'évolution de la demande sur les langages au cours des cinq dernières années. Nous avons choisi de faire deux graphiques, les langages les plus demandés et les langages les plus rares pour améliorer la lisibilité de l'étude.

Évolution des langages très demandés de 2013 à 2017	Évolution des langages moins demandés de 2013 à 2017

Et voici les données en chiffres :

	2013	2014	2015	2016	2017
Java	26,3%	26,1%	25,9%	28,8%	24,4%
JavaScript	18,6%	17,0%	18,3%	17,2%	20,5%
PHP	24,0%	21,4%	16,9%	15,1%	19,2%
Python	3,7%	4,9%	7,9%	7,1%	7,8%
C#	11,2%	8,6%	7,8%	7,8%	6,4%
C++	6,6%	5,3%	6,1%	5,3%	5,8%
Scala	1,8%	2,7%	3,3%	3,4%	3,2%
C	1,4%	2,6%	2,2%	2,4%	2,2%
Ruby	1,4%	2,2%	1,7%	1,9%	1,3%
Swift	< 0,1%	0,1%	0,9%	1,7%	1,2%
Windev	0,2%	0,6%	0,5%	0,5%	1,0%
VBA	< 0,1%	1,5%	1,2%	1,0%	1,0%
Delphi	0,6%	0,6%	0,2%	0,5%	0,8%
TypeScript	< 0,1%	< 0,1%	0,1%	0,3%	0,8%
R	< 0,1%	0,1%	0,4%	0,5%	0,7%
Perl	0,6%	1,7%	1,3%	1,9%	0,7%
VB.NET	0,2%	0,9%	1,1%	0,7%	0,6%
Go	0,2%	< 0,1%	0,2%	0,4%	0,6%
Cobol	0,2%	1,1%	0,9%	1,1%	0,5%
Objective C	1,1%	0,4%	0,9%	1,0%	0,5%
Matlab	< 0,1%	0,1%	0,6%	0,4%	0,4%
D	< 0,1%	0,9%	0,5%	0,3%	0,2%
Abap	< 0,1%	0,3%	0,1%	0,2%	0,1%
Dart	0,2%	0,1%	0,1%	0,1%	0,1%
Rust	< 0,1%	0,1%	0,2%	0,2%	< 0,1%
Flash	2,0%	0,6%	0,5%	0,2%	< 0,1%

En ce qui concerne les langages les plus demandés, Java règne en maître, et reste globalement stable. JavaScript est bon deuxième, mais sa tendance est à la hausse, ce qui n'est pas surprenant étant donné son importance dans les navigateurs, mais aussi son utilisation récente dans d'autres domaines (NodeJS, application mobile...).

PHP, autrefois bon deuxième 2013, avait vu une chute importante de sa popularité, au point de se faire dépasser par JavaScript, mais on observe une solide remontée en 2017. Les améliorations significatives apportées à la version 7 du langage de script serveur y sont probablement pour quelque chose.

Python, à l'origine sixième du classement, monte régulièrement dans le classement pour se hisser en 2017 à la quatrième place ; le fait que le langage du reptile venimeux soit souvent le langage de prédilection pour l'enseignement explique probablement en partie cette envolée.

En revanche, les performances du C#, langage phare pour développer en .NET, déçoivent. Originellement quatrième, il est en baisse constate, quoique modérée, depuis 2013, et se retrouve dépassé par Python en 2017.

Quant au C++, il maintient sa position solidement ; même s'il a été dépassé lui aussi par le Python, son utilisation est parfaitement stable au fur et à mesure des années ; rappelons que dans l'ensemble des langages présents dans ce graphique, il est le seul à produire du code natif.

Enfin Scala, qui fait son entrée dans cette étude, se maintient à un solide 3,2 %, supérieur au C sur toute la période, ce qui donne une bonne crédibilité au métalangage suisse.

Au niveau des langages moins demandés (moins de 3% des offres d'emploi), on peut voir une bonne santé (relative) du C dont la demande est en hausse ; rappelons que le C permet un développement de bas niveau, idéal pour l'embarqué par exemple. TypeScript, très récent, monte en flèche ; son utilisation dans le framework Angular y est probablement pour beaucoup. Go et R sont aussi des langages qui montent, bien que leur montée soit nettement moins spectaculaire que pour TypeScript.

Du côté des autres langages récents, Rust n'est pas en forme, avec aucune offre trouvée en 2017. Dart se maintient, mais reste à un niveau très bas.

Delphi, malgré une baisse de régime en 2015, remonte la pente et se paye même le luxe d'être bien plus populaire qu'en 2013. Le niveau de VBA indique sinon que la programmation Microsoft Office est toujours d'actualité, bien que peu porteur. Pour VB.NET, la tendance est à la baisse, à l'instar du C#.

Objective C est clairement passé de mode ; son remplaçant pour la programmation Apple, Swift, se débrouille plutôt bien même si la tendance est à la baisse en 2017. Enfin, Flash est clairement une technologie en état avancé de décomposition .

Mais combien ça rapporte, en fait ?

Savoir que tel ou tel langage est demandé dans les offres d'emploi c'est une chose, mais savoir combien ça rapporte, cela peut être aussi très intéressant. Du coup, nous avons choisi d'étudier les salaires des offres d'emploi en fonction des langages. La méthodologie utilisée consiste à prendre l'ensemble des offres d'emploi postées sur Developpez.com dont le salaire est renseigné durant l'année 2017, et sélectionner pour chaque langage les offres d'emploi qui correspondent (une même offre d'emploi peut éventuellement être utilisée plusieurs fois si elle utilise différents langages). Une moyenne des salaires est alors faite sur cette sélection, en sachant que les anomalies évidentes (salaire clairement trop bas ou trop élevé) sont exclues.

Nous avons choisi de diviser les résultats entre Paris et le reste de la France, étant donné que les salaires peuvent être très différents entre ces deux parties de la France. Enfin, à l'instar des offres d'emploi, les moyennes correspondent à des salaires bruts. N'oubliez pas qu'il s'agit d'une étude sur les salaires proposés sur les offres d'emploi de 2017, qui peuvent être différents des salaires réels des personnes embauchées, et aussi différents des personnes déjà en poste depuis un certain temps. Enfin, pour certaines technologies peu populaires, les informations de salaire n'étaient pas suffisamment fiables pour en dégager une moyenne, d'où leur absence dans cette deuxième partie de l'étude. 

Salaires par langage en région parisienne en 2017



Ce qui nous permet de dégager globalement les ensembles suivants :

« Très bien payés » ~ 5 000 €/mois	« Bien payés » ~ 4 200 €/mois	« Assez bien payés » ~ 3 800 €/mois	« Correctement payés » ~ 3 500 €/mois	« Mal payés » ~ 3 000 €/mois
R	Perl, Go, Scala	Ruby, Java, TypeScript	WinDev, C#, JavaScript, C, Python, PHP, C++, Swift	VBA, VB.NET, Cobol, Delphi

Par rapport à 2017, on note une spectaculaire montée de salaire concernant le langage R. Dans une moindre mesure, Perl, C, C++ et même Delphi connaissent une montée significative du salaire proposé. Cela n'empêche malheureusement pas Delphi de rester, comme en 2017, le langage qui vous traîne le plus dans la misère.

D'un autre côté, Go, TypeScript, Swift et VB.NET sont en baisse significative, bien que Go reste malgré tout un bon plan si la richesse est tout ce qui compte pour vous. 

Salaires par langages dans le reste de la France en 2017

« Très bien payés » ~ 4 700 €/mois	« Bien payés » ~ 3 700 €/mois	« Assez bien payés » ~ 3 100 €/mois	« Correctement payés » ~ 2 800 €/mois	« Mal payés » ~ 2 000 €/mois
Cobol	Scala, Perl	Abap, R, Go, Java, TypeScript	C, Python, Delphi, JavaScript, PHP, C++, Swift, C#	Ruby, WinDev, VBA, VB.NET

Ces chiffres confirment que les salaires en province sont moins élevés que dans la capitale, ce qui est probablement directement en rapport avec un coût de la vie plus bas.

Adepte des technologies du bon vieux temps qui ont fait leurs preuves ? Alors le Cobol vous rendra riche, puissant et adulé, mais seulement en Province. En région parisienne, le nombre d'offres de Cobol était largement insuffisant pour en déterminer un chiffre. Quant à Scala, c'est un très solide deuxième choix, qui vous offre l'avantage d'un très bon salaire partout en France.

Par rapport à Paris, Perl, R et Go se maintiennent également dans un très haut niveau de salaire, ce qui fait de ces trois langages un bon plan vers la fortune, quel que soit l'endroit où vous vivez.

Par rapport à 2017, le Cobol a vu une montée fulgurante dans le salaire proposé (presque le double, quand même). Perl aussi vaut bien plus que l'année dernière. Par contre le VB.NET n'est clairement plus un bon plan, changez de langage ou de région. 

Quel langage choisir alors ?

En définitive, si vous deviez choisir un langage à apprendre en fonction des offres d'emploi sur les cinq dernières années et des salaires proposés, voici ce qu'on pourrait en déduire :

• C n'est pas très populaire, mais la demande existera toujours grâce à ses caractéristiques sur le marché de l'embarqué ; mais cela ne se ressent pas sur la fiche de paie hélas.
• C++ reste populaire en tant que langage compilé en natif et vous trouverez toujours du travail avec, mais vous ne ferez pas fortune avec.
• C# est en perte de vitesse régulière, mais néanmoins vous ne devriez pas avoir de souci à vous faire avec cette technologie.
• Cobol en tant que technologie préhistorique est très peu demandé, mais quand il l'est, l'employeur n'hésitera pas à vous couvrir d'or, enfin en province en tout cas.
• D n'a pas le vent en poupe en ce moment ; le « dinosaure » C++ reste une valeur bien plus sûre.
• Dart ne semble pas prendre, si une alternative à JavaScript vous botte, TypeScript est clairement le choix à faire.
• Delphi semble remonter après une chute spectaculaire en 2015, mais c'est payé une misère. Vivre en province est un plus pour un Delphiste.
• Flash est une technologie morte sur le marché de l'emploi ; si vous êtes déjà en poste, restez-y, sinon reconvertissez-vous de toute urgence.
• Go voit sa demande faible, mais ça monte régulièrement, et surtout, ça paye très bien.
• Java est une valeur sûre : toujours le langage le plus demandé ; les salaires sont en revanche dans la moyenne, ce qui n'est pas surprenant, la main-d'œuvre est courante dans ce domaine.
• JavaScript est clairement une technologie d'avenir, qui pourra peut-être dépasser Java en demande un jour, bien que les salaires ne soient pas supérieurs pour Java.
• Objective C est en train d'être tué par Swift, son successeur ; pas le meilleur plan du moment.
• Perl n'est pas dans l'air du temps, mais il y a toujours de la demande, et les employeurs sont prêts à y mettre le prix. C'est le moment de postuler !
• PHP est un peu moins porteur que JavaScript et en particulier moins à la mode, mais vous trouverez sans problème un poste avec cette technologie.
• Python monte en popularité, cette compétence vous sera très utile, bien que cela ne vous permettra pas de faire fortune pour autant.
• R est de plus en plus demandé, et se paye excessivement bien ; si la science des données vous intéresse, foncez, c'est un vrai filon.
• Ruby voit sa popularité chuter ; néanmoins cela reste correctement payé, mais en région parisienne uniquement. Pas le meilleur langage pour commencer en 2018 en tout cas.
• Rust ne décolle clairement pas ; si vous souhaitez éviter de rouiller, multipliez vos compétences.
• Scala n'est clairement pas un langage courant, mais sa demande est supérieure au C et le salaire proposé ferait pâlir d'envie Bill Gates. Foncez.
• Swift progresse au détriment de l'Objective C, mais ce n'est pas l'eldorado, et le salaire ne sera pas terrible.
• TypeScript monte de plus en plus, mais le salaire proposé ne sera pas exceptionnel.
• VB.NET n'est pas le bon plan, moins demandé et largement moins payé ; si vous souhaitez rester en .NET, passez à son langage de prédilection depuis toujours, le C#.
• VBA est toujours demandé, mais est payé au lance-pierre ; regardez ailleurs si vous ne souhaitez pas finir sous les ponts.
• WinDev, toujours demandé, peut valoir le coup en région parisienne, mais le salaire en province est déprimant.

Naturellement, dans la « vraie vie », on choisit rarement un langage uniquement sur ces critères, mais c'est toujours quelque chose qu'il faudrait prendre en compte. Quel intérêt d'apprendre une technologie si c'est pour rester sur le carreau sur le marché du travail ? 

N'oubliez pas de consulter l'étude spécifique concernant les bases de données dans les offres d'emploi 2017. Voir aussi : Plus de 19 000 offres d'emploi développeurs et informatique. 

Vous pouvez également consulter la précédente étude sur la popularité des langages en 2016 ainsi que celle sur les salaires par langages en 2016. 

Que pensez-vous de ces statistiques ?
Votre langage favori est-il injustement déprécié par les employeurs ?
Êtes-vous payé à votre juste valeur ?
Seriez-vous prêt à changer d'emploi pour opter pour une technologie potentiellement mieux rémunérée ?

[Darkzinus]

Globalement, ces études sont toujours intéressantes. Ne serait-il pas mieux de mettre la rémunération en salaire brut annuel ? Je suis très surpris pour le salaire COBOL en province (à pondérer par rapport au nombre d'offres peut-être ?).

[Invité]

C'est potentiellement intéressant mais il manque tout de même une donnée fondamentale, tout est en pourcentage , mais l'étude porte sur combien d'offres d'emplois ? (ne me répondez pas 100 % !) Parce qu'entre 57 et 83 123 offres, il y en a une qui fait plus crédible que l'autre
Merci !

[wolinn]

Hum... un programmeur sur 200 est un coboliste (0.5%)
Si on pose que le salaire du coboliste de province apparaissant dans le second graphe est surtout une fluctuation statistique, parce qu'il n'est représenté que par quelques individus, je dirais que l'échantillon ne doit pas être très grand.
D'ailleurs, on voit aussi très bien que les fluctuations d'amplitudes des courbes des langages rares entre 2013 et 2017 sont nettement plus importantes que pour les langages plus courants, certainement pour la même raison : du bruit statistique.
Allez, ça m'étonnerait que l'étude porte sur plus de 2000 offres, et du coup, si c'est le cas, les fluctuations des belles courbes colorées ne valent peut-être pas grand chose pour les langages rares

[Jean-Philippe André]

Salut,

le combo C#/VB.NET devrait être mis sous la même bannière selon moi, car il est fréquent d'avoir une offre qui comporte un langage en vitrine, mais nécessite souvent son pendant dans le travail au quotidien

[Pierre Louis Chevalier]

Non l'étude montre bien que le gros de la demande sur DotNET est sur C# et pas sur VB.NET, le marché VB.NET c'est principalement quelques amateurs qui ont migré de VB6 à VB.NET, vu que VB.NET à été fait dans ce but uniquement et que le vrai langage destiné à DotNET est bien en C#, et c'est en C# que désormais Microsoft livre généralement ses exemples de codes pour DotNET.

Sur https://emploi.developpez.com on trouve :

- "C#" : 1431 résultats
- "VB.NET" : 153 résultats

C'est le même Framework mais ça reste deux langages différents. C'est important que les étudiants comprennent que s'ils veulent faire du DotNET en entreprise il faut qu'ils s’entraînent sur C# et pas VB.NET. Par exemple Unity 3D c'est C#.

[JCD_31]

En voyant ma situation et les gens autour de moi, je me dis que ces chiffres sont utopiques
diplome d'ingé + 8 ans d'xp en JAVA en province, je suis très très très loin de 3100€/mois! C'est peut etre l'effet SSII?

Globalement, ces études sont toujours intéressantes. Ne serait-il pas mieux de mettre la rémunération en salaire brut annuel ? Je suis très surpris pour le salaire COBOL en province (à pondérer par rapport au nombre d'offres peut-être ?).

Les experts COBOL sont souvent les rois du pétrole. Dans mon ancienne boite, les ingés + 10 d'xp en COBOL/DB2 tournaient autour de 5000€/mois, donc ces chiffres ne me choquent pas

[Kropernic]

Quand vous parler de xxxx€/mois, vous parlez en brut (ce qui est payé par l'employeur) ou en net (ce qui arrive dans votre poche) ?

[Darkzinus]

Quand vous parler de xxxx€/mois, vous parlez en brut (ce qui est payé par l'employeur) ou en net (ce qui arrive dans votre poche) ?

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

[Darkzinus]

Les experts COBOL sont souvent les rois du pétrole. Dans mon ancienne boite, les ingés + 10 d'xp en COBOL/DB2 tournaient autour de 5000€/mois, donc ces chiffres ne me choquent pas

Ca doit vraiment dépendre alors. Je ne connais personne dans cette situation.

[Marco46]

diplome d'ingé + 8 ans d'xp en JAVA en province, je suis très très très loin de 3100€/mois! C'est peut etre l'effet SSII?

C'est du brut. 3000 brut par mois ça fait 36KE. Même en province si tu es à 36KE avec 8 d'xp J2EE et un bac+5 tu ne peux t'en prendre qu'à toi même.

[kilroyFR]

Toujours etonné de voir C# presque 4 fois moins que Java meme si dans ma boite on a fait ce choix (C# pour raison historique C++/Windows), je suis toujours surpris et amer d'un certain coté de constater que beaucoup de choses reellement novatrices viennent tres souvent de l'environnement Java/Linux (containers, ORM, logger, etc.) qui eventuellement arrivent un jour sur C#.
Je n'ai pas connaissance de choses ayant passé du monde C# -> Java ?

Coté C#/Windows c'est bien souvent du portage de composants open sources java ayant fait largement leur preuve.
J'ai toujours le sentiment que coté monde Linux/java la communauté de dev est d'un niveau superieur quand on voit la qualité de ce qui est produit en OpenSource.

Maintenant a titre perso je suis sur java pour dev mobile android et c'est vrai que de ce coté là en tout cas, avec android studio c'est un bonheur de developper (question qualité IDE etc comparativement a ce qui existe sur windows).

[micka132]

Je n'ai pas connaissance de choses ayant passé du monde C# -> Java ?

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

Coté C#/Windows c'est bien souvent du portage de composants open sources java ayant fait largement leur preuve.

Il me semble normal que l'open source produisent plein de chose interressante vu qu'il y a des centaines de milliers de tentative. 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.

Maintenant a titre perso je suis sur java pour dev mobile android et c'est vrai que de ce coté là en tout cas, avec android studio c'est un bonheur de developper (question qualité IDE etc comparativement a ce qui existe sur windows).

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

[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.

[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.

[fiduce]

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.

Exactement. Je connais pas mal de gens qui on capuché sur .Net il y a longtemps (moi par exemple). Je l'ai redécouvert assez récemment (2 ans), mais qu'est ce que je suis content (1) d'avoir attendu ;-) et (2) d'être revenu.
Je trouve le dernier Visual Studio (2017) formidable (à coté d'un truc comme Eclipse) et j'adore le framework ainsi que le C# (vraiment un langage qui m'inspire : parfois j'ai envie de développer des projets rien que parce que le code serait cool).

[Invité]

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.

Oui, c'est la principale faiblesse de cette "étude". Elle ne présente aucunes données fixes (juste des pourcentages), ni un cadre des données analysées. Mettons que c'est comme le B.A.BA d'une étude.
Il est donc possible qu'elle porte sur seulement 45 offres et que cette analyse n'a donc aucune valeur crédible.

[redcurve]

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


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).



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

Le tout reste provoque des dégâts je le vois chez mon client actuel ou la meilleur solution est de passer par du wcf en netTcpBinging car REST est super lent (vive le json ...) pour du transfert de fichier, impossibilité de streamer les datas etc. Bref ils ont succombés à la mode du tout REST et maintenant ils ont très mal au cul.

Le plus drôle est Json Schema, pour créer un équivalent du WSDL après que toute la clique du web aient vendu json comme magique car pas de schéma ...

[moons17]

Le tout reste provoque des dégâts je le vois chez mon client actuel ou la meilleur solution est de passer par du wcf en netTcpBinging car REST est super lent (vive le json ...) pour du transfert de fichier, impossibilité de streamer les datas etc. Bref ils ont succombés à la mode du tout REST et maintenant ils ont très mal au cul.

Le plus drôle est Json Schema, pour créer un équivalent du WSDL après que toute la clique du web aient vendu json comme magique car pas de schéma ...

du REST pour du transfert de fichier ...ça sert plutôt pour des requêtes et création de ressource mais de la à faire du transfert de fichier ..
Json Schéma et Json .. comme qui dirait à la base pas possible de vérifier la cohérence des échanges ...à trop vouloir gagner du temps par rapport aux échanges en XML avec validation DTD et Schéma par exemple SOAP .

[redcurve]

Toujours etonné de voir C# presque 4 fois moins que Java meme si dans ma boite on a fait ce choix (C# pour raison historique C++/Windows), je suis toujours surpris et amer d'un certain coté de constater que beaucoup de choses reellement novatrices viennent tres souvent de l'environnement Java/Linux (containers, ORM, logger, etc.) qui eventuellement arrivent un jour sur C#.
Je n'ai pas connaissance de choses ayant passé du monde C# -> Java ?

Coté C#/Windows c'est bien souvent du portage de composants open sources java ayant fait largement leur preuve.
J'ai toujours le sentiment que coté monde Linux/java la communauté de dev est d'un niveau superieur quand on voit la qualité de ce qui est produit en OpenSource.

Maintenant a titre perso je suis sur java pour dev mobile android et c'est vrai que de ce coté là en tout cas, avec android studio c'est un bonheur de developper (question qualité IDE etc comparativement a ce qui existe sur windows).

Y'a des trucs que MS à passé de C++ à Java, exemple DryadLinq qui a été mis dans Hadoop il y a belle lurette. Et inversement C# sert de base pour la conception de pas mal de choses dans les nouvelles versions de C++ notamment les lambdas. Et ça marche aussi en sens inverse par exemple gsl::span Bjarne Stroustrup, le créateur du langage C++ et Herb Sutter qui bosse entre autre chez Microsoft ont conçus ensemble GSL qui se retrouve dans C# 7.2 avec les types Span<T> et Memory<T>.

Tu as aussi énormément de choses qui passent de .net à python et inversement une partie des dev de .net faisant partie de la core team python l'exemple le plus emblématique est la DLR. Tu as aussi l'un des principaux dev de Haskell qui fait partie de l'équipe .net, il a lancé le projet F#.

De C# vers Java tu as toute la partie lambda, l'équivalent de LINQ (dont j'ai oublié le nom en java) etc. Les dev java ont ajoutés le concept d'implémentation par défaut dans les interfaces qui va être repris en C# bref ça va dans les deux sens.

Il y a des trucs encore plus vieux comme les annotations (attributs C#) que MS à pondu pour J# un sur ensemble de java à l'époque

En fait tout ça est assez poreux en réalité ...