Anthropic affirme que ses applications Claude sont trois fois plus rapides. Voici ce qui a changé

Anthropic affirme qu’un sprint de deux semaines en août a rendu environ trois fois plus rapides les tâches courantes sur claude.ai et l’application Claude pour ordinateur. Son compte rendu technique, publié le 23 septembre, apporte des précisions plus utiles que le seul chiffre du titre : il montre quelles actions ont été accélérées, comment l’équipe a vérifié ses mesures et quelles décisions de mise en production sont restées sous la responsabilité des ingénieurs.

Le grand changement

• Ce qui a changé : Anthropic fait état d’une baisse des temps d’attente pour 13 mesures d’actions courantes sur le Web et l’application pour ordinateur. Le chiffre de 3,1× est la moyenne géométrique de ces améliorations, mesurées au 75e percentile les 13 et 27 août. Il s’agit d’un résultat de l’entreprise portant sur des parcours sélectionnés.
• Pourquoi c’est important : Pour les utilisateurs de Claude, le chargement d’une nouvelle page Web, désormais prête à recevoir du texte en 550 millisecondes au lieu de 3 085, accélère une action répétée de l’utilisation du produit. Pour les équipes techniques, ce cas illustre la façon dont un assistant d’IA peut contribuer à résoudre des problèmes de performance mesurés, tandis que les personnes définissent les priorités et approuvent les changements.
• À suivre : Anthropic reconnaît que le 95e percentile, d’autres parcours et les conversations très longues doivent encore être améliorés. Ces mesures permettront de voir si les progrès annoncés s’étendent au-delà des actions sélectionnées et de la comparaison d’août.

Ce que les utilisateurs ont gagné

Anthropic a désigné quatre parcours qui, selon l’entreprise, représentent 95 % de l’activité des utilisateurs : lancer l’application, démarrer une conversation, charger une conversation et envoyer un message. Ces parcours ont donné lieu à 13 mesures couvrant le Web, l’application pour ordinateur et ses produits. Chacune commençait par une action de l’utilisateur et s’achevait lorsque le résultat s’affichait ; les opérations effectuées par le client et par le serveur étaient mesurées séparément.

Pour le chargement d’une page claude.ai encore vierge, le délai avant qu’elle soit prête à recevoir du texte au 75e percentile est passé de 3 085 à 550 millisecondes, soit une accélération par 5,6. Le démarrage à froid de l’application pour ordinateur est passé de 6 310 à 3 328 millisecondes, soit 1,9 fois plus rapide. Le chargement d’une session cloud Claude Cowork sur ordinateur est passé de 2 566 à 728 millisecondes, soit 3,5 fois plus rapide. La partie côté client de l’envoi d’un message dans une conversation Web est passée de 180 à 59 millisecondes, soit 3,1 fois plus rapide. Il s’agit d’actions et de plateformes différentes ; le chiffre global de 3,1× est la moyenne géométrique des 13 ratios, et non le résultat d’une seule tâche.

La comparaison s’appuie sur la mesure de l’activité réelle des utilisateurs par Anthropic, au 75e percentile les 13 et 27 août. L’article ne publie ni audit indépendant, ni résultats de ces parcours au 95e percentile, ni estimation contrôlée de la part des gains attribuable à l’aide de Claude. Anthropic estime que l’accélération de ces actions fait économiser chaque jour des dizaines de milliers d’heures d’attente aux utilisateurs, mais ne présente pas le calcul à l’appui de cette estimation.

Le cycle de mesure à l’origine des changements

L’équipe est partie d’une vingtaine de projets choisis par les ingénieurs. Anthropic explique avoir utilisé Claude Tag, un agent bêta exécutant un modèle de recherche interne qu’elle juge à peu près comparable à Opus 5.5, pour repérer les goulets d’étranglement, créer des benchmarks et proposer des changements. Selon l’équipe, elle avait atteint 12 de ses 13 objectifs initiaux au troisième jour, puis en a fixé de nouveaux et recherché les problèmes qui échappaient à ses outils de surveillance existants.

