TL;DR.Un bon DAS répond à 6 questions : quoi, pourquoi, pour qui, comment ça s'intègre, les risques identifiés, et la décision attendue. 4-6 pages maximum — au-delà, c'est un dossier d'étude, pas un support de décision.

1

Pourquoi un DAS et pas une présentation PowerPoint

Un Document d'Architecture Synthétique est un texte court — pas un deck. La différence est structurelle :

  • Un texte se lit en amont, sans la présence du porteur. Les membres ARB arrivent à la session avec leurs questions déjà cadrées, le débat démarre directement sur les vrais points durs.
  • Un texte oblige à structurer la pensée. Une slide tolère la phrase creuse ; un paragraphe non. C'est le format choisi par Amazon (le 6-pager) pour cette raison précise.
  • Un texte est citable et auditables. Les notices ARB peuvent référencer un paragraphe précis du DAS ; une slide se perd dans un dossier SharePoint.

Le DAS reste un livrable d'architecture — pas une spécification fonctionnelle, pas un cahier des charges. Il cadre la solution proposée pour permettre une décision d'architecture éclairée.

2

Les 6 questions auxquelles le DAS doit répondre

Toutes les Architecture Review Board que nous avons observées — banques, mutuelles, industrie, secteur public — convergent sur ces 6 attendus. L'ordre compte :

  1. Quoi ? Décrivez en 3 phrases ce que vous proposez de construire ou de modifier. Sans jargon, sans acronyme non défini.
  2. Pourquoi ? Quel problème métier ou technique justifie cette initiative. Quantifiez si possible (volume, coût, dette, SLA dégradé).
  3. Pour qui ? Utilisateurs, équipes, systèmes consommateurs. Identifie les parties prenantes qui doivent valider ou être informées.
  4. Comment ça s'intègre ?Le schéma d'intégration : composants amont, aval, dépendances sur le référentiel SI (Business Apps, POSI, Agents IA).
  5. Quels risques ?3 à 5 risques majeurs identifiés, leur impact et la mitigation envisagée. C'est la partie où l'ARB challenge le plus.
  6. Décision attendue ? Soyez explicite : validation de principe, validation de design détaillé, arbitrage budget, etc.
3

Structure type d'un DAS

Un DAS tient en 4 à 6 pages dans un format standardisé. Voici la structure que nous proposons par défaut dans Architecture Platform :

En-tête (1 page)

  • Titre de l'initiative + référence DAS
  • Porteur (nom + équipe) et sponsor (Direction ou DSI)
  • Date de soumission ARB visée
  • Statut : draft / soumis / en revue / validé
  • Une synthèse en 5 lignes — TL;DR du document

Sections principales (3-4 pages)

  1. Contexte & objectif — répond aux questions 1 et 2 (quoi/pourquoi).
  2. Parties prenantes — répond à la question 3 (pour qui).
  3. Architecture cible — répond à la question 4 (comment). Schéma ArchiMate ou Drawio intégré, liste des composants impactés du référentiel.
  4. Risques & mitigations — répond à la question 5. Tableau structuré.
  5. Décision attendue — répond à la question 6. Une seule phrase, idéalement formulée comme une question fermée.

Annexes (1 page maximum)

  • Alternatives étudiées et écartées (avec la raison)
  • Liens vers la documentation technique détaillée
  • Calendrier macro et jalons (T0, T0+3, T0+6 mois max)
Astuce.Si vous dépassez 6 pages, c'est que vous mélangez le DAS avec la documentation technique. La doc détaillée vit ailleurs (wiki d'équipe, Confluence, README de repo) — le DAS la référence seulement.
4

Exemple rempli — extrait

Voici à quoi ressemblent les 6 réponses pour une initiative type : ajout d'un agent IA d'assistance aux conseillers commerciaux dans un CRM existant.

Quoi ?

Intégrer un agent conversationnel (Claude 3.5 Sonnet via API Anthropic) dans le CRM Salesforce pour aider les conseillers commerciaux à rédiger les comptes-rendus de rendez-vous client, en s'appuyant sur les interactions des 6 derniers mois.

