Discussion :

[Anomaly]

Emploi développeur 2020 : les bases de données les plus demandées et les mieux payées
SQL-Server est le SGBD le plus populaire, suivi par Oracle et MySQL, mais Access est la base la mieux payée

Édition du 30 juin : suite à différentes remarques, l'étude a été refaite en incluant bien plus de bases de données.

L'année 2020 a été une année chaotique. Le virus, qui n'est pas informatique celui-ci, a fait pas mal évolué notre métier et la manière de l'exercer, en donnant un recours plus fréquent, et parfois imposé, au télétravail.

Mais est-ce que cela a pu affecter également les technologies sur lesquelles les développeurs travaillent ? Est-ce que les technologies qui payaient hier, payent toujours autant aujourd'hui ?

Nous vous proposons de découvrir les différentes technologies SGBD, basées sur les offres d'emploi postées en 2020 sur le portail Emploi de Developpez.com, spécialisé dans les offres d'emploi destinées aux développeurs et professionnels de l'informatique. Cette étude fait suite à quatre autres études réalisées les années précédentes. Celle-ci se situe en 2020, et donc concerne en particulier deux confinements et une année pleine d'incertitudes pour les employeurs.

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 2020 sur Developpez.com :

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

2019 a été le sacre de SQL Server en tant que SGBD numéro 1 dans les demandes d'emploi, et même si la tendance est plutôt à la baisse, le SGBD de Microsoft creuse en réalité l'écart avec son concurrent direct, Oracle. Le marché semble valider les grandes qualités de ce SGBD, que Microsoft a même pris la peine de porter sous Linux.

Si Oracle Database est toujours numéro 2, il est talonné par MySQL, autre produit de la même société. Si MySQL, qui était autrefois un produit indépendant, puis racheté par Sun avant d'être racheté par Oracle. Souvent décrié pour ne pas respecter à la lettre le SQL, il est néanmoins très utilisé, notamment dans le domaine du Web. Sa demande est actuellement en hausse, là où celle d'Oracle Database est en chute. Il est probable que les politiques d'audit agressive d'Oracle sur Oracle Database doivent être responsables en partie de cette désaffection pour le grand SGBD.

PostgreSQL n'est pas sur le podium, mais il se démarque significativement des autres en termes de parts de marché. Le SGBD open source respectueux des normes montre ici la plus forte progression de l'ensemble des SGBD.

MongoDB, champion en titre du NoSQL, n'est pas en forme en revanche. Si les années 2015 à 2017 ont montré un certain engouement pour le logiciel, la pression est redescendue depuis.

La base d'IBM se maintient globalement, son niveau étant significativement plus élevé depuis 2018, tandis que la base de données fichiers de Microsoft, Access, est dans une tendance descendante légère, mais constante, sur l'ensemble de la période étudiée. Enfin, MariaDB peine à percer face au géant MySQL alors que pour Sybase, la demande est extrêmement faible.

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 » ~ 5 000 euros	« Bien payés » ~ 4 500 euros	« Assez bien payés » ~ 4 000 euros	« Correctement payés » ~ 3 500 euros
Access	Hive, Teradata, DB2, MongoDB	Cassandra, PostgreSQL, MySQL, Redis	Oracle, SQL Server, ElasticSearch

Ce tableau est très intéressant, car il semblerait que l'adage est vérifié : ce qui est rare est cher, ce qui est commun est bon marché.

On retrouve ainsi Access sacré base de données en or, avec un salaire moyen atteignant des sommets et une première place incontestable. La base de données de Microsoft était déjà première en 2019, sa place est donc confortée, en contradiction avec sa popularité en berne.

MongoDB est deuxième dans le classement, là encore comme en 2019, mais cette fois-ci l'écart est particulièrement marqué à l'avantage d'Access.

La base de données d'IBM, DB2 est troisième, à un niveau à peine inférieur à celui de MongoDB. C'est donc une très belle remontée par rapport à 2019, où il était avant-dernier avec un salaire moyen plus bas de 1000 euros.

À l'autre bout du classement c'est SQL Server, le plus "mal payé", mais c'est 3 500 euros en moyenne tout de même, et au même niveau que l'année dernière, il faut donc relativiser. Oracle est avant-dernier ; c'est une chute brutale en revanche par rapport à l'année dernière. MySQL est troisième dans le trio de queue, miroir inversé donc de leur popularité.

PostgreSQL est au milieu de ce classement, à l'instar de l'année dernière, et avec un niveau de salaire intéressant. Mais c'est aussi le seul dont le bon salaire est associé aussi à une augmentation significative de sa popularité. On dirait bien que c'est le bon plan du moment.

