Cartographie des systèmes IA : inventaire ISO 42001

Pourquoi un inventaire conditionne tout le SMIA

La clause 4.4 de l'ISO/IEC 42001:2023 demande à l'organisme d'établir, mettre en œuvre et tenir à jour un système de management de l'intelligence artificielle. Cette exigence est inopérante si vous ne savez pas quels systèmes d'IA tombent dans le périmètre. L'inventaire n'est pas un livrable annexe, c'est le socle factuel sur lequel reposent l'analyse de contexte, l'appréciation des risques et la déclaration d'applicabilité^[2].

L'annexe A, à travers l'objectif A.4 sur les ressources, suppose que vous puissiez décrire les composants des systèmes d'IA pour lesquels vous êtes responsable, qu'il s'agisse de données, d'outillage, de calcul ou de compétences^[2]. Sans recensement nominatif, ces contrôles deviennent déclaratifs et l'auditeur n'a aucun moyen de vérifier la complétude.

Pour un SMIA jeune, la tentation est forte de démarrer par les politiques. Les démarches observées montrent que l'inverse est plus solide : sans liste exhaustive des cas d'usage, la politique IA flotte au-dessus du réel et les risques IA évalués sont incomplets par construction.

Délimiter le périmètre et la définition de système d'IA

Premier arbitrage : que considérez-vous comme un système d'IA. L'ISO/IEC 42001 renvoie à la terminologie ISO/IEC 22989, qui distingue les systèmes d'IA des automatisations classiques par leur capacité à inférer des sorties à partir d'entrées^[2]. En pratique, cela couvre les modèles prédictifs, les modèles de langage, les systèmes de recommandation, les outils de scoring et les agents conversationnels embarqués dans vos produits.

La question du périmètre n'est pas seulement technique. La norme s'adresse à tout organisme qui développe, fournit ou utilise des systèmes d'IA^[2]. Vous devez donc cartographier à la fois les systèmes développés en interne, les briques tierces intégrées à vos produits, et les outils SaaS utilisés par les métiers. Cette distinction structure ensuite la déclaration d'applicabilité et les responsabilités contractuelles.

Cas typique en Suisse romande : une fiduciaire utilise un outil de catégorisation d'écritures comptables fourni par un éditeur, un copilote bureautique généraliste pour la rédaction, et un module de détection d'anomalies branché sur l'ERP. Trois systèmes, trois fournisseurs, trois régimes de responsabilité. Tant que ces trois éléments ne figurent pas dans le même registre, la politique IA n'est qu'un document.

Les attributs à documenter par système

L'inventaire utile va au delà du nom et du fournisseur. Le LNE rappelle que la norme couvre la conception, la qualité des données, la qualification et l'identification des risques propres aux applications d'IA^[4]. Ces dimensions doivent être tracées dans la fiche de chaque système, sans quoi l'analyse d'impact reste hors sol.

Attributs minimaux d'une fiche système IA

Identification	Nom, version, propriétaire métier, propriétaire technique
Finalité	Cas d'usage, décisions affectées, population concernée
Provenance	Développement interne, achat, intégration tierce, modèle de fondation utilisé
Données	Sources, données personnelles, sensibilité, base légale
Cycle de vie	Statut, date de mise en service, dernière revue, retrait prévu
Risques	Classification interne, lien vers l'analyse d'impact
Contrôles	Mesures de l'annexe A applicables, supervision humaine, journalisation

Ces attributs sont sélectionnés à partir des thèmes que la norme demande de couvrir dans le SMIA (gouvernance, données, cycle de vie, parties intéressées)^[2]. Ils ne remplacent pas le registre prévu par la conformité AI Act pour les systèmes à haut risque, mais ils en constituent la base commune.

Le champ provenance mérite une attention particulière. Selon EduGroupe, observateur du marché de la formation à la norme, l'ISO 42001 insiste sur la maîtrise des risques dans la chaîne de sous-traitance IA, avec des clauses contractuelles spécifiques et une évaluation des risques tiers^[7]. Cette vérification, à recouper avec les exigences officielles de la norme, suppose de savoir précisément quel composant vient d'où.

Méthode de collecte et sources internes

Un inventaire fiable ne se construit pas par questionnaire générique envoyé à tous les directeurs. La granularité des réponses est trop variable, et les usages d'IA générative en libre service échappent quasi systématiquement à cette approche. Trois sources complémentaires donnent un résultat plus solide.

Aucune source seule ne suffit, le croisement révèle les zones d'ombre.

1Registre achats et contrats fournisseurs (clauses IA, mentions de modèles)

