Architecture Review Board : structure & processus

L'Architecture Review Board(ARB) est un comité permanent dont la mission est d'évaluer les choix d'architecture significatifs pour l'organisation : adoption d'une nouvelle technologie, refonte d'un système central, sélection d'un fournisseur stratégique, intégration entre domaines fonctionnels, mise en service d'un agent IA dans un parcours client.

Le verdict prend la forme d'une notice: un document opposable qui consigne la décision (GO, GO-conditionnel, NO-GO, REPORT), le raisonnement, les conditions imposées, les actions de suivi et leurs responsables. La notice survit aux mouvements d'équipe et aux turnover de fournisseurs : elle est la mémoire architecturale.

L'ARB n'est pas un comité de validation technique au sens étroit — il ne relit pas le code, il ne pré-approuve pas les designs détaillés. Son périmètre est stratégique et transverse: ce qui engage plusieurs domaines, plusieurs années, ou plusieurs millions d'euros.

Trois bénéfices empiriquement constatés dans les organisations matures :

• Réduction des coûts cachés.Refondre un mauvais choix en année 3 coûte 5 à 20× le coût d'avoir bien arbitré en année 0. Une revue à 20 personnes-heure peut éviter 5 années-homme de remediation.
• Cohérence du SI.Sans instance transverse, chaque équipe optimise localement et le paysage applicatif diverge — mêmes capacités dupliquées, integration patterns incohérents, vendor sprawl. L'ARB est le seul espace où les arbitrages cross-domaines se prennent.
• Traçabilité & conformité. Les régulateurs (ACPR, CNIL, AI Act) exigent de plus en plus de pouvoir reconstruire pourquoi un choix a été fait et quil'a validé. Sans ARB outillé, ces preuves se perdent.

À l'inverse, l'absence d'ARB ne fait pas disparaître les arbitrages — elle les rend invisibles, informels, dépendants de l'ancienneté ou du volume vocal de chaque interlocuteur.

Un ARB efficace combine deux profils de membres : permanents et invités contextuels.

Membres permanents (le quorum)

• Chair / président.Typiquement le Chief Enterprise Architect ou un responsable d'urbanisme SI. Anime les sessions, signe les notices, arbitre en cas de désaccord persistant.
• Architectes d'entreprise (2–4).Couvrent les grands domaines : data, intégration, digital, infrastructure. Apportent la vision SI globale.
• Représentant Sécurité. RSSI ou délégué. Verdict sécurité atomique sur chaque notice (GO sur sécurité ≠ GO global mais GO global impossible sans GO sécurité).
• Représentant Données / DPO. Notamment pour les sujets RGPD, transferts hors UE, profilage, IA Act.

Membres invités (variables)

• Architectes solution / référents domainedes sujets à l'ordre du jour.
• Sponsor métierdu dossier soumis — pour qualifier la criticité et l'ambition.
• Ops / SRE sur les sujets ayant un impact opérationnel fort (SLO, capacity).
• Tech Leadsur les questions d'implémentation : c'est lui qui défend le dossier devant l'ARB.

Un cycle de revue classique se découpe en quatre étapes — souvent matérialisées par des gatessuccessifs :

Gate 0 — Intake (DAS soumis)

Le porteur du dossier (architecte solution, tech lead) soumet un Document d'Architecture Synthétique (DAS) qui répond à 6 questions clés :

• Quelle capacité métier est servie ?
• Quelle est l'option recommandée et les alternatives écartées ?
• Quels coûts (build + run sur 3 ans) ?
• Quels risques (sécurité, RGPD, vendor lock-in) ?
• Quel impact sur les systèmes existants ?
• Quelle est la décision attendue (et de qui) ?

Gate 1 — Notice ARB

L'ARB se réunit (sync ou async), challenge le dossier, demande des compléments si nécessaire, puis produit une notice avec un verdict par stakeholder :

• Architecture  — GO / GO-cond / NO-GO
• Sécurité  — GO / GO-cond / NO-GO
• RGPD     — GO / GO-cond / NO-GO
• Data     — GO / GO-cond / NO-GO
• Ops      — GO / GO-cond / NO-GO

Le verdict global est composé : GO global = tous les verdicts atomiques sont GO ou GO-conditionnel. Un seul NO-GO bloque. Cette atomicité évite le piège du « ça passe globalement » qui en fait masque un veto sécurité ignoré.

Gate 2 — Go Live validé

Une fois les conditions levées (typiquement : DPIA complétée, monitoring déployé, dette tracée), une seconde revue rapide valide le passage en production. Beaucoup d'organisations skippent ce gate — c'est souvent là que les conditions G1 deviennent purement théoriques.

Suivi (re-review clock)

Une notice GO-conditionnel doit avoir un compteur de re-review qui force une réévaluation à échéance (typiquement 6 ou 12 mois). Sans cela, les conditions deviennent du papier mort.

