Discussion :

[GPPro]

Bonjour

Travaillant en pharmaceutique (d'accord en R&D, mais ce sera, je l'espère les futurs médoc'), hors mis mes diplômes de biologie et d'informatique, je ne dispose pas d'agréments.

A ce train, faudra que je demande à ma boîte une formation continue en médecine

@++

Oé, enfin, les logiciels employés dans le médical sont censés suivent un certain nombre de normes (62304 pour commencer par la plus spécifique)... Mais par un tour de passe-passe que je ne m'explique pas trop les dossiers patients échappent à cette contrainte !

[free07]

Je connais très bien aussi le milieu informatique hospitalier et il y avait une époque ou certains logiciels étaient développés dans le cadre de ce que l'on appelait des CRIH ( Centre Régional d'Informatique Hospitalière ).
Ces instances dépendaient du ministère de la santé, ce n'étaient pas des entreprises privées.

Et ces logiciels fonctionnaient très bien, en même temps, ce n'était que la partie administrative qui étaient développé mais pas médical, en tout cas, pour la région que je connais et puis, il y a 20 ans, on ne parlait pas vraiment encore du Dossier Patient Informatisé.

Maintenant, c'est très différent, tous les éditeurs de logiciels pour les hôpitaux et les cliniques sont des entreprises privées qui sont soumis à des principes et des lois économiques, c'est à dire et pour résumer grossièrement, en faire le plus possible avec le moins de moyens possibles.

Conséquence à cela ? Les Hotlines sont chers et souvent inefficaces, pour la plupart des gros éditeurs du marché, par manque de moyens, ils sont incapables de vous résoudre 100 % des problèmes ( s'ils arrivent à 30 % c'est le bout du monde ) et ce qui est résolu, cela prend souvent plusieurs mois en s'épuisant à les relancer régulièrement.

Et puis, les nouvelles mises à jours ont toujours le nouveau lot de bugs... qui entrainent encore et encore des sollicitations des équipes de hotline et de développement qui mettent encore plus de temps à les résoudre...

Pour en avoir discuté avec pas mal de responsable info de CH, il n'y a aucun éditeur qui est meilleur que l'autre, tous souffrent des mêmes maux.

[Invité]

free07 résume magnifiquement le problème : on applique la logique économique du profit maximum (faire moins avec plus) avec quelque chose qui ne s'y prête pas du tout : les logiciels de santé

[souviron34]

J'ajouterais mon grain de sel....

Pour ma part je fûs Chef du Prototype d'un tel logiciel hospitalier, après l'échec de la version précédente..

Tout d'abord, pour infos génrales, vous devriez - aiinsi que le contribuable !!! - savoir que ces pojets ont démarré il y a maintenant 30 ans !!!! (en 1983/84, que ce soit en France ou en Amérique du Nord) (voir dernier point de la liste ci-dessous)

Et qu'à ce jour aucun ne marche de manière 100% satisfaisante.... sauf ceux ciblés (en particulier en Amérique du Nord) pour éviter les multi-visites : aux USA par exemple ce sont les compagnies d'assurances qui financent ces logiciels.

Ceci est dû à plusieurs raisons

