Discussion :

[Anomaly]

Emploi développeur 2019 : les bases de données les plus demandées et les mieux payées


En ces temps de pandémie et de confinement, il peut être difficile de se projeter dans un nouvel emploi. Mais après chaque catastrophe, il y a toujours une reconstruction, un renouveau qui suit, et donc un besoin de main d'œuvre, donc gardez confiance ! Et c'est peut-être l'occasion, si vous avez la malchance de ne pas avoir d'emploi en ce moment, d'étudier les technologies qui vous permettront plus facilement de trouver un emploi, ainsi que celles qui payent le mieux.

C'est pourquoi je vous propose de découvrir notre étude complète annuelle sur les SGBD les plus demandés, et les salaires proposés, basée sur les offres d'emploi postées sur le Portail Emploi de Developpez.com. Cette étude fait suite à trois ans d'études du même genre réalisées au fur et à mesure des années ; celle-ci se base donc sur les données de l'année 2019, antérieure à la pandémie.

Méthodologie : nous avons pris l'ensemble des offres d'emploi postées sur le Portail Emploi et comptabilisé les annonces demandant chaque technologie. Dans le cas où une annonce demande plusieurs technologies (cas extrêmement courant), elle est donc décomptée pour chaque technologie étudiée, ce qui permet donc de dégager la demande globale pour chaque technologie, du moment qu'elle fait partie d'au moins une des compétences requises pour un poste. Notez également que la manière de déterminer les offres en fonction des technologies a évolué ce qui peut expliquer des petites différences sur les chiffres des années passées.

Voici pour commencer la popularité des différents SGBD dans les 20 000 offres d'emploi postées en 2019 sur Developpez.com :

Ainsi que l'évolution de la popularité des différents SGBD de 2013 à 2019 :

Finalement, cette année 2019 aura vu la courbe d'Oracle s'inverser. Et SQL Server voler à Oracle la place de numéro 1 des SGBD demandés dans les offres d'emploi.

Il semble bien que les efforts constants de Microsoft pour améliorer SQL Server année après année, au point même de le porter sous Linux, chose inimaginable il y a seulement quelques années, finissent par payer. D'un autre côté, Oracle commence peut-être à récolter les fruits de sa politique agressive d'audits envers ses propres clients.

MySQL reste en revanche, et de loin, le premier SGBD gratuit demandé, avec une très solide troisième place sur le podium. En effet, le très honnête et bien réputé PostgreSQL est en légère baisse, malgré un sursaut notable en 2017, et bien loin derrière MySQL.

Bien que le Big Data soit, en ces temps de pandémie, plus que jamais d'actualité, en 2019, sa personnification la plus connue sous la forme de MongoDB est plutôt en légère baisse globale. À moins qu'il s'agisse d'un début de constat d'échec du NoSQL par comparaison avec le système SQL classique éprouvé dans l'immense majorité des bases de données ? À voir si dans les prochains années si la tendance repart à la hausse ou pas.

Sinon, DB2 est actuellement plutôt en baisse. Sybase stagne, tout comme MariaDB, mais pour ce dernier, mais il reste assez proche de MySQL pour lequel il peut s'y substituer, il faut donc garder cela à l'esprit, les chiffres réels de MariaDB sont probablement plus élevés. Enfin, Access conserve sa position de manière plutôt insolente pour un SGBD "fichier".

Populaire ou pas, combien chaque base de données peut rapporter ?

La demande plus ou moins élevée d'une base de données par rapport à une autre est une chose, mais un autre aspect tout aussi important est ce que ça peut vous rapporter comme salaire. On dit souvent que ce qui est rare est cher, du coup est-ce que les technologies plus confidentielles rapportent vraiment plus, au prix d'une recherche d'emploi plus délicate ? C'est ce que nous allons voir.

