Il y a des applications qui tournent dans chaque établissement et dont personne ne parle. Ce n’est pas une hypothèse. C’est le cas partout, et c’était déjà vrai avant l’IA générative. La question n’est donc plus de savoir si ces outils existent. Elle est de savoir à quelles conditions on accepte qu’ils existent au grand jour. C’est exactement ce que la labellisation des applications développées en interne permet de trancher.

Le shadow IT hospitalier, ce qui tourne déjà dans nos services

Un fichier Excel qui pilote un planning de garde depuis 6 ans.
Une base Access héritée d’un cadre parti à la retraite, que plus personne ne sait modifier.
Un formulaire en ligne qui collecte des données de suivi.
Un groupe de messagerie qui sert de transmission entre deux unités, parce que l’outil officiel est trop lent.

Rien de tout ça n’apparaît dans la cartographie du système d’information.

Et pourtant tout ça existe pour une raison très simple. Un besoin réel qui n’a pas trouvé de réponse dans le circuit officiel, et quelqu’un s’est débrouillé. On appelle ça du shadow IT. Le terme fait peur, il désigne surtout des gens qui essaient de bien faire leur travail.

Maintenant, comment est-ce qu’on les découvre, ces outils ? Presque jamais par un inventaire. Un agent part, et le fichier cesse de fonctionner. Un patient exerce son droit d’accès et personne ne sait où sont ses données. Un audit demande la liste des traitements, il manque une ligne.

Vous voyez le problème. On découvre toujours ces applications au pire moment, celui où la conversation avec la personne qui l’a construite est impossible à tenir calmement.

Ce qui change aujourd’hui, c’est le coût d’entrée. Bricoler un outil en parallèle demandait jusqu’ici une compétence rare, celle de l’utilisateur avancé . Avec les IA génératifs, une phrase suffit à produire une application avec une interface, une base de données et une adresse web. Le vibe coding arrive à l’hôpital par la petite porte (smartphone, ordi perso…), exactement comme les LLM il y a 3 ans.

La différence, c’est qu’un chatbot produit du texte. Une application vibe codée, elle, stocke des données.

Interdire ou laisser faire : pourquoi les deux réflexes échouent

Le premier réflexe, c’est d’interdire. Note de service, rappel à l’ordre, point en instance.

Sauf que le besoin ne disparaît pas avec l’interdiction. Il descend d’un étage. Et vous vous retrouvez à protéger un système d’information dont vous ne voyez plus la moitié de ce qui tourne dessus, ce qui est à peu près l’inverse du but recherché.

Il y a plus embêtant. L’interdiction n’est pas applicable. Les outils concernés vivent sur des comptes personnels, depuis des téléphones personnels, en dehors du réseau. Aucune note de service ne va les atteindre.

Et puis interdire a un coût que personne ne calcule. Ça revient à renoncer à toute innovation venue du terrain, dans des organisations où les professionnels sont les seuls à connaître vraiment leurs processus, leurs cas limites et leurs exceptions du vendredi soir.

Le réflexe inverse, c’est de laisser faire. L’outil rend service, on ferme les yeux.

Ça tient jusqu’au jour où son auteur s’en va. Personne n’a le code, personne ne sait le faire évoluer, personne ne peut exporter les données. La dépendance à une seule personne est le mode de défaillance le plus banal de ces applications. C’est aussi le plus prévisible, ce qui est assez frustrant.

S’ajoute une question de qualité qu’on ne peut plus balayer d’un revers de main. Veracode a soumis en 2025 plus de cent modèles de langage à 80 tâches de génération de code présentant un risque connu. Dans 45 % des cas, le code produit introduisait une vulnérabilité. La mise à jour publiée l’année suivante, sur davantage de modèles, ne montre aucune amélioration. Le code généré est syntaxiquement juste beaucoup plus souvent qu’il n’est sûr.

Et quoi qu’il arrive, c’est l’établissement qui porte la responsabilité du traitement. Pas l’auteur.

Interdire, laisser faire : les deux répondent par oui ou par non à une question qui n’appelle pas cette réponse.

Le CLAS, un cadre pour les applications développées en interne

Le CLAS, Centre Local d’Applications en Santé, c’est le dispositif qu’on propose pour tenir la position du milieu. Ni lab d’innovation, ni DSI bis. Il est décrit en détail dans le livre blanc dont cet article reprend une partie.

Trois éléments, pas plus.

Un binôme fondateur d’abord. Un profil métier qui connaît l’établissement, un profil technique capable de tenir une plateforme. C’est le seul prérequis réel pour démarrer.

Une plateforme ensuite, hébergée dans l’établissement, sur laquelle les applications sont créées, publiées et supervisées.

Un cycle de vie enfin, de l’idée de terrain au déploiement, avec des points de passage identifiés.

Le principe qui gouverne tout ça tient en une phrase : on ne fait jamais à la place du porteur. Il reste propriétaire de son outil du début à la fin. C’est là toute la différence avec un prestataire, qui livre et qui repart.

Le vrai déplacement est ailleurs, et il mérite qu’on s’y arrête. Le contrôle ne disparaît pas. Il change de point d’application. Il s’exerce une fois sur le cadre, c’est-à-dire l’infrastructure, l’authentification et le périmètre des données, au lieu de s’exercer à chaque fois sur chaque application. Dans ce périmètre validé en amont, créer et publier peuvent se confondre. En dehors, le circuit classique s’applique intégralement.

En d’autres termes, on créé un écosystème qui permet la création d’application. Le cadre du CLAS permet le contrôle au niveau de chaque application sans devoir courir après chacune d’entre elles.