• Dans les pays comme la France, très centralisateurs, tout est passé par l'Etat et l'AP. Du coup, d'une part procédures longues et complexes, d'autre part appel à d'énormes SSII... Qui n'ont strictement aucun intérêt à ce qu'un projet se termine, surtout quand il est financé en dizaines de millions..
  
  
• L'accent à presque partout été mis presque exclusivement sur la partie gestion financière.
  
  
• L'énormité des projets/structures ont impliqués des structures "cycles en V", avec de grosses sous-équipes , et tout un tas de documents afférents.
  
  
• De cette énormité a découlé des "recueuils de besoin utilisateur" et des "designs d'écrans" par des informaticiens ou assimilés, et non par 1) des médecins et 2) des graphistes..
  
  
• De cette inadéquation entre interlocuteurs s'est épanoui extrêmement souvent une mauvaise arborescence des écrans et actions, donc une complexité accrue pour les utilsateurs (de mémoire, nous avions mesuré le temps mis par un chirurguien cardiologue pour établir une prescription compliquée : il n'y avait pas photo : 12.5 minutes à la main, 45 minutes avec le logiciel !!!), et une (très) mauvaise ergonomie.
  
  
• Les lois "Informatique et Libertés" sont indaptées en ce qui concerne les logiciels hospitaliers - entre mots de passe à n'en plus finir, codes ou numéros Sécu alors que le patient arrive en lambeaux ou en extrême urgence, anesthésiste qu'on rappelle alors qu'il est en pause, et qui donc ne "pointe" pas, "accès" aberrant aux résultats, etc etc.... ce qui rend la conception et la fabrication des écrans pratiquement "infaisable" : si l'on suit les règles de manière absolue, pour afficher une feuille de résultats d'analyse , chaque MOT doit être associé à une catégorie/nom de médecin qui peut le voir, et donc on doit afficher en réalité une feuille remplie de trous, en ayant fait 3000 * N vérifications en BD centrale pour une page de 3000 mots...
  
  
• Les hiérarchisations / egos / domaines de compétence en cours dans le domaine médical compexlifient énormément les décisions et actions possibles (qui a le droit d'écrire dans le dossier ? d'écrire quoi ? comment ? quand ? ).
  
  
• Lié à "Informatique et Liberté", certaines lois sont absurdes : par exemple à cause de l'informatique on est censé tout garder... OR il est strictement interdit par la loi de prioriser des patients (en dehors de leur ordre d'arrivée/gravité à l'accueil). MAIS les infirmiers/ières sont bien obligés de prioriser en cas d'évcaution subite. Ce qui, avec le papier, se fait via un post-it collé sur le dossier, qui disparît à la fin du séjour (et est éventuellement modifié en cours de séjour). C'est aussi le cas lors de "troubles potentiels", du style patient en cours de séparation qui tourne mal, etc....
  
  
• D'autres lois sont médicalement combattues par des médecins (par exemple les ponctions lombaires avaient été légalement obligées d'être au nombre de 2, alors que les urgentistes pour enfants trouvaiet ça dangereux, et ont mis un an à convaincre le Parlement de faire un amendement). Du coup, un logiciel qui impose strictement de suivre la loi sera sans doute peu suivi/utilisé, en tous cas dans ces cas-là...
  
  
• Globalement, le système "top-down" ne mache pas, de même que "le consensus", qui prévaut cependant généralement dans les grandes structures de projet "en V"... Et au niveau de l'Etat..
  
  
• Un système hospitalier digne de ce nom doit prendre tout en compte, c'est à dire également lingerie, nutritionniste, ménage, labos périphériques, imagerie, tournées, gardes, remplacements, etc etc...
  
  
  