« 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
Hive, Cassandra, Access	ElasticSearch, DB2, Teradata, Redis, MariaDB	MySQL, Solr, MongoDB, Oracle	PostgreSQL, SQL Server

Et en province ?

En province, on retrouve peu ou prou la même forme du classement que pour la région parisienne, bien que les différences soient bien plus lissées.

Seul Access se démarque vraiment en étant encore une fois en première place avec un salaire significativement plus élevé. Quant à PostgreSQL, l'exception parisienne ne se vérifie hélas pas.

En conclusion

SQL Server est encore une fois la base la plus populaire, mais aussi celle qui paie le moins en moyenne.

Oracle Database est en deuxième position, menacée directement par MySQL, autre base de la même société. Là encore, les salaires sont à l'inverse de la popularité.

PostgreSQL est la bonne surprise du classement. Elle a une très solide quatrième place, en progression, et les salaires suivent, en particulier à Paris.

Si DB2 est à la cinquième place, elle n'est qu'à 3,9 %. Cependant, sa rareté se reflète sans souci sur le salaire. C'est donc un très bon choix.

MongoDB est en très nette perte de vitesse, mais au moins le bon salaire proposé est une bonne consolation.

Access n'est pas beaucoup demandé, mais les recruteurs pensent qu'une telle compétence vaut de l'or. Un autre excellent choix. Il faut savoir aussi qu'Access est différent des autres SGBD, c'est censé être un produit "utilisateur final" contrairement aux SGBD comme SQL Server et Oracle dont l'usage est destiné aux informaticiens, par exemple les DBA , donc le fait que les salaires soient plus élevés pour Access est une sorte de paradoxe. L'explication est peut-être due à l'offre et la demande, peu de candidats, et donc surenchère des offres de salaires.

MariaDB est en petite forme, la base n'arrive clairement pas à s'imposer au niveau actuel du marché de l'emploi.

Sybase enfin, est actuellement mort au niveau des offres d'emploi.

Qu'en pensez-vous ?

Retrouvez aussi l'étude langage 2020, ainsi que l'étude base de données 2019.

[GLDavid]

Bonjour

Même si on parle de moyenne, je suis étonné de voir les salaires pour Access
Ouais, c'est utilisé mais tout de même, j'en reste baba. Autant je peux comprendre que Oracle et SQLServer propose une offre assez grande et que les salaires peuvent être grattés.
L'open Source est plus de la niche de mon point de vue donc, peu de demande, peu d'offre.
Mais pour de l'Access??? Je suis curieux de voir quelques échantillons d'offres.

@++

[GreatDeveloperOnizuka]

Bonjour

Même si on parle de moyenne, je suis étonné de voir les salaires pour Access
Ouais, c'est utilisé mais tout de même, j'en reste baba. Autant je peux comprendre que Oracle et SQLServer propose une offre assez grande et que les salaires peuvent être grattés.
L'open Source est plus de la niche de mon point de vue donc, peu de demande, peu d'offre.
Mais pour de l'Access??? Je suis curieux de voir quelques échantillons d'offres.

@++

Surement pour maintenir du legacy dégueulasse en Access. C'est un peu comme Cobol quoi

[Pierre Louis Chevalier]

Un DBA en grande entreprise ca fait plutôt de l'Oracle ou du SQL server, pas de l'Access.
Donc tu va trouver qui sur Access ? Les mêmes que ceux qui ont un poste de BI, des gens qui sont payés très cher pour faire un job que les autres informaticiens ne veulent pas faire, d'où la surenchère.

L'offre et la demande fait qu'on se retrouve à par exemple avoir parfois des développeurs de très bon niveau qui travaillent dans le secteur des jeux vidéos, mais très mal payés, avec énormément d'heures, largement plus de 35, et à l'inverse des techniciens bureautique (parfois des Bac+2 ) qui travaillent en entreprise au département gestion, par exemple sur Access, Windev ou des logiciels BI et qui sont payés très cher pour souvent bien moins de 35 heures effectives.

Sinon à part ça MongoDB ca commence à se tasser, fin de la hype pour le noSQL ?

[GLDavid]

