Dans beaucoup d’établissement de santé, il y a des petits irritants que tout le monde connaît. Que ce soit un planning qui est tenu sur un tableau blanc ou bien un suivi de stock qui est refait à la main chaque semaine. Aujourd’hui les outils d’IA permettent de créer une application à la volée quasiment. Ce qui peut régler ce type de problème sans savoir coder. Et c’est devenu un jeu d’enfant.

Dans la santé en général et plus particulièrement en établissement, il faut quand même le faire en faisant attention aux patients, aux collègues et à l’établissement lui même. Cet article s’adresse à deux profils, d’une part les professionnels médicaux mais aussi paramédicaux ou administratifs qui veulent se lancer, et aussi aux directions qui ont pour objectif d’accompagner ces projets. Ce dernier point permettant de ne pas découvrir les projets une fois qu’ils sont en place.

Ce qu’on peut faire seul et ce qu’on ne fait pas seul

Le livre blanc présente le cadre CLAS, qui classe les applications par niveaux de maturité. Pour démarrer, ce sont les deux premiers niveaux qui sont concernés.

Le premier niveau, c’est le prototype. L’application reste dans le service qui l’a créée. On ne lui demande pas autre chose que d’être utile, et ce sont ses utilisateurs qui assument son usage. Ça peut être un suivi des commandes de l’unité, un tableau de répartition des tâches ou un formulaire qui remplace un fichier partagé. L’application ne sort pas du service.

Le deuxième niveau, c’est le niveau bronze. L’application a été utilisée, elle fonctionne, et d’autres services veulent l’utiliser aussi. Pour passer à ce niveau, elle doit être validée par ses utilisateurs, elle ne doit pas contenir de données de santé, et son code doit être déposé sur l’infrastructure de l’établissement. Elle est ensuite ajoutée au catalogue interne.

Il y a ensuite les applications qu’on ne fait pas seul. Ce sont celles qui utilisent des données patients et celles qui aident à une décision clinique, par exemple un calcul de dose, un score ou une alerte. Ces applications peuvent être considérées comme des dispositifs médicaux, avec des obligations réglementaires qui s’appliquent. Elles ne sont pas interdites, mais elles doivent passer par la DSI, par le DPO et par le circuit habituel de l’établissement.

La règle à retenir est la suivante : si l’application utilise des données patients ou si elle a un effet sur un soin, elle ne se construit pas seul.

Déclarer son projet avant de commencer

Avant de commencer à utiliser un outil, il faut informer la personne qui suit ces sujets dans l’établissement. Selon les établissements, ça peut être le référent IA, la DSI ou la direction de l’innovation. Il n’y a pas besoin d’un long document. Il suffit d’indiquer ce qu’on veut faire, pour quels utilisateurs et avec quelles données.

Ça peut paraître administratif, mais c’est ce qui permet à l’application d’être protégée. Une application qui est connue peut être soutenue, reprise par quelqu’un d’autre ou proposée à d’autres services. Une application qui est découverte le jour où elle tombe en panne risque d’être arrêtée.

Décrire ses besoins avec des user stories

Une erreur fréquente consiste à demander directement à l’IA de faire une application de gestion des stocks. L’IA va produire une application de gestion des stocks, mais qui ne correspondra pas au fonctionnement du service.

Pour éviter ça, on peut utiliser une méthode que les développeurs utilisent depuis longtemps, la user story. Chaque besoin est écrit en une phrase, du point de vue de la personne qui va utiliser l’application :

En tant que [qui], je veux [faire quoi], afin de [obtenir quel bénéfice].

Pour une application de gestion des stocks, ça peut donner les phrases suivantes :

• En tant qu’infirmier, je veux signaler qu’un produit arrive en rupture, afin que la commande soit passée avant le week-end.
• En tant que cadre de santé, je veux voir la liste des produits qui sont sous le seuil d’alerte, afin de valider les commandes en une seule fois.
• En tant que cadre de santé, je veux modifier les seuils d’alerte, afin de les adapter à l’activité du service.

Pour chaque story, on ajoute un ou deux critères d’acceptation. Un critère d’acceptation, c’est la condition qui permet de dire que la fonctionnalité est terminée, par exemple : le produit signalé apparaît dans la liste du cadre en moins d’une minute. Ces critères servent à tester l’application, et ce sont aussi les informations que l’IA comprend le mieux.

Les stories sont à écrire avec les collègues qui vont utiliser l’application, parce qu’ils connaissent des cas particuliers auxquels on ne pense pas forcément seul.

Construire une fonctionnalité après l’autre

Quand les stories sont écrites, il vaut mieux ne pas toutes les donner à l’IA en même temps et construire l’application fonctionnalité par fonctionnalité.

