Quel langage pour une petite appli de gestion.

Bonjour,

on me demande de faire une petite application pour gérer les médicaments pour les patients en fonction de leurs maladie.
L'appli doit allez chercher dans une base de données le nom du médicament en fonction de:
- Du patient
- De la maladie

L'appli doit avoir une base de données intégrée et oui les médecins ne veulent pas gérer un serveur type SQL.

En plus l'appli si elle est de type n-tiers peut rentrer de le cadre de ma formation pour le projet de fin d'année.
En effet, je suit une formation de concepteur développeur informatique.
N'ayant pas de "vision objet" je galère un peu, mais avec ce type de projet, je pense progresser.

Sinon autre petite contrainte.
L'appli dois fonctionner sous Windows et Mac ( à confirmer) je pensais donc à Java.

Je vais avoir prochainement plus de détails sur les demandes précises concernant cette application ( ce qu'elle doit faire, mais en gros c'est cela peut ^tre quelques modalité de recherche supplémentaires mais rien de plus).

Et en ce qui concerne la base de données que prendre sachant qu'elle doit être intégré à l’exécutable.

Merci beaucoup pour votre aide

Citation:

---

Envoyé par juninho

N'ayant pas de "vision objet" je galère un peu, mais avec ce type de projet, je pense progresser.

---

pour un projet d'application avec base de données c'est pas forcément nécessaire de faire des objets métiers à tout bout de champs
Si tu as une table client par exemple, créer une classe client dans le code source n'est pas forcément nécessaire parce que toutes les données sont dans les tables du SGBD.
Ceci dit l'avantage de créer une classe client c'est que ça permet de charger les données de la table en mémoire.
Mais tu perdras l'intérêt de faire des sélections des données grâce au SQL
Sinon pour répondre à la question, Ms Access est un outil formidable qui permet de simplifier les développements pour des petits projets.

Pour un développement sans prise de tête, compte tenu de la taille de la base (2 tables de taille probablement relativement modérées), Access peut effectivement faire parfaitement l'affaire.

Dans le cadre d'une formation, il peut être intéressant de regarder comment interfacer un langage quelconque avec une base de données quelconque. Ce type d'applications se rencontre très fréquemment et un cas simple comme celui-ci est une bonne opportunité pour regarder comment cela s'organise (objets métiers et tout le tintouin) même si, comme le fait remarquer Mat.M, ce n'est pas indispensable ici.
Par exemple :
langage python, base de données Postgresql
Python est un langage objet très polyvalent et simple d'accès (Java est beaucoup plus compliqué à aborder mais reste un bon choix compte tenu de ses performance et de son utilisation).
Postgresql est un très bon moteur de base de données

Pour quelque chose de plus orienté web, il est possible de faire du php/mysql. N'importe quel fournisseur d'accès supporte ces deux outils.
Pour ma part, j'aime beaucoup moins php que python.

Sinon, pour une base de données hypersimple à gérer avec n'importe quel langage, il y a sqlite.

Amuse-toi bien,

Bonjour,

merci pour toutes vos réponses.

J'ai plus de détails sur les demandes.
Il s'agit donc d'une application de gestion des médicament sur laquelle intervienne des pharmaciens, médecins coordinateur de centre Epad.

