Ce document présente un survol de haut niveau des principaux éléments à couvrir pour réussir la mise en œuvre d’une transformation et modernisation organisationnelle efficace. Ce survol est basé sur les bonnes pratiques afin de produire la feuille de route technologique (roadmap) alignée sur la stratégie d’affaires et sa gouvernance.

1. © 2015 Miguel Iriart, Marcelo Zampa
Transformation organisationnelle
Plan de transformation basé sur
l’architecture d’entreprise
Miguel Iriart
MBA, TOGAF 9, ArchiMate 2, PMP,
CGEIT, COBIT 5, PSM, CISA, ITIL
Marcelo F. Zampa
MBA

2. © 2015 Miguel Iriart, Marcelo Zampa
Table des matières
Introduction ...............................................................................................................................1
Modèles stratégiques et architecture d’entreprise..................................................................3
L’architecture d’entreprise .................................................................................................3
Le modèle d’affaires et le modèle opérationnel.................................................................5
La gestion de portefeuille de projets et la gestion de projet.............................................6
La gestion de portefeuille d’applications...........................................................................8
Gestion des capacités organisationnelles............................................................................. 10
Le cadre de référence TOGAF®.............................................................................................. 11
La méthode de développement d’architecture (ADM)..................................................... 11
ArchiMate®.............................................................................................................................. 13
TOGAF® et ArchiMate® .......................................................................................................... 13
Conclusion .............................................................................................................................. 14
Références............................................................................................................................... 16

3. © 2015 Miguel Iriart, Marcelo Zampa 1
Introduction
Ce document présente un survol de haut
niveau des principaux éléments à couvrir
pour réussir la mise en œuvre d’une
transformation et modernisation
organisationnelle efficace. Ce survol est
basé sur les bonnes pratiques afin de
produire la feuille de route technologique
(roadmap) alignée sur la stratégie d’affaires
et sa gouvernance.
Les gestionnaires de chaque organisation ont besoin de générer et de gérer
efficacement les changements organisationnels, en plus d’aligner les investissements en
TI sur leurs stratégies d’affaires.
La tendance actuelle nous montre que la durée de chaque cycle économique diminue
en fonction des changements de la concurrence et des technologies. La mauvaise
synchronisation et la faible communication entre les niveaux stratégique, tactique et
opérationnel génèrent le manque d’agilité qui empêche l’organisation de s’adapter
rapidement aux changements.
Réussir l’implantation d’une stratégie d’affaires pour combler ces lacunes est un défi
d’envergure, car, en général, les parties prenantes de ces différents niveaux
organisationnels agissent en fonction de leurs propres réalités et contextes.
Pour améliorer la communication entre les participants impliqués dans les processus
opérationnels et les stratégies d’affaires, on utilise des modèles d’affaires. Le résultat
de la réalisation de ces modèles est utilisé par l'architecture d'entreprise et, ensuite,
par la conception et l’implantation des processus d’affaires. Par la suite, ces processus
devront être supportés par les applications informatiques et l’infrastructure
technologique.
À la différence d’une architecture TI conventionnelle, ce concept d’architecture
d’entreprise (AE) englobe une vision beaucoup plus large de l’organisation,
donc, une vision holistique sans cloisonnement de portée.
Au cours des dernières années, la gestion de l’architecture d’entreprise a évolué
d'une vision exclusive de systèmes d’information, à une approche vers la gestion
stratégique d’entreprises.

4. © 2015 Miguel Iriart, Marcelo Zampa 2
Le parcours entre la situation actuelle et la situation cible passe à travers cette
architecture d’entreprise, évolutive, de transition, qui est la base décisionnelle de chaque
composante du portefeuille de projets et du portefeuille d’applications, en
respectant en tout temps la capacité organisationnelle.
EPM – Enterprise Portfolio Management

5. © 2015 Miguel Iriart, Marcelo Zampa 3
Modèles stratégiques et architecture d’entreprise
L’architecture d’entreprise
L’architecture d’entreprise s’appuie sur la décision stratégique d’une organisation
d’implanter une méthode structurée pour définir sa feuille de route en transformation
organisationnelle et en investissement TI, en s’assurant que ces derniers respectent
l’alignement stratégique sur les besoins d’affaires.
Cette méthode est basée sur l’évaluation continue des services d’affaires, des
processus d’affaires, des applications, et de l’infrastructure technologique qui les
supporte.
Le résultat de l’application de cette méthode est un plan de transformation qui présente
les améliorations souhaitées au portefeuille d’applications, pour arriver à la situation
cible stratégiquement définie préalablement.
Il existe une relation étroite et naturelle entre :
• l’architecture d’entreprise;
• les modèles d’affaires et la gestion des opérations;
• la gestion de portefeuille de projets;
• la gestion de projet;
• la gestion de portefeuille d’applications.

