A.9 — Utilisation des systèmes d'IA

Le domaine A.9 compte trois contrôles : A.9.2 sur les processus d’usage responsable, A.9.3 sur les objectifs d’usage responsable, A.9.4 sur l’usage conforme aux usages prévus et à la documentation du système.

Il traite d’un sujet qu’on aborde rarement de front : l’écart entre ce pour quoi un système a été mis en service et ce qu’on en fait six mois plus tard.

L’usage prévu, notion centrale

C’est la notion propre au troisième contrôle. A.9.4 demande que le système serve à ce pour quoi il est destiné, et suive la documentation qui l’accompagne — ce qui suppose que cet usage ait été écrit quelque part, et qu’il soit connu de ceux qui s’en servent. Les deux autres contrôles posent le cadre commun. A.9.2 fait définir et documenter les processus d’usage responsable, c’est-à-dire ce qui encadre la décision de recourir à un système, développé en interne ou obtenu d’un tiers : l’Annexe B cite par exemple les approbations nécessaires, le coût, les exigences d’approvisionnement et les obligations légales. A.9.3 fait identifier et documenter les objectifs qui guident cet usage — l’Annexe B mentionne l’équité, la transparence ou la fiabilité, et y rattache la supervision humaine.

C’est une notion qu’on retrouve ailleurs dans la norme : l’organisme tient compte de la finalité prévue de ses systèmes dès l’analyse de son contexte (4.1), et l’évaluation d’impact examine le déploiement, l’usage prévu et le mésusage prévisible (6.1.4). La réglementation, elle, va plus loin : la qualification d’un système et les obligations qui s’y attachent y dépendent de l’usage pour lequel il est mis sur le marché ou mis en service, et un système requalifié par son usage réel peut changer de régime.

La dérive d’usage

Elle est plus fréquente que la dérive du modèle, et beaucoup moins surveillée. Le scénario est toujours le même : un outil déployé pour une tâche fonctionne bien, quelqu’un l’essaie sur une tâche voisine, ça marche à peu près, et l’usage s’installe.

Le problème n’est pas l’initiative — c’est même souvent une bonne idée. Le problème est que le nouvel usage n’a fait l’objet d’aucune évaluation d’impact, d’aucune appréciation du risque, et que personne ne sait qu’il existe.

Trois niveaux de mise en œuvre

Minimal crédible. Une règle écrite, même courte, qui dit comment l’organisation décide d’utiliser un système d’IA : qui autorise, sur quels critères, quelles obligations légales vérifier (A.9.2). Quelques objectifs d’usage responsable écrits et adaptés au contexte — la transparence envers les personnes concernées, la supervision humaine des décisions (A.9.3). Pour chaque système : une mention explicite de l’usage prévu et de ce qui est exclu, dans le mode d’emploi ; une session d’information courte pour les utilisateurs directs ; un point périodique — même annuel — où l’on demande aux équipes ce qu’elles en font réellement (A.9.4).

Mature. Des conditions d’usage formalisées : qui peut utiliser le système, sur quels types de données, pour quelles décisions. Des ateliers de sensibilisation pour les utilisateurs clés. Et un suivi des usages effectifs, qui permet de constater une dérive plutôt que de l’apprendre par un incident.

À éviter. Exiger le passage devant une instance pour chaque nouvelle requête, ou sanctionner tout usage inhabituel avant de l’avoir examiné. L’effet est l’inverse du but : les usages nouveaux ne disparaissent pas, ils deviennent invisibles. Interdire jusqu’à l’essai exploratoire est le meilleur moyen de ne plus rien savoir de ce qui se passe.

Ce que le domaine ne demande pas

Aucune surveillance nominative des utilisateurs, aucun outil de contrôle d’usage, aucune interdiction de l’expérimentation. Il ne demande pas non plus de figer les usages. Il demande que le système serve à ce pour quoi il a été prévu, et selon la documentation qui l’accompagne (A.9.4). Un usage qui s’en écarte s’examine — l’Annexe B invite à peser la pertinence des usages non anticipés — puis il cesse, ou il devient un usage prévu, documenté et évalué.