Chapitre 1

Introduction à la modélisation objet

1. L’informatisation
L’informatisation est le phénomène le plus important de notre époque. Elle s’immisce maintenant
dans la plupart des objets de la vie courante et ce, que ce soit dans l’objet proprement dit 1, ou bien
dans le processus de conception ou de fabrication de cet objet.

Actuellement, l’informatique est au cœur de toutes les grandes entreprises. Le système

d’information d’une entreprise est composé de matériels et de logiciels. Plus précisément, les
investissements dans ce système d’information se répartissent généralement de la manière
suivante : 20% pour le matériel et 80% pour le logiciel. En effet, depuis quelques années, la
fabrication du matériel est assurée par quelques fabricants seulement. Ce matériel est relativement
fiable et le marché est standardisé. Les problèmes liés à l’informatique sont essentiellement des
problèmes de logiciel.

2. Les Logiciels
Un logiciel ou une application est un ensemble de programmes, qui permet à un ordinateur ou à
un système informatique d’assurer une tâche ou une fonction en particulier (exemple : logiciel de
comptabilité, logiciel de gestion des prêts).

Les logiciels, suivant leur taille, peuvent être développés par une personne seule, une petite équipe,
ou un ensemble d’équipes coordonnées. Le développement de grands logiciels par de grandes
équipes pose d’importants problèmes de conception et de coordination. Or, le développement d’un
logiciel est une phase absolument cruciale qui monopolise l’essentiel du coût d’un produit 2 et
conditionne sa réussite et sa pérennité.

En 1995, une étude du Standish Group dressait un tableau accablant de la conduite des projets
informatiques. Reposant sur un échantillon représentatif de 365 entreprises, totalisant 8380
applications, cette étude établissait que :

1 Par exemple, aujourd’hui, 90% des nouvelles fonc:onnalités des automobiles sont apportées par l’électronique et l’informa:que embarquées.

Il y a, ou aura à terme, du logiciel partout : ampoules électriques, four à micro ondes, :ssus des vêtements, stylos, livres, etc.
2 Compara:vement à sa produc:on, le coût du développement d’un logiciel est extrêmement important. Nous verrons par la suite que la

maintenance coûte également très cher.

Par Mme GBEDEVI ESGIS-TOGO 1

 – 16, 2% seulement des projets étaient conformes aux prévisions initiales,

– 52, 7% avaient subi des dépassements en coût et délai d’un facteur 2 à 3 avec diminution du
nombre des fonctions offertes,

– 31, 1% ont été purement abandonnés durant leur développement.

Pour les grandes entreprises (qui lancent proportionnellement davantage de gros projets), le taux
de succès est de 9% seulement, 37% des projets sont arrêtés en cours de réalisation, 50%
aboutissent hors délai et hors budget.

3. Pourquoi et comment modéliser ?

3.1. Notions de modèle et de modélisation
3.1.1. Qu’est-ce qu’un modèle ?

Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d’une
entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, de l’expliquer ou
de le prévoir.

Modèle est synonyme de théorie, mais avec une connotation pratique : un modèle, c’est une théorie
orientée vers l’action qu’elle doit servir. Concrètement, un modèle permet de réduire la complexité
d’un phénomène en éliminant les détails qui n’influencent pas son comportement de manière
significative. Il reflète ce que le concepteur croit important pour la compréhension et la prédiction
du phénomène modélisé, les limites du phénomène modélisé dépendant des objectifs du modèle.

Voici quelques exemples de modèles prédictifs :

Modèle météorologique : à partir de données d’observation (satellite . . .), il permet de prévoir les
conditions climatiques pour les jours à venir.
Modèle économique : peut par exemple permettre de simuler l’évolution de cours boursiers en
fonction d’hypothèses macro-économiques (évolution du chômage, taux de croissance . . .).
Modèle démographique : définit la composition d’un panel d’une population et son
comportement, dans le but de fiabiliser des études statistiques, d’augmenter l’impact de
démarches commerciales, etc.

