Discussion :

[J1]

Bonjour,

j'ouvre ce topic pour savoir si, d'après vous, le développement d'applications Access en interne est encore possible de nos jours. Hors SSII, est-il encore possible d'être embauché en CDI par une entreprise en tant que développeur Access (pour répondre à ses besoins en interne) ?

Merci d'avance pour vos lumières !

[loufab]

Bonne question, et pas facile d'y répondre.

Quand on voit le nombre d'annonces on peut avoir de sérieux doutes quand à l'avenir professionnel sur cette techno.

Par contre ce qui est certain c'est qu'ACCESS reste le meilleur et le plus performant des RAD du marché. Y'en a t-il un autre ?

Avec de solides connaissances qui permettront d'éviter de tomber dans les pièges classiques on peut espérer que de plus en plus de sociétés choisissent cette techno pour des besoins internes.
En effet les points positifs sont :

• Un maquettage facile
• Un développement tout aussi rapide
• Un interfaçage à la plupart des SGBD du marché (si si ACCESS n'est pas un SGBD c'est JET qui en est un)
• Sa rapidité d'exécution sur des volumes moyens de données (avec JET)

Les points négatifs :

• Quelques problèmes dans les accès simultanés à forte charge
• Un manque flagrant d'outils de maintenance du code, de test unitaire... bref tout ce qui fait l'attrait d'un langage de dev classique
• ...

Les légendes urbaines :

• Tous les développeurs ACCESS et VBA en général sont associés à des bricoleurs/bidouilleurs sans réelle formation.
• ACCESS est un produit de la suite OFFICE donc forcément un produit de secrétariat
• N'importe qui peut devenir développeur ACCESS sans formation
• ...

En effet n'importe qui est capable de faire de la merde et ce avec n'importe quel langage. Comme n'importe qui est capable de briller en société avec des arguments non fondés.

Conclusion : Avoir plusieurs cordes à son arc c'est toujours mieux.

[jimbolion]

Comme dirais Loufab, difficile de répondre à cette question.

Mais force est de constater que la plupart des ERP offrent aujourd'hui des solutions évoluant dans le monde hébergé. En soi ce n'est pas simplement l'avenir de Access qui est en cause mais l'ensemble des applications dites 'clients lourd' (solution applicative et base de données hébergées sur le réseau local).

Un responsable veut aujourd'hui bénéficier de solutions nomades (se connecter chez lui), utiliser une tablette tactile dépourvue d'os parce que l’évolution du monde moderne l'impose. Access peut souffrir d'une image de développeurs-bidouilleurs mais comme l'aime à le rappeler Loufab : on peut faire de la m... avec le plus beau produit du monde et de la qualité avec trois fois rien (mais là n'est pas le débat).

Concernant l'avenir d'une solution bureautique Access, la volonté de M$ est bien d'étendre aujourd'hui cette solution au développement WEB via SharePoint et répondre ainsi aux sollicitations de certains utilisateurs et développeurs.

Reste que aujourd’hui l’accès à l'information est cruciale pour une entreprise et ce quelle que soit sa taille et qu'une panne d'internet peut avoir de douloureux effets sur l'activité économique d'une structure. Je pense que le marché va donc se segmenter en fonction des demandes et des risques encourus et qu'une petite entreprise aura encore envie de détenir l'information dans sa structure physique (les copies de sécurité étant hébergées par exemple : ne pas être non plus rétrograde).

Donc oui, le marché va évoluer mais je pense qu'Access a encore devant lui de belles années à vivre...

JimBolion

[J1]

Tout d'abord, merci pour vos réponses. Elles me rassurent un peu sur la pérennité d'Access mais ma question est un peu plus précise : peut-on encore se faire embaucher en tant que développeur Access en interne ?

Je sors d'une expérience de plusieurs années à cette fonction mais au bout du compte, mon employeur a fait le choix de supprimer mon poste pour raisons économiques. Je souhaiterais aujourd'hui reprendre un poste du même type, qui me permette d'établir une relation sur le long terme avec un même pool d'utilisateurs, connaître leurs besoins en profondeur, pouvoir répondre à leurs demandes de développement puis d'évolution, bref, tout ce que j'ai connu ces dernières années.

Mais je ne trouve que très (très) peu d'offres de ce type sur Access. Les ouvertures que j'ai sont plutôt avec des SSII, donc pour des missions à durée déterminée. D'où ma question : un poste de développeur Access en CDI à plein temps en interne, cela vous semble-t-il encore dans l'air du temps ou bien les développements de ce type passent-il désormais exclusivement par des SSII / de la prestation ?

[jimbolion]

J1,

difficile d'engager un avenir professionnel dans ton cas mais je bénéficierai vu ton expérience des acquis sous access pour évoluer vers des langages DOTNET (c# ou vb.net) et des bdd SQL-Server.

Mais cela n'engage que moi...

Jimbolion

[Jean-Philippe André]

Salut,

des postes purs développement Access ne courrent effectivement plus les rues. L'application en elle-même reste un excellent moyen de partir de "petit" pour évoluer vers des SGBD plus industriels (volumétrie, utilisateurs, accès à distance, etc.). Si tu vises ce marché pour évoluer en interne, il est plus que probable que les postes qui pourront t'être proposés auront un périmètre légèrement différent, comme par exemple du dev VBA de proximité (où tu toucheras aussi pas mal à Excel ou Word), ou des postes plus orientés Admin BDD.

Le marché étant ce qu'il est aujourd'hui, les demandes des entreprises étant tellement ponctuelles sur Access (moins d'un mois homme sur l'année) que le boulot est souvent proposé à des freelances.

Le créneau dev VBA Excel est quant à lui grand ouvert dans les banques

[User]

Bonjour à tous,

Pas grand chose à ajouter si ce n'est que ce type d'annonce n'a jamais été très fréquent aussi par le passé.

Peut-être à cause du point faible mentionné par loufab

[J1]

Un grand merci pour vos réponses.
Je ne note pas le sujet comme "résolu" car je n'exclus pas la possibilité de revenir poser d'autres questions liées.

[loufab]

non non et non ACCESS n'est pas un SGBD, c'est un RAD qui embarque son propre SGBD. On peut très bien utiliser ACCESS avec SQL Server, Oracle, Postgres...