Pour être confronté au quotidien à une gestion de changement qui a tendance à devenir quelque peu hystérique par moment, je suis particulièrement sensible à tout ce qui pourrait améliorer la fluidité de ce process sans en perdre les qualités essentielles. Le mouvement DevOps, initié depuis quelques temps est désormais sur toutes les lèvres et sonne comme une sorte de nouveau “Saint Graal” des productions IT : agilité, qualité, intégration des équipes, responsabilité partagée etc. … Certes, sur le papier, comme toujours, la tendance DevOps semble être assez audacieuse – mélanger des équipes qui se haïssent cordialement depuis des années :) – pour qu’on se dise que finalement, ça mérite au moins d’étudier la question !
Avant d’essayer d’imaginer un Système d’Information Hospitalier fonctionnant en mode DevOps, rappelons que le principe de ce mouvement consiste en gros et de mon point de vue à réorganiser complètement les équipes d’une production donnée en transformant l’organisation en couche Dev|Test|Prod vers une organisation verticale de type Appli1 (DevTestProd) | Appli2 (DevTestProd) etc. … chaque membre de ces cellules AppliX pouvant bien entendu être aussi présent dans les cellules AppliY-Z adjacentes. Dans la pratique, il s’agit donc de tenter de regrouper les équipes de Développement et de Production, dont les objectifs historiques sont a priori opposés, au sein d’une même entité chargée collégialement de respecter tous les engagements de qualité : stabilité, robustesse, mais aussi agilité des changements et accélération du cycle de vie des applications.
Pour parler plus spécifiquement de l’IT dans le monde de la santé en France, il faut d’abord bien comprendre l’environnement dans lequel nous évoluons. Je vais parler ici de notre cas particulier, mais on peut sans aucun problème l’exporter à d’autres entités du même type et même taille. D’abord, les domaines fonctionnels couverts par les systèmes d’informations hospitaliers aujourd’hui sont énormes : le dossier patient, noyau de notre SI bien sûr, mais aussi la radiologie, la pharmacie, la biologie, la génétique, tout le périmètre RH, la facturation (entrante et sortante), la sécurité, la vidéo-surveillance, la visio-conférences, la téléphonie, les services web, le support logistique et les inventaires, la blanchisserie, les cuisines, la stérilisation, sans oublier le pilotage financier ou la recherche clinique et j’en passe … Aujourd’hui ce sont, pour notre exemple, plus de 240 applications identifiées et présentes dans notre porte-feuille de production. Mais à cela, vous devez ajouter des tonnes (des centaines probablement) de petites applications autonomes ou dépendantes de ressources externe sur Internet, permettant à l’ensemble du personne soignant, notamment, d’échanger avec leurs homologues dans le monde entier.
De plus, les enjeux informatiques des prochaines années sont considérables pour les hôpitaux : maîtrise, voire réduction, des coûts alors que le périmètre couvert ne cesse de grandir, numérisation et dématérialisation de l’ensemble des processus métiers (ce qu’on appelle chez nous “L’Hôpital numérique”), amélioration de la qualité de service, prise en compte des problématiques spécifiques de la télé-médecine etc. …
Dans ce contexte, aujourd’hui, nous sommes organisés de manière assez classique autour des fonctions “build/run” avec :
– un service de MCO/Production chargé du bon fonctionnement du système d’information et de la gestion de ses incidents quotidiens
– un service dont je m’occupe, chargée d’assurer les fonctions de responsable technique auprès de nos responsables d’applications ainsi que de l’évolution des infrastructures de soutient du SIH
– un ensemble de chefs de projets applicatifs chargés de tous les aspects métiers, AMOA et contractuels des applications existantes et nouvelles
Enfin, donnée importante, nous avons fait le choix “progiciels” depuis plusieurs années déjà, aussi, nous ne disposons plus de service de développement spécifique.
Connaissant tout cela et pour revenir au sujet après cette longue introduction, est-il possible d’envisager une autre organisation que celle que nous connaissons aujourd’hui ? A forcieri, pourrait-on envisager une approche DevOps, ou plutôt une approche “AppOps” dans notre cas ? Et plus important encore, est-ce que cette nouvelle organisation nous apporterait les bénéfices attendus ?
Pour tenter de répondre à cette question complexe, il faut déjà adapter l’approche DevOps à notre cas particulier. Il est littéralement impossible d’envisager une telle organisation sur l’ensemble des applications du SIH : trop de granularité, trop de complexité et surtout, des fournisseurs dont, pour l’essentiel, le niveau de maturité face à ces nouvelles méthodes est proche de zéro. Par contre, en sélectionnant certaines applications (et ce faisant, certains fournisseurs), je pense qu’il est possible d’appliquer les règles du DevOps à celles-ci et d’y gagner en réactivité et qualité. Les critères qui prévalent, de mon point de vue, seraient les suivants :
– La capacité de l’éditeur de la solution à nous suivre dans cette voie. C’est en effet un point crucial, n’étant pas propriétaires et développeurs de nos applications, il faut absolument intégrer le fournisseur dans ce process et travailler avec lui sur cette ré-organisation.
– Nous devons parfaitement maîtriser la solution elle-même : il faut donc que ce soit une application déjà en production depuis longtemps pour connaître ses forces et surtout ses faiblesses.
– Les gains potentiels doivent être substantiels, au moins à l’échelle de l’application elle-même, et pouvoir être estimés assez facilement : en effet, pour être en mesure de “perturber” une organisation de production dans un environnement très stressé comme l’est tout hôpital aujourd’hui, on doit présenter des gains importants et rapides, sinon, le management ne suivra pas.
Si l’on fait la somme de ces critères, les applications clientes se réduisent beaucoup, malheureusement. A partir des 240 applications connues et exploitées dans un mode build/run, celles qui sont éligibles aujourd’hui doivent se compter sur les doigts d’une seule main. C’est peu, en particulier à cause du premier critère “fournisseur”, la santé n’étant pas un monde rempli d’éditeurs très innovants et disruptifs, c’est le moins que l’on puisse dire. A leur décharge, les périmètres fonctionnels couverts sont, pour beaucoup, extrêmement sensibles et touchent de près ou de loin au patient.
Alors, aujourd’hui, quel pourrait être le potentiel et surtout l’impact d’une approche DevOps au sein d’une production informatique d’un centre hospitalier ? En l’état et à ce jour, je suis plus que réservé sur son importance, d’autant que cela bouleverserait aussi beaucoup notre organisation actuelle que nous avons déjà mis quasi 10 ans à mettre en place !
Ceci étant, la force que nous avons et que j’ai déjà évoqué ici, c’est l’explosion annoncée du périmètre de notre couverture fonctionnelle dans les prochaines années. Nul doute que cela nous offrira des opportunités sur des sujets où la réactivité et le professionnalisme des éditeurs fourniront l’élan nécessaire à cette transformation en profondeur. Je ne doute pas qu’à terme, cela nous apporte beaucoup et puisse contribuer à relever le défi hospitalier des années 2015-2020.