Google Cloud rejette le big bang du mainframe au profit d’une trajectoire de migration guidée par l’IA

Google Cloud a présenté une alternative en quatre étapes aux migrations risquées de mainframes, combinant analyse par IA, génération de code, conversion des données et validation parallèle avant la bascule.

La proposition remet en cause un choix bien connu. Les entreprises peuvent continuer à maintenir des systèmes vieillissants, ou tenter une migration de grande ampleur dont les dépendances ne deviennent visibles qu’une fois le travail engagé. Google soutient qu’aucune de ces options ne résout le problème le plus difficile : comprendre ce que fait réellement le système existant.

Sa réponse relie Mainframe Assessment Tool, Gemini CLI, Mainframe Connector et Dual Run en un processus continu. Les équipes commencent par reconstituer les règles métier et les dépendances. Elles construisent ensuite des applications cloud à partir d’exigences examinées, déplacent les données concernées et comparent les deux environnements sous des charges de travail réelles.

Cette séquence en fait davantage qu’une nouvelle annonce de conversion de code. L’enjeu principal oppose la modernisation itérative à la migration big bang, et non l’infrastructure cloud au matériel mainframe.

Google doit également faire face à des alternatives bien établies. IBM applique l’IA tout en préservant un rôle central pour IBM Z. AWS promeut un service agentique qui relie les exigences et le code générés aux sources mainframe. Chaque fournisseur reconnaît que la génération de code seule ne permet pas de déterminer si un système de remplacement est correct.

La question essentielle n’est donc pas de savoir si Gemini peut traduire du COBOL. Il s’agit de déterminer si le workflow connecté de Google peut préserver des décennies de comportements métier cachés tout en permettant aux entreprises de se moderniser par étapes maîtrisables.

Google Cloud transforme quatre outils en une trajectoire de migration

Le changement important réside dans le lien entre l’évaluation, la génération, le déplacement des données et la validation en production.

Le cadre de modernisation de Google commence par la rétro-ingénierie. Mainframe Assessment Tool examine le code source, les structures de bases de données, les moniteurs transactionnels, les configurations d’ordonnanceurs et les relations entre les actifs.

Il prend en charge les programmes COBOL, les copybooks, les jobs JCL, les procédures, les inclusions et les artefacts associés. L’outil utilise Gemini pour générer des résumés, des spécifications techniques et des règles métier proposées à partir de ces éléments.

Les règles métier sont les politiques intégrées à une application, telles que les conditions d’éligibilité, les calculs d’intérêts ou les décisions de routage des transactions. Elles sont importantes parce que le comportement observable d’un ancien programme dépasse souvent sa documentation encore disponible.

Google indique que les équipes peuvent examiner, filtrer et valider les règles extraites avant de les exporter. Ce contrôle humain distingue la proposition d’une simple instruction consistant à traduire chaque ligne en Java ou dans un autre langage moderne.

L’évaluation peut également diviser un parc applicatif en domaines métier et en unités migrables plus petites. Une unité migrable est un ensemble délimité de programmes, de données et de dépendances pouvant être déplacé conjointement sans perturber les services adjacents.

Cette partition constitue la base d’un programme itératif. Une banque pourrait isoler un flux de reporting avant de modifier l’autorisation des paiements. Un assureur pourrait déplacer un service de traitement de documents tout en laissant le règlement des sinistres sur le mainframe.

Après l’évaluation, Gemini CLI prend en charge l’ingénierie prospective. Les équipes utilisent ainsi des exigences validées pour planifier une architecture cible et générer un nouveau code, au lieu de considérer l’ancienne base de code comme la conception cible.

Le workflow peut proposer des modèles de données et des services couvrant Cloud Run, Google Kubernetes Engine, Compute Engine, BigQuery, Spanner, AlloyDB et Cloud SQL. Ces propositions nécessitent toujours un examen architectural, car une recommandation générée n’est pas une décision opérationnelle.

