Inventaire des systèmes d’IA : champs, règles et méthode

L’essentiel

• L’inventaire des systèmes d’IA recense chaque système, modèle, agent et service d’IA tiers que l’organisation conçoit, achète ou utilise.
• Aucun texte ne porte ce titre, mais l’enregistrement prévu à l’article 49 de l’AI Act, le GOVERN 1.6 du NIST AI RMF et l’annexe A.4 de l’ISO/IEC 42001 le supposent tous.
• Il ne se confond ni avec la base de données de l’UE, ni avec un registre de modèles MLOps, ni avec une AI-BOM.
• Chaque colonne utile se rattache à une exigence précise : rôle, propriétaire, classification, évaluations liées, contrôle humain.
• Un inventaire qui sert vraiment est vivant : porte d’entrée, déclencheurs de mise à jour, attestation périodique, fiche de retrait.

Inventaire des systèmes d’IA : ce qu’il est, et ce qu’il n’est pas

Un inventaire des systèmes d’IA est le registre interne qui décrit, pour chaque usage de l’intelligence artificielle dans l’organisation, ce que fait le système, qui en répond, sur quelles données et quel modèle il repose, et quel niveau de risque il présente. Il couvre les développements maison, les solutions achetées, l’IA intégrée aux logiciels SaaS et les agents. Précisons d’emblée qu’il ne s’agit pas de gestion de stocks assistée par l’IA : ici, l’objet inventorié est l’IA elle-même. Le précédent le plus proche est le registre des activités de traitement prévu à l’article 30 du RGPD. Beaucoup d’organisations partent d’ailleurs de ce registre et l’étendent. La logique est la même : on ne peut ni évaluer, ni contrôler, ni prouver ce qu’on n’a pas listé. Le vocabulaire de la CNIL privilégie le mot « registre », et les deux termes coexistent dans les directions juridiques ; ce qui compte est le contenu, pas l’étiquette. La confusion vient de quatre objets voisins, que le tableau distingue. <table header-row= »true »> <tr> <td>Objet</td> <td>Ce que c’est</td> <td>Qui le tient</td> <td>Statut juridique</td> </tr> <tr> <td>Inventaire des systèmes d’IA</td> <td>Registre interne de tous les usages d’IA, avec propriétaires, risques et évaluations liées</td> <td>La fonction gouvernance ou conformité de l’IA, alimentée par les métiers</td> <td>Non nommé par les textes, mais présupposé par l’AI Act, le NIST AI RMF et l’ISO/IEC 42001</td> </tr> <tr> <td>Enregistrement dans la base de données de l’UE</td> <td>Fiche d’un système à haut risque ou d’un usage par une autorité publique, dans une base gérée par la Commission</td> <td>Le fournisseur, ou le déployeur public</td> <td>Obligation légale (articles 49 et 71 de l’AI Act)</td> </tr> <tr> <td>Registre de modèles (MLOps)</td> <td>Catalogue technique des versions de modèles, des artefacts et des métriques d’entraînement</td> <td>Les équipes data science et plateforme ML</td> <td>Outil d’ingénierie, sans portée réglementaire propre</td> </tr> <tr> <td>AI-BOM</td> <td>Nomenclature des composants d’un système : modèles, jeux de données, bibliothèques, au format SPDX 3.0 ou CycloneDX ML-BOM</td> <td>Le fournisseur ou l’équipe produit</td> <td>Pratique de sécurité de la chaîne d’approvisionnement, sans obligation générale</td> </tr> <tr> <td>Registre des risques</td> <td>Liste des risques identifiés, de leur cotation et des mesures de traitement</td> <td>La gestion des risques</td> <td>Attendu par l’ISO/IEC 42001 et par le système de gestion des risques de l’AI Act pour le haut risque</td> </tr> </table> L’inventaire des systèmes d’IA est la table pivot : il pointe vers la fiche d’enregistrement, le registre de modèles, l’AI-BOM et le registre des risques, sans remplacer aucun d’eux. Pour le contenu attendu au niveau d’un système pris isolément, voir notre guide sur la documentation d’un système d’IA.

