Un billion sept pour une facture qui ne dépassait pas 5 $
Le 17 juillet 2026, un utilisateur AWS nommé nprateem a posté sur Hacker News : sa facture mensuelle prévisionnelle AWS affichait 1 700 000 000 $ — 1,7 milliard de dollars. Pour mémoire, sa facture normale tournait autour de 5 dollars par mois.
Il a cru avoir mal lu, a frotté ses yeux. Non, il ne rêvait pas.
L’utilisateur a aussitôt ouvert un ticket d’urgence et lancé sur le fil : “Anyone else seeing this?”
La réponse : oui, et en très grand nombre.
Reddit et X (ex-Twitter) se sont rapidement remplis de captures. Un utilisateur qui n’avait dépensé que 0,19 $ le mois précédent a reçu une facture prévisionnelle approchant 2,5 milliards de dollars. Un autre a écrit sur X : “I just saw $1.5 trillion on my AWS bill. My soul left my body.” Le message a cumulé 1,3 million de vues et près de 19 000 j’aime.
D’autres, paniqués, ont carrément supprimé toutes les ressources de leur compte — “Needless to say, I panicked and nuked everything on that account.”
Ces montants ne correspondaient toutefois à aucun débit réel. AWS a rapidement confirmé que le problème concernait la “facture prévisionnelle”, non les charges effectives. Mais même ainsi, personne n’est resté de marbre en voyant le chiffre.
Que s’est-il réellement passé ?
AWS a donné la cause racine moins de 90 minutes après les faits : “un problème de tarification par unité dans le sous-système de calcul des factures prévisionnelles”. Derrière la formule alambiquée, le fond est simple : une unité a été écrite de travers.
C’est un ancien ingénieur AWS, donavanm, qui a vraiment éclairci l’affaire. Dans les commentaires de Hacker News, il a écrit ceci (traduit de l’anglais) :
“I handled the exact same error when I was at AWS. This is a units error. We intended to charge $0.05/GB, but left off the unit (GB), and the billing system defaulted to byte. $0.05 per byte of data transfer means some customers saw million-dollar bills within hours. Paged by the on-call at 2am, fixed and shipped by 3-4am, then sent apology emails.”
Ce passage en dit long :
Premièrement, ce n’est pas la première fois. Le même type d’erreur est déjà arrivé — et sans doute plus d’une fois.
Deuxièmement, le facteur de grossissement est stupéfiant. 1 Go = 1 073 741 824 octets. Si l’on oublie d’écrire “Go”, le système facture par défaut à l’octet, et la facture gonfle d’un milliard de fois. Une utilisation à 0,05 $ devient 53 687 091,20 $.
Troisièmement, l’erreur n’est détectée par aucun contrôle automatique avant la mise en production. Elle a traversé le développement, les tests et le déploiement, jusqu’à ce que les utilisateurs voient la capture, paniquent et postent — c’est ainsi qu’elle a été repérée.
Pourquoi une “unité oubliée” franchit-elle toutes les défenses ?
C’est là le plus inquiétant.
donavanm a détaillé le fonctionnement de la facturation AWS. Les données de mesure (ressources consommées) et les informations de tarification (prix par unité) sont stockées séparément. Chaque SKU (chaque ligne de facturation) est défini dans un “plan tarifaire” comprenant le type d’unité, la région applicable, le prix unitaire, etc. Les enregistrements de mesure et les plans tarifaires sont appariés via l’ID de compte, la région, le numéro de SKU, et d’autres champs.
Si le type d’unité du plan tarifaire est mal saisi — Go au lieu de vide ou d’octet — la conversion entre mesure et tarif se corrompt. Et aucun contrôle automatique ne peut l’intercepter.
Un autre commentateur HN a mis le doigt dessus :
“No tests? A trivial detail got misconfigured — and then hundreds of thousands of admins got a bill that gave them a heart attack?”
Un autre a répondu :
“Of course there are tests. Test 1 verifies the service emits its metering data correctly (‘we ran 100 bytes of operations, confirmed the billing system received 100 bytes of data, pass’). Test 2 confirms the billing system’s computation logic (‘feed SKU#12345 100 GB units, compute $17, pass’). But no one runs these two test suites together — because that spans different teams and different layers of management, and is therefore harder to do.”
L’explication est fine. Elle révèle un travers classique du management technique : chaque maillon fonctionne isolément, mais l’ensemble coince. Un utilisateur HN y a ajouté : “Someone said in some meeting ‘we should make the tests actually walk through the billing flow’, and then someone said ‘having tests actually generate real billing charges could be a legal/financial problem, even potentially criminal’ — and then no one followed up on what the second-best alternative should be.”
Le vrai “méchant” : la complexité de la facturation cloud
Réduire l’affaire à “un ingénieur distrait a mal configuré un truc” manquerait la leçon.
Le véritable méchant, c’est la complexité du système de facturation cloud lui-même.
AWS compte environ 300 000 SKU différents. Pas 300, 300 000. Chaque SKU a sa propre logique tarifaire — au temps, au trafic, au nombre de requêtes, à la capacité de stockage, à la région. Ils se superposent : une simple requête web peut déclencher des frais de calcul, de transfert réseau, de lecture de stockage, de journalisation, de monitoring… chacun avec son unité et ses règles.
La production des données d’usage et la configuration des tarifs sont deux systèmes totalement indépendants. Leur appariement repose sur des champs, non sur des validations en dur. Rien à redire au design en soi — il offre à AWS une flexibilité maximale pour ajuster les prix sans toucher au système de mesure. Mais au prix d’une conséquence : personne ne comprend pleinement “combien mon opération me coûtera au final”.
À tel point qu’un métier est né pour décrypter les factures AWS : le consultant en optimisation des coûts cloud. Qu’une activité de plus de 100 milliards de dollars de chiffre annuel nécessite des “traducteurs” pour dire aux clients ce qu’ils dépensent en dit long.
Jusque dans la discussion HN, des ingénieurs AWS ont admis des faits troublants. Un ancien employé : “Toute l’entreprise ressemble à une machine de Rube Goldberg — peu de gens se soucient de ce qui se passe hors de leur petit périmètre, faute d’incitation à le faire.”
Un autre ancien a ajouté : “Je suis passé en plan d’amélioration des performances (Focus) parce que ma ‘contribution n’était pas visible par la direction’. Dans un tel environnement, en voyant un risque dans le code d’un collègue, je n’ai aucune raison d’aller le signaler et le corriger — si je le fais, au moment de l’évaluation annuelle un certain pourcentage sera tout de même classé ‘inefficace’, alors pourquoi ce ne serait pas le collègue qui a laissé le bug ?”
Des voix divergent. Un ancien manager a rétorqué : “Tout impact client de cette ampleur déclenche un rapport COE (correction d’erreur), c’est-à-dire une ribambelle d’actions correctives obligatoires, au bas mot un mois de travail pour une personne. Le COE est une telle plaie pour toute l’équipe qu’il crée en soi une forte motivation à éviter le problème.”
Je ne prends pas parti. Les deux versions peuvent être vraies — selon le département et le niveau hiérarchique, la culture diffère. Mais cela prouve justement ceci : dans une organisation de dizaines de milliers d’ingénieurs, même quand tous veulent bien faire, une faille systémique peut passer à travers les mailles.
Comment AWS a réagi ?
D’après la chronologie publique du tableau de bord Health Dashboard :
- 17 juillet, 3:52 PDT : AWS confirme la cause racine (“problème de tarification par unité dans le sous-système de calcul des factures prévisionnelles”) et suspend le calcul des prévisions.
- 4:58 : deux pistes de correction simultanées — annuler le dernier changement, ou restaurer les dernières données exactes.
- 5:54 : la supervision interne montre que le sous-système produit de nouveau des prévisions correctes ; validation en cours.
- 7:53 : mauvaise nouvelle — l’annulation n’a pas résolu le problème, les deux pistes continuent. La mise à jour des prévisions reste suspendue.
- 9:59 : cause racine identifiée et corrigée, recalcul des factures pour tous les clients lancé. Certains clients devraient voir la restauration sous 3 heures, tous avant midi le 18 juillet.
- 12:56 : plus lent que prévu. Restauration complète repoussée à 19 juillet, tôt le matin. Précision : “les prévisions affichées ne reflètent ni l’usage réel ni les frais. Aucune action requise des clients.”
Réparer un bug “d’unité oubliée” a coûté à AWS plus de 24 heures — et la première tentative a échoué. Ce qui revient à dire : même les ingénieurs d’AWS peinent à corriger les bugs de leur propre système.
Qu’est-ce que cela signifie ?
Au final, aucune perte financière réelle — personne n’a été surfacturé. Mais le problème révélé est bien plus profond que “un ingénieur distrait”.
Premièrement, la facturation cloud est devenue un système que personne ne comprend pleinement. AWS en est l’exemple le plus extrême, mais Google Cloud et Microsoft Azure partagent le même problème. Quand la complexité d’un système dépasse la compréhension de tout individu, il cesse d’être un outil maîtrisable pour devenir une boîte noire qu’on “observe, devine, et prie pour qu’elle ne casse pas”.
Deuxièmement, l’ère de l’IA relève la mise. La semaine même, AWS annonçait 1 milliard de dollars investis dans une équipe d’ingénieurs IA orientée client. La facture mensuelle d’une seule tâche d’entraînement IA peut atteindre des centaines de millions. Quand les montants réels deviennent si colossaux, une erreur de facturation — fût-elle “prévisionnelle” — provoque une panique et une perte de confiance bien plus graves qu’autrefois.
Troisièmement, ce bug n’est ni le premier ni le dernier. L’ancien ingénieur donavanm l’a lui-même vécu, réveillé à 2 h du matin pour le corriger. La faille existe dans les systèmes AWS depuis au moins plusieurs années, s’est produite au moins deux fois, et a déclenché à chaque fois une panique générale — sans jamais être colmatée systématiquement.
En y repensant, je revois la phrase de donavanm décrivant l’architecture : “les données de mesure du service ne sont pas directement liées au prix.” En clair : entre votre consommation et votre facture, il y a au moins deux couches de correspondances à configurer manuellement. Qu’un seul niveau soit mal saisi, et 5 $ deviennent 1,7 milliard.
Liens de référence
- Fil HN : discussion sur l’inexactitude des factures prévisionnelles AWS ; nprateem y publie la capture du billion sept, déclenchant 992 points et 618 commentaires (item?id=48945241)
- Analyse de cause racine par donavanm, ex-ingénieur AWS : explique comment une erreur d’unité de tarification (octet vs Go) a fait gonfler la facture d’un milliard de fois, et l’architecture séparant mesure et tarif
- Annonce AWS Health Dashboard : la chronologie complète de l’incident “Billing Console — données de facturation prévisionnelle inexactes”
- Reportage The Next Web : portée de l’événement, réactions Reddit (0,19 $ → 2,5 Mds $) et calendrier de correction AWS
- Reportage Cyber Kendra : cite la capture du bill de 1,5 billion de @Bharath_uwu sur X et la réponse officielle AWS Support
- Reportage TechRadar : titre “My soul left my body”, recueille les réactions de panique, dont le cas limite de celui qui a tout supprimé