Mainframe Connector traite un autre problème fréquemment sous-estimé. Il copie et convertit les données mainframe, y compris les enregistrements encodés en EBCDIC, dans des formats utilisables par les services Google.

EBCDIC est un encodage de caractères associé aux environnements mainframe IBM. Le convertir correctement exige davantage qu’un changement de représentation textuelle, car les enregistrements peuvent contenir des décimales compactées, des structures de copybooks et des conventions propres aux applications.

Dual Run complète la boucle proposée. Il exécute les charges de travail dans l’environnement mainframe existant et dans l’environnement cloud, puis compare leurs résultats avant la bascule en production.

Le processus connecté modifie l’endroit où les équipes placent leur confiance. Au lieu de se fier à une conversion ponctuelle, elles accumulent des preuves tout au long de la découverte, de l’examen des règles, de l’implémentation, des tests de données et de l’exécution parallèle.

C’est l’affirmation centrale de l’événement. Google présente la modernisation comme un système contrôlé de preuves, et non comme un projet de transformation unique.

Pourquoi la modernisation des mainframes n’est pas un travail de traduction de code

Une conversion syntaxiquement correcte peut tout de même reproduire le mauvais système métier.

Les grands parcs de mainframes se comportent rarement comme des collections ordonnées d’applications indépendantes. Un job batch nocturne peut mettre à jour des données consommées par une transaction en ligne le lendemain matin. Un copybook partagé peut définir des enregistrements utilisés dans plusieurs unités métier.

Certaines dépendances se trouvent dans le code. D’autres résident dans les ordonnanceurs, les conventions de bases de données, les procédures d’exploitation ou les connaissances des employés qui maintiennent une charge de travail depuis des décennies.

La traduction directe du code constitue donc un modèle incomplet. Un modèle de langage peut produire du Java plausible à partir d’une routine COBOL, tout en ne comprenant pas pourquoi cette routine s’exécute après un autre job. Il peut également préserver une logique dont l’entreprise ne veut plus.

Le risque inverse est tout aussi sérieux. Un remplacement généré pourrait simplifier un comportement apparemment redondant mais qui gère une exception réglementaire obscure. Cette défaillance pourrait n’apparaître que lors d’une transaction rare ou d’un processus de fin de trimestre.

La conception de Google, qui privilégie l’évaluation initiale, tente de rendre ces relations inspectables. Sa documentation indique que l’outil produit des arbres d’appels, des rapports de dépendances, des résumés de règles métier et des unités migrables proposées.

Le système d’évaluation prend également en charge un serveur MCP, qui permet aux agents IA d’interroger les données d’évaluation via le Model Context Protocol. MCP est une interface standard permettant de connecter les modèles à des outils externes et à un contexte structuré.

Cette architecture donne à Gemini davantage qu’un dossier de fichiers source. Il peut travailler avec des relations découvertes, des spécifications examinées et des règles métier liées à un domaine applicatif particulier.

Toutefois, un contexte plus riche ne garantit pas une interprétation exacte. Les spécifications générées peuvent omettre des cas limites, et l’analyse statique ne peut pas observer chaque dépendance créée par une configuration à l’exécution ou des opérations externes.

L’examen humain reste donc un élément du mécanisme. Les experts métier doivent déterminer si une règle métier proposée est valide, obsolète, incomplète ou mal comprise.

Cela crée une contrainte pratique pour les entreprises confrontées à l’attrition de leurs effectifs. Le workflow exige des opérateurs expérimentés précisément lorsque leurs connaissances sont les plus difficiles à remplacer. L’IA peut organiser leur examen, mais elle ne peut pas reconstituer rétrospectivement une mémoire institutionnelle manquante.

L’approche de Google modifie également la finalité du code existant. Au lieu de traiter chaque instruction comme un élément à préserver, les équipes peuvent considérer le parc comme une preuve du comportement métier recherché.

Cette distinction favorise une refonte cloud native. Un moniteur transactionnel n’a pas besoin d’un équivalent littéral si un service managé peut satisfaire la même exigence examinée. Un processus batch peut devenir un service événementiel lorsque les contraintes de synchronisation et de cohérence le permettent.

