D’une organisation à l’autre, c’est toujours la même équipe qu’on retrouve, sous un nom différent : RUN, exploitation, production, support N2… Mais sa mission ne varie pas : garantir que la production tourne. Elle répond, elle analyse, elle escalade, elle documente, elle suit, elle relance. Elle tient la production pour des clients qui ne verront jamais l’incident, pour des équipes internes qui attendent leurs données du matin, pour une direction qui ne se penche sur le sujet que le jour où un chiffre dérape.

On lui a confié la responsabilité du RUN. On a oublié de lui donner l’autorité qui va avec.

Ce qu’on lui refuse

Cette équipe ne peut pas décider qu’un service est devenu trop instable pour rester sous sa garde, et le renvoyer à l’équipe qui l’a écrit tant qu’il n’a pas retrouvé un niveau de stabilité tenable. Elle ne peut pas imposer un gel des déploiements sur un composant dont les incidents s’accumulent. Ces décisions-là appartiennent à d’autres.

Alors elle fait ce qu’on lui permet de faire : elle signale, elle remonte, puis elle attend. Elle attend qu’une autre équipe, avec son propre backlog et ses propres priorités, veuille bien corriger le problème de fond. Et le problème de fond, vu depuis un backlog de développement, pèse rarement lourd face à la prochaine feature promise. En attendant, le RUN tient. Parce que c’est son rôle de tenir, et que personne ne mesure ce que tenir coûte.

Le paradoxe de l’expertise

L’ironie, c’est que cette équipe connaît le système presque mieux que tout le monde. À force de le rattraper, elle en a appris les habitudes. Elle voit les patterns se répéter, elle sent venir la crise grâce aux signaux faibles, souvent sans même en avoir conscience, comme on sent qu’un moteur va lâcher au bruit étrange qu’il ne faisait pas hier.

Cette connaissance ne lui ouvre aucune porte. Elle ne pèse dans aucun arbitrage. L’équipe absorbe la pression, travaille beaucoup, et s’use. Elle porte un poids qu’on lui a posé sur les épaules sans lui tendre les leviers pour le soulever.

Ces leviers existent

On pourrait croire que c’est l’ordre naturel des choses : ceux qui construisent décident, ceux qui exploitent encaissent. Sauf que les organisations qui ont pris la fiabilité au sérieux ont écrit exactement le contraire.

Chez Google, le modèle SRE prévoit noir sur blanc le mécanisme que le RUN n’a pas le droit d’imaginer : le give back the pager. Quand un service génère une charge opérationnelle insoutenable, l’équipe SRE peut le rendre à l’équipe de développement, qui en reprend l’astreinte, exclusivement, jusqu’à ce que le service satisfasse de nouveau ses standards. Une équipe SRE de Zurich l’a fait, et l’a documenté ; elle non plus ne croyait pas, au départ, que c’était une option viable.

Même logique pour le second levier : l’error budget, littéralement un budget d’erreurs. Google fixe pour chaque service un seuil de pannes acceptable : tant d’incidents, tant de minutes d’indisponibilité tolérées sur une période donnée. Tant que ce seuil n’est pas atteint, les mises en production continuent normalement ; dès qu’il est dépassé, elles s’arrêtent, et l’équipe se consacre à fiabiliser ce qui existe avant de livrer quoi que ce soit de nouveau. Et le livre SRE le dit sans détour : ce mécanisme ne tient que si l’équipe a l’autorité réelle de stopper les lancements. Sans elle, l’error budget n’est qu’un dashboard de plus.

ITIL, de son côté, pose le verrou en amont. Les service acceptance criteria conditionnent l’entrée d’un service en exploitation : monitoring en place, tests de continuité passés, processus opérationnels validés. Un service qui n’est pas prêt à être exploité n’a rien à faire en production : c’est écrit, c’est outillé, c’est éprouvé. Et le problem management y est une pratique à part entière, distincte de la gestion des incidents : traiter les symptômes au plus vite est un métier, éliminer les causes en est un autre, qui exige ses propres moyens et sa propre autorité. Une équipe qu’on cantonne à éteindre les feux ne videra jamais le bidon d’essence.

La vraie nature du problème

Le modèle de Google contient une nuance qui dit tout. Le give back the pager, le gel des releases : ces mécanismes ne fonctionnent que parce que le management a formellement donné à l’équipe d’exploitation le pouvoir de les déclencher. Sans ce mandat venu d’en haut, rien n’oblige l’équipe produit à respecter un gel ; elle peut continuer à livrer comme si de rien n’était. Et c’est précisément pour ça que le problème du RUN n’est pas technique : il est organisationnel, et il se règle au-dessus des équipes, pas entre elles.

Donner au RUN la responsabilité de la stabilité sans lui accorder les leviers de la stabilité, c’est un choix : celui de payer la fiabilité en heures et en usure humaine plutôt qu’en arbitrages. Ça fonctionne, un temps. Puis les gens qui sentaient venir les crises s’en vont, et l’organisation découvre, incident après incident, tout le chaos que cette équipe retenait en silence, sans qu’on le lui ait jamais demandé.

À ceux qui dessinent ces organisations, la question mérite d’être posée frontalement : si vous ne faites pas confiance à votre équipe RUN pour décider qu’un service est trop instable, pourquoi lui faites-vous confiance pour le tenir à bout de bras ?

Sources