Contrôles opérationnels

Ce que recouvrent les contrôles opérationnels

La certification ISO/IEC 42001 ne s'arrête pas à la rédaction d'une politique IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire et d'une cartographie des risques. La clause 8, intitulée « Fonctionnement », est celle qui transforme les engagements pris en amont (clauses 5 à 7 : leadership, planification, support) en pratiques vérifiables au quotidien. C'est le chapitre que les auditeurs creusent le plus, parce que c'est celui où l'écart entre ce qui est écrit et ce qui est fait devient visible.

Un système d'IA en production n'est pas un artefact figé. Ses donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire d'entrée évoluent, ses utilisateurs détournent parfois son usage prévu, et ses performances se dégradent souvent sans qu'aucune alarme technique classique ne se déclenche. Les contrôles opérationnels couvrent précisément cette zone grise : le monitoring continu, la détection de dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire, la supervision humaine effective et la gestion des incidents liés à l'IA.

Planification et maîtrise opérationnelles (clause 8.1)

La clause 8.1 demande à l'organisme de planifier, mettre en œuvre et maîtriser les processus nécessaires pour répondre aux exigences identifiées en clause 6 (traitement des risques et des impacts) et pour réaliser les actions prévues. Concrètement, cela se traduit par :

• des critères documentés pour chaque étape du cycle de vie du système (conception, données, entraînement, validation, déploiement, retrait) ;
• la maîtrise des processus externalisés — modèle pré-entraîné, jeu de données tiers, plateforme d'hébergement — au même niveau d'exigence que les processus internes ;
• une gestion des changements formalisée : toute modification substantielle (ré-entraînement, changement de fournisseur de modèle, ajout d'une source de données) déclenche une réévaluation des risques avant mise en production.

Un ré-entraînement n'est pas un non-événement. S'il change le comportement du système de façon mesurable, il doit suivre le même circuit d'approbation qu'une nouvelle version : évaluation d'impact, tests de non-régression, validation par les parties prenantes désignées.

Le monitoring continu : que surveiller, et à quelle fréquence

Le monitoring d'un système d'IA en production dépasse la supervision applicative classique (disponibilité, latence, taux d'erreur HTTP). Il ajoute une couche spécifique liée au comportement du modèle et à ses données.

Fixez les seuils d'alerte avant la mise en production, sur la base d'une baseline mesurée en environnement contrôlé. Un seuil défini après coup, une fois l'incident constaté, n'est pas un contrôle : c'est une justification a posteriori — un point que les auditeurs repèrent systématiquement.

La dérive : trois phénomènes à ne pas confondre

Le terme « drift » est souvent employé de façon générique. Pour la norme comme pour la pratique, il recouvre trois mécanismes distincts, qui appellent des réponses différentes.

Dérive des données (data drift) — la distribution statistique des données reçues en production s'éloigne de celle utilisée à l'entraînement, sans que la relation entre variables et résultat attendu change nécessairement. Exemple : un modèle de scoring crédit entraîné avant une période inflationniste reçoit des montants de revenus et de dépenses qui ont structurellement changé d'échelle.

Dérive conceptuelle (concept drift) — la relation entre les données d'entrée et la sortie attendue change dans le monde réel. Le modèle continue de recevoir des données statistiquement proches de celles de l'entraînement, mais l'association qu'il a apprise n'est plus valide. Exemple : un modèle de détection de fraude entraîné sur des schémas d'attaque anciens devient obsolète dès que les fraudeurs changent de méthode.

Dérive de performance (model drift) — conséquence mesurable des deux précédentes, ou d'une cause tierce (changement d'infrastructure, bug de pipeline de features). C'est l'indicateur de sortie : la baisse effective de justesse, de rappel ou de toute métrique métier.

Détecter ces dérives suppose une instrumentation dédiée :

• tests statistiques de divergence de distribution (indice de stabilité de population — PSI, divergence de Kullback-Leibler) sur les variables d'entrée ;
• évaluation en miroir (« shadow evaluation ») : faire tourner en parallèle une nouvelle version du modèle sans qu'elle influence les décisions, pour comparer ses sorties à la version en production ;
• déploiement canari sur un sous-ensemble de trafic avant généralisation ;
• audit humain périodique par échantillonnage, y compris lorsque les métriques automatiques restent stables — certaines dérives concernent des sous-populations trop petites pour apparaître dans une moyenne globale.

La dérive silencieuse est le scénario le plus dangereux à l'audit : le système ne tombe jamais en panne, aucune alerte technique ne se déclenche, mais sa pertinence s'érode progressivement pour un sous-groupe d'utilisateurs ou un cas d'usage marginal. Sans échantillonnage humain régulier et sans métriques désagrégées par sous-population, cette dérive reste invisible jusqu'à ce qu'un tiers — client, régulateur, journaliste — la signale.

Supervision humaine : concevoir le contrôle, pas le simuler

La norme distingue plusieurs configurations de supervision humaine, souvent résumées ainsi :

• Human-in-the-loopHuman-in-the-loopIABoucle où un opérateur humain valide, corrige ou arbitre les décisions du système IA avant une action irréversible.Voir dans le glossaire — une décision individuelle ne peut être exécutée sans validation humaine préalable. Adapté aux décisions à fort impact individuel et à faible volume (licenciement assisté par IA, refus de prestation).
• Human-on-the-loop — le système agit de façon autonome, un humain supervise en continu et peut intervenir ou interrompre. Adapté aux volumes élevés où une validation systématique serait impraticable (modération de contenu, détection de fraude en temps réel).
• Human-in-command — un humain conserve l'autorité globale sur l'activationfonction d'activationIAOpération non linéaire appliquée en sortie d'un neurone. Sans elle, empiler des couches serait inutile : une succession d'opérations linéaires reste équivalente à une seule.Voir dans le glossaire, la portée et l'arrêt du système, sans nécessairement valider chaque décision individuelle. C'est le niveau minimal exigible pour tout système à impact significatif.

Un outil de présélection de candidatures est configuré en « human-in-the-loop » sur le papier : chaque rejet automatique doit être validé par un recruteur. Dans les faits, le volume de candidatures pousse les recruteurs à valider par lots de cinquante en quelques secondes, sans ouvrir les dossiers individuels. La supervision existe formellement mais n'a aucune capacité réelle de correction — c'est ce qu'on appelle la supervision de façade (« oversight theater »), l'un des constats d'audit les plus fréquents sur ce point de contrôle.

Concevoir une supervision effective suppose de répondre à des questions concrètes : le superviseur dispose-t-il du temps et de l'information nécessaires pour exercer un jugement réel ? A-t-il l'autorité et la procédure pour bloquer une décision sans justification excessive à produire ? Est-il formé à reconnaître les limites du système plutôt qu'à faire confiance par défaut à sa sortie ?

Concevez les seuils d'escalade humaine sur des critères objectifs : score de confiance du modèle sous un seuil donné, appartenance à une catégorie sensible identifiée en évaluation d'impact, ou désaccord entre deux modèles évalués en parallèle. Une escalade laissée à la seule appréciation de l'opérateur de terrain, sans critère écrit, est difficile à auditer et rarement appliquée de façon homogène.

Gestion des incidents liés à l'IA

Un incident IA n'est pas nécessairement une panne. La définition retenue est large : tout événement où le système produit un résultat préjudiciable, discriminatoire, dangereux, ou s'écarte significativement de son usage prévu — que le système soit techniquement « en panne » ou non.

Le cycle de traitement suit une logique proche de la gestion d'incident de sécurité, avec des spécificités propres à l'IA :

1. Détection — via monitoring automatique, signalement utilisateur, audit interne, ou alerte d'un tiers.
2. Triage et classification de sévérité — impact individuel ou systémique, réversibilité, nombre de personnes concernées, sensibilité de la catégorie de données ou de décision.
3. Confinement — désactivation ciblée (kill switch), retour à une version antérieure du modèle (rollback), limitation de débit ou de portée le temps de l'investigation.
4. Analyse de cause racine — distinguer défaut de données, dérive non détectée, mauvais usage, défaillance de supervision, ou limite structurelle du système.
5. Action corrective — au sens de la clause 10 : correction immédiate, puis mesure empêchant la récurrence, avec preuve d'efficacité.
6. Communication — vers les parties prenantes concernées, à un niveau de détail proportionné à l'impact ; certaines réglementations imposent des délais de notification pour les incidents touchant des droits fondamentaux.
7. Enregistrement — traçabilité complète conservée comme preuve d'audit (clause 9, informations documentées).

Le kill switch n'est un contrôle réel que s'il a été testé en conditions proches du réel avant l'incident. Un mécanisme d'arrêt documenté mais jamais exercé — parce qu'il rompt une dépendance métier non anticipée, ou parce que personne ne connaît la procédure d'activation — reste un contrôle sur le papier, pas un contrôle opérationnel.

Rôles et responsabilités dans la boucle opérationnelle

La clause 8 fonctionne rarement si elle repose sur une seule fonction. Dans les organisations qui obtiennent la certification sans réserve majeure, on retrouve généralement une répartition claire :

• Propriétaire du système d'IA (business owner) — responsable de la pertinence métier, valide les seuils d'alerte et les critères d'arrêt.
• Équipe MLOps / plateforme — responsable de l'instrumentation technique : capture des métriques, alerting, exécution du rollback.
• Fonction risque et conformité — responsable de la cohérence entre la classification de risque établie en clause 6 et le niveau de supervision effectivement appliqué.
• Superviseurs humains opérationnels — responsables de l'exercice réel du contrôle, avec un mandat clair pour bloquer une décision sans validation hiérarchique préalable en cas de doute sérieux.

Cette répartition doit apparaître dans la documentation du système d'IA, pas uniquement dans un organigramme général de l'entreprise. Un auditeur qui demande « qui a l'autorité pour arrêter ce système, et depuis quand cette personne le sait-elle » doit trouver une réponse immédiate, pas une reconstruction a posteriori.

Amélioration continue et lien avec la clause 10

Les contrôles opérationnels ne sont pas une fin en soi : ils alimentent la clause 10 (amélioration) et la revue de direction (clause 9.3). Chaque dérive détectée, chaque incident traité, chaque seuil ajusté doit remonter comme donnée d'entrée de la revue périodique du système de management. Un AIMS mature montre une trajectoire observable : les mêmes causes racines n'apparaissent pas deux fois de suite dans le registre d'incidents, et les seuils de détection évoluent avec l'expérience opérationnelle plutôt que de rester figés depuis la certification initiale.

Checklist opérationnelle

• Baseline de performance et seuils d'alerte définis avant mise en production, pas après incident.
• Indicateurs de dérive suivis par sous-population, pas uniquement en moyenne globale.
• Procédure de gestion des changements couvrant le ré-entraînement et les mises à jour de fournisseur tiers.
• Configuration de supervision humaine (in-the-loop / on-the-loop / in-command) documentée et cohérente avec le volume réel de décisions.
• Critères d'escalade humaine écrits et objectifs, pas laissés à l'appréciation individuelle.
• Kill switch et procédure de rollback testés au moins une fois hors contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire d'incident réel.
• Registre d'incidents IA distinct ou intégré au registre qualité existant, avec classification de sévérité.
• Délais de notification aux parties prenantes définis par catégorie de gravité.

Pièges fréquents à l'audit

Les non-conformités relevées sur ce chapitre reviennent souvent aux mêmes causes : des seuils de dérive absents ou fixés arbitrairement après un incident, une supervision humaine documentée mais non exercée dans les faits faute de temps alloué, un kill switch jamais testé, et une confusion entre journalisation technique (logs applicatifs) et enregistrements de gouvernance exigés par la norme (décisions, justifications, preuves de revue). Un système peut être parfaitement journalisé au sens technique et rester dépourvu de toute preuve de contrôle opérationnel au sens de l'ISO/IEC 42001.