Efficacité des contrôles IA : mesurer selon 9.1

Clause 9.1 : ce que la norme attend

La clause 9.1 de l'ISO/IEC 42001 impose à l'organisation de déterminer ce qui doit être surveillé et mesuré, les méthodes de surveillance et de mesure, le moment où ces activités doivent être réalisées, et le moment où les résultats doivent être analysés et évalués. Cette exigence reprend la logique présente dans toutes les normes de management fondées sur la structure harmonisée (HLS), que vous connaissez déjà via l'ISO 9001 ou l'ISO 27001^[2].

La différence tient à l'objet de la mesure. Dans un SMIA, vous ne mesurez pas seulement le respect d'une politique ou le taux de disponibilité d'un service. Vous devez aussi évaluer si les contrôles spécifiques à l'IA produisent l'effet attendu sur les risques identifiés, qu'il s'agisse de biais, de dérive de modèle, de sécurité ou de transparence^[4].

L'ISO 42001 suit la méthodologie Plan-Do-Check-Act^[3]. La clause 9.1 se situe dans la phase « Check ». Sans elle, les phases « Plan » et « Do » restent des déclarations d'intention. C'est cette clause qui transforme un catalogue de contrôles en un dispositif vivant, capable de signaler les dérives avant qu'elles ne deviennent des non-conformités.

Transposer l'expérience 9001/27001

Si votre organisation est déjà certifiée ISO 9001 ou ISO 27001, vous disposez d'un avantage considérable. L'ISO 42001 repose sur une structure identique à celle de ces normes de management^[2]. Vos processus de revue de direction, vos registres de non-conformités, vos procédures d'audit interne sont directement réutilisables. La question n'est pas de tout reconstruire, mais d'étendre le périmètre de mesure aux contrôles propres à l'IA.

Dans un SMSI ISO 27001, vous mesurez par exemple le taux de correctifs appliqués dans les délais, le nombre d'incidents de sécurité ou le résultat des tests de restauration. Pour un SMIA, la logique est la même, mais les indicateurs portent sur des objets différents : taux de faux positifs d'un modèle de classification, dérive statistique d'un jeu de données d'entraînement, délai de réponse à une demande d'explicabilité. Vous pouvez approfondir cette passerelle dans notre article sur les différences et passerelles entre ISO 42001 et ISO 27001.

Un point d'attention : ne transposez pas mécaniquement vos tableaux de bord ISO 27001. Les contrôles de l'Annexe A de l'ISO 42001 couvrent des domaines qui n'ont pas d'équivalent direct dans l'ISO 27001, comme l'équité, la transparence ou la gestion du cycle de vie des systèmes d'IA. Les neuf catégories de contrôles de l'Annexe A méritent chacune une réflexion spécifique sur les indicateurs pertinents.

Définir quoi mesurer et comment

La clause 9.1 demande de déterminer explicitement « quoi, comment, quand, et quand analyser ». En pratique, cela signifie documenter quatre éléments pour chaque contrôle retenu dans votre déclaration d'applicabilité (SoA).

Premièrement, l'objet de la mesure. Il ne suffit pas de dire « nous mesurons la performance du modèle ». Précisez quel indicateur, sur quel périmètre, avec quelle granularité. Par exemple : « taux de précision du modèle de scoring sur le segment des demandes de crédit à la consommation, mesuré mensuellement sur les prédictions du mois écoulé ».

Deuxièmement, la méthode. Un test statistique automatisé n'a pas la même valeur probante qu'une revue manuelle par échantillonnage. Choisissez la méthode en fonction du risque associé au contrôle. Pour un système d'IA classé à haut risque au sens du AI Act européen, une vérification automatisée continue sera plus adaptée qu'un contrôle trimestriel par sondage^[2].

Troisièmement, la fréquence. Elle dépend de la volatilité du risque. Un modèle de détection de fraude, alimenté en continu par de nouvelles données, nécessite un suivi plus serré qu'un modèle de classification documentaire mis à jour annuellement.

