La plupart des organisations ne peuvent pas répondre à une question d’une simplicité trompeuse : combien de systèmes d’IA sont actuellement en fonctionnement dans l’entreprise ? L’incapacité à fournir une réponse fiable — et l’absence d’un inventaire complet des systèmes d’IA — n’est pas seulement une lacune administrative. C’est une responsabilité en matière de conformité, un angle mort de la gestion des risques, et une position de plus en plus intenable à mesure que les cadres réglementaires, partout dans le monde, passent de recommandations volontaires à des obligations contraignantes.

L’AI Act de l’UE, entré en vigueur en août 2024 et dont les obligations sont progressivement déployées jusqu’en 2027, impose aux déployeurs de systèmes d’IA à haut risque d’enregistrer ces systèmes dans la base de données de l’UE (article 71) et de maintenir une documentation qui présuppose un recensement complet de chaque système concerné [1]. ISO/IEC 42001, la norme internationale relative aux systèmes de management de l’IA, exige que les organisations documentent le périmètre et le contexte de leurs systèmes d’IA comme prérequis à la certification, faisant de la catalogisation systématique une nécessité pratique [2]. Le NIST AI Risk Management Framework considère l’identification et la classification des systèmes d’IA comme l’activité fondatrice de sa fonction Map, qui alimente toutes les activités ultérieures de mesure et de gestion des risques [3]. Sans inventaire complet des systèmes d’IA, la conformité à l’un quelconque de ces cadres est structurellement impossible.

Pourtant, la tâche consistant à cataloguer chaque système d’IA au sein d’une entreprise est bien plus complexe qu’il n’y paraît au premier abord. Ce guide propose une approche systématique pour construire un inventaire d’IA à partir de zéro, y compris les informations à capturer, les méthodes pour découvrir des systèmes pouvant être invisibles à la gouvernance centrale, et les moyens de maintenir la précision de l’inventaire dans la durée.

Pourquoi un inventaire d’IA est le fondement de la gouvernance

Indépendamment des obligations réglementaires, un inventaire complet des systèmes d’IA constitue le prérequis de pratiquement toute activité de gouvernance en aval. Les évaluations de risques ne peuvent pas être réalisées sur des systèmes inconnus. Les audits de biais ne peuvent pas atteindre les outils d’IA que les achats n’ont jamais enregistrés. Les plans de réponse aux incidents ne peuvent pas prendre en compte des processus pilotés par l’IA auxquels l’IT n’a aucune visibilité.

Les conséquences pratiques d’un fonctionnement sans inventaire sont déjà visibles. Les organisations soumises à l’AI Act de l’UE sont confrontées à une obligation d’enregistrement des systèmes à haut risque dans la base de données européenne [1]. Celles qui visent la certification ISO 42001 doivent démontrer un processus systématique d’identification et de gestion des systèmes d’IA à l’échelle de l’organisation [2]. Les régulateurs financiers, notamment la Bank of England, la FCA et la Banque centrale européenne, ont commencé à publier des attentes de supervision qui supposent que les entreprises sachent précisément quelles décisions sont influencées par des outils algorithmiques ou fondés sur l’IA [4].

Le défi est amplifié par le rythme d’adoption de l’IA. L’enquête mondiale 2024 de McKinsey sur l’IA a révélé que 72 % des organisations avaient adopté l’IA dans au moins une fonction métier, avec une adoption presque doublée d’une année sur l’autre et une grande partie de cette adoption au niveau des départements, sans supervision centrale [5]. Des plateformes telles que Enzai ont émergé spécifiquement pour répondre à la complexité du maintien d’un inventaire d’IA vivant à l’échelle de l’entreprise, en connectant la découverte, la classification des risques et le suivi continu dans une couche unique de gouvernance.

Un inventaire d’IA n’est pas une case de conformité à cocher. C’est l’artefact unique dont dépend toute autre activité de gouvernance.

Le défi de la découverte

Comprendre pourquoi les systèmes d’IA sont difficiles à cataloguer est essentiel avant de tenter de construire l’inventaire lui-même. L’IA ne se comporte pas comme les logiciels traditionnels en matière de visibilité. Elle s’intègre dans des outils existants, fonctionne via des API tierces et prolifère au travers de décisions individuelles des employés qui ne passent jamais par un service achats.

IA fantôme

