Articles Données & environnements régulés

Projet d’Annexe 22 : une frontière nette pour l’IA dans les usages GMP critiques

Le projet européen d’Annexe 22 encadre les modèles statiques et déterministes pour les applications GMP critiques et écarte modèles dynamiques, IA générative et LLM. Une feuille de route pratique : usage prévu, données de test indépendantes, critères et surveillance.

Sommaire de l’article

Le projet de nouvelle Annexe 22 a été publié pour consultation avec le chapitre 4 et l’Annexe 11 révisés. La consultation s’est close le 7 octobre 2025 ; au 30 août 2026, la page de la Commission le présente toujours comme un projet. Ce statut compte : il s’agit d’un signal réglementaire détaillé, pas d’une Annexe GMP adoptée.

Le périmètre proposé est plus étroit que le mot « IA ». Il concerne des modèles entraînés sur des données, intégrés à des systèmes informatisés et utilisés dans des applications GMP critiques ayant un impact direct sur la sécurité du patient, la qualité du produit ou l’intégrité des données. Le projet couvre les modèles statiques et à sortie déterministe.

Le projet indique que les modèles qui apprennent dynamiquement en exploitation, les sorties probabilistes, l’IA générative et les grands modèles de langage ne sont pas couverts et ne devraient pas être utilisés dans des applications GMP critiques. Pour un usage non critique, il renvoie à une responsabilité humaine qualifiée sur l’adéquation de la sortie.

Statut réglementaireProjet de consultation, non adopté. Les formulations « devrait » ci-dessous décrivent le projet 2025, pas une nouvelle obligation déjà applicable.
Frontière proposéeCritique GMP : modèle statique, sortie déterministe, usage prévu borné. Dynamique, probabiliste, génératif et LLM restent hors du périmètre proposé.

Partie 1 — Écrire l’usage prévu comme une frontière testable

Le projet demande une description détaillée de la tâche assistée ou automatisée, fondée sur la connaissance du procédé. Elle inclut l’espace des données d’entrée, les variations communes et rares, les limitations et les entrées erronées ou biaisées plausibles. Un expert du procédé doit être responsable de l’adéquation de cette description avant les tests d’acceptation.

Cette exigence empêche une validation générique du modèle. « Détecter des défauts » n’est pas assez précis : il faut identifier familles de défauts, équipements, sites, matières, conditions d’éclairage ou de capteur, seuils, sortie attendue, action humaine et conséquences d’une erreur. La frontière d’usage devient alors une spécification contre laquelle des tests peuvent échouer.

À éviterValider une précision moyenne puis étendre l’usage sans nouvelle preuve.
À exigerUsage prévu → espace d’entrée → sous-groupes → erreurs critiques → critères → action et escalade.

Partie 2 — Protéger l’indépendance des données de test

Le projet distingue développement, entraînement, validation et test final. Les données de test doivent représenter l’espace d’usage, inclure les sous-groupes et variations rares, disposer de labels hautement fiables et rester indépendantes des équipes et données utilisées pour entraîner le modèle.

La séparation n’est pas seulement statistique. Le projet propose des contrôles d’accès et un audit trail sur le référentiel de test, l’absence de copies parallèles, l’enregistrement des jeux utilisés et du nombre de tests. Lorsque la séparation des personnes est impossible, il envisage un principe de quatre yeux.

Les critères d’acceptation sont liés à l’usage et peuvent varier par sous-groupe. Pour une classification, le projet cite comme exemples matrice de confusion, sensibilité, spécificité, exactitude, précision et score F1. Le choix ne doit pas être guidé par la métrique la plus flatteuse, mais par le coût des faux positifs et faux négatifs pour le procédé réel.

Partie 3 — Maintenir le modèle dans sa frontière approuvée

Une acceptation initiale ne protège pas contre une dérive du procédé, du capteur, de la population d’entrée ou du logiciel environnant. Le paquet de contrôle doit versionner modèle, code de prétraitement, données et labels de test, configuration, dépendances et seuils ; il doit aussi définir les indicateurs de performance en exploitation et les déclencheurs de revue.

