Risques vs analyse d'impact ISO 42001 : la différence

Deux exercices, deux points de vue

ISO/IEC 42001 impose deux activités d'évaluation distinctes mais liées. La première, adossée à la clause 6.1.2, cible les risques que l'IA fait courir à l'organisation. La seconde, adossée à la clause 6.1.4, cible les impacts que ces mêmes systèmes exercent sur les personnes, les groupes et la société^[8]. Confondre les deux est probablement l'erreur la plus fréquente observée sur les projets ISO 42001, et c'est aussi la plus visible en audit.

La distinction tient en une phrase : l'appréciation des risques répond à la question « qu'est-ce qui peut mal tourner pour nous », l'analyse d'impact répond à « qui subit quoi ». Les deux angles se recouvrent en partie, mais ils ne produisent pas la même documentation, ne mobilisent pas les mêmes acteurs et ne conduisent pas aux mêmes décisions de traitement^[1].

Pour un responsable conformité ou un DPO qui arrive d'un univers RGPD, la confusion est presque inévitable. Une AIPD (analyse d'impact relative à la protection des données) porte sur les traitements de données personnelles. Une analyse d'impact IA au sens d'ISO 42001 va plus loin : elle intègre l'équité, l'explicabilité, la robustesse, les effets sociétaux, y compris pour des systèmes qui ne traitent aucune donnée personnelle^[5].

Chaque clause pose une question différente et produit un livrable propre.

6.1.2Risques pour l'organisation

6.1.4Impacts sur personnes, groupes, société

Répartition des questions posées par chacune des deux clauses^[8].

Ce que couvre l'appréciation des risques (6.1.2)

La clause 6.1.2 relève du chapitre planification du SMIA. Elle demande d'identifier, d'analyser et d'évaluer les risques que le système d'IA fait peser sur l'atteinte des objectifs de l'organisation, sur ses obligations réglementaires et sur ses parties intéressées côté business^[8]. Le regard est organisationnel : perte financière, atteinte réputationnelle, non-conformité, rupture opérationnelle, dépendance à un fournisseur.

Les catégories de risques propres à l'IA que le référentiel invite à couvrir dépassent le périmètre classique de la sécurité de l'information : biais et amplification de discriminations, dérive de modèle, attaques adverses, absence d'explicabilité, comportement autonome inattendu, mémorisation de données sensibles par le modèle^[8]. Cette liste n'est pas exhaustive mais elle marque la spécificité par rapport à une appréciation ISO 27001 orientée confidentialité, intégrité, disponibilité.

La méthode elle-même reste classique dans sa structure : critères de vraisemblance, critères de gravité, tolérance au risque, calcul d'un niveau de risque et arbitrage de traitement^[8]. Ce qui change, c'est la nature des scénarios évalués et l'obligation d'intégrer les résultats de l'analyse d'impact dans la cotation, sujet traité plus bas. Les modalités concrètes de cette clause sont détaillées dans notre guide sur l'appréciation des risques IA selon la clause 6.1.2.

Ce que couvre l'analyse d'impact (6.1.4)

La clause 6.1.4 introduit un exercice que n'imposait aucune des normes de management précédentes de la série. Elle demande à l'organisation d'évaluer les conséquences, positives et négatives, que le système d'IA produit sur les personnes concernées, les groupes d'individus et la société^[1]. Le point de vue bascule : on ne parle plus de ce que l'organisation risque, on parle de ce que l'organisation fait subir ou apporte à l'extérieur.

Un cabinet spécialisé qualifie cet exercice de pièce documentaire la plus substantielle d'un projet ISO 42001, à comparer à une AIPD RGPD dans sa logique mais plus longue et plus détaillée^[5]. Cette lecture converge avec les templates que reprennent les guides indépendants, structurés en sections sur le système, les données, les modèles, les parties prenantes affectées et les mesures d'atténuation^[5].

Sur le plan méthodologique, l'analyse d'impact regarde tout le cycle de vie, de la conception au retrait, et interroge des dimensions que la seule appréciation des risques laisse dans l'ombre : équité algorithmique, dignité, autonomie décisionnelle, effets externes sur des tiers non-clients^[5]. Notre article analyse d'impact IA, exemple et méthode détaille la trame en sept étapes couramment retenue.

Une note sur ISO/IEC 42005

Selon un consultant senior d'un cabinet britannique, à la date de son analyse en juin 2024, ISO/IEC 42005 est le standard support consacré spécifiquement au format et au contenu de l'analyse d'impact d'un système d'IA^[5]. Vérifier l'évolution depuis cette date reste prudent, notamment pour confirmer le statut de publication et le contenu final retenu par les organismes de certification.

Comment les deux s'articulent

Les deux clauses ne sont pas parallèles, elles sont chaînées. Selon un praticien reconnu du sujet, la norme recommande d'incorporer les résultats de l'analyse d'impact dans l'appréciation des risques, ce qui plaide pour conduire l'analyse d'impact d'abord et l'appréciation des risques ensuite^[1]. Cet ordre n'est pas anecdotique : il conditionne la cotation.

Un exemple : un système d'IA qui recommande un contenu et un système d'IA qui pré-trie des candidatures peuvent partager la même vraisemblance de défaillance technique. Mais leur impact sur les personnes n'a rien à voir. Sans analyse d'impact préalable, la cotation de gravité produite au titre de la clause 6.1.2 va sous-estimer le second cas. Avec analyse d'impact préalable, la gravité intègre l'irréversibilité de la décision et la population affectée.

