La facture de l’obsolescence s’invite dans vos dépenses IBM

Introduction

La gestion de l’obsolescence au sein d’une organisation fait écho dans bien des domaines. S’agissant des technologies de l’information, c’est le plus souvent avec les notions de cybersécurité et de continuité des services qu’elle raisonne. Pourtant, cette obsolescence peut avoir également des impacts sur des secteurs moins attendus, souvent par méconnaissance, que sont la conformité et les dépenses en licences logicielles.
Cet article traitera du cas de l’éditeur IBM, avec lequel la gestion de l’obsolescence des systèmes d’exploitation doit être traitée avec rigueur, sous peine de voir un risque financier majeur peser sur votre budget alloué aux licences de Big Blue.

Rappel sur quelques notions

Afin de mieux appréhender les enjeux dont il s’agit, il conviendra dans un premier temps de rappeler quelques notions propres à l’éditeur IBM. 

Les modes de tarification des licences de type PVU/VPC

Pour les détenteurs de contrats IBM, les clauses applicables du contrat cadre qui régissent vos droits d’usage seront par défaut celles présentes dans le contrat Passeport Advantage. Dans ce contrat figure une notion relative à la tarification des licences PVU (Processor Value Unit) et VPC (Virtual Processor Core). Il s’agit de licences pour des programmes dont la tarification s’appuie sur la configuration (Physique et/ou Virtuelle) de vos environnements qui hébergent et ou exécutent les dits programmes.
De façon très simplifiée, pour le calcul des PVU, il est nécessaire de comptabiliser les cœurs physiques et/ou virtuels des machines qui exécutent les programmes et d’appliquer un coefficient de pondération (Core Factor) pour obtenir le nombre de licences requises. 

La pleine capacité (Full Capacity) : Il s’agit de la tarification applicable par défaut. Un programme licencié en PVU, installé sur un environnement, qu’il soit physique ou virtuel, sera facturé sur la base du nombre de cœurs physiques de la machine, dans son intégralité. (Bien qu’il existe des contextes de partitionnement spécifiques dans lesquels des règles particulières s’appliquent, leurs définitions n’étant nullement nécessaire à la bonne compréhension de la problématique liée à l’obsolescence, ils ne seront pas traités dans cet article)  

La capacité partielle (Sub capacity) : Dans certains cas bien spécifiques, et sous réserve que des conditions particulières soient respectées, IBM accepte de comptabiliser les licences PVU sur la base de la capacité partielle des serveurs qui hébergent les programmes. Là encore, une façon simplifiée de voir la chose est de dire qu’il suffit de comptabiliser les cœurs virtuels qui hébergent ou exécutent les programmes et d’appliquer un coefficient spécifique pour obtenir le nombre de licences PVU nécessaires. Il est essentiel de comprendre que vous ne choisissez pas le mode de tarification applicable à l’achat des licences, ni même à la façon de comptabiliser les licences lors d’un contexte d’audit. Par défaut, IBM comptabilisera sur une base de Pleine Capacité. Cependant, si vous respectez toutes les conditions décrites dans le contrat Passeport Advantage, alors vous pourrez prétendre à un mode de comptage en Capacité partielle.

Les conditions applicables à la capacité partielle (sub capacity)

Il serait légitime de penser que le lien entre l’obsolescence des SI et ce qui a été dit jusqu’à présent semble obscur, voire inexistant, et pourtant. Comme cela a été dit précédemment, le mode de comptage en capacité partielle est soumis à conditions et lorsque l’on analyse en détail celles-ci, le rapprochement avec l’obsolescence va apparaitre insidieusement.

Ces conditions sont référencées dans le Passeport Advantage et disponibles sur le site de l’éditeur à cette adresse :
https://www.ibm.com/software/passportadvantage/subcaplicensing.html

Si vous souhaitez qu’IBM accepte votre mode de comptage s’agissant de vos licences PVU/VPC, vous devrez respecter les conditions suivantes :