Reste ce que le CLAS apporte et que le porteur n’a pas. Un professionnel connaît son métier. Il ne connaît pas forcément le cadre réglementaire qui encadre son propre exercice, ni ce que le code de la santé publique l’autorise à faire. Ce sont deux expertises différentes. On a tendance à supposer que la première contient la seconde, et elle ne la contient pas.

La grille de labellisation : quatre niveaux, deux critères qui tranchent

On arrive au cœur du sujet. La labellisation repose sur quatre niveaux, et chaque niveau ouvre un périmètre de partage plus large que le précédent.

Prototype. Aucun critère. L’application reste dans son service, son usage est assumé par ceux qui s’en servent, elle ne sort pas.

Bronze. Validation métier par les utilisateurs, pas de données de santé, code déposé sur l’infrastructure du CLAS. L’application entre au catalogue interne.

Argent. Conformité RGPD vérifiée, tests de sécurité passés, relecture du code par deux ou trois développeurs d’autres établissements. Là, l’application peut sortir de son établissement d’origine.

Or. Conformité HDS, qualification par la DSI, maintenance assurée. L’application est recommandée pour un déploiement à l’échelle.

Jusqu’ici, rien de très surprenant. Ce qui compte, ce sont les deux critères transversaux, parce que ce sont eux qui font réellement le tri.

Le premier, c’est le mode dégradé. Quand vous numérisez un irritant, vous supprimez le processus papier qui le portait. Le jour où l’application tombe, le service doit pouvoir revenir au fonctionnement d’avant. Et ce retour est d’autant plus difficile que la procédure a disparu, que personne ne l’a pratiquée depuis deux ans, et que les nouveaux arrivants ne l’ont jamais connue. Donc toute application qui remplace un processus existant documente son mode dégradé. Sinon elle ne monte pas d’un cran.

Le second, c’est la sobriété d’usage. Une application qui n’est qu’une interface vers un modèle génératif, sans traitement propre, consomme des ressources à chaque utilisation sans valeur métier identifiable. Quand un traitement déterministe suffit, on prend le traitement déterministe. C’est un critère de pérennité autant qu’un critère écologique, parce que la consommation à l’usage reste très difficile à estimer à l’avance et que c’est elle qui devient structurante dans la durée.

Dernier point, et il compte : un label n’est jamais acquis. Il se gagne et il se perd. Si la maintenance s’arrête ou si le contexte réglementaire bouge, l’application redescend.

Ce qui ne passe pas le cadre

Un cadre qui accepte tout n’est pas un cadre. Autant dire tout de suite ce qui reste dehors.

Les applications qui écrivent dans le système d’information, qui s’interfacent avec le dossier patient ou qui produisent une aide à la décision clinique. Circuit classique, avec ses délais et ses garanties. Ce n’est pas négociable.

Les applications qui manipulent des données de santé hébergées ailleurs que chez un hébergeur certifié HDS.

Les applications sans réversibilité. Compte personnel, abonnement individuel, données non exportables.

Celles qui touchent à l’information du patient, au recueil du consentement ou à une priorisation entre patients. Celles-là ne sont pas interdites, elles passent d’abord devant les instances de l’établissement.

Il reste un cas qui n’est pas un refus, et j’y tiens. Une application peut être utile, validée par son service, et malgré tout non intégrable. Trois issues possibles, aucune n’est un échec : l’usage local avec ses limites assumées, la reprise en projet classique avec le prototype comme cahier des charges vivant, ou l’arrêt.

Si c’est l’arrêt, il se prépare. Service prévenu avant et pas après, processus antérieur réactivable, raisons expliquées. Un retour en arrière subi coûte une confiance qui met des mois à se reconstruire.

Par où commencer : l’inventaire avant les nouvelles idées

L’erreur classique, c’est de lancer le dispositif sur de belles idées neuves en laissant de côté ce qui tourne déjà. Faites l’inverse.

Commencez par un inventaire sans sanction. Un appel à déclaration, avec une garantie écrite : déclarer ne déclenche ni audit ni retrait immédiat. Cette garantie n’est pas un détail de forme, c’est la condition de l’exercice. Sans elle, vous ne remonterez rien.

Ouvrez le hub interne, sur un périmètre volontairement restreint aux applications sans données de santé. Ça se compte en semaines, pas en années.

Publiez les premiers labels. Cinq à dix applications suffisent à rendre le dispositif crédible, et elles viendront presque toutes de l’existant.

La grille de labellisation ne sert pas d’abord à trier des applications. Elle donne à l’établissement un vocabulaire commun pour parler d’outils qu’il n’a pas commandés, qu’il n’a jamais inventoriés, et dont il ne peut plus ignorer l’existence.

Questions fréquentes

Qu’est-ce que le shadow IT à l’hôpital ? L’ensemble des outils numériques utilisés dans un établissement sans validation de la DSI : fichiers Excel partagés, bases Access, formulaires en ligne, applications développées en interne. Ils répondent à des besoins réels mais échappent à la cartographie du système d’information et aux obligations qui l’accompagnent.

Une application développée en interne doit-elle être inscrite au registre des traitements ? Oui, dès lors qu’elle traite des données à caractère personnel, quelle que soit la façon dont elle a été construite. La responsabilité incombe à l’établissement en tant que responsable de traitement, pas à l’agent qui a développé l’outil.

Peut-on héberger une application de santé chez n’importe quel prestataire cloud ? Non. Toute application manipulant des données de santé à caractère personnel doit reposer sur une offre certifiée HDS. La certification porte sur l’offre et non sur le fournisseur : chez un même hébergeur, une offre peut être certifiée et une autre non.