Amazon affirme avoir économisé plus de 4 500 années de travail de développeur en confiant à l'IA la modernisation du code de dizaines de milliers d'applications Java. L'annonce, faite en août 2024 par son directeur général Andy Jassy, porte sur l'agent de transformation de code d'Amazon Q Developer. Ces chiffres, publiés le 1er août 2024 sur le blog DevOps d'AWS et dans un message d'Andy Jassy sur LinkedIn, par une entreprise qui vend l'outil, restent une déclaration d'Amazon, mais ils éclairent un chantier que beaucoup de directions informatiques repoussent depuis des années.
Des milliers d'applications bloquées sur de vieilles versions de Java
Java est un langage de programmation très répandu dans les systèmes d'information des grandes entreprises. Chaque nouvelle version apporte des correctifs de sécurité et des gains de performance, mais passer d'une version à l'autre demande de reprendre le code, de remplacer des bibliothèques devenues obsolètes et de tout retester. Chez Amazon, des dizaines de milliers d'applications en production tournaient encore sous Java 8 ou Java 11.
Ce type de chantier est connu de tous les responsables informatiques. Personne ne le conteste sur le fond, puisqu'une version ancienne expose l'entreprise à des failles et coûte plus cher à faire tourner. Pourtant, il passe presque toujours après les nouvelles fonctionnalités demandées par les métiers, car il ne produit rien de visible pour l'utilisateur final.
Selon Andy Jassy, une migration vers Java 17 mobilisait en moyenne une cinquantaine de jours de développeur par application. Le blog d'AWS, lui, raisonne par dépendance : mettre à jour une seule bibliothèque prenait « une journée ou plus », contre quelques minutes avec l'agent. Rapporté à des dizaines de milliers d'applications, le calcul explique pourquoi ce travail s'accumule en dette technique. On désigne ainsi l'ensemble des corrections et mises à jour qu'on reporte, et dont le coût grossit avec le temps.
Plus une application reste longtemps sur une version ancienne, plus l'écart à combler s'élargit. Les bibliothèques dont elle dépend cessent d'être maintenues, les développeurs qui l'ont écrite changent de poste, et la moindre mise à jour devient un projet en soi. Beaucoup d'entreprises finissent par vivre avec ce risque faute de pouvoir mobiliser une équipe pendant des semaines.
Un agent d'IA qui propose les modifications, des développeurs qui valident
Pour ce chantier, Amazon a utilisé en interne l'agent de transformation de code d'Amazon Q Developer, son assistant de programmation. Un agent, dans ce contexte, désigne un programme d'IA capable d'enchaîner plusieurs actions sur un projet entier plutôt que de répondre à une seule question. Il analyse l'application, identifie ce qui doit changer pour passer à Java 17 et propose les modifications correspondantes.
Le point important tient à l'organisation du travail. D'après Amazon, les développeurs relisent et valident chaque modification proposée par l'agent. L'IA prend en charge la partie répétitive, les équipes gardent la décision et la responsabilité du résultat.
Ce partage des rôles est ce qui rend le chantier praticable à grande échelle. Une migration de version suit des règles assez stables d'une application à l'autre, ce qui convient bien à un outil automatisé. Les cas particuliers, eux, restent traités par des personnes qui connaissent le logiciel.
La relecture n'est pas une formalité. Une modification techniquement correcte peut changer le comportement d'une fonction sur laquelle un service entier s'appuie, et seul un développeur qui connaît l'application sait le repérer. C'est pourquoi un tel dispositif suppose aussi des tests automatisés capables de vérifier, après chaque changement, que l'application rend toujours le même service.
Avec l'IA, la modernisation du code passe de 50 jours à quelques heures
D'après Andy Jassy, la durée moyenne d'une migration vers Java 17 est tombée d'environ 50 jours de développeur à quelques heures. The Decoder, qui relaie l'annonce, ajoute que 79 % des revues de code générées automatiquement ont été livrées sans modification. Ce chiffre ne figure pas sur le blog d'AWS, et il porte sur les revues de code, pas sur l'ensemble des modifications : on le cite donc avec prudence.
Additionnées sur l'ensemble du parc, ces heures représentent d'après Amazon plus de 4 500 années de travail de développeur économisées. Relayé par The Decoder, ce chiffre avancé par Andy Jassy est celui que la presse technique a retenu de l'annonce.
Le résultat le plus intéressant se trouve pourtant ailleurs. Amazon évalue à environ 260 millions de dollars par an les gains liés à cette migration, et l'entreprise précise que ce montant provient surtout des coûts d'infrastructure. Java 17 étant plus performant, les mêmes applications consomment moins de ressources serveur. Amazon dit avoir retenu une hypothèse prudente dans ce calcul.
Cette précision change la lecture du cas. Le temps gagné par les développeurs est spectaculaire, mais il ne représente qu'une partie de la valeur. L'essentiel vient de ce que la mise à jour rend possible une fois faite, à savoir des applications plus sûres et moins coûteuses à héberger.
Ce que les chiffres d'Amazon ne disent pas
Il faut garder en tête la nature de la source. Tous ces résultats ont été calculés et publiés par Amazon, qui commercialise Amazon Q Developer auprès de ses clients. Aucune étude indépendante ne les a vérifiés. Avant de reprendre le chiffre des 4 500 années, un directeur informatique voudra savoir comment il a été construit. Le temps de relecture, les retouches sur les propositions non acceptées et les éventuels incidents après la mise en production y sont-ils décomptés ?
Le contexte d'Amazon est aussi très particulier. Une entreprise qui doit faire la même migration sur des dizaines de milliers d'applications écrites dans le même langage profite mécaniquement davantage d'une automatisation qu'une entreprise au parc logiciel disparate. Le taux de 79 % a été obtenu à cette échelle, que peu d'organisations connaissent.
Il faut aussi rappeler qu'une bonne partie d'une montée de version Java se faisait déjà sans IA générative. Des outils de réécriture déterministe comme OpenRewrite appliquent des « recettes » de migration connues (changement d'API, renommage de paquets, mise à jour de dépendances) et produisent le même résultat à chaque exécution. Sur un projet réel, nous commençons par là, puis l'agent d'IA traite ce que les recettes ne couvrent pas. On réserve ainsi la relecture humaine aux modifications qui le méritent.
Enfin, le chiffre d'acceptation porte sur une tâche bien délimitée. Passer de Java 8 à Java 17 obéit à des règles connues et documentées. On ne peut pas en déduire la même efficacité pour réécrire un logiciel mal documenté, changer d'architecture ou reprendre des règles métier enfouies dans le code depuis des années. Pour les tâches de développement du quotidien, l'étude sur les assistants de code chez Microsoft et Accenture donne une mesure plus modeste et plus rigoureuse.
Ce que ça change pour une PME ou une ETI
Une PME n'a pas des dizaines de milliers d'applications. Elle possède en revanche souvent un logiciel métier développé il y a des années, un site de commande en ligne ou un outil de planification. Ces outils tournent parfois sur une version de langage ou de base de données que plus personne n'ose toucher. Le problème est le même à une autre échelle, et il pèse plus lourd, car l'équipe informatique se limite souvent à quelques personnes.
Prenons un distributeur de matériel électrique dont l'outil de gestion des devis repose sur un vieux cadre logiciel. Chaque mise à jour de sécurité du serveur menace de casser l'application. L'éditeur d'origine a disparu et le prestataire actuel facture chaque intervention au temps passé. Dans ce cas, un agent d'IA peut préparer l'essentiel de la migration technique, à condition qu'un développeur qui connaît le logiciel relise chaque modification, comme chez Amazon.
Avant de lancer quoi que ce soit, il faut savoir où l'on en est. Un audit de la dette technique permet de lister les composants obsolètes, les dépendances à risque et les parties du code qui se prêtent à une automatisation. C'est aussi le moment de chiffrer ce que coûte le statu quo, en incidents, en correctifs d'urgence et en hébergement surdimensionné. Nous avons détaillé ailleurs les coûts cachés de la maintenance, qui sont rarement suivis ligne à ligne.
Notre position chez JUWA est nette. L'IA appliquée à la modernisation du code compte parmi les usages les plus rentables que nous voyons en entreprise, précisément parce que la tâche est répétitive, vérifiable et reportée depuis longtemps. Lors de la reprise de l'application métier de Fit Doors, le code ne démarrait plus et aucun test n'existait : la valeur est venue après la remise à niveau, quand l'outil a pu de nouveau être corrigé et mis en ligne sans crainte. Elle suppose en revanche des tests automatisés solides et une relecture humaine systématique, sans quoi on remplace une dette par une autre.
C'est la démarche que nous suivons lors d'une reprise de tierce maintenance applicative, quand nous récupérons une application existante pour en assurer le suivi. L'IA sert à remettre le code à niveau rapidement, puis la supervision permet de repérer les erreurs avant que les utilisateurs ne les signalent. Lorsque l'application doit ensuite évoluer vers de nouveaux usages, le projet bascule vers du développement IA sur mesure, sur une base assainie.
Le bon ordre compte. Une entreprise qui ajoute des fonctions d'IA à un logiciel vieillissant empile les couches sur des fondations fragiles, et chaque nouveauté rend la future migration plus coûteuse. À l'inverse, remettre le code à niveau d'abord permet de construire ensuite avec une équipe qui comprend ce qu'elle maintient. Pour une PME, ce choix d'ordonnancement pèse souvent davantage que le choix de l'outil d'IA lui-même.
Sources
- Amazon Q Developer just reached a $260 million dollar milestone, AWS DevOps Blog, août 2024
- Amazon's AI assistant saves 4,500 years of development time, CEO Andy Jassy says, The Decoder, août 2024