Comment l’inventaire des systèmes d’IA soutient une gouvernance responsable

La question revient dans tous les comités : en quoi tenir un inventaire des systèmes d’IA sert-il une gouvernance responsable, au-delà de la case cochée ? La réponse tient en cinq mécanismes concrets.

1. Il fixe le périmètre de tous les autres contrôles. Une charte d’usage, un programme de tests de biais ou une revue des fournisseurs ne s’appliquent qu’aux systèmes connus. Sans inventaire des systèmes d’IA, chaque contrôle a son propre périmètre implicite, et les trous se trouvent précisément là où personne n’a regardé : l’IA fantôme utilisée sans validation, ou la fonction d’IA activée par une simple mise à jour d’éditeur.
2. Il pilote la classification et la hiérarchisation des risques. La qualification d’un système d’IA à haut risque dépend de l’usage, pas de la technologie. Un même modèle de langage peut présenter un risque minimal pour résumer des comptes rendus et relever de l’annexe III lorsqu’il trie des candidatures. Parce qu’il enregistre la finalité, l’inventaire porte cette distinction.
3. Il désigne un responsable par système. Chaque ligne nomme un propriétaire métier et un propriétaire technique. Le comité de gouvernance de l’IA arbitre alors sur une liste nominative, et non sur un portefeuille flou.
4. Il détecte le changement. Nouvel usage, nouvelle version de modèle, nouveau fournisseur : chacun peut changer la catégorie de risque. Un inventaire des systèmes d’IA daté et historisé rend visible l’écart entre ce qui a été évalué et ce qui tourne réellement en production.
5. Il constitue la preuve dans laquelle l’auditeur échantillonne. Auditeur de certification, autorité de surveillance du marché ou audit interne commencent par la même demande : la liste. Ils y prélèvent un échantillon, puis vérifient évaluation, propriétaire et preuves. Une liste incomplète fragilise toute la démonstration qui suit.

En somme, l’inventaire des systèmes d’IA transforme des principes en périmètre mesurable. Les politiques disent quoi faire ; l’inventaire dit à quoi, par qui et depuis quand.

Quelles règles rendent l’inventaire des systèmes d’IA obligatoire

Aucun texte n’impose un document intitulé « inventaire des systèmes d’IA ». En revanche, plusieurs régimes imposent des obligations qu’aucune organisation ne peut remplir sans lui : enregistrer, documenter, classer, rendre compte. Certains sont contraignants, comme le règlement (UE) 2024/1689 sur l’intelligence artificielle ; d’autres sont volontaires mais vérifiés en audit. Le tableau résume l’état du droit fin septembre 2026 ; partout, l’inventaire des systèmes d’IA précède l’obligation. <table header-row= »true »> <tr> <td>Régime</td> <td>Disposition</td> <td>Qui</td> <td>Ce qui est exigé</td> <td>Statut en septembre 2026</td> </tr> <tr> <td>AI Act</td> <td>Art. 6(4), 26(8), 49 et 71</td> <td>Fournisseurs de systèmes de l’annexe III ; déployeurs publics</td> <td>Enregistrement dans la base de données de l’UE avant mise sur le marché ou mise en service</td> <td>En vigueur ; obligations de l’annexe III reportées au 2 décembre 2027, enregistrement maintenu</td> </tr> <tr> <td>NIST AI RMF 1.0</td> <td>GOVERN 1.6</td> <td>Toute organisation qui adopte le cadre</td> <td>Mécanismes d’inventaire dotés de ressources selon les priorités de risque</td> <td>Volontaire</td> </tr> <tr> <td>ISO/IEC 42001:2023</td> <td>Annexe A.4, contrôle A.4.2</td> <td>Organisations certifiées ou candidates</td> <td>Documentation des ressources de chaque système d’IA</td> <td>Volontaire, vérifié en audit de certification</td> </tr> <tr> <td>Agences fédérales américaines</td> <td>EO 13960, Advancing American AI Act, mémo OMB M-25-21</td> <td>Agences fédérales</td> <td>Inventaire annuel et public des cas d’usage</td> <td>En vigueur ; inventaire 2025 publié en avril 2026</td> </tr> <tr> <td>Banques américaines</td> <td>SR 26-2 (Fed, OCC, FDIC)</td> <td>Établissements supervisés</td> <td>Inventaire des modèles, hiérarchisé selon la matérialité</td> <td>En vigueur depuis le 17 avril 2026</td> </tr> <tr> <td>Secteur public britannique</td> <td>ATRS</td> <td>Ministères centraux et organismes rattachés</td> <td>Fiches de transparence publiées sur GOV.UK</td> <td>Obligatoire depuis 2025</td> </tr> </table>