6. © 2015 Miguel Iriart, Marcelo Zampa 4
L’architecture d’affaires doit être intégrée et synchronisée avec les architectures des
données, des applications et technologique. Cette intégration définit le style et la
méthode utilisée pour la modélisation, le déploiement et les interrelations de chacune
des composantes.
L’architecture d’entreprise devrait gérer et communiquer les standards adoptés afin que
les projets les utilisent et les respectent.
Pour commencer la démarche de ce programme, les gestionnaires devront visualiser
l’organisation dans le futur et définir :
• l’état cible des affaires;
• les capacités organisationnelles;
• les modifications nécessaires afin de supporter la nouvelle stratégie d’affaires.
L’architecture d’entreprise fait une revue des capacités d’affaires et une évaluation
de l'état de préparation à la transformation organisationnelle. Elle utilise une
méthode précise permettant de définir et de planifier cette transformation sur la base
des principes de planification en focalisant sur les résultats.
Source: TOGAF® 9 - http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 6.2.6 Relating the Management Frameworks

7. © 2015 Miguel Iriart, Marcelo Zampa 5
Le modèle d’affaires et le modèle opérationnel
D’abord, on doit préciser les différences entre ces deux modèles.
• Le modèle opérationnel, ou de fonctionnement, représente la façon dont
l’organisation réalise ses activités afin d'accomplir sa mission. Ces activités sont
représentées par les processus d’affaires, d’organisation et technologiques.
• Le modèle d'affaires décrit comment une organisation crée de la valeur, la délivre
et la capture.
À partir de ces modèles, les gestionnaires pourront modéliser l’état actuel et l’état cible
en utilisant des techniques spécialisées, comme les sessions de remue-méninges
(brainstorming) et autres. Les écarts entre ces deux états permettront de définir le plan
de transformation et les besoins organisationnels pour y arriver.
Les processus d’affaires
Un processus d’affaires présente les étapes pour livrer un produit ou un service
déterminé. Quand on fait référence aux activités internes d’une organisation, on parle
d’un processus de type fonctionnel. Par ailleurs, si on met l’accent sur les besoins
des clients, on parle dans ce cas d’un processus d’entreprise.
Amélioration des processus d’affaires
Toute initiative de l’organisation doit considérer les stratégies, les cycles d’affaires,
l’intégration de ressources humaines, les processus et les technologies, afin de réaliser
de façon efficiente un produit ou un service d’affaires.
Dans un programme d’amélioration des processus d’affaires, on doit d’abord faire la
cartographie de ces processus, et ensuite appliquer la technique de la chaîne de valeur
afin de classifier chaque activité de chaque processus selon la valeur apportée à
l’organisation.
En ayant comme objectif l’optimisation de chaque processus, il faut éliminer les
activités sans valeur ajoutée, et maximiser celles perçues comme nécessaires par le
client (les activités avec valeur ajoutée pour les affaires).
Dans une période d’austérité budgétaire ou d’instabilité économique,
l’optimisation des processus d’affaires devrait faire partie des priorités de
l’organisation.
Les organisations doivent faire face à de nouveaux défis stratégiques et
tendances informatiques. Celles qui ont déjà commencé leurs plans de
transformation possèdent un avantage significatif afin d’améliorer leur
performance et leur compétitivité sur le marché.

