Anthropic a réécrit la Messages API en Rust avec Claude : la charge CPU baisse de 40–50%

Anthropic a réécrit en Rust la Messages API, l'interface par laquelle les développeurs accèdent à Claude. Selon Katelyn Lesse, de l'équipe d'Anthropic, qui en a parlé dans le podcast Latent Space, aucun des participants au projet n'était développeur Rust. Le code a été écrit par Claude lui-même. Les humains ont établi le plan et vérifié, sur du trafic réel, que l'ancienne et la nouvelle implémentation se comportaient de la même façon. Résultat, tel que le résume sur X l'auteur Somi : la charge CPU a baissé de 40–50%. Son post a dépassé les 182 000 vues, car il s'attaque à l'un des dogmes les plus tenaces du secteur : « ne jamais tout réécrire de zéro ».

Qui a fait quoi : le modèle écrit, les humains valident

La répartition des tâches compte ici davantage que le langage. Claude s'est chargé d'écrire le code. Les ingénieurs ont géré deux points : le plan de réécriture et le critère de recette. Ce critère était la comparaison des deux versions sur des requêtes réelles. Si les deux services produisent un résultat équivalent sur le même trafic, la nouvelle implémentation est jugée opérationnelle. Il n'est pas nécessaire de maîtriser les idiomes de Rust pour cela : il suffit de savoir décrire précisément ce que le service doit faire et de le vérifier sur des données.

Cela explique pourquoi « zéro développeur Rust » n'a rien d'une folie. Jusqu'ici, le principal obstacle à un changement de langage était le manque de personnes capables d'écrire et de relire le code. Ici, l'obstacle se déplace de l'écriture vers la vérification. L'équipe dispose d'une référence, un système de production qui fonctionne, et la nouvelle version doit se comporter exactement comme lui. Ce cadrage convient bien aux modèles : la tâche est clairement définie et le résultat se vérifie automatiquement.

Ce que signifient 40–50% de CPU en moins

Pour une API qui traite un nombre énorme de requêtes, le temps processeur se traduit directement en coûts d'infrastructure. Si, à charge égale, le service consomme deux fois moins de CPU, il faut soit moins de serveurs, soit le même parc peut absorber plus de trafic. Cette lecture est la nôtre, et non une déclaration d'Anthropic : le récit ne dit pas combien d'argent l'entreprise a économisé.

Un autre point mérite l'attention. La méthode consistant à « réécrire un service critique dans un langage compilé, avec un contrôle strict de la mémoire » est connue depuis longtemps. Elle coûtait des mois de travail de spécialistes, et la plupart des équipes y renonçaient. Si le modèle écrit l'essentiel du code, le coût de l'expérience baisse et le calcul de rentabilité change. Le verdict de Somi, « le conseil de ne pas faire de grosse réécriture est mort », sonne fort, mais un seul cas ne réfute pas la règle. Il montre seulement dans quelles conditions elle cesse de s'appliquer.

Ce que le récit ne dit pas

La source est un court post renvoyant vers un podcast, et non un rapport technique. Plusieurs points importants restent donc flous :

• quelle partie exacte de la Messages API a été réécrite : toute la pile ou seulement certains composants ;
• comment ont évolué les latences et le débit, et pas seulement la charge CPU ;
• combien de temps le travail a pris et combien d'itérations Claude a nécessitées ;
• quels écarts entre l'ancienne et la nouvelle version la comparaison a révélés, et comment ils ont été traités ;
• comment l'équipe maintiendra du code écrit dans un langage qu'aucun de ses membres ne maîtrise.

Le dernier point est le plus inconfortable. Un code qu'aucun humain n'a lu en profondeur devra être maintenu, il faudra y traquer des bugs rares et y ajouter des fonctionnalités. Tant que Claude reste disponible, c'est faisable. Mais le coût à long terme de cette approche n'est pas visible à partir d'un seul cas.

Ce qu'il faut en retenir en pratique

La recette que l'on peut s'approprier ne dépend pas de Rust. Il faut d'abord figer le comportement du service existant : collecter des requêtes et des réponses réelles, puis mettre en place la comparaison entre deux implémentations. Ensuite, le plan et la recette restent aux humains, et le modèle prend en charge le travail de dégrossissage. Plus votre outillage de test et votre rejeu de trafic en mode shadow sont solides, plus une telle réécriture est sûre. Sans eux, le modèle ne fera que générer rapidement une grande quantité de code non vérifié. Avant de reproduire l'expérience d'Anthropic, mieux vaut attendre la version complète du récit et voir comment l'équipe a résolu les questions absentes de ce résumé.