La logique de bouclage fonctionne aussi dans l'autre sens. Un risque identifié en 6.1.2 (par exemple une dérive de modèle) peut, une fois qualifié, réveler des impacts nouveaux à examiner en 6.1.4 (par exemple des effets discriminatoires apparus avec la dérive). L'articulation est donc itérative, et c'est cette itération que doit démontrer un système documentaire crédible en audit.

Distinctions opérationnelles entre 6.1.2 et 6.1.4^[8]

Question centrale	6.1.2 : que risque l'organisation ? / 6.1.4 : qui est affecté et comment ?
Point de vue	6.1.2 : interne / 6.1.4 : parties prenantes externes et société
Clause associée en exploitation	6.1.2 rappelée en 8.2 / 6.1.4 rappelée en 8.4
Déclencheur	6.1.2 : tout système d'IA dans le périmètre / 6.1.4 : systèmes à impact potentiel significatif

Livrables attendus en audit

Un auditeur ISO 42001 ne se contente pas d'un document unique qui mélangerait risques et impacts. Il attend au minimum deux corpus distincts, référencés à leurs clauses respectives, avec une preuve de traçabilité entre les deux. La déclaration d'applicabilité renvoie ensuite aux contrôles de l'Annexe A retenus pour traiter les scénarios cotés.

Côté 6.1.2, les pièces attendues comprennent la méthodologie d'appréciation documentée (échelles, critères, seuils de tolérance), le registre des risques, les cotations avant et après traitement, et le lien avec le plan de traitement au titre de la clause 6.1.3^[8].

Côté 6.1.4, on attend un rapport d'analyse d'impact par système d'IA significatif, structuré selon un format cohérent (typiquement inspiré d'ISO/IEC 42005), incluant la description du système, les datasets, les modèles, la cartographie des parties prenantes affectées, la cotation des impacts et les mesures d'atténuation retenues^[5]. La cadence de revue doit être définie et respectée.

Un point souvent sous-estimé : la trace de bouclage. L'auditeur cherche des preuves que les constats de l'analyse d'impact ont effectivement fait évoluer la cotation des risques et le choix des contrôles. Un tableau de correspondance entre effets identifiés en 6.1.4, risques cotés en 6.1.2 et contrôles activés dans l'Annexe A suffit généralement à démontrer la maturité de l'articulation.

Pièges fréquents de confusion

Le premier piège, courant chez les organisations qui viennent d'ISO 27001, consiste à traiter l'analyse d'impact comme un simple chapitre supplémentaire de l'appréciation des risques. Le résultat est un document hybride, orienté organisation, qui passe à côté des effets sociétaux et des populations vulnérables^[1]. Ce défaut ressort en audit dès que l'auditeur demande la liste des parties affectées non-clientes.

Le deuxième piège, symétrique, vient des équipes issues du RGPD. Elles produisent une AIPD sur les données personnelles, la renomment analyse d'impact IA, et considèrent la clause 6.1.4 satisfaite. La norme demande davantage : équité algorithmique, transparence, robustesse, effets sur des groupes qui ne sont pas nécessairement des personnes concernées au sens du RGPD^[5]. Notre comparaison entre ISO 42001 et RGPD détaille ce point.

Le troisième piège est l'oubli des effets positifs. L'analyse d'impact regarde autant le bénéfice apporté aux personnes et à la société que les préjudices potentiels^[1]. Négliger cette dimension appauvrit l'exercice et prive la direction d'un argumentaire utile pour arbitrer entre déploiement, restriction ou abandon d'un cas d'usage.

Le quatrième piège concerne le déclencheur. La clause 6.1.2 s'applique à tout système d'IA dans le périmètre du SMIA, alors que la clause 6.1.4 se déclenche pour les systèmes présentant un impact potentiel significatif^[8]. Sans critère documenté pour qualifier ce seuil de significativité, l'organisation s'expose soit à un travail inutile sur des outils internes triviaux, soit à un oubli sur un système sensible.

Cas d'illustration en contexte romand

Imaginons une PME romande de services financiers qui déploie un modèle de scoring pour préqualifier des demandes de crédit à la consommation. La clause 6.1.2 conduit à lister ce que la PME risque : sanction du régulateur si le modèle produit des décisions discriminatoires, perte de confiance client, dérive silencieuse du modèle qui dégraderait le taux de défaut, dépendance à un fournisseur de plateforme MLOps.

La clause 6.1.4 pose des questions différentes : quels demandeurs sont refusés à tort, quels groupes socio-économiques voient leur taux d'acceptation baisser sans justification métier, quelle voie de recours existe pour une personne qui conteste la décision, quelle est la transparence effective sur les critères mobilisés. Ces questions ne remontent pas naturellement dans un registre de risques classique.

Le bouclage utile : l'analyse d'impact révèle un écart d'acceptation entre deux profils comparables. Ce constat, ramené dans l'appréciation des risques, fait passer la gravité du scénario « biais du modèle » de moyenne à haute, ce qui déclenche un audit de biais externe et un renforcement de la supervision humaine sur les cas limites. Sans le bouclage, l'organisation aurait sous-évalué le risque et sous-provisionné son plan de traitement.

Ce type de cas illustre pourquoi les deux clauses ne se remplacent pas et pourquoi l'ordre chronologique compte. Il illustre aussi pourquoi une cartographie initiale des systèmes IA conditionne la qualité des deux exercices : sans inventaire fiable, ni l'un ni l'autre ne peut être considéré comme exhaustif.

Questions fréquentes

À lire ensuite