AI Act : l’enregistrement suppose un inventaire

L’article 49 oblige le fournisseur d’un système à haut risque de l’annexe III à l’enregistrer dans la base de données de l’UE avant sa mise sur le marché ou sa mise en service (art. 49(1)). Le fournisseur qui conclut, sur le fondement de l’article 6(3), que son système de l’annexe III n’est pas à haut risque doit documenter cette évaluation et l’enregistrer malgré tout (art. 6(4) et 49(2)). Les déployeurs qui sont des autorités publiques ou des institutions de l’Union enregistrent leur usage (art. 49(3) et 26(8)), et les systèmes des domaines répressif, migratoire et frontalier vont dans une section sécurisée non publique (art. 49(4)). La Commission tient la base (art. 71). Le règlement Omnibus numérique sur l’IA, (UE) 2026/1744, publié le 24 juillet 2026 et entré en vigueur le 27 juillet 2026, a reporté les obligations de l’annexe III au 2 décembre 2027 et celles de l’annexe I au 2 août 2028, mais a conservé l’obligation d’enregistrement, y compris pour les systèmes exemptés au titre de l’article 6(3). Impossible de savoir quoi enregistrer, ou quoi écarter, sans liste préalable.

NIST AI RMF : GOVERN 1.6

Le cadre américain est le seul à énoncer l’exigence en toutes lettres. GOVERN 1.6 dispose : « Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities », soit : des mécanismes d’inventaire des systèmes d’IA existent et sont dotés de ressources selon les priorités de risque de l’organisation. Le Playbook du NIST suggère d’énumérer les systèmes d’IA de l’organisation, puis d’étendre l’inventaire à la provenance des données, aux problèmes connus, aux rôles de supervision humaine et aux modèles de fondation sous-jacents. Notre page consacrée au NIST AI RMF détaille les quatre fonctions du cadre.

ISO/IEC 42001 : annexe A.4, documentation des ressources

La norme ISO/IEC 42001:2023 consacre son annexe A.4 aux ressources des systèmes d’IA. Le contrôle A.4.2 demande, en substance, d’identifier et de documenter pour chaque système d’IA les ressources dont il dépend : données, outils, ressources système et de calcul, ressources humaines. Cette exigence est inapplicable sans inventaire des systèmes d’IA, que l’auditeur vérifiera sur échantillon. Pour le déroulé et le budget d’une démarche, voir notre article sur la certification ISO 42001.

Agences fédérales américaines : mémo OMB M-25-21

Aux États-Unis, l’inventaire est public. Sur le fondement de l’Executive Order 13960 (section 5), de l’Advancing American AI Act et du mémorandum OMB M-25-21, les agences fédérales déclarent chaque année leurs cas d’usage. L’inventaire 2025, publié par l’OMB en avril 2026, recense 3 611 cas d’usage issus de 56 déclarations d’agences, dont 445 qualifiés à fort impact. C’est plus du double des 1 757 cas déclarés pour 2024. Les systèmes de sécurité nationale et la recherche en sont exclus.

Banques : l’inventaire de modèles de SR 26-2

