IA et médico-social : alléger les écrits, sécuriser la veille HAS

L'IA dans le médico-social arrive avec deux promesses concrètes : rendre du temps aux équipes sur les écrits professionnels et automatiser une veille HAS devenue ingérable. Aucune n'est gratuite. Pour qu'un directeur d'établissement, un DSI d'association ou un directeur innovation puisse y aller sereinement, il faut tenir trois lignes en même temps : la conformité RGPD sur des données particulièrement sensibles, l'hébergement souverain (et parfois HDS), et le respect d'un métier qui n'est pas un métier de bureau.

Le secteur reste sous-équipé numériquement par rapport au sanitaire. C'est précisément pour ça que les équipes y passent autant de temps : transmissions quotidiennes, projets personnalisés d'accompagnement issus de la loi du 2 janvier 2002, comptes rendus de synthèse, fiches de liaison, reporting CPOM. Le Ségur du numérique a injecté 630 millions d'euros dans la transformation numérique de 32 691 ESSMS, avec 72 solutions référencées dès la première vague. Mais le rattrapage technique ne suffit pas : il faut savoir où l'IA peut réellement libérer du temps sans casser le cadre, et où elle ne doit surtout pas aller.

Cet article s'adresse aux décideurs qui doivent arbitrer un projet IA médico-social. On y détaille les quatre cas d'usage qui tiennent en production, l'architecture qu'on déploie effectivement, les coûts réels selon les options d'hébergement, et les pièges qu'on a vus revenir trop souvent.

Prérequis avant d'envisager un projet IA dans un ESSMS

Avant de regarder les outils, voici les conditions sans lesquelles un projet IA médico-social finit en pilote à l'arrêt.

• Une qualification précise du périmètre données. Toutes les écritures professionnelles ne touchent pas aux mêmes données. Une transmission qui décrit l'état clinique d'un résident d'EHPAD relève des données de santé au sens de l'article 9 du RGPD. Une note d'observation socio-éducative en IME n'en relève pas toujours. La frontière conditionne tout le reste, dont l'obligation d'hébergement HDS.
• Une analyse d'impact (AIPD) en cours. La CNIL impose une AIPD systématique pour tout traitement à finalité d'accompagnement social ou médico-social. Sans AIPD, le projet n'est pas conforme, quel que soit le LLM choisi.
• Une politique de consentement déjà rodée. Les personnes accompagnées doivent être informées qu'un outil d'IA intervient dans la chaîne de rédaction qui les concerne. Si la culture interne du consentement n'est pas mûre, le projet IA va l'exposer.
• Un sponsor en gouvernance. Direction qualité, direction générale, ou délégué à la protection des données : il faut un porteur identifié, pas un comité.
• Un budget réaliste. Un POC ESSMS solide démarre autour de 25 à 45 k€. La phase d'amorçage du programme ESMS Numérique et les enveloppes ARS peuvent en couvrir une partie.
• Une équipe terrain volontaire. Pas le service entier. Une unité, un service à domicile, une équipe d'AES motivée. C'est là que se mesurent les gains, et c'est là que se construit l'adhésion.

Si trois de ces six points ne sont pas en place, le projet n'est pas mûr. Mieux vaut investir six mois sur l'AIPD et le sponsor qu'attaquer un POC qui sera bloqué dès la première revue conformité.

Quatre cas d'usage où l'IA libère vraiment du temps

On en voit beaucoup. Quatre tiennent vraiment en production dans le médico-social.

Génération assistée des écrits professionnels

C'est le cas d'usage le plus mûr et le plus rentable. L'AES dicte ou saisit en langage naturel ce qu'il a observé pendant la journée. Le système renvoie une transmission structurée selon le format de l'établissement, prête à valider. Idem pour un projet personnalisé d'accompagnement à partir des notes d'observation et des bilans existants.

Le gain n'est pas de remplacer le professionnel : c'est de lui rendre le temps de mise en forme. Sur un quart de service, on observe régulièrement un facteur 3 à 5 sur la rédaction d'une transmission longue, et une réduction nette du retard chronique de saisie en fin de poste. Le contenu reste sous responsabilité du rédacteur, qui valide avant transmission.

