Pourquoi il est indispensable de maîtriser son patrimoine Software

Les coûts logiciels sont souvent des coûts récurrents, portant sur de multiples produits et de multiples fournisseurs, avec des structures de prix complexes et difficilement comparables.

L'industrie du logiciel a fortement évolué depuis les années 80 et l'apparition des premiers liens entre capacité physique des machines et les prix des logiciels fonctionnant sur ces équipements. Aujourd'hui, la gestion efficace des éditeurs de logiciel reste un challenge pour l'ensemble des entreprises. On retrouve certains éditeurs qui portent traditionnellement une grande partie de la dépense chez beaucoup de clients : IBM, Microsoft, Oracle, SAP, CA, BMC, VMware, Adobe, SAS...

ISG constate que ce poste "logiciel" (achat, location, maintenance...) est supérieur à la dépense de matériels dans les budgets de production de l’IT, représentant jusqu'à 35% du budget de la production.

C'est la seule composante de coûts qui soit stable voire qui augmente au gré́ de l’évolution des produits et de leurs versions successives, année après année. Malheureusement, cette dépense échappe à toute maitrise dans de trop nombreux cas.

Enjeux et tendances du marché

L’acquisition de matériels est un processus bien compris et bien géré par les entreprises. Il s’agit plus souvent de budgets d’investissement, alors que les coûts logiciels sont souvent des coûts récurrents, portant sur de multiples produits et de multiples fournisseurs, avec des structures de prix complexes et difficilement comparables.

Historiquement, le Software Asset Management était un processus technique, le logiciel étant un bien immatériel complexe à gérer pour les services Achats.

Les raisons qui expliquent cette difficulté sont nombreuses. Parmi elles, on peut citer :

• Le transfert des commandes ou consommations de produits logiciels dans des entités métier (hors des entités DSI) qui ne fournissent pas de reporting sur ces dernières, au détriment de la maîtrise des volumes et des coûts. Dans ce schéma entropique, les achats sont décentralisés, le processus de commande et d’utilisation est distribué et il n’y a pas de gestion réelle centralisée.
• Le processus de sélection des logiciels et des vendeurs est souvent trop technique, reléguant le logiciel au statut d’outil technique sur lequel on ne peut agir en termes de gestion.
• La gestion des éditeurs et de leurs contrats de licence ou de maintenance était sporadique... ou inexistante.

 

Ces raisons amènent souvent à un constat d’échec : le coût total de possession (TCO) des logiciels n’est pas reconnu et donc pas géré par la majeure partie des entreprises (achats, licences, customisation, intégration, déploiement, maintenance, formation, impact sur la production en support et back-office, etc.)

Une tendance forte d’évolution se dégage aujourd’hui. Les acquisitions de logiciel dits  « classiques » – en CAPEX – diminuent, alors que les achats en mode souscription ou location – en OPEX – augmentent.

Enfin, on assiste également au développement d’une nouvelle bonne pratique dans l’acte d’achat ou de location des logiciels. La « sur-capacité » logicielle, c’est-à̀-dire les licences non utilisées, doit avoir un traitement spécifique dans les contrats, afin de ne pas payer au même prix ce qu’on ne consomme pas. Mais cela suppose que la métrologie du patrimoine logicielle soit complètement maîtrisée...

Le casse-tête des licences

Il faut donc bien comprendre que les éditeurs ont beaucoup d’imagination pour créer des modèles uniques qui rendent la comparaison compliquée avec des produits concurrents d’autres éditeurs. Un éditeur n’a pas forcément un seul modèle de pricing et il n’y a pas de modèle « préféré » ou « idéal ». Soit l’éditeur n’offre qu’un seul mode de licensing et le client est obligé dans ce cas d’accepter le modèle proposé, à moins de choisir un produit concurrent – s’il en a la possibilité opérationnelle et financière (migration de DB2 vers Oracle ? Migration d'Oracle vers SQL Server, passage en Open Source avec support ?). Soit l’éditeur offre plusieurs modes, et dans ce cas, le client doit réaliser des simulations – parfois très complexes – pour choisir le modèle le plus rentable.

Pour finaliser ce constat, il est vital de parler de la problématique de la virtualisation qui a considérablement déplacé les lignes du terrain du jeu ces dernières années. Cela touche premièrement le monde des serveurs, pour lequel la virtualisation augmente le risque de non-conformité. Mais cela touche aussi, le End-User Computing (Poste de Travail) avec le développement des solutions de VDI (Virtual Desktop Infrastructure) : HVD (Hosted Virtual Desktop) et de SBC (Server Based Computing).

Finalement la transition des modèles On-Premises vers un modèle Cloud est toujours un projet difficile.

Se référer au mode de contractualisation ?

Il faut savoir que l’on peut acheter ou louer les droits d’usage d’un logiciel. Les conditions opérationnelles et financières du support et de la maintenance peuvent être inclues dans cette action (achat ou location) ou être souscrites à part.

Aujourd’hui, les entreprises utilisent principalement 4 modes de contractualisation avec les éditeurs de logiciel :

Mode d’achat	Description	Avantages	Inconvénients
Achat de licences au fil de l’eau	On commande de nouvelles licences pour chaque nouveau besoin de déploiement	pas de surcoût à l’avance	besoin d’achat et de comptabilisation au cas par cas
Achat de quota de licences en avance (over-provisioning)	On achète à l’avance un certain nombre de licences en fonction des besoins et on n’achète des licences supplémentaires que quand le quota est atteint	prévision des coûts	besoin d’achat et de comptabilisation au cas par cas
Régularisation a posteriori	Mécanisme de type True Up / True Down, qui génère la facture en fonction de ce qui a été activé et / ou déployé	pas de contrainte en cours d’année	on découvre la mauvaise surprise sans être prévenu
Droit au déploiement de licences illimitées pour une entreprise et/ou un site	On peut déployer toutes les licences utiles…	facile à gérer	le prix de la redevance

 

Nonobstant cela ne suffit pas à optimiser réellement son patrimoine logiciel. L’entreprise doit pour cela mettre en place un certain nombre d’actions concrètes pour d’abord contrôler son patrimoine logiciel, avant de l’optimiser.