Méthodologie : pour le calcul des salaires, nous avons pris la moyenne de la fourchette de salaires des offres d'emploi postées sur le Portail Emploi ; les valeurs clairement trop éloignées de la moyenne sont ignorées dans le calcul. Il s'agit donc bien de propositions de salaires, et non pas de salaires réels actuellement versés à des personnes, dont l'expérience et l'ancienneté peuvent être très diverses. Les salaires dans cette étude sont exprimés en euros bruts mensuels.

Pour commencer, voici les salaires moyens proposés en Région Parisienne.

« Très bien payés » ~ 4 500 euros	« Bien payés » ~ 4 200 euros	« Assez bien payés » ~ 3 500 euros	« Mal payés » ~ 2 200 euros
Access, MongoDB	Oracle, MySQL, PostgreSQL	MariaDB, SQL Server, DB2	Sybase

Le haut du podium, représentant les bases de données qui sont synonymes de rémunération élevée, est très intéressant, réunissant à la fois MongoDB, pilier du Big Data, dont la position élevée ne surprend pas, et Access, un produit très différent, qui n'est pas un véritable SGBD mais plutôt une base de données fichiers doublée d'un EDI. On ne pouvait en effet pas réunir deux éléments autant opposés l'un à l'autre.

Sinon, Oracle et PostgreSQL apporte une rémunération moyenne supérieure à celles proposées pour SQL Server et même pour la base spécialisée DB2. De même, MySQL propose une rémunération supérieure à celle proposée pour sa variante MariaDB. Quant à Sybase, elle est bonne dernière.

Et en province ?

« Bien payés » ~ 3 200 euros	« Assez bien payés » ~ 3 000 euros	« Correctement payés » ~ 2 800 euros
MongoDB, MySQL, PostgreSQL	MariaDB, DB2, Oracle	SQL Server

En province, les salaires sont moins élevés, sans surprise, mais ils sont également moins disparates. MongoDB tient le haut du podium, mais la plupart des bases de données ne sont pas très loin derrière, à l'exception de SQL Server, significativement moins bien rémunéré. Access n'est pas présent faute d'un nombre d'offres significatif.

En conclusion

Si nous devions nous forger un avis sur les différentes bases de données en fonction de leur popularité et leur salaire, voici ce qu'il en sortirait.

• SQL Server est le nouveau numéro 1 des bases de données en terme de demande, dépassant désormais Oracle. Les efforts de Microsoft pour populariser cet excellent système ne sont pas restés vains. En revanche, si la demande est importante, les salaires proposés sont plutôt quelconques.
• Oracle est maintenant numéro 2, mais la demande reste malgré tout élevée, et les salaires sont d'ailleurs supérieurs en moyenne que ceux pour SQL Server. Cela reste donc un excellent choix.
• MySQL est toujours bien demandé, et les salaires proposés sont même très décents. Comme quoi, on peut avoir des choses à redire sur MySQL, mais c'est une base qui reste plébiscitée et incontournable.
• PostgreSQL est largement moins demandé que les trois principaux, et les salaires proposés quasiment équivalents à ceux proposés à MySQL. La rareté ne paye pas forcément, néanmoins vous serez sûrement nettement moins nombreux au portillon lorsqu'un poste se présentera. C'est donc aussi un excellent choix.
• MongoDB est encore moins demandé que PostgreSQL, mais cette fois-ci, la rareté paie. Un choix des plus judicieux si vous souhaitez vivre à la fois dans l'air du temps (du Big Data) et dans l'opulence.
• DB2 est une base spécialisée des systèmes IBM. Cette année, il semble que sa relative rareté ne paye pas beaucoup, surtout à Paris. En province, ça va encore !
• MariaDB est beaucoup moins demandé que MySQL et également moins rémunéré globalement. C'est dommage, car cette base a beaucoup d'intérêts face à MySQL.
• Access est une particularité dans les SGBD, n'étant pas un vrai SGBD, mais une "simple" base de données fichiers doublée d'un EDI, et pourtant à Paris elle trouve le moyen de décrocher l'exploit du salaire moyen proposé le plus élevé. Il est intéressant de constater qu'une solution bureautique puisse permettre d'accéder à des salaires stratosphériques, quelque chose qui n'allait pas forcément de soi.
• Sybase est en perte de vitesse, avec une demande très faible et un salaire du même niveau. Ce n'est clairement pas le meilleur choix en ce moment.