Pourquoi ?

Audit interne 2026-Q1 — un conseiller passe en moyenne 47 minutes par jour à rédiger ses comptes-rendus, dont 30 % en saisie redondante. Objectif : ramener à 15 minutes en gardant la qualité du contenu CRM.

Pour qui ?

240 conseillers commerciaux (région Île-de-France en Phase A, national en Phase B). Sponsor : Directeur Commercial. Parties prenantes à valider : DPO (données client), RSSI (intégration API tierce), Direction Conformité (traçabilité des comptes-rendus).

Comment ça s'intègre ?

Composant nouveau : un microservice crm-ai-assist déployé sur le cluster Kubernetes existant. Authentification SSO via Entra ID. Appels API Anthropic limités à 50 req/min/conseiller (rate limiter Redis). Aucune donnée client n'est stockée côté Anthropic (option data retention=0activée). Référentiel : ajout d'une fiche Agent IA dans le registre, liée à la Business Application Salesforce.

Risques & mitigations

  • Hallucinations sur les éléments factuels. Mitigation : grounding strict sur les interactions CRM réelles, garde-fous prompt, validation humaine obligatoire avant enregistrement.
  • Fuite de données vers Anthropic. Mitigation : data retention=0 contractuelle, anonymisation des PII avant envoi.
  • Dépendance fournisseur unique. Mitigation : abstraction LLMGateway permettant un fallback Mistral en cas d'indisponibilité Anthropic.

Décision attendue

Validation de principe pour lancer la Phase A (pilote 30 conseillers, mars-juin 2026). Re-passage en ARB G2 avant déploiement national.

5

Anti-patterns fréquents

Quatre erreurs récurrentes qui dégradent la qualité d'un DAS et obligent l'ARB à reprogrammer une session :

1. Le DAS dossier-techno

Le porteur arrive avec 20 pages de spécifications techniques détaillées (schéma de base, API contract, etc.) et omet le « pourquoi » et les risques. L'ARB ne sait pas quoi décider. Fix : séparer le DAS (décision) de la doc technique (implémentation).

2. Le DAS marketing

Beaucoup de bénéfices listés, aucun risque identifié, aucune alternative étudiée. L'ARB sent le pitch et challenge plus durement. Fix : ajoutez systématiquement 1-2 alternatives écartées avec la raison — cela démontre que la décision est instruite.

3. Le DAS « décision floue »

La question 6 n'est pas formulée. L'ARB hésite entre valider un principe, demander un POC, ou attendre une étude complémentaire. La session se termine sans verdict clair. Fix : formuler la décision attendue comme une question fermée (oui/non).

4. Le DAS multi-initiatives

Le porteur mélange deux ou trois initiatives connexes « tant qu'à passer en ARB ». Les verdicts par stakeholder deviennent ambigus. Fix : un DAS = une initiative = une décision. Splitter si nécessaire.

6

En pratique avec Architecture Platform

Le format DAS décrit ci-dessus est implémenté nativement dans Architecture Platform :

  • Template DAS pré-rempliavec les 6 sections — vous remplissez, le format reste cohérent d'une initiative à l'autre.
  • Lien direct au référentiel SI— quand vous citez « Business Application X » ou « Agent IA Y », c'est un lien vivant vers la fiche. Le DAS reste à jour quand la fiche évolue.
  • Schéma intégré — éditeur ArchiMate ou Drawio embarqué, le diagramme vit dans le DAS, pas dans un fichier .vsdx oublié.
  • Workflow ARB G0 → G1 → G2 avec verdicts atomiques par stakeholder. Chaque verdict référence le paragraphe du DAS concerné.
  • Export PDF signé pour les audits SOC 2 / ISO 27001 — le DAS et sa notice ARB forment un dossier opposable.
Aller plus loin. Consultez notre guide complet sur l'Architecture Review Board pour comprendre le processus de revue dans son ensemble.