8. © 2015 Miguel Iriart, Marcelo Zampa 6
La gestion de portefeuille de projets et la gestion de projet
L’architecture d’entreprise matérialise le plan de transformation à partir de la
réalisation d’« architectures de transition » successives. Dans ces architectures, on
doit visualiser les projets et les programmes de projets alignés sur la cible finale.
Cet ensemble de projets et de programmes de projets constitue le portefeuille de
projets de l’organisation. Chaque composante de ce portefeuille doit soigneusement
être identifiée, évaluée et priorisée, en s’assurant de toujours garder un bon équilibre
organisationnel et d’avoir les capacités nécessaires pour garantir la réalisation.
Le suivi fréquent de son avancement, à
partir de l’établissement de points de
contrôle précis et de tableaux de bord,
permettra de détecter tout écart et de
mettre en place les actions correctives
au bon moment, si nécessaire.
La gestion de portefeuille de projets est un processus décisionnel dans lequel chaque
composante, projet ou programme, est constamment mise à jour et révisée.
La gestion de portefeuille de projets vise à obtenir l’assurance que l’on réalise
les bons projets, alors que la gestion de projet vise à obtenir l’assurance que
chaque projet est réalisé correctement. Ces deux gestions sont nécessaires et
complémentaires.

9. © 2015 Miguel Iriart, Marcelo Zampa 7
Relation entre la planification stratégique, les opérations, les projets, les programmes et le portefeuille de projets.
Source: Figure 3-3 - The Standard for Portfolio Management – ©2006 Project Management Institute, Inc.
Un programme est défini comme un groupe de projets apparentés, de sous-
programmes et d’activités de programme, dont la gestion est coordonnée afin
d’en tirer des avantages que n’apporterait pas une gestion individuelle.
Guide PMBOK – Cinquième édition – © PMI
Certains facteurs peuvent indiquer la présence d’une problématique dans la gestion du
portefeuille de projets, telles que l’existence d’une quantité élevée de projets, une faible
valeur ajoutée pour l’organisation ou un manque d’alignement sur les objectifs
stratégiques.
La gestion de portefeuille de projets doit être placée au cœur de la gouvernance
de l’organisation.
Relation entre les composants de l’AE

10. © 2015 Miguel Iriart, Marcelo Zampa 8
La gestion de portefeuille d’applications
Certaines situations liées à l’évolution des stratégies d’entreprise ou aux tendances de
l'industrie informatique sont à l’origine des scénarios de duplication des services et des
applications, de la sous-utilisation ou de la désuétude, avec un important impact sur les
coûts opérationnels de l’organisation et sur la charge de travail de l’équipe de support
technologique.
Exemples de situations liées à :
l’évolution des stratégies d’entreprise
Exemples de situations liées aux :
tendances de l'industrie informatique
- les regroupements et les fusions;
- les acquisitions;
- la diversification;
- le commerce électronique;
- l’externalisation;
- les nouveaux canaux de distribution; …
- le Web 2.0 et 3.0; les services Web; le Cloud;
- le “bureau mobile”;
- SOA;
- l’Open Source, la virtualisation;
- ERP et CRM;
- les réseaux sociaux; …
La réalisation d’une cartographie d’applications va permettre d’identifier les sources de
ces situations problématiques.
L’optimisation du portefeuille d’applications, de même que la gestion de
leur cycle de vie, doit faire partie des priorités stratégiques de l’organisation
afin de minimiser les dépenses opérationnelles et d’entretien.
Ainsi, des économies potentielles (de 10 à 20 %) pourraient être investies pour
la réalisation de nouvelles initiatives.
En règle générale, pour une moyenne ou grande entreprise :
• 20 % des applications pourraient être consolidées en éliminant les fonctionnalités superflues;
• 20 % des applications pourraient être remplacés ou retirés.
La gestion de portefeuille d’applications (GPA) doit exécuter d’une manière rigoureuse
les activités suivantes :
• cartographier les applications;
• les catégoriser par différents critères, p. ex. :
- type d’application (stratégique, opérationnelle, de support, etc.);
- alignement sur l’AE et sur la valeur stratégique;
- coûts de maintenance;
- type de développement (maison ou achat), et autres.
• pondérer et donner un score à chaque application à partir des données quantitatives
et qualitatives.
Cette technique va permettre de positionner les applications sur les axes stratégiques
de l’organisation, afin d’identifier et d’évaluer une stratégie adaptée à chacune (p. ex. :
migrer, retirer, standardiser, consolider, etc.).
Cette veille technologique sur les applications doit être faite continuellement, ce
qui permettra aux organisations d’assurer la qualité de leur portefeuille
d’applications, leur productivité et un alignement optimal sur les stratégies
d’affaires.