De manière générale, la relation entre la demande d'une technologie et le salaire proposé s'explique le plus souvent par le jeu de l'offre (les demandeurs d'emploi dans une technologie) et la demande (la recherche de spécialistes d'une technologie sur le marché de l'emploi par les entreprises). Ainsi il y a très peu de demande Sybase, mais pas mal d'offre sur Sybase (= de développeurs Sybase sur le marché), du coup le salaire proposé est automatiquement déprécié.

Retrouvez aussi l'étude emploi 2019 sur les langages de programmation, l'étude emploi 2018 sur les bases de données ainsi que l'étude emploi 2019 sur les tendances.

Êtes-vous payé à votre juste valeur ?
Envisagez-vous de changer de SGBD en fonction de la demande ou du salaire proposé ?
Pensez-vous que les postes sur les SGBD les mieux payés méritent un tel salaire ?

[Matthieu Vergne]

Aurons-nous une étude similaire pour les langages de programmation ?

[Lung]

Aurons-nous une étude similaire pour les langages de programmation ?

https://www.developpez.net/forums/d2...s-mieux-payes/

[chrtophe]

Lien présent en fin de news.

[Matthieu Vergne]

Cool merci.

[Pyramidev]

Bien que le Big Data soit, en ces temps de pandémie, plus que jamais d'actualité, en 2019, sa personnification la plus connue sous la forme de MongoDB est plutôt en légère baisse globale. À moins qu'il s'agisse d'un début de constat d'échec du NoSQL par comparaison avec le système SQL classique éprouvé dans l'immense majorité des bases de données ? À voir si dans les prochains années si la tendance repart à la hausse ou pas.

Je pense que la majorité des utilisations de MongoDB sont le fruit d'un effet de mode et que la majorité de ceux qui l'ont choisi ne l'auraient pas choisi s'ils étaient plus forts en bases de données.

En ce moment, je travaille sur une application dont la base de données est en MongoDB. Même si MongoDB évolue pour inclure petit à petit des fonctionnalités des SGBD relationnels (left outer join avec $lookup, vues basiques, triggers depuis une version récente, etc.), je trouve ce SGBD encore trop primitif.

Quand on conçoit correctement une base de données, on essaie d'organiser les données de manière à ce qu'elles soient faciles à utiliser pour les fonctionnalités futures. C'est pour ça que, avec un SGBD classique, les données devraient généralement être découpées en plusieurs tables avec un nombre restreint de champs et surtout avoir des contraintes fortes en écriture pour que ces contraintes offrent des garanties sur les données que prendront en entrée les futures fonctionnalités. Il faut aussi éviter les redondances dans les données. Et si on veut améliorer les performances en lecture, on s'appuie sur des fonctionnalités comme les index, les colonnes précalculées et les vues matérialisées, qui sont un peu comme des données physiquement redondantes, mais pour lesquelles le SGBD garantit qu'elles sont à jour quand on les lit.

En MongoDB, on n'a même pas de contraintes FOREIGN KEY. Donc, si on veut découper une collection MongoDB (en MongoDB, ce qu'on appelle collection est l'équivalent d'une table SQL) en plusieurs, c'est la merde. Du coup, MongoDB encourage fortement à faire des collections obèses, chacune étant l'équivalent d'un résultat de jointures dans un SGBD plus classique. Bien sûr, le modèle de données est pensé pour les fonctionnalités prévues sur le moment. Et, plus tard, quand le besoin évolue, on pleure.

Il existe peut-être quelques cas où l'utilisation de MongoDB est justifiée, mais je pense qu'ils sont très minoritaires. Le reste du temps, le cheminement intellectuel doit ressembler à : « on est sur du Big Data, donc il faut du NoSQL, donc faisons du MongoDB, GOOO ».

[GreatDeveloperOnizuka]

