[DE |
EN |
FR |
IT |
JA |
ES |
KO |
PT]
Bienvenue pour un nouveau numéro du Brave GNU World - le meilleur du GNOUveau monde. Nous l'avons toujours cru, mais ce numéro apporte des preuves : les Logiciels Libres sont bons pour la santé!
Comme beaucoup de domaines, celui des applications médicales propose une grande quantité de projets qui sont parfois plutôt avancés, mais les rassembler ou les intégrer dans une solution logicielle est au-dessus des capacités d'un utilisateur "normal". Pour résoudre cela, Andreas Tille a commencé au début de 2002 le projet Debian-Med [5], dont le but est d'adapter la distribution Debian aux utilisateurs en médecine et en microbiologie et qui cherche à intégrer des projets logiciels de ces domaines.
Les lecteurs réguliers du Brave GNU World se rappelleront peut-être le projet Debian-Jr. [7] présenté dans le numéro 23 [6], et en fait l'idée de Debian-Med est inspirée de celui-ci.
Les logiciels qui interagissent avec la sphère privée et très intime de la vie humaine - comme c'est le cas pour les médecins - doivent remplir certains critères dont seuls les Logiciels Libres peuvent s'acquitter complètement aujourd'hui.
Par exemple, il doit être avéré que la confidentialité et la sécurité des données du patient sont défendues. Cela nécessite une transparence certaine, qui est mieux garantie par un processus de développement Libre.
La protection contre la perte de données peut également être très importante, parce que certains tests sont dangereux pour la santé ou ne peuvent parfois pas être répétés. Si des données sont perdues, la qualité du service médical est clairement réduite. En même temps, cela va naturellement être la cause d'une perte de confiance du patient envers le médecin.
C'est pourquoi ce domaine nécessite une base (un système d'exploitation) stable, digne de confiance, sécurisée et dotée d'applications similaires. L'utilisation des Logiciels Libres devient de plus en plus nécessaire pour tout médecin consciencieux.
Il n'est pas surprenant que la confidentialité, la protection des données et le degré de confiance soient les objectifs principaux de Debian-Med.
Les autres points majeurs sont - comme il se doit - les facilités d'utilisation, d'installation et d'administration.
La facilité d'utilisation réduit les erreurs et la frustration qui affecteraient le patient dans ces domaines. La facilité d'installation et d'administration assure au médecin consciencieux d'avoir moins de problèmes pour migrer vers les Logiciels Libres, ce qui facilitera ses considérations pratiques.
Le projet, c'est-à-dire Andreas et environ 70 autres personnes intéressées, se concentre actuellement sur la résolution de tous les problèmes communs et travaille à le rendre prêt à l'installation.
La perspective à moyen terme est de présenter Debian-Med comme une alternative tangible pour les médecins et de réaliser un CD-Rom de démonstration en direct.
La documentation et la traduction ont grand besoin d'aide et il manque aussi toujours un logo. Andreas a pensé à un mélange du logo Debian et d'un serpent pour celui-ci.
Le type de licence de l'ensemble du projet est bien sûr déterminé par les licences de chaque logiciel. Sont préférés les Logiciels Libres sous une licence approuvée par les Debian Free Software Guidelines (DFSG).
Malheureusement, le projet prévoit également de fournir des paquetages de logiciels propriétaires distribuables sans coût, ce qui crée une faiblesse pour les perspectives à moyen et long termes. Mais si suffisamment de personnes expriment leur volonté de penser au long terme ici, je suis sûr que cela n'est pas définitif.
J'ai toujours considéré qu'apporter des Logiciels Libres dans le domaine médical était plutôt important et si vous cherchez à vous engager dans un projet utile, Debian-Med est très clairement un bon choix.
Parmi les programmes présents dans Debian-Med, Gnumed [8] est un projet GNU officiel pour l'exercice de la médecine sans papier.
Le projet est né en Australie au cours d'une discussion enflammée sur les dangers des logiciels propriétaires dans le domaine de la santé en mars 2000. Les médecins refusaient de fonder leurs décisions sur des algorithmes opaques. Pendant le débat, on accusa Horst Herb d'esprit critique non constructif, ce qu'il interpréta comme un signal pour commencer à travailler sur Gnumed.
Après qu'une première version alpha fonctionnelle a été présentée au MedInfo2001 à Londres, l'intérêt international pour Gnumed rendit nécessaire de repenser complètement sa structure interne. L'implémentation de cette nouvelle structure est actuellement la tâche principale des coordinateurs du projet, Horst Herb et Karsten Hilbert, qui y travaillent ensemble avec environ 17 développeurs et de nombreux volontaires.
Après l'achèvement d'une version minimale, qu'ils espèrent être déjà utile, il est prévu de faire de Gnumed une solution médicale complète incluant l'aide à la décision.
Cet objectif de Gnumed rencontre les problèmes suivants : un manque de bases de données pharmaceutiques libres, des systèmes de santé ayant des législations différentes, le manque de formats de données, transférer les standards et les protocoles de messagerie standardisés, ainsi que l'absence d'un système générant un identifiant global unique par patient.
Les langages de programmation utilisés dans ce projet sont Python et C/C++ pour le client, PgSql, C et Python pour le serveur, où la fiabilité et la sécurité sont les paradigmes les plus importants qui, d'après l'équipe Gnumed, ne sont pas traités de façon adéquate dans les solutions propriétaires.
Au fait, l'équipe Gnumed est principalement constituée de médecins des différentes spécialités, qui savent très bien ce qu'ils veulent, mais pas aussi bien comment l'implémenter. C'est pourquoi plus de développeurs expérimentés seraient un apport très bienvenu à l'équipe.
Logiciel Libre sous Licence Publique Générale de GNU (GNU GPL), Gnumed veut proposer une interface graphique facile, ergonomique et hautement configurable et supporter des langues et des systèmes de santé différents, ainsi qu'avoir une indépendance relative de plate-forme.
Si vous souhaitez participer au développement de ce domaine, Gnumed est certainement un projet pour le faire.
L'"Infrastructure Ouverte aux Résultats" (OIO - "Open Infrastructure for Outcomes") [9] est appelée la "Quête du Graal" du transport de données par son auteur Andrew Ho. Nandalal Gunaratne, Alesander Chelnokov et d'autres l'accompagnent dans sa quête.
OIO a déjà été utilisé pour la production au Centre Médical de Harbor-UCLA en mars 2000 avant d'être publié en août en Logiciel Libre sous Licence Publique Générale de GNU (GNU GPL). En septembre, il gérait déjà les données de plus de 1000 patients et depuis février 2002, il est utilisé comme système d'information sur tout un hôpital. On peut affirmer que OIO a déjà fait ses preuves à l'usage quotidien.
Les principaux composants de OIO sont le serveur, auquel on accède via un navigateur HTML et la bibliothèque OIO. Le serveur est un système de gestion de données flexible, basé sur le web, qui gère les utilisateurs, les patients et les informations les concernant ; mais il serait également possible de l'utiliser pour des clients, des factures, des livraisons ou des comptes.
La bibliothèque OIO est un dépôt de méta-données, ce qui permet leur échange sous forme de formulaires Web instantanés ou de descriptifs de projets entre le serveur et le client.
Un utilisateur de OIO peut créer ou modifier des formulaires à l'aide d'un navigateur web, ce qui les rend immédiatement disponibles sur le réseau pour collecter des informations.
Les formulaires peuvent ensuite être exportés au format XML vers un dépôt de méta-données comme la bibliothèque OIO ou être téléchargés sur un autre serveur OIO.
Bien sûr, il est également possible de rassembler les données de différents formulaires dans un même endroit qui peut être interrogé et exploré sur le Web à l'aide d'opérations logiques.
Bien que OIO est déjà utilisé depuis quelques temps, le développement n'est pas fini. Parmi les fonctionnalités prévues pour les futures versions, le support des PDAs sans fil et les protocoles plug-and-play seront présents. Le plus utile à l'heure actuelle serait plus d'utilisateurs, de retours et un meilleur enrobage.
Pour le dernier point au moins, Debian-Med pourrait être utile.
Res Medicinae [10], de Christian Heller, est également utilisé dans le projet Debian-Med. Il a travaillé avec Karsten Hilbert à faire de Res Medicinae la solution logicielle étendue du domaine médical.
Pour obtenir une communication maximale, Res Medicinae se base sur Java (API/Swing, Servlets/JSP, JDBC) avec un peu de CORBA/IDL et SOAP/XML. Cela révèle déjà le plus gros problème de ce Logiciel Libre sous Licence Publique Générale de GNU (GNU GPL), car le manque d'une implémentation Libre et pleinement fonctionnelle de Java met la liberté de ce projet en danger.
Mais la liberté était un facteur majeur pour motiver Christian à commencer le travail sur Res Medicinae. Il semble dépasser la scène très coûteuse et propriétaire des systèmes d'information médicaux et donner aux utilisateurs des pays moins privilégiés l'accès à un système libre, stable, sécurisé, indépendant de toute plate-forme et étendu.
Le projet est encore plutôt jeune. D'après les prévisions, à la fin de 2002, le framework ResMedLib devrait être consolidé et les prototypes de deux composants complets disponibles. En 2003, le composant administratif, les formulaires d'impression et la génération de rapports devraient fonctionner.
Ensuite, un traitement d'images et un gestionnaire - ainsi qu'un composant de facturation et de statistiques - devraient être ajoutés. Un composant de formation et un d'aide à la décision devraient alors achever le projet.
S'il ne faut sans doute pas encore essayer d'utiliser le projet au quotidien, ceux qui sont intéressés par apporter une compétence médicale, des traductions, du développement Java ou de la conception de page Web recevront un accueil chaleureux de Res Medicinae.
À la connaissance des auteurs, Res Medicinae est actuellement le seul projet GPL basé sur Java dans le domaine médical ; ceux-ci prévoient de travailler conjointement avec OpenEMed, un projet Java similaire sous une licence BSD, et ils ont déjà annoncé que Gnumed lui serait compatible.
En voilà assez aujourd'hui pour la santé. S'il existe d'autres projets dans ce domaine, un courrier électronique [1] sera la façon appropriée de m'en faire part et je les présenterai ultérieurement.
Romance [11] est la tentative de Bertrand Lamy et Jean-Baptiste Lamy d'apporter aux Logiciels Libres une véritable alternative Libre au .NET de Microsoft.
D'après Bertrand, leur motivation est que Ximian ne sera sans doute pas en mesure de fournir une implémentation Libre de .NET. Le fait que Microsoft ait déjà promis de combattre toutes les alternatives Libres utilisant des brevets de logiciels rend cela plausible.
Les standards contrôlés par les entreprises sans une implémentation Libre de référence ont également toujours le problème que l'entreprise est en avance de plusieurs étapes, tandis que les projets Libres ont beaucoup de mal à suivre. La situation autour de Java souffre exactement de cet effet.
La réponse est claire : nous avons besoin d'un standard Libre accompagné d'une implémentation Libre. C'est ce que Romance cherche à apporter.
La première étape - et le début du développement - est Rose, le "Romance Object System rosE". Rose fournit un protocole, qui permet le partage des objets entre différents langages de programmation.
L'étape suivante du développement sera WiSe, le "Romance Widget Server". Il sera disponible sous forme de bibliothèque GUI/boîte à outils pour toutes les applications Romance à travers le serveur Romance. Le paradigme employé dans WiSe est que tous les widgets restent la propriété du processus WiSe, et non pas des différentes applications. Cela devrait permettre à Romance de partager les widgets très rapidement et très simplement.
Depuis que Bertrand et Jean-Baptiste sont convaincus que 75% des applications de bureautique devraient être écrites en scripts, ils se sont concentrés en premier sur les supports de Python, Guile et C. D'après leurs prévisions cependant, Rose supportera également Perl, Ruby, Lisp, Scheme et d'autres langages dynamiques dans le futur.
Il y a de nombreux exemples sur la façon d'utiliser Romance.
Pour les grandes applications, définir un langage d'extension est souvent une bonne idée. Au lieu de choisir un langage, un groupe d'objets pourraient être rendus disponibles au travers de Romance, ce qui permet d'exécuter l'application en script de n'importe quel langage supporté par Romance.
Les applications réseaux nécessitent souvent un protocole de communication, qui peut provenir de Romance. Comme il est plus léger que CORBA, qu'il supporte plus de langages que Java RMI et fonctionne avec des objets dynamiques non statiques, Romance offre plusieurs avantages à cet effet.
Romance peut aussi jouer le rôle de "liant" entre différentes parties d'un programme écrites dans des langages différents, et fournit ainsi une alternative à SWIG. Étant dynamique, Romance s'assure automatiquement que l'interface est disponible pour tous les langages "romantiques".
Via WiSe, Romance fournit aussi des widgets pour une interface utilisateur graphique, qui peut être partagée entre plusieurs processus de façon légère et efficace. Cela supprime la nécessité de se lier à des boîtes à outils graphiques et permet à l'utilisateur de choisir via Romance l'aspect de toutes les applications.
Tout en offrant toutes ces possibilités, Rose est très petit, il fait moins de 500 lignes de code en Python/Scheme.
Bien que ce projet, qui est publié sous Licence Publique Générale de GNU (GNU GPL), est plus significatif pour les développeurs, il donne à tous des perspectives intéressantes pour l'avenir.
En supplément au numéro 39 [12], qui présentait des clones de Risk, je voudrais présenter JavaRisk [13] de Christian Domsch, Sebastian Kirsch et Andreas Habel.
JavaRisk est une implémentation du fameux jeu de plateau Risk en Java sous Licence Publique Générale de GNU (GNU GPL) et dont les règles se basent entièrement sur la version allemande du jeu. Bien que JavaRisk soit un jeu sur ordinateur, les auteurs n'ont programmé ni support réseau ni intelligence artificielle.
Il a cependant de superbes graphismes, si bons que le jeu J-TEG présenté dans le numéro 39 les propose dans un thème.
JavaRisk est un projet d'étudiants typique, ce qui signifie que les trois auteurs ne s'arrêtèrent pas de jouer à l'approche de leur professeur.
Lorsqu'il remarqua le jeu, il l'aima immédiatement. Il suggéra d'écrire une intelligence artificielle pour celui-ci en projet de 5e semestre. Comme il était aussi fan de tout ce qui vient d'Asie, il leur demanda d'ajouter de petits guerriers samouraï qui s'animeraient lorsque la Chine ou le Japon seraient attaqués.
Actuellement, Christian, Sebastian et Andreas travaillent à une nouvelle version de JavaRisk, qui aura plus de ressemblance avec un jeu de stratégie comme Empire. JavaRisk v2 supportera également dès le départ le jeu en réseau.
Également en réaction au numéro 39, Mario Lang m'a écrit et recommandé de parler du projet Emacs Chess [14] de John Wiegley.
Emacs Chess se divise en trois parties. La première contient les facultés d'affichage et d'interface afin de dessiner différents types d'échiquiers dans Emacs. La seconde permet la communication avec différents moteurs d'échecs comme GNU Chess et Crafty. Et la troisième est une bibliothèque de positions et de parties incluant un vérificateur pour la gestion des bases de coups et de parties.
Le support d'Emacs Chess par le client IRC d'Emacs (ERC) [15] fait partie des fonctionnalités très soignées d'EmacsChess. Il permet de démarrer une partie avec quelqu'un sur IRC, pour peu qu'il utilise également EmacsChess et ERC.
Comme le protocole d'échecs sur IRC est basé sur CTCP, il est également possible d'implémenter un mode compatible dans d'autres clients.
Puisque Emacs fonctionne aussi en console, Emacs Chess fournit une belle interface d'échiquier pour les non-voyants, qui peuvent annoncer leurs coups sous la forme "cavalier en a4". Mais les autres peuvent également utiliser cette fonctionnalité très bien faite.
Ceux qui n'utilisent pas Emacs ne vont sans doute pas s'y mettre pour Emacs Chess, mais l'essayer en vaut vraiment la peine pour tous les amis d'Emacs.
Publié sous Licence Publique Générale de GNU (GNU GPL), Emacs Chess est un logiciel écrit en Emacs-Lisp et en version béta, donc attendez-vous à quelques petites difficultés.
Assez de Brave GNU World pour ce mois. Les idées, suggestions, commentaires et comptes-rendus sur des projets intéressants sont toujours les bienvenus à l'adresse habituelle [1].
Envoyez vos questions sur GNU et la FSF à
gnu@gnu.org.
Il y a aussi d'autres façons de
contacter la FSF.
Envoyez vos commentaires sur "Brave GNU World" (anglais ou allemand) à
column@gnu.org,
et les commentaires sur cette page à
webmasters@www.gnu.org,
les autres questions à
gnu@gnu.org.
Copyright (C) 2001 Georg C. F. Greve
Traduction [FR] : Valéry Beaud
Permission vous est donnée de distribuer des copies exactes de cette page tant que cette note de permission et le copyright apparaissent clairement.
Dernière modification : $Date: 2002/10/29 11:59:26 $ $Author: r4f $