Les mêmes questions pour chaque application IA, avec des réponses cohérentes

Une liste de noms d'outils IA n'est pas un inventaire. Un inventaire ne naît que si vous consignez pour chaque application le même ensemble de données, de sorte à pouvoir les comparer entre elles, les classifier et les démontrer ultérieurement. Sans cette structure fixe, vous ne conservez qu'une collection de faits isolés que plus personne ne peut comparer.

Ce que vous consignez : les champs essentiels

Pour chaque application, il s'agit d'un nombre limité de champs qui reviennent systématiquement.

Nom et forme. Est-ce un abonnement autonome, une fonctionnalité intégrée à un logiciel existant, un modèle développé en interne, ou une fonction IA fournie par un prestataire sans que personne ne l'ait qualifiée d'« IA ».

Qui l'utilise. Une équipe, un service, un collaborateur individuel. Cela détermine non seulement l'ampleur, mais aussi qui vous devrez contacter ultérieurement en cas de questions.

À quoi cela sert. Pas le texte marketing du fournisseur, mais la tâche effective : rédiger des textes, synthétiser des données, écrire du code, répondre aux questions des clients, préparer des décisions. Ce champ détermine le rôle que joue l'application et, par conséquent, le niveau de risque.

Quelles données y entrent. Données personnelles, données clients, informations financières, documents internes, ou aucune donnée sensible. Cela détermine quelles exigences de gouvernance deviennent pertinentes.

Comment cela a été acquis. Via un processus formel, via un abonnement que quelqu'un a souscrit de sa propre initiative, via un fournisseur qui l'intègre à un autre produit. La voie d'acquisition vous renseigne immédiatement sur le niveau de contrôle déjà exercé.

Qui en est responsable. Pas celui qui l'utilise par hasard, mais celui qui doit répondre si quelque chose ne va pas ou si vous souhaitez savoir si l'application est encore utilisée.

Depuis quand et pour combien de temps. Une application qui fonctionne depuis trois ans sans avoir été remarquée nécessite une approche différente d'un projet pilote lancé le mois dernier.

Ce ne sont pas de simples cases à cocher bureaucratiques. Ce sont les données dont vous avez besoin pour pouvoir dire, application par application : ceci relève d'un niveau de risque plus élevé, ceci non, et voici la justification.

D'où proviennent ces données

Aucun de ces champs n'est disponible intégralement dans une seule source. Vous construisez l'inventaire à partir de plusieurs canaux qui se complètent.

Le service informatique fournit un point de départ, mais pas une image complète : pourquoi la liste informatique n'est pas exacte explique qu'une part importante de l'usage de l'IA échappe aux systèmes gérés par l'informatique. Les signaux dont dispose l'informatique restent néanmoins utiles comme filtre : quels signaux informatiques sont exploitables montre quels indices techniques sont suffisamment fiables pour approfondir les questions.

Les achats et la finance complètent une autre partie. Les factures, abonnements et licences révèlent quels outils ont réellement été payés, même si l'utilisateur ne l'a jamais signalé. Ce que révèlent les données d'achat et de licence décrit quels champs issus de cette source s'intègrent directement dans l'inventaire.

La dernière partie, et la plus déterminante, provient des collaborateurs eux-mêmes. Celui qui exécute la tâche sait quel outil est utilisé, même si celui-ci n'a jamais été demandé ni approuvé. Vous n'obtiendrez cette information que si le fait de poser la question n'a aucune conséquence pour celui qui répond : comment poser la question sans risque de sanction décrit comment formuler cette question sans qu'elle ne soit perçue comme un contrôle.

Pourquoi la structure importe plus que l'exhaustivité

Un inventaire qui devrait être complet d'un seul coup ne verra jamais le jour. Les applications changent, de nouveaux outils apparaissent, d'anciens disparaissent. Ce qui demeure, c'est la structure : les mêmes champs, les mêmes questions, la même méthode de consignation. Cette structure permet d'ajouter demain une application manquante aujourd'hui, sans devoir tout recommencer.

C'est aussi pourquoi l'ordre dans lequel vous remplissez les champs importe moins que la cohérence avec laquelle vous le faites. Une organisation comptant plusieurs sites, services ou filiales se heurte ici à une couche de complexité supplémentaire, car une même application est utilisée différemment d'un site à l'autre : comment construire un inventaire IA dans une organisation à plusieurs entités explique comment garder ces différences visibles sans perdre la comparabilité. Qui souhaite savoir précisément, dans une telle structure, quels champs doivent être remplis séparément par site, trouvera cela dans ce que vous devez consigner par application dans une organisation à plusieurs entités.

De la consignation à la classification

Dès que les champs sont remplis pour chaque application, il devient possible de classifier : quel rôle joue cette application, quel niveau de risque lui correspond, et quelles mesures de gouvernance s'y rattachent logiquement. Cette étape se fonde sur ce qui a été consigné, pas sur une estimation faite après coup.

Consigner ce que fait une application n'équivaut pas à savoir ce qu'il reste comme travail

Cet inventaire décrit quelles applications IA existent et qui les utilise. Il ne décrit pas quelle part du travail sous-jacent est effectivement reprise par cette application. C'est une autre question, avec un autre instrument : le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, sur la base des tâches que vous consignez, et non sur la base de l'outil utilisé.