Template HLSA — Tier 3 (Full cible + livraison)

Template HLSA — Tier 3 (Full cible + livraison)

Cible: 20 à 40 pages · livrables A100 + A270 + A280 + A290 · public: équipe TI cliente, comité de direction, intervenants externes.

Référence de structure: DAE-0007 Trangesco — out/04-portrait-ti-cible/ (Bruno Bock, mai 2026). Ce template formalise la structure utilisée dans ce livrable gold-standard.

Vue d'ensemble — 7 sous-livrables

Le T3 peut être produit comme un seul document monolithique (architecture-cible-{slug}.md) ou comme une série de sous-livrables dans le dossier de phase. Par défaut: monolithique, sauf si l'intrant indique sinon ou si --phase est fourni (alors écrire un fichier par sous-livrable).

Sous-livrable Nom de fichier (si série) Sections
4.1.1 Diagnostic environnement TI actuel 4-1-1-diagnostic-environnement-ti-actuel.md Mise en contexte, portrait organisationnel, inventaire systèmes, dépendances, CMMI, risques
4.1.2 Besoins fonctionnels/opérationnels/techniques 4-1-2-besoins-fonctionnels-operationnels-techniques.md Cartographie 6 domaines TI, besoins par direction, traçabilité diagnostic→besoins, exigences techniques
4.1.3 Diagrammes (L1/L3/L5) diagrams-{slug}-4-1-1-et-4-1-3.md Vues conceptuelle, logique, séquence
4.1.4 Principes directeurs et paramètres 4-1-4-principes-directeurs-parametres.md Principes (8-12), paramètres structurants, hypothèses
4.1.5 Orientations processus internes 4-1-5-orientations-processus-internes.md Domaines d'orientation par priorité, actions structurantes
4.1.6 Synthèse + feuille de route 4-1-6-synthese-consolidee-feuille-de-route.md Constats clés, top besoins, feuille de route par phase
Architecture cible (master) architecture-TI-cible.md Vision, options A/B/C, architecture cible détaillée, décisions, feuille de route, risques, indicateurs

Structure de référence — 22 sections (couvertes par les 7 sous-livrables)

A. Mise en contexte (4.1.1)

  1. Objet du livrable et exigences contractuelles couvertes
  2. Méthode de collecte : tableau ateliers + entrevues + dates + participants
  3. Terminologie : tableau de définitions
  4. Événement déclencheur / driver structurant (ex: déménagement, fusion, audit)

B. Portrait actuel (4.1.1)

  1. Portrait organisationnel : identité juridique, mission, structure (directions + rôles TI), volumétrie opérationnelle
  2. Inventaire TI complet : tableau systèmes (catégorie · utilisateurs · usage · propriété · statut)
  3. Inventaire infrastructure et connectivité
  4. Observations sur l'inventaire (3-5 patterns saillants — ex. "Excel comme pivot", "fragmentation applicative")
  5. Dépendances envers le partenaire/client structurant : matrice (système · nature · criticité · impact si coupure · action requise · horizon)
  6. Maturité CMMI par domaine fonctionnel : tableau CMMI actuel/cible/justification/priorité par processus, vue consolidée, questions de validation
  7. Registre des risques : critères, registre (probabilité × impact × score · cause racine · mitigation · responsable), résumé par niveau
  8. Conclusion du diagnostic : tensions structurelles, forces sur lesquelles bâtir, orientations pour le livrable suivant

C. Besoins et exigences (4.1.2)

  1. Cartographie par domaine d'écosystème TI : 6 domaines obligatoires (Identité numérique, Messagerie/Collaboration, Sécurité, Gestion documentaire, Intégrations, Gouvernance de l'information) — pour chaque: description, besoins clés, dépendances inter-domaines
  2. Matrice de dépendances inter-domaines + séquence de déploiement recommandée
  3. Besoins par direction fonctionnelle : tableau (code besoin · description · capacité BCM · CMMI actuel · priorité · source · domaine TI) pour chaque direction
  4. Table de traçabilité Diagnostic → Besoins : constats C1..CN ↔ besoins
  5. Exigences techniques transversales : code ET-NNN · exigence · catégorie · priorité · constat rattaché · rationale
  6. Questions ouvertes : financières, volumétries manquantes, décisions ouvertes

D. Principes et orientations (4.1.4 + 4.1.5)

  1. Principes directeurs : 8-12 principes (code PA-NN · énoncé · rationale · implications)
  2. Paramètres structurants (architecture, plateforme, langue, repository) + hypothèses
  3. Orientations processus internes : par priorité (1..N) avec enjeu stratégique · objectif · actions structurantes (tableau action · horizon · système cible · processus) · résultat attendu