3.1.2. Pourquoi modéliser ?

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du
système. C’est également un bon moyen de maîtriser sa complexité et d’assurer sa cohérence. Un
modèle est un langage commun, précis, qui est connu par tous les membres de l’équipe et il est
donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle pour

Par Mme GBEDEVI ESGIS-TOGO 2

aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la
maîtrise d’ouvrage et maîtrise d’œuvre informatique) et précise d’un problème donné.
Dans le domaine de l’ingénierie du logiciel, le modèle permet de mieux répartir les tâches et
d’automatiser certaines d’entre elles. C’est également un facteur de réduction des coûts et des
délais. Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour
faire de la génération de code (au moins au niveau du squelette) voire des aller-retours entre le
code et le modèle sans perte d’information. Le modèle est enfin indispensable pour assurer un bon
niveau de qualité et une maintenance efficace. En effet, une fois mise en production, l’application
va devoir être maintenue, probablement par une autre équipe et, qui plus est, pas nécessairement
de la même société que celle ayant créée l’application.
Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes non
triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles
employés, la démarche de modélisation n’est pas la même.

3.1.3. Qui doit modéliser ?

La modélisation est souvent faite par la maîtrise d’œuvre informatique (MOE). C’est
malencontreux, car les priorités de la MOE résident dans le fonctionnement de la plate-forme
informatique et non dans les processus de l’entreprise.

Il est préférable que la modélisation soit réalisée par la maîtrise d’ouvrage (MOA) de sorte que le
métier soit maître de ses propres concepts. La MOE doit intervenir dans le modèle lorsque, après
avoir défini les concepts du métier, on doit introduire les contraintes propres à la plate-forme
informatique.

Il est vrai que les métiers, dont les priorités sont opérationnelles, ne disposent pas toujours de la
capacité d’abstraction, de la rigueur conceptuelle nécessaires à la formalisation. La
professionnalisation de la MOA a pour but de les doter de ces compétences. Cette
professionnalisation réside essentiellement dans l’aptitude à modéliser le système d’information
du métier : le maître mot est modélisation. Lorsque le modèle du système d’information est de
bonne qualité, sobre, clair, stable, la maîtrise d’œuvre peut travailler dans de bonnes conditions.
Lorsque cette professionnalisation a lieu, elle modifie les rapports avec l’informatique et déplace
la frontière des responsabilités, ce qui contrarie parfois les informaticiens dans un premier temps,
avant qu’ils n’en voient apparaître les bénéfices.

3.1.4. Maîtrise d’ouvrage et maîtrise d’œuvre

Maître d’ouvrage (MOA) : Le MOA est une personne morale (entreprise, direction etc.), une
entité de l’organisation. Ce n’est jamais une personne.

Par Mme GBEDEVI ESGIS-TOGO 3

Maître d’œuvre (MOE) : Le MOE est une personne morale (entreprise, direction etc.) garante de
la bonne réalisation technique des solutions. Il a, lors de la conception du SI, un devoir de
conseil vis-à-vis du MOA, car le SI doit tirer le meilleur parti des possibilités techniques.

Le MOA est client du MOE à qui il passe commande d’un produit nécessaire à son activité.

Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou plusieurs
fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.

La relation MOA et MOE est définie par un contrat qui précise leurs engagements mutuels.

Lorsque le produit est compliqué, il peut être nécessaire de faire appel à plusieurs fournisseurs. Le
MOE assure leur coordination ; il veille à la cohérence des fournitures et à leur compatibilité. Il
coordonne l’action des fournisseurs en contrôlant la qualité technique, en assurant le respect des
délais fixés par le MOA et en minimisant les risques.

Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison au
MOA, procéder aux vérifications nécessaires (« recette usine »).

3.2. Le cycle de vie d’un logiciel

Le cycle de vie d’un logiciel (en anglais software lifecycle), désigne toutes les étapes du
développement d’un logiciel, de sa conception à sa disparition. L’objectif d’un tel découpage est
de permettre de définir des jalons intermédiaires permettant la validation du développement
logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du
processus de développement, c’est-à-dire l’adéquation des méthodes mises en œuvre.

