A.3 — Organisation interne et signalement
Deux contrôles seulement, et le second est presque toujours oublié : un canal par lequel quelqu'un peut signaler qu'un système d'IA se comporte mal.
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 exige l’attribution de deux responsabilités précises : tenir le système conforme, et en rendre compte à la direction. Le contrôle A.3.2 va plus loin : il porte sur l’attribution des rôles relatifs à l’IA selon les besoins de l’organisation.
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 nommé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, si elle est consignée.
A.3.3 — Le canal de signalement
C’est le contrôle qu’on oublie, et c’est dommage, parce qu’il est le moins coûteux à satisfaire.
Il demande qu’une personne constatant un problème sur un système d’IA — une réponse fausse, une sortie discriminatoire, un usage qui dérape — puisse le signaler et que ce signalement aille quelque part. Rien n’impose un outil : une adresse électronique connue, relevée, et dont les entrées sont tracées suffit.
Son intérêt est pratique autant que normatif. Dans la plupart des organisations, les premiers à constater qu’un système d’IA se comporte mal ne sont ni l’équipe technique ni la conformité : ce sont les personnes qui l’utilisent tous les jours. Sans canal, leur constat 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. Une adresse ou un canal connu pour les signalements, relevé, avec une trace des entrées et de leur traitement.
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 relève de vos propres règles.