Anthropic a publié le 14 septembre un billet sur son blog d'ingénierie. Son auteur, Sachin Malhotra, y raconte comment un service interne de l'entreprise a été submergé avant d'être entièrement réécrit. Ce service s'appelle test impact analysis (analyse d'impact des tests) et sa mission est plutôt simple : à chaque modification de code entrante, déterminer quels tests doivent tourner et lesquels peuvent être sautés. Cela ressemble à un composant de coulisses, mais la raison de son effondrement est assez révélatrice.
D'abord, quelques multiplicateurs
La première série de chiffres du billet concerne la production : les ingénieurs d'Anthropic livrent désormais en moyenne 8 fois plus de code par trimestre que sur la période 2021-2025, dont 80 % écrit par Claude, qui assure par ailleurs une grande partie de la relecture et de l'approbation des pull requests.
La deuxième série de chiffres concerne la pression : le nombre total de tests dans la base de code a été multiplié par 10, et le nombre de tâches de CI a augmenté de 25 fois en six mois.
La troisième série de chiffres illustre le mieux le rythme de la situation. Pour tenir face à la charge, l'équipe a déployé trois vagues de solutions provisoires, qui ont respectivement acheté 70 jours, 29 jours et moins d'un jour de répit. La troisième solution a été saturée le jour même de sa mise en ligne.
Où l'ancien service coinçait
L'ancienne architecture reposait sur un listener mono-processus, chargé d'écrire le résultat de chaque test dans le stockage, dans l'ordre. Une écriture unique signifie qu'il est impossible de monter en charge horizontalement, et dès que le rythme d'arrivée des pull requests dépassait sa capacité de traitement, la file commençait à s'accumuler. Le billet le formule ainsi : le listener "starts to increasingly fall behind the PR queue" (prend de plus en plus de retard sur la file des PR).
Ce retard entraînait des conséquences en cascade. L'exemple donné dans le billet est qu'un décalage de 20 minutes correspondait à des dizaines de milliers de mises à jour de résultats de tests non encore enregistrées dans le stockage. Or la sélection des tests s'appuie justement sur l'historique des résultats : un historique imprécis rend l'ensemble de tests choisi peu fiable. Pour ne rien arranger, ce processus souffrait aussi d'une fuite mémoire et atteignait son plafond chaque après-midi.
Ce que ça a donné
L'idée de la réécriture était de sortir l'état du processus. La nouvelle architecture introduit un entrepôt de données en mémoire : n'importe quel worker du listener peut traiter n'importe quel résultat, sa seule tâche étant de l'ajouter à un journal, sans conserver d'état propre, ce qui permet d'ajouter des machines au besoin. Un processus consommateur distinct condense en plus ce journal, toutes les quelques secondes, en un historique organisé par test individuel. Quand le sélecteur doit trancher, il interroge directement cet historique.
Le prix à payer est une hausse des coûts. Le billet le reconnaît, en la justifiant par la scalabilité et l'observabilité obtenues — on peut désormais mesurer séparément quelle étape est lente et à quel endroit précisément. Toute la refonte a été réalisée par un seul ingénieur en trois semaines.
Cette courbe du facteur 25
Une multiplication par 25 en six mois équivaut à un taux de croissance composé mensuel d'environ 1,71 fois (calcul approximatif : racine sixième de 25). En extrapolant cette pente sur six mois de plus, on arrive à un facteur 625. La phrase de fin de l'auteur, "always plan for the exponential" (toujours anticiper l'exponentiel), n'est pas une figure de style : elle correspond à une courbe déjà mesurée.
Cette extrapolation n'est bien sûr pas fiable — le taux de croissance peut s'infléchir en fonction des politiques internes, des quotas ou de l'évolution des habitudes d'ingénierie. Anthropic n'a d'ailleurs pas publié le montant absolu de sa facture de CI, n'a pas précisé quelle proportion de tests le nouveau service parvient à filtrer, et n'a donné aucun chiffre sur la latence après la réécriture. Impossible de déduire des informations publiques combien d'argent a été économisé.
En revanche, on voit assez clairement de quel maillon à quel autre la pression se déplace. En avril dernier, GitHub a arrêté les nouvelles inscriptions aux forfaits individuels payants de Copilot, invoquant une consommation de calcul des tâches longues des agents dépassant ce que ces forfaits étaient conçus pour supporter ; plus tôt encore, une vague de commits générés par IA avait déjà provoqué des pannes chez GitHub, poussant Microsoft à emprunter temporairement de la capacité à AWS. Trois épisodes de nature différente, mais qui pointent vers la même chose : la génération de code accélère en premier, puis la relecture, et ensuite chaque système dimensionné pour la vitesse de programmation humaine se fait rattraper, l'un après l'autre. L'analyse d'impact des tests n'est que la première alarme de ce cycle.
Sources : CocoLoop, blog d'ingénierie d'Anthropic ; les multiplicateurs de volume de code, de tests et de tâches de CI, ainsi que la durée des trois solutions provisoires, sont tous tirés des chiffres publiés dans ce billet.