• Certaines règles liées à l'informatique médicale sont absurdes : il faut que les logiciels soient utilisables indifféremment par des daltoniens ou non, alors qu'un toubib daltonien saura dans la pile de papier quelle est la feuille que les autres appellent "jaune", ou "rouge"...
  
  
• Il y a extrêmement peu de "Cahier des Charges" précis (l'AP en avait fait un en 1989)
  
  
• Les investissements sont gigantesques : de 1983 à 1996 c'est environ 700 à 1800 millions (de francs) par an, et depuis 2004 et Douste-Blazy environ 1.2 milliard d'euros par an. Sur le projet sur lequel j'ai travaillé, c'était 83 millions en 14 ans, à 60 personnes, pour arriver à un échec....

Je ne m'étendrais pas plus ici, mais je dirais que les grandes raisons des échecs sont d'une part l'esprit "cycle en V", voulant tout modéliser au départ alors que c'est une problématique particulièrement complexe, et, ce qui est lié, les énormes équipes et SSII impliquées, qui font que et l'approche e elle-même, et les projets ont extrêmement peu de chances d'aboutir..


En ce qui concerne Montpellier et le Languedoc-Roussillon, c'est justement devant l'imprévisibilité d'une date éventuelle de sortie d'un logiciel national qu'ils ont décidé de partir de leur côté, en regroupant tout d'abord les logiciels des labos d'hémato et quelques spécialités , puis en aagrandissant petit à petit...

Je n'arrive pas à retrouver la source, mais un vieux article disait que la pertinence des logicielles de prescription étant plus pertinent que les prescriptions des médecins (80% logiciel - 40% médecin).

Voui, ben ça, je sais pas sur quoi tu peux te baser : la prescription logiciel avec quoi en entrée ??????

Quelle est votre analyse de la situation ? Serait-il plus salutaire de retourner à l'ère des vieux dossiers papiers ?

Revenir au papier, sans doute pas.. Le garder sans doute..

Mais surtout tester réellement les softs avec de vrais utilisateurs HORS CADRE... Pas dans des "équipes de test" pré-établies avec des gens ayant bossé 10 ans avec le fabriquant...

Et ne pas oublier que la machine ne fait QUE ce que l'humain lui dit de faire...
(qu'il soit médecin ou programmeur).. et que c'est le médecin qui a la connaissance, pas la machine - ele n'a pas passé d'examen, et elle ne juge/pondère pas....

Je comptais laisser filer mais finalement je peux pas me retenir de te faire remarquer que l'informatique est là pour automatiser les choses déterministes. Il est donc totalement absurde de tenir ce genre de discours, bien évidemment que les médecins peuvent faire le boulot du logiciel mais à quoi sert le logiciel s'ils doivent refaire le boulot après lui ?

Sauf que dans le cas d'un médecin, la partie déterministe est extrémement faible....

En gros elle se limite à ; "telle dose / jour => tel mdicament avec x gélules 3 fois / jour"....

Pratiquement tout le reste est non-déterministe : ce symptôme peut être dû à ça, ou à ça, ou à ça....

Ayant bossé pour un éditeur de matériel médical américain mondialement connu situé à Buc, ça ne m'étonne pas.

Moi aussi et moi non plus

[ymoreau]

Sauf que dans le cas d'un médecin, la partie déterministe est extrémement faible....

Qu'elle soit faible ou non, je voulais juste dire qu'il me semble normal que le médecin n'ait pas à tout revérifier à chaque fois (dans cette partie) sinon ces "calculs" automatiques n'ont aucun intérêt et on se contente de remplacer les feuilles papiers par des champs de saisie.
Tout ce qui n'est pas déterministe n'est de toute façon pas fait par le logiciel (enfin j'espère) donc forcément le médecin fera son boulot sur le reste.
Edit: et je ne dis pas que la gestion de données informatique n'est pas une amélioration par rapport au papier, mais plutôt qu'on ne propose pas de "suggestions automatiques" de prescriptions si c'est pour de toute façon tout refaire.

[MiaowZedong]

Sauf que dans le cas d'un médecin, la partie déterministe est extrémement faible....

En gros elle se limite à ; "telle dose / jour => tel mdicament avec x gélules 3 fois / jour"....

Pratiquement tout le reste est non-déterministe : ce symptôme peut être dû à ça, ou à ça, ou à ça....

Euh...le principe du determinisme est quand même à la base de la medecine (identification de la maladie à partir de syndromes, et non des symptomes individuels bien sûr). Je pense que ce tu as voulu dire, c'est que cela dépasse ce que l'on a réussi à inculquer jusqu'à présent aux systèmes experts

Qu'elle soit faible ou non, je voulais juste dire qu'il me semble normal que le médecin n'ait pas à tout revérifier à chaque fois (dans cette partie) sinon ces "calculs" automatiques n'ont aucun intérêt et on se contente de remplacer les feuilles papiers par des champs de saisie.

C'est déjà une amélioration: avec l'informatique on peut faire des recherches, indexer les données, les parcourir plus vite et stocker l'équivalent d'une grande pièce d'archives dans un seul disque dur....peut-être faudrait-t-il arrêter de vouloir trop bien faire

[souviron34]

C'est déjà une amélioration: avec l'informatique on peut faire des recherches, indexer les données, les parcourir plus vite et stocker l'équivalent d'une grande pièce d'archives dans un seul disque dur....peut-être faudrait-t-il arrêter de vouloir trop bien faire

D'un autre côté, on avait filmé le même chirugien cardio regarder 6 dossiers de patients "lourds", avec un historique de 20 ans , soit des dossiers de +600 pages....

Moyenne : 3 minutes 30 pour 1 dossier (avec même des particularités extrêmement surprenantes dans la manière de chercher suivant les dates)

Extrêmement difficile à reproduire par info tout en passant par toutes les pages...

L'humain et son cerveau sont très souvent bien supérieurs à la machine....

[free07]

Intéressant d'avoir un retour d’expérience côté développement, je connais le milieu informatique hospitalière car j'en discute souvent avec les utilisateurs et certains responsable info.

J'ajouterais mon grain de sel....

Pour ma part je fûs Chef du Prototype d'un tel logiciel hospitalier, après l'échec de la version précédente..

Je suis curieux de savoir quels étaient ces deux projets

• L'accent à presque partout été mis presque exclusivement sur la partie gestion financière.

Je comprends pas, tu parles du logiciel pour les services financiers ou de la gestion financière du projet ?

• De cette énormité a découlé des "recueuils de besoin utilisateur" et des "designs d'écrans" par des informaticiens ou assimilés, et non par 1) des médecins et 2) des graphistes..
  
• De cette inadéquation entre interlocuteurs s'est épanoui extrêmement souvent une mauvaise arborescence des écrans et actions, donc une complexité accrue pour les utilsateurs (de mémoire, nous avions mesuré le temps mis par un chirurguien cardiologue pour établir une prescription compliquée : il n'y avait pas photo : 12.5 minutes à la main, 45 minutes avec le logiciel !!!), et une (très) mauvaise ergonomie.