L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant plus élevé
qu’elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de
détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation
et les coûts associés. Le cycle de vie du logiciel comprend généralement à minima les étapes
suivantes :

Définition des objectifs – Cet étape consiste à définir la finalité du projet et son inscription dans
une stratégie globale.

Analyse des besoins et faisabilité – c’est-à-dire l’expression, le recueil et la formalisation des

besoins du demandeur (le client) et de l’ensemble des contraintes puis l’estimation de la
faisabilité de ces besoins.

Spécification ou conception générale – Il s’agit de l’élaboration des spécifications de

l’architecture générale du logiciel.

Par Mme GBEDEVI ESGIS-TOGO 4

Conception détaillée – Cette étape consiste à définir précisément chaque sous-ensemble du
logiciel.

Codage (Implémentation ou programmation) – c’est la traduction dans un langage de

programmation des fonctionnalités définies lors de phases de conception.

Tests unitaires – Ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel
est implémenté conformément aux spécifications.

Intégration – L’objectif est de s’assurer de l’interfaçage des différents éléments (modules) du

logiciel. Elle fait l’objet de tests d’intégration consignés dans un document.

Qualification (ou recette) – C’est-à-dire la vérification de la conformité du logiciel aux

spécifications initiales.
Documentation – Elle vise à produire les informations nécessaires pour l’utilisation du logiciel et
pour des développements ultérieurs.
Mise en production
Maintenance – Elle comprend toutes les actions correctives (maintenance corrective) et évolutives
(maintenance évolutive) sur le logiciel.
La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix d’un
modèle de cycle de vie entre le client et l’équipe de développement. Le cycle de vie permet de
prendre en compte, en plus des aspects techniques, l’organisation et les aspects humains.

3.3. Méthodes d’analyse et de conception

Les méthodes d’analyse et de conception fournissent une méthodologie et des notations standards
qui aident à concevoir des logiciels de qualité. Il existe différentes manières pour classer ces
méthodes, dont :
La distinction entre composition et décomposition : Elle met en opposition d’une part les
méthodes ascendantes qui consistent à construire un logiciel par composition à partir de
modules existants et, d’autre part, les méthodes descendantes qui décomposent récursivement
le système jusqu’à arriver à des modules programmables simplement.
La distinction entre fonctionnel (dirigée par le traitement) et orientée objet : Dans la stratégie
fonctionnelle (également qualifiée de structurée) un système est vu comme un ensemble
hiérarchique d’unités en interaction, ayant chacune une fonction clairement définie. Les
fonctions disposent d’un état local, mais le système a un état partagé, qui est centralisé et
accessible par l’ensemble des fonctions. Les stratégies orientées objet considèrent qu’un
système est un ensemble d’objets interagissant. Chaque objet dispose d’un ensemble
d’attributs décrivant son état et l’état du système est décrit (de façon décentralisée) par l’état
de l’ensemble.

Par Mme GBEDEVI ESGIS-TOGO 5

4. De la programmation structurée à l’approche orientée objet
4.1. Méthodes fonctionnelles ou structurées

Figure 1: Représentation graphique d'une approche fonctionnelle

Les méthodes fonctionnelles (également qualifiées de méthodes structurées) trouvent leur origine
dans les langages procéduraux. Elles mettent en évidence les fonctions à assurer et proposent une
approche hiérarchique descendante et modulaire.
Ces méthodes utilisent intensivement les raffinements successifs pour produire des spécifications
dont l’essentielle est sous forme de notation graphique en diagrammes de flots de données. Le plus
haut niveau représente l’ensemble du problème (sous forme d’activité, de données ou de processus,
selon la méthode). Chaque niveau est ensuite décomposé en respectant les entrées/sorties du niveau
supérieur. La décomposition se poursuit jusqu’à arriver à des composants maîtrisables (cf. figure
1).
L’approche fonctionnelle dissocie le problème de la représentation des données, du problème du
traitement de ces données. Sur la figure 1, les données du problème sont représentées sur la gauche.
Des flèches transversales matérialisent la manipulation de ces données par des sous-fonctions. Cet
accès peut-être direct (c’est parfois le cas quand les données sont regroupées dans une base de
données), ou peut être réalisé par le passage de paramètre depuis le programme principal.

