Une organisation comptant plusieurs établissements ne manque généralement pas d'usages de l'IA, mais de vue d'ensemble. Chaque établissement fait ses propres choix, souscrit ses propres abonnements ou laisse les équipes déterminer elles-mêmes ce qui est pratique. Le résultat est un ensemble d'applications qui n'est consigné nulle part dans sa totalité. Avant de pouvoir classifier ou faire un rapport sur quoi que ce soit, cet ensemble doit d'abord exister sous forme de liste — avec, pour chaque application, les mêmes données fixes, quel que soit l'établissement qui les communique.
Pour chaque application, vous consignez en principe : le nom et le fournisseur, l'établissement ou le service où elle est utilisée, qui gère ou a acquis l'application, à quoi elle est destinée, quelles données y sont introduites, et si l'application prend des décisions de manière autonome ou se limite à un rôle de soutien. Cette dernière distinction déterminera en grande partie le niveau de risque : un outil qui reformule un texte s'évalue différemment d'un système qui sélectionne des candidats ou évalue des demandes de crédit.
Avec plusieurs établissements s'ajoute un champ supplémentaire : l'application a-t-elle été acquise localement ou déployée de manière centralisée. Cette distinction est nécessaire pour voir si un même risque est apparu indépendamment à plusieurs endroits, ou si une seule décision s'est propagée à l'ensemble de l'organisation.
Le premier endroit où vous chercheriez est le service informatique, et cette liste constitue un bon point de départ — mais pas le point final. Pourquoi la liste informatique n'est pas exacte dans une organisation à plusieurs établissements explique que les licences gérées de manière centralisée ne couvrent qu'une partie de l'usage. Les établissements qui utilisent leur propre carte de crédit pour un abonnement, ou les équipes qui déploient une version gratuite d'un outil, n'apparaissent nulle part dans une administration centrale. La vue d'ensemble que vous construisez doit donc combiner plusieurs sources, pas une seule.
Outre la liste informatique, les données financières fournissent un autre type de signal. Ce que révèlent les données d'achat et de licence dans une organisation décrit comment les factures, abonnements et dépenses par carte de crédit par établissement donnent des indications sur des applications souscrites hors des achats centraux. Ceci est particulièrement pertinent avec plusieurs établissements : les achats locaux passent souvent par d'autres canaux que l'informatique centrale, et c'est précisément là que se forme la plus grande partie de l'image incomplète.
Aucune liste — technique ou financière — ne vous indique à quoi une application est réellement utilisée. Seules les personnes qui travaillent avec elle au quotidien le savent. Comment le demander aux collaborateurs sans sanction dans une organisation aborde la condition qui fait réussir ou échouer cette étape : quiconque sent qu'une réponse peut avoir des conséquences répond de manière incomplète ou pas du tout. Avec plusieurs établissements, ceci est d'autant plus important, car les habitudes locales peuvent fortement varier et une enquête nationale gomme facilement ces différences.
Outre les entretiens et les factures, l'environnement informatique existant contient souvent déjà des indications que personne n'a identifiées comme telles : trafic réseau vers certains domaines, nouvelles extensions de navigateur, ou connexions API mises en place quelque part. Quels signaux informatiques sont utiles dans une organisation à plusieurs établissements montre lesquels de ces signaux renseignent réellement sur l'usage de l'IA et lesquels ne sont que du bruit. Pour une organisation à plusieurs établissements, c'est un moyen de voir si un même schéma se répète à différents endroits, sans avoir à interroger chaque établissement séparément.
Une fois les données rassemblées par application — origine, finalité d'usage, données concernées, gestionnaire, établissement —, la classification peut commencer. Chaque application ne mérite pas la même attention : un outil qui résume des comptes rendus internes pèse différemment d'un système qui a une incidence sur les clients ou les collaborateurs. Cette pondération dépend de ce que fait l'application, pas du nombre de personnes qui l'utilisent ni de la date de son acquisition.
Cet inventaire est un processus continu, pas un instantané. Les établissements ajoutent des applications, les fournisseurs modifient des fonctionnalités, et ce qui est aujourd'hui un soutien peut demain décider de manière autonome. La vue d'ensemble que vous construisez doit donc être reproductible : les mêmes questions, les mêmes champs, à chaque fois à nouveau dans les mêmes établissements.
Le Responsible AI Scan est conçu pour structurer cet inventaire : les mêmes champs fixes par application, complétés par des signaux informatiques, des données d'achat et des entretiens avec les collaborateurs, aboutissant à une classification qui s'aligne sur la structure de risque existante de l'organisation. Le scan est en cours de développement. Toute personne souhaitant l'utiliser dès qu'il sera disponible peut s'inscrire sur la liste d'attente.
Dès qu'il est clair quelles applications fonctionnent par établissement et ce qu'elles font, la question suivante se pose naturellement : quelle part du travail que ces applications soutiennent peut en fait être reprise par l'IA. C'est une question différente de la gouvernance — il ne s'agit pas de risque et de démonstrabilité, mais du contenu des tâches. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, et s'inscrit ainsi dans la continuité de la vue d'ensemble que vous avez construite avec cet inventaire.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.