Cours: Méthodologie de Conception

Orientée Objet
 À propos du cours
 Le but du cours Méthodologie de Conception Orientée Objet est de se
familiariser avec l’approche orientée objet en ce qui concerne la conception.
 Au terme de ce module, l'apprenant sera en mesure de:
1. comprendre les concepts orientés objet,
2. utiliser le langage de modélisation orienté objet UML (Unified
Modeling Language),
3. analyser et concevoir un système d’informations.
 Le cours couvre les différents diagrammes d’UML, ainsi qu’une démarche
simplifiée du processus unifié allant de la spécification des besoins à la
conception concrète d’un système d’informations.

2
Chapitre 1:
Méthodes orientées objet
 Introduction
- Les méthodes d'analyse orientées objet sont initialement issues des milieux
industriels pour répondre aux facteurs de qualité dans le développement de logiciels.
- L' apparition de la méthode UML en fin des années 90  a permis d'améliorer la
qualité des logiciels développés en unifiant les méthodes existantes et en offrant un
langage commun de  modélisation orientée objet.

 Donner un bref aperçu sur l'historique d'UML. 

 Présenter les diagrammes UML.
 Donner un aperçu sur les nouveautés apportées par la version 2.0 d’UML.

4
 Unification des méthodes

- Au début des années 90, un certain nombre de méthodes objet commençaient à

couvrir la partie analyse et conception du cycle de développement du logiciel.
- Parmi les nombreuses méthodes, trois se sont détachées nettement: OMT (Object
Modeling Technique), OOD (Object Oriented Design) et OOSE (Object Oiented
Software Engineering).
- Les auteurs des trois méthodes se sont fixés les objectifs suivants:
 représenter des systèmes entiers par des concepts objet;
 établir un couplage explicite entre les concepts et les interfaces exécutables;
 créer un langage de modélisation utilisable à la fois par les humains et les
machines et adaptés aux systèmes simples et complexes.

UML est ainsi apparu comme norme du langage de modélisation objet qui a été
publiée dans sa première version en septembre 1997 par l'OMG (Object
Management Group).

5
 Modélisation avec UML

- La modélisation est une représentation d’un système réel quelle qu’en soit sa
forme: physique, graphique, mathématique, verbale ou mentale.
- Elle  consiste à décrire un problème et la solution de ce problème.

 Cette représentation intelligible est indispensable pour assurer la compréhension

de systèmes complexes.

- Les utilisateurs d'UML regardent et manipulent les modèles au moyens de vues

graphiques, qui forment de véritables projections  à travers des éléments de
modélisation contenus dans un ou plusieurs modèles.

- De nombreuses vues peuvent être construites à partir des modèles de base; à

chaque vue correspond un ou plusieurs diagrammes.    

6
 Diagrammes d'UML

• Un diagramme donne à l’utilisateur un  moyen de visualiser et de manipuler des

éléments de modélisation.
• UML propose de décrire un système à l’aide de neuf diagrammes.

7
 Diagrammes d'UML

• Chacun de ces diagrammes correspond soit à la description d’une partie du système soit
à la description du système selon un point de vue particulier.
• On distingue deux types de diagrammes :
1. les diagrammes structurels,
2. les diagrammes comportementaux.

8
 Positionnement des diagrammes d'UML

- UML décrit les concepts de formalisme de ses 9 diagrammes mais ne propose

pas une démarche de construction ni une description des interactions entre ces
diagrammes.
 Présenter les liens entre les 9 diagrammes ce qui peut constituer une aide dans la
démarche d’élaboration de ces diagrammes.

9
 Positionnement des diagrammes d'UML

Vue statique
La structure statique du système peut être élaborée à travers cinq diagrammes :

-  Diagramme de classes (DCL) : représente la description statique du système en

intégrant dans chaque classe la partie dédiée aux données et aux traitements.

- Diagramme d’objets (DOB) : contient  les instances des classes.

- Diagramme de composants (DCP) : représente les différents constituants logiciels

d’un système. Il permet de montrer les composants du système d'un point de vue
physique, tels qu'ils sont mis en œuvre (fichiers, bibliothèques, bases de données,
etc.).

10
 Positionnement des diagrammes d'UML

