Résumé

  • Google Cloud Modernize rassemble évaluation des coûts, analyse du code et des dépendances, outils de migration et services Google Cloud. Agentic Quick Estimator peut produire une projection de coût total pour Compute Engine à partir d’exports d’inventaire VMware et de données d’infrastructure.
  • Cette projection dépend des actifs recensés, du dimensionnement, de la région, des licences et d’autres hypothèses. Elle ne prouve ni migration achevée, ni acceptation en production, ni coût total de transition, ni économie réalisée par le client.
  • Le test commercial est une chaîne vérifiable : inventaire source contrôlé, cible et hypothèses validées par le client, bascule réussie, charge de travail acceptée et facture après migration rapprochée d’une base comparable.

L’annonce du 6 octobre de Google Cloud Modernize repose sur une promesse séduisante : raccourcir une feuille de route de modernisation qui peut s’étaler sur plusieurs années grâce à l’assemblage d’outils d’évaluation, d’analyse de code et de migration assistés par l’IA. La logique commerciale est plausible. Une entreprise qui recense plus rapidement ses serveurs, cartographie leurs dépendances et compare les configurations cibles peut décider plus tôt quoi déplacer. Mais la question économique la plus difficile vient après.

L’estimation résiste-t-elle aux détails des applications et le système accepté coûte-t-il moins cher une fois la transition achevée ?

L’offre réunit plusieurs promesses qu’il faut distinguer. Google dit que son Agentic Quick Estimator de Migration Center est disponible de manière générale : il exploite notamment des exports RVTools et des données d’infrastructure pour projeter le coût total de possession d’un environnement Compute Engine. Le nouveau Modernization Hub analyse le code et cartographie les dépendances des applications Java, .NET et mainframe. Le nouvel agent de migration EKS-to-GKE est, lui, en préversion publique ; Google le présente comme un outil de découverte, traduction de manifestes Kubernetes et cartographie du stockage et du réseau, avec des étapes d’approbation humaine. Ces fonctions interviennent à des étapes distinctes — chiffrer, comprendre, traduire, valider — et aucune ne constitue à elle seule une mise en production. (Annonce Google Cloud du 6 octobre)

Toute estimation hérite de ses hypothèses

La valeur décisionnelle du TCO dépend de la qualité de l’inventaire source et des choix de destination. La documentation Google permet de saisir manuellement les totaux de VM, de vCPU, de mémoire et de stockage, ou de charger un export RVTools. L’utilisateur choisit ensuite la région, la famille de machines et le stockage cible. Le rapport compare l’environnement source fourni à une configuration Google Cloud modélisée. En l’absence de données de performance, Migration Center peut recommander un dimensionnement selon une stratégie sélectionnée et indique les actifs estimés plutôt que mesurés. C’est utile pour planifier, mais il s’agit d’un modèle, pas d’une consommation facturée. (Documentation Quick TCO Estimator ; documentation des rapports TCO)

Cette distinction pèse sur la position de négociation de l’acheteur. Une prévision peut aider la finance à décider de financer une phase de découverte ou un pilote. Elle ne démontre pas, à elle seule, que la machine choisie convient aux pointes de charge, que toutes les dépendances applicatives sont recensées ou que le coût d’exploitation diminuera après l’ingénierie, les tests et la bascule.

Une comparaison solide exige des niveaux de service et des périodes de charge équivalents, ainsi que les coûts importants pour le client : consommation source et cible, licences, réseau et stockage, travail de migration, éventuelle période de fonctionnement parallèle, support et voie de sortie. Le rapport peut en inclure certains selon les données et options saisies ; il faut examiner le document concret plutôt que supposer qu’un chiffre unique couvre tout.