4.2. L’approche Orientée Objet

L’approche orientée objet considère le logiciel comme une collection d’objets dissociés, et
identifiés, définis par des propriétés. Une propriété est soit un attribut (i.e. une donnée caractérisant
l’état de l’objet), entité élémentaire comportementale de l’objet). La fonctionnalité du logiciel
émerge alors de l’interaction entre les différents objets qui le constituent. L’une des particularités
de cette approche est qu’elle rapproche les données et leurs traitements associés au sein d’un
unique objet. Comme nous venons de le dire, un objet est caractérisé par plusieurs notions :
L’identité – L’objet possède une identité, qui permet de le distinguer des autres objets,
indépendamment de son état. On construit généralement cette identité grâce à un identifiant

Par Mme GBEDEVI ESGIS-TOGO 6

 découlant naturellement du problème (par exemple un produit pourra être repéré par un code,
une voiture par un numéro de série, etc.)
Les attributs – Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des
informations sur l’état de l’objet.
Les méthodes – Les méthodes d’un objet caractérisent son comportement, c’est-à-dire l’ensemble
des actions (appelées opérations) que l’objet est à même de réaliser. Ces opérations
permettent de faire réagir l’objet aux sollicitations extérieures (ou d’agir sur les autres objets).
De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre
des valeurs des attributs, ou bien les modifier.
La difficulté de cette modélisation consiste à créer une représentation abstraite, sous forme d’objets,
d’entités ayant une existence matérielle (chien, voiture, ampoule, personne, . . .) ou bien virtuelle
(client, temps, . . .).
La Conception Orientée Objet (COO) est la méthode qui conduit à des architectures logicielles
fondées sur les objets du système, plutôt que sur la fonction qu’il est censé réaliser.

4.3. Concepts importants de l’approche objet

L’approche objet rapproche les données et leurs traitements. Mais cette approche ne fait pas que
ça, d’autres concepts importants sont spécifiques à cette approche et participent à la qualité du
logiciel.

Notion de classe

Une classe est un type de données abstrait, caractérisé par des propriétés (attributs et méthodes)
communes à toute une famille d’objets et permettant de créer (instancier) des objets possédant ces
propriétés. Les autres concepts importants qu’il nous faut maintenant introduire sont
l’encapsulation, l’héritage et l’agrégation.

Encapsulation

L’encapsulation consiste à masquer les détails d’implémentation d’un objet, en définissant une
interface. L’interface est la vue externe d’un objet, elle définit les services accessibles (offerts) aux
utilisateurs de l’objet.

L’encapsulation facilite l’évolution d’une application car elle stabilise l’utilisation des objets : on
peut modifier l’implémentation des attributs d’un objet sans modifier son interface, et donc la
façon dont l’objet est utilisé.

L’encapsulation garantit l’intégrité des données, car elle permet d’interdire, ou de restreindre,
l’accès direct aux attributs des objets.

Par Mme GBEDEVI ESGIS-TOGO 7

Héritage, Spécialisation, Généralisation et polymorphisme

L’héritage est un mécanisme de transmission des propriétés d’une classe (ses attributs et méthodes)
vers une sous-classe. Une classe peut être spécialisée en d’autres classes, afin d’y ajouter des
caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent être généralisées
en une classe qui les factorise, afin de regrouper les caractéristiques communes d’un ensemble de
classes.

Ainsi, la spécialisation et la généralisation permettent de construire des hiérarchies de classes.

L’héritage peut être simple ou multiple. L’héritage évite la duplication et encourage la réutilisation.

Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des objets de

classes différentes. Le polymorphisme augmente la généricité, et donc la qualité, du code.

