Gouvernance continue¶

Maintenir la cohérence architecturale dans la durée — comite, processus de décision, guardrails automatises et communauté de pratique.

Gouvernance n'est pas bureaucratie¶

La gouvernance architecturale a mauvaise reputation. Dans beaucoup d'organisations, elle evoque un comite qui dit non, des gates qui bloquent, des documents que personne ne lit. Cette gouvernance-la est effectivement inutile — et les équipes la contournent.

La gouvernance qui fonctionne est invisible au quotidien. Elle s'appuie sur des standards clairs, des guardrails automatises, et un processus de décision léger. Les équipes prennent des décisions architecturales en autonomie dans un cadre défini. Le comite n'intervient que sur les décisions structurantes qui depassent le périmètre d'une équipe.

Comite d'architecture¶

Rôle¶

Le comite d'architecture est le gardien de la cohérence globale. Il ne prend pas toutes les décisions — il s'assure que les décisions sont prises de manière cohérente et documentee.

Ses responsabilités :

• Valider les ADR structurants — décisions qui impactent plusieurs équipes ou domaines
• Maintenir le Technology Radar — approbation des mouvements entre anneaux
• Arbitrer les conflits — quand deux équipes font des choix incompatibles
• Réviser les standards — mise à jour des patterns et technologies approuves
• Superviser la dette technique — priorisation du remboursement à l'échelle

Composition¶

Le comite ne doit pas dépasser 8-10 personnes. Au-delà, les discussions deviennent inefficaces et les décisions prennent trop de temps.

Cadence¶

Processus de décision : RFC, review, ADR¶

Le processus de décision architecturale suit un flux en trois étapes. L'objectif est de maximiser la qualité des décisions tout en minimisant le délai.

flowchart LR
    RFC["RFC\n(Request for Comments)"] --text--> REVIEW["Review\n(pair ou comite)"]
    REVIEW --"approuve"--> ADR["ADR\n(decision documentee)"]
    REVIEW --"modifie"--> RFC
    REVIEW --"rejete"--> CLOSE["Cloture\n(avec justification)"]

Phase 1 : RFC (Request for Comments)¶

L'auteur redige une proposition structurée :

# RFC-042 : Migration du message broker de RabbitMQ vers Kafka

## Contexte
Le volume d'events a depasse 10 000/seconde. RabbitMQ montre
des signes de saturation. Plusieurs equipes ont besoin de replay.

## Proposition
Migrer les flux asynchrones de RabbitMQ vers Kafka.
Migration progressive par bounded context (strangler fig).

## Alternatives evaluees
1. Scale-up RabbitMQ (streams) — ne resout pas le replay
2. NATS JetStream — moins mature, ecosysteme plus petit
3. Kafka — replay natif, ecosysteme large, expertise disponible

## Impact
- Equipes concernees : Order, Notification, Analytics
- Timeline estimee : 3 mois
- Risques : complexite operationnelle Kafka, formation equipes

## Decision demandee
Approbation du comite pour lancer un POC de 2 semaines.

La RFC est publiee (PR, wiki, outil dédié) et ouverte aux commentaires pendant une periode définie — typiquement 1 a 2 semaines.

Phase 2 : Review¶

Selon l'impact de la décision (critères de triage vus au chapitre 02), la review est :

• Pair a pair : 2-3 personnes, asynchrone via commentaires sur la PR
• Comite : discussion en session dédiée, décision collective
• ATAM : session formelle pour les décisions les plus structurantes

Phase 3 : ADR¶

La décision est documentee dans un ADR numerate et immutable. L'ADR capture le contexte, la décision, les alternatives rejetees et les conséquences acceptees. Il est commite dans le repo et fait partie de l'historique du projet.

Évolution des ADR¶

Les ADR ne sont pas des documents statiques dans un monde statique. Le contexte change, les hypothèses sont invalidees, de meilleures options emergent.

Statuts d'un ADR¶

