À qui s'applique l'ISO 42001 ?

La règle générale : fournir ou utiliser de l'IA suffit

La première clause de la norme, celle qui fixe son domaine d'application, est large et sans ambiguïté. L'ISO/IEC 42001 s'adresse à toute organisation qui fournit ou utilise des produits ou des services recourant à des systèmes d'intelligence artificielle.^[1] Elle est applicable quels que soient la taille, le type et la nature de cette organisation.^[1]

Le point qui surprend le plus est qu'il n'est pas nécessaire de construire de l'IA pour entrer dans le champ de la norme. Le simple fait d'utiliser un outil qui en contient suffit. Une étude de notaire qui s'appuie sur un assistant de rédaction, un commerce qui déploie un moteur de recommandation, une fiduciaire qui pré-trie ses documents avec un classifieur : toutes manipulent de l'IA au sens de la norme, même si aucune ne la développe.

La page officielle de la norme le confirme dans les mêmes termes. Elle est destinée aux organisations de toute taille impliquées dans le développement, la fourniture ou l'usage de produits ou de services fondés sur l'IA, dans tous les secteurs, secteur public compris, au même titre que les entreprises et les organisations à but non lucratif.^[4]

Ce que la norme appelle une organisation

Le mot organisation peut laisser penser à une grande structure. La définition retenue par la norme est bien plus inclusive. Une organisation y est un individu ou un groupe de personnes doté de ses propres fonctions, avec des responsabilités et des relations, pour atteindre ses objectifs.^[3]

La note qui accompagne cette définition énumère ce que recouvre le terme : un indépendant, une société, une entreprise, une autorité, un partenariat, une association ou une institution, qu'elle soit constituée en personne morale ou non, publique ou privée.^[3] Autrement dit, un consultant seul est une organisation au sens de la norme, tout comme un groupe coté.

La norme prévoit aussi le cas où le système de management ne couvre qu'une partie d'une structure plus grande. Le terme organisation désigne alors uniquement la partie incluse dans le périmètre.^[3] Une division, une filiale ou un service peut donc adopter la démarche sans engager tout le groupe. La norme reconnaît d'ailleurs que les petites structures n'ont pas forcément un organe de gouvernance distinct de leur direction, ce qui confirme qu'elle est pensée pour s'adapter à l'échelle de chacun.^[3]

Le critère décisif : votre rôle vis-à-vis de l'IA

Savoir que la norme vous concerne ne dit pas encore comment elle vous concerne. C'est là qu'intervient la notion de rôle, posée par la clause 4.1. La norme demande à l'organisation de considérer la finalité des systèmes d'IA qu'elle développe, fournit ou utilise, puis de déterminer ses rôles à leur égard.^[2]

La norme propose une liste de six familles de rôles, présentée comme indicative et non limitative. Une même organisation peut en endosser plusieurs à la fois.^[2]

La clause 4.1 invite l'organisation à se situer dans une ou plusieurs de ces familles. Le rôle oriente ensuite ce que la norme attend d'elle.

1Fournisseurs d'IA (plateformes, produits, services)

2Producteurs d'IA (développeurs, opérateurs, déployeurs, experts)

3Clients d'IA (dont utilisateurs)

4Partenaires (intégrateurs, fournisseurs de données)

5Sujets de l'IA (personnes concernées)

6Autorités (décideurs publics, régulateurs)

Liste indicative reformulée à partir de la clause 4.1, NOTE 1. Le texte de la norme n'est pas reproduit.

La famille des producteurs est la plus détaillée. Elle réunit les développeurs, les concepteurs, les opérateurs, les testeurs et évaluateurs, les déployeurs, les professionnels des facteurs humains, les experts métier, les évaluateurs d'impact, les acheteurs, ainsi que les professionnels de la gouvernance et de la supervision de l'IA.^[2] Cette granularité montre que la norme ne vise pas que les éditeurs de logiciels : elle inclut tous les métiers qui interviennent autour d'un système d'IA, y compris ceux qui l'achètent ou le supervisent.

La norme relie ces rôles au cycle de vie du système d'IA. Elle renvoie à l'ISO/IEC 22989 pour une description détaillée des rôles, et au cadre de gestion des risques de l'IA du NIST pour leur relation avec ce cycle de vie.^[2] L'intérêt est concret : se situer dans une famille de rôles revient à reconnaître les étapes du cycle de vie que vous maîtrisez réellement, de la conception à l'usage, et donc les exigences que vous êtes en mesure de porter. Celui qui ne fait qu'utiliser un outil ne répond pas de la façon dont il a été entraîné.

Le rôle commande l'étendue des exigences

Déterminer son rôle n'est pas un exercice théorique. La norme indique explicitement que les rôles de l'organisation peuvent déterminer l'applicabilité et l'étendue d'applicabilité de ses exigences et de ses contrôles.^[2] Un fournisseur qui conçoit un modèle et une entreprise qui se contente d'utiliser un outil sur étagère ne portent pas les mêmes obligations, parce qu'ils ne maîtrisent pas les mêmes parties du cycle de vie du système.

La norme ajoute que la détermination des rôles peut être formée par les obligations liées aux catégories de données traitées, par exemple lorsqu'une organisation agit comme responsable ou comme sous-traitant de données personnelles.^[2] Le rôle au sens de l'ISO 42001 et le rôle au sens du droit de la protection des données se recoupent donc, sans se confondre. Une lecture raisonnable est qu'une même organisation cumule souvent plusieurs rôles, et qu'il faut tous les recenser pour cadrer correctement sa démarche.

