Évaluation d’impact IA ISO 42001 : un modèle qu’une PME peut réellement remplir

L’évaluation d’impact IA est le seul artefact qu’ISO 42001:2023 exige et qu’ISO 27001 n’exige pas. C’est aussi celui que les PME surcompliquent le plus souvent — un dossier de 40 pages au lieu d’un document d’une page par cas d’usage qu’un auditeur peut réellement lire.

ISO/IEC 42001:2023 clause 6.1.4, renforcée par la clause opérationnelle 8.4, exige une évaluation d’impact des systèmes d’IA pour les systèmes d’IA dans le périmètre du système de management de l’IA. Là où la clause 6.1.2 d’ISO 27001 demande d’évaluer les risques de sécurité de l’information contre la triade CID, ISO 42001 demande d’évaluer chaque système d’IA contre ses préoccupations de fiabilité et son impact sur les personnes. C’est le pont entre le registre de risques IA et les contrôles que vous sélectionnez — et comme la Déclaration d’applicabilité d’ISO 27001, c’est le document que l’auditeur lit en premier.

Cet article donne une structure de modèle qu’une équipe IT d’une à trois personnes peut remplir par cas d’usage en une heure, explique ce que les clauses exigent réellement, et traverse un exemple concret.

Ce qu’exigent réellement les clauses 6.1.4 / 8.4

La norme exige que l’organisme évalue les impacts des systèmes d’IA sur les individus, les groupes, la société et l’organisme lui-même, en tenant compte de la finalité prévue, du contexte d’utilisation, et des préoccupations de fiabilité qui s’appliquent. L’évaluation informe quels contrôles sont sélectionnés et enregistrés dans la Déclaration d’applicabilité. La norme n’impose pas un format fixe, une longueur fixe, ni que chaque préoccupation de fiabilité s’applique à chaque système — elle impose que l’évaluation ait lieu, qu’elle soit documentée, et qu’elle pilote les contrôles.

Ce dernier point est celui qui compte pour l’audit : les contrôles dans votre SoA devraient remonter à une préoccupation identifiée dans une évaluation d’impact. Un contrôle sans évaluation derrière lui est un contrôle implémenté pour la liste de contrôle, pas pour le risque.

Le modèle : les sections qu’une PME nécessite

Utilisez un document par cas d’usage IA, avec ces huit sections. Moins et vous perdez la piste d’audit ; plus et vous arrêtez de le maintenir.

La ligne Préoccupations de fiabilité fait double emploi : c’est là que vous décidez lesquelles des six préoccupations s’appliquent réellement (ne cochez pas les six par réflexe — cela signale que vous n’avez pas évalué), et elle alimente la sélection des contrôles. La ligne Contrôles appliqués est ce qui entre dans la SoA.

Un exemple PME concret

Un petit cabinet de services professionnels utilise un LLM hébergé par un fournisseur pour rédiger les premières réponses aux courriels de support client. L’évaluation :

C’est une page. Elle nomme les préoccupations qui s’appliquent réellement, laisse tomber celles qui ne s’appliquent pas (avec le raisonnement visible), relie chaque contrôle à une préoccupation, et fixe un déclencheur de revue. C’est une évaluation 6.1.4 défendable — et la ligne des contrôles est l’entrée de la SoA.

Trois erreurs à éviter

• **Tout cocher.** Une évaluation qui applique les six préoccupations de fiabilité à chaque système dit à l’auditeur que vous n’avez pas évalué, vous avez listé. Les vraies évaluations excluent des préoccupations avec une raison — « équité : non applicable, le système n’informe pas de décisions sur des individus. »
• **Des contrôles sans préoccupation.** Si un contrôle dans votre SoA ne remonte à aucune préoccupation dans une évaluation d’impact, soit l’évaluation l’a manqué, soit le contrôle est injustifié. Réconciliez les deux avant l’audit.
• **Une fois pour toutes.** La clause 8.2 (héritée de la structure partagée) exige une réévaluation à intervalles planifiés ou lors d’un changement significatif. Un réentraînement de modèle, un nouveau cas d’usage, ou un changement de fournisseur est un déclencheur. Fixez la date de revue dans l’évaluation et honorez-la.

Comment cela s’intègre dans la série

L’évaluation d’impact est le pendant IA de l’évaluation des risques ISO 27001, et c’est l’artefact qui alimente la SoA intégrée décrite dans la mise en œuvre conjointe 27001 + 42001. L’expliqueur Annexe A est là où vivent les objectifs de contrôle que vous sélectionnez ici. Si vous commencez le travail de gouvernance IA, le pilier ISO 42001 est le point d’entrée.

Que faire ensuite

Ouvrez un document, copiez le modèle à huit sections, et remplissez-le pour le système d’IA que votre équipe utilise le plus. Décidez quelles préoccupations de fiabilité s’appliquent réellement, écrivez le raisonnement d’une ligne pour chaque exclusion, et listez les contrôles par préoccupation. Cette seule page — une heure de travail — est votre première évaluation 6.1.4 conforme et l’entrée de votre SoA. Répétez par cas d’usage ; la plupart des PME en ont moins de cinq.

Vous voulez une seconde passe sur vos évaluations d’impact IA avant un audit ? Réservez une **évaluation des écarts de gouvernance IA** de 30 min — nous revoyons chaque évaluation contre la clause 6.1.4, signalons les contrôles injustifiés et les préoccupations manquantes, et vous remettons les corrections. Bilingue FR/EN, sans obligation.

→ /fr/iso-42001-evaluation/