Quatrièmement, le moment de l'analyse. Collecter des données sans les analyser est un gaspillage. Fixez un calendrier d'analyse aligné sur vos instances de gouvernance : comité IA mensuel, revue de direction semestrielle ou annuelle.

Indicateurs par catégorie de contrôle

L'Annexe A de l'ISO 42001 regroupe les contrôles en catégories couvrant la gouvernance, les données, le cycle de vie, les impacts sur les individus, entre autres. Pour chaque catégorie, le type d'indicateur pertinent varie. Le tableau ci-dessous propose des pistes concrètes, à adapter selon votre contexte.

Exemples d'indicateurs par domaine de contrôle

Domaine de contrôle (Annexe A)	Exemple d'indicateur	Source de la donnée
Politique IA (A.2)	Taux de collaborateurs ayant pris connaissance de la politique IA	LMS ou registre de signatures
Données (A.7)	Pourcentage de jeux de données documentés selon le format requis[1]	Registre des données
Cycle de vie (A.6)	Nombre de mises en production sans validation documentée	Pipeline CI/CD, registre de changements
Impacts sur les individus (B.5.4)	Nombre de réclamations liées à une décision automatisée	Système de gestion des réclamations
Fournisseurs IA (A.10)	Pourcentage de fournisseurs IA évalués selon les critères définis	Registre des tiers
Transparence	Délai moyen de réponse à une demande d'explicabilité	Ticketing ou registre dédié

Ce tableau n'est pas normatif. Il illustre la diversité des objets de mesure dans un SMIA. L'important est que chaque indicateur soit relié à un contrôle précis de votre SoA et à un risque identifié dans votre registre des risques IA.

Les démarches observées montrent qu'un nombre limité d'indicateurs bien choisis (entre 8 et 15 pour un SMIA de taille moyenne) produit de meilleurs résultats qu'un tableau de bord pléthorique que personne ne consulte. Privilégiez la qualité de l'analyse sur la quantité de données collectées.

Collecte, fréquence et responsabilités

Un indicateur sans propriétaire est un indicateur mort. Pour chaque mesure, désignez un responsable de la collecte, un responsable de l'analyse, et un destinataire des résultats. Dans les organisations de taille modeste, ces trois rôles peuvent être tenus par la même personne, mais la distinction doit exister dans la documentation.

La fréquence de collecte mérite une réflexion par contrôle. Certains indicateurs se prêtent à une collecte automatisée en continu (métriques de performance du modèle, alertes de dérive). D'autres relèvent d'un contrôle périodique (revue annuelle de la politique IA, évaluation des fournisseurs). Évitez la tentation de tout mesurer en continu : le coût de collecte et d'analyse doit rester proportionné au risque.

Un calendrier de mesure aligné sur le cycle PDCA du SMIA facilite la cohérence. Par exemple : collecte mensuelle des métriques opérationnelles, analyse trimestrielle consolidée au comité IA, synthèse semestrielle pour la revue de direction. Ce rythme permet d'alimenter les décisions de la direction avec des données à jour, comme l'exige la clause 9.3^[3].

Analyser et évaluer les résultats

La collecte n'est que la moitié du travail. La clause 9.1 demande aussi d'analyser et d'évaluer les résultats. En pratique, cela signifie comparer les valeurs mesurées à des seuils prédéfinis, identifier les tendances, et en tirer des actions.

Définissez pour chaque indicateur un seuil d'alerte et un seuil de non-conformité. Par exemple, si votre modèle de scoring affiche un taux de faux négatifs inférieur à 5 %, le contrôle est considéré comme efficace. Entre 5 % et 8 %, une alerte déclenche une investigation. Au-delà de 8 %, une non-conformité est ouverte et un plan de traitement est requis, conformément à la logique décrite dans le traitement du risque IA.

L'analyse des tendances est souvent plus parlante que la valeur ponctuelle. Un indicateur qui reste dans la zone verte mais dérive régulièrement vers le seuil d'alerte signale un problème latent. C'est précisément ce type de signal faible que la clause 9.1 vise à capter.