Vue statique
La structure statique du système peut être élaborée à travers quatre diagrammes :
- Diagramme de déploiement (DDP) : décrit l’architecture technique d’un système. Il
sert à représenter les éléments matériels (ordinateurs, périphériques, réseaux,
systèmes de stockage, etc.) et la manière dont les composants du système sont
répartis sur ces éléments matériels et interagissent avec eux.

11
 Positionnement des diagrammes d'UML

Vue dynamique
La structure dynamique du système peut être élaborée à travers cinq diagrammes :

-  Diagramme d’états-transitions (DET) : montre la manière dont l'état du système

(ou de sous parties) est modifié en réaction aux événements du système.

- Diagramme d’activités (DAC) : donne une vision des enchaînements des activités

propres à  une opération ou à un cas d’utilisation. C'est une variante du diagramme
d'états-transitions qui permet de représenter le déclenchement d'évènements en
fonction des états du système et de modéliser des comportements parallélisables.

- Diagramme des cas d’utilisation (DCU) : représente les besoins des utilisateurs

par rapport au système. Il décrit les possibilités d'interaction entre le système et les
acteurs, c-à -d toutes les fonctionnalités que doit fournir le système.

12
 Positionnement des diagrammes d'UML

Vue dynamique
La structure dynamique du système peut être élaborée à travers quatre diagrammes :

- Diagramme de séquence (DSE): permet de décrire les scénarios de chaque cas

d’utilisation en mettant l’accent sur la chronologie des opérations en interaction
avec les objets. C'est une représentation séquentielle du déroulement des
traitements et des interactions entre les éléments du système et/ou des acteurs.

- Diagramme de collaboration  (DCO) : est une autre représentation des scénarios

des cas d’utilisation qui met plus l’accent sur les objets et les messages échangés.

13
Nouveautés apportées par le version 2.0 d'UML
- La version 2.0 d'UML comporte 13 diagramme qui sont dépendants
hiérarchiquement et se complètent et propose une nouvelle classification de ces
diagrammes.
- Les 9 diagrammes de la version précédente d'UML sont maintenus, à l'exception
du diagramme de collaboration qui a été remplacé par le diagramme de
communication.
- Les quatre nouveaux diagrammes de la version 2.0 sont les suivants :

1. Diagramme de modules ou paquetages (package diagram) : représente la

hiérarchie des modules d’un projet.
2. Diagramme de structure composite (composite structure diagram) : décrit la
composition d’un objet complexe lors de son exécution.
3. Diagramme global d’interaction (interaction overview) : est une variante du
diagramme d'activités où les noeuds sont des interactions.
4. Diagramme de temps (timing diagram) : est une représentation des
interactions où l'aspect temporel est mis en valeur. Il permet une modélisation
des contraintes d'interaction entre les objets.

14
 Nouveautés apportées par le version 2.0 d'UML

La nouvelle classification comporte trois catégories :

1. Les diagrammes structurels : représentent la vue statique du système, décrivant

les éléments d’une spécification qui ne dépendent pas du temps. Ils comportent les
diagrammes de classes, de structures composites, de composants, de déploiement,
d'objets et de paquetages.

2. Les diagrammes comportementaux : représentent la vue dynamique du système,

décrivant les aspects comportementaux d’un système ou d’un processus d’activité.
Ils comportent les diagrammes d’activité, d'états-transitions et des cas d’utilisation.

3. Les diagrammes d’interactions : c’est une sous-catégorie des diagrammes

comportementaux qui insiste sur l’interaction entre objets. Ils comportent les
diagrammes de communication, global d'interaction, de séquence et de temps.

15
Chapitre 2:
Fondements de base de la conception Orienté
Objet
 Plan
1 Introduction

2 Principes de la modélisation

3 L’approche Orienté Objet

4  Les principes de l’Orienté Objet

17
 Introduction

- Connaître un langage de programmation orientée objet est-il suffisant pour

maîtriser la conception et le développement orientés objet?

Evidemment non! Connaître un langage orienté objet (par exemple

java) est nécessaire mais n’est pas suffisant pour créer un système
à objets.

- Il faut savoir « PENSER en objets »!

18
 Introduction
Très Important!

 C’est inutile:
• d’apprendre un langage de programmation orientée objet.
• d’apprendre UML ou un outil de génie logiciel.
 Si vous n’êtes pas en mesure de:
