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

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 :

https://anomaly.developpez.com/artic...-sgbd-2019.png

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

https://anomaly.developpez.com/artic...-sgbd-2019.png

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. :roi:

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.

https://anomaly.developpez.com/artic...paris-2019.png

« 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
https://anomaly.developpez.com/article/01.png	https://anomaly.developpez.com/article/02.png	https://anomaly.developpez.com/article/03.png	https://anomaly.developpez.com/article/05.png
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 ?

https://anomaly.developpez.com/artic...vince-2019.png

« Bien payés » ~ 3 200 euros	« Assez bien payés » ~ 3 000 euros	« Correctement payés » ~ 2 800 euros
https://anomaly.developpez.com/article/02.png	https://anomaly.developpez.com/article/03.png	https://anomaly.developpez.com/article/04.png
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.

• :roi: 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.
• :roi: 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.
• :ccool: 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.
• :ccool: 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.
• :ccool: 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.
• :mrgreen: 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.
• :cry: 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.

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

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

Citation:

---

Envoyé par Matthieu Vergne

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

---

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

Lien présent en fin de news.

Cool merci.

Citation:

---

Envoyé par Anomaly

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

Citation:

---

Envoyé par Pyramidev

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 :mouarf: . 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 :mrgreen: .

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...:furieux:

Citation:

---

Envoyé par Pyramidev

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

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 +

Citation:

---

Envoyé par 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 +

---

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

Citation:

---

Envoyé par SimonDecoline

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 !

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.

Citation:

---

Envoyé par chrtophe

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.

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.

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

Citation:

---

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.

Citation:

---

Envoyé par yento

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.

Citation:

---

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

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

Citation:

---

Envoyé par SQLpro

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

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

Le big data ça sert aussi à compter le nombre de danettes vendues par intermaché :ptdr:, 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... :mouarf:

Une base de données a migrer c'est pas le plus compliqué...

Pour oracle c'est surtout le code applicatif en PL/SQL qui peut vite devenir une tannée lors d'une migration... Et qui freine beaucoup les ardeurs.

[Troll] de toutes façons les bases de données c'est terminé, tout sera en services managés dans le cloud tôt ou tard, plus rien à faire 8-) [/Troll]

Citation:

---

Envoyé par SimonDecoline

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

---

Mais pas forcément les meilleurs... Je crois qu'on peut dire beaucoup de choses d'Access et de MySQL, qui pourtant sont "bien payés"... ou du moins, ont des propositions élevés sur le portail emploi de Developpez... cela veut-il dire que les offres aboutissent sur un contrat avec cette rémunération ?

Encore une fois on peut avoir l'effet Cheval boiteux : Si c'est cher, c'est parce que c'est rare ; si c'est rare, c'est parce que personne ne veut en faire ; si personne ne veut en faire, c'est que c'est caca... (les administrateurs SharePoint sont chers parce que tous ceux qui y ont touché ne veulent plus y retoucher...)

Citation:

---

Envoyé par 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..)

---

Belle diatribe sur le Big Data, sachant qu'on en parlait très peu, c'était plutôt orienté base de données plutôt conventionnelles... S'il y a des offres MongoDB

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

Citation:

---

Envoyé par Mat_MAT_BI

Le big data ça sert aussi à compter le nombre de danettes vendues par intermaché :ptdr:

---

Heu non, on peut comptabiliser le nombre de ventes de danettes avec de la BI classique... sauf qu'il faut prendre en compte Honoré le Business Analyst qui passe son temps à faire de la lèche au client sans retranscrire son besoin... et Michel le modélisateur qui n'a jamais lu Kimball et ne sait pas faire son analyse par granularité... Et Kevin le pseudo-DBA qui n'a pas compris comment passer les scripts... Et surtout Hippolyte le commercial de SSII qui a dit "haaaa mais nous en un projet en deux semaines en big data on vous remet tous les rapports bien droits, bien corrigés, et en plus vous pouvez le faire en temps réel". Alors que bon franchement, le marketeux il veut vraiment savoir combien de danettes ont été vendues la demi-heure précédente ?

Citation:

---

Envoyé par Mat_MAT_BI

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