La lettre SR 26-2 de la Réserve fédérale, publiée le 17 avril 2026 avec l’OCC et la FDIC, remplace SR 11-7. Elle retient une définition plus étroite du modèle et une hiérarchisation fondée sur la matérialité ; les modèles non significatifs peuvent rester à l’inventaire sous des contrôles allégés. Plusieurs commentateurs relèvent que l’IA générative et les agents échappent largement à cette définition : les banques ont donc besoin d’un inventaire des systèmes d’IA plus large que leur inventaire de modèles. Voir aussi notre guide sur la gestion du risque modèle.

Registres de transparence du secteur public : ATRS et angle français

Au Royaume-Uni, l’Algorithmic Transparency Recording Standard est devenu obligatoire en 2025 pour les ministères centraux et leurs organismes rattachés, avec des fiches publiées sur GOV.UK. En France, il n’existe pas d’équivalent sectoriel, mais la CNIL a publié une liste de vérification pour le développement des systèmes d’IA qui suppose, elle aussi, de savoir quels systèmes sont concernés.

Inventaire des systèmes d’IA : les champs indispensables

Un bon inventaire des systèmes d’IA n’a pas le plus de colonnes : chacune répond à une question qu’un régulateur, un auditeur ou un comité posera. Voici les douze champs essentiels. <table header-row= »true »> <tr> <td>Champ</td> <td>Pourquoi il compte</td> <td>Régime qui le demande</td> </tr> <tr> <td>Identifiant unique et nom</td> <td>Relier sans ambiguïté la ligne aux évaluations, aux incidents et à la fiche d’enregistrement</td> <td>Tous ; AI Act art. 49 pour l’enregistrement</td> </tr> <tr> <td>Finalité métier et cas d’usage</td> <td>La classification dépend de l’usage, pas du modèle</td> <td>AI Act annexe III ; NIST AI RMF (MAP)</td> </tr> <tr> <td>Rôle (fournisseur, déployeur, importateur, distributeur)</td> <td>Les obligations de l’AI Act changent entièrement selon le rôle</td> <td>AI Act</td> </tr> <tr> <td>Statut dans le cycle de vie</td> <td>Distinguer projet, pilote, production et retrait ; déclencher l’enregistrement au bon moment</td> <td>AI Act art. 49 ; ISO/IEC 42001</td> </tr> <tr> <td>Propriétaire métier et propriétaire technique</td> <td>Sans nom, pas de responsabilité</td> <td>NIST AI RMF GOVERN ; ISO/IEC 42001</td> </tr> <tr> <td>Fournisseur ou provenance du modèle, y compris le modèle de fondation</td> <td>Suivre la dépendance et nourrir la due diligence des fournisseurs d’IA</td> <td>NIST Playbook GOVERN 1.6 ; ISO/IEC 42001 A.4.2</td> </tr> <tr> <td>Catégories de données, dont données personnelles et sensibles</td> <td>Faire le lien avec le RGPD et le registre des traitements</td> <td>RGPD art. 30 ; ISO/IEC 42001 A.4.2</td> </tr> <tr> <td>Personnes concernées et effet sur les décisions</td> <td>Mesurer l’impact sur les droits et la gravité d’une erreur</td> <td>AI Act ; OMB M-25-21 (fort impact)</td> </tr> <tr> <td>Classification des risques (niveau AI Act, niveau interne)</td> <td>Orienter les contrôles et leur intensité</td> <td>AI Act art. 6 ; SR 26-2 (matérialité)</td> </tr> <tr> <td>Évaluations liées (AIPD, FRIA, analyse d’impact de l’IA, évaluation de la conformité)</td> <td>Prouver que chaque système a été évalué au bon niveau</td> <td>RGPD ; AI Act ; ISO/IEC 42001</td> </tr> <tr> <td>Modalités de contrôle humain</td> <td>Désigner qui peut intervenir, quand et avec quels moyens</td> <td>AI Act art. 14 ; NIST Playbook GOVERN 1.6</td> </tr> <tr> <td>Numéro d’enregistrement dans la base de l’UE, le cas échéant</td> <td>Rattacher la ligne interne à la fiche officielle</td> <td>AI Act art. 49 et 71</td> </tr> <tr> <td>Date de revue et journal des modifications</td> <td>Démontrer que l’inventaire est tenu à jour, pas figé</td> <td>ISO/IEC 42001 ; SR 26-2</td> </tr> </table> Le champ « rôle » est souvent oublié alors qu’il conditionne tout le reste : une entreprise peut être déployeur d’un outil RH acheté et fournisseur d’un modèle de scoring maison. Et dans un inventaire des systèmes d’IA, le champ « évaluations liées » contient des liens vers les documents, pas un simple « oui ».