• Élaborer une excellente conception orientée objet.
• Améliorer une conception existante.
 La compétence de « penser et concevoir en objet » est la plus importante et la plus
difficile à acquérir.

19
 Principes de la modélisation

Objectif principal de la modélisation = maitriser la complexité

Modéliser = abstraire la réalité pour mieux comprendre le système à réaliser.

• Le modèle doit être relié au monde réel.
• Un modèle peut être exprimé avec différents niveaux d’abstraction / raffinement.
• Une seule ≪ vue ≫ du système n’est pas suffisante.
 Les intervenants multiples du projet informatique possèdent des préoccupations
multiples.
• Le modèle permet de :
o Spécifier le système à réaliser/réalisé.
o Valider le modèle vis-à -vis des clients.
o Fournir un guide pour la construction du système.
o Organiser les structures de données et le comportement du système.
o Documenter le système et les décisions prises.

20
 Principes de la modélisation

POURQUOI ET COMMENT MODÉLISER EN ORIENTÉ OBJET?

 Relier le modèle au monde réel par la notion d’objets.

 Orienté objet = abstraire et décomposer le système informatique en objets.
o Le monde réel est constitué d’objets physiques ou immatériels.
o Tracer les objets virtuels de modélisation depuis les objets du monde réel.
• Relier les objets (réels) du problème et les objets (virtuels) de la solution.
o Favoriser les abstractions naturelles du monde réel utilisables en
modélisation.
• Objets vus comme des ≪ boites noires ≫ : seules les propriétés visibles
de l’extérieur nous intéressent.
• Objets possédant un nom, qualifiables, classables, interagissant avec
d’autres objets…

21
 Principes de la modélisation
Objectifs de la modélisation orientée objet

 Meilleure indépendance du modèle par rapport aux fonctions demandées.

 Meilleure capacité d’adaptation et d’évolution du modèle lorsque des fonctionnalités

sont modifiées ou ajoutées.

22
 L’approche orientée Objet
UML: Unified Modeling Language

23
 L’approche orientée Objet
UML: un langage
 UML n’est pas une méthode.
 UML est un langage de modélisation orientée objet.
 UML a été adopté par toutes les méthodes orientées objet.
 UML est dans le domaine public ; c’est un standard.
 UML est un langage pour :
 Visualiser :Chaque symbole graphique possède une sémantique.
 Spécifier: De manière précise et complète, sans ambigü ité.
 Construire :Une partie du code des classes peut être généré automatiquement.
 Documenter :Les différents diagrammes, notes, contraintes, exigences sont
conserves dans un document.

24
 L’approche orientée Objet
UML: 9 diagrammes

25
 L’approche orientée Objet
Analyse Versus Conception
Analyse:
 L’analyse met l’accent sur une investigation du problème et des besoins plutô t que
sur la recherche d’une solution.
 Analyse:
• Qu’est ce qu’on désire développer?
• Quelles sont les fonctions du système?
• Comment spécifier le bon système?
 Le terme analyste est vaste:
• Analyse des besoins (spécification des besoins).
• Analyse orienté Objet (spécification et investigation des objets du système).

26
 L’approche orientée Objet
Analyse Versus Conception

Conception:
 Elaboration d’une solution conceptuelle répondant aux besoins plutô t que la mise en
œuvre de cette solution.
 Exclut souvent les détails de bas niveau.
 Description d’un schéma conceptuel d’objets logiciel et de base de données.
 La conception se résume au terme « bien construire un système ».
 Conception:
 Conception orientée objet/composant.
 Conception de la base de données.
 Conception graphique.

27
 L’approche orientée Objet
Notion d’objet
Définition:
Un objet définit une représentation d’une entité atomique réelle ou virtuelle, dans le but de
le piloter ou de le simuler. Les objets encapsulent une partie des connaissances du monde
dans lequel ils évoluent.
 Un objet associe données et traitements en ne laissant visible que l’interface de
l’objet, c’est à dire les traitements que l’on peut faire dessus
Objet = Identité + Etat + Comportement

 Identité : En plus de son état un objet possède une identité qui permet de le
distinguer de manière non ambiguë indépendamment de son Etat.
 Etat : regroupement des valeurs instantanées de tous les attributs d’un objet.
 Comportement : regroupe toutes les compétences d’un objet (méthodes) et décrit les
actions et les réactions de cet objet.

