Vous êtes sur la page 1sur 109

Introduction à TOGAF 9.

1
Ismail AHDACH – Business & Technical Consultant
Historique…

"TOGAF is a framework - a detailed method and a set of supporting tools - for developing an
enterprise architecture. It may be used freely by any organization wishing to develop an enterprise
architecture for use within that organization" [Open Group]

"Enterprise architecture is a widely used approach to properly govern and manage enterprises, yet
it can only provide benefits when managed through a well-defined methodology and framework
supported by a robust model-driven repository. TOGAF 9 provides a common vocabulary and content
metamodel." [MEGA]

TOGAF V1 publiée en 1995: Basée sur TAFIM

TOGAF V8.1 publiée en 2003

TOGAF V9 publiée en 2009

2
Généralités & Définitions…

Qu’est ce qu’une entreprise?

Pourquoi a-t-on besoin d’une architecture d’entreprise?

Qu’est ce qu’un Framework d’architecture?

Qu’est ce que TOGAF?

Qu’est ce qu’une architecture du point de vue TOGAF?


Une description formelle d'un système ou un plan détaillé du système et de ses composants
pour guider leurs mises en œuvre

 Une structure des composants, leurs relations, ainsi que les principes et les lignes
directrices régissant leur conception et leur évolution dans le temps

Pourquoi a-t-on besoin de TOGAF comme framework d’architecture d’entreprise?

3
Généralités & Définitions…
Terme Définition

Domaine d’architecture La zone de l'étude architecturale. Il ya quatre domaines


d'architecture au sein de TOGAF: Business, données,
applications et technologies.
Architecture Business Une description de la structure et de l'interaction entre la
stratégie métier, l'organisation, les fonctions, les processus
opérationnels et les besoins en information.
Architecture de données Une description de la structure des actifs (des données logiques
et physiques) d’une organisation et les ressources de gestion de
ces données.
Architecture d’application Une description de la structure et de l'interaction des applications
en tant que groupes de fonctions qui assurent des fonctions clés
de l'entreprise et de gérer les actifs de données.
Architecture technique décrit les capacités logicielles et matérielles qui sont nécessaires
pour soutenir le déploiement du Business, données et les
services applicatifs. Cela inclut l'infrastructure, middleware,
réseaux, les communications, le traitement…

4
Généralités & Définitions…
Terme Définition

Plateforme d’application L’ensemble des composantes technologiques hardware et


software qui fournissent les services utilisés pour supporter les
applications.
Style d’architecture La combinaison des caractéristiques distinctives de l'architecture
qui est effectuée ou exprimée.
Building Block Représente un composant (potentiellement réutilisables) métier,
IT, ou la capacité d’architecture qui peut être combiné avec
d'autres éléments (buinding blocks) afin de livrer des
architectures et des solutions.
Partie Prenante (Stakeholder) Une personne, une équipe ou une organisation ayant des intérêts
dans, ou des préoccupations par rapport à l'issue de
l'architecture. Différents acteurs ayant des rôles différents ont des
préoccupations différentes.
Paysage d’architecture La représentation architecturale des actifs utilisés, ou prévus, par
l'entreprise à des moment donnés dans le temps.
Vision d’architecture Une description brève de l'architecture cible de sa valeur métier
et les changements apportés à l'entreprise qui découleront de
son déploiement réussi. Elle définit aussi une limite de
développement de l'architecture détaillée. 5
Généralités & Définitions…
Terme Définition

Référence (Baseline) Une spécification qui a été officiellement examiné et approuvé,


qui sert par la suite de base et de référence pour le
développement ou le changement et qui ne peuvent être
modifiées que par des procédures formelles de contrôle des
modifications ou un type de procédure telles que la gestion de
configuration.
Capacité Peut être définit comme le savoir-faire que possède une
organisation, une personne ou système. Les capacités sont
généralement exprimées en termes généraux et de haut niveau
et nécessitent généralement une combinaison de l'organisation,
des personne, des processus et de la technologie pour les
réaliser.
Capacité d’architecture Une description très détaillée de l'approche architecturale pour la
réalisation d’une solution ou un aspect particulier de solution.
Incrément de capacité Une portion discrète d'une architecture de capacité qui offre une
valeur spécifique. Une capacité sera dite réalisée quand tous ses
incréments s’achèvent

6
Généralités & Définitions…

Terme Définition

Gouvernance métier Soucieux de veiller à ce que les processus métier et les


politiques (et leur fonctionnement) obtiennent les résultats
opérationnels et respectent une réglementation business
pertinente.
Service métier Prend en charge les capacités métier grâce à une interface
définie explicitement et est explicitement régi par une
organisation.
Préoccupation Les principaux intérêts qui sont d'une importance cruciale pour
les parties prenantes dans un système. Ils déterminent
l'acceptabilité du système. Les préoccupations peuvent porter sur
n'importe quel aspect du fonctionnement du système, le
développement ou l'exploitation, y compris des considérations
telles que la performance, la fiabilité, la sécurité, la distribution, et
l'évolutivité.

7
Généralités & Définitions…

Terme Définition

Ecart C’est l’énoncé de la différence entre deux états. Il est utilisé dans
le cadre de l'analyse de l’écart, une technique utilisée pour
identifier la différence entre l’architecture de base et l'architecture
cible.
Architecture stratégique Une description formelle et résumée de l'entreprise. Elle fournit ,
à un niveau exécutif, un cadre d'organisation des activités
opérationnelle et de changement, ainsi qu’une vision à long
terme pour leur direction.
Architecture de transition Une description formelle d'un état d’architecture, d'un point de
vue architectural significatif dans le temps. Une ou plusieurs
architectures de transition peuvent être utilisées pour décrire la
progression dans le temps à partir de l’architecture de base
(Baseline) de base de l'architecture cible.
Méthodologie Des séries d'étapes répétitives et bien définies pour résoudre un
type de problème particulier. Elle se base généralement sur un
processus défini. Elle peut aussi inclure la définition du contenu.

