Le domaine en plein essor de l’intelligence artificielle, et notamment les grands modèles de langage (LLM), ouvre des perspectives inédites pour la santé mentale. Accès facilité à un premier soutien, à des informations de meilleure qualité, à l’accompagnement thérapeutique, et réduction des charges administratives : les avantages potentiels sont considérables. Mais quand il s’agit de santé mentale, une exigence s’impose avant toute chose : garantir la confidentialité, la sécurité des données et un déploiement éthique. C’est cette exigence qui a guidé la création de Joy, notre IA au service de la santé mentale.
Cet article explore le processus de création d’un système LLM sécurisé pour la santé mentale, et plus particulièrement les choix éthiques, réglementaires et techniques qui ont structuré son développement. En quoi la réglementation européenne est-elle un socle essentiel ? Quels sont les risques inhérents au recours à des fournisseurs de LLM tiers ? Et pourquoi opter pour un déploiement interne basé sur des solutions open source ? Nous expliquons comment notre outil garantit que les données restent là où elles doivent être : en toute sécurité, au plus près de l’utilisateur.
Le RGPD (Règlement Général sur la Protection des Données) est obligatoire pour tout système traitant des données personnelles au sein de l’Union Européenne (UE). Concernant les données de santé mentale relevant des « catégories particulières de données personnelles », celles-ci exigent une protection encore plus élevée.
La loi européenne sur l’IA, entrée en vigueur en août 2024, catégorise les systèmes d’IA en fonction de leur niveau de risque, les systèmes « à haut risque » étant soumis à des exigences strictes. Les systèmes d’IA destinés à être utilisés comme dispositifs médicaux ou dans des infrastructures critiques, ou à des fins portant atteinte aux droits fondamentaux, sont généralement considérés comme à haut risque. Les applications de santé mentale, notamment celles offrant une aide au diagnostic, un accompagnement thérapeutique ou un suivi des patients, relèveront très probablement de cette catégorie.
Les obligations prévues pour tout système d’IA dit « à haut risque » :
Comme nous venons de le voir, le RGPD et l’IA Act posent un cadre strict, mais encore faut-il pouvoir le garantir dans la pratique. C’est ce qui a motivé notre choix d’un déploiement interne, pour maîtriser pleinement les risques, la sécurité des données et le respect des principes éthiques.
L’utilisation de plateformes cloud d’IA telles que ChatGPT contrevient à plusieurs critères rappelés du RGPD ou de l’IA Act, notamment :
D’autres raisons nous ont poussés vers une stratégie de déploiement en interne mais celles-ci ne concernent ni la Data Privacy ni la Cybersecurity : nous ne les exposerons donc pas dans cet article. Ces raisons concernent davantage le contrôle des systèmes et leurs mises à jour, la maîtrise des coûts ou encore l’opportunité d’ajustement spécifique pour le domaine de la santé mentale.
Manipuler des données non structurées — et susceptibles, par nature, de contenir des données personnelles — implique une très grande responsabilité.
Afin de limiter les accès et de maîtriser les flux de données, nous avons fait le choix de déployer nos services LLM sur le réseau interne privé de teale, sans accès à Internet.
Un LLM peut en effet, dans certaines conditions, interroger des ressources externes pour enrichir son contexte. Dans le cadre de l’utilisation d’un service cloud, il est donc impossible de garantir qu’aucune requête ne soit envoyée vers Internet.
Chez teale, nos services LLM sont configurés comme des points de terminaison du réseau isolés : aucune requête extérieure n’est autorisée.
« Les LLM ont une capacité de mémorisation. » C’est faux.
Les LLM sont basés sur la technologie des réseaux de neurones. Un réseau de neurones (ou LLM) n’est généralement entraîné qu’une seule fois car c’est un processus extrêmement coûteux en ressources. Lorsqu’il génère une réponse, il le fait par inférence : le texte d’entrée va suivre le même chemin que les milliards d’autres données d’entraînement. Ce procédé, dit stateless (sans état), signifie qu’un LLM ne retient rien des requêtes qu’il traite : produire une réponse via un LLM ne modifie pas son état, il ne peut donc pas mémoriser quoi que ce soit.
La notion de « mémoire » dans les LLM est un artifice technologique : l’historique des interactions de l’utilisateur est réinjecté dans le prompt pour enrichir le contexte. Plus cet historique est long, plus les réponses sont pertinentes. La question à présent est donc de savoir où et surtout comment est stocké l’historique de ces interactions, sachant que celui-ci contient nécessairement des données personnelles.
Chez teale, cet historique est stocké dans une base de données dédiée, isolée, et chiffrée.
aes-256-gcm.Il n’y a pas de donnée plus sensible que la donnée non structurée, c’est-à-dire non contrainte par un schéma précis, saisie librement dans un champ texte.
Les interactions avec les services Internet se font via des APIs et des interfaces graphiques (web ou native) contextualisant très fortement la donnée transmise. Par exemple, renseigner son âge sur un formulaire en ligne conduit à l’insertion, dans une base de données, de la valeur numérique renseignée dans la colonne age correspondante. L’inventaire des données sensibles peut ainsi être maintenu grâce à ce contexte et ces bases de données.
Dans le cas d’un LLM, l’utilisateur a en face de lui un champ texte sans contexte. Il peut écrire ce qu’il veut. Il appartient alors au système de “comprendre” sa demande et de lui fournir la réponse. Ce changement de paradigme est fondamental car il détruit la notion d’inventaire et de catégorisation des données par la plateforme proposant le service. Ainsi, et par voie de conséquence, ne pouvant plus catégoriser l’information via un contexte contractualisé, le plus haut niveau de criticité doit être apposé à la requête reçue (Principe de moindre privilège).
Chez teale, nous avons choisi une politique stricte d’oubli, en complément du chiffrement que nous avons expliqué précédemment :
Cela ne remet pas en cause la gestion des données explicitement catégorisées comme les scores du Wellbeing Tracker ou les activités réalisées sur notre plateforme : ces informations sont stockées de manière sécurisée, avec des niveaux d’accès et de protection adaptés.
Effectuer une inférence sur un LLM prend du temps : de quelques secondes à plusieurs minutes. Lors de ce calcul, une grande quantité de mémoire doit être allouée sur les GPUs du serveur. Cette allocation limite la capacité du serveur à traiter d’autres requêtes et l’empreinte mémoire reste élevée pendant toute la durée de l’inférence (avec des variations possibles).
Pour limiter cette charge, il est courant d’utiliser un cache, qui stocke les réponses générées pour pouvoir les réutiliser si une requête identique ou très proche est soumise à nouveau.
Pour réduire le temps de calcul et limiter cette charge, il est courant de mettre en place une stratégie de cache : le cache stocke les réponses générées pour pouvoir les réutiliser dans le cas où la même requête serait effectuée. Mais comment interroger ce cache pour retrouver la bonne réponse lorsque la requête est non structurée ?
La solution classique consiste à utiliser une recherche de similarité sémantique : on stocke une représentation vectorielle de la requête, appelée « embedding », calculée par le LLM lui-même. La même approche est généralement utilisée pour enrichir le contexte d’un prompt dans un process de Retrieval Augmented Generation (RAG).
Un embedding encode la signification d’une phrase sous forme numérique. Ainsi, les deux phrases « Mon chat est paresseux » et « Mon chien est paresseux » auront des embeddings très proches, éloignés de « J’aimerais apprendre à jouer de la guitare ». Voilà comment stocker la réponse produite par un LLM dans un cache pour le retrouver facilement plus tard. Génial !
Mais il y a un problème.
Si l’embedding est un encodage de la requête envoyée par l’utilisateur, alors il est théoriquement possible de le décoder et, ainsi, d’accéder à la requête originale de l’utilisateur. Or, nous avons expliqué précédemment avoir fait le choix d’une politique stricte d’oubli des requêtes au bout de 24 heures. Si nous appliquons cette même contrainte au cache, celui-ci ne présente plus beaucoup d’intérêt. Que faire ?
Nous avons développé, chez teale, une méthode mathématique qui nous permet de conserver la recherche sémantique sur la base vectorielle (qui contient les résultats du cache) tout en empêchant toute possibilité de décoder les embeddings sans la clé de chiffrement associée. Ainsi, même si un attaquant parvenait à accéder à la base du cache, il ne pourrait pas en extraire les requêtes d’origine ni les éventuelles données personnelles qu’elles contiennent.
Naviguer dans le paysage complexe de l’IA et de la santé mentale exige une approche non seulement innovante mais surtout rigoureusement conforme aux régulations existantes et émergentes.
Comme nous l’avons exploré, le RGPD et l’IA Act de l’UE imposent des exigences strictes en matière de protection des données et de sécurité, particulièrement lorsque des données sensibles comme celles de la santé mentale sont en jeu.
Si la tentation d’opter pour des plateformes cloud d’IA prêtes à l’emploi est forte, notre analyse démontre qu’elles ne peuvent pas garantir le niveau de maîtrise, de transparence et de responsabilité nécessaire dans ce domaine critique. Les risques liés à la conservation des données, à leur intégrité, à la responsabilité et à l’évaluation continue de la conformité en font des solutions inadaptées à nos exigences.
Chez teale, notre stratégie de déploiement de Joy en interne n’est pas seulement un choix technique : c’est une nécessité dictée par la primauté de la sécurité et de la confidentialité des données de nos utilisateurs.
L’isolation réseau de nos services LLM, le chiffrement sophistiqué de l’historique des interactions avec rotation des clés, et notre mécanisme d’« oubli » automatique des données après 24 heures sont autant de mesures concrètes qui traduisent notre engagement. Nous avons même repensé la gestion du cache sémantique pour allier performance et respect absolu de la vie privée, en rendant impossible le décodage des requêtes utilisateurs sans clé de chiffrement.
Ces choix architecturaux et opérationnels ne sont pas de simples « bonnes pratiques » : ils sont au cœur de notre proposition de valeur et de notre responsabilité. Ils nous permettent d’offrir à nos utilisateurs un accompagnement qui respecte leur intimité, en garantissant un niveau de protection des données à la hauteur des enjeux de la santé mentale.
L’innovation responsable est notre boussole, et la sécurité de vos données, notre priorité. Comme depuis le premier jour chez teale.
Si vous voulez tester Joy, c’est par ici.