28
 L’approche orientée Objet
Notion d’objet

 Un objet possède un état et réagit selon un comportement.

 L’état évolue au cours du temps, en fonction du comportement.
 Les objets échanges des messages.

29
 L’approche orientée Objet
Notion de classe

 Une classe décrit un domaine de définition d’un ensemble d’objets : c’est un modèle
qui définit les données et les traitements communs à une collection d’objets
similaires.
 Chaque objet appartient à une classe.
 Classe : regroupement d ’objets de même type.
 L’objet est une instance de sa classe.
 Chaque classe est représentée sous la forme d’ un rectangle divisé en 3 parties.

Exemple:

30
 L’approche orientée Objet
Terminologie orientée objet

 Les traitements sont appelés méthodes de l’objet.

 Les données sont appelées variables, données membres, attributs ou propriétés.
 Les objets informatiques sont construits à partir de la classe par un processus appelé
instanciation.
 Tout objet est une instance d’une Classe.

31
 L’approche orientée Objet
Les qualificatifs de classe (portée)
Publique :
Les fonctions de toutes les classes peuvent accéder aux données ou aux méthodes d'une
classe définie avec le niveau de visibilité public. Il s'agit du plus bas niveau de protection
des données.

Protégée :
L’accès aux données est réservé aux fonctions des classes héritières, c'est à dire par les
fonctions membres de la classe ainsi que des classes dérivées.

Privée :
L'accès aux données est limité aux méthodes de la classe elle-même. Il s'agit du niveau
de protection des données le plus élevé.

32
 L’approche orientée Objet
Les qualificatifs de classe (portée)

Publique :
Un attribut publique pourra être accédé (lu et modifié) par tout le monde.

Protégée :
Un attribut protégé pourra être accédé (lu et modifié) par les classes filles.

Privée :
Un attribut privé pourra être accédé (lu et modifié) par les méthodes et seulement
les méthodes de sa classe.

33
 L’approche orientée Objet
Les qualificatifs de classe (portée)

Publique :
Une méthode publique pourra être accédé (lu et modifié) par tout le monde.

Protégée :
Une méthode protégée pourra être utilisée ou redéfinie par les classes héritières.

Privée :
Une méthode privée pourra être accédé (lu et modifié) par les méthodes et seulement
les méthodes de sa classe.

34
 L’approche orientée Objet
Encapsulation
 L’ encapsulation est l'idée de protéger l'information contenue dans un objet et de ne
proposer que des méthodes de manipulation de cet objet.
 Ainsi, les propriétés et axiomes associés aux informations contenues dans l'objet
seront assurés/validés par les méthodes de l'objet et ne seront plus de la
responsabilité de l'utilisateur extérieur.
 L'utilisateur extérieur ne pourra pas modifier directement l'information et risquer de
mettre en péril les axiomes et les propriétés comportementales de l'objet.
 L'objet est ainsi vu de l'extérieur comme une boîte noire ayant certaines propriétés et
ayant un comportement spécifié. La manière dont ces propriétés ont été paramétrées
est alors cachée aux utilisateurs de la classe.

35
 L’approche orientée Objet
Encapsulation
 Par défaut les valeurs des attributs d’un objets sont encapsulées dans l’objet et ne
peuvent pas être manipulées directement par un autre objet.
 Des règles de visibilité précisent la notion d’encapsulation:
 assouplissement du degré d’encapsulation et de protection au profit de
certaines classes bien particulières (exp: classes mères/filles, classes amies en
C++)
 intérêt : réduire le temps d’accès aux attributs
 Trois niveaux d’encapsulation :
