Clause 4 : contexte de l'organisation et périmètre de l'AIMS
La clause 4 décide de ce que couvre votre système de management, et de ce qu'il laisse dehors. C'est la seule clause dont une erreur se paie sur les six suivantes.
La clause 4 répond à une question simple : sur quoi porte votre système de management de l’IA ? Elle se décompose en quatre sous-clauses — comprendre le contexte et son propre rôle, identifier les parties intéressées, délimiter le périmètre, puis établir le système lui-même.
C’est la clause la plus structurante et la plus sous-estimée. Un périmètre trop large rend l’audit interminable ; trop étroit, il laisse dehors un usage d’IA que l’auditeur trouvera quand même. Et le rôle que vous vous reconnaissez en 4.1 pèse sur tout le reste : une note de la norme, informative, indique qu’il peut décider si des exigences et des contrôles vous concernent, et jusqu’où.
4.1 — Comprendre le contexte, et déterminer son rôle
La détermination du rôle est la partie que l’on oublie, et c’est la plus lourde de conséquences. Une note de 4.1, informative et non limitative, cite en exemple six catégories de rôles, chacune illustrée de rôles plus précis : les autorités compétentes (décideurs publics, régulateurs) ; les clients, dont les utilisateurs ; les fournisseurs, de plateforme ou de produit et de service ; les partenaires, comme les intégrateurs et les fournisseurs de données ; les producteurs, parmi lesquels déployeurs, concepteurs, évaluateurs d’impact, développeurs, testeurs ou exploitants ; les sujets de l’IA, dont les personnes concernées par les données. C’est ISO/IEC 22989 qui décrit ces rôles en détail. Une même organisation en cumule souvent deux ou trois sans l’avoir formalisé.
Cette grille ne se confond pas avec celle de l’AI Act, qui raisonne en fournisseur, déployeur, importateur, distributeur, mandataire et fabricant de produit. Les deux grilles coexistent et ne se recouvrent pas : vous pouvez être déployeur au sens du règlement et relever des producteurs dans la grille que cite la norme.
Pour le contexte, la norme n’impose pas de grille. Une note de 4.1, informative et ouverte, suggère des pistes qui varient selon vos rôles et vos juridictions. En interne : l’organisation et sa gouvernance, ses objectifs, politiques et procédures, ses engagements contractuels, la finalité des systèmes d’IA. À l’extérieur : la concurrence et l’évolution des offres fondées sur l’IA ; la culture, les valeurs et l’éthique ; ce que l’usage des systèmes peut faire gagner ou coûter ; le droit applicable, usages prohibés compris, et la façon dont les régulateurs l’interprètent ou le font appliquer. Rien n’oblige à consigner cette analyse, même si l’écrit reste le moyen le plus simple d’en montrer l’existence. Le changement climatique, en revanche, fait l’objet d’une exigence propre, présente dès l’édition 2023 : 4.1 vous fait déterminer s’il constitue pour vous un enjeu pertinent — et, pour des charges d’entraînement, la réponse n’est pas une clause de style.
4.2 — Les parties intéressées et leurs exigences
La liste dépasse toujours les clients et les régulateurs. Elle inclut les personnes soumises aux décisions du système — celles dont un dossier est trié, un profil noté, une candidature filtrée — qui n’ont aucun lien contractuel avec vous et sont pourtant les premières concernées. Elle inclut aussi vos propres salariés, vos fournisseurs de données, et l’autorité de contrôle de votre secteur.
Le point qui se joue en audit n’est pas la liste : c’est la décision. Pour chaque exigence pertinente, il faut pouvoir dire si elle entre dans le système ou non. 4.2 n’impose ni de justifier ce choix, ni de le mettre par écrit : dans toute la norme, seule la déclaration d’applicabilité réclame une justification, pour retenir ou écarter des contrôles, au titre de 6.1.3 f). Noter en une ligne pourquoi une exigence reste dehors est pourtant une bonne pratique : le choix se défend mieux devant l’auditeur et se révise plus facilement. Mais aucun motif ne fait disparaître une obligation applicable, légale notamment : la politique IA engage l’organisme à satisfaire les exigences qui s’imposent à lui (5.2, point c).
4.3 — Le périmètre, et il doit être écrit
La norme ne prescrit pas de découpage. En pratique, on délimite souvent le périmètre sur trois axes : organisationnel (quelles entités, quelles équipes), géographique lorsque plusieurs sites relèvent de règles différentes, et fonctionnel (quels systèmes d’IA, à quel stade de leur cycle de vie).
C’est un arbitrage économique autant que normatif. Chaque système d’IA inclus dans le périmètre réclame son évaluation d’impact et sa place dans l’appréciation des risques. La charge de mise en œuvre ne tient pas à un seul facteur : l’introduction de la norme cite elle-même la taille et la structure de l’organisme, ses processus, les attentes des parties intéressées et la diversité de ses usages de l’IA. Parmi ces facteurs, le nombre et la criticité des systèmes retenus sont ceux que la décision de périmètre permet d’ajuster le plus directement.
4.4 — Établir le système lui-même
Cette sous-clause est brève et engage tout le reste : le « système » dont elle parle recouvre l’ensemble des exigences de la norme — celles de la clause 4 elle-même, des clauses 5 à 10, et les contrôles jugés nécessaires au titre de 6.1.3. Son ampleur, en revanche, dépend de vous : une note de 7.5.1, informative, admet que l’étendue de la documentation varie avec la compétence des personnes, la complexité des processus ou la taille de l’organisme. La liste des pièces exigées, elle, ne se réduit pas. Une PME peut les tenir sobrement ; parmi celles que la norme impose à tous : un périmètre écrit, la description du système de management, une politique courte, des objectifs IA documentés, l’appréciation et le traitement des risques avec la déclaration d’applicabilité, les résultats des évaluations d’impact, les preuves de compétence, les résultats de surveillance, le programme et les résultats d’audit interne, ceux des revues de direction, menées aux intervalles que vous planifiez (9.3.1), et la trace des non-conformités traitées. Un inventaire des systèmes ou une revue semestrielle restent des choix pratiques. Un grand groupe ne s’en sortira pas sans comités ni processus formalisés.
Le critère n’est pas l’épaisseur de la documentation, c’est la correspondance entre ce qu’elle décrit et ce que font réellement les équipes. Une documentation qui décrit l’intention plutôt que la pratique est ce qui fait échouer les audits de certification au second stade.
Ce que la clause 4 ne demande pas
Elle n’impose ni format, ni modèle de document, ni outil. Elle n’exige pas un « manuel » au sens des anciennes normes de management : elle demande en revanche que le périmètre et le système de management lui-même soient documentés, sous la forme de votre choix. Elle ne fixe aucun seuil de taille de périmètre, ni aucune durée de validité de l’analyse de contexte.
L’inventaire des systèmes d’IA, souvent présenté comme obligatoire, ne figure pas en tant que tel parmi les exigences : il est la façon la plus simple de rendre démontrable le périmètre de 4.3, ce qui n’est pas la même chose qu’une obligation textuelle.