Je pense que la majorité des utilisations de MongoDB sont le fruit d'un effet de mode et que la majorité de ceux qui l'ont choisi ne l'auraient pas choisi s'ils étaient plus forts en bases de données.

En ce moment, je travaille sur une application dont la base de données est en MongoDB. Même si MongoDB évolue pour inclure petit à petit des fonctionnalités des SGBD relationnels (left outer join avec $lookup, vues basiques, triggers depuis une version récente, etc.), je trouve ce SGBD encore trop primitif.

Quand on conçoit correctement une base de données, on essaie d'organiser les données de manière à ce qu'elles soient facile à utiliser pour les fonctionnalités futures. C'est pour ça que, avec un SGBD classique, les données devraient généralement être découpées en plusieurs tables avec un nombre restreint de champs et surtout avoir des contraintes fortes en écriture pour que ces contraintes offrent des garanties sur les données que prendront en entrée les futures fonctionnalités. Il faut aussi éviter les redondances dans les données. Et si on veut améliorer les performances en lecture, on s'appuie sur des fonctionnalités comme les index, les colonnes précalculées et les vues matérialisées, qui sont un peu comme des données physiquement redondantes, mais pour lesquelles le SGDB garantit qu'elles sont à jour quand on les lit.

En MongoDB, on n'a même pas de contraintes FOREIGN KEY. Donc, si on veut découper une collection MongoDB (en MongoDB, ce qu'on appelle collection est l'équivalent d'une table SQL) en plusieurs, c'est la merde. Du coup, MongoDB encourage fortement à faire des collections obèses, chacune étant l'équivalent d'un résultat de jointures dans un SGBD plus classique. Bien sûr, le modèle de données est pensé pour les fonctionnalités prévues sur le moment. Et, plus tard, quand le besoin évolue, on pleure.

Il existe peut-être quelques cas où l'utilisation de MongoDB est justifiée, mais je pense qu'ils sont très minoritaires. Le reste du temps, le cheminement intellectuel doit ressembler à : « on est sur du Big Data, donc il faut du NoSQL, donc faisons du MongoDB, GOOO ».

Il y a l'argument du si Google fait ça faut le faire aussi . Je trouve que la majorité des boites (surtout les PME donc) n'a même pas besoin de Big Data mais simplement d'un bon système de BI .

[Mat_MAT_BI]

Il y a beaucoup de branlettes et de fantasmes autour du big data..

C'est bien alimenté par les commerciaux qui vendent du rêve aux DSI..

Blablabla.. big data.. c'est génial.. blabla.. cloud mes cou**** blabla mongo DB..no SQL..python.. blabla...

[dfiad77pro]

Je pense que la majorité des utilisations de MongoDB sont le fruit d'un effet de mode et que la majorité de ceux qui l'ont choisi ne l'auraient pas choisi s'ils étaient plus forts en bases de données.

En ce moment, je travaille sur une application dont la base de données est en MongoDB. Même si MongoDB évolue pour inclure petit à petit des fonctionnalités des SGBD relationnels (left outer join avec $lookup, vues basiques, triggers depuis une version récente, etc.), je trouve ce SGBD encore trop primitif.

Quand on conçoit correctement une base de données, on essaie d'organiser les données de manière à ce qu'elles soient faciles à utiliser pour les fonctionnalités futures. C'est pour ça que, avec un SGBD classique, les données devraient généralement être découpées en plusieurs tables avec un nombre restreint de champs et surtout avoir des contraintes fortes en écriture pour ...

Totalement d'accord et trop souvent je vois des bases de données oracle qui sont merdiques coté conception de schéma, et qui font tout en pl/sql pour raccorder les morceaux, genre fausses jointure inter-schema.

bref aussi en relationnel si la structure (Tables, contraintes, indexes , vues) est pouris, faut pas s'étonner qu'on mette 1 minute pour lancer un select complexe. Et la pour pas optimiser ils nous sortent des surcouches no-sql qui sont très difficiles voir impossible à synchronizer pour du temps réel ( avec des surcouches de versioning EBR).
Sans compter qu'un bon dev de bdd doit aussi penser en vision ensembliste ...

