Une facture AWS à 38 000 € en un week-end : qui règle l'addition ?

Contrairement à une coupure de service, l'explosion d'une facture cloud ne déclenche aucune alarme bruyante. Tout fonctionne. Les utilisateurs ne voient rien. Les dashboards sont au vert. Et pourtant, quelque part, un compteur tourne : à chaque seconde, des instances supplémentaires démarrent, des téraoctets transitent, des requêtes s'accumulent. Le client découvre l'ampleur des dégâts plusieurs jours plus tard, à l'arrivée de la facture, quand il est déjà trop tard pour réagir.

C'est précisément ce qui rend ce type d'incident redoutable pour l'administrateur cloud. Vous détenez les clés de l'infrastructure, vous écrivez les règles d'autoscaling, vous déclenchez les déploiements. Quand le montant facturé n'a plus aucun rapport avec le budget annoncé, la première question du client est mécanique : « Qu'avez-vous fait ? »

Prenons un cas concret et réaliste. Un client e-commerce vous confie sa plateforme. Budget mensuel habituel : environ 1 200 €. Un vendredi soir, vous poussez une mise à jour de la configuration Terraform. Une règle d'autoscaling est mal bornée : le nombre maximum d'instances n'est pas plafonné, et un pic de charge — réel ou provoqué par un bot — déclenche la montée en puissance. Le groupe d'auto-scaling grimpe à plusieurs dizaines de machines, qui restent actives tout le week-end. Lundi matin, le compteur affiche un surcoût de plusieurs dizaines de milliers d'euros.

Le réflexe naturel du client est de penser qu'AWS, Microsoft Azure ou Google Cloud annulera la facture « puisque c'est une erreur ». C'est une illusion dangereuse. Le modèle de ces fournisseurs repose sur le paiement à l'usage : vous consommez, vous payez. Les conditions générales sont explicites sur ce point : la responsabilité de la configuration et du contrôle des dépenses incombe au titulaire du compte, c'est-à-dire au client.

Un geste commercial existe, mais il est rare, plafonné, discrétionnaire et réservé en général à un premier incident de bonne foi. Pour une fuite de clés exploitée par un mineur de cryptomonnaie, ou pour une ressource oubliée par un prestataire, la position par défaut est claire : la consommation est due. Le provider n'est pas partie au litige entre le client et son administrateur ; il facture, point.

Conséquence directe : le client qui ne récupère rien auprès de son fournisseur se retourne vers la personne qui a la main sur l'infrastructure. Si l'erreur de configuration vient de vous, vous êtes en première ligne. Et le montant en jeu n'a rien d'un détail : un surcoût cloud peut représenter plusieurs mois, voire plusieurs années de votre marge sur la prestation.

Le point clé à comprendre : ce surcoût n'est pas un « dommage matériel ». Rien n'est cassé, aucun bien n'est détruit. C'est une perte purement financière — un dommage immatériel — et tous les contrats d'assurance ne couvrent pas cette catégorie de la même façon.

Dans le vocabulaire de l'assurance, on distingue trois familles de préjudices. Comprendre cette grille est décisif pour savoir si vous êtes réellement couvert le jour où une facture s'envole.

Une facture cloud qui explose à cause d'une erreur de paramétrage relève de la dernière catégorie : un dommage immatériel non consécutif. C'est l'une des garanties les plus importantes — et les plus souvent absentes ou plafonnées — dans les contrats mal calibrés pour les métiers de l'IT.

Concrètement, si votre RC Professionnelle d'administrateur cloud couvre les dommages immatériels non consécutifs, l'assureur prend en charge l'écart entre la facture normale et la facture réelle, dans la limite du plafond souscrit, après application de la franchise. Si cette garantie est exclue, vous payez de votre poche. La nuance tient à une ligne de votre contrat — et elle peut représenter des dizaines de milliers d'euros.

Les surcoûts cloud ne sortent pas de nulle part. Sur le terrain, on retrouve presque toujours le même petit groupe de causes. Les connaître, c'est déjà réduire fortement le risque de sinistre.

