Inventaire des systèmes d'IA : comment recenser et qualifier les usages de l'entreprise ?

Un inventaire des systèmes d'IA recense tous les outils qui utilisent l'IA dans l'entreprise : développements internes, logiciels achetés, fonctions intégrées aux outils métier et usages génératifs des équipes. Chaque système y reçoit une fiche courte, un responsable et une qualification du risque. Tenu à jour, il sert de base à toute la gouvernance de l'IA.

Demander à une direction combien de systèmes d'IA elle utilise produit souvent une réponse rapide et incomplète. Les projets portés par l'équipe data viennent en tête : un modèle de prévision des ventes, un outil de détection d'anomalies, un assistant interne. Le reste échappe au décompte, non par négligence, mais parce que personne ne le considère comme un « projet IA ».

Le logiciel de recrutement propose un tri automatique des candidatures. Le CRM suggère la prochaine action commerciale. L'outil de support rédige des réponses aux clients. Des collaborateurs utilisent un assistant génératif pour résumer des contrats ou reformuler des courriers. Chacun de ces usages traite des données de l'entreprise et peut influencer une décision, sans jamais avoir été enregistré comme tel.

Tant que l'IA restait cantonnée à quelques projets identifiés, une liste tenue par l'équipe data suffisait. Ce n'est plus le cas lorsque l'IA arrive par les éditeurs de logiciels et par les usages individuels, en dehors de tout circuit de validation.

L'inventaire n'est donc pas un exercice documentaire. C'est la condition pour savoir où se trouvent les risques, qui en répond et quelles règles appliquer à chaque usage.

Pourquoi un inventaire des systèmes d'IA est devenu indispensable

Un inventaire répond à une question simple : quels systèmes d'IA l'entreprise utilise-t-elle, pour quoi faire, et sous la responsabilité de qui ? Sans cette réponse, aucune autre décision de gouvernance ne repose sur une base solide.

L'IA entre dans l'entreprise par plusieurs portes à la fois

Les systèmes d'IA d'une organisation ont des origines très différentes, et chacune échappe à un circuit de contrôle distinct. Cette diversité explique qu'un inventaire construit à partir d'une seule source reste partiel.

• Les développements internes : modèles construits par l'équipe data ou par un prestataire pour un besoin précis. Ce sont les mieux connus, parce qu'ils ont fait l'objet d'un projet.
• Les logiciels achetés pour leur fonction d'IA : outils de tri de candidatures, de détection de fraude, d'analyse de documents. Ils passent par les achats, mais leur composante IA n'est pas toujours signalée comme telle.
• Les fonctions d'IA ajoutées à des logiciels existants : un éditeur active une fonction de suggestion ou de génération dans un outil déjà utilisé. Aucun nouvel achat n'a lieu, donc aucun circuit ne s'enclenche.
• Les usages génératifs individuels : assistants conversationnels utilisés par les collaborateurs, avec ou sans licence de l'entreprise. Ce sont les moins visibles, faute de circuit d'achat ou de projet.

Un système non recensé est un système que personne ne pilote

Un système absent de l'inventaire n'a pas de responsable désigné, pas de règles d'usage et pas de suivi. En cas d'erreur, personne ne sait qui doit répondre, ni même depuis quand le système est en service.

Cette absence de visibilité pose aussi une question de conformité. Ce que l'IA Act change concrètement pour les projets IA dépend du niveau de risque de chaque système, et ce niveau ne peut pas être évalué pour un système dont on ignore l'existence.

L'inventaire ne se confond pas avec un catalogue de données

Un catalogue de données décrit les jeux de données disponibles, leur signification et leur responsable. L'inventaire des systèmes d'IA décrit les usages : ce qu'un système fait, pour qui, avec quelles données et avec quelles conséquences.

Les deux se complètent. Un Data Catalog mis en place tôt facilite considérablement l'inventaire, puisqu'il permet de rattacher chaque système aux sources qu'il utilise. Mais un catalogue, même complet, ne dit rien des usages qui en sont faits.

