L4 — La Vision (Phase A) : éviter les choix hâtifs

« The Architecture Vision phase sets the scope, constraints, and expectations for a TOGAF architecture project. » — The Open Group, TOGAF Series Guide — Architecture Vision (G174e)

« Une décision sans architecture est une décision sans lendemain. »

Vidéo d’introduction

---

---

L’avion qui décolle sans plan de vol

Au printemps 2018, Bertrand prend la tête de la DSI de Discount Voyages — un voyagiste en ligne de taille moyenne, 250 salariés, 80 millions d’euros de chiffre d’affaires. L’entreprise a doublé son volume de réservations en trois ans grâce à un site web performant, mais le système d’information est devenu un monstre spaghetti : douze applications métier qui ne se parlent pas, une base de données clients éclatée en trois silos, une équipe de développement qui travaille à 80 % sur la dette technique plutôt qu’à la création de valeur.

Le COMEX est clair : « il faut moderniser le SI ». La question est comment. Trois visions s’affrontent. Le directeur commercial veut un « site web refondu avec un moteur de recommandation IA » — il a vu un concurrent le faire. Le directeur financier veut un « progiciel intégré qui remplace tout » — il a vu trois cabinets lui promettre des ROI mirifiques. La directrice des opérations veut un « outil de gestion des opérations back-office » — elle étouffe dans les tableurs.

Les trois visions sont incompatibles. Elles coûteraient ensemble plus de douze millions d’euros. La trésorerie ne permet pas d’en financer plus de trois. Et personne n’a posé la question préalable : que cherche-t-on vraiment à résoudre ?

C’est exactement le rôle de la Phase A — Architecture Vision. Son but n’est pas de trancher entre les trois visions. Son but est de poser un cadrage qui rend la décision possible et défendable : périmètre, contraintes, parties prenantes, critères de succès, exigences principales. Une fois ce cadrage posé, les trois visions peuvent être comparées objectivement, sans tomber dans le piège du plus-fort-qui-parle-le-mieux.

L’Open Group l’a défini ainsi : « The Architecture Vision phase sets the scope, constraints, and expectations for a TOGAF architecture project ». C’est court. C’est exactement ce que Bertrand n’avait pas fait : poser le scope, les contraintes, et les attentes. Il avait foncé sur la première vision venue — celle du commercial, qui avait la voix la plus forte.

C’est ce que cette leçon cherche à vous apprendre : comment poser une Phase A qui transforme une décision politique en une décision technique argumentée.

Le schéma suivant résume la mécanique que cette leçon cherche à transmettre :

📊

Schéma

Le triangle de la Phase A — Stakeholder → Driver → Objective

Comment une Vision d'architecture se formule : partir des acteurs, capturer leurs préoccupations, en tirer des objectifs mesurables.

---

Premier principe — La Phase A est l’antidote à l’architecture après décision

Le piège de l’« architecture après décision » est le plus coûteux de tous. La Phase A est l’antidote, à condition d’être menée avant que les décisions structurantes ne soient prises.

L’« architecture après décision » consiste à être appelé après que la direction a déjà tranché (« on refait le site web », « on achète le progiciel X »), avec pour mission de produire les plans qui justifient la décision. Ce n’est plus de l’architecture, c’est de la documentation rétrograde. Le rôle de l’architecte est réduit à celui d’un projeteur qui dessine ce que le maître d’ouvrage a déjà décidé.

La Phase A remet l’architecte à sa place : avant la décision. Son livrable central n’est pas un modèle de cible ; c’est un Statement of Architecture Work qui pose les questions préalables. Ce document a une fonction politique autant que technique : il rend visible le périmètre des choix à faire, les parties prenantes à consulter, les critères de succès à respecter.

Chez Discount Voyages, Bertrand aurait pu tenir la Phase A en six semaines. Mais il faut, pour cela, qu’il accepte de ne pas livrer tout de suite. La tentation est grande de produire une cible pour faire plaisir au COMEX. Résister à cette tentation, c’est précisément ce qui distingue un architecte d’un projeteur.