Un exemple a commencé par l’enregistrement de lignes de la barre latérale qui se déplaçaient après le chargement d’une page. La mesure existante Cumulative Layout Shift ne faisait pas ressortir le problème. Un ingénieur a proposé d’utiliser l’API Layout Instability sous-jacente. Claude a ensuite ajouté une télémétrie indiquant la zone de la page touchée ainsi qu’un test d’intégration qui retardait le chargement des données de la barre latérale. Anthropic indique que le test a échoué lors des 20 exécutions du code d’origine et réussi lors des 20 exécutions de la correction proposée. Après le déploiement de la télémétrie, l’entreprise affirme avoir constaté un déplacement après que la page était devenue utilisable sur 31 % des chargements Web. Il s’agit d’un exemple documenté par Anthropic dans son sprint, et non d’une mesure reproduite par BIG CHANGE.

L’équipe s’est également servie de mesures en laboratoire pour accélérer les cycles entre les mises en production. Sur deux portions critiques de code JavaScript, elle a comparé le nombre déterministe d’instructions exécutées au temps écoulé sur les mêmes benchmarks. Anthropic indique que la baisse du nombre d’instructions de 48 % et 31 % s’est accompagnée de réductions du temps réel de 78 % et 44 %. L’équipe a fait de ces nombres d’instructions des seuils dans le processus d’intégration continue, puis les a abaissés à mesure que les performances s’amélioraient. Elle affirme avoir écarté les benchmarks peu fiables ou qui ne suivaient pas l’évolution de la latence pour les utilisateurs. La distinction est importante : un compteur de laboratoire a guidé les changements, tandis que les mesures en conditions réelles vérifiaient que le travail mis en production était bénéfique.

Les personnes ont gardé la maîtrise

Anthropic décrit un canal Slack composé de nombreux fils de discussion ciblés, chacun consacré à un parcours ou à un benchmark. Claude retraçait le problème, proposait un benchmark et des demandes de fusion, surveillait les déploiements et lisait les données du terrain. Les ingénieurs fixaient les objectifs, décidaient des compromis acceptables pour les utilisateurs et approuvaient chaque changement. Un responsable humain nommément désigné était associé à chaque fil. Une modification proposée de 900 lignes a été rejetée, les ingénieurs jugeant que le gain de deux millisecondes par message ne justifiait pas le coût de maintenance.

Le processus de mise en production comportait plusieurs contrôles. Anthropic indique que chaque demande de fusion faisait l’objet d’un examen automatisé et de l’approbation d’au moins une personne ; des tests unitaires étaient exécutés avant les optimisations. Les changements visibles par les utilisateurs étaient protégés par des indicateurs de fonctionnalité temporaires. Les changements à haut risque étaient d’abord proposés aux employés, puis à 1 % des utilisateurs, et enfin à tout le monde. L’équipe a introduit près de 200 indicateurs pendant le sprint et affirme en avoir supprimé plus de la moitié avant sa fin. Anthropic dit avoir fusionné plus de 3 000 changements sans incident touchant les clients ni retour en arrière. C’est le récit de l’entreprise sur ce sprint ; il ne permet pas de présumer du même résultat pour une autre équipe ou une autre base de code.

Le compositeur statique montre l’utilité de ces contrôles. Anthropic a placé un champ de saisie utilisable dans le HTML initial, pendant le chargement de React. Pour vérifier le relais, ses tests comparaient les versions statique et React à 14 tailles de fenêtre, contrôlaient leur alignement à un pixel près et simulaient la saisie pendant la transition afin de détecter toute perte ou permutation de touches. La télémétrie en conditions réelles mesurait les déplacements pendant ce relais. Un employé a ensuite repéré un déplacement de la mise en page à l’ouverture d’un nouvel onglet que ces mesures n’avaient pas détecté ; Anthropic l’a attribué au redimensionnement du navigateur pendant le chargement spéculatif et a ajouté un test couvrant ce cas.

Le compte rendu d’Anthropic étaye une conclusion précise : ses ingénieurs se sont servis de Claude pour repérer et améliorer des goulets d’étranglement mesurés dans le cadre d’un processus de mise en production dirigé par des personnes, et certains parcours sélectionnés étaient plus rapides à la fin du mois d’août. Il ne permet pas de savoir comment le produit se comporte dans la partie la plus lente de la distribution, si les gains dureront ni quelle part du résultat un observateur indépendant attribuerait à l’agent plutôt qu’aux outils de mesure, au travail d’ingénierie et aux décisions de mise en production de l’équipe.