ISO 42001 : à qui s'applique cette norme IA ?

Ce que la clause 1 dit du périmètre

La clause 1 de l'ISO/IEC 42001 définit le champ d'application de la norme en des termes volontairement larges. En substance, elle vise toute organisation qui fournit, développe ou utilise des produits ou services reposant sur l'intelligence artificielle^[7]. Aucune restriction sectorielle, aucune taille minimale, aucune localisation géographique imposée.

Cette ouverture n'est pas un accident de rédaction. Les normes de système de management ISO suivent une structure harmonisée (dite « Harmonized Structure ») qui permet de les appliquer à des contextes très divers^[7]. Si vous connaissez déjà l'ISO 27001 ou l'ISO 9001, vous retrouverez la même logique : la norme fixe des exigences, votre organisation définit le périmètre dans lequel elle les applique.

En pratique, cela signifie que la question n'est pas « l'ISO 42001 s'applique-t-elle à mon entreprise ? » mais plutôt « quels systèmes d'IA mon entreprise exploite-t-elle, et quel périmètre de management vais-je définir autour d'eux ? ». C'est la clause 4.1, sur la compréhension du contexte de l'organisation, qui vous guide dans cette délimitation. Nous y revenons plus bas.

Taille de l'organisation : aucune barrière d'entrée

L'un des malentendus les plus répandus chez les dirigeants de PME tient en une phrase : « cette norme, c'est pour les grands groupes ». La réalité est différente. Selon SOCOTEC, organisme de certification, les grandes entreprises comme les petites et moyennes entreprises peuvent bénéficier de l'ISO 42001, car la norme offre des lignes directrices flexibles adaptées à différentes tailles d'organisation et niveaux de maturité en matière d'IA^[6].

DQS, autre organisme de certification accrédité, confirme cette lecture : la norme s'applique à toute organisation, quels que soient sa taille, son secteur d'activité ou sa situation géographique^[7]. Le point déterminant n'est donc pas votre chiffre d'affaires ou votre effectif, mais la présence de systèmes d'IA dans vos activités.

Pour une PME de 30 personnes qui utilise un outil de scoring automatisé dans son processus commercial, le SMIA sera naturellement plus léger que celui d'un éditeur de logiciels IA employant 500 ingénieurs. La norme le permet : elle exige un système proportionné au contexte, pas un dispositif bureaucratique uniforme. Si vous vous demandez concrètement comment adapter la démarche à une structure de petite taille, notre article sur l'ISO 42001 pour une PME détaille ce point.

Secteurs concernés : un tour d'horizon réaliste

Puisque la norme ne cible aucun secteur en particulier, la liste des domaines concernés s'allonge au rythme de la diffusion de l'IA. Certifopac, certificateur français, mentionne explicitement la finance, la santé, le e-commerce et la cybersécurité^[1]. FeelAgile ajoute que la norme répond aux exigences réglementaires croissantes liées à l'AI Act, au RGPD et à NIS2^[3], ce qui élargit de facto le champ aux secteurs soumis à ces textes.

Le secteur public est également visé. Administrations, collectivités et instituts de recherche utilisant ou expérimentant des systèmes d'IA sont concernés^[1]. DQS inclut aussi le milieu universitaire dans le périmètre^[7].

Secteurs et exemples d'usages IA typiques

Secteur	Exemple d'usage IA	Exigence réglementaire associée
Finance	Scoring crédit automatisé	AI Act (haut risque), RGPD
Santé / Medtech	Aide au diagnostic par imagerie	AI Act (haut risque), MDR
Industrie	Maintenance prédictive	NIS2 (si infrastructure critique)
Services publics	Chatbot de guichet	AI Act (transparence)
Éditeur SaaS	Moteur de recommandation	AI Act, RGPD

Ce tableau illustre la diversité des cas, mais il ne prétend pas à l'exhaustivité. L'observation de terrain montre que même des secteurs traditionnels (logistique, agriculture, formation professionnelle) intègrent désormais de l'IA, souvent via des outils tiers. Si votre organisation utilise un service cloud intégrant de l'IA générative, vous êtes déjà dans le périmètre potentiel de la norme.