La parade : accepter que la Phase A est un acte de non-production — on ne livre pas de cible, on livre une méthode pour en choisir une. C’est ce qui rend cette phase difficile à vendre aux directions habituées à des livrables tangibles.

Et toi ? Combien de fois as-tu été appelé pour « documenter » une décision déjà prise ? Combien de fois as-tu accepté ce rôle sans protester ? Qu’aurais-tu pu faire pour reprendre la main en amont ?

---

Deuxième principe — Les Business Scenarios capturent les exigences par le dialogue

Une Phase A réussie ne commence pas par un diagramme. Elle commence par des conversations structurées avec les parties prenantes. Le cadre TOGAF appelle ces conversations les Business Scenarios.

L’Open Group a publié un guide dédié à cette technique : le TOGAF Series Guide to Business Scenarios (G176e). L’idée est de remplacer les discussions vagues (« il nous faut un nouveau SI ») par des dialogues structurés autour de scénarios concrets. Chaque un le suit une méthode en six étapes :

1. Identifier le problème — quel est le problème concret que les acteurs essaient de résoudre ?
2. Identifier et modéliser les acteurs humains — qui sont les parties prenantes, et quel est leur intérêt dans le problème ?
3. Identifier et modéliser les acteurs informatiques — quels systèmes existants jouent un rôle dans le problème ?
4. Identifier et modéliser les intérêts des acteurs — qu’est-ce qui compte pour chaque acteur ? Quels sont ses critères de succès ?
5. Identifier et modéliser les dépendances — quelles relations entre les acteurs ? Quels événements déclenchent quoi ?
6. Vérifier et raffiner le un le — confronter le un le aux parties prenantes, ajuster, valider.

L’avantage de cette méthode est qu’elle transforme des opinions en énoncés testables. Au lieu de dire « le commercial veut un nouveau site web », on peut dire « le commercial veut réduire le taux d’abandon de panier de 35 % à 20 % d’ici 18 mois, mesurable via Google Analytics ». L’exigence devient mesurable. Le débat devient technique, plus politique.

Chez Discount Voyages, Bertrand a appliqué la méthode des Business Scenarios sur trois semaines. Il a rencontré le commercial, le financier, l’opérationnel, et trois clients clés. À l’issue, il avait trois scénarios formalisés, avec pour chacun un problème nommé, des acteurs identifiés, des intérêts mesurables, et des résultats attendus datés. C’est sur cette base que la Phase A a pu être écrite — et que le COMEX a pu trancher de manière informée.

Et toi ? Sur ton dernier projet, as-tu formalisé les exigences en scenarios structurés avant de produire le moindre schéma ? Ou as-tu directement dessiné des diagrammes sans avoir posé les questions préalables ?

---

Troisième principe — Formuler des objectifs SMART, pas des vœux

Une Phase A qui contient des objectifs vagues produit des architectures vagues. La parade est la formulation SMART — pas pour cocher une case de consultant, mais pour rendre les exigences testables.

L’acronyme SMART (Spécifique, Mesurable, Atteignable, Réaliste, Temporellement défini) est un vieux réflexe du conseil en organisation. Il est souvent moqué pour son côté formulaire. Il reste utile en Phase A, à condition d’être pris au sérieux.

Un objectif non-SMART : « moderniser le SI de Discount Voyages ». Que signifie « moderniser » ? Comment mesure-t-on ? Pour quand quel cet objectif a-t-il un sens, il doit passer quatre tests :

• Spécifique — un énoncé clair que deux interlocuteurs comprendraient de la même manière
• Mesurable — un indicateur chiffré, et une source de mesure identifiée
• Atteignable — une trajectoire crédible, pas une ambition hors de portée
• Réaliste — un alignement avec les contraintes réelles (budget, équipe, temps)
• Temporellement défini — une date butoir, pas un horizon vague

