Le 22 septembre, Anthropic a publié Claude Opus 5.5 et annonce un coût inférieur d’environ 40 % à celui d’Opus 5 pour une charge de travail typique. Chaque baisse de prix relance la même conversation chez les décideurs : si le code coûte moins cher à produire, la migration de mon application historique devrait suivre. Je pense que non, ou seulement pour la partie la moins chère du projet. Une étude publiée fin août sur une migration VB6 vers C# le montre chiffres à l’appui : ce que l’agent produit bon marché n’est pas ce qui décide du succès.
Ce qui a changé côté prix
Selon l’annonce d’Anthropic, Opus 5.5 est facturé 4 dollars par million de tokens en entrée et 20 dollars en sortie, avec une lecture de cache à 0,20 dollar. Le constructeur avance un coût de l’ordre de 40 % inférieur à Opus 5 sur une charge typique, et cite un développeur qui aurait mené une migration de 680 000 lignes en moins d’une journée. C’est un témoignage sélectionné par le fournisseur, à lire comme tel.
Un autre article, publié par Unite.AI le 24 septembre, donne un éclairage plus intéressant sur la mécanique : la baisse de la lecture de cache pèse le plus, parce que le cache représente l’essentiel du coût du travail agentique. Les données citées, de mars à septembre, montrent un contexte par requête multiplié par 2,6 et un temps de travail par prompt multiplié par 3,3. Autrement dit, les agents travaillent plus longtemps sur plus de contexte, et la tarification l’encourage.
La semaine suivante a confirmé la tendance. Le 29 septembre, OpenAI a publié GPT-6.1 Sol, facturé 2 dollars par million de tokens en entrée et 10 dollars en sortie (0,10 dollar pour l’entrée en cache, jusqu’à 272 000 tokens d’entrée), selon son changelog pour développeurs. Le lendemain, Google a annoncé Gemini 4 Argon au même prix d’introduction, 2 et 10 dollars, avant un tarif normal de 4 et 20 dollars ; le modèle n’est pour l’instant ouvert qu’à des équipes de cyberdéfense sélectionnées. Trois fournisseurs, trois baisses en huit jours : le prix de la génération ne distingue plus vraiment un outil d’un autre.
Pour un freelance qui utilise ces agents au quotidien, comme moi, la bonne nouvelle est claire : le coût marginal de la génération de code continue de tomber. La question est de savoir ce que cela change pour un client qui doit migrer du legacy.
Ce que dit l’étude VB6 vers C#
L’étude, signée Iago da Silva Rodrigues Alves, Cristiano Politowski et João Eduardo Montandon (soumise le 29 août 2026, donc un peu plus ancienne que la semaine), a confié à un agent Claude Code (Opus 4.6, contexte de 1 million de tokens) la migration de 12 fonctionnalités d’un ERP en Visual Basic 6 vers C# .NET 10. Le protocole est instructif : génération en une seule passe, sans retour humain, comparée à une référence que les auteurs ont établie à la main, soit 160 règles métier et 171 opérations en base de données.
Les résultats tiennent en un tableau :
| Complexité des fonctionnalités | Équivalence obtenue |
|---|---|
| Faible | 92 % |
| Moyenne | 81 % |
| Élevée | 47 % |
L’équivalence globale est de 70 %. Le coût en tokens suit la même pente : environ 1,66 dollar en moyenne pour une fonctionnalité simple, de l’ordre de 10 dollars pour une complexe. Les principales défaillances relevées sont des modules adjacents oubliés (42 cas), des opérations de base de données manquantes ou erronées (22) et des règles métier omises (20).
Lisez ces chiffres dans les deux sens. Le coût de la génération est dérisoire : une dizaine de dollars pour la fonctionnalité la plus difficile, à comparer à une journée de développeur. Mais dans le même temps, plus la fonctionnalité est complexe, moins l’agent est fidèle, et c’est la partie qui contient le plus de valeur métier.
Le budget se déplace vers la preuve
Voici le point que je veux défendre. Si générer coûte 10 dollars et qu’une fonctionnalité sur deux, dans la zone complexe, n’est pas équivalente à l’original, alors le coût de la migration est celui de la découverte des écarts. Et cela suppose d’avoir une référence. Les auteurs de l’étude ont dû constituer la leur à la main, ce qui est un travail considérable, et c’est précisément ce que la plupart des projets legacy n’ont pas.
Les trois catégories d’erreurs le confirment. Un module adjacent oublié, une écriture en base manquante, une règle métier perdue : rien de tout cela ne fait échouer la compilation. Le code produit est propre, il s’exécute, il ressemble à l’ancien. Il ne fait simplement pas la même chose, et seul un test qui compare les comportements le voit.
Le livrable central d’une migration assistée par IA est donc un filet de tests de caractérisation, écrit avant la génération, qui fige ce que l’ancien code fait réellement, y compris ses bizarreries. C’est le point de départ de la méthode que j’applique ; c’est aussi ce que j’ai voulu outiller avec Tabellion, qui « scelle » le comportement d’un code existant avant qu’on y touche.
À quoi ressemble ce filet en PHP
Rien d’exotique. Un test de caractérisation rejoue des entrées réelles contre l’ancien code, compare à une sortie enregistrée, et sert ensuite de juge pour le nouveau. Une structure minimale avec PHPUnit 10 ou plus :
use PHPUnit\Framework\Attributes\DataProvider;
use PHPUnit\Framework\TestCase;
final class InvoiceTotalCharacterizationTest extends TestCase
{
#[DataProvider('recordedCases')]
public function testBehaviourMatchesRecordedOutput(array $input, array $expected): void
{
$actual = (new LegacyInvoiceCalculator())->compute($input);
self::assertSame($expected, $actual);
}
public static function recordedCases(): iterable
{
foreach (glob(__DIR__ . '/fixtures/*.json') as $file) {
$case = json_decode(file_get_contents($file), true, flags: JSON_THROW_ON_ERROR);
yield basename($file) => [$case['input'], $case['output']];
}
}
}Les fixtures viennent de la production, anonymisées : on enregistre des couples entrée/sortie réels plutôt que d’en imaginer. Une fois la suite verte sur l’ancien code, on pointe le même test vers l’implémentation générée. Chaque écart est alors une décision à prendre : bug de l’agent, ou comportement ancien que les utilisateurs ont fini par considérer comme une règle ?
Cette décision est humaine. Aucun modèle ne sait, à ma place ou à la vôtre, si un arrondi bizarre est une erreur historique ou un engagement contractuel.
Les limites
L’étude a ses propres réserves, énoncées par les auteurs. Un seul agent et un seul modèle sont testés, une seule paire de langages, et seulement deux fonctionnalités de complexité élevée. Ils reconnaissent aussi que la complétude de leur catalogue de référence n’a pas été vérifiée de façon indépendante, et qu’il n’y a pas d’analyse de variance d’une exécution à l’autre, alors que les modèles ne sont pas déterministes. Un 47 % sur deux fonctionnalités est un signal, pas une loi.
Deuxième réserve : l’étude porte sur une génération en une passe sans retour humain, ce qui n’est pas ainsi que je travaille, ni la plupart des équipes sérieuses. Avec des boucles de correction guidées par les tests, les résultats peuvent être meilleurs. Le raisonnement sur la vérification tient tout de même, parce que ce qui améliore le résultat dans ces boucles, ce sont précisément les tests.
Troisième réserve : VB6 vers C# n’est pas PHP 7 vers PHP 8. Sur une montée de version dans le même langage, une bonne partie du travail est mécanique et bien outillée, et l’agent est plus fiable. Ne transposez pas ces pourcentages tels quels à votre projet.
Concrètement, par où commencer
- Avant tout appel à un agent, listez les fonctionnalités par complexité. Les 20 % les plus riches en règles métier sont ceux qui demandent le plus de preuve.
- Capturez le comportement réel : entrées et sorties, écritures en base, e-mails envoyés, appels sortants.
- Exigez que chaque lot généré passe la même suite que l’ancien code, et refusez les lots qui ne sont pas rejoués contre des données réelles.
- Chiffrez la migration en deux lignes : génération (faible) et vérification (le gros du budget). Si un devis ne détaille que la première, posez la question.
- Décidez à l’avance qui tranche quand l’ancien et le nouveau divergent.
Le prix des modèles continuera de baisser, et c’est une bonne chose. Ce qui ne baissera pas, c’est le temps qu’il faut pour savoir si ce qu’on a produit fait la même chose que ce qu’on remplace.
Sources
- Claude Opus 5.5, Anthropic, 22 septembre 2026
- Anthropic Ties Claude Opus 5.5 Pricing to Longer Coding Sessions, Unite.AI, 24 septembre 2026
- OpenAI API Changelog, OpenAI, entrée du 29 septembre 2026
- Gemini 4 Argon: our next era of frontier intelligence, Google, 30 septembre 2026
- Legacy System Modernization with Coding Agents: A Case Study, arXiv 2608.28972, 29 août 2026
- Legacy System Modernization with Coding Agents: A Case Study (résumé), Pith Review, consulté le 29 septembre 2026
Sur ce sujet, l’offre de l’atelier : Agents de code