Le défi de découverte le plus significatif est l’IA fantôme : des systèmes adoptés par des employés ou des équipes sans approbation formelle. Un analyste marketing qui souscrit à un outil de rédaction assistée par IA avec une carte bancaire personnelle, une équipe commerciale qui utilise un service d’IA de transcription de réunions, une équipe finance qui expérimente un grand modèle de langage via une extension de navigateur. Chacun de ces cas représente un système d’IA traitant des données organisationnelles en dehors de tout cadre de gouvernance.

IA intégrée dans les plateformes SaaS

Les principaux éditeurs de logiciels d’entreprise ont intégré des fonctionnalités d’IA dans leurs produits existants à une vitesse extraordinaire. Une plateforme CRM introduisant le scoring prédictif de prospects, un système RH ajoutant la présélection de CV, un outil de support client déployant la génération automatisée de réponses. Ce sont des systèmes d’IA, mais ils arrivent souvent sous forme de mises à jour de fonctionnalités plutôt que de nouveaux achats, ce qui les rend invisibles aux audits logiciels traditionnels.

IA des fournisseurs et des tiers

Lorsqu’une organisation fait appel à un fournisseur qui utilise l’IA dans la prestation de ses services, l’organisation peut devenir déployeur de ce système d’IA au regard de cadres réglementaires tels que l’AI Act de l’UE. Un prestataire de vérification d’antécédents utilisant l’IA pour filtrer des candidats, un sous-traitant de traitement des sinistres utilisant l’IA pour trier les dossiers, un partenaire logistique utilisant l’IA pour l’optimisation des tournées. Chacun crée une obligation de gouvernance qui commence par la connaissance de l’existence du système.

IA développée en interne

Les équipes data science, les laboratoires d’innovation et les départements d’ingénierie logicielle peuvent construire et déployer des modèles d’IA qui ne passent jamais par un processus formel de gestion des mises en production. Des notebooks Jupyter promus en production, des modèles de machine learning exécutés sur des serveurs départementaux, des scripts de décision automatisée passés d’une preuve de concept à un rôle critique pour l’activité sans qu’aucune mise en service formelle n’ait été effectuée.

Le défi de la découverte est fondamentalement un enjeu de visibilité. La gestion traditionnelle des actifs IT n’a pas été conçue pour l’IA, et les outils et processus sur lesquels la plupart des organisations s’appuient manqueront la majorité de leur empreinte IA.

Que capturer dans votre inventaire d’IA

Un inventaire d’IA utile doit trouver l’équilibre entre exhaustivité et pragmatisme. Capturer trop peu rend l’inventaire insuffisant pour l’évaluation des risques et la conformité. Capturer trop d’informations crée une charge de maintenance qui conduit à sa dégradation. Le cadre de modèle suivant couvre les champs exigés par les obligations réglementaires, les normes sectorielles et les besoins pratiques de gouvernance.

Champs d’identification de base

Propriété et responsabilité

Classification des risques et de la conformité

Détails techniques et opérationnels

Cycle de vie et statut

Tous les champs ne seront pas renseignés pour chaque système dès la première itération. Une approche pragmatique consiste à définir quels champs sont obligatoires à l’entrée (nom du système, responsable, type de déploiement, classification des risques) et lesquels peuvent être reportés au premier cycle de revue de gouvernance. Le schéma d’inventaire d’IA de Enzai met en œuvre cette approche par paliers, en distinguant les champs obligatoires à l’entrée des champs d’enrichissement progressif, afin d’éviter que les équipes ne sautent tout ou ne se retrouvent paralysées par un formulaire de 22 champs pour chacun des 200 systèmes. L’objectif est d’établir la structure et de combler les lacunes de manière systématique, plutôt que de retarder l’inventaire jusqu’à ce que chaque champ puisse être rempli parfaitement.

Méthodes de découverte

Avec une vision claire des données à capturer, la question suivante est de savoir comment identifier chaque système d’IA en fonctionnement au sein de l’organisation. Aucune méthode unique ne permettra une couverture complète. Un programme de découverte efficace combine plusieurs approches.

Analyse automatisée et découverte technique

L’analyse du trafic réseau peut identifier les appels API vers des fournisseurs de services d’IA connus, y compris les principaux endpoints d’IA cloud de prestataires tels que OpenAI, Google, Anthropic et AWS. Les journaux DNS, les enregistrements de serveurs proxy et les outils CASB (cloud access security broker) peuvent signaler des connexions à des services d’IA non formellement approuvés. L’analyse de composition logicielle peut identifier les bibliothèques et frameworks d’IA au sein d’applications développées en interne.

