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

Le , par Anomaly

222PARTAGES

25  0 
Nous avons le plaisir d'actualiser les études Emploi que nous faisons depuis deux ans. Quels sont les SGBD les plus demandés durant l'année 2018 ? Quels sont ceux qui rapportent le plus ? Comment la demande a-t-elle évolué depuis les années précédentes ? C'est ce que nous allons voir dans cet article.

Rappel au niveau de la 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 2018 sur Developpez.com :


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


Oracle, la base de données, gagne cette année la première place, tout juste devant SQL-Server. Les compétences dans ces bases de données professionnelles ont donc été particulièrement recherchées cette année.

Au contraire, MySQL chute brutalement de la première place qu'il avait acquis en 2014 vers la troisième. La demande en MySQL reste bien plus élevée que pour MariaDB. Concernant ce dernier cependant, il en faut pas oublier qu'il a été conçu à l'origine comme un remplaçant en "drop-in" de MySQL, même si au fur et à mesure des années cet adage n'est plus aussi vrai, les deux logiciels ayant de réelles divergences.

Loin derrière les trois ténors de la base de données, on trouve PostgreSQL dans une solide quatrième place. La performance de la base de données open source sont particulièrement encourageante. Enfin, en cinquième place, on peut retrouver le plus connu des bases de données orientée document, MongoDB. Cependant, après une apogée en 2016, la demande actuellement semble se tasser pour ce type de technologie.

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

Mais au fait, c'est bien beau de dire que certaines bases de données sont plus demandées que d'autres, mais au final combien cela rapporte ? 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.

Rappel au niveau de la 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 000 euros
« Assez bien payés »
~ 3 500 euros
« Correctement payés »
~ 3 250 euros
« Mal payés »
~ 3 000 euros
DB2
Oracle, Sybase,
MariaDB
PostgreSQL, MongoDB,
MySQL
SQL Server
Access

Et cette année encore, DB2 est la base de données qui vous rendra riche et puissant à Paris avec environ 4 500 euros mensuels proposés dans les offres d'emploi. Ceci dit, vous ne risquez pas de vivre sous les ponts avec Oracle, Sybase et MariaDB, qui vous proposeront 4 000 euros mensuels.

En bas du tableau, on trouve SQL Server de manière assez surprenante, mais c'est bien Access qui paye le moins. À sa décharge, Access ne joue pas dans la même cour que les autres.

La règle du « ce qui est rare est cher » se vérifie assez bien pour la plupart des bases de données, exceptés Oracle, très bien payé malgré le fait qu'il soit cette année le leader des offres d'emploi, et Access, qui malgré sa faible demande, reste véritablement payé au lance-pierres.

Et en province ?

En province, les salaires sont moins élevés, ce qui n'est pas surprenant, mais ce qui peut l'être davantage, est que les technologies les mieux payées ne sont pas les mêmes que celles des entreprises parisiennes. À croire qu'à lieu différent, besoins différents.

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

Cette fois ci, c'est MongoDB qui décroche la palme de la base de données la mieux payée en province. Ceci dit, DB2 n'est pas loin à une solide deuxième place.

