Développement agile et accompagnement au changement en GHT

Nous fêtons cette année les 60 ans du traité de Rome. L’Europe a beaucoup occupé les débats en cette année électorale… Et la conseillère régionale en charge des Fonds européens, qui animait l’événement annuel des programmes européens de ma région la semaine dernière, a bien pris soin de rappeler à l’assistance tout ce que l’Union européenne nous apporte depuis soixante ans : la paix (bien évidemment et on l’oublie souvent…), mais aussi des financements.

Le Fonds européen de développement régional (Feder) finance ainsi une bonne partie de l’innovation informatique de santé de mon GHT (j’y reviendrai plus en détail le mois prochain dans une tribune dédiée aux financements de l’e-santé). Et j’étais donc présent, pour la première fois, à cette Journée européenne de retours d’expériences, devant un parterre d’élus régionaux, de représentants de l’UE et de professionnels de tous horizons.

Juste après l’utilisation des fonds européens pour la formation professionnelle des jeunes ou l’insertion des migrants et juste avant la dernière innovation dans le domaine de la congélation des cols de bouteilles de champagne, j’ai donc présenté deux années de développement du portail sécurisé ville-hôpital MyGHT.

Au-delà de l’ergonomie et des services rendus par la version actuelle du portail (dans le domaine du handicap, du maintien de la personne âgée à domicile, du lien familial en Ehpad, de la conciliation médicamenteuse, etc.), ce qui a séduit les élus, c’est la méthode utilisée et les résultats obtenus sur une aussi courte période et un territoire aussi étendu.

Je suis reparti ravi d’avoir suscité leur intérêt et j’ai compris que le modèle serait certainement proposé à d’autres territoires en France et en Belgique (les dynamiques de territoires de soins sont très comparables dans les deux pays, et l’Europe finance quand elle estime que le sujet peut potentiellement être reproduit ailleurs), mais cela m’a surtout conduit à analyser les deux années écoulées et à essayer de modéliser la méthode qui, il faut bien l’avouer, diffère singulièrement de la manière dont j’avais géré des déploiements informatiques hospitaliers pendant les 20 dernières années…

À l’hôpital, il existe deux types de projets informatiques : ceux qui sont imposés par les tutelles, qui font grincer les dents des réfractaires mais qu’on mène à terme quand même (parce qu’ils sont obligatoires et que de fortes pressions pèsent sur l’établissement) et ceux qui sont souhaités par un service ou un corps de métier. Dans le deuxième cas, le processus de rédaction du cahier des charges avec les référents « métiers », puis la longue démarche d’appel d’offres amènent les intéressés à se convaincre eux-mêmes qu’ils ont choisi la meilleure solution logicielle du marché et à devenir ensuite les ambassadeurs du système choisi auprès de leurs collègues : le processus d’acceptation de l’outil informatique se fait naturellement, comme une tache d’huile, par les utilisateurs concernés. Et le chef de projet informatique hospitalier est surtout le garant du respect du CCTP et du planning par le fournisseur.

Quand on se lance dans un projet de territoire de soins numérique, dans un bassin de plusieurs milliers de kilomètres carrés, avec des milliers de professionnels de santé, publics et privés, des secteurs sanitaires et médico-sociaux et dans un contexte d’offres de soins souvent concurrentiel, il n’est pas si aisé :

• de choisir un outil commun et une ergonomie qui convienne à tous ;
• de mener un projet qui ne s’essouffle pas faute de relais suffisant sur le terrain ;
• et de ne pas générer des tensions entre les acteurs, alors qu’on veut simplement créer du lien ville-hôpital…

Ce qui rassemble les professionnels, au-delà des murs de leur établissement ou de leur secteur d’activité, ce sont les ordres, les syndicats, les URPS et autres corporations professionnelles.

C’est sur cette base que s’est construit MyGHT. Et cette méthode présente plusieurs intérêts :

• si le syndicat a validé le concept, il se l’approprie et va le défendre auprès de ses membres (il se charge d’ailleurs d’une grande part de la communication locale, régionale et nationale) ;
• si l’ordre départemental a le sentiment qu’un sujet va faire polémique ou amener de mauvaises pratiques (la concurrence déloyale et le libre choix du patient…), il va se charger de poser les bonnes questions à l’ordre national qui tranchera ;
• et l’URPS dispose des leviers et des réseaux pour associer, selon les sujets, les acteurs institutionnels (CPAM, ARS, etc.) et légitimer les besoins informatiques, dans des secteurs qui n’avaient jusque-là jamais été informatisés.

Le reste relève de la gestion de projet, de la patience et de la rigueur :

• on commence par réunir les représentants concernés par le module qu’on veut développer (par exemple les professionnels du handicap) en présence des développeurs ;
• on leur demande d’expliquer leur organisation actuelle, leurs contraintes, leurs attentes et leur vision a priori de l’outil informatique (ce qui permet aux informaticiens de s’imprégner progressivement de thématiques qu’ils ne connaissaient pas nécessairement) ;
• on dessine sur paperboard les ébauches des premiers écrans et on discute des workflows envisageables ;
• on se propose de se retrouver le mois suivant pour une présentation des maquettes réalisées par les informaticiens (des mocks-up), que les professionnels pourront critiquer et modifier progressivement au fil des réunions ;
•  et puis un jour (en général au bout de trois mois), la maquette est validée et les ergonomes prennent le relais pour proposer des maquettes qui ressembleront davantage aux écrans finaux. On repart alors pour au moins trois mois de discussions/modifications…

Ce n’est qu’à l’issue de la validation des maquettes finales que les développements seront lancés et testés dans un secteur pilote pendant plusieurs mois, afin d’éliminer les bogues résiduels et de régler les derniers détails, dans une sorte de vérification en service régulier. Moyennant quelques soirées d’information aux professionnels concernés et la mise en place d’une organisation centralisée (par exemple, deux pharmaciens de ville représentent leur centaine de collègues et peuvent se permettre de demander des évolutions), le projet va alors passer en mode routine : on aura mis une année à le déployer (et la difficulté d’un tel chantier réside donc dans la capacité à gérer en parallèles plusieurs dossiers), mais sa base sera suffisamment solide pour en assurer la pérennité.

Tout cela repose, bien évidemment, sur le choix d’un partenaire informatique habitué au développement agile, capable de développer vite et bien et de proposer des interlocuteurs armés de patience pour assister à des réunions où seul le quart des discussions sera consacré à l’informatique, car le plus important reste la prise en compte des usages métiers !

L'auteur 
Michaël De Block est directeur de l’information numérique des Hôpitaux de Champagne Sud et administrateur du groupement de coopération sanitaire Santé Numérique, GCS de moyens informatiques du GHT de l’Aube et du Sézannais.