Bonjour,
 
Je dois mettre en place un helpdesk dans mon service. Cet helpdesk sera en fait une base de donnée avec des accès via le login de domaine windows, les demandes à cet helpdesk devra etre possible via des formulaires.
 
Pour le moment je vois 4 technologies différentes :  
 
PHP/MySQL
ASP/Access
Access
Lotus Domino
 
Pouvez vous me donner les avantages inconvénients de chaque solution. Pour info je n'y connais rien en programmation : donc je voudrais savoir la technologie qui permet une maitrise en un temps minime.
 
Merci à vous

Salut
D'abord sépare ta base de donnée de ton interface le choix de chacun doit être fait séparément.
 
Pour la base de donnée, un des choix est le budget ? ensuite le nombre d'entrée de la base et le nombres de connexion simuiltanée.  
MySQL : gratuit, et de bonne perf.
Access : inclu dans office dons quasi gratuit perf limité peut de client simultannée, si ton parc n'est pas très grand ça peut faire mais peut d'évolutivité possible
Lotus Domino, je connais trop peu je sais que ça marche que c'est galère à dévelloper mais c'est tout.
 
 
Après il faut que tu choisisse comment tu vas attaquer ta base de donnée. Un client lourd, ou un client léger(web)
en client lourd tu peut utiliser Access réalisation rapide et intuitive d'interface. Grace au pilote ODBC tu peut attaquer tout type de base comme oracle, mysql, as400.
VB, qui te permet de faire un client un peu plus évolué qu'avec access, fortionnalité avancé de connxion et autre.
 
En client léger tu as le choix entre plusieurs langage mais les 2 principaux sont PHP et ASP.
Tu attaques tout types de base avec les deux.
Avec ASP il te faut un serveur Windows ISS.
PHP serveur Apache/PHP sous windows ou linux.
Les deux sont gratuit.
L'avantage du client léger c'est qu'il est dispo de tout les postes du réseaux.
 
Un problème que tu va rencontrer c'est la connexion par login du domaine windows.
Il va falloir que tu attaques la base de ton controleur de domaine et que tu fasse une synchronisation avec ta propre base de compte régulièrement pour avoir un couple login/mdp toujours à jour.
 
Une solution intéressante:
BDD: MySQL ou MaxDB(en cas de treès grosse charge de la base)
2 type de client 1 lourd et 1 léger.
1 devellopé avec ACCESS pour commencer car rapide à dévellopper (Qquelque jours max).
Le second en PHP permettant une utilisation souple sur le réseaux.
 
Ensuite si tu as le temps rien ne t'empèche de reprendre le dev avec un langage plus évoluer(VB,C++,C#,java)
 
 
 
 
 
 
 
 
 
 
 

Si tu le fais en Access seul en tout cas: faire 2 fichiers MDB: un centralisé avec les données, pis un second en tant que client (formulaires, rapports, modules) qui référence la première DB). Mais peu évolutif et surtout très sensible à la charge

je crois pas qu'il aura les moyens de développer plusieurs clients  Un seul, et dans des temps de fou je suppose

c'est pour cela qu'il vaut mieux utiliser mysql comme BDD et n'utiliser Access que pour visualiser, modifier, insérer les données ou faire du reporting.

PHP marche aussi avec IIS.
(Si jamais c'est une contrainte imposée par la hierarchie...ça peut arriver)

par expérience, je n'aime pas du tout Access pour faire des interfaces. C'est très simple pour faire des trucs très simples, mais la difficulté croît exponentiellement quand on gratte un peu (j'ai déjà vu une application helpdesk en Access: c'était assez lent)
 
Si l'entreprise comporte un parc hétérogène de machines et d'operating systems, il n'y a pas à réfléchir longtemps: un webclient, à voir pour le choix d'ASP ou PHP ce qui convient le mieux.

Le probleme c'est qu'apparament, il a peu de temps et et peu de connaissance dans le domaine.
Une autre solution serait de voir les solutions existantes dans le domaine de l'opensource.
 
Il faudrait conaitre plus en détail ce qui est demandé.

d'autant que la maîtrise de n'importe quelle technologie, ça se compte en années et non en mois ou en semaines

Moi je pencherai plus pour la solution client léger web.
Et il me semble que tu peux récupérer éventuellement (au niveau des variables d'environnement, le compte d'utilisateur sur le domaine qui est connecté sur le poste.
Et en PHP/ASP tu peux éventuellement interroger ta base de comptes via LDAP pour faire la vérification. Donc pas de nécessité d'avoir une base de compte propre à l'application.

Oui mais pour faire ça faut pas être débutant et avoir du temps...

En même temps, un langage comme le PHP couplé à une base MySQL n'est pas des plus difficile à apprendre.
Un cahier des charges bien complet, une analyse des besoins super détaillée, après t'aura ptet plus de facilités à choisir la technologie à mettre en oeuvre. Et bien entendu, avant de te lancer à corps perdu dans le code source, tu fais une bonne analyse au niveau de ta base de données.
Le codage derrière ensuite c'est plus qu'un travail de traduction et de concrétisation du travail en amont du projet.

Est il possible d'utiliser un document excell comme client lourd ?
 
Dispo via un lien de l'intranet, les gens pourront renseigner des champs et via un bouton envoyer qu isera dans le formulaire les info se rajouteraont dans la base de donnée ?

 
Quitte à passer par un intranet autant utiliser un formulaire html pour renseigner ta base.
Car passer par un fichier excel c'est la meilleure façon d'avoir des incoérenssence dans ta base.
Ensuite le jour ou tu veux faire évoluer ton truc tu es bloqué par toute les anciennes version qui se balade sur les poste de ton réseau.
 
Ensuite excel ce n'est vraiment pas le frontend idéal, fait un module en VB à la limite tu ira bcp plus vite qu'avec excel.

 
MySQL + formulaire HTML sous access est il une bonne base de départ ?

MySQl comme base centralisé et Access comme frontend c'est possible.
Par contre formulaire HTML dans ACCES c'est impossible, ACCESS n'est pas un navigateur web....
 
Si tu veut une solution pour ton truc donne nous la structure que tu veux, centralisé ou non, combien de client attaque la base, qu'système pour se connecter Windows ou Linux les 2?
 
Et surtout donne nous ton niveau en informatique en programmation et en base de donnée.