• Utiliser un produit éligible
• Utiliser une technologie de virtualisation éligible
• Utiliser une technologie de processor éligible
• Avoir déployé la solution ILMT (ou autre produit équivalent négocié avec l’éditeur) dans sa dernière version et disposer de rapports trimestriels présentant un historique de deux ans.

Ce qui signifie que si une seule des conditions préalablement citées n’est pas remplie, IBM serait en droit de comptabiliser vos déploiements des programmes sur un mode de pleine capacité.

A noter :
Depuis le 10 mai 2022, Les licences PVU ne sont plus les seules à être concernées par la condition relative à ILMT. Les licences VPC (Virtual processor Core) sont désormais également soumises à l’obligation de devoir être suivies avec ILMT, les rapports manuels n’étant plus autorisés.

Analyse d’impact et risque financier
Pour bien comprendre les implications liées au mode de comptage applicable, la présentation d’un exemple reste le moyen de plus simple:
Votre organisation dispose de licences pour le produit Datastage (infosphere information Server Enterprise Edition) dont la référence pour les licences PVU est D0P1DLL. Supposons que vous disposiez de 700 PVU acquis au tarif en vigueur : 1 820 € / PVU soit un investissement initial de plus de 1,2M €.
Votre organisation a déployé la solution sur 4 machines virtualisées sur Vmware disposant au total de 10 cœurs virtuels. L’infrastructure VMware sous-jacente est composée d’un cluster de 4 hôtes de virtualisation « H » équipés chacun de deux processeurs Intel « P » de 20 cœurs physiques « C »). Le Core factor appliqué sera alors de 70.

Voici le nombre de licences requises en fonction du mode de comptage appliqué :

Maintenant, vous commencez à toucher du doigt l’impact que peut avoir le non-respect d’une des conditions d’application de la capacité partielle définies dans les clauses du Passeport Advantage.

A noter :
En contexte d’audit de licence, si l’éditeur constate qu’une des conditions n’a pas été respectée, il sera en droit de vous appliquer, en plus du comptage en mode pleine capacité, un cout forfaitaire lié à l’audit ainsi que des pénalités liées à l’arriéré de support sur le périmètre considéré pouvant aller jusqu’à 2 années de maintenance additionnelle.

La double peine de l’obsolescence 

Maintenant, si nous revenons sur les conditions énoncées, et plus précisément sur la seconde relative aux technologies de virtualisation, c’est ici que la notion d’obsolescence va apparaitre au-devant de la scène.

Le principe de base

S’agissant des technologies de virtualisation éligibles, IBM met à disposition la liste de toutes les technologies de virtualisation reconnues mais également de tous les Operating system sur lesquels les programmes IBM peuvent être comptabilisés en capacité partielle.

La dernière liste mise à jour est disponible à cette adresse :
http://public.dhe.ibm.com/software/passportadvantage/SubCapacity/Eligible_Virtualization_Technology.pdf

En d’autres termes, si vous avez déployé des programmes IBM que vous couvrez avec des licences PVU/VPC sur un environnement de figurant pas sur cette liste, vous ne pourrez pas prétendre à un mode de comptage en capacité partielle.

Pour comprendre la logique appliquée par IBM, lorsqu’un éditeur d’OS annonce la fin de support pour une version de son produit (Windows Server 2008/R2, RHEL 5.X…), IBM le sort de la liste des technologies éligibles environ 18 mois après (moyenne estimée). Une fois sortie de cette liste, vous disposez d’un délai de 180 jours pour remédier la situation. Passé ce délai, vous devrez comptabiliser vos licences en mode pleine capacité.

Ce qui signifie pour une organisation, que d’un jour à l’autre, elle voit passer sa situation de conforme à une situation à risque de plusieurs dizaines de millions, et ce, sans qu’il y ait eu la moindre action effectuée sur le parc.

Une situation subie

Pour nombre d’entreprises, le maintien de vieux systèmes d’exploitation peut être multifactoriel parmi lesquels nous retrouvons souvent :