Toutefois, la refonte élargit la charge de validation. Plus l’architecture cible s’éloigne de l’implémentation d’origine, moins la comparaison ligne par ligne est utile.

Les équipes doivent comparer les résultats, les effets de bord, les délais, l’intégrité des données et la reprise après défaillance. C’est pourquoi Dual Run est central, et non facultatif, dans le discours de Google.

La promesse n’est pas une traduction parfaite. C’est une chaîne traçable allant des preuves héritées aux règles examinées, à l’implémentation générée et à une équivalence mesurée.

Le véritable enjeu oppose la modernisation itérative au big bang

L’argument le plus solide de Google est organisationnel : des unités de migration plus petites limitent les conséquences de l’incertitude.

Une migration big bang concentre de nombreuses hypothèses dans une seule bascule. Les équipes doivent comprendre les dépendances, transformer le code, déplacer les données, tester les interfaces, former les opérateurs et préparer des procédures de retour arrière sur un périmètre étendu.

Une seule dépendance mal comprise peut retarder l’ensemble du programme. Pire encore, un défaut peut atteindre la production seulement après que l’environnement d’origine est devenu difficile à restaurer.

La modernisation itérative réduit ce rayon d’impact. Les équipes peuvent choisir un domaine délimité, documenter ses relations, construire une implémentation cible et la valider tandis que les charges de travail voisines restent inchangées.

Cela ne simplifie pas la modernisation. Cela modifie la manière dont l’échec se manifeste.

Un problème découvert lors d’une unité de migration peut améliorer les règles d’évaluation pour l’unité suivante. Les écarts de test peuvent révéler des comportements non documentés avant que l’entreprise ne s’engage dans une bascule plus large.

Dual Run fournit le pont opérationnel. Le précédent modèle de test parallèle de Google maintient le mainframe comme système principal tandis qu’une copie cloud exécute la même charge de travail en tant que système secondaire.

La sortie cloud peut ensuite être comparée au résultat établi. Des différences répétées révèlent des défauts dans la logique transformée, la conversion des données ou les hypothèses environnementales.

C’est particulièrement pertinent pour les systèmes à forte intensité transactionnelle. Un test unitaire peut vérifier un calcul connu, mais il ne peut pas reproduire chaque interaction entre les modèles d’entrée réels, les conditions d’ordonnancement et les intégrations en aval.

L’exécution parallèle fournit des preuves plus larges sans accorder immédiatement au nouveau système l’autorité de production. Les équipes peuvent définir des seuils d’acceptation, enquêter sur les différences et répéter les tests avant de transférer la responsabilité.

Le compromis est une coexistence prolongée. L’exploitation de deux environnements nécessite une synchronisation, une supervision, des contrôles contre le traitement en double et une décision claire sur le système responsable de chaque sortie.

Les coûts peuvent également se chevaucher pendant la transition. Google n’élimine pas cette charge opérationnelle. L’entreprise affirme que cette charge offre une voie plus sûre qu’un événement tout ou rien.

Le modèle incrémental soulève aussi des questions de gouvernance. Les équipes ont besoin de règles pour choisir les unités de migration et décider du moment où une application a démontré une équivalence suffisante.

Elles doivent suivre quelles règles métier ont été acceptées, qui les a approuvées, quelles preuves de test les étayent et ce qui a changé après validation. Sans cet historique, le travail itératif peut créer un parc hybride fragmenté.

La discipline architecturale est importante ici. Une succession de projets cloud isolés peut reproduire la complexité des mainframes au travers de nouveaux services, files d’attente, bases de données et interfaces non documentées.

Les outils de Google peuvent cartographier et générer des artefacts, mais une entreprise a toujours besoin d’une architecture cible cohérente. Elle a également besoin d’un plan de retrait pour chaque composant mainframe remplacé par le cloud.

L’approche réussit lorsque l’itération produit une simplification cumulative. Elle échoue lorsque chaque unité migrée ajoute un nouveau pont permanent vers le parc existant.