Agrégation

Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont des
composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets
composés d’autres objets. L’agrégation permet donc d’assembler des objets de base, afin de
construire des objets plus complexes.

5. UML
5.1. Introduction

La description de la programmation par objets a fait ressortir l’étendue du travail conceptuel

nécessaire : définition des classes, de leurs relations, des attributs et méthodes, des interfaces etc.
Pour programmer une application, il ne convient pas de se lancer tête baissée dans l’écriture du
code : il faut d’abord organiser ses idées, les documenter, puis organiser la réalisation en
définissant les modules et étapes de la réalisation. C’est cette démarche antérieure à l’écriture que
l’on appelle modélisation ; son produit est un modèle.
Les spécifications fournies par la maîtrise d’ouvrage en programmation impérative étaient souvent
floues : les articulations conceptuelles (structures de données, algorithmes de traitement)
s’exprimant dans le vocabulaire de l’informatique, le modèle devait souvent être élaboré par celle-
ci. L’approche objet permet en principe à la maîtrise d’ouvrage de s’exprimer de façon précise
selon un vocabulaire qui, tout en transcrivant les besoins du métier, pourra être immédiatement
compris par les informaticiens. En principe seulement, car la modélisation demande aux maîtrises
d’ouvrage une compétence, un professionnalisme qui ne sont pas aujourd’hui répandus.
5.2. UML en œuvre

UML n’est pas une méthode (i.e. une description normative des étapes de la modélisation) : ses
auteurs ont en effet estimé qu’il n’était pas opportun de définir une méthode en raison de la
diversité des cas particuliers. Ils ont préféré se borner à définir un langage graphique qui permet

Par Mme GBEDEVI ESGIS-TOGO 8

de représenter, de communiquer les divers aspects d’un système d’information (aux graphiques
sont bien sûr associés des textes qui expliquent leur contenu). UML est donc un métalangage car
il fournit les éléments permettant de construire le modèle qui, lui, sera le langage du projet.
Il est impossible de donner une représentation graphique complète d’un logiciel, ou de tout autre
système complexe, de même qu’il est impossible de représenter entièrement une statue (à trois
dimensions) par des photographies (à deux dimensions). Mais il est possible de donner sur un tel
système des vues partielles, analogues chacune à une photographie d’une statue, et dont la
juxtaposition donnera une idée utilisable en pratique sans risque d’erreur grave.
UML 2.0 comporte ainsi treize types de diagrammes représentant autant de vues distinctes pour
représenter des concepts particuliers du système d’information. Ils se répartissent en deux grands
groupes :
Diagrammes structurels ou diagrammes statiques (UML Structure)
– Diagramme de classes (Class diagram)
– Diagramme d’objets (Object diagram)
– Diagramme de composants (Component diagram)
– Diagramme de déploiement (Deployment diagram)
– Diagramme de paquetages (Package diagram)
– Diagramme de structures composites (Composite structure diagram)
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior)
– Diagramme de cas d’utilisation (Use case diagram)
– Diagramme d’activités (Activity diagram)
– Diagramme d’états-transitions (State machine diagram)
– Diagrammes d’interaction (Interaction diagram)
– Diagramme de séquence (Sequence diagram)
– Diagramme de communication (Communication diagram)
– Diagramme global d’interaction (Interaction overview diagram)
– Diagramme de temps (Timing diagram)

Ces diagrammes, d’une utilité variable selon les cas, ne sont pas nécessairement tous produits à
l’occasion d’une modélisation. Les plus utiles pour la maîtrise d’ouvrage sont les diagrammes
d’activités, de cas d’utilisation, de classes, d’objets, de séquence et d’états-transitions. Les
diagrammes de composants, de déploiement et de communication sont surtout utiles pour la
maîtrise d’œuvre à qui ils permettent de formaliser les contraintes de la réalisation et la solution
technique.

Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation (cf. section 2) représente la structure des grandes fonctionnalités
nécessaires aux utilisateurs du système. C’est le premier diagramme du modèle UML, celui où
s’assure la relation entre l’utilisateur et les objets que le système met en œuvre.

