A.3 — Organisation interne
Deux contrôles seulement, et le second est presque toujours oublié : un dispositif par lequel chacun peut faire part d'une préoccupation sur la façon dont l'organisation conçoit, fournit ou utilise ses systèmes d'IA.
Le domaine A.3 compte deux contrôles : A.3.2 sur les rôles et responsabilités relatifs à l’IA, A.3.3 sur le signalement des préoccupations.
C’est le plus petit domaine de l’Annexe A, et celui dont le second contrôle passe le plus souvent à la trappe.
A.3.2 — Les rôles, sans confondre avec la clause 5.3
La clause 5.3 demande deux choses à la direction. D’abord, que les rôles utiles au système de management aient une responsabilité et une autorité attribuées, et que l’organisation en soit informée. Ensuite, qu’elle attribue la responsabilité et l’autorité de veiller à ce que le système de management de l’IA reste conforme à la norme, et de lui rendre compte de sa performance. Rien n’impose d’inscrire un nom : ce qui compte est que cette responsabilité soit réellement portée, par une personne ou par une fonction identifiée. Le contrôle A.3.2 ne reprend donc pas à son compte l’attribution générale des rôles, déjà exigée par la clause : il porte sur les rôles liés à l’IA, à définir et à répartir selon les besoins de l’organisation. L’Annexe B cite à ce titre, en exemples, des domaines aussi variés que la supervision humaine, les relations avec les fournisseurs, la qualité des données ou les évaluations d’impact (B.3.2). C’est un contrôle de l’Annexe A : votre déclaration d’applicabilité peut l’écarter en le justifiant, ce qui laisse la clause 5.3 entière.
La nuance compte, parce qu’elle détermine ce qu’on doit produire. Une matrice de responsabilités détaillée est une pratique répandue et souvent utile ; elle n’est pas une exigence textuelle, ni de la clause 5.3, ni du contrôle A.3.2. Présenter le contraire conduit des organisations à produire des documents dont personne n’a besoin.
Ce que l’auditeur vérifie est plus simple que la documentation qu’on lui prépare : il demande aux personnes concernées ce qu’elles peuvent décider. Un nom inscrit dans un organigramme que l’intéressé n’a jamais lu est un écart ; une attribution informelle mais connue et assumée n’en est pas nécessairement un.
A.3.3 — Le canal de signalement
C’est le contrôle qu’on oublie, et c’est dommage, parce qu’il est de ceux qui demandent le moins de moyens.
Il demande un processus défini et réellement en place, par lequel on peut faire part d’une préoccupation sur la façon dont l’organisation conçoit, fournit ou utilise un système d’IA, à n’importe quel moment de la vie de ce système : une sortie discriminatoire laissée sans suite, un usage détourné de ce qui avait été validé, une évaluation escamotée avant une mise en service.
Rien n’impose un outil, et un dispositif de signalement existant peut servir. Les recommandations de mise en œuvre précisent en revanche ce qu’on attend de ce processus : un canal connu des salariés comme des intervenants sous contrat, tenu par des personnes compétentes qui peuvent enquêter et trancher, une remontée à la direction en temps utile, une réponse dans un délai raisonnable, la possibilité de signaler de façon confidentielle ou anonyme, et une protection contre les représailles. Ce sont des recommandations, que vous pouvez adapter à votre contexte (B.1) ; une adresse électronique relevée n’y suffit pas à elle seule.
Son intérêt est pratique autant que normatif. Dans la plupart des organisations, les premiers à voir qu’un système d’IA sert à autre chose que ce qui était prévu, ou que ses résultats posent un problème à ceux qui les subissent, ne sont ni l’équipe technique ni la conformité : ce sont les personnes qui travaillent avec lui tous les jours. Sans dispositif, leur inquiétude ne remonte pas.
Trois niveaux de mise en œuvre
Minimal crédible. Un pilote identifié — souvent le responsable informatique ou qualité — nommé dans l’organigramme et dans la politique. Un canal de signalement connu, relevé, avec une trace des entrées et de leur traitement, et trois points écrits : qui l’instruit, jusqu’où cette personne peut aller, et dans quel délai on répond. Une voie confidentielle, même rudimentaire, pour qui ne veut pas s’adresser à sa hiérarchie.
Mature. Une structure de gouvernance : une instance qui se réunit périodiquement pour valider les nouveaux usages et arbitrer les incidents, des responsabilités attribuées par processus, et un canal de signalement outillé dont les entrées alimentent le registre des risques et la revue de direction.
À éviter. La superposition d’instances — comité éthique, comité juridique, comité sécurité — produisant des avis qui se contredisent, et un circuit d’approbation où chaque usage d’IA traverse une dizaine de validations. L’effet est mécanique : les équipes contournent, et les usages deviennent invisibles. On a alors dégradé la maîtrise en croyant l’augmenter.
Ce que le domaine ne demande pas
Ni poste dédié, ni comité, ni matrice de responsabilités, ni outil de ticketing. Une même personne peut porter plusieurs rôles, et dans une petite structure c’est le cas normal.
Il ne demande pas non plus un dispositif d’alerte anonyme : le signalement doit être possible et traité. La confidentialité de son auteur, en revanche, n’est pas laissée à vos seules règles. Les recommandations de mise en œuvre prévoient de proposer la confidentialité, l’anonymat, ou les deux ; de protéger contre les représailles ceux qui signalent comme ceux qui instruisent ; et de préserver cette confidentialité dans les comptes rendus. Vous pouvez les adapter à votre contexte (B.1) ; un canal qui n’offre aucune garantie de ce genre ne recueillera que les signalements qui ne dérangent personne.