Actualites

Dette technique : AWS a une moulinette pour éradiquer l’IT historique

AWS Transform Custom permet de personnaliser les projets de migration au-delà des convertisseurs qui se contentaient de traduire un format dans un autre. L’entreprise peut modéliser les étapes et travailler sur des optimisations recommandées par l’IA.

Yann Serra
par
Publié le: 08 déc. 2025

Détruire la dette technique. Telle est la promesse du service AWS Transform, qui réunit plusieurs outils de migration automatisée de l’informatique sur site vers le cloud AWS, qui avait été discrètement lancé en mai dernier et qui, à l’occasion de l’événement re:Invent 2025 que l’hyperscaler a organisé la semaine dernière à Las Vegas, prend une nouvelle dimension avec la faculté inédite de composer des migrations personnalisées.

Pour l’occasion, le service est renommé AWS Transform Custom. Et l’interface graphique de cette application web se double désormais d’une ligne de commande, plus pratique pour les développeurs et les administrateurs qui souhaitent scripter des étapes.

« Il ne s’agit plus d’appliquer des conversions génériques. Il s’agit d’apporter la faculté de composer, de faire intervenir à tout moment des humains dans le processus pour qu’ils apportent des améliorations, ou qu’ils décident de la manière de résoudre des problèmes épineux. Les IA internes donnent d’ailleurs les clés de ce qui est optimisable, si bien qu’AWS Transform Custom permet de passer d’une transformation par la migration à une transformation par l’innovation », argumente Asa Kalavade, qui dirige le programme AWS Transform.

En clair, l’outil qui servait à indexer différents projets de migration, opérés par différents outils pour différentes technologies, devient un orchestrateur capable d’assembler en un seul processus des tâches qui n’ont rien à voir, mais qui sont complémentaires.

Par exemple, plutôt que de migrer une application .Net vers Linux, puis sa base de données SQL Server vers Aurora (la version AWS de PostgreSQL/MySQL), puis leurs machines virtuelles VMware vers EC2, AWS Transform Custom fait tout dans le même flux, en tenant compte de la cohérence initiale.

C’est la magie nouvelle de l’IA agentique, grâce à laquelle les différents outils deviennent subitement capables de collaborer. Et même capables de lancer au fil de l’eau des modules externes. Là, pour exécuter des scripts préparatoires que l’entreprise cliente a elle-même mis au point. Ou, là, pour injecter des informations d’étapes dans la console d’un administrateur ou d’un développeur, afin qu’il puisse aménager en cours de route une optimisation opportune.

« AWS rejoint une tendance forte du marché, plaçant l'IA comme l'un des facilitateurs des programmes de modernisation qui, à grande échelle, sont longs, coûteux et dont la complexité constituait un obstacle majeur. Cela permet aussi d'attaquer la modernisation sous un angle différent, en l’installant dans un cycle d'amélioration continue, favorisant ainsi la mise en place d'une roadmap programmée dans le temps pour réduire la dette technique, une des bêtes noires des DSI », commente Cyrille Chausson, analyste expert en transformation IT chez IDC.

AWS Transform, une seule interface pour plusieurs outils de migration

« La vocation première d’AWS Transform était juste d’automatiser le passage d’une version obsolète d’un framework – Python, Java, etc. – à une version plus moderne, plus sécurisée, tout en modifiant les codes des utilisateurs en conséquence. Puis, son interface était si ergonomique que nous avons eu l’idée d’y inclure trois outils jusqu’ici séparés et qui permettent chacun de transformer une plateforme historique sur site vers des technologies présentes sur AWS », raconte Asa Kalavade.

En l’occurrence, les trois technologies prises en charge par AWS Transform sont la virtualisation VMware, les applications Windows écrites en .Net avec leurs bases de données SQL, ainsi que les applications Cobol des mainframes. Le service permet de les transformer en machines virtuelles EC2, en applications Linux utilisant Aurora et en code Java, respectivement.

Selon la responsable, AWS Transform aurait à date permis de convertir plus d’un milliard de lignes de codes Cobol en Java et aurait fait économiser aux administrateurs système un total de plus de 810 000 heures de travail. Ces chiffres ont une source : il se trouve que la console d’AWS Transform affiche après chaque utilisation une comptabilité des heures gagnées et des lignes de code converties. Officiellement, il s’agirait d’un rapport à l’attention des services financiers des clients d’AWS.

Une douzaine d’IA pour diagnostiquer ce qu’il faut transformer

« Seulement voilà. Migrer une machine virtuelle d’un hyperviseur à l’autre ne suffit pas. Il faut aussi adapter une topologie réseau excessivement complexe à la source vers des règles de routage réseau équivalentes sur EC2. Et quant aux applications, il faut surtout veiller à ce qu’elles atteignent exactement le même niveau de performances en cloud que sur site, ce qui passe par exemple par une compréhension fine des bases de données utilisées. Pour cela, AWS Transform utilise une douzaine d’agents d’IA susceptibles de résoudre ces sujets complexes », continue Asa Kalavade.

