Plan de traitement des risques IA : construire une réponse structurée selon la clause 6.1.3

Ce que la clause 6.1.3 attend de vous

La clause 6.1.3 de l'ISO/IEC 42001 prolonge directement l'évaluation des risques (clause 6.1.2). Là où l'évaluation identifie et hiérarchise les risques, la clause 6.1.3 vous oblige à décider quoi en faire et à documenter cette décision dans un plan formel. Sans ce plan, l'évaluation reste un exercice théorique.

Concrètement, l'organisation doit, pour chaque risque retenu après évaluation, choisir une option de traitement, sélectionner les contrôles appropriés, désigner un responsable et fixer un calendrier. La norme ISO 42001 suit la méthodologie PDCA commune aux normes de systèmes de management ISO^[2], ce qui signifie que le plan de traitement s'inscrit dans la phase « Plan » du cycle.

Le plan de traitement des risques est une information documentée que l'auditeur demandera systématiquement. Il ne s'agit pas d'un document figé : il évolue à chaque cycle de revue, en fonction des résultats de surveillance et des changements dans le périmètre des systèmes d'IA couverts par le SMIA.

Les quatre options de traitement des risques IA

Comme dans d'autres normes de systèmes de management, la clause 6.1.3 prévoit quatre options face à un risque identifié. Leur application aux risques spécifiques à l'IA mérite toutefois une lecture adaptée, car les risques d'un système d'IA (biais algorithmiques, opacité, résultats non intentionnels) ne se traitent pas comme un risque d'accès non autorisé à un serveur^[1].

Options de traitement et leur application aux risques IA

Option	Principe	Exemple IA
Réduction (atténuation)	Appliquer des contrôles pour ramener le risque à un niveau acceptable	Ajouter un mécanisme de détection de biais sur un modèle de scoring
Transfert (partage)	Transférer tout ou partie du risque à un tiers	Souscrire une assurance responsabilité civile IA ou externaliser l'hébergement à un fournisseur certifié
Évitement	Supprimer l'activité qui génère le risque	Renoncer à déployer un modèle de reconnaissance faciale dans un contexte à haut risque
Acceptation	Conserver le risque tel quel, en connaissance de cause	Accepter un risque résiduel faible sur un chatbot interne à usage limité

L'acceptation du risque résiduel doit toujours être formalisée et validée par le niveau hiérarchique approprié. Un risque accepté sans trace écrite est un risque ignoré, ce qui constitue une non-conformité.

Dans la pratique, la plupart des risques IA font l'objet d'une réduction. L'évitement reste rare mais pertinent lorsque le rapport bénéfice/risque d'un système d'IA ne se justifie pas, notamment pour les systèmes à haut risque au sens du Règlement européen sur l'IA^[1].

Contenu du plan de traitement des risques

Le plan de traitement des risques IA n'a pas de format imposé par la norme, mais il doit contenir suffisamment d'informations pour qu'un auditeur puisse vérifier que chaque risque a été traité de manière traçable. En s'inspirant de la logique des plans de traitement utilisés dans d'autres systèmes de management ISO^[3], un plan opérationnel comprend typiquement les éléments suivants.