Je pense que vous avez tous les deux raisons.
Pour GDO (t'as loupé ta carrière de Teacher ?), je vois tout à fait le genre: la base Access, jamais migré vers quelque chose de plus sérieux comme SQLServer, et qui est devenu critique au business.
Pour Pierre-Louis, il y a sans doute du vrai, je vois de mon côté pas mal d'IT guys plus payé à rien f...aire que de faire du vrai développement ou création, simplement à maintenir quelque chose de lourdingue, genre un PoC qui refuse d'évoluer.
@++

[GreatDeveloperOnizuka]

Je pense que vous avez tous les deux raisons.
Pour GDO (t'as loupé ta carrière de Teacher ?), je vois tout à fait le genre: la base Access, jamais migré vers quelque chose de plus sérieux comme SQLServer, et qui est devenu critique au business.
Pour Pierre-Louis, il y a sans doute du vrai, je vois de mon côté pas mal d'IT guys plus payé à rien f...aire que de faire du vrai développement ou création, simplement à maintenir quelque chose de lourdingue, genre un PoC qui refuse d'évoluer.
@++

Je continue à répandre la bonne parole des dév quand même en faisant prof à distance . C'est pour contrer les youtuber à la con qui disent gagner 500 balles/j tout en bossant depuis Bali en freelance avec une formation de 6 mois .

Sinon même si tu pars sur des poc ou autre maintenant, il n'y a plus aucun intérêt à Go access quand t'as des trucs style gratuit PostgreSQL ou MySQL ou encore des bases cloud PaaS.

Pour le noSQL, je pense pas que ça soit tasser mais plus une utilisation des environnements Cloud style CosmosDB plus pratique plutôt que te faire chier à installer toi-même un mongoDB.

[Pierre Louis Chevalier]

Je pense que vous avez tous les deux raisons.
Pour GDO (t'as loupé ta carrière de Teacher ?), je vois tout à fait le genre: la base Access, jamais migré vers quelque chose de plus sérieux comme SQLServer, et qui est devenu critique au business.

En fait Access c'est pas un serveur SQL, c'est surtout un générateur d'applications qui est censé permettre à un non informaticien de créer des formulaires, états, requêtes, etc. Le générateur de formulaires d'Access c'est une version plus simple de SQL Forms d'Oracle.
Dans les fait c'est faisable pour un non informaticien mais sur une seule table, ou peut être deux, dès qu'il y a beaucoup de tables la personne est généralement paumée, et c'est la qu'il faut faire appel à un bureauticien pour faire un truc qui marche correctement.
En fait Access est vraiment très bien fait au point que la concurrence ait été totalement éradiquée, du moins sur PC, : Paradox, Omis, 4D, etc. Le seul qui est arrivé à survivre à la vague c'est Windev, dans les PME en province.

Ce qui fait qu'Access doit être utilisé par des bureauticiens et non des utilisateurs finaux c'est le concept du multi tables, et ça aucun menu même hyper bien foutu ne pourra remédier au problème. Un schéma de bases de données multi tables bien foutu c'est fait par un DBA, ou un informaticien initiés aux bases de données (DUT info, MIAGE, ...) , pas pour un utilisateur final.

Donc Access étant surtout une couche applicative, en théorie les données peuvent êtres stockées sous SQL-Server, en architecture Client/Serveur, mais dans les fait c'est rarement le cas, c'est souvent de petites applications locale bricolées pour un service en particulier et c'est un stockage fichier Access parce que c'est le plus simple.

[GreatDeveloperOnizuka]

En fait Access c'est pas un serveur SQL, c'est surtout un générateur d'applications qui est censé permettre à un non informaticien de créer des formulaires, états, requêtes, etc. Le générateur de formulaires d'Access c'est une version plus simple de SQL Forms d'Oracle.
Dans les fait c'est faisable pour un non informaticien mais sur une seule table, ou peut être deux, dès qu'il y a beaucoup de tables la personne est généralement paumée, et c'est la qu'il faut faire appel à un bureauticien pour faire un truc qui marche correctement.
En fait Access est vraiment très bien fait au point que la concurrence ait été totalement éradiquée, du moins sur PC, : Paradox, Omis, 4D, etc. Le seul qui est arrivé à survivre à la vague c'est Windev, dans les PME en province.

Ce qui fait qu'Access doit être utilisé par des bureauticiens et non des utilisateurs finaux c'est le concept du multi tables, et ça aucun menu même hyper bien foutu ne pourra remédier au problème. Un schéma de bases de données multi tables bien foutu c'est fait par un DBA, ou un informaticien initiés aux bases de données (DUT info, MIAGE, ...) , pas pour un utilisateur final.

Donc Access étant surtout une couche applicative, en théorie les données peuvent êtres stockées sous SQL-Server, en architecture Client/Serveur, mais dans les fait c'est rarement le cas, c'est souvent de petites applications locale bricolées pour un service en particulier et c'est un stockage fichier Access parce que c'est le plus simple.

Au final ça revient à créer de la dette technique . De ce que je me souviens quand je faisais du Access il y a 15 ans, c'était surtout de petits trucs internes sans besoin de se prendre la tête avec une infrastructure. Par exemple, base de test, remplacer des tableurs Excel par un référentiel Access. Après en 2021, il y a tellement plus d'outils sympa que rester sur Access c'est se tirer une balle dans le pied . A l'heure où on parle de la "transformation digitale" dixit les marketeux, je veux dire .

[sergio_is_back]

MariaDB est en petite forme, la base n'arrive clairement pas à s'imposer au niveau actuel du marché de l'emploi.

MySQL / MariaDB c'est kif kif bourrico

Même s'il y a des différences, celui qui maitrise Mysql maitrisera facilement Mariadb, on y retrouve les mêmes concepts sous-jacents du fait que Mariadb est un fork de Mysql

De plus beaucoup de clients ne font pas la distinction MySQL/MariaDB pour eux c'est tout la même chose. Y'a pas longtemps un client me dit : "J'ai déjà un serveur MySQL on peut l'utiliser pour y monter le schéma de la nouvelle base de traçabilité", en fait c'était un serveur MariaDB... Y'avait pas d'importance ça a fonctionné tout pareil...

Je vois pas vraiment pourquoi faire la distinction entre les deux. Sur l'ensemble de mes clients qui utilisent ce type de DB j'ai environ 50% de MySQL (principalement pour des raisons historiques, les serveurs existaient avant le fork de MariaDB) et 50% de MariaDB (principalement de nouvelles installations, des clients qui n'ont pas de passif avec MySQL)...

[Pierre Louis Chevalier]

Sur le fond technique tu as totalement raison, sur la forme c'est de la RH et du Marketing : un RH met MariaDB sur une offre parce qu'on lui a dit de mettre ça, et cette étude est simplement basée sur les offres, et d'autre part d'un point de vue marché et Marketing ça a un sens de séparer MySQL (ca appartient désormais à Oracle pour rappel) de MariaDB parce que c'est deux éditeurs différents, et c'est une info qui risque d'intéresser aussi bien les vendeurs de solutions SGBD que les DI/DSI qui vont les acheter

Si on voie ce qu'Oracle a fait de ses acquisitions passées, par exemple Sun Microsystème, on peu se demander quel est l'avenir de MySQL sous le girond d'Oracle et si MariaDB c'est pas le vrai futur de MySQL.
Pour l'instant tout ce qu'a fait Oracle avec MySQL c'est de demander à ses commerciaux d'appeler tous les utilisateurs de MySQL pour leur faire payer une taxe, ou de migrer vers Oracle SQL, c'est pas très constructif, le résultat de cette politique c'est des migrations de plus en plus fréquentes de MySQL vers PostgreSQL ou MariaDB, et c'est exactement ce que montre le graphique de l'étude : MySQL en baisse (bravo Oracle) et donc PostgreSQL et MariaDB en hausse.

[chrtophe]

Je suis également surpris qu'Access soit mieux payé qu'Oracle qui demande quand-même plus de compétences.

Les compétences "évoluées" que demande Access c'est éventuellement le VBA, notamment pour lien avec les autres applis du pack Office, c'est la vraie valeur ajoutée d'Access. Miais je suis même pas sûr que c'est la rasion du meilleur paiement.

Et comme dit, pour un besoin réel de base de données, on peut lier Acces à SQL-Server.

[Derek Corgan]

Surement pour maintenir du legacy dégueulasse en Access. C'est un peu comme Cobol quoi

Oh la, je suis pas super spécialiste des sujets mais la comparaison me parait très exagérée.

Si je fais dans la caricature :
- Access = application développée par stagiaire (mais qui s'avère pratique donc qui survit)
- Cobol = application maintenue par scientifiques reconvertis dans l'info car les personnes qualifiées dans le domaine de l'info ne veulent pas y toucher.

Sur les dev Cobol c'est quand même + sérieux ! Surtout vu ce que cela fait. (Gros traitements de masse).

[commandantFred]

Vous connaissez mal Access...
C'est un RAD très complet qui peut encapsuler tous les serveurs (ODBC) et convertir leurs tables en tables locales adressables en SQL Access

Au Final , on peut jointurer une table Oracle avec une autre SQL server et même une table locale, tout en dynamique avec écriture de données partout.... Le tout avec des générateurs de forms et d'état de grande qualité. VBA ne rajeunit pas certes mais reste de bonne facture. Bon débugger.

Ensuite, Access n'est plus une BDD fichier , par défaut c'est un petit SQL server (format accdb) L'ancien format .mdb est toujours supporté pour compatibilité.

Evidemment , on peut ouvrir un .accdb sous .net et récupérer les jointures multi serveurs, mais pas les forms ni les états qui doivent être réécrits en .net.

Comme SQL fichier, je préfère nettement sqLite...


J'ai bossé sur Access aussi bien pour professionnaliser des applis bricolées par des non-professionnels, que comme outil de synthèse multi SI. Dans ce dernier cas, le résultat intéresse surtout la direction et autres VIP (stats, perfs, etc...). Je suppose que c'est la raison du salaire...

Par contre, Access est nul pour générer des interfaces graphiques. C'est son principal défaut selon moi : l'absence d'un controle picturebox.

[Pierre Louis Chevalier]

C'est un RAD très complet

C'est pas vraiment classé RAD, ce qui est classé RAD c'est des outils plus génériques comme par exemple Delphi, C++Builder, Lazarus, Windev, ...
Parce qu'Access n'est pas fait pour développer n'importe quel type d'applications, c'est juste une suite de générateurs ( création de bases, écrans, états, requêtes, ... ) pour les bases de données.

Au Final , on peut jointurer une table Oracle avec une autre SQL server et même une table locale, tout en dynamique avec écriture de données partout....

Oui un informaticien peut faire ça, un non informaticien ne sait même pas ce que c'est...

Je suis également surpris qu'Access soit mieux payé qu'Oracle qui demande quand-même plus de compétences.

Parce que justement c'est pas la compétence qui défini les tarifs mais la loi de l'offre et de la demande.
Parce qu'un developpeur top niveau n’a pas envie de passer des heures à peaufiner un formulaire de générateurs d'états et encore moins de passer du temps à faire du VBA, VBA il n'y a pas une super hype dessus, pourtant c'est très utilisé.

[commandantFred]

C'est pas vraiment classé RAD, ce qui est classé RAD c'est des outils plus génériques comme par exemple Delphi, C++Builder, Lazarus, Windev, ...
Parce qu'Access n'est pas fait pour développer n'importe quel type d'applications, c'est juste une suite de générateurs ( création de bases, écrans, états, requêtes, ... ) pour les bases de données.
Oui un informaticien peut faire ça, un non informaticien ne sait même pas ce que c'est...

Si, VBA est un langage complet , sa seule limite est le multithreading. J'ai écrit des programmes de dizaines de milliers de lignes avec.

VB 6 , dont il est directement issu a totalisé 55% du développement mondial à la fin du 20eme siècle.

on fait des choses d'une complexité infinie en VBA. Sous access, il excelle dans les forms et les rapports et est incapable de gérer un affichage type bitmap ou vectoriel. On peut contourner ça en linkant la librairie gdi.dll. Quoique perso, j'ai toujours préféré exporter du html/svg/xml...

.Ensuite , mes petites applis personnelles développées sous XP fonctionnent parfaitement sous win10. C'est quand même un composant Office, solidement maintenu, compatibilité sans faille, mis à jour de ses principaux défauts de jeunesse.
Certaines personnes n'ont jamais pu le considérer, pourtant, c'est un logiciel incroyablement puissant quand on a une dizaine de SI's à gérer en quelques heures. Le dernier n date était en Oracle, SQL server et MySql et même xBase++. Franchement, si vous êtes développeur, c'est incroyablement utile.
Je ne lui connais aucun équivalent, c'est un couteau suisse

[Pierre Louis Chevalier]

Si tu codes des applications en VBA c'est pas du RAD, c'est de la programmation.
Tu peux décider tout seul qu'Access est une sorte de RAD c'est ton droit mais c'est pas vendu comme tel par Microsoft en tout cas.
Si tu regardes les possibilités RAD que tu as par exemple dans Delphi, C++Builder, Lazarus ou même Windev ca n'a rien à voir avec Access qui ne propose que des services RAD très limités par rapport aux Rads plus génériques, du moins sur la partie Forms.

Franchement, si vous êtes développeur, c'est incroyablement utile. Je ne lui connais aucun équivalent, c'est un couteau suisse

Oui c'est bien foutu, c'est ce que j'ai écris plus haut, mais c'est une curiosité parce que à un moment donné c'est trop compliqué pour les utilisateurs finaux, qui ont tendance à rester tous Word et Excell mais Access c'est pas forcément à leur porté, au moins en multi tables, alors que pour les développeurs hardcore c'est trop limité, c'est entre deux. Même sur Microsoft, un développeur sera plus attiré par visual studio et C# ou C++ que Access et VBA.
Donc il y a de la demande sur Access dans les services de gestion, mais tous les développeurs ne s'y précipitent pas, d'où la surenchère de salaires.

[Antjac]

En fait Access c'est pas un serveur SQL, c'est surtout un générateur d'applications qui est censé permettre à un non informaticien de créer des formulaires, états, requêtes, etc. Le générateur de formulaires d'Access c'est une version plus simple de SQL Forms d'Oracle.
Dans les fait c'est faisable pour un non informaticien mais sur une seule table, ou peut être deux, dès qu'il y a beaucoup de tables la personne est généralement paumée, et c'est la qu'il faut faire appel à un bureauticien pour faire un truc qui marche correctement.
En fait Access est vraiment très bien fait au point que la concurrence ait été totalement éradiquée, du moins sur PC, : Paradox, Omis, 4D, etc. Le seul qui est arrivé à survivre à la vague c'est Windev, dans les PME en province.

Ce qui fait qu'Access doit être utilisé par des bureauticiens et non des utilisateurs finaux c'est le concept du multi tables, et ça aucun menu même hyper bien foutu ne pourra remédier au problème. Un schéma de bases de données multi tables bien foutu c'est fait par un DBA, ou un informaticien initiés aux bases de données (DUT info, MIAGE, ...) , pas pour un utilisateur final.

Donc Access étant surtout une couche applicative, en théorie les données peuvent êtres stockées sous SQL-Server, en architecture Client/Serveur, mais dans les fait c'est rarement le cas, c'est souvent de petites applications locale bricolées pour un service en particulier et c'est un stockage fichier Access parce que c'est le plus simple.

J'ai bossé au siège d'une grande banque au Luxembourg (en 2009, ça commence à dater). Le front était sous Access et la base de données en SQL Server.
C'était pour faire une solution de covoiturage pour le groupe. Le front Access n'était pas du tout adapté (franchement une solution web, même à l'époque, aurait été mieux) mais "fallait faire comme ça". En plus interdiction pour des raisons de sécurité d'utiliser des composants tiers...

[sergio_is_back]

Si tu codes des applications en VBA c'est pas du RAD, c'est de la programmation.
Tu peux décider tout seul qu'Access est une sorte de RAD c'est ton droit mais c'est pas vendu comme tel par Microsoft en tout cas.
Si tu regardes les possibilités RAD que tu as par exemple dans Delphi, C++Builder, Lazarus ou même Windev ca n'a rien à voir avec Access qui ne propose que des services RAD très limités par rapport aux Rads plus génériques, du moins sur la partie Forms.

Oui c'est bien foutu, c'est ce que j'ai écris plus haut, mais c'est une curiosité parce que à un moment donné c'est trop compliqué pour les utilisateurs finaux, qui ont tendance à rester tous Word et Excell mais Access c'est pas forcément à leur porté, au moins en multi tables, alors que pour les développeurs hardcore c'est trop limité, c'est entre deux. Même sur Microsoft, un développeur sera plus attiré par visual studio et C# ou C++ que Access et VBA.
Donc il y a de la demande sur Access dans les services de gestion, mais tous les développeurs ne s'y précipitent pas, d'où la surenchère de salaires.

Access est longtemps resté la base de données du pauvre... ...Et parfois aussi des incompétents... c'est peu être une des raisons qui fait qu'il a mauvaise presse...

Quand à tuer la concurrence, c'est la spécialité de M$, d'essayer par tous les moyens de phagocyter les produits concurrents quitte parfois à ouvrir le porte-monnaie pour racheter le produit et le laisser dépérir ensuite

Je ne compte plus le nombre de bases Access que j'ai éliminé au cours des années en déployant du MySQL, MariaDB, PostgreSQL, Firebird, et même du MSSQL Express, etc... Certaines étaient tellement mal foutues que j'ai galéré au maximum pour reprendre les données et les réinjecter dans une base avec une structure propre, je me souviens d'un client avec des fichiers .mdb, .accdb dans tous les sens sur des partages différents, des tables dupliquées partout avec des noms différents et les mêmes données dedans, avec des liaisons vers des classeurs Excel, une partie en VBA, l'autre en VB6, ça été l'enfer pour essayer de remonter tout et en faire quelque chose de cohérent...

[Glutinus]

Donc tu va trouver qui sur Access ? Les mêmes que ceux qui ont un poste de BI, des gens qui sont payés très cher pour faire un job que les autres informaticiens ne veulent pas faire, d'où la surenchère.

Ha bon, les gens ne veulent pas faire de BI ? C'est un beau métier pourtant

L'offre et la demande fait qu'on se retrouve à par exemple avoir parfois des développeurs de très bon niveau qui travaillent dans le secteur des jeux vidéos, mais très mal payés, avec énormément d'heures, largement plus de 35, et à l'inverse des techniciens bureautique (parfois des Bac+2 ) qui travaillent en entreprise au département gestion, par exemple sur Access, Windev ou des logiciels BI et qui sont payés très cher pour souvent bien moins de 35 heures effectives.

Je sais pas ce que tu entends par "logiciel BI" mais je peux te confirmer que :

La plupart des ETL font en "plus joli" (car souvent graphique) ce que fait du PL ou du Transact SQL, et souvent avec plus de temps de dev. Mais bon, l'avantage est de ne pas monopoliser le SGBD, surtout si elle est mal tunée. Mais globalement, en tant que développeur ETL (oui, je m'estime développeur), je fais quasiment tout en SQL ou PL/SQL sur Oracle, puis je "recopie" sur l'ETL graphique... en résistant aux insistances clients de carrément coller la requête (super utile de payer un ETL super cher juste pour copier-coller une requête...)

J'en ai fait un peu mon chemin de croix il y a quelques mois, mais concernant les outils de visualisations (reporting et/ou dataviz) ce sont des outils simplissimes, donc souvent comme tu dis à des jeunes développeurs, voire des jeunes sorties d'école de commerce.

On refile à ces juniors les tâches hyper importantes d'interviews utilisateurs et, pire, de modélisation de datamarts qui nécessite AMHA d'avoir lu quelques bibles et un peu d'expérience.

Il faut bien commencer quelque part, mais autant être l'assistant d'un confirmé qui transmettra son savoir-faire, surtout pour une tâche clé ou la moindre erreur est une catastrophe en terme de temps de développement, de maintenance (parce qu'il faudra revenir dessus sans cesse) et de performance (car on fera souvent des boucles inutiles, des produits cartésiens, des alimentations trop massives).

La vérité pour un outil de reporting est que, si le datamart est bien fait - en théorie, il est bien fait - le déploiement du reporting est très rapide et les aller-retours très souples. Mais ça, c'est dans le monde rêvé de Théorie... Je comptabilise trois missions de suite où je me suis proposé de faire les tâches d'interview et modélisation, mais évidemment on a envoyé des jeunes fringants de 23 ans en beau costard cintré

Je suis également surpris qu'Access soit mieux payé qu'Oracle qui demande quand-même plus de compétences.

Voir la méthodologie employée par Anomaly et l'équipe développée : si l'offre contient Access sur la BDD d'emploi de developpez, alors l'offre est comptabilisée. Rien que la dernière offre (Chief Security Officer) propose un salaire à 50K à 70K alors que la techno est mélangée parmi tant d'autres.

Donc Access étant surtout une couche applicative, en théorie les données peuvent êtres stockées sous SQL-Server, en architecture Client/Serveur, mais dans les fait c'est rarement le cas, c'est souvent de petites applications locale bricolées pour un service en particulier et c'est un stockage fichier Access parce que c'est le plus simple.

Comme tu dis, Access c'est une micro-base de données utilisée par une simple équipe, point-barre. Mes parents dans les années 90 m'ont poussé à utiliser la bureautique Microsoft Office : Word pour recopier mes nouvelles et poèmes, Excel pour gérer mon argent de poche, et Access - mais je ne l'ai pas fait - pour stocker le Hit-Parade Skyrock que je notais dans un carnet tous les dimanches matin. C'est parfaitement l'usage.

Pour la blague, Access était utilisé chez un gros client financier, mais comme base référentielle des produits uniques gérée par un seul gars, qui servait pour tous les environnements DEV, RECETTE, PROD.
le mec indélogeable, bien payé, très volontaire pour partager son savoir mais personne ne comprenait son modèle
et surtout, les directeurs des opérations, ceux qui sponsorisent notre projet, qui comprennent pas pourquoi quand ils lui demandent de modifier un produit ça lui prend 10 secondes mais nous modifier la règle de gestion ça prend deux semaines (et surtout pourquoi ils doivent tester, valider, et pourquoi leur mot de passe en prod ne fonctionne pas pour se connecter en UAT...)

[GreatDeveloperOnizuka]

Oh la, je suis pas super spécialiste des sujets mais la comparaison me parait très exagérée.

Si je fais dans la caricature :
- Access = application développée par stagiaire (mais qui s'avère pratique donc qui survit)
- Cobol = application maintenue par scientifiques reconvertis dans l'info car les personnes qualifiées dans le domaine de l'info ne veulent pas y toucher.

Sur les dev Cobol c'est quand même + sérieux ! Surtout vu ce que cela fait. (Gros traitements de masse).

Je ne dis pas que Cobol c'est mieux ou moins bien, je parlais d'en terme de business. De vieux trucs à maintenir et plus assez de personnes qui ont envie de faire ça, d'où une inflammation des salaires, prestations, etc.

Ha bon, les gens ne veulent pas faire de BI ? C'est un beau métier pourtant


Je sais pas ce que tu entends par "logiciel BI" mais je peux te confirmer que :

La plupart des ETL font en "plus joli" (car souvent graphique) ce que fait du PL ou du Transact SQL, et souvent avec plus de temps de dev. Mais bon, l'avantage est de ne pas monopoliser le SGBD, surtout si elle est mal tunée. Mais globalement, en tant que développeur ETL (oui, je m'estime développeur), je fais quasiment tout en SQL ou PL/SQL sur Oracle, puis je "recopie" sur l'ETL graphique... en résistant aux insistances clients de carrément coller la requête (super utile de payer un ETL super cher juste pour copier-coller une requête...)

J'en ai fait un peu mon chemin de croix il y a quelques mois, mais concernant les outils de visualisations (reporting et/ou dataviz) ce sont des outils simplissimes, donc souvent comme tu dis à des jeunes développeurs, voire des jeunes sorties d'école de commerce.

On refile à ces juniors les tâches hyper importantes d'interviews utilisateurs et, pire, de modélisation de datamarts qui nécessite AMHA d'avoir lu quelques bibles et un peu d'expérience.

Il faut bien commencer quelque part, mais autant être l'assistant d'un confirmé qui transmettra son savoir-faire, surtout pour une tâche clé ou la moindre erreur est une catastrophe en terme de temps de développement, de maintenance (parce qu'il faudra revenir dessus sans cesse) et de performance (car on fera souvent des boucles inutiles, des produits cartésiens, des alimentations trop massives).

La vérité pour un outil de reporting est que, si le datamart est bien fait - en théorie, il est bien fait - le déploiement du reporting est très rapide et les aller-retours très souples. Mais ça, c'est dans le monde rêvé de Théorie... Je comptabilise trois missions de suite où je me suis proposé de faire les tâches d'interview et modélisation, mais évidemment on a envoyé des jeunes fringants de 23 ans en beau costard cintré



Voir la méthodologie employée par Anomaly et l'équipe développée : si l'offre contient Access sur la BDD d'emploi de developpez, alors l'offre est comptabilisée. Rien que la dernière offre (Chief Security Officer) propose un salaire à 50K à 70K alors que la techno est mélangée parmi tant d'autres.


Comme tu dis, Access c'est une micro-base de données utilisée par une simple équipe, point-barre. Mes parents dans les années 90 m'ont poussé à utiliser la bureautique Microsoft Office : Word pour recopier mes nouvelles et poèmes, Excel pour gérer mon argent de poche, et Access - mais je ne l'ai pas fait - pour stocker le Hit-Parade Skyrock que je notais dans un carnet tous les dimanches matin. C'est parfaitement l'usage.

Pour la blague, Access était utilisé chez un gros client financier, mais comme base référentielle des produits uniques gérée par un seul gars, qui servait pour tous les environnements DEV, RECETTE, PROD.
le mec indélogeable, bien payé, très volontaire pour partager son savoir mais personne ne comprenait son modèle
et surtout, les directeurs des opérations, ceux qui sponsorisent notre projet, qui comprennent pas pourquoi quand ils lui demandent de modifier un produit ça lui prend 10 secondes mais nous modifier la règle de gestion ça prend deux semaines (et surtout pourquoi ils doivent tester, valider, et pourquoi leur mot de passe en prod ne fonctionne pas pour se connecter en UAT...)

J'ai connu ça mais chez moi donc c'était un référentiel de produits de test. Les états générés étaient assez simple. Même le schéma de la base était simple à déplacer, tu prends un stagiaire ou CDD en 2 mois c'est plié. Donc ici c'était pas trop grave. Là où ça fait flipper, ce sont vos témoignages sur des boites qui font limite un SI en entier dessus.

Et après pour la modélisation des bases, j'ai vu des merdes pondus par des pseudos experts de 20 ans d'XP donc ça veut rien dire pour moi .