En ce qui concerne l'application
1: Il faut une fenêtre d'accueil avec pleins de boutons porttant le nom de spécialités ( ORL, Cardiologie...)
2: Une fois que l'on à cliquer sur le bouton de la fenêtre précédente, on arrive sur une autre fenêtre ( ou onglet) dédié à la spécialité
3: Sur cette fenêtre s'affiche le contenu des médicament susceptible d'être prescrits pour les soins.
La base de données contient, le nom du produit, la molécule, contraintes*( voir plus bas), commentaires, type de produit ( en gouttes, comprimés...) et d'autres éventuellement.
4: Il faut que le médecin clique sur la ligne du datagrid ( si .net ou équivalent dans d'autre langage), une alerte de type warning Windows s'affiche avec un message ( exemple: Attention adaptation posologie pour cause de risque cardiaque...).
Ces messages diffèrent selon le médicament, la pathologie du patient.
5: Une mise à jour, suppression et ajout de médicament doit être possible à partir de la page de visualisation.

La base de données doit être incluse dans l'application de préférence, mais une base externe est possible .

6: Fonction de recherche de médicament par pathologie, nom, type de produits... .


Voilà, que me conseillez vous ?

Merci

Je reste sur ce que j'ai évoqué précédemment.

Le choix dépend en premier lieu de l'utilisation qui sera faite de ton application.
Si tu as plusieurs utilisateurs qui seront amenés à utiliser ton application, le mieux sera sans doute de te tourner vers une application web.
Cela en simplifiera l'administration en évitant d'avoir à l'installer sur tous les postes.
Dans tous les cas, de toute façon, il faut que la base soit partagée : sinon, si plusieurs personnes peuvent la modifier, c'est un vrai problème et sinon, à chaque évolution, il faudra la mettre sur chaque poste.

Donc, pour ma part, je partirais vers une solution web
L'installation initiale sera un peu plus compliquée (serveur web, serveur de base de données) mais ensuite, tout sera plus simple, notamment le déploiement puisqu'il suffira d'avoir un navigateur pour accéder à l'application. Par contre, il faut être conscient que l'interface sera moins riche qu'avec une application client serveur (encore qu'avec javascript, on peut faire des trucs très bien)

Comme langage, j'utiliserais php ou python (ou ruby).
php est plus classique et très facile à mettre en oeuvre n'importe ou (les serveurs web le prennent toujours bien en compte)
python n'est pas aussi classique mail je préfère de loin le langage en lui même. Je trouve php assez sale (opinion personnelle qui ne doit pas t'influencer plus que cela).

Comme base, postgresql ou mysql.
sqlite te permettrait d'embarquer plus facilement la base (puisque c'est un fichier) mais si plusieurs personnes sont amenées à intervenir simultanément, tu risques d'avoir des soucis.

En tous les cas, ne néglige pas la modélisation de la base.
La base de données est l'équivalent des fondations de ton application et si les concepts sont bien apparents au niveau de la base, il te sera plus facile de bien organiser ton code.

Tu trouveras plein de conseils sur la modélisation dans les sections adéquates de ce site...
Par exemple : http://cyril-gruau.developpez.com/merise/

Bonjour,

merci pour la réponse.
J'avais moi aussi penser à une appli web, mais ils ne veulent pas ! :calim2: :aie:

Il veulent quelque chose "installable à la Windows "...