• Applications métiers non supportées sur les versions d’OS supérieures
• Ressources insuffisantes pour préparer et effectuer la migration
• Délai et retard dans les plans de migration et de transition (Cloud)
• Contexte spécifique contractuel lié aux licences

Dans la majorité des cas, les organisations qui prennent le risque de maintenir des systèmes obsolètes doivent accepter les risques liés à la cybersécurité, l’absence de support de la part de l’éditeur, met se voit en plus pénaliser dans la facturation des licences des programmes qu’ils exécutent.

Prochains OS non éligibles annoncés

IBM met à disposition la liste des prochains systèmes d’exploitation qui vont être sortis de la liste des OS éligibles. Elle est consultable à cette adresse : 
https://www.ibm.com/support/pages/node/1079427

En 2022, les entreprises doivent faire face à de nouvelles problématiques liées aux systèmes suivants:

Pour les détenteurs de ces systèmes, il va être nécessaire d’investiguer sur la présence de logiciels IBM licenciés en PVU ou VPC. En cas de détection, des actions vont devoir être menées. Des exemples de remédiation seront présentées dans le chapitre suivant.

Windows Server 2012/R2

Microsoft l’a déjà annoncé, les systèmes Windows Server 2012/R2 ne seront plus supportés d’ici fin 2023. Ce qui signifie qu’IBM va probablement sortir de sa liste ces OS en fin 2024 ou courant 2025 au plus tard. Cela semble lointain, mais 24 mois, pour planifier une migration de systèmes d’exploitation, cela peut être extrêmement court.

Les entreprises vont devoir une nouvelle fois investir dans des ressources pour définir des stratégies et mettre en place les actions requises.

Quelles solutions, à quel prix ?

En fonction des contextes, les solutions pour remédier à la problématique des licences IBM en PVU/VPC vont dépendre de nombreux facteurs. Les actions et les coûts associés vont devoir se mesurer à l’aune du risque évalué.

Les décideurs statueront du niveau de risque jugé « acceptable » à maintenir ou lancer les plans de remédiation requis. Voici quelques exemples de solutions qui peuvent être mises en place.
Celles-ci sont classées par niveau de risque.  

Solution N°1 : Ne rien faire

Aussi étrange que cela puisse paraitre, c’est parfois la solution choisie. Des organisations ayant mesuré le risque, sachant que des environnements vont être décommissionnés prochainement, prennent le risque de ne rien changer. Cette solution peut parfois s’entendre, si l’on compare les coûts que représentent une migration comparée à l’estimation du risque établie.

Cependant, dans de tels cas, il est fréquent de constater que les facteurs suivants ont mal été évalués :

• Retards et délais de décommissionnement plus important que prévus
• Sous-estimation ou mauvaise évaluation du risque financier porté sur le périmètre (calcul de la pleine capacité erroné)

Une mauvaise combinaison des facteurs présentés ci-dessus peut se transformer en cocktail explosif en cas d’audit. L’impossibilité de prédire la date du prochain audit, les paiements des arriérés et le chiffrage en pleine capacité peut entrainer l’entreprise dans une situation fort délicate face à l’éditeur.

Solution N°2 : Isoler le périmètre

C’est la solution la moins onéreuse et la première envisagée dans ce type de situation. L’objectif va être de rassembler toutes les machines virtuelles non éligibles dans un seul cluster d’hôtes physiques, de comptabiliser l’ensemble des machines en pleines capacité et de provisionner le risque évalué en attendant de régler la situation...plus tard.

Cette stratégie visant à « limiter la casse » se justifie dans des contextes où il est impossible de migrer vers une autre version plus récente du système d’exploitation. Dans ce cas, il est possible de construire une cible, en fonction des licences détenues et du risque financier jugé « acceptable », qui portera l’environnement licencié en pleine capacité.