Les organisations utilisant des plateformes comme Enzai peuvent intégrer des capacités de découverte automatisée directement dans leur workflow de gouvernance, réduisant l’effort manuel requis et garantissant que les systèmes nouvellement détectés sont immédiatement signalés pour classification et revue.

Audit des achats et des fournisseurs

Une revue systématique des dossiers d’achats, des contrats de licence logicielle et des contrats fournisseurs mettra en évidence les systèmes d’IA acquis via des canaux formels. Cela doit inclure une revue rétrospective des contrats existants, car de nombreux fournisseurs ont ajouté des fonctionnalités d’IA à des produits auparavant non liés à l’IA. Les équipes achats doivent être sensibilisées afin de signaler toute nouvelle acquisition incluant des capacités d’IA ou de machine learning.

Enquêtes collaborateurs et auto-déclaration

La sollicitation directe des unités métier demeure l’une des méthodes de découverte les plus efficaces pour l’IA fantôme. Une enquête structurée demandant aux équipes d’identifier tous les outils, services ou modèles qu’elles utilisent impliquant l’IA, le machine learning, le traitement du langage naturel ou la prise de décision automatisée révélera de manière constante des systèmes qu’aucune méthode de scan technique ne détecterait. L’enquête doit être formulée de manière constructive, en mettant l’accent sur l’accompagnement de gouvernance plutôt que sur le contrôle, afin d’encourager une divulgation sincère.

Questionnaires fournisseurs

Pour les relations tierces existantes, un questionnaire ciblé demandant aux fournisseurs si l’IA est utilisée dans la prestation de services et, le cas échéant, de quel type et dans quel but, permettra d’identifier l’IA intégrée et l’IA tierce. Cela est particulièrement important pour les processus métier externalisés où l’IA peut être introduite par le fournisseur sans notification explicite au client.

Analyse du trafic réseau et API

Au-delà du scan des endpoints d’IA connus, une analyse plus approfondie des schémas de trafic API peut révéler des systèmes d’IA qui communiquent par des canaux non évidents. Le suivi de motifs cohérents avec des appels d’inférence de modèles — tels que des charges JSON structurées envoyées vers des endpoints externes avec des profils de latence typiques de l’inférence ML — peut faire émerger des systèmes que d’autres méthodes ne détectent pas.

Les programmes de découverte les plus robustes exécutent ces méthodes en parallèle et les répètent selon un cycle régulier. Une analyse unique permettra de capturer la majorité des systèmes, mais une découverte continue est nécessaire pour suivre le rythme d’entrée de nouveaux outils d’IA dans l’organisation.

Construire le processus d’inventaire

Un inventaire d’IA n’est durable que dans la mesure où le processus et la structure de gouvernance qui le soutiennent le sont. Sans responsabilité claire, implication transverse et workflows définis, même un catalogue initial approfondi se dégradera en quelques mois.

Établir la responsabilité

Une fonction unique doit être propriétaire de l’inventaire d’IA en tant qu’actif de l’entreprise. Dans la plupart des organisations, cela relève de l’un des trois rôles suivants : Chief AI Officer (lorsque ce rôle existe), Chief Information Security Officer ou Chief Compliance Officer. L’exigence critique est que ce responsable dispose d’une autorité suffisante pour imposer la divulgation à toutes les unités métier et d’une crédibilité technique suffisante pour collaborer avec les équipes d’ingénierie sur la classification et l’évaluation des risques.

Implication transverse

Le processus d’inventaire exige la participation active de multiples fonctions :

• IT et ingénierie fournissent les capacités de découverte technique et peuvent identifier les systèmes d’IA développés en interne, les détails d’infrastructure et les points d’intégration.

• Achats signalent les nouvelles acquisitions d’IA et réexaminent rétrospectivement les relations fournisseurs existantes.

• Juridique et conformité classifient les systèmes au regard des obligations réglementaires, y compris les catégories de risque de l’AI Act de l’UE et les obligations de protection des données.

• Responsables des unités métier identifient les outils d’IA utilisés dans leurs équipes et attribuent un propriétaire métier à chaque système.