E. Architecture cible détaillée (master)

  1. Vision et perimètre architectural : énoncé de vision (souvent une citation directrice), tableau périmètre (inclus / hors périmètre)
  2. Options architecturales A/B/C : pour chaque option — description, fonctionnement, avantages, inconvénients, verdict. Puis tableau de comparaison critère par critère. Recommandation avec rationale (4-6 points).
  3. Architecture cible — option recommandée détaillée : structurée en zones fonctionnelles (3-7 zones). Pour chaque zone: tableau composantes (composante · description · fournisseur type · priorité) + responsabilités + questions ouvertes
  4. Vues architecturales — diagrammes :
    • Vue conceptuelle de l'écosystème (Mermaid graph TB avec subgraphs par zone)
    • Vue logique des flux d'information (Mermaid flowchart LR — acteurs ↔ apps ↔ systèmes externes)
    • Vue de séquence — migration ou processus clé (Mermaid sequenceDiagram)
    • Référence aux diagrammes Draw.io générés (L1, L3, L5) sous out/diagrams/

F. Décisions d'architecture (master)

  1. Décisions confirmées : code · décision · base sur · date
  2. Décisions ouvertes : code · décision · options · décideur · horizon · impact si non décidé

G. Feuille de route A270 (master + 4.1.6)

  1. Vue d'ensemble par phase : Phase 0..N · période · objectif principal · décisions requises
  2. Détail par phase : tableau par phase (semaine/mois · action · responsable · livrable/priorité)

H. Estimation A290 (master)

  1. Hypothèses de coûts : taille équipe, durée, taux, contingence
  2. Structure budgétaire : tableau (poste · CAPEX · OPEX an 1 · OPEX an 2-3 · note)
  3. Récapitulatif total + breakeven / ROI si applicable

I. Risques et indicateurs (master)

  1. Registre des risques architecturaux : code · risque · probabilité · impact · niveau · mitigation
  2. Plan de mitigation prioritaire (actions sur risques CRITIQUE/ÉLEVÉ avec date butoir)
  3. Indicateurs de succès architecturaux : tableau (indicateur · valeur actuelle · cible Phase 0/1/2)

J. Pied de document

  • Auteur (Arnaud + AE), date, mandat/contrat
  • Statut (ébauche / pour validation / final)
  • Lien vers décisions ouvertes critiques

Conventions Mermaid pour T3

  • graph TB avec subgraph par zone fonctionnelle (Zone 1..Zone N)
  • Étiquettes courtes avec ligne sur deux niveaux
  • Flèches typées (-->|VPN MFA|, -->|Export données|)
  • flowchart LR pour les flux acteurs ↔ apps
  • sequenceDiagram pour les migrations multi-acteurs

Règles spécifiques T3

  1. Source de vérité = intrant + livrables existants : si un diagnostic 4.1.1 existe déjà sous out/{phase}/, le lire et le citer plutôt que de le régénérer
  2. Traçabilité explicite : chaque besoin doit pointer à un constat ; chaque action de feuille de route doit pointer à un besoin ou un risque
  3. Codification systématique :
    • Principes : PA-NN
    • Exigences techniques : ET-NNN
    • Besoins fonctionnels : BF-{DOMAINE}-NN
    • Constats diagnostic : C1..CN
    • Risques : R-NN
    • Décisions : D-NNN (ouvertes) ou D-XXX confirmées
  4. Diagrammes Mermaid inline : T3 inclut les Mermaid directement (pas seulement Draw.io)
  5. Pas d'invention : À compléter ou Non documenté partout où nécessaire — listes de questions ouvertes structurées
  6. Mode --phase : produire la série de fichiers (4-1-1..4-1-6 + master). Mode normal : produire un seul architecture-cible-{slug}.md qui concatène l'équivalent.
  7. Fin de chaque sous-livrable : footer avec auteur, date, version, statut, mandat (si fourni)

Adaptation au contexte du projet

Tous les exemples ci-dessus sont inspirés de DAE-0007 (Trangesco — sortie de filiale TI). Pour d'autres contextes:

  • Projet d'intégration applicative simple : sections A, C, E (24-25), F, G suffisent — sauter B (portrait actuel détaillé) et D (principes/orientations) si déjà couverts ailleurs
  • Migration cloud / refonte plateforme : focus sur B, C, D, E (zones), G (phases)
  • Évaluation de systèmes (style DAE-0007) : structure complète A→J

Le skill /ea-archi-cible doit adapter la profondeur de chaque section au contenu disponible dans l'intrant — pas forcer une section vide.