Reprendre le contrôle d’une plateforme Kubernetes avant une release critique

Le problème réel

La plateforme fonctionnait. C’est précisément ce qui rendait la situation dangereuse : aucune panne franche ne forçait l’organisation à traiter les zones grises.

À l’approche d’une release métier à date fixe, produit et plateforme pouvaient décrire les clusters, les composants et les alertes. En revanche, plusieurs questions essentielles restaient sans réponse nette : qui décide qu’un risque est acceptable, qui agit lorsqu’un composant partagé devient le point de défaillance, et qui porte la décision de go/no-go ?

Le risque n’était donc pas d’abord technique. Il était dans l’interface entre architecture, exploitation et responsabilité.

Ce que nous avons trouvé

L’observabilité existante permettait de voir des symptômes, mais pas toujours de relier ces symptômes à un propriétaire et à une décision.

En parallèle, le backlog plateforme continuait d’accumuler des fonctionnalités. Ajouter encore une capacité cluster aurait augmenté la surface technique sans résoudre le problème le plus urgent : l’ambiguïté sur les responsabilités en situation de changement ou d’incident.

Notre intervention

Nous avons ramené le sujet à trois objets simples :

1. les décisions nécessaires pour autoriser la release ;
2. les modes de défaillance pouvant remettre ces décisions en cause ;
3. le propriétaire attendu pour chaque action et arbitrage.

Cette cartographie a permis de distinguer les responsabilités de plateforme des objectifs de service produit, puis de transformer les zones grises en une matrice de responsabilité, un journal de décisions et un backlog de remédiation priorisé.

L’arbitrage

Le choix important n’a pas été d’ajouter un nouvel outil ou une nouvelle capacité Kubernetes.

Il a été de ralentir temporairement certains travaux de plateforme pour traiter d’abord les trous de responsabilité qui augmentaient le risque de release.

Ce qui a changé

Les équipes disposaient d’un langage commun pour discuter du risque de changement. Les critères de release sont devenus explicites, et le backlog plateforme a été réordonné autour des décisions et responsabilités à sécuriser en priorité.

La plateforme n’a pas été reconstruite. Le système de décision autour d’elle a été rendu plus clair.

Ce que nous retenons

Sur une plateforme partagée, une capacité technique sans propriétaire explicite peut augmenter la complexité plus vite qu’elle n’augmente la fiabilité.

Avant d’ajouter une fonctionnalité, il faut pouvoir répondre à une question plus basique : qui prend la décision quand cette fonctionnalité devient critique ?