Revues d'architecture — ATAM¶

Évaluer les compromis architecturaux de manière structurée — ATAM pour les décisions structurantes, lightweight reviews pour le quotidien.

Pourquoi des revues d'architecture¶

Les fitness functions automatisent la vérification des propriétés connues. Mais certaines questions echappent à l'automatisation : est-ce que ce trade-off est le bon ? Est-ce que cette hypothèse tient encore ? Est-ce que le système peut absorber les exigences a venir ?

Les revues d'architecture apportent le regard humain sur ces questions. Elles ne sont pas un audit punitif — elles sont un outil d'apprentissage collectif. L'objectif est d'identifier les risques et les trade-offs, pas de juger les choix passes.

ATAM — Architecture Tradeoff Analysis Method¶

ATAM est un processus formel développé au Software Engineering Institute (SEI) de Carnegie Mellon. Il structure l'évaluation d'une architecture autour des compromis entre attributs qualité.

Les quatre phases¶

flowchart LR
    P1["Phase 1\nPresentation"] --text--> P2["Phase 2\nScenarios qualite"]
    P2 --text--> P3["Phase 3\nAnalyse des\ntrade-offs"]
    P3 --text--> P4["Phase 4\nIdentification\ndes risques"]

Phase 1 — Présentation de l'architecture. L'architecte présente les choix structurants, les drivers qualité, les contraintes techniques et organisationnelles. Les participants decouvrent le contexte sans jugement.

Phase 2 — Identification des scenarios qualité. Les parties prenantes formulent les scenarios qui comptent pour elles. Chaque scenario est un triplet : stimulus (quoi), environnement (dans quelles conditions), réponse attendue (quel résultat). On priorise collectivement.

Exemples de scenarios :

• "Quand le trafic triple pendant les soldes (stimulus), le système en production (environnement) maintient un p99 < 500ms (réponse)"
• "Quand un développeur modifie le module Payment (stimulus), en conditions normales (environnement), aucun test du module Order ne casse (réponse)"
• "Quand un attaquant tente une injection SQL (stimulus), sur l'API publique (environnement), la requête est bloquee et loguee (réponse)"

Phase 3 — Analyse des trade-offs. Pour chaque scenario prioritaire, on identifié quels attributs qualité sont favorises et lesquels sont sacrifies. Un trade-off n'est pas un défaut — c'est une décision explicite. Le problème, c'est quand le trade-off est implicite.

Phase 4 — Identification des risques. On pointe les zones d'incertitude, les hypothèses non validees, les dépendances critiques. Chaque risque est documente avec son impact potentiel et les actions de mitigation possibles.

Artefacts produits par ATAM¶

Exemple : tableau de trade-offs¶

Un ATAM sur un système e-commerce multi-tenant pourrait produire le tableau suivant :

Ce tableau est l'artefact le plus precieux d'un ATAM. Il rend les compromis explicites et permet de les revisiter quand le contexte change.

Quand utiliser ATAM¶

ATAM est coûteux : 2-3 jours de préparation, 1-2 jours de session, 5-15 participants. On le réservé pour :

• Les projets critiques (système financier, plateforme core)
• Les changements structurants (migration vers microservices, nouveau store de données)
• Les audits externes ou les revues de gouvernance
• Les systèmes avec des trade-offs complexes entre sécurité, performance et coût

ATAM simplifie¶

Pour les organisations qui trouvent ATAM trop lourd mais qui ont besoin de plus qu'une revue légère, une version simplifiée en demi-journée fonctionne :

1. 30 min : présentation de l'architecture et des drivers qualité
2. 30 min : identification des 5 scenarios qualité prioritaires (vote par points)
3. 1h : analyse des trade-offs sur les 3 scenarios les plus votes
4. 30 min : identification des risques et actions de suivi

Ce format couvre 80% de la valeur d'un ATAM complet pour 20% du coût. Il convient aux décisions importantes mais pas critiques — typiquement l'introduction d'un nouveau composant technique ou le choix d'un pattern de communication.

Lightweight architecture review¶

Pour les revues courantes — une nouvelle feature qui touche à l'architecture, un ADR en cours de rédaction, un changement de dépendance — ATAM est disproportionne. On utilisé une revue légère.

Format¶