Pourtant la plupart des éditeurs se vantent toujours de l'étroite collaboration des médecins avec les équipes de dév voir même de médecins qui sont employé à temps plein pour collaborer et apporter leur expertise au développement des logiciels ( côté utilisateur )

Je ne m'étendrais pas plus ici, mais je dirais que les grandes raisons des échecs sont d'une part l'esprit "cycle en V", voulant tout modéliser au départ alors que c'est une problématique particulièrement complexe, et, ce qui est lié, les énormes équipes et SSII impliquées, qui font que et l'approche e elle-même, et les projets ont extrêmement peu de chances d'aboutir..

Etonnant ! Il est vrai que la complexité de ces projets ne fait aucun doute, mais j'ai été surpris que le cycle en V puisse être la raison principale d'un échec, à première vue, cela apparait aussi adapté aux projets complexes et conséquents.

[zaventem]

Pourtant la plupart des éditeurs se vantent toujours de l'étroite collaboration des médecins avec les équipes de dév voir même de médecins qui sont employé à temps plein pour collaborer et apporter leur expertise au développement des logiciels ( côté utilisateur )

Est-ce que ce n'est justement pas ça le problème, demander à des gens qui n'ont pas les mains dans le cambouis? C'est une chose de penser à l'utilisation idéale d'un logiciel à venir, c'en est une autre de devoir l'utiliser après avoir passé 36heures à travailler non-stop et où chaque seconde de perdue "pour les beaux yeux des décideurs" sont prises sur les soins du patient suivant où sur le micro-sommeil tant attendu?

C'est une chose que je vois chez moi (même si ce n'est pas dans le milieu médical): on a promu des gens du terrain "expert" et oui, il y a dix ans, ils étaient parmi les meilleurs et avaient plein d'idées pratique et fonctionnelle, aujourd'hui, ben, ils sont toujours "expert" et le terrain se débrouille comme il peut avec leurs super trouvailles...

[souviron34]

Je suis curieux de savoir quels étaient ces deux projets

En privé ok, mais pas en public..

Disons que c'était à l'étranger, et testé également en France..

Je comprends pas, tu parles du logiciel pour les services financiers ou de la gestion financière du projet ?