et souvent l'excuse c'est ' oui mais le métier nous demande de sortir de chose rapidement', oui, mais quand le back est lent/complexe le front ralenti aussi, donc on perds à tout les étages

[SQLpro]

Il y a aussi un autre argument qui n'est pas mentionné dans l'article concernant la popularité de SQL Server.
C'est à ma connaissance, le seul SGBDR présent dans tous les segments horizontaux et verticaux :
1) en embarqué avec la version Local DB
2) en gratuit avec la version Express (certe limitée)
3) en web avec l'édition Web
4) pour les PME avec l'édition standard
5) pour les grandes entreprises avec l'édition Enterprise
6) dans le cloud avec SQL Azure, Docker et Kubernetes
7) intégrant les technologies du NoSQL (big table, document, graphe, KV)
8) dans le décisionnel avec SSAS/SSIS
9) inclant un outil de reporting (même Oracle n'a pas cela)
10) doté de technologies de pointe dans le décisionnel "real time" (même Oracle n'a pas cela)
11) intégrant le big data (data virtualization/polybase, hadoop/sparks, big data clusters...)

Plus fiable et sécurisé qu'oracle et bien d'autres SGBD... et bien moins cher que la plupart des concurrents

A +

[Invité]

Il y a aussi un autre argument qui n'est pas mentionné dans l'article concernant la popularité de SQL Server.
C'est à ma connaissance, le seul SGBDR présent dans tous les segments horizontaux et verticaux :
1) en embarqué avec la version Local DB
2) en gratuit avec la version Express (certe limitée)
3) en web avec l'édition Web
4) pour les PME avec l'édition standard
5) pour les grandes entreprises avec l'édition Enterprise
6) dans le cloud avec SQL Azure, Docker et Kubernetes
7) intégrant les technologies du NoSQL (big table, document, graphe, KV)
8) dans le décisionnel avec SSAS/SSIS
9) inclant un outil de reporting (même Oracle n'a pas cela)
10) doté de technologies de pointe dans le décisionnel "real time" (même Oracle n'a pas cela)
11) intégrant le big data (data virtualization/polybase, hadoop/sparks, big data clusters...)

Plus fiable et sécurisé qu'oracle et bien d'autres SGBD... et bien moins cher que la plupart des concurrents

A +

Alors toi aussi, fais confiance à sqlserver ! Et gagne 15% de réduction avec le code promo mssqlpro !

[Invité]

Alors toi aussi, fais confiance à sqlserver ! Et gagne 15% de réduction avec le code promo mssqlpro !

Travaille directement sur les bases de données et fais-toi une opinion
Essaie sérieusement MS Sql Server, Oracle et MySQL et reviens-nous !

[chrtophe]

Désolé, mais même si SQLPRO est pro-fanatique (à prendre sur le ton de la plaisanterie) MS-SQL, il sait de quoi il parle.

Et moi sur le terrain, TPE/petite PME, je ne vois que du Access ou du SQL-server utilisé avec des applis métiers, ne serais-ce que pour les produits grand-public type EBP/Sage, ça utilise SQL Server Express ou le SQL standard.

De par ça, que SQL-Server représente 30% des offres d'emploi comme le montre le camembert ne me parait pas abérent. Et les grands groupes auxquels je ne suis pas confrontés doivent l'utiliser ne serait-ce qu'un peu même quand ils utilisent d'autres bases.

Pour moi Oracle, c'est pour les grandes structures.

Il ne s'agit pas ici d’évaluer ce que vaut un produit, mais des possibilités d'embauche en connaissant/utilisant un produit ou un autre.

[Invité]

Et moi sur le terrain, TPE/petite PME, je ne vois que du Access ou du SQL-server utilisé avec des applis métiers, ne serais-ce que pour les produits grand-public type EBP/Sage, ça utilise SQL Server Express ou le SQL standard.
...
Il ne s'agit pas ici d’évaluer ce que vaut un produit, mais des possibilités d'embauche en connaissant/utilisant un produit ou un autre.

