Le choix entre AWLC et TFP est aujourd’hui en tête des préoccupations de la plupart des responsables mainframe. Ce sont deux modèles de tarification du mainframe IBM, mais ils facturent de façon très différente. Quand IBM a lancé le Tailored Fit Pricing en mai 2019, le message principal était simple : des coûts prévisibles, avec un modèle de tarification aligné sur le comportement réel des charges de travail modernes. Plus de gestion des pics. Plus de mauvaises surprises sur la facture. Choisissez votre conteneur, signez un contrat pluriannuel et arrêtez d’optimiser la moyenne glissante sur 4 heures.
Tout cela est vrai. Et pour beaucoup d’entreprises, le TFP est le bon choix.
Mais la documentation d’IBM a tendance à minimiser un aspect de cette transition : ce que vous perdez en arrêtant de gérer les pics. Avant d’entrer dans la négociation du contrat TFP, vous devez comprendre les deux côtés de la balance.
Ce qui change vraiment quand vous passez d’AWLC à TFP
Sous AWLC (Advanced Workload License Charges), IBM calcule votre facture logicielle à partir de la plus haute moyenne glissante sur 4 heures (R4HA, Rolling 4-Hour Average) de consommation de MSU (millions d’unités de service) sur chaque période de facturation. Le R4HA est le chiffre qui compte le plus, et toute la gestion des coûts mainframe sous AWLC consiste à le maîtriser. Soft capping, planification des charges de travail, réglage du WLM (Workload Manager), allocation dynamique de la capacité : tous ces moyens réduisent votre R4HA, et donc votre facture.
Avec la Software Consumption Solution du TFP, le modèle de facturation change en profondeur. IBM ne facture plus sur le pic de consommation, mais sur la consommation cumulée de MSU sur l’année. Vous vous engagez sur un volume annuel de MSU au début du contrat et vous payez chaque mois 1/12 de cet engagement, quelle que soit votre consommation réelle du mois.
Cela paraît plus simple, et sur bien des points, ça l’est. Mais cela change l’économie de chaque décision de votre équipe mainframe.
Les vrais compromis
La plupart des contenus sur le TFP ressemblent au marketing d’IBM. Nous voulons donc vous donner une vision plus équilibrée.
| ✓ Avantages | ✗ Contreparties |
| Coût mensuel fixe et prévisible : la même facture chaque mois pendant toute la durée du contrat | Plus aucun moyen de réduire les coûts après la signature : le soft capping ne réduit plus votre facture |
| Plus de pression sur les périodes de pic : les traitements batch tournent quand l’activité en a besoin | Engagement de 3 à 5 ans, avec une baseline qui tend à augmenter avec le temps |
| Croissance à 50 % du prix de base : les MSU supplémentaires coûtent nettement moins cher | La négociation avec IBM est complexe et sous pression : la préparation est décisive |
| Extension des environnements de développement sans hausse proportionnelle des coûts | La baseline est fixée à partir de vos 12 derniers rapports SCRT : optimisez donc avant l’appel d’IBM |
| Mieux adapté aux charges de travail irrégulières, pilotées par API ou en cloud hybride | Les dépassements de consommation sont facturés en fin d’année : le suivi devient indispensable |
Le compromis qui compte le plus : perdre votre moyen de réduire les coûts
Sous AWLC, vous pouvez agir directement sur votre facture IBM. Par exemple, vous pouvez déployer le soft capping dynamique, optimiser vos règles WLM, déplacer des traitements batch et réduire votre R4HA. Vos rapports SCRT reflètent ces changements, et votre facture baisse. D’année en année, les équipes rigoureuses peuvent faire baisser leurs MLC (frais de licence mensuels).
Sous TFP, ce levier n’existe plus. Votre mensualité est fixée dès le premier jour du contrat. Vous ne pouvez pas la réduire en gérant la consommation pendant le contrat. La Software Consumption Solution facture sur les MSU cumulés : que vous lanciez ces charges de travail à 3 h ou à 15 h ne change rien à votre total annuel.
Ce n’est pas une raison d’éviter le TFP. Mais c’est une raison de préparer la transition à l’avance : sous TFP, la gestion des coûts se fait avant la signature, pas après. L’entreprise qui arrive à la négociation TFP avec un environnement déjà optimisé obtiendra une baseline plus basse et paiera moins sur toute la durée du contrat. Celle qui fait la transition sans cette préparation figera les conditions du contrat à un niveau plus élevé.
En résumé : sous AWLC, vous maîtrisez vos coûts en temps réel. Sous TFP, vous négociez vos coûts une fois et vous vivez avec ce chiffre pendant 3 à 5 ans. C’est avant la signature que votre travail d’optimisation des coûts compte vraiment.
Le TFP est-il adapté à votre entreprise ?
La réponse dépend de votre profil de charge, de vos ressources d’ingénierie et de la préparation déjà faite, ou que vous avez le temps de faire, avant d’ouvrir la discussion sur la baseline avec IBM.
| Le TFP vous convient si… | AWLC reste pertinent si… |
| Vos charges de travail sont de plus en plus irrégulières et imprévisibles : temps réel, pilotées par API, services numériques | Vous gérez vos charges de travail avec rigueur et vos pics R4HA restent bas de façon constante |
| Vous investissez dans de nouvelles applications mainframe, avec une croissance budgétaire prévisible | Votre profil de charge est stable, prévisible et dominé par le batch |
| La gestion des pics mobilise du temps d’ingénierie pour des gains de plus en plus faibles | Le travail d’optimisation avant transition n’est pas encore fait : signez après, pas avant |
| Vous prévoyez une forte extension de vos environnements de développement et de test | La souplesse du contrat compte plus que la prévisibilité de la facture |
| Vous allez vers le cloud hybride, avec des profils de charge plus variables | Vous êtes à moins de 12 à 18 mois de changements importants d’infrastructure |
Un point à surveiller : si votre profil de charge devient plus difficile à gérer sous AWLC (plus de transactions en temps réel, plus d’intégrations par API, une demande moins prévisible), le modèle de consommation du TFP réduira probablement les pertes d’efficacité opérationnelle, même à coût absolu comparable. À l’inverse, si votre équipe a beaucoup investi dans l’optimisation AWLC et en voit encore les résultats, l’intérêt de changer est plus faible.
Le facteur le plus important : votre fenêtre avant la transition
IBM utilise vos 12 derniers relevés Sub-Capacity Reporting Tool (SCRT) pour établir la baseline de votre Software Consumption Solution. Votre consommation annuelle cumulée de MSU en production devient le chiffre de départ de votre contrat, et votre mensualité en découle.
Les 12 mois qui précèdent votre négociation avec IBM sont donc la période où vous avez le plus de poids avant de passer au TFP. Chaque baisse de consommation MLC obtenue pendant cette fenêtre réduit directement le prix que vous paierez pendant les 3 à 5 années suivantes. Chaque mois de retard sur ce travail d’optimisation, c’est un mois de baseline plus élevée figé dans un contrat de long terme.
La méthode la plus rapide pour réduire votre baseline TFP, avec le moins de risque opérationnel, est le soft capping dynamique : une gestion automatisée de la capacité qui alloue les ressources des LPAR (partitions logiques) selon l’activité réelle, et non selon des limites de capacité définies de façon statique. Contrairement aux approches de planification manuelle, elle ne demande aucun changement d’horaire des traitements batch et n’a aucun impact sur les niveaux de service. Les résultats apparaissent dès le premier cycle SCRT mensuel.
Les mêmes principes s’appliquent aux entreprises sous CMP, avec un avantage : comme CMP regroupe la capacité de plusieurs systèmes dans un multiplex national, le partage automatisé des ressources dispose de plus de LPAR. En général, cela donne une baisse plus forte, en pourcentage, de la baseline MLC avant la transition.
Si vous ne retenez qu’une chose de cet article : donnez-vous au moins 12 mois de données SCRT optimisées avant de parler du TFP avec IBM. La baseline qu’IBM calcule à partir de ces relevés est le chiffre autour duquel vous négocierez, et sur lequel vous paierez pendant toute la durée de votre contrat.
Téléchargez notre ebook sur le TFP (IBM Tailored Fit Pricing, considerations & strategies). Nous y présentons toute la démarche d’optimisation, avec un exemple chiffré qui compare, en pratique, une transition optimisée et une transition non optimisée.
Questions fréquentes
AWLC vs TFP : quelle est la différence ?
L’AWLC (Advanced Workload License Charges) facture sur la plus haute moyenne glissante sur 4 heures (R4HA) de consommation de MSU de chaque période de facturation : la gestion des coûts consiste donc à maîtriser les pics. Le TFP (Tailored Fit Pricing), lancé par IBM en mai 2019, facture sur la consommation cumulée de MSU sur l’année, répartie en mensualités fixes. Sous AWLC, vous pouvez réduire activement vos coûts par le soft capping et la gestion des charges de travail. Sous TFP, votre facture mensuelle est fixée au début du contrat, et chaque MSU consommé compte dans votre engagement annuel, quel que soit le moment où il est consommé.
Le TFP est-il moins cher qu’AWLC ?
Pas forcément. La prévisibilité des coûts du TFP est un vrai avantage, mais le prix réel dépend de votre baseline négociée, calculée à partir de vos 12 derniers relevés SCRT. Les entreprises qui réduisent leurs MLC avant la négociation avec IBM entrent systématiquement dans le TFP avec une baseline plus basse, et donc un prix de contrat plus bas. Celles qui font la transition sans cette préparation figent pour 3 à 5 ans leur niveau de consommation actuel, qui peut être plus élevé que le besoin réel.
Comment IBM calcule-t-il ma baseline TFP ?
IBM demande vos 12 derniers relevés Sub-Capacity Reporting Tool (SCRT) au début des négociations TFP. Votre consommation annuelle cumulée de MSU en production devient la baseline de la Software Consumption Solution. Votre pic R4HA moyen pour les environnements de développement et de test devient la baseline de la Dev/Test Solution. IBM utilise ces deux baselines pour fixer le prix de votre contrat et projeter vos volumes de croissance engagés. C’est pourquoi les 12 mois qui précèdent la signature sont la période la plus décisive, financièrement, de toute transition vers le TFP.
Puis-je encore utiliser le soft capping pour réduire mes coûts après le passage au TFP ?
Non, pas de la même façon. Dans les modèles sub-capacity comme AWLC, le soft capping réduit votre pic R4HA, et donc votre facture. Avec la Software Consumption Solution du TFP, la facturation repose sur la consommation cumulée de MSU, pas sur les pics. Une fois sous TFP, le soft capping ne réduit plus votre coût annuel. Il peut aider à éviter les dépassements du conteneur Dev/Test, mais il ne peut pas réduire le coût principal de votre Software Consumption Solution après la signature. C’est l’un des compromis les plus importants à comprendre avant de s’engager dans le TFP.
Que se passe-t-il si je dépasse mon engagement de MSU sous TFP ?
Si votre consommation cumulée de MSU dépasse votre engagement annuel, IBM facture le dépassement en fin d’année, en général à 50 % de votre prix de base par MSU. Les dépassements coûtent donc plus cher que de rester dans le volume contractuel. Contrairement à AWLC, ils ne peuvent pas être limités en ajustant les pics de consommation en cours d’année. Les outils de projection qui prévoient votre trajectoire de MSU sur l’année à partir du réel cumulé sont indispensables pour repérer tôt un risque de dépassement.
Quelle est la durée d’un contrat TFP ?
Les contrats TFP durent en général de 3 à 5 ans, même si IBM s’est montré plus souple sur des durées plus courtes dans des négociations récentes. La durée compte, car votre baseline, fixée à la signature à partir de vos 12 derniers rapports SCRT, devient le point de départ de chaque renouvellement du contrat. Une baseline élevée figée pour 5 ans coûte nettement plus cher qu’une baseline plus basse, négociée après un vrai travail d’optimisation avant la transition. La durée du contrat rend la qualité de votre préparation avant signature encore plus importante sur le plan financier.
