Le mot gouvernance évoque encore une salle pleine et une réponse après le début du projet. Dans mon rôle d’architecte, je veux réserver le contrôle collectif aux choix qui créent une dépendance longue : identité, source de vérité, exposition publique, protocole, données sensibles et coût récurrent.

Une décision d’architecture utile garde contexte, options, choix, conséquences et date de revue. Elle est petite, versionnée et reliée au système. Le comité ne redessine pas la solution; il vérifie les risques qui dépassent l’équipe.

Trois chemins selon la réversibilité

Je classerais les décisions :

1. locale et réversible : librairie interne, laissée à l’équipe avec tests;
2. partagée : schéma d’événement ou plateforme, revue par les consommateurs;
3. engageante : fournisseur, identité, donnée réglementée, revue formelle et propriétaire.

Pour exposer une API client, le dossier contient modèle de menace, données, authentification, limites, propriétaire, reprise et coût. Le résultat peut être accepté, accepté avec échéance ou à reprendre. Une échéance sans responsable n’est pas une décision.

Les standards devraient offrir un chemin pavé : modèles de pipeline, identité, logs, secrets et alertes. Une exception décrit pourquoi le chemin ne convient pas, sa durée et son plan de sortie. Compter les exceptions sans comprendre leur motif cache les vrais problèmes du standard.

La gouvernance doit recevoir du feedback

Une règle peut devenir fausse. Je mesurerais délai de décision, nombre d’exceptions répétées, incidents reliés et coût. Si toutes les équipes demandent le même écart, le standard mérite une mise à jour. Si la revue arrive après la livraison, son point d’entrée est trop tardif.

Le registre doit rester consultable. Une nouvelle équipe retrouve pourquoi un protocole ou fournisseur a été choisi. Les décisions portant sur sécurité et reprise sont testées : rotation de secret, export de données, bascule et révocation. Le document seul ne protège rien.

Les urgences ont un chemin : décision temporaire par une autorité connue, limites, journal et revue après coup. Elles ne deviennent pas automatiquement permanentes. Les privilèges accordés pour l’incident expirent.

Expirer automatiquement les dérogations techniques

Une exception permanente devient un standard parallèle. Je lui donnerais un identifiant, une portée, un risque, un contrôle compensatoire et une date. Trente jours avant l’échéance, le propriétaire doit renouveler avec preuve ou fermer. Les règles de pipeline peuvent avertir qu’un certificat faible, une image ancienne ou un accès réseau dépend de cette exception. À l’expiration, on ne casse pas aveuglément une production : on escalade selon la criticité et bloque les nouveaux déploiements concernés. Le registre calcule les dérogations répétées par cause. Cette mécanique distingue une transition honnête d’une dette sans fin et fournit des faits pour améliorer le chemin standard.

Je mettrais une revue de trente minutes au moment où deux options réelles existent encore, avec une page de contexte et une personne qui tranche. Tout ce qui peut être corrigé dans un sprint reste dans l’équipe. La gouvernance devient utile lorsqu’elle accélère les choix risqués en rendant la responsabilité et le coût visibles, pas lorsqu’elle ajoute une signature à chaque détail.