Veille HAS, DGCS, ARS : un RAG sur vos référentiels

Une direction qualité d'une association gestionnaire de 30 à 50 établissements consacre une demi-journée par semaine, parfois plus, à suivre les publications HAS, les circulaires DGCS, les arrêtés ARS régionaux, les recommandations de bonnes pratiques. C'est précisément le cas d'usage type d'un RAG (Retrieval Augmented Generation) : un système qui indexe l'ensemble des référentiels et qui répond, sur citation, à une question posée en langage naturel.

L'architecture pour ça est éprouvée. On l'utilise au quotidien sur des sujets adjacents : voir notre retour d'expérience pgvector sur un RAG d'1 To en production. La difficulté n'est pas technique, elle est dans le sourcing et la fraîcheur des référentiels : il faut un pipeline d'ingestion qui suit les publications HAS et DGCS automatiquement.

Préparation de l'évaluation HAS : croiser critères et preuves

Le référentiel HAS d'évaluation des ESSMS publié en mars 2022 compte 157 critères, dont 18 critères impératifs (17 pour le secteur social), organisés en 3 chapitres, 9 thématiques et 42 objectifs. L'évaluation est obligatoire tous les cinq ans, et la programmation pluriannuelle court jusqu'au 31 décembre 2027.

Préparer une évaluation, c'est passer six mois à associer chaque critère à des preuves documentaires : compte-rendus de CVS, procédures, plans de prévention, supports de formation, registres. L'IA peut faire ce travail de mise en correspondance à condition d'avoir indexé en RAG l'ensemble du fonds documentaire de l'établissement. Elle ne valide pas la conformité : elle propose pour chaque critère les pièces probables, le qualiticien arbitre.

Détection précoce des signaux faibles (à manier avec soin)

L'analyse longitudinale des transmissions sur 3 à 12 mois peut révéler des évolutions discrètes : repli relationnel, dégradation cognitive, isolement progressif. C'est techniquement faisable. C'est cliniquement et déontologiquement le plus risqué des quatre cas d'usage. Une alerte mal calibrée peut faire glisser l'établissement vers une logique de surveillance algorithmique des personnes accompagnées, à mille lieues de l'éthique du secteur. À ne déployer qu'avec un comité éthique interne actif, et jamais comme outil de décision automatisée.

Pourquoi un LLM hébergé hors UE est exclu

C'est notre conviction la plus tranchée sur ces projets : un LLM dont les serveurs d'inférence sont aux États-Unis est disqualifié d'office pour un ESSMS qui traite des écrits professionnels nominatifs, quelles que soient les clauses contractuelles affichées.

Deux raisons. La première est juridique : le CLOUD Act américain permet aux autorités fédérales d'exiger d'un fournisseur cloud US la communication de données stockées sur ses serveurs, y compris en dehors du territoire américain. Cette extraterritorialité entre en conflit frontal avec l'article 9 du RGPD sur les données sensibles, et avec l'article L.1110-4 du Code de la santé publique sur le secret professionnel. Un Data Processing Agreement n'efface pas une loi extraterritoriale.

La seconde est opérationnelle. Une transmission décrit une personne réelle, identifiable, vulnérable. La sortie de cette donnée hors UE n'est pas auditable côté établissement : on ne sait pas où elle a transité, ni si elle a alimenté un dataset d'entraînement. Pour une donnée médico-sociale, c'est un risque qu'on ne prend pas.

Concrètement, l'écosystème souverain est aujourd'hui à maturité : Scaleway propose du Managed Inference Mistral à partir d'environ 679 €/mois pour Mistral 7B sur GPU L4 ou 2 482 €/mois pour les modèles 70B sur H100, avec garantie d'inférence sur sol français. OVHcloud déploie Mistral Large 123B dans un environnement souverain conforme RGPD. Ce sont des prix industriels, pas des prix d'expérimentation.

L'architecture type qu'on déploie

Voici le schéma de référence qu'on utilise pour un projet IA médico-social, en cluster Kubernetes Scaleway France avec réplication offshore OVH.