---

Wahou c'est une brocante ?!

T'as un petit DB2/400 et du SAS Mainframe pour compléter la collection ?

Avec un petit sap bo xi3, ou coheris harry pour la restit aussi :-P

Il y a aussi du cobol.. :scarymov:

le dwh de cette banque, c'est comme un paella géante, tout le monde se nourrit dessus et c'est une usine à gaz :mrgreen:

C'est mal organisé avec plein de chefs planqués qui n'y connaissent que dalle, ils sont montés à l'ancienneté..

Mon directeur de projet s'occupait des DAB avant :ptdr:

mais bon, on s'en fout car il y a votre pognon sur les comptes et il y en a plein :aie:

Citation:

---

Envoyé par Mat_MAT_BI

Il y a aussi du cobol.. :scarymov:

le dwh de cette banque, c'est comme un paella géante, tout le monde se nourrit dessus et c'est une usine à gaz :mrgreen:

C'est mal organisé avec plein de chefs planqués qui n'y connaissent que dalle, ils sont montés à l'ancienneté..

Mon directeur de projet s'occupait des DAB avant :ptdr:

mais bon, on s'en fout car il y a votre pognon sur les comptes et il y en a plein :aie:

---

Toute façon en informatique je vois 2 choses. Soit t'es un cador ou passionné donc tu passes freelance ou essaies de bosser dans de vraies boites d'informatique (éditeur, Gafa, etc.).
Soit t'es un lambda dans ce cas là essaie de développer tes compétences sur autre chose que l'informatique dans les autres boites. Tes compétences deviennent secondaires voir sans importance par rapport à la politique, le commercial, la suce, le fonctionnel, etc. De toute façon t'auras une armée de pisseurs de code en SSII dans ton budget si tu sais pas faire :mrgreen:

Citation:

---

Envoyé par DuyBinh

ou essaies de bosser dans de vraies boites d'informatique (éditeur, Gafa, etc.).

---

"Vraie boîte d'informatique" -> J'en croise de moins en moins et pourtant ça fait trente ans que je suis dans le métier !!

On croises des "Machin Chose Scientist", des "Truc muche Manager", des "Bidules Administrator".... Tout ce beau monde vend du rêve à prix cassé (enfin ça dépend)

Mais quand j'ai besoin d'un ou deux développeurs capables de me pondre une interface métier qui tient la route (dans un temps raisonnable, c'est à dire pas 18 mois pour une dizaine d'écrans) et répond au cahier des charges j'en trouve pas !

Citation:

---

Envoyé par frayou

Wahou c'est une brocante ?!

T'as un petit DB2/400 et du SAS Mainframe pour compléter la collection ?

Avec un petit sap bo xi3, ou coheris harry pour la restit aussi :-P

---

J'ai un client sous AS/400 et plusieurs avec du SAP, faut savoir s'adapter à son client...

Citation:

---

Envoyé par sergio_is_back

"Vraie boîte d'informatique" -> J'en croise de moins en moins et pourtant ça fait trente ans que je suis dans le métier !!

On croises des "Machin Chose Scientist", des "Truc muche Manager", des "Bidules Administrator".... Tout ce beau monde vend du rêve à prix cassé (enfin ça dépend)

Mais quand j'ai besoin d'un ou deux développeurs capables de me pondre une interface métier qui tient la route (dans un temps raisonnable, c'est à dire pas 18 mois pour une dizaine d'écrans) et répond au cahier des charges j'en trouve pas !

---

Quoi les SSII ont du mal à répondre à tes besoins? :mrgreen:

Citation:

---

Envoyé par DuyBinh

Toute façon en informatique je vois 2 choses. Soit t'es un cador ou passionné donc tu passes freelance ou essaies de bosser dans de vraies boites d'informatique (éditeur, Gafa, etc.).
Soit t'es un lambda dans ce cas là essaie de développer tes compétences sur autre chose que l'informatique dans les autres boites. Tes compétences deviennent secondaires voir sans importance par rapport à la politique, le commercial, la suce, le fonctionnel, etc. De toute façon t'auras une armée de pisseurs de code en SSII dans ton budget si tu sais pas faire :mrgreen:

---

Je peux te garantir que quand t'es freelance et que tu fais "la politique, le commercial, la suce, le fonctionnel, etc", t'es le roi du pétrole 8-)

Citation:

---

Envoyé par Glutinus

Je peux te garantir que quand t'es freelance et que tu fais "la politique, le commercial, la suce, le fonctionnel, etc", t'es le roi du pétrole 8-)

---

C'est vrai :D Après je pense que c'est plus chaud d'être freelance quand t'es une brêle techniquement dans l'informatique technique quand même :mouarf: . Enfin j'ai jamais vu de naze techniquement qui sont en freelance sur des domaines techniques encore. Evidemment j'ai déjà vu des managers freelance.

Citation:

---

Envoyé par SimonDecoline

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

---

C'est un paradoxe qui est à relativiser...

Pour mongoDB, le faible niveau de sa popularité (5%) induit fatalement une marge d'erreur importante au niveau des stats. Il suffit donc d'un seul salaire surélevé et la moyenne s'affole...

pour MySQL on trouve beaucoup de branleurs qui pensent savoir ce qu'est MySQL et qui sont bon à jeter à la poubelle. Je connais beaucoup d’entreprises qui nous sollicite nous experts et quand on leur dit qu'on ne fait pas, qu'on ne veut pas faire, ils sont obligé de monter les tarifs pour tenter de trouver les bons.... en vain, d'ailleurs ! Car ces stats ne sont pas les stats des salaires, mais des proposition de salaire ! la nuance est importante !!!

A +

Citation:

---

Envoyé par sergio_is_back

J'ai un client sous AS/400 et plusieurs avec du SAP, faut savoir s'adapter à son client...

---

Bah on s'adapte on prend le pognon, l'informatique c'est devenu tellement la foire du trône...

Tout le monde joue un rôle... entre Le client, le commercial de SSII, l'éditeur tout ça c'est une mascarade...

Faut le prendre a la rigolade... Je travaille actuellement actuellement sur un projet avec un nombre d'intervenants a peine croyable !!

Qu'est ce qu'on se marre entre l'éditeur qui essaye de caser tous les produits de son catalogue et quand ça bug n'a qu'une seule réponse : oui augmentez les ressources et raquez un peu plus lol, le grand cabinet de conseil qui fait le cadrage (débordement), le client qui comprend rien a ce qu'il se passe mais qui raque, les SSII diverses qui viennent placer du canasson pour croquer un morceau

putain on se marre bien !!!!!

Citation:

---

Envoyé par SQLpro

C'est un paradoxe qui est à relativiser...

Pour mongoDB, le faible niveau de sa popularité (5%) induit fatalement une marge d'erreur importante au niveau des stats. Il suffit donc d'un seul salaire surélevé et la moyenne s'affole...

pour MySQL on trouve beaucoup de branleurs qui pensent savoir ce qu'est MySQL et qui sont bon à jeter à la poubelle. Je connais beaucoup d’entreprises qui nous sollicite nous experts et quand on leur dit qu'on ne fait pas, qu'on ne veut pas faire, ils sont obligé de monter les tarifs pour tenter de trouver les bons.... en vain, d'ailleurs ! Car ces stats ne sont pas les stats des salaires, mais des proposition de salaire ! la nuance est importante !!!

A +

---

Ah bon? Si j'avais su, j'aurais faire une carrière de DBA MySql dommage :mouarf:

Citation:

---

Envoyé par frayou

Bah on s'adapte on prend le pognon, l'informatique c'est devenu tellement la foire du trône...

Tout le monde joue un rôle... entre Le client, le commercial de SSII, l'éditeur tout ça c'est une mascarade...

Faut le prendre a la rigolade... Je travaille actuellement actuellement sur un projet avec un nombre d'intervenants a peine croyable !!

Qu'est ce qu'on se marre entre l'éditeur qui essaye de caser tous les produits de son catalogue et quand ça bug n'a qu'une seule réponse : oui augmentez les ressources et raquez un peu plus lol, le grand cabinet de conseil qui fait le cadrage (débordement), le client qui comprend rien a ce qu'il se passe mais qui raque, les SSII diverses qui viennent placer du canasson pour croquer un morceau

