IA générative et RGPD dans le médico-social
ariane
Livres Blancs

Le Ticket du Jour #1
IA générative et RGPD
dans le médico-social

Par Lionel Huck, Responsable Activité Réseau et Cybersécurité, Sincrone IT
Novembre 2026

Client

Association du secteur médico-social, environ 170 salariés répartis sur un IME, un SESSAD, un ESAT et un foyer d’accueil médicalisé.

Demande initiale

« Nos équipes utilisent des IA que nous n’avons pas validées, avec des données d’usagers. Est-ce qu’on bloque tout ? »

Technologies

Cato Networks SASE
Cato AI Security for Users

quote sign
Un client voulait bloquer ChatGPT. Notre première question : savez-vous ce que vos équipes y écrivent ?
La réponse était non. Résultat : une gouvernance adaptée plutôt qu’un blocage total.
Responsable d'activité Réseaux et Sécurité chez Sincrone IT

Le contexte : beaucoup d’écrit,
des données très sensibles

L’association accompagne des enfants et des adultes en situation de handicap. Ses salariés sont éducateurs, aides médico-psychologiques, psychologues, assistantes sociales ou cadres de direction. Peu de profils techniques, beaucoup d’écrit : projets personnalisés, synthèses, courriers aux familles, comptes rendus de réunion.

Nous avions déployé la plateforme SASE de Cato Networks quelques mois plus tôt. Les établissements sont reliés par des Sockets Cato, les salariés en déplacement passent par le Cato Client, et le pare-feu comme le filtrage web sont dans le cloud Cato. Côté IA, la règle interne était simple : Microsoft Copilot, dans le tenant Microsoft 365 de l’association, et rien d’autre.

Le problème : une politique « Copilot uniquement » qui n’existait que sur le papier

Lors d’une revue de la console Cato, j’ai parcouru les statistiques par application. ChatGPT, Claude, Perplexity et DeepSeek apparaissaient tous, avec des volumes loin d’être anecdotiques. ChatGPT générait à lui seul plus de trafic que Copilot.

Dans une entreprise industrielle, c’est déjà un sujet de confidentialité. Dans une structure médico-sociale, c’est plus lourd. Les écrits du quotidien contiennent des noms d’usagers, des numéros de sécurité sociale (NIR), des références de notification MDPH, et souvent des informations de santé : diagnostic, traitement, troubles du comportement. Ce sont des données sensibles au sens de l’article 9 du RGPD. Une fois collées dans un compte ChatGPT personnel, l’association n’a plus aucune maîtrise sur elles.

La direction a posé la question sans détour : est-ce qu’on bloque tout ?

L’analyse : bloquer était facile, et c’était une mauvaise idée

Techniquement, bloquer prenait dix minutes : une règle sur la catégorie « IA générative » dans le pare-feu Cato. Je l’ai déconseillé, pour trois raisons.

Le besoin est réel

Un éducateur qui passe une heure sur un courrier aux familles a de bonnes raisons de vouloir de l’aide. Couper l’accès ne supprime pas le besoin.

Le blocage déplace l'usage

Le salarié bascule sur son téléphone personnel, en 4G, hors de tout contrôle. On passe d’un risque visible à un risque invisible.

Les IA changent tous les mois

Une liste de blocage a toujours un temps de retard sur le prochain outil à la mode.

Le vrai problème était ailleurs. Le pare-feu voit la destination : chatgpt.com. Le CASB (Cloud Access Security Broker) voit l’application. Aucun des deux ne lit la phrase. Or c’est la phrase qui contient le NIR ou le diagnostic. Il fallait un contrôle capable de lire le message envoyé à l’IA, d’en comprendre le contenu et de décider message par message. Avant de proposer quoi que ce soit, nous avons voulu mesurer.

La solution : observer, puis appliquer une règle graduée

Nous avons retenu Cato AI Security for Users. Le module s’ajoute à la plateforme SASE déjà en place : même console, même moteur de règles, pas de nouvel équipement. Il se déploie sous forme d’extension de navigateur, que nous avons poussée par GPO sur Edge et Chrome.

Étape 1 : trente jours en observation

Nous avons activé le module sur un groupe pilote de 40 salariés répartis sur les quatre établissements.
Rien n’était bloqué, tout était mesuré. Les chiffres ont mis tout le monde d’accord :

  • 9 IA différentes utilisées, dont 3 que personne n’avait identifiées
  • environ 2 600 messages envoyés aux IA en un mois
  • un message sur huit contenait au moins une donnée personnelle d’usager
  • les usages dominants : courriers aux familles, synthèses de projet personnalisé, comptes rendus de réunion

Personne ne faisait rien de malveillant. Les salariés cherchaient à gagner du temps sur l’écrit, avec les outils qu’ils connaissaient.

Étape 2 : quatre réponses au lieu d’une

