Depuis que je porte davantage le chapeau d’architecte, le mot gouvernance revient souvent. Il évoque vite un comité, une pile de documents et une personne qui dit non à la fin. Pourtant, le besoin de départ est technique : certaines décisions créent une dépendance pour plusieurs équipes et doivent survivre à leur auteur.

Je ne donnerais pas le même traitement à tous les choix. La couleur d’un bouton demeure locale. Le format d’un message de commande, la source des identités ou la manière de déployer en production deviennent des contrats partagés. Si une équipe change seule l’un de ces contrats, les autres applications peuvent casser même si leur code n’a pas bougé.

Prenons un échange très simple entre un système de vente et un système de facturation :

<Commande version="1">
  <Numero>1842</Numero>
  <Total devise="CAD">125.00</Total>
</Commande>

La gouvernance utile ne consiste pas à approuver chaque ligne XML. Elle nomme le propriétaire du contrat, définit ce que signifie Total, indique comment une nouvelle version sera introduite et garde un exemple testable. Si Total passe soudainement des dollars aux cents, ou si le champ devient facultatif sans avertissement, la facture peut être fausse sans produire d’erreur spectaculaire.

Trois niveaux plutôt qu’un seul comité

Je commence à séparer les décisions en trois catégories :

1. Locale : l’équipe décide et assume le soutien dans son application.
2. Partagée : les consommateurs du contrat se consultent et publient une décision courte.
3. Organisationnelle : identité, sécurité, données maîtres ou production exigent un responsable commun.

Pour une décision partagée, une page suffit souvent : contexte, choix, solution rejetée, conséquences et date de révision. Ce petit journal évite de refaire le même débat six mois plus tard et permet à une nouvelle personne de comprendre pourquoi deux systèmes utilisent encore un format qui paraît étrange.

L’exception fait aussi partie du mécanisme. Une équipe peut avoir besoin d’essayer une bibliothèque ou de contourner temporairement une norme. Je lui demanderais alors un périmètre, un propriétaire, le risque accepté et une date d’expiration. Sans date, le prototype devient une plateforme permanente par simple oubli.

Quand la règle produit son propre contournement

Si l’approbation prend trois semaines pour un essai de deux jours, l’équipe va créer son environnement sous le radar. Le système officiel perd alors toute visibilité sur les vraies dépendances. À l’inverse, l’absence de règles donne plusieurs formats de date, plusieurs annuaires locaux et des déploiements que seule une personne sait refaire.

Je mesurerais donc la gouvernance comme un service : délai de décision, nombre d’exceptions ouvertes, incidents causés par un contrat partagé et règles jamais utilisées. Une règle contournée régulièrement doit être simplifiée ou retirée; une règle qui prévient des bris réels mérite d’être automatisée dans les tests ou le déploiement.

Après deux mois dans le rôle, je cherche encore le bon dosage. Mon point de départ serait quelques frontières explicites, des décisions courtes et une voie rapide pour expérimenter. La gouvernance devient alors la mémoire et le garde-fou du système, pas un poste de péage devant chaque commit.