09. Clause 8 : fonctionnement

Section 9 du cours « Pilotez un système d’IA | ISO/IEC 42001 ».

La clause 8 porte sur la mise en œuvre des actions planifiées. Le cours l’illustre surtout par la gestion quotidienne des modèles, leurs mises à jour et leur surveillance.

Repères de vocabulaire

• SMIA / AIMS : système de management de l’IA.

• MLOps : pratiques d’exploitation des modèles : déploiement, versions, surveillance et maintenance.

• SHAP / LIME : méthodes utilisées pour expliquer les résultats d’un modèle.

• KPI : indicateur clé de performance.

• PV : procès-verbal, compte rendu formel d’une décision.

Notions

• Clause 8 : appliquer les plans définis en clause 6. Vérifier dans les opérations que les mesures de traitement des risques et d’évaluation d’impact sont effectivement mises en œuvre.

• Cycle de vie : conception, développement, vérification, validation, déploiement, surveillance, mise à jour, mise hors service

• MLM : Model Lifecycle Management : gestion du cycle de vie des modèles

• Registre des modèles : finalité, propriétaire, sources de données, classe de risque, version, statut de déploiement, évaluations d'impact liées

• IA fantôme : modèle créé, testé ou mis en service hors de la vue de la gouvernance

• Gestion du changement réentraînement, réglage, nouveau public -> évaluation d'impact, revue parties prenantes, plan de retour arrière, analyse de performance après

• Dérive (drift) : baisse de performance ou d'équité quand les données réelles s'écartent des données d'entraînement

• Surveillance : planifiée (intervalles définis) + réactive (seuil ou événement atteint)

• Mise hors service : documentée, systèmes dépendants mis à jour ou remplacés, historique de performance archivé

• Explicabilité globale structure du modèle : poids des critères, règles de décision générales

• Explicabilité locale : raison d'une prédiction précise pour une entrée donnée

• SHAP, LIME : méthodes d'explication a posteriori (SHapley Additive exPlanations, Local Interpretable Model-agnostic Explanations)

• Modèles explicables : régression logistique, arbres de décision, modèles à règles

• Transparence : comment le système a été conçu, validé, déployé, encadré ; information de l'utilisateur qu'une IA intervient

• Journalisation : points de décision, entrées, comportement, erreurs, dérogations, alertes, interactions ; journaux sécurisés, infalsifiables, accès limité

• MLOps : DevOps étendu aux modèles, avec points de contrôle gouvernance

À retenir

• Clause 8 -> la gouvernance passe du papier aux opérations quotidiennes

• chaque étape du cycle de vie : procédure définie, adaptée à l'appétit pour le risque, à l'éthique, au droit

• Si un risque de biais est identifié, prévoir des tests d’équité avant la mise en production. Définir les critères d’acceptation selon le contexte et les exigences applicables.

• déploiement -> plan de secours en cas de panne ou de comportement inattendu

• systèmes adaptatifs ou autonomes -> surveillance continue, jamais ponctuelle

• aucune mise à jour de modèle sans validation ni supervision

• modèle réentraîné = même cycle de vie, lié aux versions précédentes (traçabilité)

• fournisseur, open source, API tierce -> mêmes exigences qu'en interne ; responsabilité non délégable

• tiers -> diligence raisonnable, transparence exigée, clauses contractuelles, questionnaires, audits

• situations d'urgence : arrêt manuel (véhicule autonome), coupe-circuit (trading), signalement du doute (diagnostic)

• Prévoir un canal de signalement facile à utiliser. Analyser les retours et répondre dans un délai défini.

Valider et expliquer les décisions

• mise en production -> approbation formelle : responsable du modèle, responsable risques IA, comité de surveillance

• déploiement limité aux domaines opérationnels validés, environnements versionnés

• validation -> précision, robustesse, tests adverses, équité, interprétabilité, cas limites, scénarios de stress

• documenter cas d'usage prévus et exclus dès le développement

• niveau d'explication adapté au public : technique (audit), simplifié (usager), schéma de décision (juriste)

• décision critique -> modèle transparent préféré, même au prix d'un peu de performance

• décision à fort impact -> dire qu'une IA intervient, sur quelles données, quel recours humain

• conservation des journaux proportionnée au risque (plus longue pour haut risque, données réglementées)

• Pouvoir reconstituer une décision contestée : données d’entrée, version du modèle, éléments d’explication et vérifications réalisées.

Exemples du cours :

• VTC (affectation) : hausse des plaintes dans une ville -> mise à jour fautive -> retour arrière + procédure de changement revue

• Administration : dérive après choc socio-économique -> alertes, comité humain, évaluation manuelle le temps du réentraînement, tout journalisé

• Assurance santé : registre (identifiant, risque, objectif) ; drift à 3 mois (nouvel hôpital) -> réentraînement ; retrait à 2 ans (nouvelle approche)

• Banque (crédit) : fraude : faux positifs après changement de marché -> analyse, réentraînement

