Les actifs logiciels occupent aujourd’hui une place majeure dans les budgets informatiques des entreprises. Aux licences traditionnelles se sont progressivement ajoutés les abonnements, les services Cloud, les offres SaaS, les modèles à la consommation et, désormais, les services et agents basés sur l’intelligence artificielle.
Dans ce contexte, le Software Asset Management (SAM) et, plus largement, l’IT Asset Management (ITAM) ne consistent plus seulement à inventorier les logiciels installés sur les postes de travail et les serveurs. Ils doivent permettre à l’entreprise de comprendre ses usages, de maîtriser ses engagements contractuels, d’optimiser ses dépenses et d’anticiper les risques liés aux évolutions technologiques et aux politiques de licensing des éditeurs.
Du suivi des licences à la maîtrise du cycle de vie des actifs logiciels
Le SAM peut être défini comme l’ensemble des processus permettant de gérer les actifs logiciels tout au long de leur cycle de vie : expression du besoin, acquisition ou souscription, déploiement, utilisation, optimisation, renouvellement et retrait.
Cette approche implique généralement plusieurs directions de l’entreprise : DSI, équipes techniques, Achats, Finance, Juridique, Sécurité, mais également les directions métiers consommatrices des solutions.
Chez iMUO, cette démarche s’inscrit plus largement dans le cycle de vie du Procurement IT : depuis l’optimisation de la demande interne et la coordination entre utilisateurs, prescripteurs techniques et Achats, jusqu’à la gouvernance des contrats et au suivi de la stratégie de conformité logicielle.
Une organisation SAM mature doit ainsi être capable de répondre à quelques questions en apparence simples :
Quelles licences possédons-nous ? Quels sont nos droits d’usage ? Quels logiciels et services utilisons-nous réellement ? Nos usages correspondent-ils aux droits acquis ? Et surtout : payons-nous le juste prix pour répondre à nos besoins ?
Les principaux domaines d’intervention du SAM
Les services SAM / ITAM peuvent intervenir à différentes étapes du cycle de vie des contrats et des actifs logiciels.
La gouvernance contractuelle
Les contrats de licences sont devenus particulièrement complexes. Aux contrats historiques d’acquisition de licences perpétuelles se sont ajoutés les abonnements, engagements pluriannuels, métriques Cloud, droits hybrides et modèles de consommation.
La gouvernance contractuelle permet notamment de suivre les droits acquis, les échéances, les évolutions des politiques tarifaires des éditeurs, les avenants, les transferts de licences ou encore les conséquences d’opérations de fusion et acquisition.
Elle permet également d’anticiper les renouvellements plutôt que de découvrir les enjeux contractuels quelques semaines avant une échéance.
L’optimisation et la négociation
Une démarche SAM ne doit pas avoir pour seul objectif la conformité.
La connaissance précise des déploiements, des usages et des droits constitue également un levier important lors des négociations avec les éditeurs.
Il peut s’agir de supprimer des souscriptions inutilisées, d’adapter les éditions ou niveaux de services réellement nécessaires, de consolider différents contrats ou encore de comparer plusieurs scénarios contractuels.
Le SAM devient alors un outil d’aide à la décision permettant de rapprocher les contraintes techniques, contractuelles et financières.
Les audits à blanc et diagnostics de conformité
L’audit à blanc consiste à reproduire en interne une partie de la démarche qui pourrait être appliquée lors d’un audit éditeur.
L’objectif est d’identifier les éventuels écarts entre les droits acquis et les usages constatés, d’en évaluer l’exposition financière potentielle puis, lorsque cela est nécessaire, de définir une stratégie de remédiation.
Cette approche permet surtout de traiter les problèmes avant qu’ils ne soient découverts dans le cadre d’un audit externe.
L’assistance à audit
Lorsqu’un éditeur déclenche un audit, la problématique devient à la fois technique, contractuelle, financière et parfois juridique.
Les données d’inventaire doivent être qualifiées, les règles de licensing applicables vérifiées, le périmètre de l’audit maîtrisé et les éventuels écarts analysés avant toute communication.
L’objectif n’est pas de contester systématiquement les constats de l’éditeur, mais de s’assurer que les quantités, métriques, droits contractuels et hypothèses utilisés pour valoriser une éventuelle non-conformité sont justifiés.
Les services managés et le HelpDesk Licensing
Les problématiques de licences apparaissent désormais tout au long de l’année : nouveau projet Cloud, changement d’architecture, acquisition d’une société, déploiement d’une nouvelle application métier, virtualisation d’un environnement, ouverture d’un service à de nouveaux utilisateurs, etc.
Le SAM évolue donc progressivement d’une logique de projet ponctuel vers une logique de service continu.
Les services managés et HelpDesk Licensing permettent notamment d’intégrer l’expertise licensing aux décisions techniques et achats, avant que les architectures ne soient figées.
Un métier transformé par le Cloud et le SaaS
Le passage au Cloud n’a pas fait disparaître les problématiques de Software Asset Management. Il les a transformées.
Avec une licence perpétuelle, l’un des principaux enjeux consistait à rapprocher un droit acquis d’une installation ou d’un usage.
Dans un environnement SaaS, le problème devient souvent différent : qui dispose d’un abonnement, qui utilise réellement le service, quelles fonctionnalités sont consommées et à quel niveau de licence ?
À cela s’ajoutent les services facturés à la consommation : puissance de calcul, stockage, appels API, transactions ou unités de traitement.
Le SAM doit donc progressivement rapprocher trois univers historiquement séparés :
les droits contractuels, les usages techniques et les données financières.
Et l’arrivée massive de l’intelligence artificielle pourrait accélérer encore cette évolution.
IA : l’accès indirect revient au centre des problématiques de licensing
Les règles d’accès indirect ou de multiplexing ne sont pas nouvelles.
Depuis de nombreuses années, certains éditeurs considèrent qu’intercaler une application, une interface ou un middleware entre un utilisateur et un logiciel ne supprime pas nécessairement les obligations de licence associées à l’utilisateur ou au système sous-jacent.
Microsoft, par exemple, définit le multiplexing comme l’utilisation de matériels, logiciels ou mécanismes d’automatisation permettant notamment de mutualiser les connexions ou de réduire le nombre d’utilisateurs ou de terminaux accédant directement à un produit. Le principe général est que cette couche intermédiaire ne réduit pas automatiquement les licences nécessaires.
L’intelligence artificielle donne toutefois une nouvelle dimension à cette problématique.
Jusqu’à présent, un scénario classique pouvait être relativement facile à représenter :
Utilisateur → Application métier → Base de données
Demain, le scénario pourrait plutôt devenir :
Utilisateur → Agent IA → Serveur MCP → Application métier / API → Base de données
Ou encore :
Utilisateur → Agent IA → RAG → Base vectorielle → Documents / applications / données d’entreprise
Dans ces architectures, l’utilisateur ne consulte parfois plus directement l’application ou la base de données. C’est l’agent qui interroge les systèmes, consolide les informations puis restitue une réponse.
D’un point de vue technique, l’utilisateur peut donc sembler avoir disparu de la chaîne d’accès.
D’un point de vue licensing, la question est beaucoup moins évidente.
MCP et agents IA : qui est réellement l’utilisateur ?
Le Model Context Protocol (MCP) permet notamment à un modèle ou à un agent IA d’interagir avec différents outils et sources de données au travers d’interfaces standardisées.
Un serveur MCP pourrait ainsi permettre à un agent de rechercher une information dans un CRM, d’interroger une base SQL, de consulter un référentiel documentaire ou de déclencher une opération dans une application métier.
Pour les équipes SAM, plusieurs questions vont alors devenir importantes :
Qui doit être licencié ?
Est-ce l’utilisateur qui formule la demande à l’agent ? L’identité technique utilisée par l’agent ? Les deux ? Faut-il comptabiliser l’ensemble des utilisateurs susceptibles de bénéficier indirectement des données issues de l’application ?
La réponse dépendra évidemment des règles contractuelles propres à chaque éditeur et à chaque produit.
Microsoft commence d’ailleurs à formaliser cette problématique avec ses offres dédiées aux agents. Dans sa documentation relative à Microsoft Agent 365, l’éditeur distingue notamment les agents des utilisateurs qui interagissent avec eux, les administrent ou les sponsorisent. Cette évolution montre que l’identification du bénéficiaire réel d’un service exécuté par un agent devient progressivement un sujet de licensing à part entière.
Le RAG pose une autre question : l’utilisation des données
Les architectures RAG – Retrieval-Augmented Generation ajoutent une problématique supplémentaire.
Dans un système RAG, les données provenant de documents ou d’applications peuvent être extraites, transformées en embeddings puis indexées dans une base vectorielle afin de fournir au modèle les informations nécessaires à la génération de ses réponses.
Le système source n’est alors pas nécessairement interrogé à chaque question.
Cela soulève plusieurs sujets qui devront être examinés au cas par cas :
-
les droits permettant d’extraire les données du système source ;
-
les conditions d’utilisation des API ;
-
les accès synchronisés ou désynchronisés selon la chaîne de traitements;
-
les accès aux données dites “live” au sein d’un application;
-
les droits de copie ou d’indexation des contenus ;
-
les restrictions éventuelles concernant l’utilisation des données pour l’entraînement ou l’amélioration d’un modèle ;
-
et la qualification de l’accès des utilisateurs qui bénéficient ensuite de ces informations au travers d’un agent.
Ces problématiques ne relèvent d’ailleurs plus uniquement du SAM. Elles se situent à l’intersection du licensing, de la gouvernance des données, de la sécurité, de la propriété intellectuelle et de l’architecture des systèmes d’information.
Vers un « SAM des agents » ?
L’un des enjeux des prochaines années pourrait donc être de faire évoluer l’inventaire SAM traditionnel.
Aujourd’hui, une organisation cherche généralement à connaître ses utilisateurs, ses terminaux, ses serveurs, ses machines virtuelles, ses installations logicielles et ses souscriptions Cloud.
Demain, il faudra probablement également inventorier :
-
les agents IA déployés dans l’entreprise ;
-
leurs propriétaires et leurs utilisateurs ;
-
les identités techniques qu’ils utilisent ;
-
les API auxquelles ils accèdent ;
-
les serveurs MCP auxquels ils sont connectés ;
-
les applications et bases de données interrogées ;
-
les sources utilisées par les systèmes RAG ;
-
et, enfin, les droits contractuels associés à chacun de ces accès.
Interprétation probable : le SAM pourrait ainsi progressivement évoluer d’une logique de Software Asset Management vers une gouvernance plus large des droits d’accès et de consommation des services numériques, qu’ils soient exercés directement par un humain ou indirectement par un agent.
Anticiper plutôt que constater
L’arrivée de l’IA ne remet donc pas en cause les fondamentaux du SAM. Elle renforce au contraire leur importance.
Inventorier, comprendre les usages, identifier les droits, documenter les architectures, rapprocher données techniques et données contractuelles et anticiper les évolutions des éditeurs restent les piliers d’une démarche SAM efficace.
Mais le périmètre évolue.
Après la virtualisation, le Cloud et le SaaS, les agents IA constituent probablement la prochaine évolution importante à laquelle devront s’adapter les organisations SAM / ITAM.
Pour les entreprises, l’enjeu sera d’intégrer suffisamment tôt ces problématiques aux projets IA. Car il sera toujours plus simple de prendre en compte une contrainte de licensing au moment de concevoir l’architecture que de découvrir ses conséquences financières lorsque plusieurs centaines ou milliers d’utilisateurs consommeront déjà, indirectement, les données et services concernés.
C’est précisément l’un des rôles du SAM : transformer une contrainte de licensing en élément de décision en amont des projets IT.