Dans la santé et la pharma, les usages IA avancent vite, mais la marge d'erreur reste faible. Entre documentation réglementaire, procédures internes, corpus qualité et contenus à valeur clinique, le contexte doit être préparé avec beaucoup plus de soin qu'un simple chatbot interne.
La pression vient de plusieurs directions simultaneously : exigences réglementaires (HAS, EMA, ANSSI), attentes des professionnels de santé qui doivent rester responsables de leurs décisions, et risque de responsabilité juridique si une réponse IA est utilisée sans vérification. Voici les fondamentaux à maîtriser.
Ce qui rend ces usages spécifiques
Trois caractéristiques distinguent les déploiements IA en santé et pharma des autres contextes :
- L'hétérogénéité des sources : une organisation de santé produit simultanément des protocoles cliniques, des fiches de poste, des dossiers réglementaires, des contenus de formation, des guides patients et des comptes rendus d'incidents. Ces sources ont des niveaux d'autorité très différents et ne peuvent pas être mélangées dans un corpus sans hiérarchisation explicite.
- La sensibilité des données : même des questions apparemment anodines peuvent impliquer des données de santé directement ou indirectement identifiantes. L'accès au corpus IA doit être segmenté par rôle, pas seulement par service.
- L'exigence d'explicabilité : dans ce secteur plus qu'ailleurs, une réponse IA doit pouvoir être auditée. « D'où vient cette information ? Quelle est sa version ? Qui l'a validée ? » ne sont pas des questions optionnelles – elles font partie du cadre réglementaire.
La gestion des versions documentaires : une urgence réglementaire
Un document obsolète en santé n'est pas seulement inutile – il peut être dangereux. Une procédure opératoire standard mise à jour après un incident qualité doit impérativement primer sur la version antérieure dans tous les systèmes, y compris les assistants IA.
Les organisations soumises à des audits (HAS, EMA, FDA selon le contexte, et pour les hébergeurs HDS en France) ne peuvent pas se permettre qu'un assistant IA cite une version périmée d'un protocole. Le système de contexte doit garantir trois choses :
- Suivi de version explicite : chaque document ingéré est versionné avec date de mise à jour et statut (actif / archivé / en révision).
- Invalidation automatique : quand une nouvelle version d'un document est publiée, l'ancienne est retirée du corpus actif – pas seulement déprioritisée.
- Traçabilité auditée : lors d'un audit, il doit être possible de retrouver quelle version du document a fondé quelle réponse IA, à quelle date.
Certification HDS et hébergement des données de santé
En France, toute solution qui héberge ou traite des données de santé à caractère personnel doit s'appuyer sur un hébergeur certifié HDS (Hébergeur de Données de Santé). Cette certification, délivrée par l'ANS (Agence du Numérique en Santé), est une obligation légale issue de l'article L.1111-8 du Code de la santé publique.
Ce point a des implications directes sur l'architecture IA : un LLM dont l'API est hébergée dans un datacenter non certifié HDS ne peut pas être appelé avec des données de santé identifiantes en entrée. Les organisations ont deux options : utiliser une architecture local-first qui ne transmet pas de données de santé vers l'extérieur, ou s'assurer que l'ensemble de la chaîne – de l'ingestion à la génération – est conforme HDS.
L'ANSSI, de son côté, émet des recommandations sur la sécurité des systèmes IA, notamment sur la robustesse face aux injections de prompt et la protection des corpus contre l'exfiltration.
Architecture local-first : ce que ça change pour les données sensibles
Une architecture local-first maintient tous les traitements sur l'infrastructure de l'organisation. Pour la santé, cela signifie concrètement que les données ne transitent pas vers des APIs cloud externes – ce qui élimine une partie des risques de fuite et simplifie la conformité RGPD et HDS.
Mais le local seul ne suffit pas. Un modèle local mal alimenté reste peu fiable. Il faut aussi que la couche de retrieval soit correctement structurée : le modèle ne consulte que les documents appropriés à la question posée, avec les droits d'accès correspondant au rôle de l'utilisateur, et dans la version à jour des documents concernés. L'architecture sépare la couche de retrieval (locale, contrôlée) de la couche de génération (configurable selon les exigences du contexte).
Workflow de validation clinique : où placer l'IA dans le processus
La question la plus pratique pour les équipes médicales et pharmaceutiques n'est pas « peut-on utiliser l'IA ? » mais « à quel point du workflow l'IA peut-elle intervenir, et sous quelle forme ? »
Une approche sûre distingue trois niveaux d'intervention :
- Assistance documentaire : l'IA aide à trouver le bon document, le bon protocole, la bonne référence réglementaire. La décision reste entièrement humaine. C'est le cas d'usage avec le meilleur ratio valeur/risque dans ce secteur.
- Synthèse avec supervision : l'IA produit un résumé ou une analyse préliminaire qu'un professionnel valide avant usage. Le document IA est explicitement marqué comme « non validé » jusqu'à validation humaine.
- Génération autonome : réservée aux cas strictement non cliniques (communication interne, rédaction administrative, formation générale). Jamais pour des contenus à valeur clinique ou réglementaire sans process de validation formalisé.
Conclusion
En santé et pharma, l'IA utile est une IA compatible avec les exigences documentaires, réglementaires et humaines du terrain. Ce qui distingue un déploiement réussi d'un projet qui échoue sous la pression des équipes médicales ou des auditeurs, c'est presque toujours la même chose : la qualité de la gouvernance du contexte et la rigueur de la gestion des versions. Commencer par là – avant de choisir le modèle ou de construire des interfaces – est le bon ordre des priorités.