8
Structure du document TOGAF
Partie 1: Introduction -Présente un survole du vocabulaire TOGAF
- Contient les notes de mise à jour détaillant la différence
entre cette version et la version précédente
Partie 2: Méthodologie de développement d’architecture Décrit l’ADM, une démarche pas-à-pas pour le
(ADM) développement d’une architecture d’entreprise
Partie 3: Recommandations et Techniques ADM Présente un ensemble de recommandations et de
techniques utilisables pour l’application de l’ADM
Partie 4: Framework de contenu Décrit le framework de contenu de TOGAF qui comprend
un métamodèle structuré des éléments d'architecture,
l'utilisation de building blocks d'architecture et un aperçu
général d'exemples types de livrables d'architecture
Partie 5: Continuum d’entreprise et outils Analyse les taxonomies et les outils permettant de
catégoriser et de stocker les sorties d’une activité de
développement d’architecture au sein d’une entreprise
Partie 6: Modèles de Référence TOGAF Propose deux modèles de référence d’architecture, à
savoir le Modèle de Référence Technique (TRM) et le
Modèle de Référence d’Infrastructure d’Information
Intégrée (III-RM).
Partie 7: Framework de capacité TOGAF Traite de l’organisation des processus, des compétences,
des rôles et des responsabilités exigés pour créer et faire
fonctionner une pratique d’architecture au sein d’une
entreprise. 9
Plan:
 Introduction et Concepts de base
 Méthode de développement d’architecture: ADM
Framework de contenu
Continuum d’entreprise
Modèles de références TOGAF
Framework de Capacité d’architecture
 Focus sur ADM
Plan:
 Introduction et Concepts de base
Introduction et Concepts de base

Quels sont les types d’architecture que traite TOGAF?


II y a quatre domaines d'architecture qui sont généralement acceptés comme des sous-ensembles
d'une architecture globale de l'entreprise:

TOGAF est conçu pour soutenir ces 4 domaines d’architecture.

12
Introduction et Concepts de base
Méthode de développement d’architecture

13
Introduction et Concepts de base

Livrables, Artifacts et Building blocks

14
Introduction et Concepts de base

Continuum d’entreprise
- Structure le patrimoine architectural
- explique comment les solutions génériques peuvent être mis à profit et spécialisés afin de
soutenir les besoins d'une organisation spécifique

15
Introduction et Concepts de base
Référentiel d’architecture
- Soutenir le continuum d’entreprise
- Stocker les actifs architecturaux (créés par l’ADM)à différents niveaux d’abstraction

16
Introduction et Concepts de base
Capacité d’architecture
- Base operationnelle solide pour soutenir la pratique de l’AE
- Le framework de capacité recense les actifs à mettre en place et à maîtriser pour être en
mesure d’améliorer sa capacité à faire de l’AE pour transformer et gouverner l’entreprise

17
Introduction et Concepts de base
Utilisation de TOGAF avec d’autres frameworks
- Tout framework d’AE se base sur les deux points suivants:
* Une définition des livrables que l'activité architecturale devrait produire
* Une description de la méthode par laquelle cela doit être fait

- ADM a une grande marge d’adaptabilité et de customisation


- TOGAF est un framework générique

TOGAF a une grande capacité de collaboration avec d’autre framework (ITIL,


CMMI, COBIT, PRINCE2, PMBOK…).
 TOGAF peut être utiliser pour des domaines métiers spécifique (Sécurité, Télécom,
E-commerce…)
 TOGAF peut s’adapter aux différents style d’architecture (SOA…)

18
Introduction et Concepts de base

TOGAF 9 vs TOGAF 8.1


- Structure modulaire

- Le framework de contenu

- Orientation étendue sur l'adoption de TOGAF au sein d'une entreprise


* Le partitionnement
* Le Référentiel d’architecture
* Le Framework de capacité

- Plus d'utilisabilité, Plus de cohérence dans les sorties de l’ADM.

19
Plan:

 Méthode de développement d’architecture: ADM


Introduction à l’ADM

Méthodologie de développement d’architecture = la pièce maitresse de TOGAF


Principal atout de TOGAF
C’est une démarche pour développer et utiliser l’AE
L’ADM décrit la façon d’élaborer l’AE en répondant aux exigences métiers

La capacité d’architecture met en oeuvre l’ADM

Contenu

-classification conformément au continuum d’entreprise


- Stockage dans le référentiel initialement peuplé par les
Modèles de Référence TOGAF

21
Introduction à l’ADM

ADM assisste les architectes tout au long de la définition de l’architecture


Elle définit un cycle de 10 phases organisées en plusieurs domaines d’architecture:

ADM fournit un descriptif de chaque phase présentant:

Objectifs Approche Entrées Etapes Sorties

22
Phase Préliminiare

La phase préliminaire prépare une organisation donnée à la réalisation de projets d'Architecture


d'entreprise. Elle prépare et décrit les activités pour répondre aux directives métier pour une nouvelle
architecture d'entreprise

23
Phase A: Vision d’Architecture
Cette phase contient des informations à propos de la définition du périmètre, l'identification des
parties prenantes, la création de la vision d’Architecture ainsi l'obtention des approbations.

24
Phase B: Architecture Business

Cette phase décrit le développement d'une architecture métier pour soutenir une vision
d'architecture d'accord.

25
Phase C (1/2): Architecture de données
Cette phase doccmente l'organisation fondatmentale des systèmes informatiques d'une entreprise
(les principaux types d'information et les systèmes d'applications qui les traitent)

26
Phase C (2/2): Architecture d’Applications
Cette phase doccmente l'organisation fondatmentale des systèmes informatiques d'une entreprise
(les principaux types d'information et les systèmes d'applications qui les traitent)

27
Phase D : Architecture technique
Cette phase doumente l'organisation fondatmentale des systèmes informatiques d'une entreprise à
savoir le hardware, le software et les techniques de communication

28
Phase E: Opportunités et Solutions
C'est la première phase qui concerne directement la mise en oeuvre

29
Phase F: Planification de la Migration
Cette phase concerne la planification de la migration c'est à dire la façon de passer de
l'Architecture initiale à l'architecture cible en finalisant un plan de mise en oeuvre et de migration

30
Phase G: Gouvernance de la mise en oeuvre
Cette phase définit la façon dont l'architecture contraint les projets de mise en oeuvre, en assurant
le suivi pendant sa construction et produit un contrat d'architecture signé

31
Phase H: Management du changement d’Architecture
Cette phase a pour but de gérer de façon maîtrisée les modifications apportées à l'architecture

32
Gestion des exigences

Le processus de gestion des exigences de l'architecture s'applique à toutes les phases du cycle
ADM. C'est un processus dynamique qui a pour but d'identifier les exigences de l'entreprise, de les
mémoriser puis les livrer en entrée des phases correspendant

33
Plan:

Framework de contenu
Introduction au framework de contenu

L’application de l’ADM va générer plusieurs produits en sorties (Flux de processus, exigences


d’architecture, Plans de projets, Evaluation et conformité de projets…)

Besoin d’un framework de contenu d’architecture afin de présenter d’une façon


structurée et cohérente ces différents produits

Un framework de contenu d’architecture permet:


- La classification et la référence
- La structuration des relations entre les constituants afin de développer une AE

35
Introduction au framework de contenu

Le framework de contenu fourni dans TOGAF 9.1 assure l’autonomie de TOGAF lors de son
utilisation

TOGAF peut être utilisé avec d’autre framework de contenu comme Zachman.

Les entreprise peuvent opter pour l’utilisation d’un autre framework avec l’ADM. Dans ce cas, le
framework de contenu fourni par TOGAF peut être considéré comme référence utilse et point de
départ pour le contenu de TOGAF qui sera mappé avec les méta-modèles des autres frameworks.

36
Introduction au framework de contenu

Objectif:
- Aider à la classification des produits des nouveaux travaux
- Se mettre en corrélation avec d’autres framework de contenu ainsi que les produits déjà
existants et classés

Le framework de contenu de TOGAF définit trois catégories pour décrire le type de produit

Livrable Artefact Building Block

Produit du travail formel et Un produit du travail Elément (réutilisable) du


contractuel. Il est revu, d’architecture plus précis qui Business, de IT ou de la
approuvé et signé par les décrit une architecture d’un capacité de l’architecture, qui
parties prenantes concernées. point de vue spécifique. Les peut être combiné avec d’autres
Les livrable représentes souvent artefacts sont généralement pour offrir des architectures et
les résultats des projets considérés comme des des solutions
catalogues, des matrices ou des
schémas

37
Introduction au framework de contenu

Relations entre Livrables, Artifacts et Building blocs

38
Métamodèle du contenu

Le framework de contenu TOGAF est basé sur un métamodèle de contenu standard qui fournit
une définition pour tous les types de building blocks existant au sein d’une architecture

Le métamodèle illustre comment ces building blocks peuvent être décrits et comment ils se
rapportent les uns aux autres

Le métamodèle met en évidence toutes les préoccupations lors de la création et la gestion des
architectures (Les services métiers, les acteurs, les applications, les entités de données, la
technologie)

Le métamodèle montre les relations qui existent entre ces préoccupations (ex: un acteur qui
consomme un service métier)