Pour comprendre comment la norme s'articule avec le règlement européen sur l'IA, consultez notre comparatif ISO 42001 et AI Act.

Fournisseur, développeur, utilisateur : trois profils, une norme

La norme distingue implicitement trois postures face à l'IA. Selon DQS, elle s'adresse à toute organisation qui fournit, développe ou utilise des systèmes d'IA^[7]. Microsoft, dans sa documentation de conformité, précise que la norme est conçue pour les entités fournissant ou utilisant des produits ou services basés sur l'IA^[8]. Certifopac parle quant à lui d'organisations qui développent, intègrent ou utilisent des systèmes IA^[1].

Ces formulations convergent vers trois profils distincts :

• Le fournisseur : il conçoit et commercialise un système d'IA (éditeur de logiciels, plateforme SaaS, service cloud).
• Le développeur interne : il construit des modèles ou des pipelines IA pour les besoins de sa propre organisation.
• L'utilisateur : il déploie ou exploite un système d'IA développé par un tiers, sans nécessairement maîtriser le modèle sous-jacent.

La distinction compte, car les risques et les contrôles diffèrent selon le profil. Un fournisseur doit documenter la conception, les données d'entraînement et les biais potentiels de son modèle. Un utilisateur, lui, doit s'assurer que le système qu'il déploie reste conforme dans son contexte d'usage. La déclaration d'applicabilité (SoA) reflétera ces différences : un utilisateur n'activera pas les mêmes contrôles de l'Annexe A qu'un fournisseur.

Pour un dirigeant de PME, la question pratique est souvent : « nous ne faisons qu'utiliser un outil IA, sommes-nous vraiment concernés ? ». La réponse est oui, dès lors que cet outil influence des décisions affectant des personnes ou des processus critiques. La norme attend de vous que vous compreniez ce que fait le système, que vous en évaluiez les risques et que vous en assuriez la gouvernance, même si vous n'avez pas écrit une ligne de code.

Quels rôles internes sont mobilisés ?

La norme ne prescrit pas d'organigramme type, mais elle exige que les responsabilités soient clairement attribuées. En pratique, plusieurs fonctions sont sollicitées lors de la construction d'un SMIA.

La direction générale porte la responsabilité première : c'est elle qui définit la politique IA, alloue les ressources et s'assure que le système de management est aligné sur la stratégie de l'organisation. FeelAgile souligne que la gouvernance et la responsabilité doivent être définies au plus haut niveau^[3].

Au-delà de la direction, les rôles suivants sont généralement impliqués :

• Responsable du SMIA (parfois appelé AI Officer) : pilote opérationnel du système de management.
• Responsable conformité ou DPO : assure l'articulation avec le RGPD, la nLPD ou l'AI Act.
• Responsable qualité : si un SMQ (ISO 9001) ou un SMSI (ISO 27001) existe déjà, il coordonne l'intégration.
• Équipes techniques : data scientists, ingénieurs ML, développeurs qui opèrent les systèmes d'IA au quotidien.
• Métiers utilisateurs : les collaborateurs qui exploitent les résultats de l'IA dans leurs décisions.

Dans une PME, ces rôles se cumulent souvent. Le directeur technique peut être à la fois responsable du SMIA et référent technique. Ce cumul est acceptable tant que les responsabilités sont documentées et que les conflits d'intérêts sont gérés. Pour une vue complète de la structure de la norme et des clauses qui détaillent ces exigences, reportez-vous à notre guide clause par clause.

La clause 4.1 : définir votre propre contexte

La clause 4.1 demande à l'organisation de déterminer les enjeux externes et internes pertinents par rapport à sa finalité et qui influent sur sa capacité à atteindre les résultats attendus du SMIA. En langage opérationnel, cela revient à répondre à trois questions : qui sommes-nous, dans quel environnement opérons-nous, et quels systèmes d'IA sont en jeu ?

