COMPRENDRE / OGEA-101
Vos révisions
Théorie gratuite, sans compte · TOGAF Foundation
Pourquoi faire de l’architecture d’entreprise ?
Relier les changements de l’organisation, les investissements et les systèmes aux objectifs communs de l’entreprise.
Entreprise, finalité et bénéfices de l’EA
Délimiter l’« entreprise » visée par un travail d’architecture, comprendre à quoi sert une Enterprise Architecture, reconnaître les cinq familles de bénéfices que TOGAF lui associe et savoir quelles situations déclenchent un tel travail.
Comprendre la certification EA Foundation
Situer OGEA-101 dans le parcours TOGAF et préparer un examen qui vérifie la compréhension des fondamentaux.
Certification et déroulement de l’examen OGEA-101
Ce que valide la certification EA Foundation, comment l’examen est construit et comment s’y préparer efficacement.
Les quatre domaines d’architecture
Distinguer Business, Data, Application et Technology Architecture tout en comprenant leurs relations.
Domaines et niveaux d’abstraction : une grille
Croiser les quatre domaines d’architecture et les quatre niveaux d’abstraction pour savoir de quoi l’on parle (le domaine) et à quel degré de détail (le niveau), en reliant chaque niveau à une question fondamentale.
Glossaire : domaines et types d'architecture
Les définitions des quatre domaines (Business, Data, Application, Technology) se ressemblent et se confondent facilement à l'examen. Cette fiche reformule chacune d'elles, ajoute les deux sens du mot « architecture », la Solution Architecture et la Digital Architecture, puis donne des critères simples pour classer un élément dans le bon domaine.
Passer du contexte à la réalisation
Utiliser les niveaux contextuel, conceptuel, logique et physique pour choisir le bon degré de détail.
Framework, méthode et langage de modélisation
Comprendre ce qu’apportent TOGAF, une classification comme Zachman et un langage comme ArchiMate.
Pourquoi TOGAF convient comme framework d’EA
Identifier les arguments qui font de TOGAF un framework d’EA adapté : ce qu’on attend d’un architecture framework, une démarche standard qui réduit le risque, trois apports concrets et une grande capacité d’adaptation et d’intégration avec d’autres pratiques.
Système, architecture et description
Distinguer la réalité étudiée, ses caractéristiques architecturales et les informations utilisées pour les exprimer.
Parties prenantes, préoccupations et rôles
Identifier les personnes concernées, ce qui compte pour elles et les responsabilités qu’elles exercent.
Glossaire : acteurs, parties prenantes et énoncés d'intention
Qui agit, qui est concerné, et comment exprimer ce que l'on attend ? Cette fiche reformule les définitions d'Actor, Role, Stakeholder et Concern, puis celles de trois énoncés souvent confondus : Requirement, Architecture Principle et Objective. Elle ajoute des critères simples pour classer un énoncé.
Views, viewpoints et modèles
Choisir une représentation adaptée à une préoccupation sans confondre règles de représentation et résultat produit.
Classer et réutiliser avec l’Enterprise Continuum
Situer les architectures et solutions entre références générales et besoins propres à une organisation.
L’Enterprise Continuum en détail
Approfondir l’Enterprise Continuum comme outil de classification et de communication : ce qu’il classe, ses deux continuums liés par une relation de guidage et de support, ses niveaux du générique au spécifique et son articulation avec l’Architecture Repository.
Capacité métier et capacité d’architecture
Distinguer ce que l’entreprise sait faire de ce qui lui permet de pratiquer l’architecture durablement.
Faire fonctionner la capacité d’architecture
Comprendre ce qu’est une capacité d’Enterprise Architecture, comment l’établir comme une unité opérationnelle à part entière, quels services elle rend à l’entreprise et pourquoi la gouvernance est au cœur de son fonctionnement.
Services d’architecture, Service Portfolio et Foundation Architecture
Comment la capacité d’architecture rend ses services, et deux définitions souvent oubliées : Service Portfolio et Foundation Architecture.
La documentation TOGAF 10 : standard, guides et Library
Comprendre comment la 10e édition est organisée — six documents de Fundamental Content, des Series Guides qui rendent les concepts opérationnels et une TOGAF Library de référence — et pourquoi ce découpage modulaire facilite une adoption progressive.
Les huit composants de l’Architecture Repository
Savoir où ranger chaque type d’actif d’architecture : pourquoi un repository structuré devient indispensable, quels sont ses huit composants, comment distinguer les composants voisins et comment il s’insère dans l’Enterprise Repository.
Glossaire : états de l'architecture et vocabulaire du changement
Baseline, Target, Transition, Gap, Work Package, Roadmap : ces termes décrivent tous le passage d'un état à un autre, mais chacun répond à une question différente. Cette fiche les reformule à partir des définitions du chapitre 4 du standard et montre comment les enchaîner sans les confondre.
Glossaire : Landscape, niveaux et partitions
L'examen teste souvent la différence entre Strategic, Segment et Capability Architecture, ainsi qu'entre niveau et partition. Cette fiche part des définitions exactes du standard, reformulées, pour distinguer ce qui découpe le Landscape par granularité de ce qui le découpe pour en répartir la gestion.
Glossaire : capacités, valeur et services métier
Capability, Business Capability, Business Model, Value Stream, Business Function, Business Service, Product : ces termes métier apparaissent dans la Business Architecture et dans de nombreux scénarios d'examen. Cette fiche donne leur définition reformulée et la question à se poser pour reconnaître chacun d'eux.
Glossaire : cadres, méthodes, gouvernance et interopérabilité
Framework, Method, Architecture Framework, ADM, Governance : ces mots structurent tout le discours TOGAF, mais leurs définitions précises sont rarement mémorisées. Cette fiche les reformule et y ajoute les termes liés aux services et à l'échange d'information : Interoperability, Service Orientation, SOA et Boundaryless Information Flow.
Utiliser le Standard TOGAF et le rôle de The Open Group
Les conditions d’utilisation et de téléchargement du standard, la mission de The Open Group et ce qu’apporte l’Architecture Forum.
L’ADM : développer et faire évoluer l’architecture
Comprendre les objectifs des phases et le caractère itératif d’une méthode guidée par les exigences.
Le cycle ADM : dix éléments et leur finalité
Vue d’ensemble de l’Architecture Development Method : ce qu’elle couvre, la finalité de chacun de ses dix éléments, et la bonne manière de lire son schéma, qui est un modèle de référence et non une cascade d’étapes.
Draft, approved et itération : gouverner l’évolution
Une architecture évolue sans cesse. Cette fiche explique comment l’ADM qualifie le statut des livrables, à quels niveaux il itère, et pourquoi la création et la maintenance de l’architecture doivent être gouvernées.
Preliminary Phase : préparer la pratique
Établir une capacité d’architecture adaptée à l’organisation avant de conduire un travail particulier.
Preliminary Phase : déterminer puis établir la capacité
La Preliminary Phase ne produit pas d’architecture cible : elle construit la capacité qui en produira. Objectifs, activités clés, principales entrées, étapes et sorties à connaître.
Du contexte métier à la demande de travail
Comprendre pourquoi une initiative d’architecture commence et ce que le Request for Architecture Work apporte.
Phase A : Architecture Vision et périmètre
Établir une direction compréhensible et obtenir l’autorisation d’un travail d’architecture précisément cadré.
Phase A : objectifs, entrées, étapes et livrables
Tout développement d’architecture commence par la phase A. Elle cadre le travail, fédère les parties prenantes autour d’une vision et se conclut par l’approbation d’un Statement of Architecture Work. Voici ce qu’elle consomme, ce qu’elle fait et ce qu’elle produit.
Phases B, C et D : développer les domaines
Passer d’une vision aux architectures baseline et target avec une démarche commune, adaptée à chaque domaine.
Phase B : développer la Business Architecture
La phase B traduit la vision en une description de la manière dont l’entreprise doit fonctionner. Objectifs, entrées, étapes communes aux phases de domaine et livrables à connaître.
Phase C : Data et Application Architecture
La phase C, Information Systems Architectures, développe deux architectures complémentaires qui rendent possible la Business Architecture : les données et les applications. Objectifs, ordre de travail, contenu et livrables.
Phase D : développer la Technology Architecture
La phase D décrit les moyens technologiques qui permettront de livrer les building blocks métier, données et applications définis en amont. Objectifs, entrées, contenu, livrables et passage vers la phase E.
Phase E : solutions, roadmap et transitions
Assembler les changements architecturaux en travaux cohérents et définir des étapes utiles vers la cible.
Phase E en détail : des gaps aux work packages
La Phase E, Opportunities & Solutions, est la charnière entre la définition de l’architecture et sa mise en œuvre. Elle part des écarts identifiés dans les phases de domaine, les regroupe en work packages évalués et produit la première Architecture Roadmap complète. Cette fiche reprend sa finalité, ses objectifs, ses entrées, ses étapes et ses livrables.
Phase F : planifier la migration
Transformer la roadmap en un plan réaliste, coordonné avec les portefeuilles, programmes et projets.
Phase F en détail : du plan initial aux projets approuvés
La Phase F, Migration Planning, transforme la roadmap initiale de la Phase E en un plan de migration détaillé, coordonné avec le portefeuille de changements de l’entreprise. Elle aboutit à des projets approuvés, dotés de ressources et datés, et clôt le cycle de développement de l’architecture avant le passage à la gouvernance de la mise en œuvre.
Phase G : contrats et conformité
Gouverner la réalisation afin que les solutions respectent les engagements architecturaux tout en traitant les écarts.
Phase G en détail : gouverner la mise en œuvre
La Phase G, Implementation Governance, accompagne la réalisation des projets définis en Phase F. L’architecture n’y construit pas la solution : elle encadre, contrôle la conformité et arbitre les écarts. Cette fiche détaille la finalité de la phase, ses objectifs, ses entrées, ses étapes et ses livrables.
Phase H et Requirements Management
Garder l’architecture pertinente et gérer les exigences pendant toutes les phases du cycle.
Phase H en détail : piloter le changement d’architecture
La Phase H, Architecture Change Management, surveille l’architecture une fois déployée, mesure la valeur réellement obtenue et décide de la réponse aux changements : simple ajustement ou nouveau cycle ADM. Cette fiche détaille sa finalité, ses objectifs, ses étapes, la classification des changements et ses livrables.
Requirements Management : le processus au cœur de l’ADM
Requirements Management n’est pas une phase parmi d’autres : c’est un processus continu, placé au centre du cycle, qui identifie, stocke et suit les exigences d’architecture et les met à disposition de chaque phase. Cette fiche précise sa finalité, ses objectifs, ce qu’il fait et ne fait pas, ses étapes et ses livrables.
Cadrer une architecture et comparer les alternatives
Avant de modéliser, il faut fixer les limites du travail : pourquoi les restreindre, selon quelles dimensions, et comment éviter que plusieurs équipes se marchent dessus. Puis, une fois la cible esquissée, pourquoi en comparer plusieurs.
Flux d’information et livrables à travers l’ADM
Le schéma circulaire de l’ADM ne décrit pas une suite d’activités mais la circulation de l’information entre les phases. Suivre les livrables d’une phase à l’autre, qui les crée, qui les enrichit, qui les finalise, est la meilleure façon de comprendre ce flux et de répondre aux questions d’examen sur les phases.
Définir des principes d’architecture utiles
Formuler des règles durables qui relient les choix d’architecture aux valeurs et objectifs de l’entreprise.
Architecture Principles : à quoi servent-ils et d’où viennent-ils ?
Avant de rédiger un principe, il faut savoir à quoi il servira et à quel niveau il se situe. Cette fiche détaille les quatre finalités des Architecture Principles, les acteurs qui les produisent et les approuvent, et leur place dans la hiérarchie qui part des Enterprise Principles.
Rédiger et relire un principe : template, pièges et critères
Cette fiche est une check-list de rédacteur. Elle reprend le template en quatre rubriques sous l’angle « que mettre, que ne pas mettre », liste les pièges de formulation signalés par TOGAF, puis montre comment diagnostiquer un ensemble de principes à l’aide des cinq critères de qualité.
Engager les parties prenantes et communiquer
Adapter les échanges à chaque groupe pour construire une compréhension et des décisions partagées.
Stakeholder management : identifier, classer, engager
La gestion des parties prenantes est une technique des ADM Techniques qui aide à obtenir le soutien nécessaire à l’architecture. Elle n’est pas un objectif du programme Foundation, mais elle éclaire de nombreuses questions de Phase A. Cette fiche présente ses bénéfices, ses quatre étapes, les catégories de parties prenantes et la grille pouvoir/intérêt.
Business Scenarios et objectifs SMART
Décrire un problème métier complet pour découvrir des exigences et préciser des résultats attendus.
Mener un business scenario pas à pas
Un business scenario transforme un problème métier en exigences d’architecture exploitables. Cette fiche suit la méthode étape par étape, précise ce qu’un scénario décrit et ne décrit pas, détaille les objectifs SMART et situe la technique dans l’ADM.
Capability Assessment et préparation au changement
Évaluer les capacités et les conditions humaines ou organisationnelles nécessaires à la transformation.
Business Transformation Readiness Assessment : mode d’emploi
Une architecture peut être juste sur le papier et échouer faute de préparation humaine. La Business Transformation Readiness Assessment évalue et quantifie la capacité de l’organisation à changer. Cette fiche explique quand la mener, avec qui, selon quelles activités, et comment ses résultats alimentent les risques et le plan de migration.
Identifier, réduire et suivre les risques
Relier l’incertitude aux objectifs et distinguer risque initial, mesures de réduction et risque résiduel.
Gestion des risques : de l’initial au résiduel
Comprendre le risque comme effet de l’incertitude sur les objectifs, distinguer appréciation et gestion du risque, suivre le processus décrit par TOGAF et situer risque initial, risque résiduel et acceptation par la gouvernance.
Gap Analysis et arbitrages
Identifier les différences significatives entre états et comparer des alternatives selon les préoccupations réelles.
Gap Analysis pas à pas : la matrice
Construire et lire la matrice de Gap Analysis pour valider une architecture : axes Baseline et Target, ligne « New », colonne « Eliminated », mention « Included » et traitement de chaque écart identifié.
Penser l’interopérabilité dès les besoins
Permettre aux organisations, systèmes et services de partager une information compréhensible et exploitable.
Interopérabilité : deux classifications et une carte des phases
L’interopérabilité est la capacité à partager information et services. Cette fiche distingue les deux grilles de lecture proposées par TOGAF (catégories métier et formes d’intégration inspirées de l’EAI), retrace la manière dont l’interopérabilité se précise de la Phase A à la Phase F, puis présente les degrés d’interopérabilité décrits dans les ADM Techniques.
L’ADM et ses techniques : qui fait quoi ?
L’ADM décrit les phases et leurs objectifs ; les techniques et guides expliquent comment réaliser concrètement certaines étapes. Comprendre cette répartition permet de savoir où chercher l’aide utile et de reconnaître, à l’examen, ce qui relève d’une phase et ce qui relève d’une technique.
Appliquer l’ADM à différents besoins
Adapter le travail architectural à la stratégie, au portefeuille, au projet ou à la livraison d’une solution.
Quatre finalités pour dimensionner un projet
Avant de lancer un Architecture Project, il faut savoir à quoi servira l’architecture produite. Le Series Guide G186 propose quatre finalités : soutenir la stratégie, un portefeuille, un projet ou la livraison d’une solution. Chacune fixe un horizon, une étendue et une profondeur différents, et oriente aussi ce que l’on range dans l’Enterprise Architecture Repository. Cette fiche compare ces finalités pour savoir les reconnaître dans un scénario.
ADM, agilité et autres approches
Le TOGAF ne s’oppose pas à l’Agile ni aux autres référentiels : il se combine avec eux. Cette fiche explique où l’ADM rejoint le développement Agile, ce que l’architecture apporte aux équipes Agile, comment le standard aborde l’agilité d’entreprise et comment il s’intègre à d’autres cadres comme ITIL ou PRINCE2.
Naviguer dans le standard, 10e édition
Comprendre la structure modulaire du Fundamental Content, des Series Guides et de la bibliothèque TOGAF.
Itérer dans l’ADM : schémas et cycles
Le cercle de l’ADM ne se parcourt pas comme une liste de tâches. Le standard décrit plusieurs façons d’itérer : enchaîner des cycles complets pour enrichir l’Architecture Landscape, faire travailler plusieurs phases en parallèle au sein d’un même cycle, et faire évoluer la capacité d’architecture elle-même. Cette fiche explique ces schémas, les quatre cycles d’itération qui regroupent les phases et les situations qui justifient chacun d’eux.
Classer le Landscape et répartir le travail
Une grande entreprise décrit simultanément des dizaines d’architectures, certaines très générales, d’autres très détaillées. Pour s’y retrouver, TOGAF classe l’Architecture Landscape selon trois caractéristiques et trois niveaux, puis découpe le travail en partitions confiées à des équipes. Cette fiche montre comment ces deux outils se complètent sans se confondre.
Adapter TOGAF : guides, frameworks et styles
TOGAF est un framework générique : il ne s’applique jamais tel quel. Le standard indique où trouver des conseils d’application, comment combiner TOGAF avec d’autres frameworks et bonnes pratiques, et comment le mettre au service d’un style d’architecture particulier. Cette fiche rassemble ces trois angles d’adaptation.
EA, entreprise numérique et agilité
Les entreprises numériques livrent produits et services en cycles courts. L’Enterprise Architecture n’y freine pas les équipes : elle les aide à aller plus vite en gérant la dette technique, en fournissant des composants réutilisables et en simplifiant un écosystème devenu complexe. Le standard distingue aussi l’agilité d’entreprise du développement logiciel agile et montre quels concepts de TOGAF la rendent possible.
Comprendre la gouvernance d’architecture
Organiser les décisions, l’autorité et la responsabilité pour orienter le changement de façon cohérente.
Nature, niveaux et cadre de la gouvernance d’architecture
La gouvernance d’architecture ne se résume ni à un comité ni à une liste de règles. C’est un système de décision qui oriente et contrôle les architectures à l’échelle de l’entreprise, s’insère dans une hiérarchie de gouvernances plus large et s’appuie sur un cadre qui sépare processus, contenu et contexte. Cette fiche donne la vue d’ensemble à maîtriser pour l’objectif 6.1.
Caractéristiques et bénéfices de la gouvernance
Pourquoi gouverner l’architecture ? TOGAF répond de deux façons : par six caractéristiques qui disent à quoi ressemble une bonne gouvernance, et par une liste de bénéfices concrets pour l’entreprise. Cette fiche aide à reconnaître chaque caractéristique dans un scénario et à argumenter la valeur de la gouvernance (objectif 6.2).
Architecture Board et droits de décision
Coordonner les parties prenantes, traiter la non-conformité et faire évoluer la capacité EA de manière gouvernée.
L’Architecture Board en pratique
L’Architecture Board est l’élément central d’une stratégie de gouvernance réussie, mais son rôle est souvent mal compris. Cette fiche distingue ce que le Board possède de ce qui appartient aux parties prenantes, puis classe ses responsabilités en trois groupes (générales, opérationnelles, de gouvernance), avant d’aborder sa mise en place (objectif 6.3).
Les Architecture Contracts tout au long de l’ADM
Un Architecture Contract n’est pas un document unique signé en phase G : il en existe plusieurs, à différents moments de l’ADM, entre des parties différentes. Cette fiche suit le fil de ces contrats, leur contenu type et la façon dont la gouvernance s’en sert (objectif 6.4).
Conformité d’architecture : revues, niveaux et dispensations
Vérifier que les projets respectent l’Enterprise Architecture est un aspect essentiel de la gouvernance. Cette fiche explique pourquoi et quand on mène des revues de conformité, comment qualifier précisément le résultat avec les six niveaux de conformité de TOGAF, et que faire lorsque la conformité n’est pas atteinte (objectif 6.5).
Organiser le contenu d’architecture
Distinguer Content Framework, Content Metamodel, artifact et deliverable pour produire des descriptions cohérentes.
Content Framework et Enterprise Metamodel
Avant de produire le moindre livrable, une pratique d’architecture doit décider comment ranger ses productions et quels types d’éléments elle décrit. Le Content Framework fournit la grille de classement des produits de travail ; l’Enterprise Metamodel fixe les types d’entités et leurs relations. Ensemble, ils rendent les sorties de l’ADM cohérentes, complètes et traçables.
Deliverable, artifact, building block : qui contient quoi
Les trois catégories de produits de travail ne s’opposent pas : elles s’emboîtent. Un deliverable contractuel regroupe des artifacts, et chaque artifact présente une view sur un ou plusieurs building blocks. Savoir placer un produit dans la bonne catégorie, selon son contexte d’usage, est une compétence attendue à l’examen.
Architecture et Solution Building Blocks
Faire évoluer une capacité attendue vers des composants de réalisation sans choisir trop tôt un fournisseur.
Les building blocks au fil de l’ADM
Un building block naît comme une idée abstraite en phase A et finit, en phase E, rattaché à un work package. Entre les deux, les phases B, C et D appliquent un même schéma en quatre étapes qui fait passer des ABB aux SBB. Cette fiche suit ce parcours et rappelle ce qui fait un bon building block.
L’Architecture Repository
Organiser les informations d’architecture, leur statut et leur traçabilité dans un patrimoine réellement utilisable.
Niveaux du paysage et partitionnement
Relier architecture stratégique, architecture de segment et architecture de capacité sans perdre la cohérence d’ensemble.
Engagements, description et exigences
Distinguer Statement of Architecture Work, Architecture Definition Document et Architecture Requirements Specification.
Livrables clés : définir l’architecture
Pendant les phases B, C et D, deux livrables jumeaux grossissent ensemble : le Architecture Definition Document, qui exprime l’intention des architectes, et l’Architecture Requirements Specification, qui en tire des critères mesurables. Savoir ce que chaque phase y ajoute permet de répondre aux questions « quel livrable » et « quelle phase ».
Demandes de changement et analyse d’impact
Faire évoluer une décision de manière contrôlée lorsque de nouvelles informations modifient le contexte.
Glossaire : produits de travail, building blocks et patterns
Artifact, Deliverable, Building Block, Pattern, Reference Model : ces termes désignent ce que produit ou réutilise une équipe d'architecture. Cette fiche donne leur définition reformulée, les critères qui les séparent et le lien avec les adjectifs Logical et Physical, qui expliquent la relation entre ABB et SBB.
Glossaire : modèles, métamodèles et vues
Model, Modeling, Model Kind, Metamodel, Metadata, View, Viewpoint : une famille de termes très proches, que les questions d'examen opposent volontiers. Cette fiche les définit un par un et montre comment ils s'emboîtent, de la technique de modélisation jusqu'au recueil organisé des vues.
Catalogs, matrices et diagrams en pratique
Les artifacts se présentent sous trois formes complémentaires : la liste, le tableau de relations et l’image. Reconnaître la forme d’un artifact à partir de sa description, et savoir à quelle étape de l’ADM il apparaît typiquement, aide à lire les deliverables et à répondre aux questions de classement.
Livrables clés : lancer le travail d’architecture
La Preliminary Phase et la phase A produisent les livrables qui cadrent tout le reste : la demande du sponsor, les principes, le cadre adapté, l’accord sur le travail, la vision, le plan de communication et l’évaluation des capacités. Cette fiche donne pour chacun sa finalité, son contenu typique et sa phase.
Livrables clés : planifier, gouverner, faire évoluer
À partir de la phase E, l’accent se déplace vers la planification, la gouvernance de la réalisation et la gestion des évolutions. Les descriptions d’architecture continuent d’être affinées, notamment avec les Transition Architectures. Roadmap, plan de migration, modèle de gouvernance, contrats, conformité, demandes de changement et analyse d’impact forment cette seconde moitié du jeu de livrables.
Des concerns aux views dans les livrables
Un livrable d’architecture n’est utile que s’il répond aux questions de ceux qui le lisent. Le modèle issu d’ISO/IEC/IEEE 42010 relie stakeholders, concerns, viewpoints, views et modèles en une chaîne logique. Cette fiche montre comment la suivre pour construire le contenu des livrables, plutôt que de réciter les définitions.