• Durée : 30 minutes a 1 heure
• Participants : 2-4 personnes (l'auteur, 1-2 pairs, optionnellement un architecte senior)
• Déclencheur : PR avec un ADR, changement dans les fitness functions, nouveau module, nouvelle dépendance externe

Checklist de revue légère¶

## Architecture Review Checklist

### Coherence
- [ ] Les ADR sont-ils a jour et refletent-ils les decisions recentes ?
- [ ] Les bounded contexts sont-ils respectes dans le code et les deployments ?
- [ ] Le changement est-il coherent avec la vision architecturale documentee ?

### Qualite
- [ ] Les SLO sont-ils definis, instrumentes et mesures en production ?
- [ ] Les fitness functions passent-elles en CI ?
- [ ] La couverture de tests est-elle suffisante pour les chemins critiques ?

### Securite
- [ ] Les security boundaries sont-elles documentees et appliquees ?
- [ ] Le modele de menace a-t-il ete mis a jour si necessaire ?
- [ ] Les secrets sont-ils geres via un vault (pas en clair) ?

### Operabilite
- [ ] L'observabilite est-elle en place (metriques, logs, traces) ?
- [ ] Le rollback est-il possible et documente ?
- [ ] Les dependances externes sont-elles identifiees et leur SLA connu ?

Résultat¶

La revue légère produit trois résultats possibles :

1. Approuve — le changement est cohérent, les risques sont acceptables
2. Approuve avec conditions — ok sous réservé de modifications spécifiques
3. Bloque — risque identifié qui nécessité une investigation avant de continuer

Architecture Review Board¶

Pour les organisations avec plusieurs équipes, un Architecture Review Board (ARB) formalise le processus de revue à l'échelle.

Composition¶

Cadence et fonctionnement¶

Le board se reunit a cadence fixe — typiquement bi-hebdomadaire ou mensuelle selon le volume de décisions. Les demandes de revue sont soumises à l'avance avec un template standardise.

flowchart TD
    REQ["Demande de revue\n(RFC / ADR draft)"] --text--> TRIAGE["Triage par\nl'architecte principal"]
    TRIAGE --"leger"--> LIGHT["Revue legere\n(pair a pair)"]
    TRIAGE --"structurant"--> ARB["Architecture\nReview Board"]
    TRIAGE --"critique"--> ATAM["Session ATAM\ndediee"]
    LIGHT --text--> DECISION["Decision\ndocumentee (ADR)"]
    ARB --text--> DECISION
    ATAM --text--> DECISION

Critères de triage¶

Peer reviews architecturales¶

Au-delà du board formel, les revues entre pairs sont le mécanisme le plus frequent et le plus efficace pour maintenir la qualité architecturale au quotidien.

Architecture Décision Records en PR¶

Quand un changement implique une décision architecturale, on inclut un ADR dans la pull request. Les reviewers evaluent la décision en même temps que le code. C'est le moment le plus naturel pour la revue : le contexte est frais, le code est la, les alternatives ont été evaluees.

Le reviewer d'un ADR en PR doit se poser ces questions :

• Le contexte est-il clair et complet ? Un lecteur externe comprendrait-il pourquoi cette décision est nécessaire ?
• Les alternatives rejetees sont-elles documentees avec leur raison de rejet ?
• Les conséquences sont-elles honnetes — y compris les coûts et les risques acceptes ?
• La décision est-elle réversible ? Si oui, quel est le critère de révision ?
• Les fitness functions nécessaires sont-elles identifiées ?

Design docs légers¶

Pour les changements plus importants qui ne justifient pas un ATAM complet, un design doc léger (1-2 pages) permet de recueillir les retours avant de coder. Le format minimal :

1. Problème — qu'est-ce qu'on résout ?
2. Contraintes — qu'est-ce qui limite les options ?
3. Options evaluees — qu'est-ce qu'on a considéré et pourquoi ?
4. Décision — qu'est-ce qu'on fait et pourquoi ?
5. Risques — qu'est-ce qui peut mal tourner ?

Fréquence recommandee¶

Anti-patterns des revues d'architecture¶

Construire une culture de revue¶

Les processus de revue ne fonctionnent que si la culture les soutient. Quelques principes pour y arriver :

Normaliser la critique constructive. Une revue qui ne trouve rien est suspecte. L'objectif est d'améliorer, pas de valider. Les reviewers doivent être encourages a poser des questions difficiles — et les auteurs doivent les accueillir comme des contributions plutôt que comme des attaques.

Rendre les revues visibles. Les comptes-rendus de revue sont publies et accessibles a tous. Les décisions qui en decoulent sont tracees dans des ADR. La transparence construit la confiance dans le processus.

Mesurer et ajuster. Combien de revues par trimestre ? Quel est le lead time moyen entre demande et décision ? Combien de décisions de revue ont été revisees dans les 6 mois ? Ces métriques permettent d'ajuster le processus.

Former les reviewers. La revue d'architecture est une compétence — elle s'apprend. Les architectes juniors participent d'abord en observateurs, puis en co-reviewers, avant de mener des revues en autonomie. La guild d'architecture (chapitre 05) est le lieu naturel de cette formation.

Chapitre suivant : Dette technique — identifier, classifier et gérer la dette technique de manière strategique.