Ces agents d’IA avaient été déjà plus ou moins développés dans les outils de migration d’origine pour comprendre ce qu’il fallait migrer. Par exemple, la migration de VMware vers EC2 était jusque-là la mission d’une équipe de consultants dédiée chez AWS, celle des Professional Services, alias ProServe. Celle-ci avait mis au point un agent d’IA maison, ProServe Delivery Agent, capable de comprendre la configuration en place. Aujourd’hui, ce même ProServe Delivery Agent indique à AWS Transform comment configurer EC2 en conséquence.

« Tous ces agents d’IA ont été conçus de la même manière : ils savent tous lire et interpréter des documentations fournies par les équipes techniques de l’entreprise pour comprendre les configurations à atteindre. C’est cette uniformisation qui nous a incités à tout regrouper dans un seul produit », dit Asa Kalavade.

Globalement, l’utilisation d’AWS Transform est gratuite, mais l’utilisation des agents d’IA en amont, pour diagnostiquer les configurations à faire ou comprendre ce qu’il faut changer dans des lignes de code, est payante.

Faire de la place aux prestataires de services

À l’écran, l’entreprise cliente enchaîne ainsi les travaux à faire étape par étape, glissant, de-ci, de-là, des documents pour que les IA déterminent comment les faire. Ou ajoutant des points d’étape pour les interventions humaines.

« Par exemple, après qu’un agent d’IA a compris les critères de performances de votre code d’origine, vous pouvez lui demander d’intégrer ces critères dans votre outil de développement ou dans une IA externe telle que Claude, pour développer quelque chose autour de ces critères et les réinjecter ensuite dans votre processus », explique Asa Kalavade.

Ces interventions humaines ou, ce qui revient au même, les insertions de scripts externes au milieu du flux d’opérations constituent en vérité une porte ouverte aux prestataires tiers qui vendent de l’innovation et avec qui AWS entend travailler en bonne intelligence.

« Certaines entreprises voudront utiliser AWS Transform Custom elles-mêmes, nous leur permettons de le faire. Mais la plupart voudront sans doute passer par un intégrateur. Notre produit a été conçu pour rendre possible cette collaboration, pour qu’un prestataire apporte sa sauce secrète », argumente Asa Kalavade.

« Accenture, par exemple, a développé un module, appelé Digital Brain, qui applique automatiquement les bonnes pratiques pour le respect des réglementations. Ils ont déjà pu le mettre dans le processus d’AWS Transform Custom. En l’occurrence, Accenture a porté son agent sur AWS Bedrock, via AgentCore, afin qu’il soit facile de les intégrer », ajoute-t-elle, en précisant que seuls les clients d’Accenture peuvent accéder à ses agents.

Cyrille Chausson voit cette ouverture aux prestataires externes d’un bon œil. « Aujourd'hui, tous les Capgemini, Accenture, Infosys, Wipro, TCS ont des plateformes de modernisation IT à base d'IA, de GenAI et d'Agentic AI. Ainsi, si on peut s'interroger sur l'éventuelle dépendance aux agents d'AWS dans le processus de transformation, il apparaît qu'AWS Transform Custom n’est pas qu’une nouvelle porte d'entrée vers les services AWS. Il donne aussi une place de choix aux partenaires qui apparaissent davantage comme des co-innovateurs que comme de purs intégrateurs », dit-il.

Demain, la conversion des VM en containers Kubernetes

Parmi les démonstrations en ligne qu’AWS propose pour présenter AWS Transform Custom, il en est une qui le montre, grâce à l’ajout d’une documentation dédiée, adapter le code d’un jeu vidéo programmé pour la bibliothèque OpenGL en code adapté pour Metal, la bibliothèque similaire que propose Apple sous macOS. Quoique sortant du cadre des migrations prévues à l’origine par AWS, cet exemple reste limité à de la traduction d’un jeu d’instruction vers un autre.

AWS entend enrichir AWS Transform Custom d’extensions plus conséquentes. « Dans un avenir proche, nous intégrerons par exemple la migration depuis d’autres hyperviseurs que VMware, mais aussi depuis des systèmes de stockage particuliers, depuis des bases de données particulières. Nous voulons aussi simplifier la procédure pour que des prestataires externes ajoutent leurs agents à AWS Transform Custom. Nous regardons comment les intégrer à la Marketplace, comment vérifier que tous ces agents puissent fonctionner ensemble », évoque Asa Kalavade.

Reste que lorsque les entreprises envisagent de moderniser leurs applications sur site, elles pensent plus à les transformer d’un format machine virtuelle à un format container, qu’à simplement les convertir d’un hyperviseur à l’autre.

« Pour l’instant, AWS Transform ne sert pas à convertir des VM en containers Kubernetes. Mais je vous promets que nous y travaillons. Et nous nous appuierons encore une fois sur les travaux de notre unité ProServe, qui dispose d’un agent permettant aux entreprises de charger des diagrammes décrivant l’architecture d’une application. Leur agent peut aussi extraire des informations sur le fonctionnement de cette application depuis de simples notes de réunion. C’est une bonne base pour automatiser un existant vers une architecture complètement nouvelle », conclut la responsable d’AWS.

Pour approfondir sur Middleware et intégration de données