Les enjeux externes incluent le cadre réglementaire (AI Act si vous exportez vers l'UE, nLPD en Suisse), les attentes des clients et partenaires, et l'état de l'art technologique. Les enjeux internes couvrent la culture d'entreprise, les compétences disponibles, les systèmes d'IA déjà déployés et le niveau de maturité en gouvernance.

Cette analyse de contexte n'est pas un exercice théorique. Elle détermine le périmètre de votre SMIA et, par conséquent, l'effort de mise en conformité. Une PME qui n'utilise qu'un chatbot de support client n'aura pas le même contexte qu'un éditeur de logiciels dont le produit principal repose sur du machine learning.

Le livrable attendu est un document qui recense ces enjeux. Il n'a pas besoin d'être volumineux, mais il doit être à jour et cohérent avec la politique IA que vous définirez ensuite. L'auditeur vérifiera que votre périmètre SMIA découle logiquement de cette analyse de contexte.

Le piège fréquent : confondre périmètre IA et périmètre IT

Les organisations qui disposent déjà d'un SMSI certifié ISO 27001 commettent souvent la même erreur : elles calquent le périmètre du SMIA sur celui du SMSI. Or les deux ne se superposent pas nécessairement.

Le périmètre IT couvre les actifs informationnels et leur sécurité. Le périmètre IA couvre les systèmes qui apprennent, infèrent ou génèrent des résultats à partir de données, avec des enjeux spécifiques : biais, transparence, impact sur les personnes. DQS rappelle que la norme traite de caractéristiques propres à l'IA, notamment la dépendance aux données, l'apprentissage continu, les attentes en matière de transparence et les impacts sur les personnes, les organisations et la société^[7].

Prenons un cas concret. Votre SMSI couvre l'ensemble de votre infrastructure cloud. Mais votre SMIA pourrait ne couvrir que le module de recommandation produit qui utilise du machine learning, car c'est le seul système qui répond à la définition d'un système d'IA au sens de la norme. À l'inverse, un outil d'IA générative utilisé par le département marketing pourrait être hors du périmètre SMSI (pas d'enjeu de sécurité de l'information critique) mais pleinement dans le périmètre SMIA (enjeux de biais, de propriété intellectuelle, de transparence).

Si vous envisagez d'intégrer les deux systèmes de management, notre article sur l'intégration ISO 42001 et ISO 27001 détaille les passerelles et les points de vigilance.

Exemple concret : une PME romande de medtech

Imaginons une PME de 45 collaborateurs basée dans l'Arc lémanique, spécialisée dans les dispositifs médicaux. Elle a développé un algorithme d'aide au tri de clichés radiologiques, vendu à des hôpitaux suisses et à deux cliniques en Allemagne.

Cette entreprise cumule deux profils : fournisseur (elle commercialise un système d'IA) et développeur (elle conçoit le modèle en interne). Son contexte (clause 4.1) inclut des enjeux réglementaires lourds : le règlement européen sur les dispositifs médicaux (MDR), l'AI Act (son système relève probablement de la catégorie haut risque puisqu'il touche au domaine médical), et la nLPD pour les données de patients suisses.

Son SMIA couvrira le cycle de vie complet du modèle : données d'entraînement, validation, déploiement, surveillance post-marché. Les rôles mobilisés : le CEO (engagement de la direction), le responsable qualité (déjà en place pour l'ISO 13485), un data scientist senior désigné comme responsable du SMIA, et le DPO pour l'articulation avec la protection des données.

Le périmètre ne couvre pas le site web de l'entreprise ni son ERP, même s'ils font partie du périmètre SMSI. Il se concentre sur le système d'IA et les processus qui l'entourent. Cette délimitation claire est précisément ce que la clause 4.1 attend.

SOCOTEC indique que la norme est applicable à divers contextes et applications d'IA^[6]. Le cas de cette PME medtech illustre qu'une structure de taille modeste, avec un seul système d'IA, peut définir un périmètre SMIA cohérent et gérable.

Pour un résumé rapide de l'ensemble de la norme avant de vous lancer, le condensé en 10 minutes pour dirigeant offre un bon point de départ. Et pour approfondir l'ensemble du pilier, retrouvez tous nos contenus sur le hub Comprendre la norme.

Questions fréquentes

À lire ensuite