11. © 2015 Miguel Iriart, Marcelo Zampa 9
Par ailleurs, une GPA efficace permet d’assurer l’alignement entre le portefeuille
d’applications et le portefeuille de projets, ce qui représente une diminution des coûts et
des risques associés à la réalisation des projets.
Ratio du budget d’entretien vs les nouvelles initiatives
• En général, la plupart du budget TI est consacrée à la maintenance des
applications (+/- 80 %), et seule une partie minime (+/- 20 %) est affectée aux
nouvelles initiatives.
• Chaque organisation doit établir son propre ratio d’utilisation du budget (p.
ex. 70/30, 60/40, etc.) selon les axes stratégiques définis par la direction
stratégique.

12. © 2015 Miguel Iriart, Marcelo Zampa 10
Gestion des capacités organisationnelles
Pour réaliser efficacement le plan de transformation organisationnelle, l’organisation doit
identifier et bâtir ses propres capacités, et ce, pour chaque domaine essentiel.
L’organisation doit s’assurer que chaque capacité dont elle dispose réalisera ses
responsabilités de façon efficace et efficiente, et qu’elle arrivera au niveau de maturité
requis afin de garantir la réalisation du plan de transformation.
• Il y a différents cadres de référence de maturité pour chaque domaine de
l’architecture d’entreprise.
• On trouve le cadre de maturité d’architecture dans le référentiel TOGAF® 9 1
,
ainsi que la description des rôles et compétences 2.
• Le modèle OPM3® (Organizational Project Management Maturity Model) du
PMI est le cadre de maturité pour la gestion de portefeuille, de programmes,
et de projet.
Source: Figure 2 - EA Domain Positioning – Livre: Enterprise Architecture Good Practices
Guide: How to Manage the Enterprise Architecture Practice - Jaap Schekkerman – © IFEAD
1
TOGAF ® - http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 51. Architecture Maturity Models
2
TOGAF ® - http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 52. Architecture Skills Framework; 52.6 Generic
Role and Skills of the Enterprise Architect; 52.6.3 Key Characteristics of an Enterprise Architect

13. © 2015 Miguel Iriart, Marcelo Zampa 11
Le cadre de référence TOGAF®
« TOGAF® est un cadre d’architecture – Le cadre d’architecture de l’Open Group (The
Open Group Architecture Framework). En résumé, TOGAF® est un outil d’aide à
l’appropriation, à la production, à l’utilisation et à la maintenance des architectures. Il se
fonde sur un modèle de processus itératifs faisant appel aux bonnes pratiques et à un
actif architectural réutilisable. TOGAF® 9 peut être utilisé pour développer une large
gamme d’architectures d’entreprise. TOGAF complète d’autres cadres conceptuels
(frameworks) et peut s’utiliser conjointement avec eux. » 3
The Open Group est un consortium de normalisation neutre vis-à-vis des
fournisseurs et des technologies (c'est-à-dire qu'il ne dépend pas d'une firme ou
d'une technologie en particulier) composé de plus de trois cents organisations
membres. 4
Une façon de vulgariser un cadre de travail (framework) d’AE est de définir l’AE comme
une méthode pour tracer le parcours vers les résultats. À l’intérieur de chacune de
ses phases de réalisation, on intègre et recommande l’utilisation de différents domaines
de connaissances, d’autres cadres5
(p. ex. PMBOK®, ITIL®, COBIT®, etc.), de bonnes
pratiques et de techniques existantes dans chaque domaine, pour définir un plan de
transformation harmonisé, efficace et efficient, afin d’arriver à l’état cible défini par les
objectifs et orientations de la stratégie d’affaires de l’entreprise.
La méthode de développement d’architecture (ADM)
Parmi toutes les parties du cadre de référence TOGAF, l’ADM est celle qui mérite un
traitement préférentiel dans ce document.
« L'ADM, qui est le fruit des contributions d'un grand nombre d'architectes, est le cœur
de TOGAF. Il s'agit d'une méthode permettant d'élaborer des architectures d'entreprise
propres à chaque organisation. Elle est spécifiquement conçue pour répondre aux
exigences de l'entreprise. L'ADM décrit :
• Une démarche fiable et éprouvée permettant de développer et d'utiliser une
architecture d'entreprise.
• Une méthode de développement d'architectures à des niveaux différents (affaires,
applications, données, technique) qui permet à l'architecte de bien prendre en
compte un jeu complexe d'exigences.
• Des recommandations concernant les outils utilisés dans le développement d'une
architecture. » 6
3
TOGAF™ Version 9 – Guide de Poche – The Open Group
4
Wikipedia
5
Source : http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 2.10 Using TOGAF with Other Frameworks
http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - 5.3 Adapting the ADM
6
TOGAF™ Version 9 – Guide de Poche – The Open Group - 2.1 Qu'est-ce que l'ADM ?