Cette solution permet certes de circonscrire un périmètre à risque, mais elle présente l’inconvénient de devoir modifier son infrastructure sur la base du seul critère de gestion de licences, ce qui est loin d’être le critère prépondérant dans la construction d’une architecture. De plus, elle entraine de devoir dédier un cluster, ce qui implique l’acquisition de licences VMware supplémentaires (Vcenter) uniquement pour palier à l’obsolescence d’un système d’exploitation.

Solution N°3 : Migrer sur du physique

Dans le cas où l’on dispose d’un faible nombre de machines virtuelles, la solution de migrer les environnements sur un serveur physique est parfois adoptée. Probablement celle qui limite le plus le risque, elle comporte cependant bien des contraintes qui laissent les entreprises adopter cette solution qu’en dernier recours :

• Disposer ou acquérir un matériel avec peu de cœurs physiques
• Administrer un nouveau périmètre non centralisé, ce qui va à l’encontre de la stratégie de virtualisation mise en place
• Migration et réinstallation complète des applications, re paramétrage du réseau, des systèmes de stockage etc

Solution N°4 : l’IASP

Dans une situation où aucune solution ne semble acceptable, une organisation pourrait être tentée par prendre les devants, et en toute bonne foi contacter l’éditeur pour demander un accompagnement dans la remédiation.

IBM propose à ses clients un « programme » dans lequel une tierce partie agréée pour ce type d’accompagnement contractualisera avec l’entreprise un accord (le plus souvent pluriannuel) permettant à l’entreprise de se remettre en conformité. Il s’agit de l’IBM Authorized SAM Provider Offering (IASP). Les 4 tierces parties autorisées à ce jour à proposer de tel contrat sont les cabinets Deloitte, KPMG, E&Y et Anglepoint (« Authorized SAM Provider »).

Pendant toute la durée du contrat, l’une d’elle va accompagner l’entreprise en procédant à des inventaires complets du périmètre IBM et fournir un plan de remédiation. L’avantage pour le client sera alors d’être accompagné dans toutes les actions à mener permettant que le comptage soit effectué en capacité partielle et qu’il n’y aura pas de pénalités liées à l’arriéré de maintenance.

Avant d’envisager cette solution qui semble présenter que des avantages, il est essentiel d’en présenter également le revers de la médaille. L’entreprise, un fois engagée dans le processus, va devoir transmettre toutes les informations demandées (Rapports d’usage, rapports ILMT, configuration des environnements etc) et ce de façon périodique. Un rapport sera alors établi et si des licences sont manquantes, une demande de régularisation suivie d’un bon de commande sera transmis et devra être réglé sous 30 jours. Nous retrouvons alors beaucoup de similitudes avec un audit classique, à la différence que celui-ci est permanent, le temps du contrat.

De plus, en cas d’impossibilité de migration, si vous avez souscrit à des conditions spécifiques dans le cadre de l’IASP vous permettant de bénéficier d’un comptage en capacité partielle, vous serez donc contraint de devoir maintenir le programme pour une durée indéterminée. Programme dans lequel vous serez dans tous les cas contraint tôt ou tard, de devoir migrer vos OS non éligibles ou de les comptabiliser en plein capacité.

Conclusion

La gestion de l’obsolescence des systèmes d’information reste un enjeu qui dépasse la simple problématique du « vieillissant ». Elle représente un ensemble multifactoriel impliquant des domaines extrêmement variés. Dans un contexte contractuel IBM, l’impact financier d’une mauvaise gestion peut devenir majeur.

Malgré les contraintes liées au maintien de tels systèmes, les entreprises n’ont pas d’autres choix que de mener des actions pour réduire les risques de non-conformité liés à leur infrastructure. Les solutions, quand elles existent, sont complexes à élaborer et doivent être élaborées dans le cadre d’une démarche bien définie.

C’est pourquoi il est essentiel de disposer en amont de toutes les informations requises, d’avoir mesuré correctement le risque, de bien saisir tous les enjeux contractuels de votre organisation afin de pouvoir définir la bonne stratégie adaptée à un contexte spécifique.