Sauf que l'étude indique que les meilleurs salaires sont pour mongodb ou mysql.

[yento]

ElasticSearch, Cassandra, RedShift, BigQuery? Les bases de donnees NoSQL les plus utilisees n'apparaissent pas?

MySQL et MariaDB devraient etre fusionne en MySql. Honnêtement personne fait la difference.

Relativement surpris que Oracle soit encore si haut place et relativement en hausse sur plusieurs annees. J'imagine que c'est parce que les gros projets sont fait a travers des SSII qui revendent du Oracle automatiquement.

[dfiad77pro]

Si oracle est encore si haut placé, c'est qu'on ne change que très rarement de BDD, surtout ci celle-ci est bourée de procédures stockés.
Et c'est très dur de migrer une grosse base de donnée dans ce cas

[chrtophe]

Sauf que l'étude indique que les meilleurs salaires sont pour mongodb ou mysql.

D'accord, mais là je parlais des offres d'emploi disponibles : SQL-Server représente 30% soit 1 tiers des offres, il en ressort que c'est la technologie qui te donne le plus de chances d'avoir du travail, et que c'est "correctement payé".

Si tu veux un meilleur salaire, tu peux investir sur MongoDB qui représente 5% des offres d'emploi et tu seras dans le statut "très bien payé", si tu arrives à te faire embaucher. Reste à voir l'écart entre l'offre et la demande (si très peu de candidats, tu as tes chances)

Pour MySQL qui représente 20%, je pense qu'il y un écart important de salaire entre travailler en agence web (mal payé) avec php-mysql et travailler sur des applis métiers (bien ou correctement payé) donnant la moyenne correctement payé.

quant à la "bizarrerie" sur Access, je pense qu'Access se trouve dans le statut "très bien payé" pas à cause d'Access, mais plutôt des compétences annexes demandées en plus d'Access.

[Glutinus]

ElasticSearch, Cassandra, RedShift, BigQuery? Les bases de donnees NoSQL les plus utilisees n'apparaissent pas?

Parce que ce sont des statistiques qui sont effectuées d'après les offres d'emploi de developpez.

[sergio_is_back]

Travaille directement sur les bases de données et fais-toi une opinion
Essaie sérieusement MS Sql Server, Oracle et MySQL et reviens-nous !

J'ai déjà travaillé avec toutes celles-là et même beaucoup d'autres (PostgreSQL, Ingres, Ingres II, DB2, Interbase, Firebird, GuptaSQL, etc...)
Chacune à ses avantages et ses propres inconvénients qu'il faut savoir parfois appréhender

C'est pas tout rose ou tout noir...

Après on comprend que SQLPro essaie de vendre sa soupe en tant que MVP Microsoft...

Plus fiable et sécurisé qu'oracle et bien d'autres SGBD... et bien moins cher que la plupart des concurrents
A +

Ça peut quand rapidement couter la peau des rouleaux....

Et j'ai quand même souvenir d'un crash d'un serveur MSSQL (même si le moteur n'était sans doute pas seul en cause, le système de fichiers NTFS de Windows Server l'a sans doute bien aidé aussi...)

[Mat_MAT_BI]

Toutes vos Bases de données new génération big data, ouais ça fait fun avec de la novlangue dégueulasse..

Mais une grosse entreprise veut minimiser les risques et ne pas bosser avec des éditeurs pignolos (la moitié des BDD big data n'existeront plus dans 10 ans..)

Là je travaille dans une banque, l'ETL en partie utilisé est ETI et OWB.

ETI a mis la clé sous la porte en 2006.. et toi tu fais comment ?

Soyons sérieux, dans la banque, le big data c'est seulement pour du parcours client sur le WEB...
Tout ce qui est réglementaire reste en oracle

Le big data ça sert aussi à compter le nombre de danettes vendues par intermaché , savoir si tartanpion a la côte sur les réseaux sociaux...
Compter le nombre de fois qu'on a cherché pangolin ou wuhan sur le web...