Comment recenser les systèmes d'IA, y compris ceux qu'on ne voit pas ?

Le recensement ne peut pas reposer sur une seule source. Chaque porte d'entrée de l'IA dans l'entreprise appelle une méthode de repérage différente, et c'est leur combinaison qui produit un inventaire fiable.

Partir des projets connus et des équipes data

La première source est la plus simple : les projets déjà identifiés par l'équipe data, la DSI ou les directions métier. Ils constituent le socle de l'inventaire et permettent de tester la fiche de recensement sur des cas bien documentés.

Ce premier passage sert aussi à repérer les personnes qui connaissent le mieux les usages de chaque direction. Elles deviennent les relais de la suite du recensement.

Passer en revue les achats et les contrats logiciels

La deuxième source est le portefeuille de logiciels. Une revue des contrats, des factures et des outils référencés par la DSI permet d'identifier ceux qui intègrent une fonction d'IA, même lorsque celle-ci n'est pas mise en avant.

Cette revue gagne à s'appuyer sur quelques questions posées systématiquement à chaque éditeur, par écrit.

• Le logiciel contient-il une fonction d'IA ? Si oui, laquelle, et est-elle activée par défaut ?
• Quelles données de l'entreprise cette fonction utilise-t-elle ? Et où ces données sont-elles traitées ?
• Les résultats influencent-ils une décision concernant une personne ? Un classement, un score, une recommandation, un refus.
• Quelle documentation l'éditeur fournit-il ? Sur le fonctionnement, les limites et les conditions d'usage de la fonction.

Interroger les métiers sur leurs usages réels

La troisième source est l'usage quotidien. Un questionnaire court, adressé aux responsables d'équipe, permet de repérer les outils génératifs utilisés, les fonctions d'IA activées dans les logiciels et les usages que personne n'a déclarés.

La formulation des questions compte plus que leur nombre. Demander « utilisez-vous l'IA ? » produit peu de réponses. Demander « quels outils vous proposent des suggestions, des résumés ou des textes rédigés automatiquement ? » en produit beaucoup plus, parce que la question décrit ce que les équipes voient à l'écran.

Le recensement des usages génératifs doit se faire sans logique de sanction. Une équipe qui craint d'être reprise pour un usage non validé le taira. Une équipe qui comprend que l'objectif est d'encadrer, pas d'interdire, le déclarera. Les règles sur l'IA générative viennent ensuite, une fois les usages connus.

Consolider les résultats sans créer de doublons

Les trois sources se recoupent. Un même outil peut apparaître dans la revue des contrats, dans le questionnaire d'une direction et dans la liste des projets data, sous trois noms différents. Sans consolidation, l'inventaire gonfle artificiellement et perd sa crédibilité.

La consolidation repose sur une règle simple : une fiche par système et par finalité. Un outil utilisé par deux directions pour la même finalité fait l'objet d'une seule fiche, qui mentionne les deux directions. Le même outil utilisé pour deux finalités différentes fait l'objet de deux fiches, parce que le niveau de risque peut différer d'un usage à l'autre.

Que doit contenir une fiche d'inventaire ?

Une fiche d'inventaire utile reste courte. Elle rassemble les informations nécessaires pour qualifier le risque, désigner un responsable et décider des règles à appliquer, sans chercher à documenter tout le fonctionnement technique du système.

Les informations indispensables pour chaque système

Le tableau suivant présente les champs à renseigner pour chaque système, et la raison pour laquelle chacun compte. Il sert de modèle de départ, à adapter au vocabulaire de l'organisation.

Le bon niveau de détail : assez pour décider, pas plus

Une fiche trop détaillée ne sera jamais remplie, ou sera remplie une fois puis abandonnée. Une fiche trop sommaire ne permettra pas de qualifier le risque. Le bon niveau de détail est celui qui permet de répondre à trois questions : ce système influence-t-il une décision concernant une personne, quelles données utilise-t-il, et qui en répond ?

