ZAF / CHAPITRE 12 / 15

Gouvernance, responsabilité plateforme et exploitation

Édition publique de référence 1.0 · 5 novembre 2026 · Exemple institutionnel fictif. Aucun résultat client ou déploiement n’est revendiqué.

Dans ce chapitre
  1. 12.1 Organiser les décisions
  2. 12.2 Responsabilités
  3. 12.3 Cycle de décision
  4. 12.4 Exploiter après transfert
  5. 12.5 Validation

12.1 Organiser les décisions

La gouvernance nomme qui décide, fournit les preuves, exploite et accepte une exception. Elle doit correspondre aux personnes disponibles. Dans l’équipe fictive de deux ingénieurs, plusieurs rôles peuvent être réunis. Les responsabilités restent distinctes et les décisions critiques nécessitent un contrôle adapté. Une capacité plateforme n’impose pas un département séparé.

12.2 Responsabilités

ActivitéAutorité accountableRéalisationConsultation
Politique métierPropriétaire métierResponsable domaineFinance et contrôle
Définition et conservationPropriétaire des donnéesSteward et exploitantAutorité juridique ou politique
LivraisonResponsable systèmeIngénieur livraisonMétier et support
Exception d’architectureAutorité habilitéeÉquipe proposanteConsommateurs affectés
IncidentResponsable systèmeCoordinateur nomméMétier et sécurité
Risque résiduelAutorité institutionnelleCoordinateur des risquesArchitecte et exploitants

Une cellule vide ne transfère pas la responsabilité au fournisseur. Le contrat précise délégations et responsabilités conservées.

12.3 Cycle de décision

Figure 12.1 · Cycle des décisions d’architecture
Cycle des décisions d’architectureLa décision conserve justification et conséquences. Un déclencheur ouvre une nouvelle revue sans réécrire silencieusement l’historique.ProposerContexte et preuvesExaminerResponsables affectésAccepter ou refuserAutorité habilitéeRéaliserResponsable nomméVérifierPreuves d’acceptationRéexaminerDéclencheur ou contexte
La décision conserve justification et conséquences. Un déclencheur ouvre une nouvelle revue sans réécrire silencieusement l’historique.

Un enregistrement conserve contexte, preuves, options, recommandation, conséquences et déclencheur de revue. Distinguer proposé, accepté, remplacé et retiré. Une modification locale peut recevoir une revue légère ; un contrat interdomaines ou une destination sensible demande une autorité plus large. Adapter la revue aux conséquences.

12.4 Exploiter après transfert

Définir horaires, support, escalade, accès, correctifs et exercices de reprise. La réponse à l’incident comprend communication et rapprochement des résultats incertains. Le runbook précise prérequis, droits, actions, vérifications et escalade. Le tester avec une autre personne si possible.

12.5 Validation

Livrer droits de décision, contrats de service, exceptions temporaires et responsabilités opérationnelles. Un incident simulé doit trouver un décideur et une réponse, pas seulement un organigramme.