Avec la direction et le délégué à la protection des données, nous avons défini quatre réponses possibles pour chaque message.

  • L’identité de l’usager (nom, NIR, numéro de dossier, référence MDPH, téléphone) est remplacée par des jetons avant l’envoi.
    L’IA rédige le courrier sans savoir de qui il s’agit.
  • Les informations de santé, les demandes d’avis médical et les tentatives de contournement de l’IA (jailbreak).
    Un nom se remplace par un jeton, un diagnostic non : c’est le sens même de la phrase qui est sensible.
  • Les demandes qui touchent aux décisions RH (salaires, évaluations).
    Le message part, mais il est enregistré. La direction a fait ce choix pour accompagner les managers plutôt que les sanctionner.
  • Tout le reste : une invitation à la fête de fin d’année, une reformulation, un résumé de texte réglementaire.

Concrètement, voici ce que tape une éducatrice et ce que reçoit réellement l’IA :

Message tapé :
Rédige un courrier de convocation à la réunion de projet personnalisé pour Lucas MARTIN, dossier DU-2026-10000, NIR 185047305369334, notification MDPH38-2026-191161.

Message reçu par l’IA :
Rédige un courrier de convocation à la réunion de projet personnalisé pour [NOM_1], dossier [DOSSIER_USAGER_1], NIR [NIR_1], notification [MDPH_1].

Sur les outils eux-mêmes, Copilot reste l’IA officielle. DeepSeek a été bloqué, faute de garanties sur l’hébergement des données. Les autres IA restent accessibles sous la règle graduée, et le message affiché à l’utilisateur rappelle que Copilot est l’outil validé.

Étape 3 : reconnaître les formats de l’association

Les détecteurs standard reconnaissent un NIR. Ils ne connaissent pas le format des numéros de dossier du logiciel du dossier usager, ni celui des références MDPH du département. Nous avons écrit des règles personnalisées, à base d’expressions régulières, pour ces deux formats.

Nous sommes ensuite allés plus loin avec la correspondance exacte (EDM, Exact Data Match). L’association exporte sa liste d’usagers : numéro de dossier, nom, prénom, NIR. Chaque valeur est transformée en empreinte avec une clé secrète conservée par l’association (HMAC-SHA256), et seules les empreintes sont transmises à Cato. Cato ne voit jamais la liste en clair, mais il sait reconnaître le NIR d’une personne réellement accompagnée. Cela permet de bloquer net les vrais usagers et de simplement masquer tout ce qui ressemble à un NIR.

Étape 4 : tester avant de basculer

Avant la mise en production, j’ai rejoué les situations repérées pendant l’observation dans notre environnement de démonstration, avec des données fictives : le courrier aux familles, la synthèse avec diagnostic, le script d’export où le prestataire colle son mot de passe, la demande d’ajustement de traitement un week-end où le médecin n’est pas joignable. La direction a validé chaque réponse en voyant le résultat à l’écran, pas sur une slide.

Le résultat

Le module a été étendu aux 170 postes en trois semaines. Sur le premier mois en production :

checked
  • environ 3 100 messages analysés
checked
  • 312 messages passés avec des données masquées, sans gêne pour l’utilisateur
checked
  • 41 messages bloqués, dont 6 demandes d’avis médical
checked
  • aucune donnée d’usager détectée en clair vers une IA non validée
checked
  • la part de Copilot dans les usages IA est passée de 35 % à 60 %

Tout n’a pas été parfait. Pendant les deux premières semaines, les numéros de téléphone des établissements étaient masqués à tort, ce qui rendait certains courriers inutilisables. Une liste d’exceptions a réglé le problème. Le retour le plus intéressant est venu des équipes : le message affiché au moment du blocage, avec sa raison, a fait plus pour la sensibilisation qu’une formation théorique.

Ce que je retiens

Mesurer avant de décider
Trente jours d’observation valent mieux que tous les questionnaires.
On découvre toujours des usages et des outils que personne n’avait vus.

Masquer n’est pas anonymiser
Le nom et le NIR disparaissent, mais une date de naissance, une commune et un établissement restent lisibles.
Dans une petite structure, ces trois éléments peuvent suffire à reconnaître une personne. Il faut le dire clairement au DPO.

La règle d’usage n’est pas une décision technique
Ce qui est bloqué, masqué ou seulement tracé se décide avec la direction et le DPO.
Notre rôle est de le rendre applicable.

Prévoir les faux positifs
Les deux premières semaines servent à ajuster. Annoncez-le aux équipes avant l’activation.

Ne pas bloquer par réflexe
Un blocage sans alternative pousse l’usage là où plus rien ne se voit.

Responsable de l’activité Réseau & Cybersécurité chez Sincrone IT depuis 2015, Lionel Huck accompagne les entreprises dans leurs projets d’évolution et de sécurisation des infrastructures IT. Fort de plus de 15 ans d’expérience et diplômé de Télécom Lille, il intervient sur des sujets tels que les réseaux LAN/WAN, le Wi-Fi d’entreprise, le NAC, le SD-WAN, le SASE, le ZTNA et les solutions de cybersécurité. À travers cet article, il partage un retour d’expérience issu du terrain afin d’aider les DSI et équipes IT confrontés à des problématiques similaires.