• privé (-): attribut non vu de l’extérieur de l’objet,
• protégé (#): attribut vu par des classes dérivées,
• public (+): attribut visible pour toutes les classes.

36
 L’approche orientée Objet
Héritage

 Chaque instance d’une classe possède ses caractéristiques (attributs+méthodes),

mais aussi celles d’une éventuelle super classe (classe mère).

 La notion d’héritage permet de décrire un type de lien qui unit les différents objets.

 C’est un mécanisme permettant à une classe d’objets de bénéficier de la structure de

données et du comportement d’une classe "mère", tout en lui permettant de les
affiner et ce, afin de prendre en compte les spécificités de la classe "fille", sans avoir
cependant à redéfinir ce que les deux classes ont de commun.

37
 L’approche orientée Objet
Généralisation

Dans le cas d’un héritage, on dit qu’une classe "mère" est une généralisation des
propriétés de ses classes "fille" .

Spécialisation
Dans le cas d’un héritage, on dit qu’une classe "fille" est une spécialisation des
propriétés de sa classe "mère " .

Spécialisation
Généralisation
B

38
 L’approche orientée Objet
Exemple
 Relation entre classes
• Oiseaux est un cas particulier de Animaux (spécialisation)
• Animaux généralise Oiseaux (Généralisation)
 La classe fille
• hérite les attributs et les comportements
• peut avoir des attributs et des méthodes nouvelles
• peut avoir un comportement modifié.

39
 L’approche orientée Objet
Polymorphisme :
• Possibilité de recourir à la même expression pour dénoter différentes opérations.
• L’héritage est une forme particulière de polymorphisme caractéristique des systèmes
orientés objet.
 Exemple-Polymorphisme:
• Tout animal peut se déplacer.
• Il le fait différemment s’il s’agit d’un oiseau ou d’un serpent.

40
 Exercice
1. Je suis ce qui permet de répondre au problème de couplage des données __________.
2. Je suis ce qui circule entre les objets __________.
3. Je suis un synonyme d'objet ou d'agent ____________________.
4. Je suis la visibilité qu'il faut généralement accorder aux données dans une classe ____________.
5. Je représente un ensemble d'objets qui partagent une structure commune et un comportement
commun ________________________.
6. Je donne accès à un service de la classe _______________________.
7. Je suis la composante de la classe qui conserve un état particulier ________.
8. Un des grands espoirs de l'orienté objet qui s'avère plus facile à dire qu'à faire. _____________.
9. Je suis la méthode automatiquement appelée lors de la création d'un objet __________________.
10. Se dit d’une relation de généralisation qui permet de partager les similitudes entre les classes tout
en conservant leurs différences _________.
11. Découper un problème en morceaux suffisamment petits pour permettre de le comprendre
séparément ___________.
12. Je suis une relation de tout et de partie _____________.

41
 Correction
1. Je suis ce qui permet de répondre au problème de couplage des données encapsulation
2. Je suis ce qui circule entre les objets message
3. Je suis un synonyme d'objet ou d'agent instance
4. Je suis la visibilité qu'il faut généralement accorder aux données dans une classe privée
5. Je représente un ensemble d'objets qui partagent une structure commune et un comportement
commun classe
6. Je donne accès à un service de la classe méthode
7. Je suis la composante de la classe qui conserve un état particulier attribut
8. Un des grands espoirs de l'orienté objet qui s'avère plus facile à dire qu'à faire réutilisation
9. Je suis la méthode automatiquement appelée lors de la création d'un objet constructeur
10. Se dit d’une relation de généralisation qui permet de partager les similitudes entre les classes
tout en conservant leurs différences héritage
11. Découper un problème en morceaux suffisamment petits pour permettre de le comprendre
séparément composition
12. Je suis une relation de tout et de partie agrégation

42
Chapitre 3:
Les diagrammes statiques:
Le diagramme de Cas d’utilisation
 Plan
1Introduction
2Identification et représentation des cas d’utilisation
3 Représentation du diagramme des cas d’utilisation

4  Relation entre cas d’utilisation

5  Relation entre cas acteurs

6  Description textuelle

44
 Introduction
 Les cas d’utilisation « use cases » ont été formalisés par Ivar Jacobson.
 Ils décrivent sous forme d’actions et de réactions, le comportement d’un système du
point de vue d’un utilisateur.

 Les cas d’utilisation sont utiles lors de l’élaboration du cahier des charges ou du
document de spécifications des besoins du logiciel.

 Le modèle des cas d’utilisation comprend:

1. les acteurs,
2. le système,
3. les cas d’utilisation.

45
 Introduction
 L’ensemble des fonctionnalités du système est déterminé en examinant les besoins
de chaque acteur, exprimés sous forme de famille d’interactions dans les cas
d’utilisation.
 Les acteurs se représentent sous forme de petits personnages qui déclenchent les
cas. Ces derniers se représentent par des ellipses contenues dans un rectangle
représentant le système.

 l’acteur A déclenche le cas X et l’acteur B déclenche le cas Y.

46
 Introduction
- Il existe quatre catégories d’acteurs:
1. les acteurs principaux: ceux qui sont les utilisateurs du système.
2. les acteurs secondaires: ceux qui administrent le système.
3. le matériel externe.
4. les autres systèmes.

- Un cas d’utilisation décrit un ensemble de scénarios du point de vue de l’utilisateur

grâ ce à des diagrammes de séquence ou des diagrammes de collaboration. 
- Les cas d'utilisation constituent un moyen de recueillir et de décrire les besoins des
acteurs du système.
- Ils peuvent être aussi utilisés ensuite comme moyen d'organisation du développement
du logiciel, notamment pour la structuration et le déroulement des tests du logiciel.

47
 Identification et représentation des cas d'utilisation

• Tout système peut être décrit par un certain nombre de cas d'utilisation représentant
les besoins exprimés par l'ensemble des utilisateurs.

• À chaque utilisateur, vu comme acteur, correspondra un certain nombre de cas

d'utilisation du système.

• L'ensemble de ces cas d'utilisation se représente sous forme d'un diagramme.

• Chaque cas d'utilisation doit être décrit sous forme textuelle afin de bien identifier
les traitements à réaliser par le système en vue de la satisfaction du besoin exprimé
par l'acteur.

48
 Identification et représentation des cas d'utilisation

 Chaque cas d'utilisation produit un ou plusieurs résultats.

 Le travail d'identification des cas d'utilisation suppose que les acteurs eux-mêmes
soient déjà connus ou doivent l'être complètement à la fin de l'opération de
description des cas d'utilisation.

 Un acteur est un utilisateur type qui a toujours le même comportement vis-à -vis d'un
cas d'utilisation.

Ainsi les utilisateurs d'un système appartiennent à une ou plusieurs classes

d'acteurs selon les rô les qu'ils tiennent par rapport au système.

49
 Représentation du diagramme des cas d'utilisation

• La représentation d'un cas d'utilisation met en jeu trois concepts :

1. l'acteur ;
2. le cas d'utilisation ;
3. l'interaction entre l'acteur et le cas d'utilisation.

• Le formalisme de base de représentation d'un cas d'utilisation:

L'interaction entre un acteur et un cas d'utilisation se représente comme une

association.

50
 Représentation du diagramme des cas d'utilisation

Acteur
• entité externe qui agit sur le système (opérateur, autre système…).
• Il se représente par un petit bonhomme avec son nom inscrit dessous.
• Il est également possible de représenter un acteur sous la forme d'un classeur
stéréotypé « actor  ».

51
 Représentation du diagramme des cas d'utilisation

Cas d'utilisation
• ensemble d’actions réalisées par le système, en réponse à une action d’un acteur.
• Les uses cases peuvent être structurés.
• Les uses cases peuvent être organisés en paquetages (packages).
• L’ensemble des uses cas décrit les objectifs (le but) du système.

Remarque : Le nom du use case doit se composer d'un verbe à l'infinitif qui décrit
une action. Pour que l'ensemble du modèle soit cohérent il faut choisir tous les
verbes soit du point de vue du système soit du point de vue de l'utilisateur (ce qui est
généralement préférable).

52
 Représentation du diagramme des cas d'utilisation

Cas d'utilisation
• Un cas d'utilisation se représente par une ellipse contenant le nom du cas (un verbe à
l'infinitif), et optionnellement, au-dessus du nom, un stéréotype.

• Dans le cas où l'on désire présenter les attributs ou les opérations du cas d'utilisation,
il est préférable de le représenter sous la forme d'un classeur stéréotypé  »use case » 

53
 Représentation du diagramme des cas d'utilisation

Formalisme de représentation des cas d’utilisation

54
 Représentation du diagramme des cas d'utilisation

Exemple
Un système de messagerie comporte quatre cas d'utilisation. Nous verrons, dans la
suite du cours d'UML, qu'un cas d'utilisation peut avoir une ou plusieurs instances
représentées par des scénarios. Chaque scénario fait l'objet lui-même d'un
diagramme de séquence ou de collaboration. En conclusion, nous dirons qu'un
système est caractérisé par son comportement vis-à -vis de ses utilisateurs. Ce
comportement se représente sous forme d'un ensemble de cas d'utilisation qui
correspond aux besoins des acteurs de ce système.

55