Trois formats coexistent dans les organisations matures :

• Async-first (recommandé pour 80 % des dossiers). Le DAS est publié, les membres commentent par écrit pendant 5 jours ouvrés, le chair statue. Pas de réunion. Décision rapide, traçable, peu coûteuse.
• Sync hebdo / bimensuel pour les dossiers complexes ou contestés. 60–90 minutes, 3–5 dossiers max, agenda envoyé J-3.
• Spike review (sur invitation) pour les sujets bloquants ou très sensibles : 30 min, un seul dossier, décision immédiate.

Anti-pattern à éviter : un sync mensuel à 3h avec 12 dossiers. Personne ne lit, tout le monde acquiesce, et la décision est prise par le chair en off.

Définir le périmètre est aussi important que le processus lui-même. Une grille classique de déclenchement :

• Vendor stratégique (CRM, ERP, data platform, IdP)
• Intégration cross-domaine nouvelle
• Technologie pas encore au catalogue (nouveau langage, nouveau framework critique, agent IA)
• Système traitant des données personnelles ou sensibles
• Build vs Buyavec coût Total Cost of Ownership > 250k€ sur 3 ans
• Tout système soumis à régulation (DSP2, MIFID, AI Act risque high)

À l'inverse — ne passoumettre à l'ARB : les choix d'implémentation locaux (quelle lib utiliser, quel pattern de cache), les bug fixes, les évolutions mineures sur un système déjà arbitré. Sinon l'ARB devient un sas administratif que les équipes apprennent à contourner.

Patterns qu'on observe dans 80 % des ARB qui deviennent dysfonctionnels :

• Le goulot d'étranglement.Files d'attente de 6 semaines pour passer en revue. Cause : trop de dossiers, périmètre flou, format sync unique.
• Le rubber-stamping.Les membres arrivent sans avoir lu le DAS, le chair valide tout. Cause : agenda surchargé, pas d'async, pas de challenge réel.
• Le shadow-IT.Les équipes contournent l'ARB en ne lui soumettant que les sujets non-critiques. Cause : périmètre mal défini, délais perçus comme bloquants.
• Les notices sans suite.Conditions GO-cond jamais vérifiées, actions assignées à personne, re-review clock inexistant. Cause : pas d'outil de suivi, pas de propriétaire de la notice après signature.
• Le verdict flou.« OK on valide mais faites attention à la sécu ». Pas de verdict atomique, pas d'action items, pas de date. Cause : absence de format de notice contraignant.

1. Async par défaut, sync par exception. Réservez les réunions aux dossiers complexes ou contestés.
2. Périmètre explicite et documenté. Un one-pager qui dit « on revoit ça » et « on ne revoit pas ça ». Affiché publiquement.
3. SLA de réponse. Engagement formel sur le délai (ex. 5 jours ouvrés en async, 2 semaines en sync). Sans SLA, les équipes contournent.
4. Verdict atomique par stakeholder. Un GO global est composé de GO sécurité, GO RGPD, GO archi, GO data, GO ops. Jamais un GO « général ».
5. Action items affectés et datés. Chaque condition GO-cond a un porteur (un humain nommé), une échéance, et un statut (todo / done / abandoned).
6. Re-review clock systématique. Toute notice avec conditions doit re-passer en revue à échéance définie.
7. Audit trail immutable. Une décision archivée doit pouvoir être ressortie 5 ans plus tard avec la même fidélité — qui a voté, sur quels arguments, dans quelle version du DAS.
8. Notifications proactives.Notice publiée → alerte Slack/email aux porteurs. Action item J-7 d'échéance → relance automatique. Sans ce nudging, les notices sortent du radar.

Beaucoup d'organisations démarrent avec un Excel partagé + un Confluence pour les comptes-rendus. Ça tient jusqu'à ~30 dossiers / an et 4–5 membres permanents. Au-delà, les pertes de traçabilité deviennent systémiques.

Les artefacts à produire — quel que soit l'outil :

• DAS templates standardisés (un par type de dossier : nouveau système, refonte, vendor, agent IA).
• Notices versionnées avec verdict par stakeholder, conditions, action items, re-review clock.
• Décisions architecturales (ADR) pour les choix techniques majeurs — souvent référencées par les notices.
• Pipeline visuel par gate (G0/G1/G2) qui montre où chaque dossier en est.
• Registre IA dédiési l'organisation est sous périmètre AI Act — chaque agent a sa fiche (vendor, modèle, catégorie de risque, DPIA, reviews).
• Tableau de bord cross-tenant pour la direction architecture : nombre de dossiers actifs, délai moyen de décision, taux de GO conditionnels, notices à re-review J-30.

C'est précisément ce qu'Architecture Platform fournit out-of-the-box — un workflow ARB natif, sans qu'il faille assembler 4 outils manuellement.