C’est pourquoi l’enjeu n’oppose pas la vitesse à la prudence. Un big bang précipité peut échouer de manière spectaculaire, tandis qu’un programme incrémental sans fin peut échouer silencieusement.

La mesure qui compte réellement est une capacité métier opérationnelle achevée. Chaque unité de migration doit atteindre une exploitation en production validée et supprimer la responsabilité héritée correspondante.

Google Cloud affronte IBM et AWS selon des modalités différentes

Les trois fournisseurs utilisent désormais l’IA, mais ils divergent quant à l’emplacement de la charge de travail modernisée et à la manière d’établir l’équivalence.

La position d’IBM part de la valeur persistante du mainframe. Son watsonx Code Assistant for Z prend en charge la découverte, l’explication, la refactorisation, la génération de code, l’optimisation et la transformation, tout en conservant IBM Z comme environnement d’exécution important.

IBM indique que son assistant peut expliquer du COBOL, PL/I, REXX, Assembler et JCL. Il peut également refactoriser certains programmes en services modulaires ou transformer du COBOL en Java orienté objet.

Les outils de modernisation par IA de l’entreprise incluent des tests unitaires automatisés visant l’équivalence sémantique. Ce terme signifie que le nouveau code doit produire le même comportement attendu que l’original, même si sa structure change.

Cette voie peut convenir aux entreprises qui souhaitent améliorer leurs pratiques de développement sans engager toutes leurs charges de travail vers un cloud hyperscale. Elle permet aussi aux équipes de moderniser autour d’un mainframe plutôt que de considérer la plateforme comme une échéance.

AWS adopte une position plus proche de la destination cloud de Google, mais son message actuel met l’accent sur l’exécution agentique et la traçabilité. AWS Transform for mainframe couvre l’évaluation, l’extraction des règles métier, les exigences, la génération de code, les tests et le déploiement.

AWS affirme que chaque sortie générée peut être retracée, via les exigences, jusqu’au code source d’origine. Son workflow agentique s’intègre également à des agents de codage tels que Kiro et aux environnements de développement existants par le biais de protocoles ouverts.

Cette traçabilité vise le même déficit de confiance que le Dual Run de Google. Elle fournit aux réviseurs une piste d’audit montrant l’origine d’une exigence ou d’un composant généré.

La différenciation de Google repose sur l’association d’une évaluation contextualisée, de la conversion des données et d’une validation parallèle au niveau de la charge de travail. Gemini aide à la compréhension et à la génération, tandis que Dual Run teste le comportement par rapport au système de référence.

Il ne s’agit pas de catégories de produits clairement séparées. IBM propose également des fonctions de découverte et de test. AWS revendique aussi une validation automatisée de l’équivalence fonctionnelle. Chaque fournisseur étend son offre sur l’ensemble du cycle de vie.

La pression concurrentielle se déplacera donc vers les preuves de mise en œuvre. Les acheteurs doivent savoir quels langages, ordonnanceurs, bases de données, systèmes transactionnels et formats de données chaque workflow prend en charge dans leur environnement.

Ils doivent également distinguer les capacités du produit de la prestation de services. Les programmes mainframe impliquent souvent des intégrateurs de systèmes, des experts internes, des spécialistes fournisseurs et des années d’historique applicatif.

Aucun modèle ne fonctionne indépendamment de cette structure de prestation. L’IA peut réduire l’analyse manuelle, rédiger des spécifications et générer du code, mais les décisions d’intégration restent propres à chaque environnement.

La dépendance fournisseur constitue un autre point à considérer. Une architecture générée peut favoriser les bases de données, plateformes de calcul, systèmes de supervision et services d’IA d’un seul fournisseur.

Cet alignement peut simplifier le déploiement. Il peut aussi augmenter les coûts de changement lorsqu’une entreprise modifie ultérieurement sa stratégie cloud ou conserve des charges de travail sur plusieurs environnements.

