Amazon dépense 1,8 million de dollars avec Claude, une tâche banale dépasse son budget de 860 %

Une tâche de programmation décrite comme banale a généré une facture d’environ 1,8 million de dollars chez Amazon après avoir été confiée à Claude. L’épisode montre comment un agent de code peut transformer quelques modifications automatisées en dépense hors de contrôle lorsque chaque appel au modèle, chaque test et chaque nouvelle tentative s’accumulent sans plafond efficace.

Une petite tâche, une facture de grande entreprise

Amazon a découvert qu’une mission de programmation menée avec Claude, le modèle d’IA développé par Anthropic, avait largement dépassé son enveloppe initiale. Selon les informations rapportées par TechRadar, le coût final aurait atteint environ 1,8 million de dollars, soit un dépassement de budget de 860 %.

La tâche en question n’aurait rien eu d’exceptionnel sur le plan technique. Il ne s’agissait pas de concevoir un nouveau produit ou de résoudre un problème scientifique complexe, mais d’effectuer un travail de programmation considéré comme menial, c’est-à-dire subalterne ou routinier. C’est précisément ce contraste qui rend l’incident révélateur : la dépense ne provient pas nécessairement d’une difficulté exceptionnelle, mais de la manière dont l’agent exécute et répète ses opérations.

Pris au sens strict, un dépassement de 860 % signifie que la dépense totale représente environ 9,6 fois le budget initial. Une facture de 1,8 million de dollars correspondrait alors à une enveloppe prévue d’environ 187 500 dollars. Le chiffre donne une idée de l’ampleur de l’écart, même si les modalités exactes du calcul budgétaire n’ont pas été détaillées publiquement.

Le coût ne vient pas d’un seul appel

Un modèle comme Claude ne facture pas une tâche complète à un prix fixe. La consommation dépend notamment du volume de texte traité, du nombre de requêtes, de la longueur du contexte et des opérations déclenchées par l’agent.

Dans un flux classique, un agent de code peut :

• analyser un dépôt logiciel ;
• formuler un plan ;
• modifier plusieurs fichiers ;
• lancer des tests ;
• interpréter les erreurs ;
• corriger son code ;
• relancer les tests ;
• demander une nouvelle analyse au modèle.

Chaque étape peut entraîner un ou plusieurs appels supplémentaires. Une erreur d’interprétation, un test instable ou une stratégie de correction inefficace peut alors provoquer une boucle d’exécution. Le modèle ne se contente plus de répondre à une question : il agit sur un environnement, observe le résultat et recommence jusqu’à atteindre un objectif — ou jusqu’à ce qu’un mécanisme externe l’arrête.

Le risque financier est donc moins lié au tarif d’une requête isolée qu’à la multiplication des requêtes. Une opération peu coûteuse peut devenir très chère si elle est répétée des milliers de fois, avec un contexte de plus en plus volumineux. Les systèmes capables d’appeler des outils, de lancer des commandes ou de déléguer des sous-tâches rendent cette accumulation plus difficile à repérer qu’une simple utilisation conversationnelle.

Le problème est d’abord celui de la gouvernance

L’incident ne permet pas, à lui seul, de conclure que Claude aurait produit un code inutilisable ou que le modèle aurait « halluciné » pendant des heures. Les informations disponibles ne détaillent pas la séquence exacte ayant conduit à la facture. Elles ne précisent pas non plus si le dépassement vient d’un grand nombre de tentatives, de contextes particulièrement longs, de tests répétés ou d’une configuration défaillante de l’agent.

En revanche, le cas met en évidence une faiblesse structurelle : déléguer une tâche à une IA autonome sans appliquer les mêmes contrôles qu’à une infrastructure informatique classique. Une entreprise surveille normalement ses serveurs, ses bases de données et ses services cloud à l’aide de budgets, d’alertes et de quotas. Un agent de code doit être soumis à des garde-fous comparables.

Un budget global mensuel ne suffit pas. Il faut pouvoir fixer une limite par tâche, par projet ou par utilisateur, avec un arrêt automatique lorsque le seuil est atteint. Des alertes doivent également signaler les comportements anormaux : hausse soudaine du nombre d’appels, répétition d’une même commande, augmentation rapide du volume de tokens ou durée excessive d’une session.

Sans ces mécanismes, l’autonomie devient une forme de dépense autorisée par défaut. L’agent peut continuer à travailler parce qu’il est techniquement capable de le faire, et non parce que chaque nouvelle tentative reste économiquement justifiée.

L’automatisation doit être mesurée comme une infrastructure

Le cas Amazon intervient alors que les entreprises déploient des assistants capables d’écrire du code, de corriger des incidents et d’exécuter des tâches dans des environnements de développement. Ces outils promettent de réduire le temps consacré aux opérations répétitives, mais leur rentabilité dépend d’une mesure précise du coût complet.

Le calcul ne doit pas se limiter au prix affiché par le fournisseur du modèle. Il doit intégrer le nombre d’appels, les étapes de validation, les services utilisés en parallèle, le stockage des contextes et le temps d’intervention humaine nécessaire pour vérifier le résultat. Une automatisation qui économise deux heures de travail mais consomme plusieurs dizaines de milliers de dollars n’est pas une automatisation rentable.

La supervision humaine reste également nécessaire aux étapes sensibles. Un agent peut être autorisé à lire un dépôt ou à proposer un correctif, puis devoir obtenir une validation avant de lancer une campagne de tests coûteuse. Des limites peuvent être appliquées aux commandes exécutables, à la taille des fichiers analysés et au nombre de tentatives successives. Dans certains cas, un mode dry run — qui simule l’action sans l’exécuter — permettrait d’identifier une boucle avant qu’elle ne génère une facture importante.

Cette discipline vaut aussi pour les équipes internes. L’accès à un modèle puissant ne doit pas être traité comme une ressource infinie simplement parce que son paiement est centralisé par la direction informatique. Les tableaux de bord doivent associer la dépense à une tâche, à un produit et à un résultat mesurable.

Le prochain test sera celui du contrôle des dépenses

L’affaire rapportée par TechRadar et relayée par Techmeme ne constitue pas seulement une anecdote coûteuse. Elle fournit un indicateur concret du risque associé aux agentsic workflows, ces chaînes d’actions où un modèle décide lui-même des étapes à exécuter.

Pour éviter qu’une tâche ordinaire ne produise une nouvelle facture à sept chiffres, les entreprises devront instaurer des plafonds stricts, des alertes à plusieurs niveaux, des validations humaines et un arrêt automatique après un nombre défini de tentatives. Le prochain jalon attendu est la clarification, par Amazon, de la séquence exacte ayant conduit aux 1,8 million de dollars. Pour les autres organisations, le test est immédiat : démontrer que chaque agent dispose d’un budget par mission et qu’aucune boucle ne peut continuer sans limite.