Le projet associe le human-in-the-loop à des responsabilités explicites. Ajouter un humain après la sortie ne réduit pas automatiquement le risque : il faut définir ce qu’il voit, quand il peut contester, comment sa performance est formée et suivie, et quelle trace relie sortie, jugement et décision finale.

Dans un usage GMP critique, « l’IA fonctionne » n’est pas une conclusion de validation. La conclusion doit nommer l’usage borné, les sous-groupes testés, les erreurs acceptables, la version approuvée et la condition de retrait.

Contrôle opérationnel — dossier minimum d’un modèle critique

  • Usage prévu approuvé avec espace d’entrée, variations rares, limitations, sorties et actions.
  • Version immuable du modèle et de tout prétraitement, avec dépendances et configuration.
  • Jeu de test indépendant, protégé par accès et audit trail, représentatif de chaque sous-groupe critique.
  • Métriques et critères d’acceptation justifiés par le risque d’erreur, pas par la seule performance moyenne.
  • Surveillance, changement contrôlé, responsabilités humaines et critères d’arrêt ou de retour arrière.

Graphe de décision — le cas d’usage entre-t-il dans la frontière proposée ?

ÉtapeQuestionSuite
1. CriticitéLa sortie affecte-t-elle directement patient, produit ou intégrité des données ?Non → gouvernance proportionnée hors usage critique. Oui → vérifier le type de modèle.
2. TypeLe modèle est-il statique et sa sortie déterministe ?Non → hors frontière proposée pour le critique. Oui → définir l’usage.
3. TestLe jeu final est-il indépendant, représentatif et protégé ?Non → ne pas accepter. Oui → appliquer les critères par sous-groupe.
4. ExploitationVersion, surveillance, humain responsable et retrait sont-ils contrôlés ?Non → ne pas mettre en service. Oui → décision qualité documentée.

Informations manquantes et limites

  • Le texte reste un projet ; son périmètre et ses exigences peuvent changer avant adoption.
  • Le projet ne définit pas une métrique universelle ni un seuil chiffré applicable à tous les modèles.
  • L’articulation détaillée avec le règlement européen sur l’IA et les autres obligations sectorielles nécessite une analyse séparée.

Sources primaires citées

Date limite de vérification : 30 août 2026.

Voir aussi

Tous les articles, par sujet

Ce sujet rejoint le vôtre ?

Décrivez le problème et l’échéance : la réponse indique ce qui est faisable, ce qui ne l’est pas, et à quelles conditions.

Cadrer le besoin Estimer une enveloppe
Restez informé

Ce sujet vous intéresse ? Recevez les prochains articles.

Choisissez les sujets qui vous intéressent et la fréquence. Aucun spam, désinscription en un clic.

Les prochains articles sur ce sujet, envoyés à leur parution — et rien d’autre.

Quels sujets vous intéressent ?

Sujets facultatif

Où envoyer la réponse ? Votre adresse reste sur l’infrastructure du site. Aucun service tiers.

Vos réponses sont enregistrées sur l’infrastructure du site. Aucun service tiers, aucun traceur publicitaire.

Pour appliquer cet article

Le cadre méthodologique derrière ce que vous venez de lire.

Dites en un clic sur quoi vous travaillez : la ressource envoyée est celle qui traite ce sujet, pas un catalogue générique.

Vous venez de lire la théorie ; le cadre qui la met en œuvre est publié et vous est envoyé gratuitement.

Sur quoi travaillez-vous en ce moment ?

Le chantier en cours facultatif

Le chantier que cet article vous a fait envisager : c’est lui qui décide du cadre méthodologique envoyé.

Une fois le document lu, que ferez-vous ? facultatif

Demander un avis n’engage rien et ne coûte rien : c’est la réponse qui ouvre l’Office Hours, pas une mission.

Où envoyer la réponse ? Le lien de téléchargement part immédiatement. Aucune séquence commerciale.

Vos réponses sont enregistrées sur l’infrastructure du site. Aucun service tiers, aucun traceur publicitaire.