Une organisation comptant plusieurs sites dispose rarement d'un seul environnement informatique. Il existe souvent un contrat central pour les grands logiciels de productivité, mais à côté de cela existent des budgets d'achat locaux, des gestionnaires informatiques régionaux et des sites qui souscrivent leurs propres abonnements. Qui recherche l'usage de l'IA au sein d'une telle structure doit savoir quels signaux disent quelque chose et lesquels ne donnent que l'impression d'être complets.
Le service informatique central fournit généralement un aperçu des licences : quels outils ont été achetés, pour quels services et avec quelles fonctions activées. Cet aperçu est un point de départ, pas un point final. Il montre ce qui a été approuvé, pas ce qui est utilisé, et encore moins ce qui a été ajouté par chaque site en plus de cette offre centrale. Une raison pour laquelle la liste informatique n'est pas exacte est précisément celle-ci : l'approbation et l'usage sont deux questions différentes, et avec plusieurs sites, l'écart entre les deux se creuse à chaque site supplémentaire.
Au sein d'une organisation comptant plusieurs sites, certains signaux, qui coïncident encore dans le cas d'un seul site, se distinguent les uns des autres.
La facturation en est un exemple. Un paiement par carte de crédit pour un abonnement d'IA peut figurer sur le centre de coûts du site plutôt que sur le budget informatique central. Qui ne regarde que le système d'achat central manque entièrement ces dépenses.
Le trafic réseau est un autre signal, et il ne se comporte pas de la même façon partout. Un site disposant de sa propre connexion internet génère un trafic qui reste en dehors des journaux du pare-feu central. Le trafic vers des domaines d'IA connus n'est alors visible que si ce site est raccordé au même point de surveillance que le siège, ce qui n'est pas toujours le cas.
Les extensions de navigateur et les comptes isolés forment une troisième catégorie. Ceux-ci sont généralement installés localement, sur des équipements gérés par un collaborateur informatique régional ou parfois par l'utilisateur lui-même. Un parc d'appareils géré de manière centralisée avec un déploiement logiciel uniforme fait apparaître ce type d'installations ; un site disposant de sa propre gestion ne les montre justement pas, sauf si la question est posée spécifiquement.
Enfin, il y a la question de savoir qui a accès à quoi. Un outil acheté de manière centralisée pour un service peut également se retrouver, via des identifiants partagés, dans d'autres sites, sans que cela soit consigné nulle part. La gestion des accès par site, dans la mesure où elle existe, donne ici une indication, mais aucune certitude.
Aucune de ces sources n'est complète en elle-même. Les données de facturation montrent des dépenses, pas un usage. Les journaux réseau montrent du trafic, pas une intention ou un contexte. La gestion des accès montre qui peut se connecter, pas qui le fait réellement et pour quoi. Pour un seul site, il reste possible de croiser ces sources ; avec plusieurs sites, le risque naît que chaque site ne détienne qu'une partie du tableau et que personne n'en ait la vue d'ensemble.
S'y ajoute la source humaine : interroger les collaborateurs et les responsables locaux. Ce signal est souvent le plus riche, car il montre non seulement ce qui est utilisé, mais aussi pour quoi et à quelle fréquence. C'est en même temps le signal le plus fragile, car il ne fonctionne que si les personnes osent répondre. La manière d'aborder cela est décrite dans comment le demander sans que cela n'entraîne de sanction.
Les signaux sont utiles, mais sans consignation fixe, ils restent des observations isolées. Pour chaque application trouvée, il est utile de noter au minimum : quel site ou service utilise l'outil, qui gère ou a acheté l'application, quel type de données y est saisi, et si l'application prend des décisions de manière autonome ou se limite à un appui. Cette structuration est développée davantage dans ce que vous consignez par application, et la construction de l'aperçu complet, du premier signal à un inventaire cohérent, est décrite dans comment construire un inventaire de l'IA.
Avec plusieurs sites, la distinction entre fournisseur et utilisateur d'une application d'IA est d'autant plus pertinente, car un site ajoute parfois lui-même une fonctionnalité d'IA à un produit ou un service, obtenant ainsi un rôle différent de celui du site qui se contente d'utiliser un outil prêt à l'emploi. La nature de cette distinction est expliquée sur êtes-vous fournisseur ou utilisateur, et le moment où ce rôle peut évoluer, par exemple à la suite d'adaptations qu'un site effectue lui-même, est expliqué sur quand votre rôle change-t-il.
L'objectif de cet inventaire n'est pas l'exhaustivité en une seule fois, mais un point de départ pouvant être répété. Les sites évoluent, les abonnements sont renouvelés ou résiliés, et de nouveaux outils apparaissent plus vite qu'un audit annuel ne peut le suivre. Un aperçu qui combine les principaux signaux et qui est reproductible par site offre davantage de repères qu'un instantané ponctuel.
Une fois qu'il est visible quelles applications d'IA sont utilisées au sein de l'organisation, une autre question suit naturellement : ce que ces applications font précisément avec le travail lui-même. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise par l'IA, et rejoint ainsi l'aperçu que produit le Responsible AI Scan.
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.