• Protection des données / Vie privée évaluent le traitement des données personnelles et garantissent l’alignement avec le RGPD et les cadres équivalents.

• Audit interne valide périodiquement l’exhaustivité et l’exactitude de l’inventaire.

Définir le workflow d’entrée

Tout nouveau système d’IA, qu’il soit acquis, développé ou découvert par scan, doit passer par un workflow d’entrée standardisé. Ce workflow doit inclure l’enregistrement initial (renseignement des champs d’identification de base), une classification préliminaire des risques, l’attribution des responsables métier et technique, et la planification d’une revue complète de gouvernance. Le processus d’entrée doit être suffisamment léger pour ne pas inciter à le contourner, tout en étant suffisamment rigoureux pour qu’aucun système n’entre en production sans documentation de gouvernance de base.

Définir la cadence de gouvernance

L’inventaire doit faire l’objet d’une revue formelle au minimum trimestrielle. Chaque revue doit évaluer l’exhaustivité (de nouveaux systèmes ont-ils été ajoutés depuis le dernier cycle ?), l’exactitude (les détails des systèmes existants sont-ils toujours corrects ?) et la posture de conformité (des systèmes opèrent-ils en dehors de leurs paramètres de risque approuvés ?).

Un processus sans responsabilité claire est une aspiration. Un processus avec responsabilité, adhésion transverse et cadence définie est un programme de gouvernance.

Maintenir l’inventaire dans le temps

La construction initiale est la moitié la plus simple du défi. Maintenir un inventaire vivant et exact exige des déclencheurs, de l’automatisation et une intégration à la conduite du changement organisationnel au sens large.

Déclencheurs de mise à jour de l’inventaire

L’inventaire doit être mis à jour dès lors que l’un des événements suivants survient :

• Un nouveau système d’IA est acquis, développé ou déployé

• Un système existant est modifié de manière substantielle (nouvelles sources de données, évolution du périmètre décisionnel, réentraînement du modèle)

• Un système est décommissionné ou suspendu

• Un fournisseur informe l’organisation d’ajouts de fonctionnalités d’IA à un produit existant

• Un changement réglementaire modifie la classification des risques d’un système existant

• Un incident impliquant un système d’IA est signalé

• Une réorganisation modifie la propriété métier d’un système

Découverte continue

Les méthodes de découverte technique doivent fonctionner en continu plutôt que sous forme d’exercices périodiques. Le scan automatisé du trafic API IA, les alertes CASB sur de nouveaux outils IA SaaS et l’intégration aux pipelines de déploiement logiciel pour signaler les composants IA dans les nouvelles versions contribuent tous à réduire le délai entre l’entrée d’un système dans l’organisation et son apparition dans l’inventaire.

Intégration à la gestion du changement

L’inventaire d’IA doit être intégré aux processus existants de gestion du changement et de gestion des services IT. Les comités consultatifs de changement doivent inclure l’impact sur l’inventaire d’IA comme critère standard d’évaluation. Les processus de déploiement logiciel doivent inclure une vérification des composants IA. Les workflows de gestion des fournisseurs doivent inclure la divulgation de l’IA comme exigence contractuelle et de revue standard.

Historique des versions et piste d’audit

Chaque modification d’une entrée de l’inventaire doit être journalisée avec un horodatage, l’identité de la personne ayant effectué la modification et la raison de la mise à jour. Cette piste d’audit n’est pas seulement une bonne pratique. C’est une exigence explicite de plusieurs cadres réglementaires et elle sera attendue par les auditeurs et les autorités de supervision.

La maintenance est le point de défaillance de la plupart des inventaires d’IA. Les organisations qui réussissent sont celles qui traitent l’inventaire comme un système vivant intégré aux workflows opérationnels, et non comme un document statique revisité annuellement.

Pièges fréquents

Même les organisations bien dotées en ressources rencontrent des modes d’échec prévisibles lors de la construction et du maintien d’un inventaire d’IA. Reconnaître ces schémas en amont améliore significativement la probabilité d’un résultat durable.

Définir l’IA de manière trop restrictive. Les organisations qui limitent leur inventaire aux « modèles de machine learning » manqueront les systèmes de décision automatisée fondés sur des règles, l’automatisation robotisée des processus avec des éléments cognitifs, et les outils d’IA générative utilisés de manière informelle dans l’entreprise. La définition de ce qui constitue un système d’IA à des fins d’inventaire doit être volontairement large et alignée sur les définitions réglementaires, comme le cadrage étendu de l’AI Act de l’UE [1].