Un objectif SMART : « Réduire le taux d’abandon de panier de 35 % à 20 % d’ici 18 mois, mesurable via Google Analytics, sur la base d’une refonte du tunnel d’achat ». La différence est considérable : le premier ne peut pas être contesté parce qu’il ne peut pas être vérifié ; le second peut l’être.

La contrefaçon à éviter : la formulation SMART purement cosmétique — des objectifs qui paraissent SMART mais qui ne sont en réalité pas mesurables (parce que la source de mesure n’existe pas, ou parce que l’indicateur ne reflète pas vraiment l’intention). La parade est de tester chaque indicateur en demandant « comment mesure-t-on cet objectif aujourd’hui, et qui a accès à cette mesure ? ». Si la réponse est floue, l’objectif n’est pas SMART en pratique.

Et toi ? Sur tes cinq derniers livrables d’architecture, combien d’objectifs sont SMART au sens propre ? Combien sont SMART en apparence mais invérifiables en pratique ?

---

Quatrième principe — Le Diagramme de Concept de Solution est le livrable central

Une Phase A ne produit pas de modèle de cible détaillé. Elle produit un Diagramme de Concept de Solution — un schéma qui montre les grandes options architecturales à l’étude, sans prétendre à l’exhaustivité.

Le Diagramme de Concept de Solution est l’outil qui rend la Phase A concrète. C’est un schéma volontairement haut niveau — quelques boîtes, quelques flèches, des couleurs — qui représente les grandes options en lice. Sa fonction n’est pas de tout dire, mais de rendre visible le périmètre de la décision.

Pour Discount Voyages, Bertrand a produit un Diagramme de Concept de Solution qui présentait trois options :

• Option A — Refonte du site web avec moteur de recommandation IA
• Option B — Acquisition d’un progiciel intégré (avec migration complète des données)
• Option C — Outil back-office de gestion des opérations, sans toucher au front

Chaque option était représentée par un schéma simplifié, avec ses dépendances principales, ses risques, ses coûts estimés. Le COMEX a pu comparer les trois options en 45 minutes, avec un support visuel clair, sans se perdre dans les détails.

Le Diagramme de Concept de Solution n’est pas une cible — c’est un menu. Il sert à choisir, pas à exécuter. Une fois l’option choisie, le reste du cycle ADM (Phase B, C, D…) détaillera l’option retenue.

Et toi ? Sur ton dernier projet d’architecture, as-tu produit un schéma haut-niveau qui présentait les options en lice — ou as-tu foncé sur une seule option sans en avoir fait l’inventaire ? Quelle a été la qualité de la décision finale ?

---

Cinquième principe — Le sponsor s’engage sur la Phase A, pas sur la Phase F

Le dernier piège classique consiste à obtenir l’engagement du sponsor sur la totalité du cycle — un engagement de 18 mois, 12 millions d, 50 personnes-mois. Cet engagement est impossible à honorer et reste lettre morte.

La Phase A dure en pratique 6 à 8 semaines. Son livrable est léger (15 à 30 pages). Son coût est modéré (1 à 3 personnes-mois). C’est ce sur quoi le sponsor doit s’engager. Pas sur les 12 millions à venir, pas sur les 50 personnes-mois. Sur les 6 semaines et les 1-3 personnes-mois de la Phase A.

Une fois la Phase A livrée et validée, le sponsor dispose d’un cadrage clair pour engager — ou non — la Phase B. C’est ce qui rend la gouvernance soutenable : chaque phase est un engagement de faible ampleur, avec un point de validation explicite. Si le cadrage de la Phase A révèle que les ambitions initiales sont intenables, le sponsor peut redéfinir le périmètre avant que des millions ne soient engagés.