On commence par le minimum, c’est-à-dire la story sans laquelle l’application n’a pas d’intérêt. Dans l’exemple des stocks, c’est la liste des produits et le signalement de rupture. Les autres fonctionnalités viennent après.

Pour chaque fonctionnalité, on donne une seule story à l’IA avec ses critères d’acceptation. On teste le résultat, on corrige, et on passe à la story suivante.

Il faut aussi sauvegarder chaque étape qui a été validée. La plupart des outils ont un historique des versions, et beaucoup permettent une synchronisation avec GitHub. Si une modification casse une fonctionnalité qui marchait, on peut revenir à la version précédente.

Il est utile de faire tester l’application par un collègue dès la première fonctionnalité, parce qu’il va souvent trouver rapidement des problèmes qu’on n’a pas vus.

Avec cette méthode, si le projet s’arrête avant la fin, il reste quand même une application qui fonctionne, même si elle n’a pas toutes les fonctionnalités prévues.

Préparer la base de données avant de la demander

Si l’application doit enregistrer des informations, elle a besoin d’une base de données. Les outils actuels peuvent la créer, souvent avec Supabase, mais le résultat ne sera pas bon si on ne sait pas quelles informations on veut y mettre.

Le plus simple est de faire la liste, sur papier, des éléments que l’application utilise et des informations associées à chaque élément. Pour la gestion des stocks :

• Produit : nom, référence, seuil d’alerte, quantité en stock
• Signalement : produit concerné, date, auteur, statut
• Utilisateur : nom, rôle

On donne ensuite ce schéma à l’IA, en lui demandant de créer les tables correspondantes, puis de relier chaque fonctionnalité à ces tables. Ça permet de garder la main sur la structure et de savoir où sont stockées les informations.

Il y a trois règles à respecter.

• Pendant la construction, on utilise uniquement des données fictives. On ne met pas de noms de patients, même pour faire un test.
• On ne met pas de données de santé dans l’application tant qu’elle est au stade de prototype et qu’elle n’a pas passé les étapes prévues pour ça.
• Il faut demander explicitement une authentification, et que chaque utilisateur n’ait accès qu’aux informations qui le concernent. Si on ne le demande pas, l’IA ne le fait pas toujours.

Choisir un outil

Aujourd’hui, trois outils permettent de créer une application complète à partir d’instructions, sans compétence technique : Google AI Studio, Bolt et Lovable. Il en existe d’autres bien évidemment, mais sont moins adaptés pour quelqu’un qui ne sait pas coder.

Ces trois outils sont des SaaS (accessible via votre navigateur), ce qui les rend simples à utiliser. Mais ça veut aussi dire que tout ce qui y est saisi sont enregistrer par ces plateformes. Ils est donc préférable de les utiliser pour faire un prototype ou alors de soumettre des données fictives.

Pour choisir entre ces outils, il y a quatre questions à se poser.

• Où vont les données ?
• Est-ce qu’on peut récupérer le code ?
• Qui paie et combien ?
• Qui peut reprendre l’application si on part ?

Le passage au niveau supérieur, le niveau bronze correspond au moment où l’application quitte ces outils pour aller dans l’environnement sécurisé et maîtrisé, notamment par votre établissement. Le livre blanc décrit une plateforme hébergée en interne, basée sur de l’open source, qui permet de continuer à travailler de la même manière.

Rédiger une page avant la mise en service

Avant la mise en service d’une application, il y faut rédiger une page qui indique :

• à quoi sert l’application et qui l’utilise ;
• où se trouvent le code et les données ;
• comment le service fonctionne si l’application ne fonctionne plus. Car quand on remplace un processus papier par une application, le processus papier risque de disparaitre. En fait il disparait même quasiment à chaque fois, ou du moins il est relégué dans un tiroir d’où il risque jamais de ressortir.
  Le jour où il y a une panne significative ou une cyberattaque, il faut pouvoir revenir à un fonctionnement sans l’application ;
• qui peut reprendre l’application suite au départ de la personne qui l’a créée.

Cette page permet que l’application soit un outil du service et non pas l’outil de la personne qui l’a créée.

Encadrer plutôt qu’interdire

Des applications sont déjà construites dans la plupart des établissements. L’enjeu, c’est donc que ces app soient connus, qu’elles soient sûrs et qu’elles puissent durer.

Ce que je décris ici, c’est la réponse à l’échelle d’un porteur de projet. La réponse à l’échelle d’un établissement se trouve dans le livre blanc Vibe Coding en santé. Il couvre l’organisation, la gouvernance et la plateforme qui permettent d’accompagner ces initiatives au lieu de les subir.
Recevoir le livre blanc