Gérer les risques et évaluer les impacts de l’IA (clauses 6 et 8)

Durée indicative : 2 heures

4.1 Une méthodologie en quatre temps

ISO/IEC 42001 ne réinvente pas la gestion du risque : elle s’appuie, via ISO/IEC 23894, sur les principes bien établis d’ISO 31000, adaptés aux caractéristiques propres des systèmes d’IA. La clause 6.1 (planification) définit ce qui doit être fait ; la clause 8 (fonctionnement) en assure l’exécution concrète, système d’IA par système d’IA, tout au long de leur cycle de vie.

Le cycle de gestion des risques et des impacts d’un système d’IA.

4.2 Identifier et évaluer les risques d’un système d’IA

Contrairement à un risque informatique classique, un risque lié à l’IA combine souvent plusieurs dimensions qu’il convient d’examiner systématiquement :

• Risques techniques : performance insuffisante ou instable du modèle, dérive dans le temps (« drift »), vulnérabilité à des attaques adverses, dépendance à un fournisseur unique de modèle.
• Risques liés aux données : biais dans les données d’entraînement, qualité insuffisante, absence de base légale pour leur utilisation, fuite de données sensibles.
• Risques éthiques et sociétaux : discrimination directe ou indirecte, manque de transparence vis-à-vis des personnes affectées, atteinte à l’autonomie de décision humaine.
• Risques juridiques et réglementaires : non-conformité au règlement européen sur l’IA ou à d’autres textes applicables (protection des données, droit du travail, droit de la consommation).
• Risques réputationnels et d’affaires : perte de confiance des clients ou du public, coût de remédiation en cas d’incident médiatisé.

Pour chaque risque identifié, l’évaluation combine, comme dans toute démarche de gestion du risque, une estimation de la probabilité d’occurrence et de la gravité des conséquences si le risque se matérialise. La difficulté propre à l’IA est que la probabilité de certains risques (biais, dérive du modèle) est plus difficile à quantifier qu’un risque physique classique : une évaluation qualitative bien argumentée, révisée périodiquement, est préférable à une fausse précision chiffrée.

4.3 Traiter le risque : quatre options

Une fois évalué, un risque IA se traite selon les quatre options classiques de la gestion du risque, appliquées au contexte de l’IA :

• Éviter : renoncer à un cas d’usage jugé trop risqué au regard de la valeur attendue (par exemple, renoncer à automatiser entièrement une décision de licenciement).
• Réduire : mettre en place des contrôles pour ramener le risque à un niveau acceptable (audit de biais périodique, supervision humaine des décisions à fort enjeu, seuils de confiance en dessous desquels le système ne décide pas seul).
• Transférer : partager le risque avec un tiers, par exemple via une clause contractuelle avec un fournisseur de modèle, ou une couverture d’assurance dédiée aux risques technologiques.
• Accepter : documenter consciemment qu’un risque résiduel, après traitement, est jugé acceptable par la direction au regard des bénéfices attendus — une acceptation doit être formalisée et datée, jamais implicite.

4.4 L’évaluation d’impact d’un système d’IA (ISO/IEC 42005)

L’évaluation d’impact va au-delà de la gestion du risque interne à l’organisation : elle porte l’attention sur les conséquences d’un système d’IA pour les personnes et les groupes affectés par ses décisions, qu’ils soient parties prenantes contractuelles de l’organisation ou non. ISO/IEC 42005 propose une méthodologie structurée en plusieurs étapes : définir le périmètre du système évalué, identifier les parties prenantes potentiellement affectées (y compris des groupes vulnérables), documenter les impacts potentiels positifs et négatifs, évaluer leur ampleur, et consigner les mesures d’atténuation retenues.

Une évaluation d’impact bien conduite pour un outil de présélection de candidatures identifierait par exemple : les candidats comme partie prenante directe, un risque de discrimination indirecte si le modèle a été entraîné sur des données historiques biaisées, un impact potentiel sur des groupes protégés par la loi, et des mesures d’atténuation telles qu’un audit de biais avant mise en production et une supervision humaine systématique des décisions de rejet automatique.

4.5 Sélectionner les contrôles de l’annexe A et rédiger la déclaration d’applicabilité

Une fois les risques et impacts identifiés, l’organisation sélectionne, parmi les 38 contrôles de référence de l’annexe A organisés en 9 catégories, ceux qui sont pertinents pour traiter ses risques propres. Ce choix — et sa justification — constitue la déclaration d’applicabilité (« Statement of Applicability », SoA), document central de tout projet de certification, sur le même modèle que pour ISO/IEC 27001.

Les 9 catégories de contrôles de référence de l’annexe A d’ISO/IEC 42001.

Un contrôle non retenu doit être justifié (par exemple : « Non applicable, l’organisation ne développe pas de systèmes d’IA en interne ») ; un contrôle retenu doit être documenté avec son état de mise en œuvre. Un auditeur de certification vérifiera systématiquement la cohérence entre les risques identifiés en clause 6.1 et les contrôles effectivement sélectionnés — une SoA qui omettrait un contrôle directement lié à un risque majeur documenté par ailleurs constituerait une non-conformité probable.