Les résultats de l'évaluation alimentent trois processus : la revue de direction (clause 9.3), l'audit interne (clause 9.2) et l'amélioration continue (clause 10). Un indicateur qui reste constamment au vert peut aussi signifier que le seuil est trop lâche, ou que le contrôle mesure un risque qui n'existe plus. Remettez en question vos indicateurs au moins une fois par an.

Piège fréquent : confondre conformité et efficacité

Le piège le plus courant, observé dans les démarches de certification tous référentiels confondus, consiste à mesurer la conformité documentaire plutôt que l'efficacité réelle du contrôle. Avoir une politique IA signée par 100 % des collaborateurs ne dit rien sur le fait que cette politique influence réellement les pratiques quotidiennes.

La conformité documentaire est nécessaire, mais elle ne suffit pas. L'audit de certification ISO 42001 évalue non seulement l'existence des contrôles, mais aussi leur capacité à produire les résultats attendus en matière de gestion des risques IA^[2]. Un auditeur expérimenté distinguera rapidement un tableau de bord « cosmétique » d'un dispositif de mesure qui alimente de vraies décisions.

Pour éviter ce piège, posez-vous systématiquement la question : « Si cet indicateur passe au rouge, quelle décision prenons-nous ? » Si la réponse est floue, l'indicateur n'est probablement pas le bon. Un bon indicateur d'efficacité déclenche une action concrète : retraîner un modèle, suspendre un déploiement, renforcer un contrôle d'accès aux données d'entraînement.

Selon Deloitte, la confiance envers l'IA passe par des mécanismes de contrôle mesurables, vérifiables et cohérents^[4]. Cette exigence de vérifiabilité rejoint directement ce que la clause 9.1 attend : des preuves tangibles que vos contrôles fonctionnent, pas simplement qu'ils existent sur le papier.

Exemple concret romand

Prenons le cas d'une société de services financiers basée en Suisse romande, employant une cinquantaine de personnes, déjà certifiée ISO 27001, et qui déploie un modèle de scoring de crédit alimenté par apprentissage automatique. Elle décide d'étendre son système de management pour couvrir l'ISO 42001.

Le responsable qualité commence par identifier les contrôles de l'Annexe A applicables à ce système d'IA, documentés dans la SoA. Pour le contrôle relatif à l'équité (lié aux impacts sur les individus), il définit l'indicateur suivant : écart de taux d'approbation entre groupes démographiques, mesuré mensuellement, avec un seuil d'alerte fixé à 3 points de pourcentage et un seuil de non-conformité à 5 points.

La collecte est automatisée via un script qui interroge la base de décisions du mois écoulé. L'analyse est présentée au comité IA trimestriel. Lors du deuxième trimestre, l'indicateur passe de 1,8 à 4,2 points. Le comité décide de lancer une investigation sur les données d'entraînement récentes, identifie un biais introduit par un nouveau jeu de données fournisseur, et déclenche un retraînement du modèle avec un jeu corrigé.

Ce scénario illustre la boucle complète : définition, collecte, analyse, décision, action. Sans la mesure, le biais serait resté invisible jusqu'à une réclamation client ou, pire, un contrôle réglementaire. Pour approfondir la gestion des fournisseurs de données et de modèles, consultez notre article sur les risques fournisseurs IA selon A.10.

Notez que cet exemple reste simplifié. Dans la réalité, la définition des groupes démographiques pertinents, le choix de la métrique d'équité et la détermination des seuils font l'objet de discussions approfondies, souvent avec le DPO et le service juridique. L'ISO 42001 ne prescrit pas les seuils : elle exige que vous les définissiez, que vous les documentiez et que vous agissiez lorsqu'ils sont dépassés.

Pour un responsable qualité habitué aux revues de processus ISO 9001, cette logique est naturelle. La nouveauté réside dans la nature technique des indicateurs et dans la nécessité de collaborer étroitement avec les équipes data science. La gouvernance des risques IA ne se construit pas en silo : elle suppose un dialogue permanent entre qualité, technique et métier.

Questions fréquentes

À lire ensuite