Le résultat le plus surprenant est Sybase qui décroche une dernière place très nette, alors qu'elle est très bien placée à Paris. Au contraire, Access se défend bien en quatrième place par comparaison à son humiliation parisienne.

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.
  • Oracle est la coqueluche de cette étude ; non seulement c'est la base la plus demandée, mais les salaires proposés peuvent faire pâlir d'envie toute la profession.
  • SQL Server est aussi très demandé, mais malheureusement les salaires proposés sont décevants. Si ce qui est rare est cher, ce qui est commun est également bon marché.
  • MySQL est bien demandé, et mieux payé que SQL Server. Si vous deviez choisir entre les deux sur le seul critère de l'emploi, MySQL serait un meilleur plan.
  • PostgreSQL est une base relativement peu demandée, mais les salaires proposés sont dans la moyenne. Peut mieux faire, assurément.
  • MongoDB, malgré la hype autour du NoSQL, est plutôt rare. Le salaire moyen proposé est d'environ 3 500 euros sur l'ensemble du territoire, ce qui incite au haussement d'éauple sur Paris, mais qui se révèle dément en province. Si vous n'êtes pas de Paris et cherchez une base de données lucrative, c'est le filon du moment !
  • DB2 est la voie des futurs millionnaires, aussi bien à Paris qu'en Province, c'est la rançon de sa demande relativement faible.
  • Access paraît être un choix peu heureux à Paris. En province, c'est envisageable, mais il y a de meilleurs choix, sans le moindre doute.
  • MariaDB spécifiquement semble peu demandé, mais plutôt bien rémunéré à Paris, et dans la moyenne en province. En tout cas, cela ne sera pas un mauvais choix.
  • Vous aurez du mal à trouver un emploi avec Sybase, mais clairement c'est à Paris qu'il faut décrocher un tel poste, si vous ne souhaitez pas connaître la misère.
  • DB2 est une base de données relativement rare, mais elle vous assurera un avenir radieux et un compte en banque plein.
  • Sybase fait partie des base de données très rares qu'il vaut mieux pratiquer à Paris pour espérer un salaire convenable.


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

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 02/04/2019 à 19:19
La encore comme sur le sujet des langages, je trouve les resultats tres representatifs de ce que j'ai pu experimenter moi meme.
SqlServer ca paie pas pour un dev contrairement a Oracle ou un DBA s'en sort vraiment bien.
Les autres BDDs sont assez anecdotiques pour le coup et en particulier mongodb. Qui sait ce que seront ce type de BDDs exotiques dans 10 ans.
5  0 
Avatar de DuyBinh
Membre éprouvé https://www.developpez.com
Le 03/04/2019 à 11:20
SQL Server a l'avantage (ou le désavantage niveau blé ) d'être hyper user friendly donc même le dev lambda peut se démerder dessus. Pour Oracle, c'est quand même pas évident au début même si il y a des outils style SQL Developer ou Toad mais pour un newbie devoir se coltiner des config de tnsnames.ora, Tablespace et se retrouver sur SQL plus c'est pas forcément évident .
2  1 
Avatar de kilroyFR
Membre éclairé https://www.developpez.com
Le 04/04/2019 à 14:28
Citation Envoyé par DuyBinh Voir le message
SQL Server a l'avantage (ou le désavantage niveau blé ) d'être hyper user friendly donc même le dev lambda peut se démerder dessus. Pour Oracle, c'est quand même pas évident au début même si il y a des outils style SQL Developer ou Toad mais pour un newbie devoir se coltiner des config de tnsnames.ora, Tablespace et se retrouver sur SQL plus c'est pas forcément évident .
Tnsnames c'est une option dont tu peux te passer (surtout avec les outils cités);
Les tablespaces c'est pas plus abstrait qu'un filegroup sur sqlserver.
Je ne connais plus personne se servant de sqlplus en dev (a part pour derouler des scripts ligne de commande lors de deploiement de version).

Pour quelqu'un qui veut utiliser oracle sans se poser de question, un coup de Oracle XE et tout est deja preinstallé (meme une instance avec BDD prete pour le dev).
Pas plus compliqué que sqlserver express ou autre finalement.
0  0 
Avatar de DuyBinh
Membre éprouvé https://www.developpez.com
Le 04/04/2019 à 14:57
Citation Envoyé par kilroyFR Voir le message
Tnsnames c'est une option dont tu peux te passer (surtout avec les outils cités);
Les tablespaces c'est pas plus abstrait qu'un filegroup sur sqlserver.
Je ne connais plus personne se servant de sqlplus en dev (a part pour derouler des scripts ligne de commande lors de deploiement de version).