14. © 2015 Miguel Iriart, Marcelo Zampa 12
Les phases de l’ADM de TOGAF
Les activités de l'ADM phase par phase 7
Phase ADM Activité
Phase préliminaire Préparer l'organisation pour la réussite des projets d'architecture TOGAF.
Entreprendre les activités de préparation et de démarrage nécessaires pour
aligner les recommandations d’affaires sur une nouvelle architecture
d’entreprise, incluant la définition d’un cadre d’architecture et les outils
propres à l’organisation, avec la définition des principes.
Gestion des
exigences
Chaque stade d'un projet TOGAF fait appel à des exigences d’affaires et
valide ces dernières. Les exigences sont identifiées, stockées et délivrées
comme entrants et sortants des phases ADM concernées, qui traitent et
hiérarchisent ces exigences.
A. Vision de
l'architecture
Définir la portée, les contraintes et les attentes d'un projet TOGAF.
Créer une vision de l'architecture. Définir les parties prenantes.
Valider le contexte d’affaires et créer la définition du chantier d'architecture.
Obtenir les approbations.
B. Architecture
d’affaires
C. Architecture des
systèmes
d'information
D. Architectures
techniques
Développer les architectures à trois niveaux :
• Affaires
• Systèmes d'information (applications et données)
• Technologique
Dans chaque cas, développer les architectures initiale et cible, et analyser
les écarts.
E. Opportunités et
solutions
Effectuer une première planification de mise en œuvre et une première
identification des modalités de livraison pour les Building Blocks identifiés
lors des phases précédentes. Identifier les principaux projets de mise en
œuvre et les regrouper dans les architectures de transition.
F. Planification de la
migration
Analyser les avantages et les risques financiers.
Développer un plan détaillé de mise en œuvre et de migration.
G. Gouvernance de
la mise en œuvre
Assurer la supervision de la mise en œuvre. Préparer et diffuser les contrats
d'architecture (Comité de gouvernance de la mise en œuvre). Vérifier que le
projet de mise en œuvre respecte l'architecture.
H. Gestion du
changement
d'architecture
Assurer un suivi continu, et prévoir un processus de gestion des
changements garantissant que l'architecture réponde aux besoins de
l'organisation et qu’elle rende maximale la valeur ajoutée pour les affaires.
7
TOGAF™ Version 9 – Guide de Poche – The Open Group - Tableau 3

15. © 2015 Miguel Iriart, Marcelo Zampa 13
ArchiMate®
ArchiMate® est un langage de modélisation, ouvert et libre, pour l'architecture
d'entreprise. Il est supporté par différents fournisseurs.
Il fournit des instruments pour permettre aux architectes d'entreprise de décrire,
d’analyser et de visualiser sans ambigüité les relations entre les domaines d'affaires.
Pour cette raison, il est rapidement devenu le langage standard pour réaliser cette
modélisation.
Le cadre de référence TOGAF® et ArchiMate® sont tous les deux des standards
ouverts, supportés et harmonisés par The Open Group.
TOGAF® et ArchiMate®
Le langage ArchiMate 2.0 met l’accent sur la description des quatre domaines
d’architecture de TOGAF (affaires, données, applications et technologie) ainsi que sur
leurs relations et dépendances, et les extensions pour modeler la Motivation et la
planification de la migration et de l’implantation, afin d’implémenter toutes les
composantes de la méthode ADM de TOGAF.
Source : Figure 5 : Relation entre TOGAF et ArchiMate
Livre : ArchiMate® 2 Certification Guide
Source : Figure 6 : Relation entre ArchiMate et l’ADM de TOGAF
Livre : ArchiMate® 2 Certification Guide
• TOGAF et ArchiMate sont naturellement complémentaires.
• ArchiMate est aussi complémentaire à tous les autres langages et notations de
modélisation, tels qu’UML et BPMN. Chacune de ces modélisations a ses
particularités et avantages, et possède des fonctionnalités complémentaires à
celles d’ArchiMate.
• Autres possibilités d’utilisation d’ArchiMate : la modélisation des risques
d’entreprise, l’ajout d’attributs pour faciliter la gestion des applications,
l’évaluation des coûts des stratégies, la réalisation des analyses d’impact, etc.

