A.8 — Information des parties intéressées
Quatre contrôles sur ce que vous dites à ceux qui utilisent ou subissent vos systèmes. C'est aussi le domaine où l'on vient chercher, à tort, deux sujets qui n'y sont pas.
Le domaine A.8 compte quatre contrôles : A.8.2 sur la documentation du système et l’information des utilisateurs, A.8.3 sur le signalement externe, A.8.4 sur la communication des incidents, A.8.5 sur l’information des parties intéressées.
Commençons par ce qu’il ne contient pas, car c’est là qu’on le cherche à tort. Les évaluations d’impact relèvent du domaine A.5, pas d’A.8. Les fournisseurs relèvent d’A.10.2 et A.10.3, pas d’A.8. Ces deux erreurs sont parmi les plus répandues de la littérature secondaire, et elles font préparer les mauvaises preuves.
Ce que l’auditeur regarde
Une question centrale : une personne qui utilise votre système sait-elle ce qu’il fait et ce qu’il ne sait pas faire ?
Ce n’est pas de la communication institutionnelle. C’est de l’information utile : à quoi sert le système, dans quelles limites, avec quel degré de fiabilité, et que faire quand le résultat paraît faux.
A.8.3, le signalement externe, est le pendant tourné vers l’extérieur du contrôle interne A.3.3. Il demande qu’une personne qui n’appartient pas à l’organisation — un client, une personne affectée par une décision, un chercheur — puisse signaler un problème. Une adresse connue et relevée suffit.
A.8.4 porte sur la communication des incidents : retenu dans la déclaration d’applicabilité, il demande un plan écrit, qui prévoit comment les utilisateurs du système en sont informés. La suite est souvent mal citée. Aucune clause n’est consacrée au traitement des incidents, et la clause 10 s’arrête à 10.2 : il n’existe ni 10.3 ni 10.4. Pour la réponse elle-même — réparer, assurer le support, recueillir les remontées —, la norme donne ses repères à propos de l’exploitation des systèmes, avec le contrôle A.6.2.6 et les recommandations de l’Annexe B. Quant à la clause 10.2, un incident n’y entre que s’il révèle une exigence non satisfaite : il se traite alors comme toute non-conformité.
Trois niveaux de mise en œuvre
Minimal crédible. Pour chaque système, une notice destinée à ceux qui s’en servent, en interne comme à l’extérieur : à quoi il sert, ce qu’il ne sait pas faire, que faire devant un résultat douteux. Pour les utilisateurs externes, la mention qu’un système d’IA intervient complète cette notice au lieu de la remplacer. Une adresse de signalement publiée et relevée. Un plan écrit, même court, qui fixe quels incidents sont portés à la connaissance des utilisateurs, qui en décide et par quel canal (A.8.4). Et, système par système, la liste tenue à jour des obligations d’information qui vous incombent, avec leur origine : contrat, loi, autorité (A.8.5). Le tout vaut pour les contrôles que retient votre déclaration d’applicabilité.
Mature. Une documentation tenue : liste des systèmes en service, usages autorisés et interdits — cohérents avec le domaine A.9 —, aperçu du fonctionnement pour qui doit l’intégrer, questions fréquentes pour les utilisateurs. Un circuit d’incident défini, avec des destinataires nommés et des délais, et la trace des communications effectuées.
À éviter. Publier par principe toute la documentation interne, y compris ce qui relève du secret industriel, au nom de la transparence. Ou produire des communications si techniques qu’elles noient l’information utile. La norme ne demande pas de tout divulguer : elle demande d’informer utilement, ce qui est presque l’inverse.
Ce que le domaine ne demande pas
Aucune publication du code, aucune divulgation publique de l’architecture, aucun rapport public. Le domaine ne crée pas non plus d’obligation de transparence algorithmique : celles qui existent viennent de la loi, des contrats ou des autorités. Il demande en revanche de les recenser et de les consigner (A.8.5), et l’Annexe B recommande de veiller à ce que l’information attendue parvienne aux bonnes autorités. La documentation technique destinée à certaines catégories de parties intéressées, elle, relève d’A.6.2.7.
Il n’exige pas non plus un portail dédié : une page dans une documentation existante peut porter l’information des utilisateurs, et une adresse relevée le signalement externe. Cela couvre A.8.2 et A.8.3, pas les deux autres contrôles : A.8.4 demande en plus un plan écrit de communication des incidents aux utilisateurs, et A.8.5 le relevé écrit de vos obligations d’information.