EN

TYPE D’ACTION · LIVRER UN CHANGEMENT

Des changements qui arrivent en production parce que le pipeline a dit oui.

Poussées de configuration, versions, changements d’infrastructure, indicateurs de fonctionnalité. Les agents de code et les robots de publication déploient déjà ; les règles de gestion du changement existent, et c’est dans le pipeline qu’elles sont censées tenir.

Qui l’exécute aujourd’hui : Agents de code IA, robots de publication, pipelines d’infrastructure en code.

Les règles qui l’encadrent d’habitude

  • Seulement dans une fenêtre de changement approuvée
  • Revu par une autre personne que l’auteur
  • Un plan de retour arrière signé pour les systèmes critiques
  • Aucun changement pendant un gel déclaré

Des formes de règles typiques, pas une affirmation sur une organisation en particulier. Un pilote part des vôtres.

Où ce genre de règles casse

  1. L’approbation visait un autre changement.

    Une revue approuve un diff. Si ce qui part n’est pas lié au diff approuvé, l’approbation voyage vers des changements que personne n’a lus.

  2. La fenêtre est vérifiée par ce qu’elle contraint.

    Un pipeline qui décide s’il est dans la fenêtre peut être amené à décider autrement. Le contrôle appartient devant l’action, pas dedans.

Ce que fait la barrière

  1. 01

    Vérifie chaque demande contre la politique prouvée avant son exécution. Ce qui échoue n’atteint jamais le système.

  2. 02

    Refuse quand une fenêtre ou une population dont dépend la règle manque ou ne concorde pas, au lieu de deviner.

  3. 03

    Scelle chaque décision, autorisée ou bloquée, pour qu’elle soit revérifiable sans nous.

Ce que vous pouvez vérifier aujourd’hui

PAS ENCORE

Rien de public encore pour ce type d’action. Les décisions de l’accueil sont illustratives, sous une politique d’exemple. C’est d’un pilote que viendrait le premier dossier scellé pour les déploiements.

DÉMARRER UN PILOTE