Le CLAS, Centre Local d’Applications en Santé, est un dispositif interne qui permet à un établissement d’accueillir, de labelliser et de superviser les applications créées par ses professionnels.

À ne pas confondre avec le Contrat local d’accompagnement à la scolarité, qui porte le même sigle.

Pourquoi un CLAS

Des applications créées par les professionnels tournent déjà dans chaque établissement. Le vibe coding accélère le mouvement. Face à ce constat, deux réflexes échouent.

Interdire, parce que le besoin ne disparaît pas, il sort du champ de vision. Laisser faire, parce que l’outil tient jusqu’au jour où son auteur s’en va.

Le CLAS tient la position du milieu.

Trois éléments

Un binôme fondateur. 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 hébergée dans l’établissement, sur laquelle les applications sont créées, publiées et supervisées.

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

Un principe gouverne l’ensemble : on ne fait jamais à la place du porteur. Il reste propriétaire de son outil.

Le principe : déplacer le contrôle

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 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.

Quatre niveaux de label

Prototype : usage local, aucun critère.
Bronze : validation par les utilisateurs, pas de données de santé, code déposé sur la plateforme.
Argent : conformité RGPD, tests de sécurité, relecture du code par des pairs d’autres établissements.
Or : conformité HDS, qualification par la DSI, maintenance assurée.

Deux critères transversaux font le tri : le mode dégradé et la sobriété d’usage.

Un label n’est jamais acquis. Il se gagne et il se perd.

Ce qui reste hors du cadre

Les applications qui écrivent dans le système d’information, s’interfacent avec le dossier patient ou produisent une aide à la décision clinique. Celles qui manipulent des données de santé hors d’un hébergement HDS. Celles qui n’offrent aucune réversibilité.

Pour elles, le circuit classique s’applique intégralement.

Par où commencer

Par l’existant, pas par les idées neuves. Un [inventaire sans sanction] des outils qui tournent déjà, puis une plateforme ouverte sur un périmètre restreint aux applications sans données de santé. Cinq à dix premiers labels suffisent à rendre le dispositif crédible.

Le détail du cadre est présenté dans l’article Le CLAS, un cadre pour le vibe coding, et l’ensemble du dispositif dans le livre blanc.

Questions fréquentes

Faut-il une équipe de développeurs pour créer un CLAS ?

Non. Un binôme métier et technique suffit pour démarrer.

Le CLAS remplace-t-il la DSI ?

Non. Il n’est ni un lab d’innovation ni une DSI bis. Il s’appuie sur la DSI pour le cadre technique, et lui transmet les applications qui doivent passer par le circuit classique.

Une application vibe codée peut-elle traiter des données de santé ?

Oui. Si la maintenance s’arrête ou si le contexte réglementaire change, l’application redescend d’un niveau.