• Autoscaling sans plafond. Un groupe d'auto-scaling sans valeur maximale raisonnable peut multiplier les instances à l'infini face à un pic — réel ou malveillant. C'est la cause la plus coûteuse, car elle s'auto-entretient.
• Trafic egress non maîtrisé. La donnée qui entre est souvent gratuite ; celle qui sort est facturée. Une mauvaise architecture, un transfert massif inter-régions ou un CDN mal configuré peuvent générer des téraoctets d'egress facturés au prix fort.
• Environnements de test laissés allumés. Une plateforme de recette, un cluster Kubernetes de démo ou une base de données provisionnée « pour deux jours » et jamais éteinte tournent silencieusement pendant des semaines.
• Clés d'API ou identifiants fuités. Une clé d'accès poussée par erreur dans un dépôt public est repérée en quelques minutes par des robots, qui démarrent aussitôt des dizaines d'instances pour miner de la cryptomonnaie. La facture grimpe en heures.
• Boucle de script ou job mal borné. Un pipeline CI/CD qui se relance en boucle, une fonction serverless qui s'appelle elle-même, un cron mal écrit : autant de mécanismes qui appellent des ressources facturées en continu.

Le point commun de ces cinq scénarios : ils relèvent tous, à un degré ou à un autre, de la configuration — donc du périmètre de l'administrateur cloud. C'est pourquoi la responsabilité se retrouve si facilement de votre côté.

Toute facture qui explose ne se traduit pas automatiquement par votre condamnation. La question juridique centrale reste : l'erreur vous est-elle imputable, et avez-vous agi en professionnel diligent ?

Si vous avez livré une infrastructure avec des garde-fous (plafonds d'autoscaling, alertes de budget, quotas, secrets correctement gérés), et qu'un facteur extérieur incontrôlable provoque le surcoût, votre position est solide. Si, à l'inverse, vous avez déployé une configuration sans aucun plafond ni alerte, en laissant la porte ouverte à une dérive, la faute devient caractérisée. La différence se mesure souvent à quelques lignes de code d'infrastructure — et à votre capacité à prouver ce que vous aviez mis en place.

D'où trois réflexes de prévention qui valent autant pour votre tranquillité que pour votre défense en cas de litige :

1. Bornez tout. Plafond maximum d'instances, quotas de service, budgets avec alertes automatiques (AWS Budgets, Azure Cost Alerts, GCP Budget Alerts). Une alerte à 80 % du budget transforme un sinistre à cinq chiffres en simple incident résolu en une heure.
2. Tracez vos livraisons. Conservez l'historique de vos configurations (versionnement Terraform, journaux de déploiement). En cas de litige, montrer que la dérive vient d'une intervention postérieure du client, ou d'un facteur externe, change tout.
3. Cadrez le périmètre par écrit. Précisez dans votre contrat de prestation qui surveille les coûts, qui détient les accès, et quelles alertes sont en place. Un partage des responsabilités clair limite votre exposition.

Ces précautions ne suppriment pas le risque, mais elles le réduisent et, surtout, elles vous donnent les preuves nécessaires si le client vous met en cause.

Un surcoût cloud n'est ni une panne, ni une casse : c'est une perte financière sèche qui peut, à elle seule, mettre en danger un indépendant ou une petite structure. Là où une coupure se répare en quelques heures, une facture à cinq chiffres se règle, elle, avec de la trésorerie réelle.

C'est exactement ce que vise la RC Professionnelle d'administrateur cloud d'Insurio lorsqu'elle inclut la garantie des dommages immatériels non consécutifs : la prise en charge des conséquences financières d'une erreur, faute ou omission dans vos prestations d'administration cloud, y compris un surcoût de consommation causé au client, dans la limite du plafond et après franchise. Avant de souscrire, vérifiez noir sur blanc que cette garantie figure bien au contrat et que son plafond est dimensionné pour le profil de vos clients — un grand compte qui consomme lourdement n'expose pas au même montant qu'un petit site vitrine.

Pour mesurer l'ensemble des risques propres à votre activité d'infrastructure, consultez aussi notre page dédiée assurance ingénieur DevOps. Le bon réflexe avant chaque mission : combiner des garde-fous techniques sérieux et une couverture qui prend le relais le jour où, malgré tout, le compteur s'emballe.