putain on se marre bien !!!!!

---

On a fait une fois un projet comme ça (je ne nommerai pas l'éditeur ici) -> 5 ans après c'est toujours pas en golive
On s'est retiré du projet, on n'assure plus que la maintenance coté machine...

L'un des rares développeurs de cet éditeur qui tenait la route, c'est barré du projet au bout d'un an...
Le chef de projet est une brêle mais comme il est délégué syndical, personne ne peut le virer... Son seul discours consiste à rejeter la faute sur les autres intervenants...
Leur ERP est bourré de bugs et de fuites de mémoire, il a fallu multiplier par quatre la capacité du serveur AIX derrière pour avoir des temps de réponse inférieurs à 5s pour une simple requête avec une clé exacte
C'est une grosse bouse développé avec Sysbase PowerBuilder, des bouts en VB.NET en C#, des adaptations client en PL/SQL et quand ça plante personne ne sait où chercher...
Et il y a une armée de consultants et d'auditeurs au cul, je vous raconte pas !

Ben, et dBase III+ ? Et Foxpro ?
Ha mince, 2019.:ptdr:
C'était la touche humour.;)

Sinon il y des technos et des composants qui apportent une réelle plus-value à un SGBD. Je pense notamment à Exadata. On sort du métier exclusif dba mais les missions sont plus intéressantes et mieux rémunérées.

Une des raisons des disparités salariales est que, dès que tu es dans une technologie très demandée (donc avec tension sur le marché, tu as plus intérêt à être à ton compte et proposer tes services. Or ces stats en ne s'intéressant qu'auax offres d'emploi et non pas au marché offrent une vision tout à fait faussée.

En tant qu’expert SQL Server, je fais payer mes journées d'intervention en moyenne dans les 1 200 € (HT) hors frais de déplacement.... Et tous les experts SQL Server vous diront que leur carnet de commande est plein !

Aucune entreprise ne m'embaucherais si je demandais le même salaire que ce que je gagne. Il faudrait qu'elle aligne plus de 90 KF annuels !

En revanche je ne connais pas beaucoup d'expert MySQL... la presque totalité sont salariés !

A +

Citation:

---

Envoyé par 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..

---

de toute façon oui c'est bien connu.
Les éditeurs de solutions logicielles font croire aux entreprises que leur système informatique est devenu obsolète donc oui il faut vendre aux DSI des solutions un peu sur-dimensionnées pas forcément toujours pertinentes

Citation:

---

Envoyé par Mat.M

de toute façon oui c'est bien connu.
Les éditeurs de solutions logicielles font croire aux entreprises que leur système informatique est devenu obsolète donc oui il faut vendre aux DSI des solutions un peu sur-dimensionnées pas forcément toujours pertinentes

---

Du coup c'est de la faute des commerciaux ou des DSI qui sont à la ramasse et pas foutu de connaître les besoins de la boîte ou même de la direction tout court qui file un budget à la DSI qui se doit de l'utiliser sous peine de faire croire qu'elle branle rien ? :ptdr:

Citation:

---

Envoyé par Glutinus

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

---

Pour parler de ma banque. Officiellement Oracle est la seule base de donnée supportée et tout ou presque tourne sur Oracle.

Officieusement, la marorite des applications qui utilisent une base de données SQL sont sur Postgre ou MySql. Parce que le service interne Oracle met 6 mois pour fournir une base de donnee et n'importe quel projet qui en aurait besoin a du livrer depuis longtemps avec les moyens du bord. :ptdr:

Ca c'est pour la theorie et bien sur la pratique ne rejoint jamais la theorie.
En realite la banque d'investissement developpe ses propres bases de donnees distribuées (NoSQL) depuis plus de dix ans et c'est la dessus que les dizaines de milliers d'applications internes fonctionnent.

Il faudrait aussi connaitre les connaissances connexes requises pour être embauchées sur ces SGBD.
Par exemple :
SQLServer --> PowerShell
MySQL --> bash
MongoDB --> Nodejs
Oracle --> PLsql