Traiter l’inventaire comme un projet IT. Si l’inventaire est détenu exclusivement par l’IT, l’adoption de l’IA côté métier sera systématiquement sous-déclarée. Inversement, s’il est détenu exclusivement par la conformité, les détails techniques seront lacunaires et peu fiables. La responsabilité transverse n’est pas optionnelle.

Rechercher la perfection dès la première itération. Les organisations qui exigent de compléter chaque champ pour chaque système avant de publier l’inventaire ne publieront jamais l’inventaire. Une approche pragmatique accepte des dossiers partiels dans la version initiale et met en place un programme structuré pour combler les lacunes lors des cycles de revue suivants.

Négliger l’IA des fournisseurs. Les systèmes d’IA ayant le plus grand impact sur une organisation sont fréquemment ceux opérés par des tiers. L’IA d’un prestataire de vérification d’antécédents, le modèle d’un bureau de scoring de crédit, l’outillage de sécurité automatisé d’une plateforme cloud. Ils exigent la même attention de gouvernance que les systèmes développés en interne, et souvent davantage, compte tenu de la visibilité réduite.

Ne pas relier l’inventaire à l’action. Un inventaire d’IA qui existe sous forme de feuille de calcul, revue annuellement, déconnectée des processus d’évaluation des risques, de gestion des incidents et de reporting réglementaire, apporte une valeur de gouvernance négligeable. L’inventaire doit constituer l’ossature opérationnelle du programme de gouvernance de l’IA, et non une annexe.

Sous-estimer la charge de maintenance. Le rythme d’adoption de l’IA dans la plupart des organisations signifie qu’un inventaire complété aujourd’hui sera substantiellement incomplet dans un délai de trois à six mois sans processus de maintenance actif. Les organisations doivent budgéter un effort continu pour la tenue de l’inventaire, et pas seulement pour la construction initiale.

La différence entre un inventaire d’IA qui apporte de la valeur de gouvernance et un inventaire qui prend la poussière ne réside pas dans la sophistication du catalogue initial. Elle réside dans la rigueur du processus qui le maintient à jour et connecté à la prise de décision.

Implications pratiques

La trajectoire réglementaire est sans ambiguïté. L’AI Act de l’UE, ISO 42001, le NIST AI RMF, ainsi qu’un ensemble croissant d’attentes de supervision sectorielles convergent tous vers la même exigence fondamentale : les organisations doivent savoir quelles IA elles possèdent, où elles opèrent, qui en est responsable et quels risques elles présentent. Le coût de construction de cette capacité ne fait qu’augmenter avec le délai, car le volume de systèmes d’IA dans toute entreprise croît plus vite que la capacité à les cataloguer rétrospectivement.

Les organisations qui commencent dès maintenant, même avec une première itération imparfaite, seront dans une position nettement meilleure que celles qui attendent qu’une échéance réglementaire les contraigne à agir. Le cadre de modèle, les méthodes de découverte et les structures de processus présentés dans ce guide offrent un point de départ concret.

Pour les organisations qui souhaitent opérationnaliser leur inventaire d’IA au sein d’une plateforme conçue spécifiquement pour la gouvernance, le risque et la conformité de l’IA, Enzai propose une approche structurée de découverte, de classification et de maintenance continue. Réserver une démonstration pour voir comment cela fonctionne en pratique.

Références

[1] Parlement européen et Conseil de l’Union européenne, « Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l’intelligence artificielle (Artificial Intelligence Act) », Journal officiel de l’Union européenne, août 2024.

[2] Organisation internationale de normalisation, « ISO/IEC 42001:2023 - Technologies de l’information - Intelligence artificielle - Système de management », décembre 2023.

[3] National Institute of Standards and Technology, « Artificial Intelligence Risk Management Framework (AI RMF 1.0) », NIST AI 100-1, janvier 2023.

[4] Bank of England, FCA, PRA et PSR, « Artificial intelligence and machine learning », DP5/22, octobre 2022 ; PRA, Supervisory Statement SS1/23, 2023.

[5] McKinsey and Company, « The State of AI in Early 2024: Gen AI Adoption Spikes and Starts to Generate Value », mai 2024.