Chez Discount Voyages, Bertrand a obtenu un engagement ferme du COMEX sur 8 semaines de Phase A. Le périmètre a été réduit après le cadrage (la troisième option — outil back-office — s’est avérée être un prérequis aux deux autres, et a été engagée en premier). Sans ce cadrage progressif, les trois options auraient été engagées en parallèle, et la moitié du budget aurait été gaspillée.

Et toi ? Sur ton dernier cycle, quel engagement formel as-tu obtenu de ton sponsor ? Sur 8 semaines ou sur 18 mois ? L’engagement correspondait-il à ce que tu pouvais réellement livrer dans la période ?

---

Application — Mon Business Scenario

À rédiger séance tenante. Six sections précises. À afficher à un endroit visible et à confier à deux personnes de confiance.

1. Le problème — Quel est le problème concret que mes parties prenantes essaient de résoudre ? En une phrase, formulé du point de vue de l’act, (pas du point de vue de la DSI).
2. Les acteurs humains — Qui sont les trois à cinq parties prenantes principales, et quel est leur intérêt personnel dans le problème ? Nommer les personnes réelles, pas les fonctions abstraites.
3. Les acteurs informatiques — Quels deux à quatre systèmes existants jouent un rôle dans le problème ? Décrire brièvement leur état actuel et leurs limites.
4. Les intérêts — Pour chaque acteur, quel est son critère de succès ? Comment le mesure-t-on aujourd’hui ?
5. Les dépendances — Quel événement déclenche le problème ? Quelle séquence d’événements le résoudrait ?
6. La validation — Avec qui vais-je tester ce scénario avant de l’engager dans la Phase A ?

Ce document d’une page est votre premier livrable de Business Scenario. C’est le matériau brut de votre Phase A.

---

Encadré Au lecteur / À l’animateur

Question d’ouverture : « Sur ton prochain projet d’architecture, combien d’exigences sont formalisées sous forme SMART aujourd’hui ? »

Profils à observer :

• Le récitant qui connaît Phase A mais ne l’a jamais pratiquée. Cite TOGAF, énumère les livrables, n’a jamais tenu un Business Scenario. Question : « Quel est ton dernier Statement of Architecture Work ? »
• Le politicien qui cherche l’option qui plaît plutôt que l’option vraie. Adapte son cadrage aux desiderata du COMEX. Question : « Sur quel indicateur ton cadrage repose-t-il en dernier ressort ? »
• Le projeteur qui veut passer directement à la cible. Trouve la Phase A trop abstraite, veut dessiner. Question : « Quel est le risque si tu n’alignes pas les parties prenantes avant de proposer une cible ? »
• L’isolement du sponsor. N’a personne pour valider sa Phase A, signe seul. Question : « Avec qui partages-tu ton Statement of Architecture Work avant de le présenter ? »

Pièges d’animation :

• Ne pas laisser la discussion dériver vers les détails de la Phase B. Rappeler que la Phase A est un acte de cadrage politique, pas un exercice de modélisation.
• Ne pas confondre Phase A et étude d’opportunité. L’étude d’opportunité peut être antérieure à la Phase A. La Phase A commence une fois l’opportunité validée.

---

Cas pratique — Construction d’un Schéma Directeur Omnicanal (Retail)

Contexte sectoriel : chaîne de distribution retail, 3 000 employés, 250 magasins physiques, présence e-commerce en croissance. L’objectif stratégique est de passer de 15 % à 30 % du chiffre d’affaires réalisé en ligne dans les trois prochaines années. Le marché est dominé par des pure-players digitaux (Amazon, Cdiscount, Veepee) qui ont élevé les standards de réactivité client.

Diagnostic de l’existant. L’architecture en silos provoque un désalignement critique : 4 % des commandes web sont annulées car le produit, affiché disponible, a été vendu en magasin physique entre-temps. Le coût d’opportunité et l’atteinte à l’image de marque imposent une unification immédiate. Le système de stock actuel fonctionne par magasin : chaque point de vente gère son propre inventaire, avec un délai de consolidation de 24 heures vers le siège.

Parties prenantes clés :

