Un projet IT démarre bien, puis déraille. Les équipes prennent des décisions techniques en silo, les standards divergent, la sécurité devient une rustine appliquée en fin de parcours. C’est exactement le problème qu’un Architecture Review Board (ARB) est censé éviter. Pas un comité de plus pour ralentir les projets — un mécanisme de gouvernance qui aligne les choix techniques sur la stratégie business de l’organisation.
L’ARB existe sous différentes formes selon la maturité de l’enterprise, sa taille et son secteur. Mais sa mission reste constante : garantir que les décisions architecturales respectent les standards établis, gèrent les risques de sécurité, et servent les objectifs à long terme — pas seulement les urgences du sprint en cours.
Ce que fait vraiment un ARB
Valider les décisions architecturales majeures
L’ARB ne s’occupe pas de chaque choix technique. Il intervient sur les décisions qui engagent l’enterprise sur la durée : adoption d’un nouveau cloud provider, migration d’un système legacy, choix d’un framework de sécurité transversal. En pratique, la plupart des organisations fixent un seuil — budgétaire ou d’impact — en dessous duquel les équipes décident seules.
Concrètement, un projet soumet un dossier architectural (souvent appelé Architecture Decision Record) que l’ARB examine. Le board évalue :
- L’alignement avec les standards enterprise existants
- Les risques de sécurité identifiés et les mesures prévues
- La cohérence avec la stratégie IT à moyen terme
- L’impact sur les autres équipes et systèmes
- La faisabilité opérationnelle post-déploiement
L’ARB peut approuver, rejeter, ou — cas le plus fréquent — approuver sous conditions. Cette troisième option est souvent la plus utile : elle débloque le projet tout en imposant des garde-fous précis.
Maintenir et faire évoluer les standards
Un ARB sans standards, c’est un arbitre sans règlement. La moitié du travail du board consiste à définir, documenter et mettre à jour les standards architecturaux de l’enterprise. Ces standards couvrent typiquement les patterns d’intégration, les exigences de sécurité minimales, les politiques de données, les conventions de design et les référentiels technologiques approuvés.
Microsoft, par exemple, publie ses propres Architecture Review Boards internes pour ses business units, avec des standards distincts selon les domaines (cloud, sécurité, expérience utilisateur). Le principe : chaque équipe sait avant de concevoir ce qui sera ou non accepté en review.
Les standards ne sont pas gravés dans le marbre. L’ARB doit les réviser régulièrement — au moins une fois par an — pour éviter qu’ils deviennent des obstacles bureaucratiques face aux évolutions technologiques. Un standard de sécurité rédigé en 2019 ne couvre pas les menaces de 2024.
Composition et gouvernance d’un ARB efficace
Qui siège dans un Architecture Review Board ?
La composition de l’ARB détermine son efficacité autant que ses processus. Trop technique, il perd le lien avec le business. Trop managérial, il prend des décisions déconnectées de la réalité des projets.
Un ARB équilibré réunit généralement :
- Un executive sponsor — souvent le CTO ou le CIO — qui donne le mandat et tranche les impasses
- Des enterprise architects seniors, responsables de la cohérence globale
- Des représentants de la sécurité, en charge des standards et de l’évaluation des risques
- Des leads techniques issus des principales équipes produit
- Un représentant business ou des stakeholders métier pour ancrer les décisions dans la réalité opérationnelle
La taille idéale ? Entre 5 et 9 membres permanents. Au-delà, le board devient ingérable. En dessous, il manque de perspectives. Certaines organizations font appel à des membres invités selon les sujets — un expert sécurité externe, un architecte spécialisé cloud — sans les intégrer en permanence.
Processus de décision et rythme de fonctionnement
L’ARB se réunit à fréquence fixe — bi-mensuel ou mensuel dans la plupart des cas — et traite les soumissions selon un ordre du jour structuré. Chaque projet responsable de son dossier présente ses choix architecturaux, répond aux questions du board, puis sort de la salle pendant la délibération.
Trois règles font la différence entre un ARB qui crée de la valeur et un ARB qui crée de la frustration :
- Un délai de traitement garanti — 10 jours ouvrés maximum entre soumission et décision, sinon les équipes contournent le processus.
- Des critères de décision transparents et documentés, accessibles à toutes les équipes avant même qu’elles déposent un dossier.
- Un droit de recours clair, permettant à un projet de contester une décision auprès de l’executive sponsor si le rejet semble disproportionné.
L’ARB doit aussi publier ses décisions — anonymisées ou non selon la culture de l’enterprise — pour que l’ensemble de l’organization apprenne des arbitrages passés. C’est le meilleur moyen de faire baisser le volume de soumissions redondantes et d’élever le niveau des dossiers reçus.
Un ARB bien rodé finit par modifier les comportements en amont : les équipes conçoivent différemment dès le départ, en anticipant les questions du board. C’est là que réside la vraie valeur — non pas dans les décisions prises en réunion, mais dans les mauvaises décisions qui ne sont jamais prises parce que les standards sont intégrés dès la phase de design.