16. © 2015 Miguel Iriart, Marcelo Zampa 14
Conclusion
La solution à la problématique présentée commence par le démarrage d’un plan
d’architecture d’entreprise, en ayant comme objectif principal l’obtention d’une feuille de
route de la transformation organisationnelle et technologique alignée sur la stratégie
d’affaires.
Les résultats recherchés par le plan de transformation organisationnelle basé sur
l’architecture d’entreprise se résument à l’agilité, la transparence, la maximisation des
bénéfices, la minimisation des coûts et la réduction des risques.

17. © 2015 Miguel Iriart, Marcelo Zampa 15
Pour assurer le succès de la transformation organisationnelle et sa pérennité dans le
temps, le plan doit tenir compte de :
• l’évaluation de l’état de préparation de l’organisation face à la transformation
d’affaires, l’évaluation de la capacité organisationnelle, et la gestion des risques liés
à cette transformation 8
;
• la maîtrise des processus d’affaires jusqu’au niveau de maturité choisi afin de
donner à l’organisation l’agilité nécessaire pour livrer efficacement ses produits et
ses services;
• une gestion efficace du portefeuille d’applications mettant l’accent sur la valeur
ajoutée organisationnelle;
• une gestion de projet rigoureuse qui vise à obtenir l’assurance que l’on réalise
correctement les projets, afin d’obtenir les bénéfices escomptés;
• une gestion de portefeuille de projets efficace et optimisée en tenant compte de
la capacité organisationnelle et de la gestion des résultats;
• l’utilisation des meilleures pratiques et des cadres de référence reconnus
internationalement, comme TOGAF® et ArchiMate® (pour l’AE), PMBOK® (pour la
gestion de projet), ITIL®, COBIT® et autres.
Finalement, nous préconisons une approche basée sur l’intégration et l'alignement de
toutes ces différentes disciplines, indépendantes et complémentaires, pour que
l’organisation soit équipée de tous les éléments nécessaires (stratégies, processus,
méthodes, techniques et outils), afin de garantir la réussite de la transformation
organisationnelle visée.
8
http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - TOGAF® - 7. Phase A: Architecture Vision - 7.4.4 Evaluate
Business Capabilities - 7.4.5 Assess Readiness for Business Transformation - 7.4.10 Identify the Business
Transformation Risks and Mitigation Activities

18. © 2015 Miguel Iriart, Marcelo Zampa 16
Références
1. TOGAF® Version 9.1 - © 2011, The Open Group
2. TOGAF® 9.1 – http://pubs.opengroup.org/architecture/togaf9-doc/arch/ - © The Open Group
3. TOGAFTM
Version 9 – Guide de Poche, © 2009, The Open Group
4. ArchiMate® 2.1 – Specification - © 2012, The Open Group
5. ArchiMate® 2.1 - http://pubs.opengroup.org/architecture/archimate2-doc/toc.html © The
Open Group
6. ArchiMate® 2.0 – A Pocket Guide - © 2012, The Open Group
7. Guide du corpus des connaissances en management de projet (Guide PMBOK®) –
Cinquième édition – © 2013, PMI
8. The Standard for Program Management (PgMP®) - Third Edition – © 2013, PMI
9. The Standard for Portfolio Management - Third Edition – © 2013, PMI
10. Organizational Project Management Maturity Model (OPM3®) – Third Edition - © 2013, PMI
11. Enterprise Architecture Good Practices Guide: How to Manage the Enterprise Architecture
Practice - Jaap Schekkerman – © 2008, Institute For Enterprise Architecture Developments
TOGAF® et ArchiMate® sont des marques enregistrées par The Open Group.
PMBOK®, OPM3®, PgMP® sont des marques enregistrées par Project Management Institute Inc.
Les auteurs ont fait les démarches qu’ils ont estimées nécessaires pour obtenir les autorisations des
détenteurs des droits d’auteur (copyright) du matériel inclus dans cette œuvre. Dans le cas d’un oubli
involontaire, on demande au détenteur d’accepter nos excuses et de nous contacter pour régler dans
les plus brefs délais cette situation.