IA en pharma : cadrer un pilote sans court-circuiter le système qualité

Un outil d’IA peut résumer des écarts, rapprocher des rapports, préparer une revue de dossier de lot ou signaler une image inhabituelle. Ces usages ne portent pas la même responsabilité. Sur un site pharmaceutique, la bonne question de départ est donc simple : quelle décision le système va-t-il influencer, et que se passe-t-il si sa réponse est erronée ?

Cette question arrive avant le choix d’un fournisseur, d’un modèle ou d’une interface. Elle permet de séparer un essai documentaire d’un système qui participe à la fabrication, au contrôle qualité ou à la libération d’un produit. Le niveau de preuve, les personnes impliquées et le circuit de changement ne seront pas les mêmes.

Swissmedic relève que les usages d’IA et de machine learning concernent déjà le développement, la fabrication et le cadre réglementaire des médicaments. L’institut met l’accent sur la qualité des données, la traçabilité des modèles, le contrôle qualité et les biais. Son cadre de référence sur l’IA renvoie aux travaux de l’EMA, de l’ICH, de l’IMDRF, de l’OMS et de la FDA. Il ne remplace pas le système qualité d’un site. Il rappelle que l’usage réel du système doit être compris et documenté.

Commencer par la décision, pas par l’outil

Un même modèle peut avoir des conséquences très différentes selon son intégration. Un assistant qui aide un ingénieur à retrouver une procédure dans une copie documentaire reste dans un périmètre limité, à condition que les accès, les sources et la revue soient maîtrisés. Le même assistant, connecté à un dossier de lot électronique et utilisé pour trier les points qui appellent une décision qualité, entre dans un flux plus sensible.

Le cadrage doit donc décrire la décision attendue avec des mots de procédé et de qualité, pas avec le nom commercial de l’outil. Une fiche de départ peut tenir sur une page :

• la tâche précise que le système prépare, recommande ou exécute ;
• le propriétaire de la décision et la personne qui vérifie la sortie ;
• les données lues, les systèmes sources et les éventuelles données personnelles ;
• les données ou enregistrements que le système peut modifier ;
• les erreurs plausibles et leur conséquence opérationnelle ;
• le mode de repli lorsque l’outil est indisponible ou donne une réponse douteuse.

Cette description est aussi utile pour arrêter un projet trop flou. « Mettre de l’IA dans la qualité » ne définit ni un besoin, ni un test, ni une responsabilité. « Préparer une liste de pièces à revoir dans les rapports d’écart, sans modifier les enregistrements et avec validation QA » donne déjà un périmètre de travail.

Distinguer assistance, recommandation et décision

Trois niveaux méritent d’être séparés dès le départ.

L’assistance prépare une information. Par exemple, un système recherche les passages pertinents dans des procédures approuvées ou rassemble les entrées d’un rapport. Une personne qualifiée conserve l’analyse et la décision. Le pilote peut alors être évalué sur la pertinence des sources, les omissions, les réponses erronées et le temps de contrôle nécessaire.

La recommandation classe ou hiérarchise des éléments qui seront examinés par une personne. Le risque augmente lorsque la recommandation peut faire manquer un écart, un signal qualité ou une donnée critique. Les critères de tri, les cas limites et la façon dont l’opérateur contredit l’outil doivent rester visibles.

La décision automatisée change un état, valide un résultat, modifie un paramètre ou déclenche une action sans revue au moment de l’exécution. Elle ne se traite pas comme une démonstration. Son usage prévu, ses interfaces, ses données d’entrée et ses conditions de test doivent être instruits dans le système qualité du site avant toute mise en production.

Cette séparation ne donne pas seule une qualification réglementaire. Elle aide l’équipe projet à poser les bonnes questions à la QA, aux affaires réglementaires, à l’IT et aux responsables du procédé. Elle évite aussi de présenter une fonction de rédaction comme une fonction de contrôle, ou l’inverse.

Examiner le changement avant de connecter la production

L’interprétation technique de Swissmedic relative aux notifications selon l’article 41 MPLO, version 4.0 du 23 septembre 2026, cite des systèmes IA ou ML utilisés en fabrication ou en supply parmi les exemples de changements majeurs. Elle mentionne notamment les LLM destinés à la gestion de réclamations, aux notifications d’effets indésirables, aux PQR ou à la revue de batch records, ainsi que le machine learning appliqué au rendement ou à l’inspection visuelle automatisée. Le texte cite aussi les nouvelles applications d’IA en contrôle qualité. Le document complet doit être lu avec les licences concernées et le contexte du site.

Il serait faux d’en déduire qu’un avis à Swissmedic est requis pour chaque assistant utilisé dans une entreprise pharmaceutique. Le document décrit des catégories de changements majeurs et des exemples. La qualification dépend de l’usage prévu, du champ de la licence, des données, du procédé et des procédures applicables. Cette analyse appartient au site et à ses fonctions qualité et réglementaires autorisées.

En revanche, un projet qui touche un système de fabrication, une revue de lot, une donnée qualité ou une décision de libération ne doit pas être branché comme un outil bureautique. Il faut identifier les systèmes impactés, les documents de changement, les preuves attendues et le moment où la QA doit intervenir. Attendre la fin d’un prototype pour reconstruire cette traçabilité coûte généralement du temps et limite la valeur des essais déjà réalisés.

Construire un pilote qui produit des preuves utiles

Un pilote défendable ne cherche pas à montrer que l’IA « marche ». Il répond à une tâche bornée avec des critères convenus. La meilleure matière de départ est souvent un jeu de cas dont la réponse est déjà connue : dossiers anonymisés lorsque cela est nécessaire, historiques approuvés, erreurs fréquentes et cas auxquels les sources ne permettent pas de répondre.

