invite a écrit :Stéphane Bernabé a écrit :Bonjour,
pour la compta, rien à faire, aucun logiciel n'est compatible avec ses voisins, chacun ayant fait des choix techniques et de codification qui lui sont propres. Aucune passerelle n'est possible.
Pour les données des patients, il faut poser la question à votre commercial chez nous. Les données de K+4000 sont cryptées (illégal à ma connaissance), et nous avons toujours du mal à en extraire quelques bribe d'informations exploitables.
Contactez-nous pour faire un état des lieux sur le sujet avant le changement de logiciel : après le démarrage sous Vega, plus d'importation possible de quoi que ce soit...
J'ignore si les fichiers VEGA sont cryptés, mais ce qui est sur , c'est que ceux de KINE+4000 (et autres série 4000) sont CRYPTES , mais seulement dans la version actuelle V7 (pas dans la V6 précédente) ;
et que ce cryptage est avec code secret connu uniquement du fabricant, interdit de le révéler aux usagers (et là, d'accord avec BARNABE , c'est illégal
).
Par contre, à sa défense, le fabricant donne dans le logiciel une fonction d'EXPORTATION des données en format dit standard ouvert XML , et effectivement cela permet d'avoir toutes les données en clair, mais pour les utiliser en pratique, il faut beaucoup d'huile de coude !
Cette fonction d'exportation XML a été développée par cet éditeur pour "faire plaisir" à la FFMKR, dont l'adresse parisienne était pendant longtemps située dans ... le même immeuble que l'agence commerciale dudit éditeur ! Éditeur pour lequel j'ai par ailleurs la plus grande estime, pour avoir durant un temps côtoyé certains de ses membres lors de réunions de travail, quelques années durant.
Pourquoi "faire plaisir" ?
Il y a quelques années, les gens de la FFMKR ont "
convoqué" les deux principaux éditeurs du marché (RMI et nous) pour nous imposer la réalisation de fonction d'export de données au format XML. Ils avaient entendu dire que XML était un format standard, et en avaient déduit qu'un export de données à ce format permettait à un MK de quitter son éditeur s'il le voulait. En tant que syndicat majeur de la profession, la Fédé a estimé pertinent de prendre une position ferme envers les éditeurs et de leur imposer un comportement assurant la liberté des utilisateurs. Plutôt une bonne idée en soi, même si les moyens mis en œuvre pour la réaliser (la coercition) me semblaient dater d'un autre temps... Comme le sujet me tient à cœur depuis longtemps, j'y suis allé...
Mon homologue rodézien a abondé dans le sens fédéral, brossant notre interlocuteur dans le sens du poil :
un export au format XML est effectivement ce qu'il y a de mieux pour garantir la liberté de nos clients d'aller voir ailleurs. ce doit être gratuit. Tous les éditeurs doivent le faire. Il est légitime de l'imposer aux éditeurs. Chacun saura par la suite intégrer les XML des concurrents en cas de besoin...
Pour ma part, hormis mon hostilité à me voir imposer des développements informatiques par des personnes peu au fait de la chose, j'ai fais deux remarques que je vous livre à nouveau :
- sans un dictionnaire de données commun, définissant a minima les noms, types, positions des données et de leurs relations, un export XML est tout à fait inutile ;
- sans un module d'importation capable d'exploiter ce cahier des charges, imposé aux éditeurs par des gens compétents, un export de données ne rend pas l'utilisateur libre. C'est ce qui se passe aujourd'hui : l'export XML de RMI n'est pas documenté, n'est pas "standard", et ne sert finalement à rien pour ses clients.
Rappelons qu'XML c'est un peu comme convenir d'utiliser l'alphabet latin au lieu d'idéogrammes coréens. Sans vocabulaire, grammaire et conjugaison commune, on ne se comprend pas et on passe son temps à mal traduire...
Curieusement, notre interlocuteur fédéral n'a pas été sensible à mes remarques : l'expert informatique qu'il avait consulté (
dans le même bâtiment, vous vous souvenez) lui ayant dit que ces deux objections étaient inutiles, car un "
bon" éditeur sait se contenter d'un fichier XML, même non documenté...
Je suis resté un peu en froid avec les instances syndicales depuis lors.
Hormis RMI, qui a fait cavalier seul sur le sujet, aucun autre éditeur n'a obéi aux exigences fédérales. L'idée était pourtant bonne, pleine de bon sens, et je la défends encore régulièrement lorsque l'occasion se présente. Le travail à faire est considérable : établir un cahier des charges "a minima" cohérent, applicable par tous les éditeurs, documenté, avec une vraie procédure de validation : voilà qui serait un travail responsable de la part des syndicats et/ou des éditeurs. Les premiers ont suivi d'autres chemins de communication depuis lors; les éditeurs sont d'indécrottables concurrents dont la seule idée de coopérer à un projet qui pourrait leur faire perdre des clients prime sur l'idée que ce projet puisse leur en faire gagner. Ahurissant !
Pour éviter les désagréments que mes contributions produisent parfois, j'affirme que cet avis n'est que le mien, et n'engage nullement Epsilog. Si l'un des interlocuteurs cité souhaite des compléments, des rétractations ou des dédommagements (on 'en a déjà demandé suite à un vieux sujets parlant de skuds...), ce n'est pas à Epsilog qu'il faudra s'adresser.
