Gouvernance de l’architecture dans les organisations agiles

À quoi sert la gouvernance de l’architecture

La gouvernance de l’architecture est l’ensemble des pratiques par lesquelles une organisation s’assure que ses décisions techniques significatives sont bien prises, cohérentes avec ses objectifs et réellement suivies. Elle répond à quatre questions : qui peut prendre quelles décisions, comment les prendre, quelle direction suivre, et comment savoir si le résultat est conforme.

Ses finalités sont pratiques. La gouvernance aligne la technologie sur la stratégie, afin que cinquante équipes ne choisissent pas cinquante façons de stocker les données clients. Elle gère le risque et la conformité : la protection des données, la sécurité, l’accessibilité et la réglementation sectorielle exigent toutes des preuves que les règles sont respectées. Elle limite la diversité inutile, car chaque base de données, langage ou produit de messagerie supplémentaire exige des compétences, des correctifs et une astreinte. Elle protège les qualités dont aucune équipe n’est seule propriétaire, comme la latence de bout en bout, la sécurité et le coût. Et elle diffuse les enseignements, afin qu’une leçon payée par une équipe ne soit pas payée à nouveau par la suivante.

Les organisations agiles ressentent ici une tension. Le principe du Manifeste agile selon lequel les meilleures architectures émergent d’équipes auto-organisées (section 1.8) tire vers l’autonomie ; l’échelle, la réglementation et l’infrastructure partagée tirent vers l’alignement. Les descriptions de la culture d’ingénierie de Spotify par Henrik Kniberg ont popularisé l’expression autonomie alignée (aligned autonomy) pour désigner l’objectif : des équipes libres de décider du comment, dans une compréhension partagée du quoi et du pourquoi. La gouvernance est la mécanique qui rend cela possible. Mal faite, elle devient le lent processus d’approbation de la section 11.2 ; bien faite, les équipes la remarquent à peine, parce que la bonne façon de faire est aussi la plus facile.

Principes, normes, garde-fous et points de validation

La gouvernance utilise quatre types d’instruments, qui diffèrent par leur degré de contrainte et par le moment où ils agissent. Les principes d’architecture expriment une direction durable et laissent place au jugement. Les normes sont des choix précis et obligatoires (tous les services exposent des traces OpenTelemetry ; toutes les API publiques sont décrites en OpenAPI). Les garde-fous (guardrails) maintiennent les équipes dans des limites sûres pendant qu’elles travaillent, généralement de façon automatique et continue. Les points de validation (gates) arrêtent le travail jusqu’à ce que quelqu’un l’approuve.

Le consensus moderne, sans être universel, consiste à préférer les garde-fous aux points de validation partout où une règle peut être énoncée objectivement, à réserver les points de validation aux quelques décisions qui exigent réellement un jugement humain responsable, et à les tenir tôt et dans un temps limité. Une paved road (chemin balisé) (terme de Netflix ; Spotify parle de golden path) complète les deux : quand la façon prise en charge de construire un service inclut déjà les images approuvées, la journalisation, l’analyse de sécurité et le déploiement, la plupart des équipes se conforment sans qu’on le leur dise, et l’effort de gouvernance peut se concentrer sur les écarts délibérés. La section 10.7 présente les plateformes qui fournissent de tels chemins.

Rédiger des principes d’architecture

TOGAF, le cadre d’architecture d’entreprise de l’Open Group (le TOGAF Standard, 10th Edition, 2022), fournit un modèle de principes largement utilisé, en quatre parties. Le nom est court et facile à retenir. L’énoncé exprime la règle en une ou deux phrases sans ambiguïté. La justification explique le bénéfice pour l’entreprise, en des termes qu’un commanditaire non technique pourrait accepter. Les implications disent ce que le principe exige en pratique : ce qui doit être fait, ce qu’il coûte et ce qu’il exclut. TOGAF énumère aussi les critères d’un bon ensemble de principes : compréhensible, robuste (assez précis pour trancher les cas difficiles), complet, cohérent et stable.

Deux tests repèrent la plupart des principes faibles. D’abord, une organisation raisonnable pourrait-elle choisir l’inverse ? « Les systèmes doivent être sécurisés » échoue ; personne ne choisirait l’insécurité. « Préférer l’achat au développement pour les capacités génériques » réussit, car certaines organisations préfèrent à juste titre développer. Ensuite, le principe change-t-il une décision réelle ? Si personne ne peut citer un choix qu’il trancherait, c’est un slogan. Andrew Harmel-Law demande un ensemble ni trop petit pour couvrir les besoins essentiels ni trop grand pour que les équipes s’en souviennent, issu des équipes elles-mêmes et lié à la stratégie de l’entreprise, plutôt que des maximes générales de programmation ou des pratiques. Des principes moins nombreux et plus tranchants sont retenus et utilisés ; les longues listes ne le sont pas.

