IBM met en avant le modèle Tailored Fit Pricing (TFP) pour ses avantages : coûts fixes, plus de gestion des heures de pointe, moins de soucis de planification de capacité. Mais ce nouveau mode de facturation s’accompagne d’autres facteurs de coût cachés, difficiles à repérer tant qu’ils n’ont pas d’impact financier réel.
Parlons aujourd’hui de quelques risques TFP cachés pour les clients mainframe qui envisagent ce modèle, ou qui l’ont peut-être déjà adopté. En les connaissant, vous pourrez mieux les gérer.
Risque 1 : consommer à l’aveugle, et le payer
Le problème
Les équipes sous AWLC surveillent un seul chiffre : le pic R4HA (moyenne glissante sur 4 heures) du mois. Avec le TFP, au contraire, votre coût s’accumule en continu, et chaque MSU (million d’unités de service) consommé s’ajoute à votre facture annuelle. Avec ce nouveau modèle, vous n’avez plus besoin de surveiller la consommation aux heures de pointe, mais vous devez suivre la consommation cumulée.
C’est difficile, car les rapports SCRT ne donnent qu’une photo mensuelle, sans données en temps réel. Quand vous voyez un problème, il est déjà sur votre facture.
Pourquoi c’est plus difficile qu’il n’y paraît
IBM fournit des outils de surveillance natifs qui donnent des données en temps réel au niveau des charges de travail. Mais la surveillance elle-même consomme une quantité notable de MSU, qui s’ajoute à votre consommation totale.
Votre entreprise utilise peut-être déjà des outils d’observabilité généralistes pour surveiller les performances des applications. Mais ces outils ne sont pas conçus pour les données SMF du mainframe : soit ils ne savent pas se connecter aux sources de données qui comptent (enregistrements SMF, DCOLLECT, journaux IMS), soit ils demandent une intégration sur mesure pour le faire.
La solution : une observabilité native mainframe, sans surcharge
Zetaly Data Platform (ZDP) a été conçu précisément pour résoudre ce problème. ZDP collecte en continu les enregistrements SMF du mainframe, en n’utilisant que 0,2 % des ressources du mainframe. ZDP enrichit ensuite les données et montre la consommation par charge de travail, application et produit, sans augmenter le coût total de façon notable.
Les tableaux de bord ZDP sont mis à jour toutes les 15 minutes : vous voyez quasiment en temps réel où partent vos MSU. Pour les entreprises qui ont besoin de mises à jour plus fréquentes (par exemple pour surveiller une fenêtre batch critique), le tableau de bord de ZAC peut se rafraîchir toutes les 2 minutes, et il comprend des fonctions d’automatisation des charges de travail.
Pour les équipes qui n’ont pas de plateforme de business intelligence (BI) pour analyser et visualiser les données, Zetaly Service Intelligence (ZSI) fournit des tableaux de bord prêts à l’emploi et configurables, construits sur ZDP. Vous reliez ainsi les données de consommation informatique au contexte métier, sans expertise mainframe poussée.
Risque 2 : le coût caché du conteneur Dev/Test Solution
Le problème
Si votre contrat TFP comprend un conteneur Dev/Test Solution, vous êtes soumis à un mécanisme de facturation que presque personne ne lit attentivement avant de signer : l’effet cliquet du conteneur Dev/Test.
Avec la Dev/Test Solution du TFP, IBM définit une taille de conteneur pour vos charges de travail de développement et de test. Si le R4HA (Rolling 4-Hour Average, moyenne glissante sur 4 heures) de vos charges de dev/test dépasse un jour cette taille (même une seule fois, même pendant un traitement batch que personne ne pensait coûteux), le conteneur s’agrandit définitivement jusqu’à ce nouveau niveau record. Aucun mécanisme ne vous laisse le réduire ensuite.
Comment cela arrive en pratique
Les déclencheurs les plus courants sont les rafraîchissements de données de fin de trimestre (copie de volumes de données de production dans les environnements de test), les grandes campagnes de tests de non-régression, ou le déploiement d’une nouvelle application dont les charges de test n’ont pas été plafonnées avant leur lancement. Une seule erreur peut agrandir votre conteneur dev/test et votre coût récurrent pour le reste du contrat.
La solution : voir venir le pic
Une fois la limite du conteneur franchie, il n’existe pas de moyen simple de revenir en arrière. Il est donc important de savoir quand vous vous en approchez, pour agir avant de la franchir.
ZDP vous donne une visibilité sur la consommation des charges de dev/test, charge de travail par charge de travail. Si un traitement batch ou un test se rapproche de la limite de votre conteneur, vous le voyez assez tôt pour intervenir, en reportant le traitement ou en plafonnant les ressources.
ZAC ajoute une couche d’automatisation : il peut appliquer des plafonds souples (soft caps) aux charges de dev/test pour les empêcher automatiquement de dépasser les limites de ressources définies, sans qu’une personne doive intercepter chaque pic en temps réel.
Risque 3 : votre consommation d’aujourd’hui fixe votre baseline de renouvellement
Le problème
Sous TFP, la baseline de votre contrat n’est pas fixée à vie. Au renouvellement du contrat, IBM tire une nouvelle baseline des 12 derniers mois de données SCRT, avec le même calcul que pour votre baseline d’origine.
La plupart des clients TFP n’ont pas vraiment conscience de cet effet cumulatif. Si votre consommation a glissé vers le haut pendant le contrat (peu à peu, charge de travail par charge de travail, trimestre après trimestre), votre baseline de renouvellement sera plus haute que celle d’origine.
À l’inverse, les entreprises qui gèrent activement leur consommation pendant tout le contrat arrivent au renouvellement avec une baseline maîtrisée et peuvent baisser leur tarif.
Pourquoi la consommation dérive
Le passage d’AWLC au TFP apporte d’abord un peu plus de souplesse dans les façons de travailler, car la pression sur les pics de consommation disparaît. Résultat : les environnements de test s’agrandissent, les nouveaux projets obtiennent des ressources sans le même contrôle, et les applications qui étaient strictement encadrées sous AWLC tournent désormais avec moins de surveillance.
Aucune de ces décisions n’est déraisonnable en soi. Mais ensemble, elles font monter votre consommation mensuelle moyenne, et donc votre prochaine baseline.
La solution : faire du TFP une discipline continue, pas un événement ponctuel
Sous TFP, la gestion de la baseline est une pratique continue. Les entreprises qui tirent le meilleur du TFP gardent visibilité et gouvernance pendant toute la durée du contrat, et pas seulement dans les mois qui précèdent le renouvellement.
| Pratique | Ce qu’elle évite | Outil |
| Revue mensuelle de la consommation | Une dérive de la consommation qui passe inaperçue | Tableaux de bord ZDP |
| Plafonds et automatisation des charges de travail | L’extension du dev/test et la surconsommation des traitements batch | ZAC |
| Rationalisation des applications | Des charges de travail dormantes qui pèsent sur la moyenne mensuelle | ZDP + ZSI |
| Fenêtre d’optimisation avant renouvellement | Une négociation de renouvellement qui part d’une baseline élevée | ZAC + ZDP |
Les outils pour gérer le TFP
Ces risques ont un point commun : une visibilité réduite. Le modèle AWLC oblige les entreprises à surveiller le pic de consommation mensuel. Avec le TFP, ce mécanisme n’existe plus : les entreprises doivent donc instaurer des contrôles délibérés.
Les entreprises qui gèrent bien le TFP utilisent :
- ZDP pour la collecte continue des données SMF et la visibilité sur la consommation (avec seulement 0,2 % de surcharge sur le mainframe)
- ZSI pour les équipes qui ont besoin de tableaux de bord BI sans construire leur propre intégration
- ZAC pour l’automatisation des charges de travail, le soft capping et la protection du dev/test
Aucun de ces outils n’exige une grande équipe pour fonctionner. Il s’agit de remplacer la surveillance manuelle par des garde-fous automatisés, ce qui compte surtout pour les entreprises qui ont moins d’ingénieurs mainframe qu’il y a cinq ans.
📌 Sur l’observabilité en général : le marché de l’observabilité mainframe comprend des outils généralistes de grands éditeurs. Mais la plupart ont été conçus pour les environnements distribués, puis adaptés au mainframe. ZDP est conçu spécifiquement pour les données SMF de z/OS : aucune adaptation n’est nécessaire, et les 0,2 % de ressources consommées reflètent cette spécialisation. Sous TFP, où vos outils de surveillance s’ajoutent à la consommation facturée, cette différence compte.
Questions fréquentes
Quels sont les principaux risques TFP pour les clients mainframe ?
Les trois risques les plus courants sont : (1) la dérive de la consommation, avec des coûts qui s’accumulent peu à peu sans visibilité ; (2) l’extension du conteneur Dev/Test, où un seul pic de charge agrandit définitivement la taille de votre conteneur ; et (3) une consommation qui monte pendant le contrat, ce qui vous fait négocier le renouvellement à partir d’une baseline plus haute.
Les outils de surveillance d’IBM peuvent-ils suivre la consommation TFP ?
Oui, mais cela a un coût. Les outils de surveillance natifs d’IBM peuvent fournir des données de consommation par charge de travail. Mais ils consomment eux-mêmes beaucoup de MSU, ce qui, sous TFP, s’ajoute directement à votre facture mensuelle. Des outils spécialisés comme Zetaly Data Platform (ZDP) offrent une visibilité comparable en n’utilisant que 0,2 % des ressources du mainframe, et évitent cette surcharge.
Qu’est-ce que l’effet cliquet du conteneur Dev/Test dans le TFP ?
Avec la Dev/Test Solution du TFP, IBM fixe une taille de conteneur pour vos charges de travail Dev/Test. Si votre moyenne glissante sur 4 heures (R4HA) en Dev/Test dépasse un jour ce conteneur, même une seule fois, le conteneur s’agrandit définitivement jusqu’au nouveau pic. Il ne peut pas être réduit. La seule protection : voir venir le dépassement, et poser des plafonds de ressources automatiques pour l’éviter.
Comment fonctionne le renouvellement de la baseline TFP ?
Au renouvellement de votre contrat TFP, IBM recalcule votre baseline avec les 12 derniers mois de données SCRT de la période en cours. Si votre consommation mensuelle moyenne augmente pendant le contrat, votre nouvelle baseline et votre plancher de coût minimum seront plus élevés. La gestion de la consommation pendant le contrat compte autant que l’optimisation avant la transition.
ZDP est-il compatible avec les outils de BI existants ?
ZDP expose des données enrichies via des API, ce qui permet l’intégration avec Power BI, Excel et d’autres plateformes de business intelligence. Pour les entreprises sans plateforme de BI, Zetaly Service Intelligence (ZSI) fournit des tableaux de bord prêts à l’emploi et configurables, construits sur ZDP, qui couvrent les usages ITOps : surveillance des charges de travail, suivi des objectifs WLM et détection d’anomalies.
ZAC apporte-t-il encore de la valeur une fois le client passé au TFP ?
Oui, pour deux raisons. D’abord, les fonctions d’automatisation des charges de travail de ZAC réduisent la consommation cumulée de MSU, ce qui compte pour la gestion des coûts au quotidien comme pour l’optimisation de la baseline avant renouvellement. Ensuite, la fonction de soft capping de ZAC protège automatiquement contre l’extension du conteneur Dev/Test. Les équipes qui ont peu de personnel mainframe profiteront tout particulièrement de la capacité de ZAC à appliquer automatiquement les règles de consommation.
