Avantages d'access uniquement comme interface, votre avis...

Bonjour,

J'ai eu l'occasion de réaliser un logiciel dont l'interface principale est en access mais la BDD sous PostgreSQL (j'utilise un ODBC). Un seul utilisateur utilisera l'interface access, les autres utilisateurs distants utiliseront quant à eux une interface web simple en php.
Je vais devoir défendre cette réalisation devant un Jury.
Voici les principaux avantages et inconvénients que je peux citer sur mon choix:

+++: possibilité de réaliser une interface conviviale et simple d'utilisation très facilement sous access
++: le fait de ne pas avoir créé la BDD sous access évite de rencontrer les problèmes fréquents d'access (chute des performances lors d'une utilisation par plusieurs users et lorsque BDD volumineuse)
++: possibilité d'utiliser la connexion ODBC même si l'interface en access ne se trouve pas sur le réseau de la BDD (ce ki n'est pas le cas avec BDD access)
++: interface simple en php permettra accessibilité à partir de n'importe quelle plate-forme, et ne devront pas posséder un progr spécifique

-- interface lourde + utilisation ODBC augmentera significativement les temps de réponses
-- risque si BDD volumineuse (même si non développée sous access) ???
-- Interface en JAVA aurait ête beaucoup plus performante?

Voilà, que pensez vous de ces arguments?
Voyez vous d'autres inconvénients que pourrait rencontrer ce choix? Auriez vous opté pour une autre méthode?

Effectivement, ça me semble un bon choix. C'est vrai qu'Access est lourd, mais comme interface pour une BD il est très pratique. De plus, pour ce qui est de la génération/impression d'états, c'est mieux que depuis une page web ! Ta solution me semble bonne; une autre possibilité aurait été de réaliser un VPN (extension sécurisée d'un LAN par Internet) pour que les utilisateurs distants puissent aussi utiliser l'interface complète en Access. Mais peut-être n'en ont-ils pas besoin.

Parmi les avantages d'Access, citons le fait que c'est un logiciel très répandu, et que ton "client" a la possibilité de modifier l'interface s'il le désire (par exemple, modification des états).
Parmi les inconvénients, Access nécessite une licence. Généralement les entreprises possèdent une licence Office, mais il faut que ce soit la bonne version, avec Access dedans (je crois qu'il existe une version "light" d'Office sans Access ? ).

J'ai un projet similaire en cours pour une PME, j'ai implémenté le serveur de données en open source sous linux, le site web en PHP et pour l'interface utilisateur j'envisage aussi de la faire en Access (bien qu'un intranet de base en PHP soit déjà en place).

Je pense qu'utiliser Access uniquement comme interface à un vrai serveur de données est une bonne façon de voir les choses :D

Personnellement, je sais qu'Access en tant qu'interface utilisateur avec SQL Server se fait facilement. Par contre, avec une autre base de données que SQL Server, je ne tenterais pas l'aventure. Je pense que rester dans le même environnement pour la base de données et l'interface, si possible en restant en langage natif sans passer par ODBC, peut éviter bien des problèmes. Ce n'est qu'un avis, avis qui me vient d'une mauvaise expérience avec Visual Studio / IBM DB2. Ton application est-elle finalisée ? Quels problèmes as-tu rencontré ?

Mon application est quasi finalisée.
Néanmoins, il me reste la dernière étape qui me permettra de voir les performances d'access: la migration de plus de 6000 enregistrements de personnes.
Si cela n'entrâine pas trop de ralentissements, je pense que la solution est à conseiller.

L'ODBC que j'ai utilisé (psqlODBC) marche nikel et toutes mes requêtes créés sous access fonctionnent correctement.

J'ai réalisé récemment un stage dans une grosse entreprise pharmaceutique, et ils utilisaient la même méthode, sauf que le SGBDR utilisé était Oracle (logique pour une grosse entreprise).

Je crois que l'argument de poids pour ce choix c'est réellement la facilité de créer des interfaces conviviales avec Access! En plus, ce choix m'a permis de réaliser facielement du publipostage avec Word...

Voilà, merci pour avoir émis vos commentaires
Bye

Je suis très content que ça marche bien pour toi car j'ai justement un projet que je comptais faire exactement comme toi, donc ça me conforte dans mon idée que c'est une bonne solution :D