Prise de décision décentralisée : le processus de consultation

Si les décisions ne passent plus par un comité, qui les prend ? L’article d’Andrew Harmel-Law Scaling the Practice of Architecture, Conversationally (martinfowler.com, décembre 2021) a proposé une réponse empruntée aux organisations autogérées : le processus de consultation (advice process). Sa règle unique est que n’importe qui peut prendre une décision architecturale, à condition de solliciter, avant de décider, l’avis de toutes les personnes qui seront sensiblement concernées et de personnes ayant une expertise pertinente. La personne qui décide doit entendre et consigner les avis, mais n’est pas tenue de les suivre ; le but est de recueillir des contributions larges, pas d’obtenir un consensus. La responsabilité reste à la personne ou à l’équipe qui décide, et c’est ce qui fait fonctionner la règle : les personnes qui savent qu’elles assument les conséquences sollicitent sérieusement des avis.

Harmel-Law décrit quatre éléments d’appui. Les enregistrements de décision (ADR, section 4.5) sont l’outil de réflexion et de consignation, et incluent les avis reçus, de qui et quand. Un forum consultatif d’architecture, généralement hebdomadaire, d’environ une heure et ouvert à tous, donne de la visibilité aux nouveaux spikes, aux décisions proposées et à celles qui sont réexaminées ; point crucial, il donne des avis mais ne décide pas. Des principes d’architecture issus des équipes donnent une direction commune. Et un radar technologique interne montre le paysage technologique actuel de l’organisation et sa position à son égard.

Le processus de consultation a des modes de défaillance qu’il vaut la peine de connaître. Les décisionnaires peuvent ne consulter que les personnes susceptibles d’être d’accord ; une liste publiée de qui doit être consulté pour quels types de décisions (la sécurité pour tout ce qui touche aux données à caractère personnel, l’équipe plateforme pour toute nouvelle infrastructure) y remédie. Les avis peuvent être sollicités trop tard, une fois le code écrit ; faire de l’ADR proposé le début du travail, et non sa fin, y remédie. Et certaines personnes trouvent d’abord inconfortable que le forum ne décide pas. Dans les environnements réglementés, le processus peut coexister avec un petit nombre de points de validation formels, appliqués uniquement là où la loi ou l’appétence au risque de l’organisation l’exige.

Radars technologiques

Thoughtworks publie son Technology Radar deux fois par an depuis 2010. Chaque édition place une centaine de blips (techniques, outils, plateformes, ainsi que langages et frameworks : les quatre quadrants) dans des anneaux qui expriment une recommandation. Adopt signifie éprouvé et recommandé ; Trial, digne d’être poursuivi sur un projet capable d’assumer le risque ; Assess, digne d’être exploré pour en comprendre l’effet ; et l’anneau le plus extérieur, appelé Hold pendant la majeure partie de l’histoire du radar et Caution dans ses éditions les plus récentes, signifie avancer avec prudence. Chaque blip est accompagné d’une courte justification écrite, qui en est la partie la plus précieuse.

De nombreuses organisations construisent leur propre radar, pour elles-mêmes plutôt que pour l’industrie. Thoughtworks fournit un outil open source, Build Your Own Radar, qui génère un radar à partir d’une feuille de calcul ou d’un fichier CSV avec les colonnes name, ring, quadrant, isNew et description. La valeur tient moins à l’image qu’au processus : les équipes proposent des blips, un petit groupe réunissant des représentants de nombreuses équipes en discute, les anneaux sont attribués avec une raison écrite, et le radar est actualisé chaque trimestre ou chaque semestre. Un anneau Hold est un outil de gouvernance doux mais efficace : il dit « pas de nouveaux usages » sans interdire ce qui existe déjà. Un radar diffère d’une liste de technologies approuvées en ce qu’il est explicitement provisoire et argumenté, et qu’il consigne ce que l’organisation a appris, y compris ses erreurs.

name,ring,quadrant,isNew,description
Debezium for outbox relay,Trial,Tools,TRUE,"Change data capture from the order database's write-ahead log to Kafka, replacing polling relays. Trial in ordering only; see ADR-0031. Owner: ordering team. Review: Q3."
Polling outbox relay,Hold,Techniques,FALSE,"Adds load and latency at peak; no new uses. Existing relays move when Debezium leaves Trial."

# ADR-0031: Use Debezium change data capture for the ordering outbox relay

Status: Accepted (2026-05-14)   Decision-taker: Priya N., ordering team
Context: The polling relay queries the outbox table every 500 ms. At 100 orders/s
it adds measurable database load and up to 1 s of event delay to dispatch.
Options: (1) tune polling; (2) Debezium CDC on the write-ahead log; (3) managed CDC
from the cloud provider.
Decision: Option 2, for the ordering service only, as a Trial on the radar.
Advice received:
- Platform team (2026-05-06): supports; will run Kafka Connect, needs runbook.
- Data team (2026-05-07): concern about replication slot growth if Connect stops;
  asks for an alert on slot lag. Accepted.