Un truc m'échappe :
(1) L'appli doit tourner sur plusieurs postes - donc avoir des utilisateurs simultanés.
(2) L'appli, depuis chaque poste, doit pouvoir mettre en place un référentiel unique(si j'ai bien compris le point 5).
(3) L'appli n'a pas le droit de se connecter à un serveur central(si j'ai bien compris le premier post).

Le point (3) est clairement incompatible avec le point (2), et pose aussi des problèmes avec le point (1). Si on veut que le travail du docteur Bertrand soit visible par le docteur Bernard, il FAUT des données centralisées. Donc un serveur. SQL ou pas, peu importe, mais un serveur centralisé. Sinon, JAMAIS le PC du docteur Bernard ne pourra voir les modifications du docteur Bertrand.

(à moins de mettre en place une mise à jour permanente et systématique des référentiels locaux entre eux, mais c'est vraiment aimer se faire mal, genre il faut gérer les timestamps de mises à jour dans chaque base, prendre en compte les plus récents en comparant tous les ordinateurs connectés, bouffer des ressources réseau comme c'est pas possible, risquer en permanence la désynchronisation.....franchement, à oublier, c'est plus que pourri, cette idée).

Soit je n'ai rien compris, et chaque installation peut être indépendante, et il n'y a même pas besoin de se faire chier avec une base de données : un simple dump mémoire comme sauvegarde suffit à la permanence des données(et on échappe à l'eternel emmerdement du lien base-objet). Soit j'ai bien compris, et les informations doivent être partagées, et on ne fera pas l'économie d'un serveur, quels que soient leurs cris d'orfraie, et donc il faut s'assoir sur la partie "ne veulent pas gérer un serveur type SQL" des specs. On est pas obligé de faire du SQL, on peut faire du NoSQL, ou même des fichiers plats à accès concurrentiel(c'est risqué quand même, hein, je cite juste parceque c'est théoriquement possible), mais on est obligé d'avoir un serveur central pour les données centrales.

D'après ce que j'ai compris, ils sont plusieurs à vouloir utiliser l'applications.
Combien ?
Veulent-ils une base partagée ou chacun la sienne ?
Dès lors où il y a des données partagées, il y a forcément une installation sur un serveur.
Si les données ne sont pas partagées, les problèmes de synchronisation vont inévitablement se poser, le déploiement et la maintenance de l'application vont rapidement devenir un cauchemar, surtout s'il y a plus de 5 ou 6 utilisateurs.

Quel est leur argumentaire pour une installation à la windows (savent-ils ce qu'il veulent) ?
Pour ma part, ça fait presque 20 ans que je bosse en informatique dont la moitié en SSII et je n'ai encore jamais fait d'application "installable à la windows".
Je conçois bien ce type d'installation pour une application autonome monoutilisateur, par contre, pour une application avec plusieurs utilisateurs simultanés, je suis dubitatif (mais peut-être des habitués de ce type d'installation pourront-ils me contredire).
Ont-ils un exemple d'application qui s'installe comme ils le souhaitent avec le type de fonctionnalités qu'ils souhaitent (les traitements de textes, navigateurs internet, et autres logiciels habituellement présents sur un ordinateurs ne permettent pas de partager des données stockées dans une base...)

Il est donc nécessaire de connaître des éléments complémentaires :
L'utilisation des données se fera-t-elle uniquement en lecture ?
Comment la base doit-elle être remise à jour lorsque de nouveaux médicament doivent être pris en compte ?
Y a-t-il déjà un intranet dans leur établissement ?

Y a-t-il un cahier des charges ???

grillé par el_slapper :-)
A la lecture de son interprétation à laquelle j'adhère entièrement, je pense que les médecins voudraient une belle applications professionnelle de gestion de patients, maladies et médicaments (ce qui ne sera pas forcément si simple qu'imaginé dans le premier post), avec, potentiellement la mise en place d'un système expert pour la détermination de la posologie des médicaments (attention, intelligence artificielle très intéressante mais non triviale inside) tout en ayant les avantages de la simplicité d'installation et d'utilisation qu'un éditeur de texte genre notepad.
Une belle crise de yakafaukon toujours très ennuyeuse pour un développeur débutant (bon courage) qui ne s'est encore jamais fait piéger dans la construction d'une tour de 50 étages avec les plans et les budgets d'une niche de chien.

Attention quand même à ne pas te faire avoir car quand je lis

Citation:

---

on me demande de faire une petite application pour gérer les médicaments pour les patients en fonction de leurs maladie.
L'appli doit allez chercher dans une base de données le nom du médicament en fonction de:
- Du patient
- De la maladie

---

Je pense :
Si il s'agit de récupérer les médicaments déjà utilisés par le patient dans le cadre d'un traitement de maladie déjà connue pour lui, pas de problème.
S'il s'agit de récupérer les médicaments qui sont adaptés à la prescription pour un patient en tenant compte des contre-indications potentielles liées à ses antécédents : attention.

Si tu ne sais pas à l'heure actuelle laquelle de ces deux réponses est la bonne, c'est qu'il est temps de demander avec une certaine fermeté un cahier des charges :-)

On peut revenir sur l'argumentaire à utiliser mais j'ai expérimenté une fois un projet sans cahier des charges (ma première mission) et le résultat, après un an de développement pour une équipe de trois personnes, a été un désastre complet (107 cas de tests, 100 échecs).
Les spécifications changeaient sans arrêt. Il fallait sans cesse modifier, remodifier... Le tout en utilisant un framework développé par une autre équipe et qui évoluait aussi en parallèle.
Je n'avais certes pas la même qualité de travail qu'aujourd'hui mais c'est juste pour dire que ce que dit le client n'est pas forcément très pertinent.

Excellent complément de fatbob, merci pour cet éclairage.

Pour aller encore plus loin, je dirais qu'il existe des logiciels professionels de prescription, validés par des médecins après des années de vérifications, et que si les gars rêvent d'un équivalent torché en trois mois par un jeune diplômé, même talentueux, ça pue le piège à plein nez.

Donc, +1000 avec fatbob : demande un cahier des charges complet, et n'hésite pas à leur rentrer dedans si tu y trouves des incohérences.

Par contre, sur l'aspect "appli windows installable", rien n'oblige à faire un vrai installeur. Un .py qui oblige juste à installer Python une seule fois, (par exemple), pas besoin de faire des milliers d'inscriptions dans la base de registre. Si ils ont peur d'un "serveur SQL"(quoi qu'ils entendent par là, et je subodore que c'est différent ce ce que nous professionels entendons par ces mots), alors un truc facile à déployer(i.e. copier-coller-ça-marche) est indispensable. Et comme la page web n'est pas disponible(faudra leur demander pourquoi, ça peut être instructif), un bête élément qui se lance par double-clic sans autre configuration me parait adapté(c'est possible en Java? J'y connais rien en Java...)

En bref, l'exigence "comme si c'était une appli windows installable"(je rajoute le "comme si" en raison du déploiement sur Mac, ça ne sera donc pas un bête .exe) ne me parait pas aberrante, même si il faudrait creuser pour déterminer sa pertinence(une mauvaise experience sur une interface web peut être la seule vraie cause, ça peut aussi être justifié), parait gérable, mais pose des limites. "Pas de serveur SQL", ça sonne comme un caprice de kissikoné.

Citation:

---

Envoyé par el_slapper

n'hésite pas à leur rentrer dedans si tu y trouves des incohérences.

---

Pour ma part, pour la question du CDC, je suis plus pour le froid exposé clinique des faits et conséquences.
J'ai déjà eu l'occasion de retourner deux fois une situation où le client ne voulais pas me fournir de cahier des charges et m'a ensuite remercié d'avoir été intraitable.
Dans le premier cas, j'ai carrément arrêté de travaillé en attendant qu'ils bougent (ça a duré deux jours) et j'ai fini par ssister à leurs réunions et à réaliser moi même le CDC (ce qui était une expérience fort intéressante)
Dans le second, j'ai déclaré que j'allais tenter leur développement mais que je ne garantissais aucun résultat. Que même, d'après mon expérience, je pouvais leur garantir que, ne sachant pas ce que je devais faire, il y avait fort peu de chance qu'un résultat correspondant un tant soit peu à leurs attentes non exprimées soit atteint dans les délais.

L'argumentaire est très simple et très efficace. Pour un succès maximal, il suffit de l'envoyer par écrit (mail) au demandeur avec éventuellement une copie à un décideur :
Sans cahier des charges, il n'est pas possible au développeur de savoir ce qu'on attend de lui. En effet, il est informaticien et non (mettre ici le métier du spécialiste. ex: médecin). Ainsi donc, il va devoir développer l'application de (mettre ici l'intitulé de l'application. ex : gestion des médicaments en fonction des malades et des maladies) alors même qu'il n'y connais rien.
Dans ces conditions, il est certain (à 100%, pas à 90, ni à 99. 100%) que si le développement est fait sans indication précise (cahier des charges OU spécialiste détaché en temps plein à la réponse de questions), le résultat qui sera fourni sera non seulement non satisfaisant mais réellement éloigné des attentes.
Il sera donc nécessaire d'apporter des corrections importantes qui ébranleront jusqu'aux fondations même de l'application (la structure de la base de données)... Pour produire un résultat tout aussi éloigné des attentes.
Au bout d'un certain temps de ces cycles, la qualité du code va tellement baisser (à moins que l'équipe de développement ne soit constituée que d'experts, auquel cas, elle peut peut-être réussir à s'en tirer) qu'il sera aussi simple de tout recommencer à zéro.