Construire et maintenir un inventaire des systèmes d’IA

La première version d’un inventaire des systèmes d’IA prend quelques semaines ; sa maintenance est permanente. Sept étapes suffisent.

1. Croiser les sources de découverte. Aucune source ne suffit seule : contrats d’achat et contrats fournisseurs, journaux SSO et CASB pour repérer l’IA fantôme, facturation cloud et API, dépôts de code et plateformes de ML, et une campagne de déclaration auprès des directions métiers.
2. Installer une porte d’entrée. Aucun système ne passe en production sans ligne dans l’inventaire des systèmes d’IA. Le point de contrôle se place là où la décision se prend déjà : validation achats, revue d’architecture, mise en production.
3. Trier et hiérarchiser. Chaque nouvelle entrée reçoit une qualification AI Act (interdit, haut risque, transparence, minimal) et un niveau interne, qui détermine la profondeur des évaluations à mener.
4. Nommer les propriétaires. Un propriétaire métier répond de la finalité et de l’usage ; un propriétaire technique répond du fonctionnement. Les deux signent.
5. Définir les déclencheurs de mise à jour. Nouvelle finalité, nouvelle version de modèle, changement de fournisseur, incident, ouverture à une nouvelle juridiction : chacun impose de rouvrir la ligne, et parfois de réévaluer le système.
6. Organiser une attestation périodique. Chaque propriétaire confirme, au moins une fois par an et plus souvent pour le haut risque, que sa ligne est exacte.
7. Tracer le retrait. Un système décommissionné ne disparaît pas de l’inventaire des systèmes d’IA : il passe au statut « retiré », avec la date, le motif et le sort des données.

Les agents méritent une attention particulière. Un agent qui enchaîne des appels d’outils, lit des bases internes ou déclenche des actions est un objet d’inventaire à part entière, tout comme les outils MCP qu’il appelle. Pour chacun, l’inventaire des systèmes d’IA indique les permissions accordées, les systèmes touchés et la personne qui répond de ses actions. Notre comparaison entre IA agentique et IA générative explique pourquoi le profil de risque change dès que le système agit au lieu de seulement répondre.

Où les inventaires d’IA échouent

Un inventaire des systèmes d’IA échoue rarement pour des raisons techniques. Six écueils reviennent.

• Le tableur qui se périme. Les versions se multiplient, les colonnes dérivent, personne ne sait laquelle fait foi.
• Compter les outils au lieu des usages. « Copilot » n’est pas une ligne ; « Copilot pour les réponses clients » en est une.
• Oublier l’IA embarquée dans les SaaS. CRM, SIRH et outils de support ajoutent des fonctions d’IA sans nouveau contrat.
• Des lignes sans propriétaire. Une entrée orpheline n’est ni mise à jour, ni défendue en audit.
• Aucun lien vers les évaluations. Un inventaire qui ne pointe pas vers les analyses d’impact et les preuves de contrôle reste déclaratif.
• Un inventaire construit une fois, pour un audit. Figé à la date de l’audit, il devient faux dès le trimestre suivant.

Le remède est commun : relier l’inventaire des systèmes d’IA au reste du dispositif de conformité de l’IA, pour qu’il soit mis à jour par les processus existants et non par une campagne annuelle.

FAQ