Pour quelqu'un qui veut utiliser oracle sans se poser de question, un coup de Oracle XE et tout est deja preinstallé (meme une instance avec BDD prete pour le dev).
Pas plus compliqué que sqlserver express ou autre finalement.
Voilà le "problème" les dév newgen sont du genre allergique à la BDD et au SQL je trouve, ils vont privilégier le code d'un langage (java ou autre) avec un ORM.
Sinon pour la "difficulté" (une fois la main dans le cambouis c'est pas vraiment compliqué), clairement Oracle XE c'est bien moins user friendly par rapport à SQL Server Express. Un mec lambda devra apprendre la notion de schéma et les droits qui vont y être associés. Dans un SQL Management Studio, ça se fait plutôt simplement avec un login que tu associes à ton user.

Maintenant regarde comment un utilisateur lambda sur SQL Server va faire une requête simple avec une date
Code : Sélectionner tout
SELECT * FROM MaTable WHERE DateConnexion = '13/12/2018'
ça peut passer direct sans que le mec se pose ce genre de questions (mon client est installé sur quelle région), il n'y a pas forcément besoin de spécifier le format de la date

Sur Oracle, il va devoir se taper la fonction to_date() sinon sa requête ne marche pas...

Je parle pas des trucs config de base qui évitent au mecs allergiques à la BDD de se prendre la tête sur SQL Server Management Studio (autocommit, les autocast quand tu fais id = '1' par exemple, le case insensitive sur les comparaisons de chaines, etc.)
2  0 
Avatar de 7gyY9w1ZY6ySRgPeaefZ
Expert confirmé https://www.developpez.com
Le 04/04/2019 à 15:15
Citation Envoyé par DuyBinh Voir le message
SQL Server a l'avantage (ou le désavantage niveau blé ) d'être hyper user friendly donc même le dev lambda peut se démerder dessus.
Malheureusement, c'est tellement friendly que certains se pensent rapidement devenus dba et jouent dans des paramètres et notions qu'ils ne comprennent pas...
Activer les paramètres Auto Shrink ou Auto Close sur une bd semble être une bonne idée dans l'absolu. Mais en fait, NON !
Le user SA utilisé à toutes les sauces et tout le monde qui en connait le mot de passe...
Ce qui est dommage, c'est qu'avec SSMS, l'aide contextuelle est directement accessible mais combien le savent ?
1  0 
Avatar de DuyBinh
Membre éprouvé https://www.developpez.com
Le 04/04/2019 à 17:38
Citation Envoyé par 7gyY9w1ZY6ySRgPeaefZ Voir le message
Malheureusement, c'est tellement friendly que certains se pensent rapidement devenus dba et jouent dans des paramètres et notions qu'ils ne comprennent pas...
Activer les paramètres Auto Shrink ou Auto Close sur une bd semble être une bonne idée dans l'absolu. Mais en fait, NON !
Le user SA utilisé à toutes les sauces et tout le monde qui en connait le mot de passe...
Ce qui est dommage, c'est qu'avec SSMS, l'aide contextuelle est directement accessible mais combien le savent ?
Perso je suis dev et pas DBA mais j'ai quand même une bonne connaissance par rapport aux dev lambda (Oracle SQL Server et Sybase), je parle bien dans ce topic des dev lambda. La plupart des PME n'ont pas forcément le fric et l'envie d'engager un DBA et souvent un informaticien style admin sys ou dev s'y colle. Ils vont pas se prendre la tête et vont y aller en mode rapide. Donc authentification windows sur la base et je pense pas qu'ils vont toucher à l'auto shrink ou auto close. Je suis même pas sûr qu'ils connaissent le principe de COLLATION .

La plupart du temps ça sera, une fois connecté à la base, je récupère les data via l'ORM style entity framework, hibernate et on bosse côté code dessus . Chez php/myadmin sur MySQL dans ma jeunesse c'était (à l'époque pas d'ORM) "SELECT * FROM MaTable WHERE nomp='" + &nom + "'" et tu fais un fetch à l'ancienne (me tapez pas, j'ai pas touché à PHP depuis 10 ans je suis pas du tout à la page )

Bref pour vous dire, plus un SGBD est compliqué à mettre en place (aux premiers abords), plus le spécialiste sera difficile à trouver, tirant le salaire vers le haut, d'où l'avantage des DBA Oracle (sans parler de l'historique qui existent en Oracle comparé à des database plus récent).
0  0 
Contacter le responsable de la rubrique Emploi informatique et développeurs

Partenaire : Hébergement Web