Budget d'erreur (SLO)
Un budget d'erreur est la part de panne qu'un produit s'autorise sur une période, déduite de son objectif de disponibilité. Tu vises 99,9 % de disponibilité sur le mois : le budget d'erreur est le 0,1 % restant, l'enveloppe d'indisponibilité que tu peux dépenser sans manquer à ta promesse. L'objectif s'appelle un **SLO** (*service level objective*) ; le budget est l'écart entre cet objectif et 100 %. Ce qui en fait une règle de décision plutôt qu'un chiffre de tableau de bord, c'est la politique qui l'accompagne : tant qu'il reste du budget, on livre des fonctionnalités ; une fois le budget consommé, on suspend les mises en production qui ne sont pas des correctifs de fiabilité ou de sécurité, jusqu'à ce que le service revienne dans son objectif. Google, qui a formalisé la pratique dans ses livres SRE, y voit « une mesure claire et objective » de l'instabilité tolérée et « une incitation commune » pour l'équipe produit, jugée sur sa vitesse, et l'équipe d'exploitation, jugée sur la fiabilité : la même mesure arbitre pour les deux, et l'équipe produit « s'autodiscipline ». Un budget se consomme de deux manières : par incident (une heure de panne mange une heure de budget) et par érosion lente (un taux d'erreurs de 0,2 % qui traîne tout le mois). D'où sa place au dernier palier des sept étapes d'une chaîne DevOps (dépôt de code, intégration et livraison continues, conteneurs, infrastructure décrite en code, orchestration, métriques, puis budget d'erreur) : il suppose qu'on mesure déjà la disponibilité contre une référence historique, sinon il n'y a rien à dépenser ([reel Instagram DfNcLvbhL0X](https://www.instagram.com/reel/DfNcLvbhL0X/), Technology Brief, vidéo relevée le 9 novembre 2026).