- Security (2026-05-08): CDC user must have replication rights only. Accepted.
- Advisory forum (2026-05-09): suggested option 3; rejected for portability (P3).
Consequences: lower load and delay; a new component to operate; slot-lag alert
and a fitness function on event delay (p99 under 2 s) added.
Review: after one quarter, or before any second service adopts it.

Le rôle de l’architecture d’entreprise aujourd’hui

L’architecture d’entreprise (section 1.2) a eu une réputation difficile dans les organisations agiles : des équipes centrales produisant des cadres, des normes et des processus d’approbation que les équipes de livraison vivaient comme des obstacles. Le rôle évolue. Dans les organisations où il fonctionne bien, les architectes d’entreprise entretiennent les principes et le radar plutôt que de les dicter, tiennent à jour la carte des capacités métier et des systèmes qu’aucune équipe ne peut voir seule, prennent ou facilitent les décisions de type porte à sens unique qui concernent réellement toute l’organisation (identité, données centrales, stratégie cloud, grands fournisseurs), animent le forum consultatif, et façonnent la plateforme et la paved road avec les équipes plateforme.

L’image de Gregor Hohpe, celle de l’architecte qui prend l’ascenseur entre la salle du conseil et la salle des machines (section 11.7), décrit la compétence que cela exige : traduire la stratégie en orientation technique et les contraintes techniques en langage métier. Les praticiens restent en désaccord sur le degré d’autorité centrale qui est sain. Certains soutiennent qu’une fonction centrale forte est indispensable dans les entreprises réglementées, marquées par de nombreuses fusions ou très intégrées ; d’autres, que l’essentiel de sa valeur peut être apporté par des plateformes, des principes et des avis. La réponse dépend de la taille de l’organisation, de sa réglementation et de la part de son paysage de systèmes qui est réellement partagée.

La conformité par l’automatisation

Quel que soit le modèle organisationnel, la conformité la moins coûteuse est automatisée. Les fonctions d’aptitude (section 11.3) vérifient les caractéristiques d’architecture. La politique en tant que code (policy as code) fait de même pour les règles de l’organisation : les règles sont écrites dans un langage lisible par une machine, conservées sous contrôle de version, revues et testées comme du code, et évaluées automatiquement par rapport aux définitions d’infrastructure, aux manifestes de déploiement ou aux requêtes d’API. Open Policy Agent, projet diplômé (graduated) de la Cloud Native Computing Foundation, est un moteur généraliste largement utilisé, doté de son propre langage de politiques, Rego ; Conftest applique des politiques Rego aux fichiers de configuration dans un pipeline, et des contrôleurs d’admission comme OPA Gatekeeper ou Kyverno font appliquer des politiques à l’intérieur des clusters Kubernetes.

L’automatisation de la conformité a un autre avantage que les organisations réglementées apprécient particulièrement : la preuve. Un journal de pipeline montrant que chaque mise en production a passé les mêmes vérifications constitue une preuve bien plus solide pour un auditeur qu’un formulaire signé, et il est produit sans coût supplémentaire.

package main

import rego.v1

# Guardrail: images must come from the organisation's scanned registry
deny contains msg if {
    input.kind == "Deployment"
    some c in input.spec.template.spec.containers
    not startswith(c.image, "registry.fooddelivery.example/")
    msg := sprintf("%s: image %s is not from the approved registry", [input.metadata.name, c.image])
}

# Guardrail: every container declares a memory limit
deny contains msg if {
    input.kind == "Deployment"
    some c in input.spec.template.spec.containers
    not c.resources.limits.memory
    msg := sprintf("%s: container %s has no memory limit", [input.metadata.name, c.name])
}

Équilibrer autonomie et alignement

La question pratique est de savoir quelles décisions sont gouvernées, et comment. Une règle utile découle de la section 1.6 : plus une décision est réversible et locale, plus elle doit être prise près de l’équipe ; plus elle est irréversible et largement ressentie, plus elle demande d’avis et, parfois, d’approbation. Le tableau présente une répartition typique ; chaque organisation ajuste la sienne.

La gouvernance doit elle-même être mesurée. Les signaux utiles sont le temps que prennent les décisions significatives entre la proposition et l’acceptation, le nombre d’exceptions aux normes demandées et accordées, la part des services qui suivent la paved road, le nombre de technologies en Hold qui continuent de se répandre, et le fait que des incidents remontent ou non à des décisions prises sans consultation. Si les décisions sont lentes, la gouvernance est trop lourde ; si des incidents continuent de remonter à des décisions non consultées, elle est trop légère.