flowchart TB
    subgraph Terrain["Front terrain (PWA)"]
        A1[Application mobile éducateur]
        A2[Poste qualité / direction]
    end

    subgraph API["Backend applicatif"]
        B1[API métier authentifiée]
        B2[Service de validation humaine]
        B3[Journal d'audit immuable]
    end

    subgraph Data["Base de données EU"]
        C1[(Postgres chiffré at rest)]
        C2[(pgvector embeddings RAG)]
    end

    subgraph IA["Inférence souveraine"]
        D1[LLM Mistral via Scaleway FR]
        D2[ASR Voxtral pour dictée]
        D3[Retrieval sur référentiels HAS]
    end

    A1 -->|HTTPS + JWT| B1
    A2 -->|HTTPS + JWT| B1
    B1 --> C1
    B1 --> D1
    B1 --> D2
    D1 --> D3
    D3 --> C2
    D1 --> B2
    B2 -->|validation| C1
    B1 -.->|log| B3
    D1 -.->|log| B3

Quatre points méritent l'attention. D'abord, le journal d'audit est immuable et journalise qui a déclenché une génération, qui a validé, sur quels documents le RAG s'est appuyé. C'est exigible en cas de contrôle CNIL et c'est utile pour la traçabilité interne. Ensuite, le service de validation humaine est une étape obligatoire avant écriture en base : rien ne part en production sans clic humain. La base Postgres est répliquée avec stream WAL vers OVH pour la résilience multi-fournisseurs. Enfin, le LLM et le RAG sont isolés : si on doit changer de fournisseur d'inférence demain, le contrat applicatif ne bouge pas.

Cette architecture est très proche de celle qu'on a déployée pour Jef, l'assistant IA du Barreau de Bruxelles : environnement clos, isolation multi-tenant garantie par design, hébergement européen, RAG sur les documents que l'utilisateur a choisi d'uploader. La logique est la même dans un secteur réglementé : pas de fuite par défaut, pas d'hallucination hors corpus, pas de visibilité système sur les contenus individuels. Jef sert aujourd'hui plus de 6 000 avocats. Le médico-social pose les mêmes contraintes, avec des données encore plus sensibles.

Le piège récurrent : confondre dictée vocale et IA générative

On l'a vu sur plusieurs cadrages : un directeur d'établissement nous dit qu'il veut « de l'IA pour les transmissions », alors qu'il décrit en réalité un outil de dictée vocale.

• Symptôme : le projet est présenté comme un projet IA. Les équipes craignent que la machine écrive à leur place. La direction qualité bloque sur la conformité.
• Diagnostic : ce sont deux briques techniques distinctes, avec deux profils de risque très différents. La reconnaissance vocale (ASR) transforme un flux audio en texte. L'IA générative reformule, structure, propose un format. Une dictée vocale conforme RGPD ne génère rien : elle transcrit fidèlement. Notre retour d'expérience sur l'intégration de Voxtral chez Lex4u détaille ce que change la qualité d'un ASR européen sur un secteur réglementé.
• Fix : séparer les flux dès le cadrage. Une chaîne « dictée pure » conforme HDS si nécessaire, et une chaîne « génération assistée » avec validation humaine, journal d'audit, et un LLM EU clairement identifié. Ce sont deux features, deux périmètres conformité, deux courbes d'adoption.

Combien ça coûte : trois architectures comparées

Pour un ESSMS qui veut industrialiser la génération assistée d'écrits sur 80 à 150 professionnels, voici les trois options qu'on chiffre en cadrage. Les coûts d'inférence varient selon le volume d'écrits ; les ordres de grandeur ci-dessous correspondent à une consommation typique observée en contexte similaire.

L'option médiane (Mistral via Scaleway France) couvre 80 % des cas. L'auto-hébergement devient pertinent au-delà de 200 professionnels actifs ou quand l'établissement gère déjà un cluster Kubernetes, comme c'est le cas pour les grandes associations gestionnaires.

Une opinion qu'on assume : ne pas déployer l'IA sur le cœur du métier éducatif

Le risque le plus discret d'un projet IA médico-social, ce n'est pas la fuite de données. C'est le glissement progressif vers une rédaction standardisée qui dilue la singularité de chaque situation.

Un projet personnalisé d'accompagnement n'est pas un document administratif. Il porte une lecture professionnelle, une hypothèse de travail, parfois un désaccord avec un partenaire. Si l'IA génère le projet entier à partir de notes brutes, le rédacteur risque de signer un texte qui n'est plus le sien. Le cadre légal protecteur du secteur, et notamment la loi 2002-2 qui consacre le projet personnalisé comme expression de la singularité, est mal servi par une IA qui homogénéise.

Notre conviction, après plusieurs cadrages dans le secteur : l'IA doit travailler sur la périphérie (transmissions, veille, préparation d'évaluation HAS, reporting CPOM) pour libérer du temps qui sera réinvesti dans le cœur (l'observation clinique, la relation, la rédaction analytique du projet personnalisé). Pas l'inverse. Une équipe qui gagne deux heures par semaine sur les transmissions est une équipe qui peut écrire un projet personnalisé plus juste, pas un projet personnalisé plus rapide.

FAQ

Faut-il un hébergement HDS pour faire de l'IA en ESSMS ?

Pas systématiquement. L'hébergement HDS est obligatoire dès lors que l'application traite des données de santé à caractère personnel au sens du Code de la santé publique. Un outil de génération de transmissions en MAS, FAM ou EHPAD touche aux données de santé : HDS requis. Un outil de veille HAS qui n'accède à aucune donnée nominative : HDS non requis. La frontière s'analyse au cas par cas, idéalement avec le DPO de la structure.

Quel LLM européen pour le médico-social ?

Mistral en première intention (modèles Small, Medium ou Large selon le besoin), hébergé sur Scaleway France ou OVH France. Claude d'Anthropic est accessible via Bedrock EU avec un contrat de sous-traitance strict, utile quand le besoin justifie un modèle frontière (raisonnement complexe sur référentiels). On évite OpenAI et Gemini hors région EU stricte.

Quel délai pour un POC IA médico-social ?

De 8 à 12 semaines pour un POC sérieux. Quatre semaines de cadrage (AIPD, périmètre données, sponsor), quatre à six semaines de build, deux à quatre semaines de test terrain avec une équipe volontaire. En dessous de huit semaines, on raccourcit l'AIPD ou le test terrain : ni l'un ni l'autre n'est négociable.

Le RGPD interdit-il l'usage de l'IA en ESSMS ?

Non. L'article 9 encadre le traitement des données sensibles, il ne l'interdit pas. Les bases légales possibles sont le consentement explicite de la personne accompagnée (privilégié), les intérêts légitimes du responsable de traitement pour l'accompagnement, ou l'obligation légale dans certains cas. Le référentiel CNIL sur les traitements de données dans les établissements médico-sociaux précise les cadres applicables.

L'IA peut-elle remplacer un éducateur, un AES, un chef de service ?

Non. Et la question est mal posée. L'IA bien déployée dans un ESSMS rend du temps à ces professionnels en absorbant la part la moins métier de leur activité. Le métier reste celui de la relation, de l'observation clinique, de l'arbitrage éthique. L'IA ne le remplace pas, elle le dégage.

Pour aller plus loin

Un projet IA médico-social bien cadré est un projet de transformation organisationnelle autant que technique. Le bon ordre est : AIPD et sponsor d'abord, périmètre données ensuite, choix de stack EU-souveraine après, et test terrain avec une équipe volontaire avant tout déploiement à l'échelle. C'est ce qu'on a appris en construisant des plateformes documentaires en secteur réglementé, dont Jef pour le Barreau de Bruxelles.

L'agence Platane (https://platane.io) accompagne les associations gestionnaires, les ESSMS et les organismes publics sur ce type de projet IA médico-social, depuis le cadrage AIPD jusqu'à l'industrialisation sur cluster Kubernetes souverain. Pour discuter d'un cadrage ou d'un POC, un échange direct se cale ici.