Les mainframes, c’est un peu comme l’iPhone.

Sans l’exprimer ainsi, IBM a tout de même fait le rapprochement, en réaction à un emballement boursier qui lui a été défavorable.

Vendredi 20 février, le titre avait clos à environ 257 $. Lundi 23, la tendance baissière constatée depuis l’ouverture s’est subitement accélérée à la mi-journée. À la fermeture, l’action avoisinait les 225 $. Son cours avait donc chuté de près de 15 %.

L’élément déclencheur fut probablement un post d’Anthropic, sur le blog consacré à ses LLM Claude. Sujet : comment l’IA « aide à passer outre la barrière du coût pour la modernisation cobol ».

Ce que dit le post d’Anthropic

Le contexte est posé d’une façon simple, pas nouvelle : de moins en moins de personnes compétentes dans ce langage, du code mal documenté qui a évolué sur des décennies… et donc d’autant plus de difficulté à moderniser. Là interviennent « des outils comme Claude Code ». Ils automatisent les phases d’exploration et d’analyse, qui « représentent l’essentiel des efforts » de modernisation.

Avec eux, « plus besoin d’une armée de consultants », ajoute Anthropic. Ils vont au-delà des graphes d’appels pour découvrir des dépendances implicites qu’une analyse statique ne révèle pas : structures de données partagées, opérations qui créent du couplage entre modules, séquences d’initialisation qui affectent l’exécution, etc.

L’IA documente aussi les workflows, identifie les risques et suggère une feuille de route, poursuit Anthropic. L’humain apporte sa connaissance des exigences réglementaires, des priorités métiers, des contraintes opérationnelles (exigences de standardisation, d’intégration…) et des degrés de tolérance auxdits risques. Il décide aussi si les tests fonctionnels suggérés suffisent, quels scénarios nécessitent une validation par des experts et quels critères de performance le code modernisé doit respecter.

La démarche est validée par étapes, sans changements massifs qui exigeraient de revenir sur des semaines de travail, conclut Anthropic.

Pourquoi IBM dénonce un amalgame

IBM ne s’en prend pas tant à ce post qu’à l’interprétation que le marché semble en avoir faite.

Traduire du code est une chose ; moderniser une plate-forme en est une autre, affirme-t-il. La valeur des mainframes réside dans leur architecture, du silicium à l’OS. De là, le défi de modernisation n’est pas un problème de conversion de langage. Le vrai travail, c’est l’ingénierie système : reconception de l’architecture data, remplacement du runtime, maintien de l’intégrité du traitement des transactions, respect des exigences non fonctionnelles embarquées.

Un simple refactoring de code ne suffit pas à répliquer des décennies d’intégration étroite entre logiciel et matériel, poursuit Big Blue. C’est là qu’il fait l’analogie avec l’iPhone.

Son propos touche aussi à un aspect qu’Anthropic n’aborde pas – tout du moins explicitement -, mais que le marché a dans son radar : comment une solution full SaaS pourrait-elle remplacer des applications mainframe ? Cela paraît difficile vu l’ampleur des dépendances on-prem, estime IBM, qui brandit de surcroît l’argument de la souveraineté et de la résidence des données.

Partant, la conversion du cobol ne serait pas un sujet de mainframes. Environ 40 % de ce code fonctionne sur Windows, Linux et d’autres systèmes distribués, avance IBM. On évitera donc l’amalgame…

Illustration générée par IA

The post Claude Code, la fin des mainframes ? IBM crie à l’amalgame appeared first on Silicon.fr.

Erreur humaine ou pas, toujours est-il qu’une IA, héritant des privilèges d’un ingénieur, a supprimé un environnement de production.

Une partie des commentaires sur « l’affaire Kiro » convergent en ce constat.

Amazon n’avait initialement pas communiqué à propos de l’incident, survenu mi-décembre. Il a fini par le faire la semaine dernière… après que le Financial Times l’eut révélé.

Ce qu’affirme le Financial Times

S’en référant à des employés d’Amazon, le FT déclare qu’AWS a subi, « ces derniers mois », au moins deux pannes en production dues à des erreurs impliquant ses propres outils d’IA. Il ne date pas l’une d’entre elles, qui aurait, toujours selon des employés, impliqué l’assistant Amazon Q Developer.

Celle de mi-décembre a entraîné 13 heures d’indisponibilité pour un « système utilisé par les clients ». La conséquence de modifications effectuées par l’assistant Kiro, qui avait choisi de supprimer puis de recréer un environnement.

Autre propos prêté à des employés : traités comme une « extension » des ingénieurs, les outils IA avaient les mêmes permissions. Dans l’un et l’autre cas, les personnes impliquées n’ont pas sollicité de validation des changements par un pair.

Le FT attribue certains propos directement à Amazon. D’après ce dernier, l’incident de décembre a été « extrêmement limité » : un seul service affecté, dans certaines zones de Chine continentale. Quant à l’autre incident, il n’a pas eu d’impact sur des services exposés aux clients.

Autre déclaration attribuée au groupe américain : dans les deux cas, il s’agissait d’une erreur humaine. Plus précisément un problème de contrôle d’accès : l’ingé impliqué dans l’incident de décembre avait plus de permissions qu’il n’aurait dû. Le même problème aurait pu se produire avec tout outil – doté ou non d’IA – ou toute action manuelle.

Ce que rétorque Amazon

Concernant le prétendu incident avec Amazon Q Developer, le groupe américain est catégorique : « Il est complètement faux de dire qu’un deuxième événement a impacté AWS ».

Celui de décembre a touché l’explorateur de coûts AWS (Cost Explorer), dans une de ses 39 régions cloud. Amazon juge ce périmètre « extrêmement limité » et précise n’avoir reçu aucune demande client.

L’entreprise confirme le scénario des contrôles d’accès mal configurés. C’est « une coïncidence » que des outils d’IA aient été impliqués, clame-t-elle. Et d’ajouter avoir implémenté des garde-fous « pour que cela ne se reproduise pas ». Parmi eux, une révision systématique par les pairs pour les accès en prod.

Une « directive Kiro » qui ne fait pas l’unanimité

En complément à ces éléments, un porte-parole a expliqué que l’erreur humaine n’était pas la validation de l’action par l’ingénieur, mais le fait que ce dernier n’avait pas compris quel était son niveau de privilèges. Sous-entendu : il aurait probablement agi différemment s’il avait su.

Amazon assure que par défaut, Kiro demande une validation pour chaque action qu’il souhaite effectuer. Il ne dit en revanche rien de la façon dont l’assistant a proposé de supprimer l’environnement en question. A-t-il été explicite ? Dans la négative, l’ingénieur s’est-il renseigné davantage avant de valider ?…

En toile de fond, une directive interne de novembre 2025 par laquelle Amazon pousse ses équipes à standardiser sur Kiro. Une démarche entreprise tant au nom d’une sécurité renforcée (limitation des risques de fuites de données, notamment) que d’une télémétrie unifiée.

L’initiative a suscité des remous. Plus d’un millier d’employés ont demandé de pouvoir conserver un accès à des outils, dont Claude Code. Motif : ils sont plus performants que Kiro sur des cas d’usage comme le refactoring multilangage et la gestion de certains frameworks « de niche ».

Illustration générée par IA

The post Kiro, l’IA d’Amazon, a cassé AWS : ce qu’on en sait appeared first on Silicon.fr.