Comment se conçoit une mise à jour chez Epsilog ?

Rencontrez les autres végaliens dans cet espace dédié à l'entraide.
Questions et réponses sur l’utilisation de Vega, discussions sur l’informatique de santé,
cet espace est le votre : partagez vos expériences !
Répondre
Avatar du membre
Stéphane Bernabé
Administrateur
Administrateur
Messages : 2540
Enregistré le : ven. déc. 29, 2000 11:31 am
Profimage : E
Localisation : Castries (34)

Comment se conçoit une mise à jour chez Epsilog ?

Message par Stéphane Bernabé »

Une mise à jour d'un logiciel comme Vega est quelque-chose de relativement complexe, qui nécessite, il me semble, quelques explications.
Quand vous recevez une version de Vega (en tant que nouveau client ou à l'occasion d'une mise à jour), cette version est la seule qui soit commercialisée chez nous à ce moment là. Elle a été finalisée, documentée, testée, stabilisées et validée par notre équipe de "qualité". Dès cet instant, les "sources" en sont archivés, et les développeurs entreprennent une nouvelle série d'améliorations, corrections, adjonctions, etc.
Durant quelques semaines, rarement plus, ils peuvent apporter quelques corrections issues du terrain, sur certaines fonctions bien précises et limitées. Si ces corrections ne touchent pas au noyau de facturation du logiciel, il n'est pas nécessaire d'obtenir un nouvel agrément SESAM-Vitale. De telles corrections, rares chez Epsilog, font alors l'objet d'un "patch" correctif, mis en téléchargement. Jusqu'à ce jour nous n'avons jamais eu besoin d'envoyer à nouveau un CD de mise à jour quelques semaines après un premier envoi. J'aime à croire que nos développeurs et notre équipe de tests-qualité font bien leur travail...
En temps normal, et sauf en période de bouclage d'une mise à jour, nos développeurs travaillent donc sur la "prochaine" version de votre logiciel Vega. Et ils n'hésitent pas à modifier profondément certains de leurs travaux passés pour changer ou améliorer le comportement de tel ou tel pan de Véga. Qu'il s'agisse de programmes physiquement séparés (bilans, DSI, comptabilité, etc) ou non, le protocole reste invariant : tous les développements sont synchronisés en vue du bouclage d'une mise à jour complète, documentée, testée, stable et validée. Durant cette période, qui prends plusieurs mois généralement, aucune version intermédiaire ne peut être produite, tant il y a d'éléments "en chantier". Certains éditeurs sont familiers des mises à jour "à répétition", dont certaines s'enchaînent parfois au rythme de plusieurs par mois. Nous nous refusons à procéder ainsi, car dans ce cas il devient impossible de garantir à chacun de nos clients une qualité de logiciel (et donc de service) identique. Trop d'aspects de Vega sont en cours de modification pour que nous puissions nous-même avoir l'assurance de produire une version intermédiaire stable.
Ainsi, quand une réglementation change (arrivée de la DSI pour les infirmières, des bilans-diagnostics des MK l'an passé), nous choisissons toujours d'intégrer ces évolutions dans le cadre d'un planning cohérent de développement. Quitte à intégrer la chose en question non pas à la prochaine mise à jour, mais à celle d'après. C'est ce qui est en train de se passer pour la DSI, où les textes sont disponibles depuis longtemps, mais où nous avons voulu prendre le temps de concevoir un véritable outil professionnel. Les IDE qui l'ont vue la semaine passée en séminaire "VegaTropic" ont trouvé l'outil exceptionnel (y compris par rapport aux fonctions comparables dans d'autres logiciels). Mais il ne sera envoyé qu'avec la MAJ, car il n'a pas été documenté intégralement, pas été totalement testé, ni validé par notre équipe de "qualité".
Une exception a été faite à ce cas de figure, à propos des bialsn MK, lors du changement de la fiche de synthèse puis du changement de cotation de certains bilans. Pour le premier cas une rapide adaptation a été produite et mise à disposition de nos clients concernés, hors mise à jour, mais sans avoir subi une réelle phase de développement finalisé. C'est ce qui explique les critiques de certains à propos d'éventuels défauts d'impression sur quelques modèles d'imprimantes. Pour le second cas, la cotation "x.1" des bilans avait été programmée "en dur" dans Vega, puisqu'elle semblait être issue d'une mure réflexion des partenaires conventionnel, et destinée à assurer la traçabilité desdits bilans. Malheureusement, l'introduction d'une nouvelle cotation "x.1" ne peut à ce jour pas être intégrée à la verison 4.20 de Vega : il ne s'agit pas d'un simple paramétrage (nouveau formulaire, nouvelle NGAP, nouvelles tables de caisses ou de tarification), mais bl et bien d'un comportement intrinsèque de Vega. Ce point a déjà fait l'objet de la correction nécessaire, mais celle-ci ne pourra par nature être disponible qu'à compter le la prochaine MAJ.
Pour formuler différement, imaginez que Vega est un véhicule automobile. Imaginez que votre concessionnaire vous offre la possibilité de changer de modèle à chaque sortie planifiée par le constructeur. Ainsi, un jour, vous bénéficiez de la correction électronique de trajectoire, de la climatisation automatique individualisée, d'une boîte multitronic ou séquentielle, d'un nouveau coloris d'habillement intérieur, etc. Tout ça compris dans votre contrat d'entretien. Hors contrat d'entretien, vous avez aussi la possibilité de racheter un nouveau modèle, en échange du vôtre, à votre convenance.
Maintenant, quand un constructeur modifie le chassis de son véhicule, et qu'il doit ainsi repenser l'implantation de tous les éléments mécaniques, électroniques, décoratifs, etc, on comprends aisément qu'il n'est pas possible d'exiger de lui l'intégrer ce nouveau chassis dans un modèle actuellement en circulation. Si c'est possible pour certains détails (on peut repeindre une voiture ou en changer la forme des ajntes), il y a des améliorations qui ne peuvent se concevoir qu'au travers de la sortie d'un nouveau modèle.
C'est pareil pour un logiciel, même si le côté "abstrait" de la chose et l'apparente simplicité de certains correctifs rendent l'analogie dérangeante...
Etre abonné aux services annuels d'un éditeur (Epsilog ou un autre), dans le cadre de l'usage d'un logiciel professionnel, me semble dès lors une nécessité impérative : même si vous n'avez pas la certitude d'obtenir immédiatement tous les correctifs personnels ou réglementaires que vous attendez, vous avez l'assurance que votre éditeur en tiendra compte, et vous fournira ce qu'il faut. Après, ce qui différencie certains éditeurs, ou ertaines équipes de développement, c'est leur capacité à répondre plus ou moins rapidement à ces attentes. Et la capacité de le faire avec professionnalisme et qualité de production. Il ne sert à rien d'envoyer une MAJ hâtive pour répondre aux demandes de certains clients si l'on sait qu'elle devra fair l'objet de multiples correctifs par la suite. Mais inversement, cette attitude que je juge comme non-professionnelle a le mérite de calmer les tensions et d'appaiser les critiques. Alors, quel est le bon choix ?
Stéphane Bernabé
"Si on paie ceux qui ne travaillent pas et si on impose ceux qui travaillent, il ne faut pas s'étonner si le chômage augmente."
Milton Friedman, prix Nobel d'économie en 1976

... et dans un autre domaine
- Pensée unique
Chris

Re: Comment se conçoit une mise à jour chez Epsilog ?

Message par Chris »

Je pense qu'une majorité de clients ont compris votre démarche Stéphane.
Je suis moi même embêté par une fonction que vous refusez d'intégrer dans Vega (cf déselectionner les FSE, pour décaler la date d'envoie d'une partie de celles ci), mais je comprends parfaitement que les intérêts d'un concept entier, ne peuvent s'appliquer à chacune de nos petites envies et désirs : et c'est la même chose pour les bilans : s'il faut attendre un petit peu, on attendra, car on est pas à quelques mois prés non plus, et j'avoue que cette polémique sur les bilans depuis un certain temps commence franchement à m'irriter, d'autant que l'on parle d'un ecart d'un seul coefficient, et d'une question de présentation provisoirement "foireuse".....
Cependant, soyez assuré Stéphane, que si le manque à gagner de ce coefficient manquant se révèle désastreux pour la survie de mon cabinet, je vous en tiendrais pour personnellement responsable, et vous assignerais en justice... :op
Répondre