Les informations techniques plus poussées (performances, architecture, jeux de données d'entraînement) relèvent d'une documentation distincte. Elles ne sont nécessaires que pour les systèmes qualifiés à risque élevé.

Comment qualifier chaque système d'IA recensé ?

Recenser ne suffit pas. Chaque système doit ensuite recevoir une qualification qui détermine les règles à lui appliquer. Cette étape transforme une liste en outil de décision.

Préciser le rôle de l'organisation : fournisseur ou déployeur

L'AI Act distingue le fournisseur, qui développe un système d'IA ou le fait développer pour le mettre sur le marché ou en service sous son nom, et le déployeur, qui utilise un système sous sa propre autorité. Les obligations diffèrent selon le rôle.

Pour un logiciel acheté et utilisé tel quel, l'entreprise est en principe déployeur. Pour un modèle développé en interne et proposé à des clients ou à des partenaires, elle peut devenir fournisseur. Ce point mérite d'être tranché avec la direction juridique pour chaque système concerné, plutôt que supposé.

Classer le système selon son niveau de risque

L'AI Act organise ses règles par niveaux de risque : les pratiques interdites, les systèmes à haut risque, les systèmes soumis à des obligations de transparence et ceux qui présentent un risque minimal. La qualification consiste à placer chaque système recensé dans l'un de ces niveaux.

Les systèmes à haut risque se trouvent notamment dans des domaines comme le recrutement et la gestion des ressources humaines, l'évaluation de la solvabilité, l'éducation, l'accès aux services essentiels et les infrastructures critiques. Un même outil peut relever d'un niveau différent selon l'usage qui en est fait, ce qui explique pourquoi la finalité est le champ le plus important de la fiche.

L'inventaire fonctionne comme un cycle en quatre étapes : repérer, décrire, qualifier, suivre. La qualification ne vient qu'après le recensement et conditionne les règles appliquées ensuite, et le suivi renvoie un système vers une nouvelle qualification dès que son usage change.

Croiser avec les obligations liées aux données personnelles

La qualification au regard de l'AI Act ne remplace pas l'analyse au titre du RGPD. Un système qui traite des données personnelles doit figurer au registre des traitements, avec une finalité et une base légale.

Le registre existant constitue d'ailleurs une source précieuse pour l'inventaire : il peut déjà contenir des traitements qui reposent sur des outils d'IA. Le lien entre les deux exercices, détaillé dans l'article sur le RGPD à l'ère de l'IA, évite de documenter deux fois la même information. La protection des données personnelles fournit un cadre que les équipes juridiques connaissent déjà, ce qui accélère la qualification.

Traiter à part les usages génératifs des collaborateurs

Les assistants génératifs utilisés par les équipes posent une difficulté particulière : ils sont nombreux, leurs usages varient d'une personne à l'autre et ils évoluent vite. Une fiche par personne et par usage rendrait l'inventaire ingérable.

Une approche plus réaliste consiste à recenser les outils plutôt que chaque usage individuel, puis à qualifier les grandes familles d'usages observées. Rédiger un courrier, résumer un document interne, analyser un fichier client ou préparer une décision RH ne présentent pas le même niveau de risque. La qualification porte alors sur le type d'usage, et les règles s'appliquent à tous ceux qui le pratiquent.

Cette approche permet aussi de repérer les usages qui méritent d'être sortis du cadre individuel. Un usage génératif qui influence des décisions sur des personnes, ou qui traite des données sensibles, doit être traité comme un système à part entière, avec sa propre fiche et son propre responsable.

Qui porte l'inventaire des systèmes d'IA ?

Un inventaire sans propriétaire se périme vite. La question de savoir qui le tient, qui l'alimente et qui en répond doit être tranchée avant le premier recensement.

Un pilote central, des contributeurs dans chaque direction

L'inventaire a besoin d'un pilote unique, qui fixe la méthode, consolide les fiches et suit les mises à jour. Selon l'organisation, ce rôle revient au responsable de la gouvernance de l'IA, au Data Office ou à la direction de la conformité.

Le pilote ne peut pas tout recenser seul. Chaque direction désigne un contributeur qui connaît les usages de son périmètre et remplit les fiches. La question de savoir qui est responsable de l'IA en entreprise, et de quoi exactement trouve ici une application directe.

Un responsable métier nommé pour chaque système

Chaque système recensé doit avoir un responsable côté métier. Ce n'est pas la personne qui l'a installé, c'est celle qui répond de son usage : elle connaît la finalité, valide les évolutions et décide de l'arrêt si le système ne répond plus au besoin.

Pour les systèmes qui utilisent des données sensibles, le Data Owner du domaine concerné intervient aussi. Il confirme que les données utilisées peuvent l'être pour cette finalité.

Comment tenir l'inventaire des systèmes d'IA à jour ?

Un inventaire exact le jour de sa création perd de sa valeur à chaque nouvel outil, à chaque mise à jour d'éditeur et à chaque nouvel usage. La mise à jour doit donc être organisée dès le départ.

Des déclencheurs de mise à jour connus de tous

Certains événements doivent entraîner automatiquement la création ou la révision d'une fiche. Les rendre explicites évite que la mise à jour dépende de la mémoire de quelques personnes.

• L'achat ou le renouvellement d'un logiciel : la présence d'une fonction d'IA est vérifiée à chaque contrat.
• L'activation d'une nouvelle fonction chez un éditeur : la fiche du logiciel concerné est revue, même sans nouvel achat.
• Le lancement d'un projet data ou IA : la fiche est créée dès le cadrage, pas à la mise en service.
• Le changement de finalité d'un système existant : un outil utilisé pour une nouvelle décision est requalifié.
• L'arrêt d'un système : la fiche est archivée, avec la date et la raison de l'arrêt.

Une revue régulière pour corriger les écarts

En complément des déclencheurs, une revue périodique de l'inventaire permet de repérer les systèmes oubliés, les fiches incomplètes et les usages qui ont évolué. Elle réunit le pilote, les contributeurs et, si nécessaire, la direction juridique.

Cette revue est aussi le moment de décider de l'avenir de certains systèmes. Un outil qui n'est plus utilisé, qui ne répond plus au besoin ou qui présente un risque disproportionné peut être arrêté. La méthode pour prioriser des cas d'usage IA sans sur-promettre s'applique aussi à l'existant.

Les erreurs qui rendent un inventaire inutilisable

Quelques erreurs vident l'inventaire de son intérêt. Les connaître permet de les éviter dès la conception.

• Un inventaire limité aux projets de l'équipe data : les logiciels achetés et les usages génératifs restent invisibles.
• Des fiches sans responsable nommé : personne ne met à jour ce dont personne ne répond.
• Une qualification faite une fois pour toutes : un changement d'usage peut faire passer un système d'un niveau de risque à un autre.
• Un inventaire tenu dans un fichier que personne ne consulte : il doit être accessible aux personnes qui prennent des décisions sur les outils.

L'inventaire, point de départ de la gouvernance de l'IA

Un inventaire complet ne règle aucun risque à lui seul. Il rend en revanche toutes les autres décisions possibles : choisir les systèmes à encadrer en priorité, fixer les règles d'usage, désigner les responsables, décider des arrêts.

La démarche tient en trois temps, dans cet ordre : recenser tous les systèmes avec une fiche courte, qualifier chacun selon son rôle et son niveau de risque, puis organiser la mise à jour. Suivre cet ordre permet d'obtenir plus vite une vision exploitable. Chercher d'emblée l'exhaustivité technique retarde au contraire le moment où l'inventaire devient utile.