Non, je dis que la focalisation a toujours été, dans tous les projets, sur la partie financière : Sécu, remboursements, et autres...

La partie à proprement parler médicale a toujours été considérée comme un à-côté, et non pas le centre...

Pourtant la plupart des éditeurs se vantent toujours de l'étroite collaboration des médecins avec les équipes de dév voir même de médecins qui sont employé à temps plein pour collaborer et apporter leur expertise au développement des logiciels ( côté utilisateur )

Oui, sauf que...

Et c'est lié au "cycle en V"..

Ils n'ont qu'un rôle consultatif et non décisionnel, voire pire uniquement de testeurs / interviewés.

De plus, en général ils sont réunis en "groupes" pour lesquels on veut voir sortir un "consensus"... Or qui dit consensus dit compromis, d'une part vers le plus petit dénominateur commun, et d'autre part en fonctionalité..

Enfin, obtenir un consensus dans les prfessions médicales est long, pour ne pas dire impossible, et surtout n'arrive pratiquement jamais au meilleur résultat, à cause de la limite de la taille des écrans..

En gros, on va hiérarchiser des choses, et on va faire faire ce choix par des toubibs (par exemple en disant que telle spécialité est moins importante que telle autre), au lieu de prendre simultanément en compte l'ensemble des désidératas et trancher pas par rapport à la spécialité, mais par rapport à l'importance relative globale et générale...


Mais surtout ces comités sont à base de médecins, et la parole des médecins est prise pour supérieure à celle des infirmiers, urgentistes, accueil, etc.. Même si des représentants infirmiers y siègent, ils sont en général soumis à la même pression hiérarchique que dans la vraie vie.

Etonnant ! Il est vrai que la complexité de ces projets ne fait aucun doute, mais j'ai été surpris que le cycle en V puisse être la raison principale d'un échec, à première vue, cela apparait aussi adapté aux projets complexes et conséquents.

Non, pour 4 ou 5 raisons de fond :

• dans un tel cycle, on ne tient pas compte des avancées techniques ou de besoin au fur et à mesure
  
  
• les tests se font à la fin
  
  
• les "comités" sont statiques, consultatifs, et on leur demande des choses en dehors de leur domaine (choisir entre telle ou telle chose) mais peu sur leur vrai domaine (dans quel ordre se font les choses , ou à quelle fréquence).
  
  
• les décisions de choix d'architecture , de présentation, etc, se font en dehors de ces comités
  
  
• les grandes équipes impliquent des documents différents pour chaque équipe, avec des pertes d'information/traduction à chaque échelon. De plus, cela implique des délais phénomènaux pour remonter une information ou prendre une décision ou faire re-descendre (on va facilement à des délais de 6 mois à 1 an pour prendre une décision). Et finalement ces équipes travaillent en parallèle entre les réunions, et leurs mebres ne communiquement pas : seuls les chefs commnuiquent.. Il y a là encore perte d'information, vu que certains s'occupent d'une partie, qui peut éventuellement recouvrir potentiellement une partie d'une autre équipe (dans le besoin réel, pas celui exprimé et découpé)

C'est à mon avis (de ce que j'en ai vu) justement les grandes raisons d'échec du côté des professions médicales...

Quant aux devenirs des projets, tout dépend de quel point de vue on se place :