• Banque (étude) : clause 4 contexte régulateurs ; clause 5 politique, responsable risques IA, comité ; 6.1.4 évaluation d'impact (discrimination indirecte par quartier) ; clause 8 données anonymisées, approbation si seuils parité démographique et prédictive respectés ; décision injustifiable -> revue humaine ; clause 9 rapport mensuel d'équité, KPI écart d'acceptation entre groupes protégés ; clause 10 biais régional -> réentraînement, cause racine, collecte revue

• Hôpital (triage) : risques : sous-triage des personnes âgées, symptômes rares graves manqués ; médecin peut passer outre, incertitude signalée, patient informé et peut demander un médecin ; baisse de précision à 6 mois (polypathologies) -> alerte, réentraînement, nouveaux critères de suivi, consultation patients

Lien avec l'audit IA

• Registre des modèles : tous les modèles en prod, en dev, en évaluation y figurent ? -> registre, rapprochement avec l'inventaire technique (recherche d'IA fantôme)

• Gestion du changement : dernier réentraînement : évaluation d'impact, approbation, plan de retour arrière ? -> ticket de changement, PV d'approbation, version taguée

• Validation : rapport de tests avant mise en prod (équité, robustesse) ? -> rapport signé

• Surveillance : seuils de dérive définis, alertes testées ? -> tableau de bord, historique d'alertes

• Tiers : contrat et diligence sur le modèle fournisseur ? -> clauses, questionnaire, audit

• Urgence : arrêt ou reprise manuelle possible ? -> procédure, test de bascule daté

• Journalisation : une décision contestée se reconstitue ? -> journal : entrées, version, horodatage

• Transparence usager : l'usager sait qu'une IA intervient et connaît le recours ? -> mentions, parcours

• Mise hors service : retrait documenté, dépendances traitées ? -> dossier de retrait, archive

• Déjà traité : inventaire et risques : ai-governance-fundamentals 02-inventaire.md, 03-risques.md ; AI Act, incidents : ai-governance-fundamentals 08-cadre-europeen-et-france.md ; journaux sécurisés : iso-27001 (mesures de journalisation et gestion des changements)

Précisions et points à vérifier

Les points ci-dessous signalent les limites du cours et les vérifications à poursuivre. Les exemples et recommandations du formateur ne sont pas tous des exigences de la norme.

• découpage officiel de la clause 8 : 8.1 maîtrise opérationnelle, 8.2 appréciation des risques IA, 8.3 traitement, 8.4 évaluation d'impact ; le cours n'en parle presque pas et met le cycle de vie au premier plan (ISO/IEC 42001:2023, 8.1 à 8.4)

• cycle de vie, registre, journaux : relèvent surtout de l'annexe A (A.4 ressources, A.6 cycle de vie, A.6.2.8 journaux d'événements, A.10 tiers), pas du texte de la clause 8 ; numéros à confirmer dans la norme

• « la norme impose de journaliser » : l'annexe A demande de déterminer à quelles phases les journaux sont activés ; pas de liste imposée (ISO/IEC 42001:2023, A.6.2.8)

• « article 7.5 traite de l'explicabilité » : 7.5 = informations documentées ; l'information des parties est en A.8 (ISO/IEC 42001:2023)

• « registre des modèles exigé » : inventaire attendu de fait, intitulé exact non vérifié (A.4, ISO/IEC 42001:2023)

• transcription : « CHAP, Chaplet » = SHAP, Shapley ; « cartes de science » = cartes de saillance ; « ISO 20001 » = ISO/IEC 27001 (ou ISO/IEC 20000-1) ; « SMIS / sécurité de l'information » en fin de leçon = AIMS

• Conservation des journaux : distinguer l’article 12 (capacité de journalisation), l’article 19 (fournisseur) et l’article 26 § 6 (déployeur). Portée et exceptions détaillées au modèle 8.

• information de l'usager qu'il interagit avec une IA : AI Act art. 50, règlement (UE) 2024/1689 ; droit à intervention humaine : RGPD art. 22

• parité démographique et parité prédictive en même temps : souvent incompatibles mathématiquement (voir leçon biais, section 10)

Questions de révision

• Quelles étapes du cycle de vie d'un modèle ? Réponse : conception, développement, validation, déploiement, surveillance, mise à jour, mise hors service.

• Que contient le registre des modèles ? Réponse : finalité, propriétaire, données, classe de risque, version, statut, évaluations d'impact.

• Un modèle réentraîné est-il un nouveau modèle ? Réponse : non, même cycle de vie, lié aux versions précédentes.

• Explicabilité globale ou locale ? Réponse : globale = logique du modèle ; locale = raison d'une décision précise.

• Modèle acheté à un fournisseur : qui est responsable ? Réponse : l'organisation qui l'utilise, gouvernance non délégable.

Leçons couvertes

Clause 8 Opérations ; Gestion du cycle de vie des modèles sous AIMS ; Exigences d'explicabilité, de transparence et de journalisation ; Étude de cas AIMS dans la finance et la santé.