C'est après cet argument que j'avais ajouté, la première fois :
donc, j'attends directement la deuxième phase, celle où vous aurez compris qu'il me faut des informations précises pour faire un développement pertinent. En attendant, je ne fais rien.

Et la deuxième (j'étais plus coulant)
Donc il est évident que je ne peux garantir aucun résultat. Je peux même vous prédire que l'application que vous aurez en septembre ne correspondra pas du tout à ce que vous souhaiteriez obtenir :-)

Après, on peut entrer dans des discussions sur les méthodes agiles mais même là, il faut des spec.

Citation:

---

Envoyé par el_slapper

En bref, l'exigence "comme si c'était une appli windows installable"(je rajoute le "comme si" en raison du déploiement sur Mac, ça ne sera donc pas un bête .exe) ne me parait pas aberrante, même si il faudrait creuser pour déterminer sa pertinence(une mauvaise experience sur une interface web peut être la seule vraie cause, ça peut aussi être justifié), parait gérable, mais pose des limites. "Pas de serveur SQL", ça sonne comme un caprice de kissikoné.

---

Pour ma part, vouloir faire du client lourd (traduction : avec une partie de l'application installée sur chaque poste client) pour une appli qui semble être une appli de gestion standard, c'est... comment rester correct... Stupide ???
Si les applis web ont le vent en poupe et que les clients serveurs avec client lourd sont en déclin dans ce domaine, et ce malgré les langages web qui ne sont quand même pas très jojo (php, passe encore - quoique - mais javascript... c'est ce que je connais de pire) et la perte d'ergonomie (toute relative avec l'utilisation d'ajax), ce n'est pas par hasard. En particulier parce que les mises à jours sont à faire sur tous les postes.
Quand un administrateur à des dizaines, voire des centaines d'applications à gérer, les clients lourds sont des cauchemars.

Dès lors où l'on est sur un projet destiné à être utilisé par plusieurs utilisateurs avec des données partagées, pour justifier un client lourd, il faut vraiment que l'interface utilisateur nécessite des fonctionnalités non réalisables avec les technos web... Où qu'il y ait besoin d'une ergonomie particulièrement poussée.
Sans compter l'avantage de pouvoir se connecter à l'appli de n'importe quel poste.
Si un médecin est dans un autre service et veut consulter l'appli, il peut le faire sur n'importe quel poste et pas seulement sur ceux où elle aura été installée.

Bonjour,

j'ai pu rapidement échanger avec une personne "plus haut placée".

voici les réponses brèves:

Citation:

---

1 L'appli seras installée sur 1 pc ( celui de médecin de l'EPAD) et uniquement celui ci ?

Sur 1 PC (celui du médecin uniquement)

2 Pas besoin de synchronisation en temps réel avec un autre pc ( pharmacie par exemple ) ? NON

3 Seul le médecin peut apporter des ajouts, modification et suppression de médocs dans la base de données ? OUI

4 Une alerte résumant une adaptation de la posologie doit apparaitre pour les médicament le nécessitant ? Oui c'est le principe des icones dans le tableau.

(un message à récupéré dans une colonne de la base de données)

5 La possibilité d'installer un logiciel pour simuler un serveur sur le pc du médecin est il possible ou à éviter ? Si c'est nécessaire pour stocker la base de données, c'est possible, cependant il ne faut pas que ça prenne trop de place.

---

Donc pas de synchronisation en live.
Petite application de type client lourd avec une base de données mais pas trop lourde car installée sur le pc du médecin qui peut être assez vieux ou peu performant ( mais vu le type d'appli, cela doit passer ).
Mise à jours de la BDD faite par le médecin et lui seul.
Chaque médecin de centre EPAD adapte la BDD en fonction de ses besoins.
Application en parallèle d’autre application professionnelle.

Objectifs :
1 --> Faire faire une liste de médicament pour une étudiante en pharmacie ( thèse)
2 --> facilité la vie du médecin ( avec les alertes) pour ne pas avoir besoin de chercher dans le Vidal ou autre pavé médical.
3 --> Permettre à un jeune ( moi) de pouvoir faire une appli pour un projet d'étude ( application n-tiers en ce qui me concerne).
D’ailleurs une application de ce type ( IHM + code + BDD correspond bien à une appli n-tiers enfin 3-tiers dans mon cas ?)

Merci pour votre aide, je découvre la programmation et je galère un peu en cours mais je m'accroche et les projets de ce type sont bienvenue pour me faire progresser.

Bon, alors je me suis inquiété pour rien, mais il vaut mieux dans ce sens que dans l'autre.

Reste la contrainte PC/MAC, qui exclut les solutions microsoft. Mais sinon, la plupart des langages permettent de faire ça. JAVA, Python me viennent à l'esprit, mais il y en a sans doute bien d'autres, et il est préférable de taper dans ce que tu connais déjà.

Bien. On y voit plus clair.
Cela ressemble plus à un projet correctement calibré pour un stage de fin d'études et c'est tant mieux (mais il vaut mieux être prudent : le mien, par exemple, n'était pas bien calibré du tout, ce qui ne m'a pas empêché d'avoir une note correcte car l'évaluation finale a tenu compte de ce fait)

Aparté sur les clients lourds. Dire client lourd ne signifie pas forcément qu'il faut une bécane de course pour le supporter. Cela veut simplement dire qu'il y a une installation à effectuer du côté du client, contrairement à un client léger où un navigateur quelconque suffit.

Pour en revenir au choix du langage de développement.

Comme déjà dit, tu peux prendre ACCESS. Cela te permettra de créer très facilement une base de donnée et les écrans pour interagir avec. Dans ton cas, ce serait sans doute bien adapté (un seul utilisateur...) Par contre, cela masquera un peu les questions d'architecture de l'application
Il me semble que la suite office existe également pour mac. Reste à vérifier que les applis développées sur l'une fonctionnent sur l'autre.

Pour ce qui me concerne, je pencherais pour python/sqlite avec une librairie bien choisie pour l'interface graphique (je ne suis pas très versé dans ce domaine donc pour le choix de la bonne librairie, je ne sais pas trop que dire. tkInter me suffit la plupart du temps mais sera sans doute un peu juste pour ce que tu veux faire). Attention, dès qu'on sort des outils hyper intégrés, le développement des interfaces graphiques est assez compliqué à comprendre au début.
Python est facile à apprendre, très agréable à utiliser et permet de faire tout ce dont tu as besoin ici et bien plus. semi interprété (comme java) Il tourne sous windows et mac sans problème.
Je trouve java bien trop lourd et complexe et tu passerais beaucoup plus de temps à comprendre le langage lui même que les concepts sous-jacents (architecture n-tiers, objets...). Cela dit, java est un bon choix dans une perspective de plus long terme quoique python aie le vent en poupe et est de plus en plus demandé.
Sqlite te permettra de gérer une quasi-véritable base de données. Pour un seul utilisateur, c'est parfait. En plus, tu as un plugin firefox pour l'administration des tables donc c'est assez pratique. Comme la base est stockée dans un unique fichier et ne nécessite pas de service particulier pour la gérer, tu peux considérer qu'elle est embarquée dans l'application.

Reste peut-être un outil que j'ai utilisé il y a fort longtemps mais qui est d'une efficacité redoutable dans le développement d'applications comme celle ci : Delphi de Borland.
Il en existe des versions gratuites mais leurs limitations seront apparemment difficiles à concilier avec ton projet. Il faut également vérifier le problème mac/PC
http://delphi.developpez.com/telecharger-gratuit/
Le langage utilisé est le pascal objet et la mise en place d'une base de donné et de l'interface graphique sont très faciles.

C'est certainement la solution qui sera la plus rapide à mettre en oeuvre et qui te laissera le plus de temps pour penser au code métier proprement dit (à mon avis, le Pascal objet est un langage nettement meilleur que Visual Basic). Le client sera content.

Amuse-toi bien

Bonjour,

merci à vous tous !

On à eu une réunion, et j'ai des contraintes suplémentaire.

Côté base de données j'ai le choix. Je vais prendre de l'embarquée avec SQLite.
Par contre coté interface et code,( c'est imposé) C# ou VB.net mais avec Visual studio 2005 ! ( une tierce personne qui à l'habitude de travailler avec eux utilise cette version et m'oblige à la conservée, en plus ils ont la licence officielle ).

Là je commence à tester tout ceci je vais créé un topic car je rencontre un souci :)

Merci beaucoup :)