Cette logique d'approche par les risques est cohérente avec l'esprit de la norme : le niveau de contrôle s'ajuste aux usages réels de l'IA, plutôt que de s'appliquer de façon uniforme.^[4] La norme gère les risques et les opportunités à l'échelle de l'organisation, sans entrer dans le détail de chaque application, ce qui lui permet d'apporter de la valeur à toute entité.^[4]

Les enjeux internes et externes qui précisent votre cas

Déterminer son rôle ne suffit pas à cadrer la démarche. La même clause 4.1 demande à l'organisation de déterminer les enjeux internes et externes pertinents pour sa finalité, ceux qui peuvent affecter sa capacité à atteindre les résultats attendus de son système de management de l'IA.^[2] Elle ajoute, comme les normes de management récentes, de considérer si le changement climatique constitue un enjeu pertinent.^[2]

La norme illustre ce que recouvrent ces enjeux. Côté externe, elle cite les exigences légales applicables, y compris les usages interdits de l'IA, les orientations et décisions des régulateurs, les incitations ou les conséquences liées à la finalité de l'IA, la culture et les valeurs entourant son usage, ainsi que le paysage concurrentiel des produits et services fondés sur l'IA.^[2]

Côté interne, elle mentionne la gouvernance et les objectifs de l'organisation, ses politiques et procédures, ses obligations contractuelles, et la finalité même du système d'IA développé ou utilisé.^[2] Ces facteurs expliquent pourquoi deux organisations au même rôle peuvent mener des démarches différentes. Un usage de l'IA soumis à de fortes exigences légales, ou engageant des obligations contractuelles précises, appelle un cadrage plus serré qu'un usage interne sans enjeu réglementaire particulier.

Parties intéressées et périmètre : où la norme s'applique chez vous

Une fois le rôle clarifié, la norme demande de cadrer deux choses avant d'aller plus loin. D'abord les parties intéressées : l'organisation détermine celles qui sont pertinentes pour son système de management de l'IA, leurs exigences, et lesquelles de ces exigences seront prises en charge par le système.^[2] Clients, employés, autorités, personnes concernées par les décisions de l'IA : chacun peut porter des attentes qui pèsent sur la démarche.

Ensuite le périmètre. L'organisation détermine les frontières et l'applicabilité du système de management pour en fixer le champ, en tenant compte des enjeux internes et externes et des exigences des parties intéressées.^[2] Ce périmètre est tenu à disposition sous forme d'information documentée.^[2] Concrètement, vous choisissez quels usages d'IA, quels services et quelles équipes entrent dans la démarche, et vous l'écrivez. C'est ce document qui transforme une norme applicable à presque tout le monde en un projet délimité et réaliste pour votre organisation.

Comment déterminer concrètement votre rôle et votre périmètre

La norme ne fournit pas de formulaire, mais l'enchaînement de la clause 4 dessine une marche à suivre. Quatre questions, dans l'ordre, suffisent à savoir ce qui vous concerne réellement.^[2]

• Quels sont vos usages réels de l'IA, et quelle est la finalité de chacun ?^[2]
• Pour chaque usage, quel rôle jouez-vous, fournisseur, producteur, client ou partenaire, et avec quelle responsabilité sur les données ?^[2]
• Quelles parties intéressées comptent pour ces usages, et quelles attentes portent-elles ?^[2]
• Quels enjeux internes et externes pèsent sur ces usages, à commencer par les exigences légales applicables ?^[2]

Les réponses se consolident dans un seul document, le périmètre du système de management, qui fixe ses frontières et reste disponible comme information documentée.^[2] C'est l'exercice qui transforme une norme applicable à presque toutes les organisations en un projet borné, proportionné à vos usages. Tant que ce périmètre n'est pas écrit, la question de savoir à qui s'applique la norme reste théorique. Une fois écrit, elle devient une question bien plus utile : à quoi, chez vous, la norme s'applique.

Un cas concret : une PME romande qui utilise un outil d'IA

Prenons, à titre d'illustration, une fiduciaire de vingt personnes qui utilise un outil d'IA pour pré-trier les pièces comptables de ses clients. Elle ne développe rien : elle achète un service. Au sens de la norme, elle entre malgré tout dans le champ d'application, parce qu'elle utilise un produit recourant à l'IA.^[1]

Son rôle principal est celui de cliente et d'utilisatrice d'IA, avec une dimension de partenaire si elle fournit des données à l'éditeur.^[2] Elle agit aussi comme sous-traitante de données personnelles pour le compte de ses clients, ce qui colore ses obligations.^[2] Comme elle ne conçoit pas le modèle, les exigences qui portent sur la construction du système ne la concernent pas au premier chef. En revanche, celles qui portent sur l'usage responsable, le choix du fournisseur, la surveillance des résultats et le périmètre la concernent directement.

Son périmètre raisonnable n'est pas toute l'entreprise, mais l'usage précis de cet outil de pré-tri.^[2] En le documentant, elle obtient une démarche tenable, sans mobiliser des exigences pensées pour les éditeurs de modèles. C'est exactement ce que permet l'articulation entre le rôle et le périmètre.

Questions fréquentes

À lire ensuite