Budget d'erreur (SLO)
An error budget is the share of failure a product allows itself over a period, derived from its availability target. You aim at 99.9% availability for the month: the error budget is the remaining 0.1%, the downtime allowance you can spend without breaking your promise. The target is called an **SLO** (*service level objective*); the budget is the gap between that target and 100%. What turns it into a decision rule rather than a dashboard number is the policy attached to it: while budget remains, you ship features; once it is spent, you hold back any release that is not a reliability or security fix, until the service is back within its objective. Google, which formalised the practice in its SRE books, calls it "a clear, objective metric" of how unreliable the service is allowed to be and "a common incentive" for the product team, measured on velocity, and the operations team, measured on reliability: one number arbitrates for both, and the product team "becomes self-policing". A budget burns in two ways: through incidents (an hour of outage eats an hour of budget) and through slow erosion (a 0.2% error rate that lingers all month). Hence its place at the last of the seven DevOps stages (source control, continuous integration and delivery, containers, infrastructure as code, orchestration, metrics, then error budgets): it assumes you already measure availability against a historical baseline, otherwise there is nothing to spend ([Instagram reel DfNcLvbhL0X](https://www.instagram.com/reel/DfNcLvbhL0X/), Technology Brief, video captured on 9 November 2026).