L’inventaire des systèmes d’IA est-il obligatoire au titre de l’AI Act ? Pas sous ce nom : l’AI Act ne contient aucun article intitulé « inventaire ». En pratique, il est pourtant indispensable. Un fournisseur ne peut pas enregistrer ses systèmes de l’annexe III, ni documenter ceux qu’il écarte au titre de l’article 6(3), sans liste exhaustive. Un déployeur public ne peut pas enregistrer des usages qu’il ne connaît pas. Et toute organisation doit vérifier qu’elle n’utilise aucune pratique interdite. L’inventaire des systèmes d’IA est donc le préalable de fait à la conformité. Quelle différence entre un inventaire des systèmes d’IA et la base de données de l’UE ? La base de données de l’UE, créée par l’article 71 et gérée par la Commission, reçoit les enregistrements légaux : systèmes à haut risque de l’annexe III, systèmes écartés au titre de l’article 6(3) et usages par des autorités publiques. Elle ne contient qu’une fraction des systèmes. L’inventaire interne couvre tous les usages, y compris à risque minimal, avec des informations non publiques (propriétaires, évaluations, preuves), et reprend le numéro d’enregistrement quand il existe. Qui doit être propriétaire de l’inventaire ? L’inventaire des systèmes d’IA dans son ensemble relève d’une fonction centrale : le responsable de la gouvernance de l’IA, la conformité ou la gestion des risques, selon l’organisation. Chaque ligne, en revanche, appartient à un propriétaire métier, responsable de la finalité, et à un propriétaire technique, responsable du fonctionnement. La fonction centrale fixe les règles et vérifie la qualité ; elle ne remplit pas les lignes à la place des métiers. À quelle fréquence faut-il le mettre à jour ? En continu pour les événements, périodiquement pour la vérification. Toute nouvelle finalité, nouvelle version de modèle, changement de fournisseur ou incident déclenche une mise à jour immédiate de la ligne concernée. En complément, une attestation annuelle par chaque propriétaire garantit que rien n’a dérivé en silence ; pour le haut risque, une revue semestrielle ou trimestrielle est plus prudente. Un inventaire des systèmes d’IA mis à jour une fois par an est faux la majeure partie de l’année. Un tableur suffit-il ? Pour démarrer, oui ; pour durer, rarement. Un tableur lance le recensement, puis montre ses limites : pas d’historique fiable, pas de liens vers les évaluations, pas de relances, versions concurrentes. Dès que l’inventaire des systèmes d’IA dépasse quelques dizaines de lignes ou doit servir de preuve en audit, un outil dédié, relié aux évaluations et aux propriétaires, devient nécessaire. Faut-il inventorier les agents d’IA ? Oui, et avec plus de détail que les autres systèmes. Un agent agit : il appelle des outils, lit des données, déclenche des opérations. L’inventaire des systèmes d’IA décrit donc, en plus des champs habituels, les outils et serveurs MCP qu’il utilise, les permissions accordées, les systèmes qu’il peut modifier, le niveau d’autonomie et la personne qui répond de ses actions. Un agent construit sur un modèle déjà inventorié reste une ligne distincte, car son usage et son risque diffèrent.

Conclusion

L’inventaire des systèmes d’IA n’est pas une bonne pratique parmi d’autres : c’est l’objet que présupposent l’enregistrement de l’AI Act, le GOVERN 1.6 du NIST, l’annexe A.4 de l’ISO/IEC 42001, les inventaires fédéraux américains et la supervision bancaire. Sa valeur tient aux liens qu’il porte : vers les propriétaires, les évaluations, les preuves et la fiche d’enregistrement. Un inventaire des systèmes d’IA qui vit au rythme des achats, des mises en production et des incidents devient l’ossature de la gouvernance ; un inventaire figé redevient un tableur. C’est cette logique qui structure le registre de l’IA d’AI Sigil : chaque entrée y est reliée à ses évaluations, à ses responsables et à ses preuves, pour que la liste reste exacte le jour où quelqu’un la demande.