Le métamodèle identifie les artefacts qui peuvent être utilisés pour les représenter (Pour but de
faciliter la présentation de l’information de l’architecture ou pour des fins de gouvernance et de
référence.

39
Métamodèle du contenu

Framework de contenu & l’ADM


Le framework de contenu doit être utilisé comme un compagnon pour l’ADM.
L’ADM décrit ce qui doit être fait pour créer une architecture
Le framework de contenu décrit à ce que devrait ressembler l'architecture une fois faite.

40
Métamodèle du contenu de base

TOGAF est conçu pour founrir un standard ouvert et applicable dans de différents scénarios et
situations.

Le framework de contenu repose sur un métamodèle de base, avec un ensemble de


caractéristiques basiques.
Le métamodèle du contenu supporte l’inclusion des extensions optionnelles afin d’adapter la
démarche au contexte de l’application

Ces extensions de métamodèle sont optionnelles. Leurs sélections et adaptations se


font lors de la phase préliminiare de l’ADM et dépendent des besoins de l’entreprise

41
Métamodèle du contenu de base

Le métamodèle de base utilise et met en relation plusieurs concepets afin de supporter la


traçabilité à travers les Artifacts

42
Concepts de catalogue, Matrice et Diagramme
Le métamodèle de contenu est utilisé comme une technique permettant de structurer l'information
architecturale d'une manière ordonnée afin qu'il puisse être traitée afin de répondre aux besoins des
parties prenantes. Exemple: Quels fonctionnalités d’une application donnée? Quels sont les processus qui
seront impactés par un projet donné

Building Block: Entité d’un type particulier dans le métamodèle (par exemple: un business
process nommé « Bon de commande »). Les building blocks peuvent être sujet de requête et
d’analyse pour répondre aux interrogations des stakeholders.
Catalogue: C’est souvent une liste de building blocks du même type et des types connexes.
Les Catalogues sont utilisés pour des finalités de gouvernance et de référence.
Matrice: C’est une grille qui indique les relations entre deux ou plusieurs entités du modèle.
Les matrices sont utilisées pour représenter les relations qui sont basées sur une liste plutôt que
dans leur usage graphique (Exemple: Matrice RACI).
Diagramme: C’est un rendu graphique synthétisant du contenu architectural qui permet aux
partie prenantes récupérer les informations requises. TOGAF définit un ensemble de
diagrammes à créer. Chacun de ces diagrammes peut être créé à plusieurs reprises pour une
architecture avec un style différent pour s'adapter aux préoccupations des intervenants.

Ces concepts sont bien pris en charge par les principaux outils d'architecture d'entreprise.
Ces outils prennent généralement en charge les mécanismes de rechercher, filtrer et
interroger le référentiel d'architecture.
43
Concepts de catalogue, Matrice et Diagramme

44
Les extensions du métamodèle de contenu
Le métamodèle du contenu TOGAF supporte un certain nombre de modules d’extension afin de
traiter d’une façon approfondie les préoccupations particulières d’Architecture

45
Les extensions du métamodèle de contenu

46
Les artifacts architecturaux
Les artifacts sont créés dans le but de décrire un système, une solution, ou l'état de l'entreprise
L’artifact fait appel à d’autres concepts (Système, Architecture, Partie Prenante, Préoccupation,
Vue, Point de vue) qui ont été adaptées à partir des définitions plus formelles contenues dans la
norme ISO / IEC 42010:2007

47
Les artifacts architecturaux
Une vue est ce qu’on voit. Un point de vue est l'endroit où on est; c’est une perspective qui
détermine ce que l’on voit.
Les points de vue sont génériques, et peuvent être stockés dans des bibliothèques pour la
réutilisation.
Chaque vue a un point de vue associé qui la décrit. ISO / IEC 42010:2007 encourage les
architectes à définir des points de vue de manière explicite. Cette distinction entre le contenu et le
schéma d'une vue peut sembler à première vue être une surcharge inutile, mais il fournit un
mécanisme pour la réutilisation des points de vue à travers les différentes architectures.

Les vues d'architecture sont des représentations de l'architecture globale en termes significatifs
pour les parties prenantes. Elles rendent l'architecture bonne à être communiquée et comprise par
les parties prenantes, afin qu'ils puissent vérifier que le système répond à leurs préoccupations.

48
Les livrables architecturaux

Le framework de contenu TOGAF identifie les livrables produits en tant que sorties de l'exécution
du cycle ADM.

Ces livrables peuvent être utilisés comme des entrées dans d’autres phases ADM

D’autres livrables peuvent être produites ailleurs et exploités par l’ADM.

Les livrables sont généralement les produits de travail contractuelles ou formelle d'un projet
d'architecture.

il est probable que ces livrables seront limitées ou modifiées par un projet global ou par l’approche
adoptée pour la gestion des processus de l'entreprise (tels que CMMI, PRINCE2, PMBOK).

49
Les Building Blocks

Un building Block est un package de fonctionnalité défini pour répondre aux besoin métier à travers
l’entreprise

Un building block a un type correspendant dans le métamodèle du contenu de TOGAF (Business


process, Application, Acteur,Risk…)

Un building block peut opérer avec d’autres building blocks

Un bon building block:


- Doit prendre en compte la mise en œuvre et l'utilisation, et évoluer afin d’exploiter la technologie et
les normes.
- Peut être assemblé à partir d’autres building blocks
- Il peut s'agir d'un sous-ensemble de building blocks
- Idéalement, un building block est réutilisable, remplaçable, et bien spécifiée.

50
Les Building Blocks

Un building Block est un package de fonctionnalité défini pour répondre aux besoin métier à travers
l’entreprise

Building blocks d’Architecture Building blocks de solution


Les ABBs se rapportent au continuum Les SBBs se rapportent au continuum de
d'architecture et sont définis et choisis en raison solutions. Ils peuvent être achetés ou développés.
de l'application de l’ADM.
Les AABs capture les exigences d'architecture Les SBBs Définissent les produits et composants
(des entreprises, des données, des applications qui vont mettre en œuvre la fonctionnalité
et des exigences technologiques Ils définissent la mise en œuvre
Ils dirigeent et orientent le développement de Ils répondent aux exigences métier
SBB

51
Les Building Blocks et l’ADM

Une architecture est un ensemble de building blocks décrits dans un modèle architectural, et une
spécification qui précisent comment ces éléments sont connectés afin de répondre aux exigences
générales de l'entreprise.

Une architecture ne doit contenir que des building blocks qui sont pertinents pour le problème
métier auquel l'architecture essaie de répondre.

Les building blocks peuvent avoir des relations complexes les uns aux autres. Un building block
peut prendre en charge plusieurs building blocks ou partiellement en charge un building block unique
(par exemple, le business process de "traitement des plaintes» serait pris en charge par de
nombreuses entités de données et composants d'application)

Les building blocks doivent être conformes aux normes applicables à leur type, les principes de
l'entreprise et les normes de l'entreprise.

52
Les Building Blocks et l’ADM
Le processus de définition de building block a lieu progressivement dans l’ADM (surtout dans les
phases A, B, C et D). C’est un processus itératif et évolutif
La finalité principale de ces étapes consiste à identifier les ABBs nécessaires pour répondre aux
objectifs de l'entreprise. L'ensemble sélectionné de ABBS est ensuite raffinée dans un processus
itératif pour arriver à un ensemble de SBB qui peuvent être achetés ou développés sur mesure.

53
Les Building Blocks et l’ADM

Une architecture est un ensemble de building blocks décrits dans un modèle architectural, et une
spécification qui précisent comment ces éléments sont connectés afin de répondre aux exigences
générales de l'entreprise.

Une architecture ne doit contenir que des building blocks qui sont pertinents pour le problème
métier auquel l'architecture 'essaie de répondre.

Les building blocks peuvent avoir des relations complexes les uns aux autres. Un building block
peut prendre en charge plusieurs building blocks ou partiellement en charge un building block unique
(par exemple, le business process de "traitement des plaintes» serait pris en charge par de
nombreuses entités de données et composants d'application)

Les building blocks doivent être conformes aux normes applicables à leur type, les principes de
l'entreprise et les normes de l'entreprise.

54
Plan:

Continuum d’entreprise
Le Continuum d’entreprise

Plusieurs parties prenantes Plusieurs préoccupations à prendre en compte

Impossible d’avoir une seul architecture unifiée qui répond à toutes les exigences des parties
prenantes.

L'architecte d'entreprise devra faire face non seulement à une architecture d'entreprise unique,
mais à de nombreuses architectures d'entreprise connexes.
Chaque architecture aura à traiter une problématique précise.
 La délimitation du périmètre de l'architecture est un facteur de réussite essentiel pour permettre
aux architectes de décomposer un problème complexe en éléments gérables qui peuvent être
adressés individuellement.
Le continuum d’entreprise offre une vue sur le référentiel d'architecture qui montre l'évolution de
ces architectures connexes du générique au spécifique, de l'abstrait au concret, et de logique au
physique.
Le continuum d'entreprise comprend le continuum de l'architecture et le continuum de solutions. Il
décrit comment les architectures peuvent être partitionnées et organisées dans un référentiel. Il
décrit également les outils de développement de l'architecture.
56
Le Continuum d’entreprise

Le continuum d’entreprise = Un modèle pour structurer un référentiel virtuel

Il fournit des méthodes pour classer des éléments d’architecture décrivant des principes et des
solutions

Il illustre la façon dont évoluent les différents types d’éléments d’architecture et la façon dont on
peut les exploiter et les réutiliser

Il se fonde sur des architecture et des solutions (tels que des modèles, des patterns, des
descriptions d’architectures…) présentes au sein de l’entreprise et accumulées tout au long de
développement de ses architectures

57
Le Continuum d’entreprise

58
Continuum d’Architecture & Continuum de solution

59
Le Continuum d’entreprise & l’ADM

L’ADM décrit le processus d'élaboration d'une architecture spécifique à l'entreprise et une solution
spécifique à l'entreprise (s) qui sont conformes en adoptant et en adaptant (le cas échéant) les
architectures et solutions génériques (de gauche à droite dans la classification continuum).

De la même façon, les architectures et des solutions spécifiques qui s'avèrent être crédibles et
efficaces seront généralisées pour la réutilisation (de droite à gauche dans la classification
continuum).

Lors du cycle de l’ADM, on peut faire appelle à des actifs architecturaux utiles à un niveau
approprié de généralité dans la classification du continuum (les modèles de références qu’offre
TOGAF entre autres)

60
Le Partitionnement d’une architecture

Les partitions sont utilisées pour simplifier le développment et la gestion d’une AE

Les Architectures sont partitionnées en raison de:


 Les unités organisationnelles d’architectures peuvent être en conflit
 Les différentes équipes ont besoin de travailler sur les différents éléments de l'architecture
simultanément et les partitions permettent à des groupes spécifiques d'architectes de posséder
et d'élaborer des éléments spécifiques de l'architecture.
 La réutilisation efficace d’architecture nécessite des segments d’architecture modulaires qui
peuvent être pris et intégrés dans d’architectures et de solutions.

IL n’y a pas de modèle de partitionnement définitif pour l'architecture. Chaque entreprise a besoin
d'adopter un modèle de partitionnement qui reflète son mode de fonctionnement

TOGAF définit des critères de partitionnement et de classification des architectures

61
Critères de classification et de création de partitions

62
Référentiel d’Architecture

63
Plan:

Modèles de références TOGAF


Modèle de référence Technique

L’Architecture de fondation est une architecture de services et fonction génériques qui fournissent
un socle pour batir des architectures et des composants architecturaux spécifiques. Cette
architecture de Fondation est incarnée dans le modèle de référence technique (TRM), qui fournit le
modèle et la taxonomie des services de la plate-forme générique.

Un TRM a deux composants principaux:


 Une taxonomie, qui définit la terminologie, et fournit une description cohérente des
composants et de la structure conceptuelle d'un système d'information
Un TRM graphique associé, qui fournit une représentation visuelle de la taxonomie
Modèle de référence Technique
Plan:

Framework de Capacité d’architecture


Framework de capacité d’Architecture

La capacité d’Architecture peut être définit comme le savoir-faire, l’approche, les actifs
architecturaux servant à réaliser ou gérer une architecture, une solution d’architecture ou un aspect
particulier de l’architecture.

Tout comme les capacités Business, ADM permet d’établir la capacité d’une architecture
d’entreprise.

Le framework de capacité d’Architecture peut être vu comme un ensemble de ressources,


recommandations, modèles, compétences…

Le framework de capacité d’Architecture d’entreprise aide les architectes à établir une pratique
d’architecture au sein d’une organisation

Ce framework recense les actifs à mettre en place et à maîtriser pour être en mesure d’améliorer sa
capacité à faire de l’AE pour transformer l’enreprise (Transformer les capacités Business)

Ce framework n'est pas destiné à être un modèle complet pour le fonctionnement d'une capacité
d'architecture d'entreprise.
Framework de capacité d’Architecture
Etablissement de la capacité d’Architecture

L’ADM est la méthodologie idéale pour mettre en œuvre une capacité d’Architecture

L’application de l’ADM avec une vision d’Architectrue spécifique permet d’établir une pratique
d’Architecture afin d’atteindre la capacité d’Architecture espérée.

L’implémentation d’une capacité d’Architecture doit être un projet d’Architecture à part entière. Elle
doit être une pratique courant qui fournit le contexte, l'environnement et les ressources de gouverner
et livrer une architecture à l'organisation.

Tout comme les capacités Business, l’implémentation d’une capacité d’architecture requière la
conception de quatre domaines d’Architecture:
 L’Architecture Business
L’Architecture de Données
L’Architecture Applicative
L’Architecture technologique
Etablissement de la capacité d’Architecture

L’Architecture Business: met le point sur la gouvernance d’Architecture, les processus


d’architecture, la structure organisationnelle d’Architecture, les exigences d’information d’Architecture,
les produits d’Architecture…

L’Architecture de données: Définit la structure du continuum d’entreprise et le référentiel


d’Architecture de l’organisation.

L’Architecture applicative: spécifie la fonctionnalité et /ou les services d’applications requis pour la
pratique d’Architecture

L’Architecture technologique : Spécifie les exigences de l’infrastructure de la pratique d’Architecture


pour le support des applications de l’Architecture et du continuum d’Entreprise
Le comité d’Architecture

Le comité d’Architecture est un élément clé pour la réussite d’une stratégie de gouvernance
d’architecture. Il a comme rôle de superviser l’implémentation de cette stratégie

Le comité d’Architecture doit représenter toutes les parties prenantes clés. Il doit comprendre
surtout un groupe de cadres responsables de la revue et l’entretien de l’architecture globale

Le comité d’Architecture a un périmètre bien défini (domaine d’expertise, Ligne de responsabilité,


ligne Business, zone d’activité…)

Le framework de capacité d’architecture fournit un ensemble de directives pour l’établissement et


l’exploitation d’un comité d’architecture d’entreprise
Le comité d’Architecture

Le comité d’Architecture est responsable et rend des comptes de:


 Décisions prises en ce qui concerne les architecture (dans des éventuelles situations de conflit
entre autres)
 La cohérence entre les sous-architectures
 L’identification des composantes réutilisables
 La flexibilité de l’AE (Répondre aux besoins métier et utiliser des nouvelles technologies…)
 Application de la conformité d’architecture
 Améliorer le niveau de maturité du domaine de l’architecture au sein de l’organisation
 Fournir la base de toute prise de décision en ce qui concerne les changements apportés aux
architectures
Le comité d’Architecture a des responsabilités opérationnelles: Suivi et réunions régulières, le
contrôle des contrats d’Architecture, la résolution de conflits…

Le comité d’Architecture a des responsabilités de gouvernances: L’identification des divergences


des architectures et planification des activités de réalignement.
Le comité d’Architecture

La mise en place d’un comité d’Architecture se déclenche par un ou plusieurs événements:


 Nouveau DSI
Fusion ou acquisition
Reconnaissance que l’IT n’est pas alignée avec le métier
Désir d’obtenir un avantage concurrentiel grâce à la technologie
Création d’un programme d’architecture d’entreprise
Changement significatif ou croissance rapide du Métier
Obligation de solutions inter-fonctionnelles et complexes

Le comité d’architecture contient 4 à 10 membres permanents

La composition du comité peut être revue (selon l’effort de l’architecture initial, l’efficacité du comité
d’architecture…), en donnant le privilège de prise de décisions et des responsabilités aux cadres
supérieurs

Pour assurer la continuité de la politique d’architecture, on ne doit pas changer tous les membres
du comité à la fois.
La conformité de l’Architecture

Assurer la conformité des projets individuels avec l'architecture d'entreprise est un aspect essentiel
de gouvernance d’architecture

La gouvernance informatique définit deux processus complémentaires:


 La fonction architecturale qui prépare une série d'Architectures de projet. Elle illustre les
impacts d'architecture d'entreprise sur les grands projets de l'organisation.
 La fonction de gouvernance IT qui définit un processus formel de revue de conformité
d’architecture. Elle examine la conformité des projets par rapport à l'architecture d'entreprise

La gouvernance de l'architecture stipule que la fonction architectural edevrait s'étendre au-delà du


rôle de la définition de l'architecture et la sélection des normes. Elle doit participer également au
processus de sélection de la technologie, et même s’impliquer dans la prestation de services
externes et les achats de produits. Cela va minimiser les risques de mauvaises interprétations de
l'architecture d'entreprise et maximiser la valeur de négociation commerciale centralisée.
La conformité de l’Architecture
Les niveaux de conformité entre l’architecture et son implémentation
La conformité de l’Architecture

Une revue de la conformité d’architecture est un examen de la conformité d'un projet spécifique par
rapport aux critères architecturaux établis, à l'esprit et les objectifs métier. Un processus formel de
ces revues constitue le noyau d'une stratégie de Conformité d’une AE.
Les contrats d’Architecture
Les contrats d'architecture sont des accords communs entre les parties impliquées dans le
développement et la livraison de l’architecture (les sponsors, le département SI, les sociétés de
services….)

La Mise en œuvre réussie de ces accords sera assurée par une gouvernance d’architecture
efficace. Cela consiste à assurer la mise en œuvre d’une approche régie de la gestion des contrats

De différents contrats d'architecture peuvent survenir à différentes étapes de l’ADM, par exemple:
 L’énoncé d’un travail d’Architecture: un livrable de la phase A. C’est un contrat d’Architecture
entre l’orgnaisation d’architecture et le sponsor de l’AE
Le contrat de conception et de développement d’Architecture: Le modèle de ce contrat peut
êrte défini dans la phase préliminaire ou même dans des phases ultérieures de l’ADM. C’est un
accord commun entre les partenaires de développement et les sponsors concernant les livrables,
la qualité et la « fitness-for-purpose » d'une architecture
Le contrat d’utilisation métier de la fonction architecturale: établi une fois l’architecture est mise
en place (à la fin de la phase F).
Le document de contrats d’architecture, produit dans la phase G, est souvent utilisé comme un
moyen de pilotage de changement d’architecture
La gouvernance d’Architecture

La gouvernance d’architecture est la pratique par laquelle les architectures sont gérées et
contrôlées au niveau de l’entreprise. Ceci inclut:
 Mettre en place un système de contrôles sur la création et le suivi de toutes les composantes
de l’architecture et ses activités, pour assurer la mise en œuvre et l’évolution effectuve des
architectures au sein de l’organisation
 Mettre en place un système visant à assurer le respet des normes internes et externes ainsi
que les obligations réglementaires
 Etablir des démarches qui favorisent une gestion efficace des processus
 Etablir et documenter les structures de décision qui influencent l’AE. Cela inclut les
intervenants qui donnent des entrées à ces décisions
 Développer des pratiques qui assurent la responsabilisation d’une communauté bien identifiée
d’intervenants (à l’interieur ou à l’exterieur de l’organisation
La structure conceptuelle du framework de gouvernance d’architecture

D’un point de vue conceptuel, la gouvernance d’architecture est une approche, une suite de
processus, une orientation culturelle et un ensemble de responsabilités, qui assurent l’intégrité et
l’efficacité des AEs
La structure organisationnelle du framework de gouvernance d’architecture

Pour assurer un contrôle efficace de l’entreprise, il est incontournable d’établir une surtucture
organisationnele correcte qui va supporter les différentes activités de gouvernance
Modèles de maturité d’Architecture
Les entreprises qui ont l’aptitude de gérer efficacement les changement ont un plus concurrentiel
par rapport aux autres entreprises

Les entreprises sont conscientes qu’un management réussi de changement passe par une
amélioration des processus MAIS elles ne savent pas COMMENT faire?

Capability Maturity Models


Fournissent des méthodes pour gagner en contrôle et amélioration des processus de changement:
 Ils décrivent les pratiques que toute organisation doit accomplir afin d'améliorer ses processus.
 Ils fournissent un étalon permettant de mesurer périodiquement l’amélioration.
 Ils constituent un cadre éprouvé dans lequel on peut gérer les efforts d'amélioration.
 Ils organisent les différentes pratiques en niveaux, chaque niveau représentant une capacité
accrue de contrôler et de gérer l'environnement de développement.

Open Group prévoie d’inclure son propre CMM dans des versions ultérieures de TOGAF
Framework de compétences d’Architecture

Le framework de capacité d’architecture fournit un ensemble de rôles, de compétences, de normes


d’expérience pour le personnel réalisant des travaux d’AE

Les deux termes « Architecture d’Entreprise » et « Architecte d’entreprise » sont vachement utilisés
mais mal définis dans l’industrie informatique. Ils désignent une variété de pratique et de
compétences qui s’appliquent à un registre large de domaines d’architecture.

Il y a un besoin d’une meilleure classification pour permettre une comprehension plus implicite du
type d’Architect/Architecture que l’on est entrain de décrire

Le framewrok de compétence essaie de répondre à ce besoin en fournissant les définitions des


compétences de l’architecture et des niveaux de compétences requis du personnel, interne ou
externe, qui sont appelés à exercer les différents rôles définis au sein du framework d’architecture
TOGAF
Framework de compétences d’Architecture

Il y a de différentes catégories de compétences:


 Les compétences génériques: Le leadership, le travail d’équipe, les compétences
interpersonnelles….
Les compétences en métier et méthodes: Planification stratégique, Business process,
Business Cases…
Les compétences en AE: Modeling, Conception des Building Blocks, Integration système…
Les compétences en management de projets et de programmes: Management des
changements métier, Méthodes et outils de management de projet…
Les compétences d’ordre général en IT: Gestion des actifs IT, Planification de migration,
SLA…
Les compétences dans le domaine juridique: Les lois de protection de données, la loi des
contrats, lois des marchés publiques, loi de fraude…
Framework de compétences d’Architecture

TOGAF définit quatre niveaux de compétences:


Niveau de compétence Description
Base Pas de compétence requis, mais devrait être en mesure de
définir et de gérer les compétences si nécessaire
Sensibilisation Comprendre suffisamment le contexte, les enjeux et les
implications pour être en mesure de comprendre comment
aller plus loin et de conseiller le client en conséquence
Connaissance Connaissance approfondie de domaine et capable de fournir
des conseils professionnels et d'orientation. La capacité
d'intégrer les capacités dans la conception de l'architecture
Expertise Une expérience pratique vaste et solide et des connaissances
appliquées sur le sujet

Pour chaque type de compétence, TOGAF définit une matrice Rôles/Niveaux de compétences,
illustrant le niveau de compétences que devrait avoir un role pour un type de compétence donné
Plan:

 Focus sur ADM


Techniques pour l’ADM

 Les principes d’Architecture:

Les principes de l’entreprise sont des règles générales et des lignes directrices, destinés à être
durables et rarement modifiés. Ils décrivent et soutiennent la façon avec laquelle une organisation
remplit sa mission et forment une base pour la prise de décision

Les principes d'architecture sont des principes qui se rapportent aux travaux d'architecture. Ils
reflètent un niveau de consensus au sein de l'entreprise ainsi que les autres parties prenantes. Ils
incarnent l'esprit et la pensée des principes d'entreprise existantes.

Les principes de l'architecture régissent le processus d'architecture, affectent le développement, la


maintenance et l'utilisation de l'architecture d'entreprise. Ils forme une base pour la prise de décisions IT
Techniques pour l’ADM
 Les principes d’Architecture:
La définition d’un principe d’architecture comprend:
Le nom: doit être clair sans termes ambigus ou vagues. Il ne doit pas mentionner des plate-
formes technologiques spécifiques
L’énoncé: communique et sans ambiguïté la règle fondamentale.
Le raisonnement: met en évidence les avantages commerciaux à tirer en respectant le principe.
Il décrit la priorité (poids) du principe et sa relation avec d'autres principes
L’implication: met en évidence les besoins (Business ou IT, en termes de ressources, coûts,
engagement, activités / tâches…) pour la réalisation du principe. L'impact sur l'activité et les
conséquences de l'adoption d'un principe doivent être clairement indiqué.

Les principes d’Architecture sont approuvés par le comité d’architecture


Un principe doit être comprehensible, robuste, complet, cohérent et stable
Exemple de principes:
Augmenter les bénéfices de l’entreprises
Protéger la propriété intelectuelle
La résponsabilité
L’interopérabilié
Techniques pour l’ADM
 Le management des parties prenantes:
Le management des partie prenantes est une discipline très imporantes pour les architectes
 Les acteurs les plus puissants peuvent être identifiés plus tôt et leur contribution peut être
utilisé pour façonner l'architecture. Du coup on peut assurer leur soutien et améliorer la qualité des
modèles produits.
Le soutien des intervenants pesants aidera l'engagement à gagner plus de ressources
En communiquant avec les parties prenantes tôt et fréquemment, l'équipe d'architecture peut
s'assurer qu'ils comprennent bien le processus de l'architecture et les avantages de l‘AE, ce qui
signifie qu'ils peuvent supporter l'équipe d'architecture plus activement lorsque cela est
nécessaire.
 L'équipe d'architecture peut plus efficacement anticiper les réactions probables pour les
modèles d'architecture et de rapports
 L'équipe d'architecture permet d'identifier des objectifs conflictuels ou concurrentiels entre les
parties prenantes enfance et d'élaborer une stratégie pour résoudre les problèmes qui en
découlent.

Dans toute initiative visant à identifier les individus et les groupes au sein de l'organisation qui
contribuent au développement de l'architecture, il est essentiel d’identifier ceux qui gagneront et ceux
qui perdront de l’introduction de l’initiative. Par la suite il faut élaborer une stratégie pour y faire face.
Techniques pour l’ADM

 Les scénarios Métier:

La téchnique des scénarios métier permet d’extraire, à partir des besoins de l’entreprise, les
exigences métier et architecturales à traiter lors du développement d’une AE

Les scénarios métier sont utilisés principalement dans les deux phases « vision d’architecture » et «
Architecture Business»

Un scénario métier décrit les éléments de base d’une solution qui va répondre aux éxigences

Un scénario métier sert de référence «High Level » pour les vendeurs de solutions software afin de
s’assurer que leur produit répond au besoin de l’entreprise.

Un scénario métier est SMART


Techniques pour l’ADM
 Les scénarios Métier:
Techniques pour l’ADM

 L’Analyse de l’écart:

Cette technique est largement utilisé dans l’ADM pour valider une architecture qui est en cours
d'élaboration.

Le principe de base est de mettre en évidence un déficit entre l'architecture de base et l'architecture
cible en repérant les points qui ont été omis ou pas encore définis

Les écarts les plus critiques, et qui doivent être pris en compte, sont des préoccupations des parties
prenantes qui n’ont pas été abordées dans le travail d’architecture

Les écarts concernent les domaines métier, données, applicatif ou technologique .


Techniques pour l’ADM

 L’Analyse de l’écart:
Techniques pour l’ADM

 Techniques de planification de la migration: Matrice d’évaluation et de déduction des


facteurs d’implémentation
Cette technique permet de documenter les facteurs qui vont impacter l’implémentation de
l’architecture et le plan de migration

Ces facteurs comprennent des risques, des problèmes, des hypothèses, des dépendances, des
actions, des impacts…

La matrice doit lister les facteurs à prendre en compte, leurs descriptions, et les déductions qui en
découlent en terme d’actions et contraintes à prendre en considération dans le plan de migration
Techniques pour l’ADM

 Techniques de planification de la migration: Matrice de consolidation des écarts,


solutions et dépendances
Cette matrice permet de consolider les écarts identifiés dans les différents domaines d’architecture et
évaluer les solutions et les dépendances concernant ces écarts

Cette technique peut être utilisée comme un outil de planification lors de la création des work
packages
Techniques pour l’ADM

 Techniques de planification de la migration: Tableau de définition des incréments


d’Architecture
Cette technique permet à l'architecte de planifier une série d'architectures de transition décrivant l'état
de l‘AE à des moments précis.

Ce tableau doit établir la liste des projets et l’attribution de leurs réalisations progressives à travers
les architectures de transition
Techniques pour l’ADM

 Techniques de planification de la migration: L’évaluation de la valeur métier

Cette technique consiste à dresser une matrice basée sur une dimension « indice de la valeur métier »
et une dimension « indice de risque »

L'indice de valeur devraient inclure des critères tels que le respect des principes, la contribution
financière, l’alignement stratégique, et sa position concurrentielle

L'indice de risque devraient inclure des critères tels que la taille et la complexité, la technologie, la
capacité organisationnelle et l'impact d'un échec

L'indice, ses critères, la pondération devraient être élaborés et approuvés par la haute direction.
Techniques pour l’ADM

 Les exigences de l’interopérabilité:

L’interopérabilité est la capacité de partage d’informations et de services au sein d’un organisme

La définition du niveau de partage d’information et de service est une exigence architecturale


considérable, surtout pour des entreprises de grandes tailles

Afin de définir une interopérabilité cohérente au sein de l’entreprise, il est préférable de la classer
comme suit:
 L’interopérabilité métier et fonctionnelle
L’interopérabilité des informations
L’interopérabilité technique

l’Architecte doit toujours s’assurer qu’il n’y a pas des conflits d’interopérabilité surtout lorsqu’on veut
réutiliser des SBBs.
Techniques pour l’ADM

 L’évaluation de la préparation aux transformations métier:

Cette technique permet d'évaluer et de quantifier la préparation de l'organisation à subir des


changements.

L’élément humain est l’une des princiaples dimensions qui subira le changement

Les activités de cette évaluation sont:


 Déterimner les facteurs de préparation qui vont impacter l’organisation
 Présenter les facteurs de préparation en utilsant les modèles de maturité
 Evaluer les facteurs de préparation
 Evaluer les risques de chaque facteur et identifier les actions d’atténuation de ces risques
La mise en place de ces actions dans les phases E et F de l’ADM
Techniques pour l’ADM
 Le management des risques:
Chaque activité de transformation (métier/architecturale) va engendrer des risques

Le suivi de ces risques durant l’activité de transformation passe par leurs identification, classification
et atténuation au tout début

Il y a deux niveaux de risque:


 Le niveau initial: Catégorisation des risques avant de déterminer et mettre en œuvre des
mesures d'atténuation.
 Le niveau residuel: Catégorisation des risques après la mise en œuvre des mesures
d'atténuation (le cas échéant).

Le processus de management des risques comprend les activités suivantes:


 La classification des risques
L’identification des risques
L’évaluation initiale des risques
L’atténuation des risques et l’évaluation des risques résiduels
Le suivi des risques
Techniques pour l’ADM
 La planification axée sur les capacités:

C’est une technique détaillée pour définir et planifier la transformation de l’entreprise. Elle est
surtout utilsée dans les phases E et F de l’ADM

C’est une technique très pratique pour l’alignement IT/Business et la création continue de la valeur

Elle met l’accent sur les résultats operationnels. Elle combine les ressources nécessaires de toutes
les lignes métier pour atteindre la capacité souhaitée

La planification axée sur les capacités cerne toutes les phases ADM dans le contexte des résultats
opérationnels attendus en reliant clairement la vision IT, ABBs, SBBs et les plans de mise en œuvre
aux plans stratégiques et métiers de l’entreprise.

Afin de montrer la valeur métier d’une capacité aux parties prenantes et garder leur adhésion, il est
préférable de décomposer le capacité à des incréments de capacité
Techniques pour l’ADM
 La planification axée sur les capacités:
Les itérations de l’ADM

L’ADM prend en charge un certain nombre de concepts qui sont caractérisées comme itération:

 Une itéraion est un processus qui décrit le paysage d’architecture, à travers de multiples
cycles d’ADM basés sur des initiatives individuelles liées au périmètre d’une demande de travail
d’architecture

 Une itération décrit le processus intégré de développement d'une architecture où les activités
décrites dans les différentes phases ADM interagissent pour produire une architecture intégrée

 Une itération décrit le processus de gestion du changement d’une capacité d'architecture de


l'organisation.

L’ADM doit être toujours utilisé dans un processus itératif


Les itérations de l’ADM

Les cycles d’itération peuvent être utilisés pour un regroupement efficaces des activités
architecturales pour atteindre un objectif spécifique
Les itérations de l’ADM
Exemple d’une itération entre plusieurs cycles de l’ADM
Les itérations de l’ADM
L’ADM propose deux approches à adopter pour le développement d’une architecture :
 BaseLine First: Dans ce modèle, une évaluation du paysage de référence est utilisé pour
identifier les problèmes et les possibilités d'amélioration. Ce processus est le plus approprié
lorsque la baseline est complexe et mal comprise
 Target First: Dans ce style, la solution cible est élaborée en détail et ensuite mappée vers la
baseline, afin d'identifier les activités de changement. Cette approche est adaptée l'entreprise
souhaite une transition efficace vers le modèle cible
Quand on pense à utiliser des cycles d’itération, il faut penser aussi aux points de contrôles
approprié dans le processus:
 Si le niveau attendu de participation des parties prenantes est élevé, il peut être judicieux de
procéder à des points de contrôle très fréquents mais informels afin de s'assurer que le
processus se déplace dans la direction voulue
Si les intervenants sont moins étroitement associés, les points de contrôle peuvent être
moins fréquentes mais plus formelles.
Généralement, les points de contrôle se font à la fin de chaque cycle d'itération ou à la fin de
plusieurs cycles d'itération
Les itérations de l’ADM
Les activités par itération dans une définition d’architecture en mode Baseline First
Les itérations de l’ADM
Les activités par itération dans une définition d’architecture en mode Target First
Les niveaux d’architecture
Dans une entreprise, plusieurs architectures seront décrites dans le paysage d’architecture
Pour gérer la complexité du développement de ces architectures, TOGAF utilise la notion de niveau
et le concept de continuum d’entreprise pour fournir un cadre d’organisation du paysage architectural
TOGAF définit trois niveaux de granularité pour diviser le paysage d’architecture
 L’architecture stratégique: fournit un cadre organisationnel des activités de changements et
des opérations et permet un suivi de haut niveau
 L’architecture de segment: fournit un cadre de développement des feuilles de route
d'architecture efficaces au niveau du programme ou du portefeuille.
L’architecture de capacité: founrit un cadre de développement des feuilles de route
d’architecture efficaces en réalisant des incréments de capacité.