2CMDB et logs IT (flux sortants vers API de modèles, applications déployées)

3Entretiens métiers ciblés (cas d'usage non visibles côté IT)

Le rapprochement des trois listes met en évidence les outils shadow.

Cette méthode est une lecture pratique des attentes de la norme, qui demande de prendre en compte les enjeux internes et externes pertinents et les besoins des parties intéressées^[2]. Interprétation : l'inventaire est par nature transverse et ne peut pas être délégué à une seule fonction.

Le rôle du DPO est ici déterminant. Les registres de traitement RGPD, et en Suisse les registres prévus par la nLPD pour les acteurs concernés, contiennent déjà la moitié des cas d'usage à haut enjeu. Ils ne suffisent pas, beaucoup d'outils d'IA ne traitent pas de données personnelles, mais ils fournissent un point de départ structuré.

Une fois la liste brute constituée, prévoyez une revue de qualification avec le responsable conformité, le RSSI et un référent métier. Cette revue tranche trois questions : ce qui entre dans le périmètre du SMIA, ce qui est suspendu en attente d'analyse, ce qui est exclu et pour quel motif documenté. Cette traçabilité du périmètre est ce qu'un auditeur ISO regardera en priorité.

Gouvernance, mise à jour et rattachement au SMIA

Un inventaire figé perd sa valeur en quelques mois. La norme exige une amélioration continue du SMIA^[2], ce qui implique une cadence formalisée de mise à jour. À la date de rédaction (juin 2026), les retours publics des organismes de certification accrédités sur les rythmes attendus restent peu nombreux, à vérifier auprès de votre organisme. Une cadence trimestrielle pour les revues techniques et annuelle pour la revue de direction constitue une base raisonnable.

La propriété de l'inventaire doit être nominative. Selon ITSocial dans son guide FeelAgile, la mise en place du SMIA inclut l'identification de rôles et responsabilités et une cartographie des systèmes IA portée par la direction^[6], observation à recouper avec le texte officiel de la norme^[2]. En pratique, le responsable du SMIA tient l'inventaire, mais chaque ligne a un propriétaire métier qui répond du contenu.

Le rattachement au reste du SMIA se fait par identifiants stables. Chaque système référencé dans l'inventaire est cité dans l'appréciation des risques de la clause 6.1.2, dans la SoA, dans le plan de traitement et dans les preuves opérationnelles. Sans cette traçabilité, vous obtiendrez des non-conformités majeures sur la cohérence documentaire.

Pièges fréquents observés sur le terrain

Premier piège : confondre cartographie applicative et inventaire des systèmes d'IA. La CMDB liste des applications, pas des cas d'usage. Un même outil peut héberger plusieurs cas d'usage IA aux niveaux de risque très différents, par exemple un assistant interne et un classifieur orienté client. L'inventaire ISO 42001 raisonne par système d'IA, pas par application.

Deuxième piège : sous-estimer le shadow AI. Les outils d'IA générative grand public sont souvent utilisés via comptes personnels, sans laisser de trace côté achats. Le seul moyen de les détecter est de coupler entretiens métiers et journaux réseau. Une politique d'usage signée ne remplace pas la détection.

Troisième piège : recenser sans qualifier. Une fiche système qui se limite à un nom et un fournisseur ne sert à rien pour l'auditeur ni pour l'analyse d'impact IA. Le minimum utile inclut la finalité, les données traitées, la population concernée et un premier niveau de criticité. Mieux vaut dix fiches complètes que cent fiches creuses.

Quatrième piège : oublier les systèmes en projet. Les comités d'investissement décident parfois de cas d'usage IA qui n'apparaîtront dans aucun système avant six mois. La norme couvre l'ensemble du cycle de vie^[2], l'inventaire doit donc inclure une rubrique pour les systèmes décidés mais non encore en service, avec leur stade de maturité.

Cinquième piège : traiter l'inventaire comme un document Word. Le volume des attributs et la fréquence de mise à jour rendent rapidement le format texte ingérable. Un tableur structuré, idéalement adossé au registre RGPD existant, suffit pour démarrer. Les organisations plus matures basculent vers un outil dédié quand le nombre de systèmes franchit la cinquantaine.

Sixième piège : laisser le périmètre se contracter sous pression de calendrier. Quand l'échéance d'audit approche, la tentation est forte d'exclure les systèmes les plus complexes du périmètre du SMIA. C'est défendable si l'exclusion est motivée et documentée, c'est dangereux si elle vise simplement à passer la certification. L'auditeur lira la justification du périmètre avant de regarder les contrôles.

Questions fréquentes

À lire ensuite