Les entreprises devraient donc évaluer les artefacts, et pas seulement les démonstrations. Des règles exportables, des spécifications lisibles, des tests portables et des validations traçables importent au-delà de la transformation initiale.

Le marché converge vers une modernisation assistée par l’IA. La concurrence non résolue porte sur l’endroit où les humains vérifient le travail, la manière dont les fournisseurs mesurent l’équivalence et la plateforme qui détient le résultat.

Ce que le workflow d’IA de Google Cloud ne peut toujours pas garantir

Le workflow réduit certains risques de migration, mais il n’établit pas que les règles métier générées ou le code cible sont corrects.

La première incertitude apparaît lors de la découverte. L’analyse statique peut identifier les relations dans le code source et les appels déclarés, mais le comportement dynamique peut dépendre de valeurs d’exécution, de choix d’opérateurs ou de systèmes externes.

Un résumé généré par IA peut aussi paraître plus certain que ne le permettent ses preuves. Les réviseurs peuvent approuver une explication claire parce qu’elle est lisible, même lorsqu’elle omet une branche peu fréquente.

Cela crée un biais d’automatisation, qui survient lorsque les personnes accordent une confiance excessive à la recommandation d’un système. Une spécification soignée peut accroître ce risque, car elle masque l’ambiguïté présente dans l’environnement sous-jacent.

Le workflow de Google conserve lui-même une étape de révision des règles extraites. Les entreprises devraient considérer cette étape comme un contrôle, et non comme un simple point de passage administratif.

La révision doit avoir des responsables désignés, des preuves associées et des décisions explicites. Une règle doit être marquée comme acceptée, rejetée, révisée ou non résolue avant de guider la génération de code.

La sécurité ajoute une couche supplémentaire. Google indique que le Mainframe Assessment Tool conserve les données d’évaluation collectées dans la machine virtuelle où il est déployé. Sa documentation indique également que le code source est envoyé vers la Gemini Enterprise Agent Platform.

Cette même documentation précise que le modèle n’est pas enrichi avec les informations extraites de ce code. Les organisations doivent néanmoins vérifier les contrôles régionaux, les politiques d’accès, le comportement de conservation et les exigences contractuelles applicables à leurs charges de travail.

Les tests ont également leurs limites. Dual Run peut détecter des différences entre les sorties observées, mais l’équivalence dépend de la couverture et de la qualité des comparaisons.

Si les deux environnements ne reçoivent que des transactions courantes, les cas rares restent non testés. Si la logique de comparaison ignore le délai, l’ordre ou les effets de bord en aval, deux sorties peuvent sembler égales alors que les systèmes se comportent différemment.

Les tests parallèles peuvent aussi reproduire un mauvais comportement hérité. Reproduire le mainframe est utile pendant la migration, mais cela ne prouve pas que chaque règle héritée soit souhaitable ou conforme à la politique actuelle.

Les équipes doivent séparer deux questions. L’implémentation cloud se comporte-t-elle comme l’original, et le comportement original doit-il être conservé ?

La deuxième question exige un jugement métier, juridique, de sécurité et opérationnel. L’analyse du code seule ne peut y répondre.

Les affirmations de performance nécessitent également des preuves proches de la production. Un service généré peut réussir les tests fonctionnels tout en créant une latence, une consommation d’infrastructure ou une contention de base de données inacceptables au pic de volume.

La reprise opérationnelle mérite la même attention. Les équipes devraient tester les nouvelles tentatives, les échecs partiels, les messages retardés, les transactions dupliquées et les procédures de retour arrière avant de transférer la responsabilité.

Enfin, le workflow ne peut garantir l’achèvement du programme. Une entreprise peut produire d’excellentes évaluations et prototypes sans retirer une seule charge de travail mainframe.

Le succès nécessite des critères de sortie pour chaque unité de migration. Ces critères devraient couvrir les preuves fonctionnelles, la préparation opérationnelle, le rapprochement des données, l’approbation de sécurité, les attentes de coûts et le retrait effectif de l’héritage.