• Directeur Retail (pouvoir élevé, intérêt élevé) — co-décideur de la stratégie omnicanal.
• Responsable E-commerce (pouvoir élevé, intérêt élevé) — moteur du projet.
• RSSI (pouvoir élevé, intérêt moyen) — devient partie prenante pivot : l’ouverture du SI de stock via API expose l’entreprise à de nouveaux vecteurs d’attaque (API tierces, comparateurs, partenaires web).
• Directeurs de magasins (pouvoir moyen, intérêt élevé) — craignent la perte de visibilité sur leur stock et la complexité des nouveaux processus.
• Équipes logistiques (pouvoir faible, intérêt élevé) — bénéficiaires du projet mais sous-informés.

Méthodologie de construction du Schéma Directeur.

Le passage du AS-IS au TO-BE repose sur les « commandements de l’architecte » :

1. L’exposition par API est le seul vecteur d’accès aux données de stock. Aucun accès direct (« SQL direct ») aux bases de données ne sera toléré pour garantir l’intégrité des flux.
2. Single Source of Truth : le stock central est le maître. Aucun système local ne peut surcharger une disponibilité sans synchronisation immédiate.
3. L’indépendance des plateformes : la solution doit permettre d’intégrer de nouveaux transporteurs en moins de quatre semaines, sans modifier le cœur du système.

Construction étape par étape :

1. Analyse de l’existant (As-Is) : cartographier les sources de données stock, les flux de mise à jour, les fréquences, les silos (par magasin, par enseigne, par transporteur).
2. Définition des objectifs cibles : « Zéro rupture web sur 95 % du catalogue d’ici 18 mois », « Réduction du délai de mise à jour stock de 24h à 5 minutes ».
3. Établissement des principes d’architecture : API-first, event-driven pour les événements de stock, observabilité unifiée.
4. Description de la cible (To-Be) : plateforme de stock unifiée avec Event Sourcing, API Gateway, propagation temps réel vers tous les canaux (web, mobile, magasin, comparateurs).
5. Trajectoire : trois vagues (quick wins / fondations / déploiement massif).
6. Gouvernance : arbitrage des écarts via Architecture Review Board intégrant le RSSI dès la première revue.

Livrables attendus de l’apprenant (Schéma Directeur de trois pages) :

• Page 1 : Contexte stratégique, parties prenantes, principes d’architecture.
• Page 2 : Architecture cible avec schéma de flux, API exposées, événements émis.
• Page 3 : Roadmap sur 18 mois, avec critères de succès chiffrés.

Pièges classiques à éviter :

• Tomber dans la sur-modélisation de l’existant. Ne pas viser l’exhaustivité ; viser la valeur métier de la vision cible.
• Minimiser l’enjeu de cybersécurité. Une API exposée sans protection devient le point d’entrée des attaquants.
• Négliger la communication vers les directeurs de magasin, qui peuvent bloquer le projet par inertie.

Critères d’évaluation : le SD est validé si l’apprenant (1) propose une cible simplifiée plutôt qu’exhaustive, (2) chiffre le gain attendu (réduction du taux d’annulation web), (3) identifie un chemin critique d’intégration en moins de quatre semaines pour un nouveau transporteur.

---

Ce que la leçon 5 vous demande

Ouvrez votre dossier d’architecte à la page suivante. Préparez :

• Un Business Scenario formalisé selon les 6 étapes G176e, en une page.
• Un Diagramme de Concept de Solution avec trois options au maximum, présentées de manière comparable (coût, délai, risque, bénéfice).
• Un sponsor identifié qui pourra valider votre Phase A dans les 8 semaines.

---

Sources de cette leçon : TOGAF Series Guide to Business Scenarios (G176e) · Desfray & Raymond, TOGAF en pratique (chap. 6) · Cas Discount Voyages (anonymisé)

Leçon suivante : L5 — L’Architecture Métier (Phase B) : la Business Capability Map.