Bill shock cloud : qui paie la facture AWS qui explose à 80 000 € ?

Le bill shock cloud est l'angoisse silencieuse de tout architecte AWS, Azure ou GCP. Contrairement à une panne ou à une fuite de données, rien ne casse, rien ne s'arrête : tout fonctionne parfaitement. Le seul symptôme est une facture mensuelle qui passe brutalement de quelques milliers d'euros à plusieurs dizaines de milliers, sans que le métier du client n'ait changé d'un iota.

Les causes sont presque toujours des décisions d'architecture : une instance db.r6g.16xlarge provisionnée pour un pic de migration et jamais redimensionnée, des transferts de données inter-régions ou sortants (egress) non maîtrisés, un cluster Kubernetes dont l'autoscaler n'a pas de borne haute, ou des snapshots et logs jamais purgés qui s'accumulent en stockage premium. Aucun de ces choix n'est un bug. Ce sont des fautes de conception ou d'optimisation, et c'est précisément ce qui les rend juridiquement délicats.

La particularité de ce sinistre est qu'il produit un dommage immatériel pur : un préjudice financier qui ne découle d'aucun dommage corporel ni matériel. C'est exactement le type de préjudice que les assurances multirisques classiques et la plupart des RC Pro généralistes excluent de leur garantie. Pour un architecte, c'est le trou de couverture le plus dangereux.

Tous les dépassements de budget ne se valent pas devant un expert. Voici les trois schémas les plus fréquents que nous voyons remonter en sinistre.

1. L'oubli post-migration

Vous dimensionnez large pour absorber une migration sans risque, avec l'intention de réduire ensuite. Le projet se clôture, la phase de rightsizing n'est jamais facturée ni planifiée, et le client paie pendant six mois une infrastructure trois fois trop grande. Le préjudice est l'écart entre la facture réelle et la facture optimisée attendue.

2. Le service mal choisi

Vous orientez le client vers un service managé coûteux (par exemple une base relationnelle managée premium) là où un design alternatif aurait divisé le coût par cinq pour le même besoin. C'est un défaut de conseil sur le choix de service.

3. L'absence de garde-fou FinOps

Aucune alerte de budget, aucun quota, aucun plafond d'autoscaling. Une erreur de configuration côté client (ou une boucle applicative) provoque une explosion de consommation que rien n'a stoppée. Ici, la responsabilité est partagée, et c'est ce partage qui se négocie en expertise.

Quand un client réclame le remboursement d'un sur-coût, le débat ne porte presque jamais sur le montant de la facture (elle est documentée à la seconde par le fournisseur cloud). Il porte sur une seule question : le surcoût découle-t-il de votre design ou d'un usage que vous ne pouviez pas anticiper ?

Un architecte n'a pas d'obligation de résultat sur la facture finale : il a une obligation de moyens sur la qualité de l'architecture et du conseil. Si le client a lancé des traitements massifs non prévus dans le cahier des charges, augmenté le volume de données par dix sans vous consulter, ou ignoré vos recommandations d'optimisation, votre responsabilité s'effondre — à condition de pouvoir le prouver.

La traçabilité de vos décisions d'architecture est votre meilleure défense. Un sur-coût indéfendable se transforme en sinistre indemnisable quand le dossier d'architecture démontre où s'arrête votre mission.

C'est pourquoi vos livrables HLD/LLD doivent toujours mentionner les hypothèses de charge retenues, les volumes de données projetés, et les recommandations FinOps formulées. Sans ce socle, vous êtes présumé responsable de l'intégralité de l'écart.

La meilleure assurance commence avant le sinistre, dans la manière dont vous cadrez votre mission. Voici les clauses et pratiques qui font la différence en expertise.

• Hypothèses de charge écrites : documentez les volumes, le nombre d'utilisateurs et le profil de trafic retenus pour le dimensionnement.
• Recommandation FinOps formelle : alertes budgétaires, quotas, plafonds d'autoscaling, et tags de coût livrés en standard.
• Périmètre de mission borné : précisez si vous concevez seulement, ou si vous exploitez et optimisez dans la durée (run vs build).
• Clause de limitation de responsabilité : plafonnez votre engagement à un multiple des honoraires de la mission.
• Validation client documentée : faites valider chaque choix de service structurant par écrit.
• Alerte de dérive obligatoire : prévoyez qui surveille la facture en exploitation, vous ou le client.
• Réserve sur les usages non prévus : excluez explicitement les traitements ajoutés sans nouvelle étude d'architecture.

Ces réflexes ne suppriment pas le risque : ils le rendent assurable et chiffrable. Pour comprendre l'ensemble des situations couvertes par votre garantie, consultez notre page dédiée à l'assurance RC Pro.

La perversité du bill shock tient à son inertie. Contrairement à une panne qui se voit immédiatement, une dérive de coût s'installe en silence. Une instance surdimensionnée ne déclenche aucune alarme : elle fonctionne, elle répond, elle facture. Le sur-coût n'est souvent détecté qu'au moment de la clôture comptable mensuelle, voire trimestrielle, quand le directeur financier du client découvre la ligne cloud.

Ce décalage temporel a deux conséquences redoutables pour l'architecte. D'abord, le préjudice s'accumule : ce n'est pas un mois de sur-facturation qui est réclamé, mais parfois quatre, six ou huit mois de dérive cumulée. Ensuite, la prescription du sinistre et la datation de la faute deviennent un sujet d'expertise à part entière : la faute a-t-elle été commise à la livraison du design, ou se renouvelle-t-elle chaque mois où vous auriez dû alerter ?

C'est aussi pour cela que la frontière entre build (la conception) et run (l'exploitation) est si décisive. Si votre mission s'arrête à la livraison du dossier d'architecture, vous n'avez aucune obligation de surveiller la facture qui dérive ensuite. Mais si vous avez accepté une mission d'optimisation continue ou de FinOps managé, alors le silence devient une faute : vous deviez voir la dérive et la signaler. Beaucoup d'architectes signent des missions hybrides sans mesurer que la composante run étend leur responsabilité dans le temps bien au-delà de la livraison initiale.

Un mois de sur-coût est une anomalie. Huit mois de sur-coût non signalés, c'est un défaut de surveillance — et la nuance se chiffre en dizaines de milliers d'euros.

Quand votre responsabilité est engagée pour un sur-coût cloud, la RC Pro IT senior intervient sur le poste que les autres contrats laissent de côté : le dommage immatériel non consécutif, c'est-à-dire le préjudice financier du client qui ne découle d'aucune casse physique.

Concrètement, l'assureur missionne un expert technique qui reconstitue la facture optimisée théorique, isole la part imputable à votre faute de conception, et chiffre le préjudice réel. C'est cette part — et non l'intégralité de la sur-facturation — qui est indemnisée. Les frais de défense, souvent sous-estimés, sont également pris en charge dès la réclamation.

Pour un architecte freelance ou en cabinet, le plafond souscrit se situe généralement entre 500 000 € et 2 M€, à calibrer sur la criticité de vos missions. Si vous intervenez sur des plateformes e-commerce ou SaaS à fort trafic, où un mois de sur-coût peut atteindre six chiffres, le plafond bas est une fausse économie. Vous pouvez retrouver l'ensemble de vos garanties et tarifs sur la page assurance architecte systèmes, réseaux et cloud.