Clause 8 : maîtrise opérationnelle et processus fournis par l'extérieur
La clause 8 est le passage de l'intention à l'exécution. Son dernier alinéa de 8.1 est aussi l'endroit où se règle la question des fournisseurs d'IA.
La clause 8 met en œuvre ce que la clause 6 a planifié. Sa structure la reflète : 8.2 exécute l’appréciation du risque définie en 6.1.2, 8.3 exécute le traitement défini en 6.1.3, 8.4 exécute l’évaluation d’impact définie en 6.1.4.
Ce dédoublement n’est pas une redondance. La clause 6 exige de définir les processus ; la clause 8 exige de les faire tourner, à intervalles planifiés et lors de changements significatifs. Un processus défini mais jamais rejoué depuis sa rédaction est un écart sur la clause 8, pas sur la clause 6.
8.1 — Planification et maîtrise opérationnelles
Le dernier alinéa est stratégique et souvent ignoré. Il signifie qu’une API de génération appelée par votre produit, un assistant déployé sur abonnement ou un modèle open-weight auto-hébergé ne sortent pas de votre responsabilité parce qu’ils viennent de l’extérieur. La maîtrise attendue est proportionnée à votre rôle et à votre marge de manœuvre réelle, mais elle n’est pas nulle.
Les contrôles A.10.2 et A.10.3 de l’Annexe A déclinent cette exigence pour la répartition des responsabilités et pour les fournisseurs. C’est là qu’il faut les chercher — pas dans le domaine A.8, qui traite de l’information des parties intéressées.
8.2 et 8.3 — Apprécier et traiter, réellement
Deux questions suffisent à un auditeur pour situer une organisation : à quelle date remonte la dernière appréciation, et qu’est-ce qui a changé depuis. Une évaluation unique, datée du montage du dossier de certification, est l’indice le plus net d’un système qui ne tourne pas.
Le traitement, en 8.3, ajoute une exigence que l’on néglige : vérifier l’efficacité des mesures engagées. Une action clôturée sans mesure de son effet ne prouve rien, et l’absence de revue d’efficacité est l’omission la plus fréquente relevée par les praticiens, tous domaines confondus.
8.4 — L’évaluation d’impact, en exploitation
Le déclencheur le plus courant est aussi le plus facile à manquer : la mise à jour du modèle. Lorsqu’un fournisseur change de version, le comportement du système change sans qu’aucune ligne de votre code n’ait bougé. Une évaluation d’impact qui datait de la version précédente ne décrit plus le système en production.
Ce que la clause 8 ne demande pas
Aucun modèle de cycle de vie n’est imposé. La norme ne prescrit ni méthode de développement, ni jeu de tests, ni seuil de performance. ISO/IEC 22989 et ISO/IEC 5338 traitent du cycle de vie et peuvent servir de référence, mais elles ne sont pas exigées par ISO/IEC 42001.