Cadrer le périmètre : inventorier ses systèmes d'IA, écouter les parties intéressées, trancher
Le périmètre se décide en premier et se paie ensuite sur tout le reste : chaque système d'IA qui y entre relève du processus d'évaluation d'impact, dont vous fixez vous-même les cas de déclenchement. Il se construit en trois temps — voir, écouter, trancher — et dans cet ordre.
Ce guide suit l’ordre qui évite les allers-retours : voir ce qui existe, écouter ceux qui ont des attentes, puis trancher ce qui entre dans le périmètre. La page de la clause 4 détaille ce que la norme exige ; celle-ci décrit comment s’y prendre.
1. Voir : inventorier les systèmes d’IA
La norme n’exige pas un inventaire en tant que tel. Elle exige un périmètre documenté (4.3), et l’inventaire est la seule manière connue de le rendre démontrable : un périmètre ne dit rien des systèmes dont on ignore l’existence.
Où les chercher
Les systèmes déclarés sont la partie facile. Les autres se trouvent en croisant plusieurs sources.
- Les projets et les produits : ce que les équipes développent, intègrent ou paramètrent.
- Les contrats et les achats : abonnements à des services d’IA, accès à des modèles par API, options d’IA souscrites dans un logiciel existant.
- Les notes de frais et les cartes de paiement : les abonnements individuels passent souvent par là.
- Les fonctions ajoutées aux outils en place : suite bureautique, gestion de la relation client, outil de support, qui activent des fonctions d’IA sans nouveau contrat.
- Les extensions de navigateur et les applications installées.
- Les flux sortants vers des fournisseurs de modèles, que la DSI ou la sécurité peuvent repérer.
- Les équipes elles-mêmes, par un questionnaire court qui demande ce qu’elles utilisent — pas ce qu’elles ont le droit d’utiliser.
Ce qu’il faut noter pour chaque système
| Information | Pourquoi elle compte |
|---|---|
| Nom et description de l’usage | Savoir de quoi on parle, et repérer plus tard les usages qui dérivent |
| Usage prévu, et ce que le système ne doit pas faire | C’est la référence de toute évaluation ultérieure |
| Développé, intégré, paramétré ou acheté | Détermine le rôle de l’organisation (4.1) et les contrôles applicables |
| Fournisseur et type de service | Alimente la gestion des fournisseurs, au titre d’A.10.3 |
| Données traitées, dont les données personnelles | Oriente l’évaluation d’impact, et l’articulation avec le RGPD |
| Personnes concernées par les sorties ou les décisions | Ce sont elles que l’évaluation d’impact devra considérer (6.1.4) |
| Propriétaire métier | Chaque système doit avoir quelqu’un qui en répond |
| Stade : idée, test, production, retrait | Un système en test peut déjà traiter des données réelles |
| Criticité provisoire | Priorise le travail avant l’appréciation des risques |
| Qualification au sens de l’AI Act, le cas échéant | Le même inventaire sert à qualifier ses rôles et à classer les systèmes |
Qu’est-ce qui compte comme un système d’IA ?
La question arrive vite : une règle métier codée à la main, un tableur avec une régression, un correcteur orthographique ? La norme s’appuie sur le vocabulaire d’ISO/IEC 22989 ; l’AI Act a sa propre définition, précisée par des lignes directrices de la Commission publiées en février 2025. Le glossaire résume ce qui les rapproche.
Une règle pratique suffit au stade de l’inventaire : dans le doute, inscrivez-le, avec la mention « qualification à confirmer ». Un système inventorié à tort se retire en une ligne ; un système oublié se découvre en audit.
2. Écouter : les parties intéressées et leurs exigences
Le périmètre ne se décide pas seulement à partir de ce qui existe. Il se décide aussi à partir de ce que d’autres attendent : un client qui demande des garanties, une autorité qui impose des règles, des personnes qui subissent les décisions d’un système. C’est l’objet de la clause 4.2.
| Partie intéressée | Ce qu’elle attend typiquement | D’où vient l’exigence |
|---|---|---|
| Direction, actionnaires | Que l’IA serve la stratégie sans exposer l’organisation | Décision interne |
| Salariés et leurs représentants | Savoir quels outils sont autorisés, et ce qui est fait de leurs données | Règles internes, droit du travail, dialogue social |
| Clients | Des garanties sur l’usage de l’IA, souvent par questionnaire | Contrat, consultation |
| Utilisateurs des systèmes | Comprendre ce que fait le système et ses limites | Attente, parfois obligation de transparence |
| Personnes soumises aux décisions | Ne pas être traitées injustement, pouvoir contester | Protection des données, non-discrimination, attente sociétale |
| Fournisseurs de modèles, de données, prestataires | Le respect de leurs conditions et restrictions d’usage | Contrats, licences |
| Autorités | Le respect des règles : protection des données, régulation sectorielle, AI Act | Loi, règlement |
| Assureurs, investisseurs | La maîtrise des risques | Contrat, questionnaire |
Dans les entreprises dotées d’un comité social et économique, l’introduction de nouvelles technologies relève de sa consultation : c’est une exigence que l’inventaire fait souvent apparaître pour la première fois.
Ce que la norme demande n’est pas une cartographie exhaustive. La clause 4.2 demande d’identifier les parties intéressées qui comptent pour le système de management et leurs exigences pertinentes, puis de décider lesquelles de ces exigences le système prendra en charge. Elle n’impose pour cela ni registre, ni motif écrit pour celles qu’il laisse de côté.
En pratique, un registre simple fait l’affaire. Y noter où chaque exigence retenue se traduit, et pourquoi une autre est écartée, n’est donc pas exigé : c’est ce qui rend la décision relisible, nourrit la revue de direction et répond d’avance aux questions de l’auditeur.
| Partie | Exigence | Source | Prise en charge | Où elle se traduit | Motif si écartée |
|---|---|---|---|---|---|
| Client grand compte | Être informé des fonctions d’IA du service livré | Clause contractuelle | Oui | Attentes des clients (A.10.4), information des utilisateurs (A.8.2), communication (7.4) | — |
| Candidats à l’embauche | Ne pas être écartés par un tri automatisé injuste | Droit de la non-discrimination | Oui | Périmètre, évaluation d’impact (6.1.4), supervision humaine | — |
| Équipe marketing | Utiliser librement un générateur d’images | Attente interne | Non, en l’état | — | Usage soumis à la charte, réexaminé à la prochaine revue |
3. Trancher : ce qui entre, ce qui sort
Avec l’inventaire et les exigences en main, le périmètre se décide. Quatre critères aident à le faire de façon défendable.
- L’effet sur des personnes. Un système dont les sorties touchent des personnes, à l’intérieur comme à l’extérieur de l’organisation, ou orientent des décisions à leur sujet, a sa place dans le périmètre.
- Les exigences identifiées. Si un client, une autorité ou un contrat attend des garanties sur un système, l’exclure crée un écart entre ce qu’on promet et ce qu’on gouverne.
- La cohérence organisationnelle. Un périmètre découpé système par système au sein d’une même équipe, avec les mêmes processus, se défend mal : on inclut une activité, pas une liste de cas faciles.
- La capacité à tenir. Un périmètre qu’on n’a pas les moyens de faire vivre produit un certificat fragile. Mieux vaut un périmètre plus étroit, justifié, élargi au cycle suivant.
Ce qui distingue une exclusion recevable d’une exclusion qui ne tient pas, c’est son motif.
| Une exclusion qui tient | Une exclusion qui ne tient pas |
|---|---|
| Les outils d’aide à la rédaction interne, sans décision affectant des tiers, sortent du premier cycle ; ils restent encadrés par la charte d’usage, et la question revient à la prochaine revue de direction | L’assistant du service client est exclu parce qu’il est fourni par un tiers |
| La filiale qui n’utilise aucun système d’IA à ce jour est hors périmètre | Les systèmes en test sont exclus parce qu’ils ne sont pas en production, alors qu’ils traitent déjà des données réelles |
| La maintenance prédictive, sans effet sur des personnes ni exigence externe, entre au deuxième cycle | Le tri de candidatures est exclu parce que son évaluation d’impact serait trop longue |
Écrire la déclaration de périmètre
La déclaration tient en une ou deux pages. Elle mentionne :
- les entités et les sites couverts ;
- les activités, et le ou les rôles que l’organisation y tient ;
- les systèmes d’IA couverts, par renvoi à une version datée de l’inventaire ;
- les stades du cycle de vie concernés ;
- les exclusions, chacune avec son motif ;
- l’articulation avec d’autres systèmes de management, lorsque le système est intégré ;
- sa date, son approbation par la direction, et la prochaine échéance de revue.
La clause 4.3 n’impose pas de motiver chaque exclusion. L’écrire reste le moyen le plus sûr de montrer que le périmètre tient compte des enjeux (4.1) et des exigences des parties intéressées (4.2), comme la clause le demande.
C’est ce périmètre, en substance, que l’organisme de certification fera figurer sur le certificat.
Tenir le périmètre à jour
Un inventaire exact le jour de l’audit et faux trois mois plus tard ne prouve rien. Trois mécanismes le font vivre.
- Un point d’entrée unique. Tout nouvel usage d’IA — un achat, un projet, une fonction activée dans un outil existant — passe par l’inventaire avant d’être mis en service. Les achats et la DSI en sont les gardiens naturels. Ce qui suit l’inscription est décrit dans le parcours d’un nouveau système.
- Des déclencheurs écrits. Nouveau fournisseur, nouvelle fonction d’IA dans un logiciel en place, changement d’usage d’un système, évolution réglementaire.
- Un réexamen en revue de direction. Les changements d’enjeux et d’attentes des parties intéressées font partie de ce que la revue de direction examine : c’est le moment naturel de rouvrir le périmètre.
Ce qu’il faut retenir
Le périmètre ne se choisit pas au jugé. Il se déduit d’un inventaire qui va chercher ce que personne n’a déclaré, et des exigences de ceux qui ont des attentes sur vos systèmes. Il s’écrit avec ses exclusions et leurs motifs, et il ne vaut que s’il reste à jour.