Le protocole peut comparer la sortie de l’outil avec une référence humaine vérifiée. Il relève les réponses exactes, les sources introuvables, les omissions, les classements discutables et les réponses formulées avec assurance alors que la donnée manque. Il documente aussi les limites d’accès, les versions utilisées et le temps de revue. Une réponse plausible mais sans source exploitable ne peut pas servir de preuve pour une décision GMP.

La sortie attendue d’un bon pilote est plus concrète qu’une démonstration :

• un flux de données connu, depuis la source jusqu’à la sortie ;
• une liste de cas de test et leurs résultats ;
• les limites du système et les cas exclus ;
• les règles de revue humaine et d’escalade ;
• la procédure de repli et la décision de poursuivre, d’adapter ou d’arrêter.

Cette matière permet ensuite de choisir une intégration, de chiffrer les travaux et de préparer la qualification nécessaire. Elle évite de confondre une promesse de fournisseur avec une fonction validée sur le procédé réel.

Garder les données et les accès à leur juste place

Les données disponibles déterminent la qualité du pilote. Un modèle ne corrige pas une procédure obsolète, un historique incomplet ou des versions de documents contradictoires. Avant tout chargement documentaire, l’équipe doit identifier la source de vérité, les règles d’accès, les documents qui peuvent être utilisés et ceux qui doivent rester hors périmètre.

Pour un premier essai, des copies maîtrisées et des accès en lecture seule réduisent le risque opérationnel. Les enregistrements GMP doivent conserver leur système de référence. Une sortie d’IA peut être exportée dans un rapport de travail, mais elle ne doit pas devenir silencieusement la nouvelle version d’une instruction, d’un dossier de lot ou d’une décision de qualité.

Cette discipline rejoint les principes décrits dans notre article sur les agents IA en industrie : l’utilité dépend des sources, des accès et des contrôles réalisés par l’équipe. En pharma, la frontière entre l’aide à l’analyse et une fonction GxP doit rester explicite.

Relier l’essai au cycle de vie du système

Le pilote ne remplace pas les travaux de qualification ou de validation. Il les prépare. Le guide GAMP 5 appliqué à l’automation pharma rappelle que l’effort dépend de l’usage prévu, des risques pour le patient, la qualité du produit, l’intégrité des données et le système qualité du site.

Pour une intégration qui se poursuit, les exigences utilisateur, l’analyse de risques, l’architecture, les interfaces, les responsabilités, les essais et les règles de changement doivent être reliés. Un modèle mis à jour, une nouvelle base documentaire ou une modification de prompt peut modifier le comportement du système. Ces évolutions ont besoin d’un propriétaire, d’une trace et de critères d’acceptation adaptés au périmètre retenu.

Donner un propriétaire à chaque évolution

Un pilote devient fragile lorsque sa maintenance reste implicite. Une équipe peut connaître le cas d’usage au lancement, puis changer de périmètre, de fournisseur, de base documentaire ou de méthode de revue quelques mois plus tard. Sans responsabilité définie, personne ne sait alors si la sortie actuelle reste comparable aux résultats des premiers tests.

Le propriétaire de procédé définit le besoin opérationnel et les conséquences d’une erreur. Le responsable du système gère l’architecture, les interfaces et les versions. La QA examine le niveau de contrôle attendu par le système qualité. L’IT et la cybersécurité traitent les identités, les accès, les transferts et la conservation des données. Le fournisseur peut expliquer son produit et fournir des éléments techniques, mais il ne peut pas décider à la place du site du niveau de risque acceptable.

Cette répartition doit apparaître dans le dossier de projet, même pour une première intégration limitée. Elle permet de répondre à des questions simples mais déterminantes : qui peut modifier les sources utilisées par le modèle ? Qui approuve une nouvelle version ? Quelle personne relit les résultats de test ? Qui arrête l’outil en cas de comportement inattendu ?

Un changement de prompt, de règle de filtrage, de modèle ou de corpus peut sembler mineur parce qu’il ne modifie pas un automate. Il peut pourtant modifier la réponse fournie à l’opérateur ou au relecteur. L’équipe doit donc décider quelles évolutions relèvent de la configuration courante et lesquelles demandent une analyse d’impact, des essais ou une approbation formelle. La réponse dépend du cas d’usage et du QMS ; elle ne peut pas être importée telle quelle d’un projet voisin.

Décider à partir du pilote

La fin d’un pilote doit produire une décision explicite. Poursuivre peut vouloir dire préparer une intégration avec des exigences, une architecture et un plan de qualification. Adapter peut vouloir dire réduire le périmètre à une tâche documentaire, compléter les données ou revoir le mode de contrôle humain. Arrêter peut être la bonne conclusion si les sources sont insuffisantes, si le temps de revue dépasse le gain attendu ou si le risque résiduel n’est pas acceptable.

Ces trois issues ont la même valeur lorsqu’elles reposent sur des cas de test et une analyse lisible. Elles évitent de maintenir un outil qui reste en démonstration permanente, sans règle claire pour son usage en production.

Vanguard Systems peut aider à cadrer le cas d’usage, cartographier le flux de données, préparer les critères de test et relier le pilote aux systèmes d’automation et de documentation existants. La décision qualité, l’évaluation réglementaire et l’autorisation de mise en production restent entre les mains des personnes habilitées par le site. Le service de qualification et validation et notre page dédiée à l’automation pharmaceutique décrivent ce périmètre de travail.

Sources : Swissmedic, cadre pour l’IA dans le cycle de vie des médicaments ; Swissmedic, notifications selon l’article 41 MPLO, V4.0.