La stratégie de Google est plus sûre parce qu’elle rend l’incertitude visible plus tôt. Elle n’est pas sûre simplement parce que l’IA y participe.

Ce qu’il faut surveiller à mesure que Google Cloud passe de la méthode à la preuve

Le prochain test consiste à déterminer si la méthode par étapes produit des bascules en production reproductibles, et non un code généré plus convaincant.

Le premier signal est constitué de preuves clients liées à des unités de migration achevées. Les acheteurs devraient rechercher des charges de travail de production nommées ayant passé les tests parallèles et transféré la responsabilité du système de référence.

Une étude de cas utile expliquerait le périmètre, les artefacts pris en charge, les dépendances découvertes, la durée de validation, le traitement des écarts et les composants mainframe finalement retirés. Les déclarations générales sur une analyse plus rapide en révèlent moins.

Des bascules répétées renforceraient l’argument de Google selon lequel le workflow s’étend au-delà d’une application soigneusement sélectionnée. Des évaluations sans retrait en production l’affaibliraient.

Le deuxième signal est une traçabilité plus profonde dans toute la chaîne d’outils. L’historique des versions de Google montre un travail continu sur l’extraction des règles métier, l’accès MCP, la couverture des langages et l’analyse de grands environnements.

L’avancée importante relierait chaque règle approuvée aux preuves source, aux composants générés, aux tests, aux résultats de comparaison et aux approbations humaines. Cette chaîne faciliterait les révisions lors des audits et de la maintenance ultérieure.

Elle aiderait également les équipes à identifier le point d’entrée d’une erreur dans le processus. Un écart pourrait renvoyer à une extraction défaillante, à une exigence modifiée, à du code généré, à des données converties ou au dispositif de validation.

Une traçabilité claire renforcerait le modèle itératif, car les connaissances s’accumuleraient d’une unité de migration à l’autre. Des artefacts fragmentés feraient ressembler chaque unité à un projet distinct.

Le troisième signal est la manière dont IBM et AWS répondent avec des preuves de validation comparables. Les listes de fonctionnalités se recoupent déjà ; les fournisseurs devront donc montrer comment leurs méthodes gèrent les dépendances réelles et les bascules difficiles.

IBM peut soutenir que la modernisation n’exige pas l’abandon d’IBM Z. AWS peut mettre en avant la traçabilité de la source à la sortie et les tests automatisés. Google doit prouver que l’évaluation contextualisée associée à Dual Run offre une meilleure limite de risque.

Cette concurrence devrait bénéficier aux acheteurs en entreprise. Elle éloigne la discussion des démonstrations brutes de génération de code pour l’orienter vers les preuves, la gouvernance, la portabilité et les résultats achevés.

Pour les responsables technologiques, l’action immédiate n’est pas d’approuver une migration à l’échelle de tout l’environnement. Elle consiste à sélectionner un domaine significatif et à tester toute la chaîne.

Le domaine devrait comporter de vraies dépendances et des conséquences métier sans devenir un premier mouvement irréversible. Son évaluation devrait inclure le code, les données, les calendriers, les interfaces et les connaissances opérationnelles.

Les équipes devraient consigner le nombre de règles extraites nécessitant une correction, la fréquence des divergences entre les résultats parallèles et le temps nécessaire pour résoudre chaque écart. Ces mesures révèlent davantage que le volume de code généré.

Elles devraient également décider de ce qui prend fin après une bascule réussie. Une unité de migration reste incomplète si la charge de travail originale, le poids des licences, le processus opérationnel et la responsabilité de support demeurent tous en place.

Google Cloud offre aux entreprises une voie entre une maintenance indéfinie et un big bang risqué. Cette voie est crédible parce qu’elle traite la modernisation comme une démarche de découverte, de reconstruction et de preuve.

Sa valeur dépendra de la capacité des clients à répéter ce cycle dans des environnements complexes sans créer un labyrinthe hybride permanent. Les prochaines bascules en production compteront davantage que la prochaine démonstration générée par IA.