Par Mme GBEDEVI ESGIS-TOGO 9

Diagramme de classes
Le diagramme de classes (cf. section 3) est généralement considéré comme le plus important dans
un développement orienté objet. Il représente l’architecture conceptuelle du système : il décrit les
classes que le système utilise, ainsi que leurs liens, que ceux-ci représentent un emboîtage
conceptuel (héritage) ou une relation organique (agrégation).

Diagramme d’objets
Le diagramme d’objets permet d’éclairer un diagramme de classes en l’illustrant par des exemples.
Il est, par exemple, utilisé pour vérifier l’adéquation d’un diagramme de classes à différents cas
possibles.

Diagramme d’états-transitions
Le diagramme d’états-transitions représente la façon dont évoluent (i.e. cycle de vie) les objets
appartenant à une même classe. La modélisation du cycle de vie est essentielle pour représenter et
mettre en forme la dynamique du système.

Diagramme d’activités
Le diagramme d’activités (cf. section 4) n’est autre que la transcription dans UML de la
représentation du processus telle qu’elle a été élaborée lors du travail qui a préparé la modélisation :
il montre l’enchaînement des activités qui concourent au processus.

Diagramme de séquence et de communication

Le diagramme de séquence (cf. section 5) représente la succession chronologique des opérations
réalisées par un acteur. Il indique les objets que l’acteur va manipuler et les opérations qui font
passer d’un objet à l’autre. On peut représenter les mêmes opérations par un diagramme de
communication graphe dont les nœuds sont des objets et les arcs (numérotés selon la chronologie)
les échanges entre objets. En fait, diagramme de séquence et diagramme de communication sont
deux vues différentes mais logiquement équivalentes (on peut construire l’une à partir de l’autre)
d’une même chronologie. Ce sont des diagrammes d’interaction.

5.3. Comment présenter un modèle UML ?

La présentation d’un modèle UML se compose de plusieurs documents écrits en langage courant
et d’un document formalisé : elle ne doit pas se limiter au seul document formalisé car celui-ci est
pratiquement incompréhensible si on le présente seul. Un expert en UML sera capable dans
certains cas de reconstituer les intentions initiales en lisant le modèle, mais pas toujours ; et les
experts en UML sont rares. Voici la liste des documents qui paraissent nécessaires :

Par Mme GBEDEVI ESGIS-TOGO 10

Présentation stratégique : elle décrit pourquoi l’entreprise a voulu se doter de l’outil considéré,
les buts qu’elle cherche à atteindre, le calendrier de réalisation prévu, etc.

Présentation des processus de travail par lesquels la stratégie entend se réaliser : pour
permettre au lecteur de voir comment l’application va fonctionner en pratique, elle doit être
illustrée par une esquisse des écrans qui seront affichés devant les utilisateurs de terrain.

Explication des choix qui ont guidé la modélisation formelle : il s’agit de synthétiser, sous les
yeux du lecteur, les discussions qui ont présidé à ces choix.

Modèle formel : c’est le document le plus épais et le plus difficile à lire. Il est préférable de le
présenter sur l’Intranet de l’entreprise. En effet, les diagrammes peuvent être alors équipés
de liens hypertextes permettant l’ouverture de diagrammes plus détaillés ou de commentaires.

On doit présenter en premier le diagramme de cas d’utilisation qui montre l’enchaînement des cas
d’utilisation au sein du processus, enchaînement immédiatement compréhensible ; puis le
diagramme d’activités, qui montre le contenu de chaque cas d’utilisation ; puis le diagramme de
séquence, qui montre l’enchaînement chronologique des opérations à l’intérieur de chaque cas
d’utilisation. Enfin, le diagramme de classes, qui est le plus précis conceptuellement mais aussi le
plus difficile à lire car il présente chacune des classes et leurs relations (agrégation, héritage,
association, etc.).

Par Mme GBEDEVI ESGIS-TOGO 11