• Si l'on prend le point de vue du contribuable et d'une direction de projet "normale", ce sont tous des échecs : on a demandé à faire tel soft pour un montant estimé de tant et un délai estimé de XX. En général les délais ont triplé, voire quintuplé ou décuplé, les budgets aussi, et les résultats plus que mitigés (le point d'où est parti ce fil en est un exemple)
  
  
• Si l'on prend le point de vue des SSII, c'est un succès phénoménal : voilà maintenant 30 ans qu'elles remplissent leurs caisses à qui mieux mieux, en louant leurs employés à l'année , et en nombre plus conséquent...

Du point de vue des gouvernements, cela participe au discours sur "on favorise l'emploi"....

Je m'étais à l'époque engueulé avec le Directeur, car je disais : "je suis désolé, mais le BUT pour lequel on vous a donné de l'argent, c'est faire un logiciel, pas que vos employés payent des impôts...".

[Flaburgan]

T'as le code source et ?

Et tu patches \o/

[Franck Z]

Pour moi, à partir du moment où pour développer un système d'information, il est nécessaire de comprendre d'abord le modèle d'entreprise de l'entreprise où il sera installé, proposer un logiciel qui néglige le modèle d'entreprise d'un hôpital en faisant croire qu'il peut fournir une aide à la prescription (donc prétendre mériter la confiance des prescripteurs) alors qu'il ne traite pas des allergies médicamenteuses est une attitude coupable de la part du développeur du SI.

[loufab]

Le développeur est le dernier maillon, je taperais un peu plus haut personnellement.

Mais sinon je prescrirais bien au responsable une lapidation à coup de figues molles ! Des fois qu'il y soit allergique (aux figues)...

[souviron34]

Je rajouterais un point pour appuyer sur un post qui semble être un peu passé inaperçu et qui , à mon sens, est pourtant très important sur un forum comme celui-ci :

Point de vue d'un médecin prescripteur pratiquant !
....
La conception des fonctions est souvent mauvaise.

Tout à fait, à mon avis en (très) grande partie à cause des raisons citées ci-dessus...

Par exemple :traiter "prescription" en écartant analyse, avis, dispensation, gestion pharmaceutique et aussi administration alors que les efforts liés à la certification récente ont portés sur le non recopiage d'information est rétrograde !

Là aussi.. C'était d'ailleurs le point central de notre proptoype (et de nos heurts avec l'équipe originale)

L'informaticien ne connait pas (il croit parfois les connaître) les métiers dans le domaine de la santé ! Il faut que l'équipe de conception s'enrichisse des compétences nécessaires et le budgète !

Tout à fait.. C'st bien pour ça que, que ce soit dans ce domaine - encore plus que dans d'autres, mais les autres relèvent cependant de la même problématique de fond - je prône une tête de projet bi-céphale un généraliste scientifique/informaticien (mais pas que) et un utilisateur (dans ce cas un médecin) reconnu par ses pairs et les autres professions visées (ici infirmiers, urgentistes, accueil, laborantins, pharmaciens, ménage, nutritionniste, etc)...

Et qu'on devrait absolument - ce qui ne peut pas être le cas avec de grandes équipes et des cycles en V, ni avec une vision "grosse SSII" - avoir des "couples" ou "binômes" informaticien/utilisateur pour chaque grande fonctionalité, travaillant ensemble avec (presque) toute la responsabilité de leur fonctionalité..

(ce qui en gros ne peut se faire que dans de petites équipes agissant en mode "agile")

C'est exactement la raison centrale de l'échec des grosses équipes et du cycle en V : les recueuils de besoins sont faits par des informaticiens, qu'ici aujourdhui on appelle des "MOA", dans un langage qui leur est propre, (et ont donc fait déjà une certaine traduction du langage utlisateur), retranscris pour la partie analyse par d'autres informaticiens (avec d'autres traductions) , retranscris ensuite différemment par les architectes, par les chefs d'équipe, puis par les programmeurs, chaque niveau ajoutant des déformations / approximations / traductions de son cru, et ça fait donc du "téléphone arabe" si vous me permettez l'expression...

Erreurs et approximations encore augmentées par les créateurs d'écrans, puis les rédacteurs du manuel, et enfin par les marketing et les brochures...

Sans compter des tests "au bout", une fois qu'on ne peut plus revenir en arrière sauf à tout refaire - ce qu'on ne fait donc jamais, donc on patch...

Considérer que la DB "médicaments" est incontournable est vicieux -au sens illogique- car elle même comporte des erreurs; le responsable doit rester le clinicien, le pilote, le pharmacien le garde fou !

Absolument...

Mais il semble que nous vivons dans un monde - voir plusieurs posts de ce fil - où on est persuadé que la machine fait mieux le travail que l'homme.... Et que toute "donnée" informatique est plus fiable que un humain ayant passé 8 ans d'enseignement spécialisé, sans compter 15 à 25 ans d'expérience...





Quant à la doc : dans le code, elle ne suit JAMAIS, même avec la meilleure méthode ISO, CMMI, ou autre, et dans le manuel utilisateur rarement... (si c'est des pages séparées, elle se perdent, ne sont pas envoyées à tous, pas tout le temps, ou avec un délai, ....)

La mise à jour de la doc technique d'un projet est une Grande Illusion des théoriciens - et de beaucoup de chercheurs et intervenants en "ingéniérie logicielle".... (la vraie mise à jour, j'entend, qui remonte jusqu"au document d'analyse initiale, aux diverses specs "d'en haut", etc...)... Je pense que je peux à peu près mettre ma main à couper que je n'ai jamais vu et ne verrai jamais - ni vous - aucun projet de plus de 5 ou 8 ans et de plus de 40 personnes dont les docs initiales sont mises à jour 8 ou 10 ans plus tard lors d'une modif assez importante...

[el_slapper]

(.../...)Quant à la doc : dans le code, elle ne suit JAMAIS, même avec la meilleure méthode ISO, CMMI, ou autre, et dans le manuel utilisateur rarement... (si c'est des pages séparées, elle se perdent, ne sont pas envoyées à tous, pas tout le temps, ou avec un délai, ....)

La mise à jour de la doc technique d'un projet est une Grande Illusion des théoriciens - et de beaucoup de chercheurs et intervenants en "ingéniérie logicielle".... (la vraie mise à jour, j'entend, qui remonte jusqu"au document d'analyse initiale, aux diverses specs "d'en haut", etc...)... Je pense que je peux à peu près mettre ma main à couper que je n'ai jamais vu et ne verrai jamais - ni vous - aucun projet de plus de 5 ou 8 ans et de plus de 40 personnes dont les docs initiales sont mises à jour 8 ou 10 ans plus tard lors d'une modif assez importante...

+1000 sur tout le reste(même si je n'y connais rien en médical).

Sur ce point là, j'ai déjà vu une doc technique à jour. Mais bon, c'était une équipe de 6, ça n'était pas un vrai langage de programmation(RdJ), et ça avait 3 ans d'âge. Ca coutait très cher et ça n'apportait pas grand chose. Un accès(en lecture) de la MOA au paramétrage source aurait fourni les mêmes services que d'avoir ce doublon.

D'ailleurs, sur la partie programmée, en Cobol, il n'y avait pas ce genre de doc, et la MOA farfouillait souvent dans le code..... ce qui marchait très bien. L'aspect "verbeux" du cobol et la grande quantité de commentaires les ont beaucoup aidés, aussi.

[souviron34]

Disons que j'aurais dû dire "pour le code" et non "dans le code"...

C'est à dire la doc telle qu'elle est envisagée dans l'ensemble des méthodologies de développement/gestion de projet....

(en distinguant donc celle-là de celle à destination des utilisateurs)

[nadine.mauch]

Evidemment qu'il ne faut pas revenir au tout papier !
D'après moi dans les réflexions qui précèdent l'essentiel a été dit :
- l'informatique n'est pas sans bogues
- dans la santé comme dans les autres domaines l'informatique et l'utilisateur forment un binôme, l'informatique automatise, accélère, ... les traitements mais rien ne remplace l'oeil expert d'un utilisateur averti
- c'est vrai aussi que souvent l'informatique sert de coupable aux erreurs "de l'interface chaise/écran"
Je suis prestataire dans le domaine de l'informatique médicale depuis 20ans et je crois qu'il y a quelques points qu'il faut évoquer :
- parfois l'équipe médicale manque de moyens et de temps pour s'occuper aussi de l'informatique
- parfois les sociétés d'informatique ne consacrent pas le temps nécessaire aux tests/docs/formations/... pour des raisons économiques
- parfois le responsable informatique du site n'est pas un informaticien et donc pas un professionnel du domaine et n'a peut être pas un jugement d'informaticien sur la qualité du logiciel qu'il choisit
- parfois l'achat est fait sur appel d'offre et donc une gestion comptable de l'acquisition
- parfois (pour gratter) on ne souscrit pas de maintenance ni de formation parce que tous les utilisateurs ont de l'informatique à la maison et savent donc s'en servir
- et (enfin?) l'argument qui tue et revient sans cesse est que tout le monde est informaticien et donc "quand on sait pas comment procéder on demande à quelqu'un en interne qui sait !"
Tous ces éléments mis bout à bout font de l'informatique actuelle ce qu'elle est.
Et dans le fond le problème n'est pas un problème d'informatique pure mais de la façon dont on la considère et l'utilise actuellement.
Bref on revient aux grands sujets de société ...

[souviron34]

.
Bref on revient aux grands sujets de société ...

J'ajouterais d'ailleurs un point, qui rejoint le thread sur les Cahiers des Charges, et plusieurs autres :

le fond de tout est le fait que (beaucoup) de gens s'écrasent et ferment leur g.eule quand ils ne sont pas d'accord avec une déciision... Bref des gens qui ne savent pas dire non..

Très souvent par peur de non-avancements futurs, donc par carrièrisme..

Que ce soit au niveau programmeur, chef d'équipe, CP, gestionnaire, gestionnaire au Ministère, etc...


Alors bien entendu il faut avoir des arguments, et ne pas faire de l'obstruction systématique... (ce qui est un peu diffciile dans le contexte français).

Mais cependant le fait de dire "non" est bien souvent plus une promesse d'avancement futur (et de réussite des projets..) que le fait de s'écraser.. .



C'était ma pensée du jour

[niarkyzator]

Ces gens devrait demander des cours à Linus Torvald ! Lui il sait crier quand il faut

[Fagus]

Ces softs devraient en effet être open source, c'est une question de salut public.

Ah non, surtout pas ! C'est déjà tellement affolant en terme de sécurité qu'il ne manquerait plus que ça. Des groupes malintentionnés auraient alors un angle d'attaque particulièrement aisé, sachant que l'open source afficherait toutes les vulnérabilités sans que personne n'ait le temps de les corriger.

Je connais un peu l'APHP (le monstre qui gère les hôpitaux de Paris), où tous les postes sont sous windows XP (parfois en SP2...), avec le vieux IE 6 ± patché, flash d'il y a 2 ans et java made in sun. Les mots de passe (y compris admin) sont typiquement pegase036 (où 36, c'est un numéro qu'on incrémente à chaque fois que la politique impose de le renouveler).
Si on veut un accès au système, c'est simple : il suffit de verrouiller un compte (c'est simple, avec l'annuaire un papier qui traine on a les noms, il suffit de faire trois erreurs de saisie de mot de passe,) d'appeler le service info, de demander de le débloquer et ils génèrent un nouveau code qu'il donnent par téléphone.

L'autre jour, j'ai dévérolé à la main un poste qui infestait ma clé usb à chaque fois (pasque s'il faut attendre une intervention du service informatique en été, ça peut prendre un ou deux mois). C'était sous SP2, le malware avait les droits admin et le PC était un botnet. Les A-V étaient tués, etc. Ce truc mettait en communication le réseau interne APHP et un botnet... J'en ai parlé à un ou deux responsable qui ont fait preuve d'un désintérêt complet mêlé d'incrédulité modérée.

Je parle pas des PC en mode admin branchés au réseau avec les codes en clair dans le registre.

Je ne parle pas de la direction qui trouve pertinent de déployer un logiciel médical critique, pour qu'on remarque à postériori qu'il est farci de bugs empêchant le travail normal, qu'il faudrait 6 Go de RAM (vs 2 dans la version précédante) sur des PC 32 bit dans un parc XP... (pendant que les deux informaticiens compétents sur ce logiciel sont simultanément en vacances : bilan deux semaines d'arrêt d'une partie du travail médical...)

Je ne parle pas du couple firewall/A-V qui à la grande surprise (et colère) du service informatique laisse passer tous les remote administration tools (troyen) légaux commerciaux... depuis des années, sans correction.