• Référence du risque (lien vers le registre des risques)
• Option de traitement retenue
• Contrôles sélectionnés (avec référence à l'Annexe A le cas échéant)
• Responsable du traitement (nom ou fonction)
• Ressources nécessaires (budget, compétences, outils)
• Échéance de réalisation
• Niveau de risque résiduel attendu après traitement

Chaque ligne du plan doit pouvoir être reliée à une entrée du registre des risques. Si votre organisation gère déjà un plan de traitement pour l'ISO 27001, la structure sera familière^[3]. La différence tient à la nature des contrôles : ceux de l'ISO 42001 couvrent des domaines propres à l'IA comme l'atténuation des biais, la gouvernance des données ou la réponse aux incidents IA^[4].

Un point souvent négligé : le plan doit aussi documenter les risques que l'organisation choisit d'accepter. Un tableau qui ne montre que des actions de réduction donne l'impression que certains risques ont été oubliés plutôt qu'acceptés délibérément.

Granularité du plan

La granularité dépend du nombre de systèmes d'IA dans le périmètre du SMIA. Pour une organisation qui exploite deux ou trois modèles, un unique document tabulaire suffit. Pour une organisation qui gère des dizaines de systèmes, il est préférable de structurer le plan par système d'IA ou par domaine de risque, avec un document de synthèse consolidé pour la direction.

Quelle que soit la granularité choisie, le plan doit rester un document vivant. Les risques IA évoluent rapidement, notamment lorsque les modèles sont réentraînés ou que les données d'entrée changent. Un plan figé depuis douze mois sera questionné en audit.

Articuler le plan avec les contrôles de l'Annexe A

L'Annexe A de l'ISO 42001 fournit un catalogue de contrôles de référence spécifiques aux risques liés à l'IA^[4]. Ces contrôles couvrent, entre autres, l'atténuation des biais, la gouvernance des données et la réponse aux incidents. L'Annexe B fournit un guide de mise en œuvre associé^[4].

Lors de l'élaboration du plan de traitement, vous devez comparer les contrôles que vous avez sélectionnés avec ceux de l'Annexe A. Cette comparaison débouche sur la déclaration d'applicabilité, qui justifie l'inclusion ou l'exclusion de chaque contrôle de référence. Le plan de traitement et la déclaration d'applicabilité sont deux documents distincts mais étroitement liés : le premier dit « comment » vous traitez un risque, la seconde dit « quels contrôles » vous avez retenus ou écartés, et pourquoi.

En interprétation, il est recommandé de numéroter les contrôles du plan en reprenant les références de l'Annexe A. Cela facilite la traçabilité lors de l'audit et évite les doublons lorsque plusieurs risques sont couverts par le même contrôle.

Contrôles propres à l'organisation

L'Annexe A n'est pas limitative. Si un risque spécifique à votre contexte n'est couvert par aucun contrôle de référence, vous pouvez définir un contrôle propre. Cela arrive fréquemment pour des risques liés à des cas d'usage très sectoriels (par exemple, un modèle de prédiction de sinistres dans l'assurance ou un outil de triage médical). Le plan de traitement doit alors documenter ce contrôle additionnel avec le même niveau de détail que les contrôles issus de l'Annexe A.

Exemple pratique : un éditeur romand face au biais

Prenons le cas fictif d'un éditeur de logiciels RH basé en Suisse romande, qui intègre un module de présélection de candidatures alimenté par un modèle de traitement du langage naturel. L'évaluation des risques (clause 6.1.2) a identifié un risque de biais de genre dans le classement des CV, lié à un jeu de données d'entraînement historiquement déséquilibré.

Le plan de traitement pourrait se structurer ainsi. L'option retenue est la réduction. Le contrôle principal est un mécanisme de test de biais exécuté avant chaque mise en production du modèle, aligné sur le contrôle de l'Annexe A relatif à l'atténuation des biais^[4]. Un contrôle complémentaire prévoit un audit trimestriel des résultats du modèle par un comité interne incluant un représentant RH et un data scientist.

Le responsable désigné est le responsable produit IA. L'échéance de déploiement du test de biais est fixée à trois mois. Le risque résiduel attendu est qualifié de « faible » après application des contrôles, sous réserve que le jeu de données soit rééquilibré. La direction valide formellement le risque résiduel.

Ce type de documentation, même succinct, répond aux attentes de la clause 6.1.3. L'auditeur pourra suivre le fil : du risque identifié au contrôle appliqué, du contrôle au responsable, du responsable au résultat mesuré.

Pièges fréquents et comment les éviter

Les démarches de conformité menées sur d'autres référentiels ISO font apparaître des schémas d'erreur récurrents. Ils s'appliquent au plan de traitement des risques IA avec quelques spécificités.

Le plan « copier-coller » de l'ISO 27001

Les organisations qui possèdent déjà un SMSI ISO 27001 sont tentées de dupliquer leur plan de traitement existant en remplaçant « sécurité de l'information » par « IA ». Le problème : les risques IA incluent des dimensions que l'ISO 27001 ne couvre pas, comme les biais algorithmiques, l'opacité des modèles ou les résultats non intentionnels^[1]. Un plan qui ne traite que la confidentialité et l'intégrité des données sans aborder ces risques spécifiques sera jugé incomplet.

Le partage de structure entre les deux normes est tout à fait pertinent (elles suivent la même structure de haut niveau^[1]), mais le contenu des contrôles doit refléter les risques propres à l'IA.

L'absence de risque résiduel documenté

Un plan qui indique « risque traité » sans quantifier ou qualifier le risque résiduel ne remplit pas son rôle. L'auditeur cherche à vérifier que la direction a pris une décision éclairée sur le niveau de risque qu'elle accepte après traitement. Sans cette information, il est impossible de déterminer si les contrôles sont proportionnés.

Le plan orphelin

Un plan de traitement rédigé une fois puis jamais mis à jour constitue un signal d'alerte. La norme ISO 42001 s'inscrit dans un cycle d'amélioration continue^[2]. Le plan doit être révisé au minimum lors de chaque revue de direction, et idéalement à chaque changement significatif dans les systèmes d'IA couverts (nouveau modèle, changement de données d'entraînement, modification du périmètre).

La confusion entre risque IA et risque projet

Le plan de traitement des risques au sens de la clause 6.1.3 porte sur les risques liés à l'utilisation des systèmes d'IA (biais, atteintes à la vie privée, défaillances de sécurité, impacts sociétaux^[4]), pas sur les risques de gestion de projet (retard de livraison, dépassement de budget). Mélanger les deux dilue le plan et complique l'audit.

Intégration avec un plan de traitement ISO 27001 existant

Pour les organisations qui détiennent déjà une certification ISO 27001, la question de l'intégration se pose immédiatement. Les deux normes partagent la même structure de haut niveau (HLS), ce qui permet de mutualiser le cadre de management, la méthodologie de risques, le programme d'audit et la structure documentaire^[1].

En pratique, cela signifie qu'un registre des risques unique peut couvrir à la fois les risques de sécurité de l'information et les risques IA, à condition que les colonnes du registre permettent de distinguer la nature du risque et le référentiel de contrôle applicable (Annexe A de l'ISO 27001 vs. Annexe A de l'ISO 42001). Le plan de traitement peut suivre la même logique : un document unifié avec des sections clairement identifiées par norme.

Le plan de traitement se situe entre l'évaluation et la déclaration d'applicabilité dans la chaîne documentaire du SMIA.

1Registre des risques (6.1.2) : risques identifiés et évalués

2Plan de traitement (6.1.3) : options, contrôles, responsables, délais

3Déclaration d'applicabilité : contrôles Annexe A retenus ou exclus

4Validation direction : acceptation du risque résiduel

Ce flux s'applique tant à l'ISO 42001 qu'à l'ISO 27001 lorsque les systèmes sont intégrés.

L'intégration réduit l'effort de maintenance documentaire. Selon BALTUM, un programme intégré ISO 27001 + ISO 42001 peut réduire l'effort total de 35 à 45 % par rapport à des démarches séquentielles indépendantes^[1]. Ce chiffre est avancé par un organisme de conseil (vérifier l'évolution depuis cette date, la source datant de 2025 environ).

Attention toutefois : intégrer ne signifie pas fusionner aveuglément. Les contrôles de l'Annexe A de l'ISO 42001 couvrent des domaines absents de l'ISO 27001 (gouvernance des données d'entraînement, supervision humaine, transparence des décisions algorithmiques). Le plan de traitement intégré doit refléter cette spécificité, faute de quoi l'auditeur ISO 42001 constatera des lacunes.

Calendrier de révision

Dans un système intégré, alignez les cycles de révision du plan de traitement sur le calendrier d'audit interne commun. La norme prévoit une surveillance des performances après déploiement et un suivi des incidents^[1]. Chaque incident IA documenté devrait déclencher une relecture du plan de traitement pour vérifier si les contrôles en place sont encore adaptés. Cette boucle de rétroaction est ce qui distingue un SMIA vivant d'un exercice de conformité sur papier.

Questions fréquentes

À lire ensuite