La documentation de Migration Center décrit une évaluation de compatibilité technique, pas un certificat d’acceptation commerciale. « Bonne compatibilité » signifie qu’aucun obstacle technique n’a été détecté selon les conditions appliquées aux données recueillies ; « compatibilité avec effort » signale du travail supplémentaire possible. Google recommande également d’inventorier les clusters et les charges, d’étudier les dépendances et les processus d’exploitation, de choisir une stratégie, de fixer le calendrier et de valider le plan. Ce ne sont pas des formalités : c’est le travail qui transforme une recommandation en changement sûr et chiffrable. (Évaluation de compatibilité Migration Center ; guide de migration EKS-to-GKE ; planification d’une migration)

Accélérer une étape ne termine pas le parcours

L’agent EKS-to-GKE illustre cette limite. Google indique qu’il peut traduire les manifestes Kubernetes et cartographier le stockage et le réseau, avec validation humaine et protection des identifiants en mémoire. Cela peut réduire les tâches répétitives et rendre le parcours plus visible. Le statut de préversion publique invite aussi à considérer l’outil comme une capacité en développement, et non comme un substitut universel aux tests propres à chaque application.

Politique réseau, sémantique du stockage, observabilité, identité, objectifs de fiabilité, transfert des données et procédures de mise en production peuvent toujours déterminer si un service est prêt. Google ne publie ni le nombre de migrations de production réalisées avec le nouvel agent, ni son taux d’erreur ou de retour arrière, ni les gains de temps et d’argent par client.

Les exemples clients de l’annonce donnent du contexte, pas la preuve du lancement. Google affirme que NetEase Games a précédemment réduit ses coûts de serveurs de 40 % et son délai de montée en charge en période de pointe de plusieurs heures à cinq minutes grâce à des services sur GKE. Le billet n’attribue pas ce résultat à Google Cloud Modernize ou au nouvel agent EKS. Il s’agit d’un résultat rapporté pour une implémentation GKE, pas d’une mesure des outils annoncés en octobre.

La même discipline s’applique au mainframe, à VMware et à la modernisation applicative. L’analyse de code peut révéler une architecture et des dépendances ; un fonctionnement en double peut comparer les résultats avant bascule ; l’environnement cible peut fournir de la capacité. La valeur n’apparaît que si le comportement attendu est préservé et que le coût d’exploitation baisse, ou si les nouvelles capacités justifient l’écart. « Raccourcir la feuille de route » reste donc une hypothèse sur le temps d’ingénierie, pas une baisse observée du coût total.

L’acheteur a besoin d’un grand livre qui survive à la bascule

Google fournit l’estimateur et les services de destination ; le client apporte une grande partie de l’inventaire, des priorités applicatives et de l’approbation. Des partenaires peuvent réaliser une partie du travail. Cette répartition est efficace lorsque les responsabilités sont explicites. Elle devient plus difficile à évaluer lorsque le fournisseur qui modélise la cible vend aussi la capacité recommandée et que le client ne peut pas reproduire les hypothèses. Cela ne prouve ni conflit ni estimation erronée : cela justifie de conserver les entrées, les hypothèses versionnées et une base indépendante.

La mesure doit continuer après le déploiement. Pour chaque charge, conserver le profil de demande source, la configuration cible, le traitement des licences, les coûts de migration et de fonctionnement parallèle, les critères d’acceptation, le périmètre de support et la facture réelle. Comparer à demande, latence, disponibilité, stockage et région équivalents lorsque c’est possible. Si la migration modifie le service, signaler ce changement au lieu d’imputer chaque écart de facture à la plateforme.

La ligne de calcul peut baisser tandis que les coûts de données, de réseau ou de support augmentent ; une livraison plus rapide peut aussi avoir de la valeur même si la facture directe reste similaire. Un suivi poste par poste rend les deux résultats visibles.

Google Cloud Modernize peut réduire le coût de la décision et de la préparation. L’annonce ne montre pas à quelle fréquence cette accélération aboutit à une migration de production réussie ou à un meilleur résultat économique. Tant que les clients ne relient pas une base source vérifiée aux charges acceptées et aux coûts réalisés, ces outils offrent un chemin plus rapide vers une hypothèse — pas la preuve que la migration est rentable.

Sources