stateDiagram-v2
    [*] --> Proposed
    Proposed --> Accepted
    Proposed --> Rejected
    Accepted --> Superseded
    Accepted --> Deprecated
    Rejected --> [*]
    Superseded --> [*]
    Deprecated --> [*]

Triggers de révision¶

Un ADR doit être revisite quand :

• Le contexte a change — nouvelles contraintes, nouveau volume, nouvelle reglementation
• L'hypothèse est invalidee — le trade-off accepte se révélé plus coûteux que prévu
• Une meilleure option emerge — nouvelle technologie, nouveau pattern, retour d'expérience
• La dette technique associee est devenue critique — la conséquence acceptee dans l'ADR est devenue un problème

Superseding¶

Quand un ADR est remplacé, le nouvel ADR :

1. Référence l'ancien ADR explicitement : "Supersedes ADR-012"
2. Explique pourquoi le contexte a change
3. Documente ce qui est différent dans la nouvelle décision
4. L'ancien ADR est marque Status: Superseded by ADR-042

Architecture guild et communauté de pratique¶

Le comite d'architecture est un organe de décision. La guild (ou communauté de pratique) est un espace d'apprentissage et de partage.

Différence comite vs guild¶

Formats de guild¶

• Lightning talks (15 min) : un membre présente un pattern, un outil, un retour d'expérience
• Architecture kata (1h) : exercice collaboratif de conception (scenario fictif ou simplifie)
• Book club (bi-mensuel) : lecture et discussion d'un chapitre de livre d'architecture
• Post-mortem architecture (ad hoc) : analyse d'un incident ou d'une décision qui n'a pas fonctionne

Inner source¶

La guild facilite l'inner source — la contribution entre équipes sur les composants partages. Les patterns, les libraries internes, les templates de configuration sont maintenus en mode open-source interne. Toute équipe peut proposer une amélioration via PR, et la guild assure la revue et la cohérence.

Guardrails vs gates¶

La distinction entre guardrails et gates est fondamentale pour une gouvernance qui fonctionne.

Gates¶

Les gates sont des points de contrôle binaires : on passe ou on ne passe pas. Elles bloquent le flux si les critères ne sont pas remplis.

Exemples : approbation du comite pour un ADR structurant, validation sécurité avant mise en production, revue de conformité reglementaire.

Quand les utiliser : décisions irreversibles, exigences reglementaires, risques élevées.

Guardrails¶

Les guardrails sont des mécanismes automatises qui empêchent les dérivés sans bloquer le flux. Elles guident plutôt qu'elles ne bloquent.

Exemples : fitness functions en CI, linters d'architecture, policy as code, templates standardises.

Quand les utiliser : décisions réversibles, pratiques quotidiennes, prevention de la dette.

Équilibre¶

flowchart TD
    DEC["Decision architecturale"] --text--> EVAL["Evaluation\nde l'impact"]
    EVAL --"reversible\nfaible impact"--> GUARD["Guardrail\n(automatise)"]
    EVAL --"irreversible\nfort impact"--> GATE["Gate\n(humain)"]
    GUARD --text--> PROD["Production"]
    GATE --"approuve"--> PROD
    GATE --"refuse"--> BACK["Retour\na la conception"]

Niveaux de maturité de la gouvernance¶

Progression¶

On ne passe pas de "Ad hoc" a "Optimise" en un trimestre. La progression est graduelle et chaque niveau doit être stabilise avant de passer au suivant. Le piege classique : implémenter les outils du niveau "Optimise" sans avoir les pratiques du niveau "Défini".

Métriques de gouvernance¶

Pour piloter la gouvernance, on mesure :

• Lead time des décisions : temps entre la soumission d'un RFC et la publication de l'ADR
• Taux de conformité : pourcentage de projets qui respectent les standards documentes
• Coverage des ADR : pourcentage de décisions structurantes documentees
• Fréquence de mise à jour du radar : dernier update < 3 mois
• Participation à la guild : nombre de participants actifs / taille de l'organisation

Chapitre suivant : Cas d'étude — SaaS e-commerce — validation et gouvernance appliquees a un système e-commerce multi-tenant.