République Démocratique du Congo

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

INSTITUT SUPERIEUR DE STATISTIQUE DE KINSHASA

(I.S.S. – KINSHASA)

SECTION : INFORMATIQUE DE GESTION

B.P. : 1757

MISE EN ŒUVRE D’UNE ARCHITECTURE

ORIENTEE SERVICE DANS UN SYSTEME
DISTRIBUE POUR LA GESTION DES DROITS
D’AUTEUR
« Cas de SOCODA COOP-CA »

Par

AMUNDALA SAIDI Joscal

Gradué en Informatique de Gestion

Mémoire présenté et défendu en vue d’obtenir le

titre de Licencié en Informatique de Gestion

Option : Conception du Système d’Information

Directeur : MBIKAYI MPANYA Jean-Marcel

Professeur Docteur

Rapporteur : KANYINDA KAYEMBE Kam’S

Chef de Travaux

ANNEE ACADEMIQUE 2021-2022

 i

EPIGRAPHE

Droits d'auteur, culture et onanisme sont inaliénables, on peut même en jouir

en prison.

José Artur
 ii

IN MEMORIAM

A notre mère FOLO KOMBOZI Ida, que le destin a si tôt arraché à notre
affection. L’amour qui nous a liés sera à jamais plus que tout et nous ne
saurons oublier les efforts et sacrifices consentis pour notre éducation et notre
bien-être.

AMUNDALA SAÏDI Joscal

 iii

DEDICACES

A notre père AMUNDALA ABEL Gaston, à mon frère ainsi que mes sœurs, je
dédie le présent travail.

AMUNDALA SAÏDI Joscal

 iv

REMERCIEMENTS
Après tant d’années de notre formation au sein de l’Institut Supérieur
de Statistique de Kinshasa, nous voici à la fin de notre deuxième cycle. Le
présent travail étant le fruit de multiples efforts durant ces deux ans de notre
cycle de licence, nous n’aurons pu le réaliser sans la collaboration de
nombreuses personnes.

A tout Seigneur, toute Honneur, nous remercions Dieu, notre Père,

pour toutes les grâces dont nous avons bénéficié afin d’arriver à la fin de notre
second cycle malgré des trajectoires glissantes.

Nos remerciements s’adressent aussi aux autorités académiques ainsi

que tout le corps professoral de l’Institut Supérieur de Statistique de Kinshasa,
ISS – KIN en sigle, pour la formation bénéficiée durant notre cursus dans cette
institution.

Notre profonde gratitude à l’attention particulière du Professeur

Docteur MBIKAYI MPANYA Jean Marcel, qui a assuré la direction du présent
travail, pour la disponibilité, le conseil, les remarques et orientations dans la
rédaction de ce travail.

Nous exprimons notre reconnaissance au Chef des Travaux

KANYINDA KAYEMBE Kam’s qui nous a éventuellement tendu la main et
encouragé pour que ce travail puisse bien s'achever.

Nos pensées et notre considération vont à l’endroit de toute la

famille AMUNDALA, FOLO ainsi que la famille UNAMAKA, pour leur si grande
attention psychologique, leur soutien sur tous les plans ainsi que leur amour.

Aux Membres de la Communauté Christ Lumière du Monde et ceux

du Chœur Lux Mundi, qu’ils trouvent ici l’expression de notre reconnaissance
pour leurs soutiens, précieux conseils et contributions spirituelles.

A notre chère ABOKWA MAMUNGA Chanceline, celle pour qui nous

avons beaucoup d’estimes, ainsi que tous ceux qui nous ont soutenus de près
ou de loin, nous citons : Monsieur N’YOKA LONGO M’VULA Joseph-Roger,
KUTUMBAKANA Bonnette, MONDONGA Joe, MOKONZI Olivier, MANDAY Jean,
UNAMAKA Fides et KAKINGA Juddy.

Aux confrères et amis de lutte que je ne puis citer de peur que

l’injustice de l’oubli m’habite, pour leur joie de vivre, encouragement, nous
vous en sommes reconnaissant et prions que rien n’efface ces souvenirs
construits durant toutes ces années.

AMUNDALA SAÏDI Joscal

 v

LISTE DES SIGLES ET ACRONYMES

• AN : Alpha numérique
• C# : C Shap
• COOP-CA : Société Coopérative avec Conseil d’Administration
• CORBA : Common Object Request Broker Architecture
• CPM : Critical Post Method
• CRUD : Create, Read, Update, Delete
• GEST.DR.AU : Gestion des Droits d’Auteur
• HTTP : HyperText Transfert Protocol
• IIOP : Internet Inter-ORB Protocol
• JMRP : Java Remote Method Protocol
• LAN : Local Area Network
• MIME : Multipurpose Internet Mail Extensions
• ML : Marge Libre
• MT : Morge Totale
• MYSQL : My Structured Query Language
• N : Numérique
• NASA : National Aeronautics and Space Administration
• OMT : Object Modeling Technique
• ONDA : Office National des Droits d’Auteur
• OOSE : Object- Oriented Software Engineering
• ORPC : Object Remote Procedure Call
• PERT : Program Evaluation and Review Technique
• RDC : République Démocratique du Congo
• RMI : Remote method invocation
• SACO : Société des Auteurs Congolais
• SMTP : Simple Mail Transfer Protocol
• SOA : Service-Oriented Architecture
• SOAP : Simple Object Access Protocol
• SOCODA : Société Congolaise des Droits d’Auteur et des Droits Voisins
• SONECA : Société Nationale des Editeurs, Compositeurs et Auteurs
• SQL : Structured Query Language
• UDDI : Universal Description Discovery and Integration
• UP : Unified Process
• URI : Uniform Resource Identifier
• USA : United States of America
• W3C : World Wide Web Consortium
• WSDL : Web Services Description Language
• XML : Extensible Markup Language
 vi

LISTE DES FIGURES

- Figure I.1. Modèle d’architecture client-serveur ………………………………….. 14
- Figure I.2. Architecture client-serveur à un niveau ……………………………….. 15
- Figure I.3. Architecture client-serveur à deux niveaux …………………………… 16
- Figure I.4. Architecture client-serveur à trois niveaux …………………………….. 16
- Figure I.5. Architecture client-serveur multicouche ………………………………. 17
- Figure I.6. Architecture peer-to-peer …………………………………………………18
- Figure II.1. Infrastructure des services web …………………………………………. 24
- Figure II.2. Les composants d’un service web …………………………………….. 25
- Figure II.3. Structure d’un SOAP ………………………………………………………. 27
- Figure II.4. Fonctionnement du protocole SOAP ………………………………….. 28
- Figure II.5. Protocole WSDL …………………………………………………………….. 29
- Figure II.6. Fichiers WSDL………………………………………………………………… 30
- Figure II.7. UDDI …………………………………………………………………………... 31
- Figure I.1. Graphe PERT ………………………………………………………………… 40
- Figure I.2. Chemin critique et tâches critiques ……………………………………. 46
- Figure I.1. : Diagramme de contexte GEST.DR.AU. ……………………………….. 64
- Figure I.2 : Architecture du Système GEST.DR.AU. ………………………………… 67
- Figure I.3. : Diagramme de cas d’utilisation pour la déclaration ……………… 69
- Figure I.4. : Diagramme de cas d’utilisation pour la taxation et le paiement 70
- Figure I.5 : Diagramme de classes……………………………………………………. 71
- Figure I.6 : Diagramme de séquence pour la déclaration ……………………… 72
- Figure I.7 : Diagramme de séquence pour la taxation et le paiement ……… 72
- Figure I.8 : Diagramme d’activités pour la déclaration …………………………. 73
- Figure I.9 : Diagramme d’activités pour la taxation et le paiement ………….. 74
- Figure I.10 : Diagramme de déploiement ………………………………………….. 74
 vii

LISTE DES TABLEAUX

- Tableau I.1. Identification et classement des tâches …………………………… 39
- Tableau I.2. Matrice d’antériorité …………………………………………………… 42
- Tableau I.3. Délai de réalisation du projet ………………………………………… 43
- Tableau I.4. Détermination des dates au plus tôt, datent au plus tard, marge
totale et marge libre …………………………………………………………………… 45
- Tableau I.5. Calendrier de réalisation du projet ………………………………….. 47
- Tableau II.1. Description lettre de demande d’adhésion ………………………. 56
- Tableau II.2. Description d’adhésion aux Statuts et acte d’apports …………. 57
- Tableau II.3. Description du contrat de cession entre créateur et SOCODA
COOP-CA ………………………………………………………………………………… 58
- Tableau II.4. Description des relevés des œuvres déclarées …………………… 58
- Tableau I.1. Tableau de scenario du processus de déclaration ………………. 68
- Tableau I.2. Tableau de scenario du processus de taxation et paiement ….. 69
 1

INTRODUCTION
1. Généralités

Depuis la nuit du temps, le monde développe des innovations dans

le but d’alléger les tâches et d’améliorer les conditions de travail de
l’homme. L’inquiétude majeure à ce niveau est de réorganiser son
environnement et cela sous-entend une organisation informationnelle solide.

Actuellement, le monde informatique entre dans une ère où on doit

traiter des données massives et des calculs lourds. Avec l’évolution de la
technologie, nous sommes obligés de travailler avec d’énormes quantités de
mémoires et des processeurs puissants pour que les traitements se fassent
dans un temps record. Or, une méthode parmi tant d'autres a été trouvée
depuis lors avec la construction de système de distribution de stockages et
de traitements de données qui est : le système distribué.

D’autre part, on veut parfois profiter de cette solution à tout

moment et n’importe où, d’où le fait de l’utiliser en tant que service à
distance par des applications à travers le web qui est accédé directement
au serveur de distribution.

On a donc évoqué ce mémoire intitulé « Mise en œuvre d’une

architecture web dans un système distribuée pour la gestion des droits
d’auteur avec comme cas d’étude la SOCODA COOP-CA » qui finalise une
implémentation d’une architecture web dans un système distribué pour que
des utilisateurs puissent employer les fonctionnalités de traitements de
données distribués à travers Internet.

2. Problématique

Comme dit ci-haut, le monde développe des innovations dans le

but d'alléger les tâches et d'améliorer les conditions de travail de l'homme.
L'évolution d'une société aujourd'hui est aussi conditionnée par son évolution
technologique.

En République Démocratique du Congo, dans plusieurs secteurs

notamment l'économie, la finance, la sécurité, etc., l'avènement de la
technologie a facilité les exécutions des tâches avec le traitement
automatique des informations.

Mais un constat a été fait au niveau des plusieurs domaines, entre

autre la gestion collective des droits d’auteur, qu'il y a carence des logiciels
appropriés répondant à certains besoins spécifiques touchant cette gestion.
Au cours de notre passage à la Société Congolaise des Droits d’Auteur et des
 2

Droits Voisins, « SOCODA COOP-CA » en sigle, nous nous sommes rendu

compte que la société accusait des nombreuses difficultés particulièrement
dans la gestion des artistes sociétaires, adhérents et les orphelins, la
communication entre les entités basées à l’intérieur du pays, et surtout
l'absence d'un dispositif informatique sur mesure pour cette gestion.

Parmi ces difficultés, nous citons notamment :

- La communication lente ou presque inexistante entre les entités ;

- L’adhésion compliquée pour les artistes résidant hors de la ville de
Kinshasa ;
- Les erreurs et omissions lors des traitements des dossiers ;
- La non informatisation des entités et des délégations provinciales ;
- La perte de temps lors de la recherche d’informations sur les artistes ;

Ainsi, pour mieux percevoir l'objet abordé afin de solutionner les

problèmes sus évoqués, nous nous sommes proposé de répondre aux
questions suivantes :

• L'apport des nouvelles technologies de l'information et de la

communication aurait-il un impact sur l'efficacité et le rendement au sein
de la SOCODA COOP-CA ?
• Quel est le mécanisme à appliquer par la SOCODA COOP-CA pour la
conservation des informations et leur utilisation au moment opportun ?

3. Hypothèses du sujet

L’hypothèse étant une réponse provisoire à une question posée

dans notre problématique, nous allons essayer au travers de notre réponse de
confirmer ou d’infirmer les questions posées à la fin de la présente étude.

En vue de remédier aux inquiétudes soulevées au travers des

questions posées ci-haut, nous pensons qu’il y aura un moyen facile de
traitement des informations automatiques, le partage des ressources
matérielles et logicielles qui seront adaptées à la gestion efficace et
efficience au sein de la SOCODA COOP-CA.

Un dispositif informatique apporterait la précision, la fiabilité et la

rapidité dans l'exécution des tâches. En outre, la mise en place d’une
architecture web permettrait non seulement d’identifier et d’enregistrer les
artistes distants voulant adhérer à la SOCODA, mais aussi de bien garder leurs
données sans redondances.

Aussi, l'utilisation de l'outil informatique pour la SOCODA COOP-CA

conserverait les données utiles dans une base des données et cela pour une
 3

utilisation ultérieure et une bonne prise des décisions sur les éventuelles
données, mais donnerait également la certitude de protéger ces données
contre toute malveillance.

4. Choix et intérêt du sujet

4.1. Choix du sujet

Le choix de ce sujet a été motivé par le souci d’arriver à

développer un site web dynamique pour la bonne gestion des artistes au sien
de la société SOCODA COOP-CA.

4.2. Intérêt du sujet

L’intérêt du présent sujet est triple :

• Sur le plan personnel, ce travail nous permet d’approfondir nos

connaissances et surtout de concilier les théories apprises à la pratique
avec un cas concret ;
• Sur le plan scientifique, le fond et la forme du présent travail ne
manqueront pas d’être utilisés par d’autres chercheurs comme source
référentielle dans leurs investigations ;
• Sur le plan environnemental, par le présent travail, la société SOCODA
COOP-CA sera dotée d’un outil informatique lui permettant de résoudre
les tâches liées à l’identification, inscription des artistes, bref ça facilitera
la gestion des artistes au sein de cette dernière.

5. Délimitation du travail.

Délimiter un travail scientifique signifie définir son champ d’étude

afin d’éviter des hypothèses et des conclusions trop hâtives et spéculatives.

• Dans le temps, nous avons pris en compte les informations allant de l’an
2019 jusqu’au mois de février 2022 ;
• Dans l’espace, nous sommes intéressé à la Société Congolaise des Droits
d’Auteur et des Droits Voisins, « SOCODA COOP-CA » en sigle, sise avenue
KIDISHO N°03 (Place des Evolués) dans la commune de la Gombe.

6. Méthodes et techniques utilisées

6.1. Méthodes utilisées

Tout chercheur se focalise sur une méthode susceptible de l’orienter

à atteindre son objectif et résoudre le problème qu’il étudie dans son travail ;
en d’autres termes, on peut dire que les méthodes sont des voies qui
 4

permettent au chercheur d’atteindre l’explication du phénomène à étudier

et les résultats escomptés. 1

- Méthode analytique : Elle nous a permis d’analyser en détail des données

récoltées durant la période de recherche ;
- PERT : (Program Evaluation and Review Technique) c’est une méthode
conventionnelle utilisable en gestion de projet d’ordonnancement. Cette
méthode nous a servi à suivre et contrôler l’évolution et l’avancement de
notre projet, à évaluer la durée d’exécution ainsi que le coût de son
implantation.
- UP (Unified Process) : se définit comme un processus de développement
logiciel itératif, centré sur l'architecture, piloté par des cas d'utilisation et
orienté vers la diminution des risques.

6.2. Techniques utilisées

Parmi les techniques, les suivantes sont celles dont nous nous
sommes servies dans la collecte de données :

a. Technique d'interview : elle nous a aidé à rassembler les données par un

jeu des questions réponses auprès de nos interlocuteurs ;
b. Technique documentaire : nous a permis la consultation des ouvrages et
tout autre document susceptible de contenir des informations utile afin de
pouvoir mieux éclairer notre lanterne ;
c. Technique d’observation : elle consiste à faire une analyse personnelle
après avoir observé et palpé le fonctionnement du système
d’information. Grâce à cette dernière nous sommes descendu sur terrain
pour assimiler ce que font les acteurs afin de comprendre et tirer les
conséquences.

7. Etat de la question

Nul n'ignore qu'il n'existe de sujet de recherche qui est vraiment

neufs, autrement dit, jamais traité.

Cependant, nous admettons que les travaux malgré qu'ils peuvent

avoir de ressemblances dans leurs formulations, ils se démarquent dans leurs
délimitation spatio-temporelles d'une part mais aussi dans leurs objectif de
l'autre part.

En effet, pour ce qui concerne notre cas, la mise en œuvre d’une

application dans un système distribué, a plus d'une fois fait l'objet d'étude
complexe. En titre d'exemple nous citons :

1 OSOKONDA, Cours des méthodes de Recherche en Sciences sociales(MRS), L1 INFO,

ISS/KIN, 2020-2021
 5

- En 2013, Monsieur Ernest EYEME LENDU de l'ISIPA en étudiant sur le sujet de

la mise en place d'un LAN avec connexion internet au sein d'une
entreprise privée cas de SYNERGY GROUP. Au cours de ses recherches il a
voulu savoir si la mise en place d'un réseau LAN avec connexion internet
facilitera la communication dans une entreprise. Après analyse, il arriva a
confirmé que cette entreprise pouvait échanger les données ainsi il joint
le système de connexion internet pour lui assurer l'échange de données
entre différentes directions ; 2
- En 2014, Monsieur BALOLA NDUSHA Moïse dans son travail intitulé
« conception et développement d'une application pour la gestion des
artistes et de leurs œuvres cas de la division provinciale de la culture et
des arts », a traité de la gestion des artistes, du bien-fondé de
l’informatisation dans un domaine où la mise en place d’un dispositif
informatique sur mesure demeure un mythe. Dans son étude, il a vu que
mettre en place un système informatique pour la gestion des artistes
permet d’avoir les informations sur le mouvement de ces derniers, ainsi
que la valeur liée à chacune de leur œuvre ; 3
- Dans son ouvrage intitulé « Principes et mécanismes de base de système
distribué », le Professeur Ousmane THIARE dit « les systèmes distribués
rendent des services, offrent des moyens aux applications réparties et
permettent d’assurer la communication et le partage d’informations ».4

Toutes ces études (travaux et ouvrage) ont fait des analyses sur la
gestion des artistes et le système distribué sous différents aspects. Pour ce qui
est du présent travail, il va alors nous permettre non seulement d'analyser la
gestion des artistes dans un système distribué, mais aussi de trouver un outil
pouvant permettre à la société de gérer efficiemment ce système.

8. Difficultés rencontrées

Toute conception que ce soit d’un logiciel ou d’un travail est

toujours butée à plusieurs difficultés. Pour le présent travail, nous avons
accusé plusieurs difficultés d’ordre matériel non seulement pour la récolte des
données, mais aussi pour l’obtention de certains ouvrages afin de mener au
mieux notre étude.

2 EYEME LENDU Ernest, Mise en place d'un LAN avec connexion internet au sein d'une
entreprise privée cas de SYNERGY GROUP, ISIPA-Kinshasa, 2013-2014, inédit
3 BALOLA NDUSHA Moïse, Conception et développement d'une application pour la gestion

des artistes et de leurs œuvres « cas de la division provinciale de la culture et des arts », UCB-
Bukavu, 2013-2014, inédit
4 Prof. Ousmane THIARE, Principes et mécanismes de base de système distribué, Université

Saint-Louis, Sénégal, 2020

 6

9. Subdivision du travail

Hormis l’introduction et la conclusion, le présent travail est subdivisé

en trois grandes parties à savoir :

Première partie : Notion fondamentale où nous allons parler des notions dont
nous traitons dans le présent travail

Chapitre 1 : Système distribué

Chapitre 2 : Architectures orientées services

Deuxième partie : Etude préalable et Cadrage du projet où nous allons faire

l’étude de notre existant puis faire le cadrage de notre projet.

Chapitre 1 : Cadrage du projet

Chapitre 2 : Analyse et spécification des besoins

Troisième partie : Notion opérationnelle qui a pour objectif la conception et

modélisation du système et l’implémentation du nouveau système

Chapitre 1 : Conception et modélisation du nouveau système

Chapitre 2 : Implémentation du nouveau système
 7

PREMIERE PARTIE :
NOTION FONDAMENTALE
 8

CHAPITRE I : SYSTEME DISTRIBUE

I.1. Introduction sur le système distribué

Vue l'augmentation de leurs ressources, les entreprises multi-sites

doivent pouvoir compter sur une infrastructure informatique hautes
performances, à même d'assurer l'exécution transparente de leurs processus
informatiques et une communication fiable, en interne comme en externe.

Les systèmes distribués proposent des solutions d'améliorer l'agilité

globale du système d'information au travers des architectures orientées
services.

Ces systèmes permettent aussi de mettre en place des

architectures informatiques permettant d'améliorer les performances ainsi
que la disponibilité des systèmes informatiques.

Dans le présent chapitre, nous décrivons les principes et le

fonctionnement des systèmes distribués, tout en présentant leurs
caractéristiques, avantages ainsi que leur mode de communication et sa
conception.

I.2. Définition de concepts.

a. Système distribué

Un système distribué est un système disposant d'un ensemble

d'entités communicantes, installées sur une architecture d'ordinateurs
indépendants reliés par un réseau de communication, dans le but de
résoudre en coopération une fonctionnalité applicative commune.5

Autrement dit, un système distribué est défini comme étant un

ensemble des ressources physiques et logiques géographiquement dispersées
et reliées par un réseau de communication dans le but de réaliser une tâche
commune. Cet ensemble donne aux utilisateurs une vue unique des données
du point de vue logique.

Un système distribué est un ensemble d'entités autonomes de calcul

interconnectées et qui peuvent communiquer.6

5 C. Gavoille, « Algorithmes distribués », LaBRI : Université de Bordeaux, Mars 2019

6 Idem
 9

b. Système reparti

Un système réparti est un ensemble de machines autonomes

connectées par un réseau, et équipées d’un logiciel dédié à la coordination
des activités du système ainsi qu’au partage de ses ressources.7

C’est un système qui s’exécute sur un ensemble de machines sans

mémoire partagée, mais que pourtant l’utilisateur voit comme une seule et
unique machine.8

c. Système centralisé

Un système centralisé est un système qui utilise une architecture

client/serveur où un ou plusieurs nœuds clients (ordinateur, smartphone, etc.)
sont directement connectés à un serveur central. Il s’agit du type de système
le plus couramment utilisé dans de nombreuses organisations où un client
envoie une demande à un serveur d’entreprise et reçoit la réponse.9

I.3. Type des systèmes distribués

I.3.1. Système embarqué distribué

Le système distribué a été toujours largement sur le côté

physiquement distribué où les nœuds sont fixés et ont une connexion plus ou
moins permanente et de haute qualité à un réseau. Cette stabilité est due
aux nombreuses techniques disponibles qui nous donnent l'impression que
parfois les choses tournent mal. Ces techniques comme le masquage et la
récupération de l'échec, cachant l'aspect distribué des nœuds permettent
effectivement aux utilisateurs et aux applications de croire en la fiabilité de
ces systèmes.10

I.3.2. Système d'information distribué

Les systèmes d'information distribués constituent une autre classe

importante de systèmes distribués, très présents dans les organisations. Ces
systèmes ont pour noyau quelques applications en réseau. Le serveur
exécutant l'application est connecté au réseau et les autres systèmes du
réseau peuvent communiquer avec ce serveur via des clients. Ces clients
enverront une requête au serveur pour exécution et recevront et traiteront la
réponse du serveur.

7 F. SINGHOFF, Cours d’Introduction aux systèmes repartis, Université de Brest, 2015

8 Idem
9 fr.acervolima.com, consulté le 10 juillet 2022 à 15h12’
10 L. Junon, « Les systèmes distribués », ISEP, 2009
 10

L'intégration à un niveau inférieur permet aux clients d'emballer

plusieurs demandes en une seule requête plus importante et de l'exécuter en
tant que transaction distribuée. L'idée clé était que toutes ou aucune des
demandes seraient exécutées.11

I.3.3. Systèmes informatiques distribués

C'est une classe de systèmes distribués qui prédominent dans les

tâches de calcul de haute performance. On peut faire une distinction
générale entre deux sous-groupes, les systèmes informatiques en cluster
(cluster computing) et les systèmes informatiques en grille (grid computing).

La différence c’est qu’un « cluster computing » est un groupe de

systèmes travaillant ensemble en une seule unité. Par exemple quatre
serveurs de base de données regroupés en un seul serveur de base de
données. Si un système du cluster tombe en panne, les autres serveurs ou
cluster 29 sont toujours disponibles pour effectuer le travail. On peut mettre à
l'échelle la performance du travail en ajoutant plus de ressources au cluster.
Le grid computing est une extension du cluster computing, dans le but
d’élargir la capacité de calcul et de recueil de données. Il est plus
hétérogène que le cluster computing parce qu’il utilise des entités très variées
comme ressources (capteurs, imprimantes, ordinateurs, appareils mobiles,
etc.).12

I.4. Intérêts et inconvénients des systèmes distribués

Comme dans la plus part des technologies, la conception de

systèmes distribués a des intérêts et inconvénients dont voici quelques-uns ci-
dessous. 13

a. Intérêts

- Partage des ressources (données, programme, services) qui permet un

travail collaboratif ;
- Accès distant, c'est-à-dire qu'un même service peut être utilisé par
plusieurs acteurs situés à des endroits différents ;
- Amélioration des performances : la mise en commun de plusieurs unités
de calcul permet d'effectuer des calculs parallélisables en des temps
plus courts ;
- Confidentialité : les données brutes ne sont pas disponibles partout au
même moment, seules certaines vues sont exportées ;

11 L. Junon, « Les systèmes distribués », ISEP, 2009

12 Idem
13 G. Coulouris, J. Dollimore, T. Kindburg, G, Blair, « Distributed systems : Concepts and Design

», Addison-Wesley : United States of America, 2012

 11

- Ouverture. C'est la capacité d'étendre le système en ajoutant de

nouvelles ressources.
- Parallélisme : plusieurs processus peuvent s'exécuter simultanément sur
différents ordinateurs du réseau.
- Évolutivité : il y a la possibilité d'ajouter de nouvelles propriétés et
méthodes ;
- Tolérance aux pannes : La présence de plusieurs ordinateurs permet la
duplication des informations et la résistance à certaines erreurs
matérielles et logicielles ;
- Transparence. Les utilisateurs bénéficient d'un accès complet aux
ressources du système, tandis que dans le même temps, les
informations sur la répartition des ressources dans le système leur sont
cachées
- Réalisation des systèmes à grande capacité d'évolution ;
- Augmentation de la fiabilité grâce à la duplication de machines ou de
données, ce qui induit à une réalisation des systèmes à haute
disponibilité.

b. Inconvénients

Les systèmes distribués présentent également un certain nombre

d'inconvénients :

- Complexité... Il est beaucoup plus difficile de comprendre et d'évaluer

les propriétés des systèmes distribués en général, et ils sont plus difficiles
à concevoir, tester et maintenir.
- Sécurité... En règle générale, le système est accessible à partir de
plusieurs machines différentes, les messages sur le réseau peuvent être
consultés et interceptés. Par conséquent, dans un système distribué, il
est beaucoup plus difficile de maintenir la sécurité.
- Contrôlabilité... Le système peut être constitué de différents types
d'ordinateurs sur lesquels différentes versions de systèmes d'exploitation
peuvent être installées. Les erreurs sur une machine peuvent se
propager à d'autres machines de manière imprévisible.
- Imprévisibilité ... La réaction des systèmes distribués à certains
événements est imprévisible et dépend de la pleine charge du
système, de son organisation et de la charge du réseau.
- S’il y a un problème au niveau du réseau, le système marche mal ou ne
marche plus
- Si le serveur plante, le système ne peut fonctionner
 12

I.5. Caractéristiques des systèmes distribués

La performance d'un système distribué se révèle dans ses

caractéristiques. Ces caractéristiques ci-dessous devraient être prises en
compte lors de la conception d'un système distribué.

I.5.1. Interopérabilité

L'interopérabilité est une caractéristique importante qui désigne la

capacité à rendre compatibles deux systèmes quelconques. A son tour, la
compatibilité est la capacité qu'ont deux systèmes à communiquer sans
ambiguïté.

En effet, l'interopérabilité vise à réduire le vrai problème de

l'hétérogénéité en la masquant par l'utilisation d'un protocole unique de
communication. Pour les échanges des messages, il faut utiliser des standards
qui cachent les différences entre les différentes plateformes.

I.5.2. Partage des ressources

Le partage des ressources est le facteur principal de motivation

pour construire les systèmes répartis. Des ressources telles que des
imprimantes, des dossiers, des pages Web ou des disques de base de
données sont contrôlées par des serveurs du type approprié. Par exemple, les
serveurs Web contrôlent des pages Web et d'autres ressources
d'enchaînement. Des ressources sont consultées par des clients - par
exemple, les clients du web des serveurs s'appellent généralement les
browsers (navigateurs).

I.5.3. Ouverture

Cette caractéristique fait mention de l'extensibilité dans la mesure

où des composants peuvent être ajoutés, remplacés ou supprimés dans un
système distribué sans en affecter les autres. Et lorsque nous parlons des
composants, nous voyons les matériels et les logiciels. L'ouverture nécessite
que les interfaces logicielles soient documentées et accessibles aux
développeurs d'applications.

I.5.4. Expansibilité

Nous disons qu'un système distribué est expansible lorsque les

modifications du système et des applications ne sont pas nécessaires quant à
l'augmentation de la taille de ce système.
 13

I.5.5. Performance

Dans ce cas, le système doit s'adapter à bien fonctionner même

quand le nombre d'utilisateurs ou de ressources augmentent.

I.5.6. Transparence

Pour un utilisateur, un système distribué doit ressembler exactement

comme un système non-distribué.

La transparence cache aux utilisateurs l'architecture, la distribution

des ressources, le fonctionnement de l'application du système distribué pour
apparaître comme une application unique cohérente.

I.5.7. Sécurité

Le problème de sécurité se pose dans tout système informatique.

Dans un système distribué, les ressources doivent être protégées contre des
utilisations abusives et malveillantes, en particulier, le problème de piratage
des données sur le réseau de communication. Outre, les connexions doivent
être sécurisées par authentification avec les éléments distants ainsi que les
messages circulant sur ce réseau doivent être cryptés en vue d'éviter des
conséquences graves.

I.6. Modèle d’architecture d’un système distribué

Les systèmes distribués relèvent généralement de l’un des deux

différents modèles d’architecture de base :

1. Client-serveur

L’architecture client-serveur est un modèle informatique dans lequel

le serveur héberge, fournit et gère la plupart des ressources et des services
demandés par le client. Il est également connu sous le nom de modèle
informatique de réseau ou réseau client-serveur car toutes les demandes et
tous les services sont fournis sur un réseau. Elle a d’autres systèmes connectés
sur un réseau où les ressources sont partagées entre les différents ordinateurs.
 14

Figure I.1. Modèle d’architecture client-serveur

En règle générale, l’architecture client-serveur est organisée de

manière à ce que les clients soient souvent situés sur des postes de travail ou
sur des ordinateurs personnels, tandis que les serveurs sont situés ailleurs sur le
réseau, généralement sur des machines plus puissantes. Un tel modèle est
particulièrement utile lorsque les clients et le serveur effectuent des tâches de
routine. Par exemple, dans le traitement des données hospitalières, un
ordinateur client peut être occupé à exécuter un programme d’application
pour entrer des informations sur le patient, tandis que l’ordinateur serveur
peut exécuter un autre programme pour récupérer et gérer la base de
données dans laquelle les informations sont stockées en permanence.

a) Composants de l’architecture client-serveur

Essentiellement, trois composants sont nécessaires pour que

l’architecture client-serveur fonctionne. Les trois composants sont les postes
de travail, les serveurs et les périphériques réseau.

• Postes de travail : Les postes de travail sont également appelés

ordinateurs clients. Les postes de travail fonctionnent comme des
subordonnés aux serveurs et leur envoient des demandes d’accès aux
fichiers et bases de données partagés. Un serveur demande des
informations au poste de travail et remplit plusieurs fonctions en tant que
référentiel central de fichiers, de programmes, de bases de données et
de stratégies de gestion. Les postes de travail sont régis par des
stratégies définies par le serveur.
• Serveurs : les serveurs sont définis comme des périphériques de
traitement rapide qui agissent comme des référentiels centralisés de
fichiers, de programmes, de bases de données et de stratégies réseau.
Les serveurs disposent d’un espace de stockage énorme et d’une
 15

mémoire robuste pour traiter plusieurs demandes, approchant

simultanément à partir de différents postes de travail. Les serveurs
peuvent remplir simultanément de nombreux rôles, tels que serveur de
messagerie, serveur de base de données, serveur de fichiers et
contrôleur de domaine, dans l’architecture client-serveur.
• Périphériques réseau : Les périphériques réseau sont un support qui
connecte les postes de travail et les serveurs dans une architecture
client-serveur. De nombreux périphériques réseau sont utilisés pour
effectuer diverses opérations sur le réseau. Par exemple, un
concentrateur est utilisé pour connecter un serveur à différents postes de
travail. Les répéteurs sont utilisés pour transférer efficacement des
données entre deux appareils. Les ponts sont utilisés pour isoler la
segmentation du réseau.

b) Types d’architecture client-serveur

Les fonctionnalités de l’architecture client-serveur sont à différents

niveaux.

• Architecture à 1 niveau

Figure I.2. Architecture client-serveur à un niveau

Dans cette catégorie d’architecture client-serveur, l’architecture

contient toutes sortes de paramètres, tels que les paramètres de
configuration et la logique marketing, sur un seul appareil. Bien que la
diversité des services offerts par l’architecture à 1 niveau en fasse l’une des
sources fiables, la gestion d’une telle architecture est difficile. Cela est
principalement attribuable à la variance des données. Il en résulte souvent la
réplication du travail. L’architecture à 1 niveau se compose de plusieurs
couches, telles que la couche de présentation, la couche métier et la
 16

couche de données, qui sont combinées à l’aide d’un progiciel unique. Les
données présentes dans cette couche sont généralement stockées dans des
systèmes locaux ou sur un lecteur partagé.

• Architecture à deux niveaux

Figure I.3. Architecture client-serveur à deux niveaux

Cette architecture a le meilleur environnement. Dans cette

architecture, l’interface utilisateur est stockée du côté du client et la base de
données est stockée sur le serveur, tandis que la logique de base de données
et la logique métier sont conservées du côté du client ou du côté du serveur.

L’architecture à 2 niveaux est plus rapide que l’architecture à 1

niveau ; En effet, l’architecture à 2 niveaux n’a pas d’intermédiaire entre le
client et le serveur. Il est souvent utilisé pour éviter la confusion entre les
clients. L’un des exemples populaires d’architecture à 2 niveaux est le
système de réservation de billets en ligne.

• Architecture à trois niveaux

Figure I.4. Architecture client-serveur à trois niveaux

Contrairement à l’architecture à 2 niveaux qui n’a pas

d’intermédiaire, dans l’architecture client-serveur à 3 niveaux, un middleware
se trouve entre le client et le serveur. Si le client place une demande pour
 17

récupérer des informations spécifiques à partir du serveur, la demande sera

d’abord reçue par le middleware. Il sera ensuite envoyé au serveur pour
d’autres actions. Le même schéma sera suivi lorsque le serveur enverra une
réponse au client. Le cadre de l’architecture à 3 niveaux est classé en trois
couches principales : couche de présentation, couche d’application et
couche de base de données.

Les trois couches sont contrôlées à différentes extrémités. Alors que

la couche de présentation est contrôlée sur le périphérique du client, le
middleware et le serveur gèrent respectivement la couche application et la
couche base de données. En raison de la présence d’une troisième couche
qui assure le contrôle des données, l’architecture à 3 niveaux est plus
sécurisée, a une structure de base de données invisible et assure l’intégrité
des données.

• Architecture multicouche

Figure I.5. Architecture client-serveur multicouche

L’architecture multicouche est également appelée architecture

multiniveau. C’est la forme à l’échelle des trois autres types d’architecture.
Cette architecture permet de localiser chaque fonction en tant que couche
isolée qui inclut la présentation, le traitement des applications et la gestion
des fonctionnalités de données. Généralement, elle est utilisée lorsqu’une
application ou un serveur doit transmettre des demandes à des services
d’entreprise supplémentaires sur le réseau.

2. Peer-to-Peer

Il n’y a pas de machines supplémentaires utilisées pour fournir des

services ou gérer des ressources. Les responsabilités sont uniformément
réparties entre les machines du système, appelées pairs, qui peuvent servir de
client ou de serveur.
 18

Figure I.6. Architecture peer-to-peer

L’architecture peer-to-peer implique deux ordinateurs ou plus qui

regroupent diverses ressources périphériques telles que des imprimantes et
des lecteurs de DVD. Ces ressources partagées sont disponibles sur chaque
ordinateur du réseau. Dans cette architecture, chaque ordinateur se
comporte à la fois comme client et serveur, et il communique directement
avec les autres ordinateurs.
 19

CHAPITRE II : ARCHITECTURES ORIENTEES SERVICES

La conception d’un programme informatique s’effectue
conformément à un paradigme de programmation. Ce dernier est un style
de programmation informatique qui traite de la manière dont les solutions
aux problèmes doivent être formulées dans un langage de programmation.14

Un paradigme de programmation définit un concept pour

représenter les modes et des techniques pour traiter ce concept. Dès lors,
plusieurs paradigmes ont vu le jour et ayant évolué du binaire, à différents
modèles de programmation puis à l’architecture orientée service où nous
allons consacrer un aperçu dans le présent chapitre.

II.1. Définition

a. Architecture

En informatique, une architecture désigne la structure générale

inhérente à un système informatique, l'organisation des différents éléments du
système (logiciels et/ou matériels et/ou humains et/ou informations) et des
relations entre les éléments.15

Cette structure fait suite à un ensemble de décisions stratégiques

prises durant la conception de tout ou partie du système informatique, par
l'exercice d'une discipline technique et industrielle du secteur de
l'informatique dénommée elle aussi architecture, et dont le responsable est
l'architecte informatique.

b. Service

En informatique, un service est une unité autonome de

fonctionnalité logicielle, ou d'un ensemble de fonctionnalités, conçue pour
réaliser une tâche précise comme récupérer des informations ou exécuter
une opération. Il contient les intégrations de code et de données nécessaires
pour exécuter une fonction métier distincte et complète. Vous pouvez y
accéder à distance, et interagir avec lui ou le mettre à jour de manière
indépendante.16

14 Houda EL BOUHISSI, Cours SOA et Services web, Université Abderrahmane Mira de Bejaia,
inédit, 2020-2021
15 www.wikipedia.com, consulté le 07 août 2022 à 09h00’
16 https://www.redhat.com, consulté le 07 août 2022 à 10h05’
 20

Hauda EL BOUHICI le définit comme étant un composant logiciel

qui exécute une action pour le compte d’un client, il traduit le niveau logique
d’accès aux traitements, plutôt que le niveau physique d’implémentation.17

c. Architecture orientée service

L'architecture orientée service (ou SOA, Service-Oriented

Architecture) est un modèle de conception qui rend des composants
logiciels réutilisables, grâce à des interfaces de services qui utilisent un
langage commun pour communiquer via un réseau.18

En d'autres termes, l'architecture SOA permet à des composants

logiciels déployés et gérés séparément de communiquer et de fonctionner
ensemble sous la forme d'applications logicielles communes à différents
systèmes.

C’est aussi un style d’architecture distribuée qui permet de fournir

ou consommer un processus métier en tant que service.19

II.2. Principes généraux d’une architecture orientée services

Il n'existe pas à proprement parler de spécifications officielles d'une

architecture SOA, néanmoins les principales notions fédératrices
que l'on retrouve dans une telle architecture sont les suivantes :20

- La notion de service, c'est-à-dire une fonction encapsulée dans un

composant que l'on peut interroger à l'aide d'une requête composée
d'un ou plusieurs paramètres et fournissant une ou plusieurs réponses.
Idéalement chaque service doit être indépendant des autres afin de
garantir sa réutilisabilité et son interopérabilité.
- La description du service, consistant à décrire les paramètres d'entrée
du service et le format et le type des données retournées.
- Le principal format de description de services est WSDL (Web Services
Description Language), normalisé par le W3C.
- La publication (en anglais advertising) et la découverte (discovery) des
services. La publication consiste à publier dans un registre (en
anglais registry ou repository) les services disponibles aux utilisateurs,
tandis que la notion de découverte recouvre la possibilité de rechercher
un service parmi ceux qui ont été publiés. Le principal standard utilisé

17 Houda EL BOUHISSI, Cours SOA et Services web, Université Abderrahmane Mira de Bejaia,
inédit, 2020-2021
18 https://www.redhat.com, consulté le 07 août 2022 à 12h30’
19 Houda EL BOUHISSI, Idem
20 https://web.maths.unsw.edu.au, consulté le 07 août 2022 à 13h01’
 21

est UDDI (Universal Description Discovery and Integration), normalisé par

l'OASIS.
- L'invocation, représentant la connexion et l'interaction du client avec le
service. Le principal protocole utilisé pour l'invocation de services
est SOAP (Simple Object Access Protocol).

II.3. Avantages d’une architecture orientée service21

Une architecture orientée services permet d'obtenir tous les

avantages d'une architecture client-serveur et notamment :

• Une modularité permettant de remplacer facilement un composant

(service) par un autre ;
• Une réutilisabilité possible des composants (par opposition à un système
tout-en-un fait sur mesure pour une organisation) ;
• De meilleures possibilités d'évolution (il suffit de faire évoluer un service
ou d'ajouter un nouveau service) ;
• Une plus grande tolérance aux pannes ;
• Une maintenance facilitée ;
• Les fonctions de l'architecture SOA sont à la portée de tous.

II.4. Les concepts de base

II.4.1. SOA et service

Le service est le concept clé de la SOA. Il rassemble une ou

plusieurs activités métier réelles que l'on peut associer à des opérations, c'est-
à-dire des fonctionnalités offertes par le service.

Un service est une unité autonome de logiciel qui effectue une

tâche spécifique. Il comporte trois composants : une interface, un contrat et
une implémentation. L’interface définit comment un fournisseur de services
exécutera les demandes d’un consommateur de services, le contrat définit
comment le fournisseur de services et le consommateur de services doivent
interagir, et l’implémentation est le code de service lui-même. Étant donné
que l’interface d’un service est distincte de son implémentation, un
fournisseur de services peut exécuter une demande sans que le
consommateur de services sache comment il le fait; le consommateur de
services ne s’inquiète que de la consommation de services.22

Il existe deux types de services, qui sont :

• Métier : issu du cahier des charges,

21 Idem
22 www.mulesoft.com, le 07 août 2022 à 15h10’
 22

• D’architecture : issu pendant l’établissement de l’architecture de

l’application (généralement implémenté par un ou plusieurs
services métiers). Et le service doit respecter les propriétés
suivantes :
❖ Couplage faible : Un service ne peut pas appeler un autre service. Il
délègue cette fonction à un traitement spécialisé dans
l’enchaînement (fonction d’orchestration). Un service est activable
indépendamment de sa technologie. Pour ce faire, l’activation se
réalise par l’envoi (et la réception) d’un message XML. Un service
peut être activité suivant un mode asynchrone. Dans ce cas, le
service s’abonne à un événement auprès d’une fonction
d’orchestration.
❖ Expose à un contrat d’utilisateur : Un service expose un contrat
d’utilisation décrit en deux parties. Une partie abstraite qui déclare
les messages d’entrée et de réponse du traitement offert. Une
partie concrète qui décrit les standards et protocoles techniques
utilisés pour l’activation du service10. On nomme aussi le contrat
d’utilisation par le terme d’interface de service.
❖ Respecte le patron (pattern) d’architecture : Le pattern
d’architecture SOA consiste à créer une architecture applicative
qui décompose les traitements sous la forme de services rattachés
à des paquets de classes. Ces paquets forment des Catégories
(objet métier, sujet métier), chacune dotée d’une façade d’accès
qui contient l’ensemble des services qu’elle expose (on parle aussi
de port). Un service a le droit d’interagir uniquement avec les
classes de sa catégorie.

II.4.2. Web service

Un service web est un programme informatique permettant la

communication et l'échange de données entre applications et systèmes
hétérogènes dans des environnements distribués.23

Selon, le W3C (World Wide Web Consortium), c’est un système

logiciel conçu pour supporter les interactions entre applications à travers le
réseau.24

23KANYINDA, API et Web service, Stage académique, ISS-KIN, 2022, inédit

24BOUKHEDOUMA Saida, « Adaptation et Restructuration de Modèles de Processus Workflow
dans un Contexte Inter-Organisationnel », Thèse de Doctorat, Université de Nantes, 2015,
inédit
 23

II.4.2.1. Caractéristiques des Services Web25

Un certain nombre de caractéristiques représentant en même

temps des atouts de la technologie des services Web sont recensés dans la
littérature à travers une panoplie de travaux, nous rappelons celles
présentées dans :

- L’interopérabilité : c’est la capacité des services Web à interagir avec

d’autres composants logiciels via des éléments XML et utilisant des
protocoles de l’Internet.
- La simplicité : les services Web réduisent la complexité des
branchements entre les participants. Cela se fait en ne créant la
fonctionnalité qu’une seule fois plutôt qu’en obligeant tous les
fournisseurs à reproduire la même fonctionnalité à chacun des clients
selon le protocole de communication supporté.
- Le couplage faible : l’architecture modulaire des services Web,
combinée au faible couplage des interfaces associées, permet
l’utilisation et la réutilisation de services qui peuvent être facilement
recombinés à différentes autres applications.
- L’hétérogénéité : les services Web permettent d’ignorer l’hétérogénéité
entre les différentes applications. En effet, ils décrivent comment
transmettre un message (standardisé) entre deux applications, sans
imposer comment construire ce message.
- L’auto-descriptivité : les services Web ont la particularité d’être auto-
descriptifs, c’est à dire capables de fournir des informations permettant
de comprendre comment les manipuler. La capacité des services à se
décrire par eux-mêmes permet d’envisager l’automatisation de
l’intégration de services.

II.4.2.2. Infrastructure des services web

L’infrastructure des services web se présente comme suit :

- SOAP (Simple Object Access Protocol) : assure la communication avec

et entre les services web ;
- WSDL (Web Services Description Language) : offre un schéma formel
des descriptions des services web ;
- UDDI (Universal Description, Discovery and Integration) : offre une
manière uniforme de définir les registres des services web et un schéma
uniformément extensible de descriptions des services web.

25 Idem
 24

Figure II.1. Infrastructure des services web

II.4.2.3. Types de services web

Nous avons deux types de services web :

- Services web 1.0 (Première génération) qui utilisent les infrastructures

standards UDDI, WSDL et SOAP ;
- Services web 2.0 (Deuxième génération) qui utilisent directement HTTP
au lieu d’une enveloppe SOAP, un URI pour nommer et identifier une
ressource, et les méthodes HTTP (POST, GET, PUT et DELETE) pour
effectuer les opérations CRUD (Create, Read, Update, Delete).

II.4.3. Approche Orientée Objet

Cette approche n’est rien d’autres une méthodologie permettant

la construction des systèmes d’information sous forme d’objets pour faciliter
l’implémentation du logiciel. SOA et approche orientée objet sont
complémentaires du fait qu’on utilise un principe de décomposition du
service sous la forme de méthodes attachées à des objets.

II.4.4. Les composants

Un composant est un élément d'un système rendant un service

prédéfini et capable de communiquer avec d'autres composants.
Ainsi, un composant logiciel est un élément d'un système logiciel.26

26 www.wikipedia.com, consulté le 08 août 2022 à 10h13’

 25

Les principaux composants et standards de la SOA sont illustrés

dans la figure ci-dessous27 :

Figure II.2. Les composants d’un service web

II.5. Définition des rôles

En ce qui concerne la définition des rôles dans une architecture

SOA, nous avons :

• Le fournisseur du service : appelé aussi « prestataire de service »,

désigne d'un point de vue conceptuel, la personne ou l'organisation
responsable juridiquement du service. D'un point de vue opérationnel,
les fournisseurs de services peuvent désigner le ou les serveurs qui
hébergent les services déployés.
• Le client (consommateur du service ou demandeur de services) :
représente une personne ou une organisation, cliente potentielle de
services. Du point de vue opérationnel, il représente l’application
cliente qui invoque le service.
• L’annuaire de services : appelé aussi registre, rassemble les descriptions
de tous les services publiés par les fournisseurs de services, afin de
faciliter la tâche de recherche du service adéquat au client.

27BOUKHEDOUMA Saida, « Adaptation et Restructuration de Modèles de Processus Workflow

dans un Contexte Inter-Organisationnel », Thèse de Doctorat, Université de Nantes, 2015,
inédit
 26

II.6. Les apports du SOA

II.6.1. Les apports métiers

La SOA a favorisé la découverte et la spécification de services

métiers au niveau de la modélisation des processus.

- L’entreprise expose des services métiers à des organisations tierces.

- L’entreprise intègre dans son propre système d’information des services
offerts par d’autres.

La SOA s’appuie sur des outils de management dont certaines

fonctionnalités sont directement destinées aux Maîtrises d’Ouvrage. Il est très
important de noter que les entreprises perçoivent l’intérêt du SOA dans un
contexte d’usage multipoints des services métiers.

II.6.2. Les apports techniques

Selon les différentes techniques, la SOA permet de (d’) :

- Rationaliser les développements orientés objets ;

- Contrôler les risques de couplage fort entre les méthodes des classes ;
- Intégrer un modèle d’architecture en couches indispensable pour la
qualité du logiciel.

II.7. Présentation générale du protocole SOAP28

SOAP représente l’acronyme de Simple Object Access Protocol (en

français, Protocole Simple d’Accès aux Objets). En fait, il s’agit
essentiellement d’un protocole d’échanges d’informations au sein d’une
architecture distribuée, et qui présente les caractéristiques générales
suivantes :

- ce protocole est écrit en XML ;

- il supporte les services concernant les appels de procédure distante
(Remote Procedure Call) aussi bien que les services d’échange de
messages (services) ;
- il est principalement déployé au-dessus du protocole de transport HTTP
- il est indépendant des plates-formes (platform-independant) ;
- il est indépendant des langages (language-independent).

Le fait que SOAP soit en XML est fondamental, car il rend SOAP
beaucoup plus attractif, notamment en termes de débuggage, que d’autres
protocoles tels que IIOP (Inter-ORB Protocol, assurant la communication entre

28 Article, Service Web (SOAP), Cours : NFE107 Urbanisation & Architecture des Systèmes
d’Information, 2008-2009.
 27

objets JAVA et CORBA), ORPC (Object Remote Procedure Call)

et JMRP (Java Remote Method Protocol utilisé par RMI), qui sont des
protocoles reposant sur des flux binaires, et donc plus difficiles à gérer.

II.7.1. Présentation et fonctionnement de SOAP

a. Présentation

SOAP est un protocole de RPC (Remote Procedure Call) permettant

d'invoquer des méthodes d'objets distants. Il s'appuie sur des standards très
connus. Il utilise XML pour définir les fonctions et les définitions disponibles. Il
prend en charge divers protocoles de transport, tels que HTTP et SMTP, ainsi
que différents formats comme MIME. Ces derniers sont très répandus sur de
multiples plates-formes, ce qui donne à SOAP une grande portabilité et
interopérabilité.

SOAP est une spécification non-propriétaire. Il n'est pas lié à un

protocole particulier. Il n'est pas non plus lié à un système d'exploitation ni au
langage de programmation.

Figure II.3. Structure d’un SOAP

b. Fonctionnement

La grammaire de SOAP procure un moyen d'accès aux objets par

appel aux méthodes à distance.

Les deux plus fortes fonctionnalités de SOAP sont sa simplicité et le

fait que tout le monde a accepté de l'utiliser.

• Coté client
 28

Le client envoie des messages au serveur correspondant à des

requêtes SOAP-XML enveloppés dans des requêtes HTTP. De même, les
réponses des serveurs sont des réponses HTTP qui renferment des réponses
SOAP-XML. Dans le processus client, l'appel de service est converti en une
requête SOAP qui est ensuite enveloppé dans une HTTP.

• Coté serveur

C'est légèrement plus complexe car il requiert un process listener

correspondant au processus serveur en attente de connexion cliente. Le
listener est souvent implémenté au travers d'un servlet qui s'exécute qui a
pour tâche d'extraire le message XML-SOAP de la requête HTTP, de le
désérialiser c'est à dire de séparer le nom de la méthode et les paramètres
fournis puis invoquer la méthode du service en conséquence. Le résultat de
la méthode est alors sérialisé, encodé HTTP et renvoyé au demandeur.

Figure II.4. Fonctionnement du protocole SOAP

II.7.2. Le protocole WSDL

WSDL est un langage de description standard. C'est l'interface

présentée aux utilisateurs. Il indique comment utiliser le service Web et
comment interagir avec lui. WSDL est basé sur XML et permet de décrire de
façon précise les détails concernant le service web tels que les protocoles, les
ports utilisés, les opérations pouvant être effectuées, les formats des messages
d'entrée et de sortie et les exceptions pouvant être envoyées.29

29 Idem
 29

Figure II.5. Protocole WSDL

a) Les fichiers WSDL

Un fichier WSDL contient sept éléments :

• Types: fournit la définition de types de données utilisées pour décrire les

messages échangés.
• Messages: représentent une définition abstraire (noms et types) des
données en cours de transmission.
• PortTypes: décrit un ensemble d'opérations. Chaque opération à zéro ou
un message en entrée, zéro ou plusieurs messages de sortie ou d'erreur.
• Binding: spécifie une liaison entre un <portType> et un protocole concret
(SOAP, HTTP...).
• Service: indique les adresses de port de chaque liaison.
• Port: représente un point d'accès de services défini par une adresse
réseau et une liaison.
• Opération: c'est la description d'une action exposée dans le port.

Le fichier WSDL est utilisé pour décrire en résumé ce que fait le

service Web et donne au client toutes les informations nécessaires pour se
connecter au service Web et utiliser toutes les fonctionnalités fournies par le
service Web.

Le fichier WSDL est écrit en XML. C’est en XML que le fichier peut
être lu par n’importe quel langage de programmation.

Par exemple, si l’application client était écrite en .Net, elle

comprendrait le fichier XML. De même, si l’application client était écrite dans
le langage de programmation Java, elle pourrait aussi interpréter le fichier
WSDL.
 30

Figure II.6. Fichiers WSDL

Avec le fichier WSDL qui est au format XML, et qui peut être compris
par n’importe quel langage de programmation, vous pouvez désormais faire
en sorte qu’une classe Java consomme le service Web .Net.

II.7.3. Le protocole UDDI

UDDI est un annuaire qui permet aux entreprises fournissant des

services Web de s'enregistrer et de publier les services web qu'elles offrent au
grand public.30

L'idée principale d'UDDI est de standardiser le format des entrées

d'entreprise et de services dans un annuaire.

Ceci permettant, éventuellement, d'automatiser le processus de

découverte de services web afin de faciliter les échanges d'affaires entre
entreprises.

30 Ibidem
 31

Un registre UDDI est défini comme un méta service qui utilise les
protocoles SOAP et HTTP et qui suit un modèle d'échange de données basé
sur le langage XML.

Figure II.7. UDDI

II.7.4. Différence entre IIOP et SOAP

IIOP (Internet Inter-ORB Protocol) est un protocole qui permet aux

programmes distribués écrits dans différents langages de programmation de
communiquer sur Internet. IIOP est un élément essentiel d’une norme
stratégique de l’industrie, la Common Object Request Broker Architecture
(CORBA). Il permet d’envoyer et de recevoir des données du type complexe,
et facilite l’échange entre client-serveur en mélangeant les langages de
programmation et des plateformes. Etant complet, il est capable d’effectuer
tous les transferts exigés par SOAP. Cependant l’utilisation de SOAP peut être
parfois préférable pour différentes raisons :

• IIOP va poser des problèmes pour le franchissement des équipements

de filtrage (firewall, proxy). Cela va demander un travail en plus de la
part de chaque personne administrant l’équipement.
• SOAP étant un protocole utilisant HTTP, il y a peu de chance qu’il soit
bloqué lors d’un filtrage. Evidemment CORBA, au travers de IIOP, est
plus performant : il y a moins de données transitant sur le réseau, et les
opérations de conversion / de déconversion sont traitées plus
rapidement. Cependant avec SOAP les données circulent en format
texte et en clair sur le réseau. Leur lecture en est donc facilitée et le
débogage est beaucoup plus simple.
 32

En fait, l’utilisation de CORBA ou de SOAP va surtout dépendre de

ce que l’on doit faire : dans le cas des web services, SOAP semble être une
bonne solution, par contre si l’on souhaite faire des applications distribuées
classiques comme du calcul distribué, on choisira plutôt CORBA.

II.7.5. Protocoles utilisés par SOAP

Le SOAP (Simple Object Access Protocol) est tout d’abord un

protocole de messagerie. Il permet à des programmes qui s'exécutent sur des
systèmes d'exploitation distincts (tels que Windows et Linux) de communiquer
au moyen du protocole HTTP (HyperText Transfer Protocol) et de son langage,
XML (Extensible Markup Language). Le SOAP utilise beaucoup le protocole
HTTP et le langage XML. Nous pouvons aussi ajouter le SMTP (Simple Mail
Transfer Protocol).

II.7.6. Problèmes posés par SOAP

a. Problème http

Le HTTP (HyperText Transfert Protocol) est un protocole

de couche application du modèle de suite de protocoles Internet pour les
systèmes d’information hypermédia distribués, collaboratifs. HTTP est le
fondement de la communication de données pour le World Wide Web
(WWW), où les documents hypertextes incluent des hyperliens vers d’autres
ressources auxquelles l’utilisateur peut facilement accéder, par exemple par
un clic de souris ou en appuyant sur l’écran dans un navigateur Web.31

HTTP utilise des méthodes de requête spécifiques dans le but

d’effectuer diverses tâches. Tous les serveurs HTTP sont ainsi basés sur GET (qui
désigne une ressource spécifique dans son intégralité) et HEAD (qui demande
une ressource spécifique sans le contenu du corps).

Tous ne prennent cependant pas en charge les autres méthodes.

En effet, il y a également le POST, qui ajoute du contenu, des messages ou
des données à une nouvelle page sous une ressource Web existante.
Le PUT modifie directement une ressource web ou crée un nouvel URI si cela
est nécessaire. DELETE se débarrasse d’une ressource spécifiée, tandis
que TRACE montre aux utilisateurs tous les changements ou ajouts apportés à
une ressource Web. Quant à OPTIONS, il montre aux utilisateurs quelles
méthodes HTTP sont disponibles pour une URL spécifique. Nous avons, en
outre, les méthodes CONNECT (conversion de la demande de connexion en

31 www.wikipedia.com, consulté le 08 août 2022 à 15h20’

 33

un tunnel TCP/IP transparent) et PATCH (modification partielle d’une

ressource Web).32

b. Problème XML

Les problèmes d’interopérabilité XML concernent l’analyse du

langage XML. SOAP repose sur l’utilisation de ce langage, donc si XML pose
des problèmes d’implémentations, ceux-ci vont poser des problèmes sur
SOAP.

32 www.lebigdata.fr, consulté le 08 août 2022 à 18h30’

 34

DEUXIEME PARTIE :
ETUDE PREALABLE ET
CADRAGE DU PROJET
 35

CHAPITRE I : CADRAGE DU PROJET

Section I : Évaluation du projet

1.1. Introduction

L’évaluation est une fonction qui consiste à porter une appréciation

aussi systématique et objective que possible, sur un objet en cours ou
achevé, un programme ou un ensemble de lignes d’actions, sa conception,
sa mise en œuvre et ses résultats. Il s’agit de déterminer la pertinence des
objectifs et leur degré de réalisation, l’efficience au regard du
développement, l’efficacité, l’impact et la validité.

Les projets doivent avoir les buts et des objectifs clairs et être
durables, ils doivent s’accompagner de résultats mesurables et indicateurs.

1.2. Cycle de vie d’un projet

Parlant de cycle de vie d’un projet, nous voyons s’agit du processus

de gestion de projet, composé de ses différentes étapes partant de
l’identification des besoins jusqu’à la clôture du projet.

Le cycle de vie du projet se compose en quatre (4) étapes

principales qui sont :

• Le cadrage (étude de faisabilité et examen) ;

• La conception ;
• La réalisation ;
• La clôture.

1.2.1. Étape de Cadrage

Cette première phase d’étude et d’analyse se nomme également :

initialisation, démarrage ou encore avant - projet.

Le projet est initialisé à partir d’un besoin (problème à résoudre ou

opportunité à saisir) ; un objectif est défini, une analyse est menée pour
identifier la meilleure façon de travailler sur la réponse à apporter. Cette
phase entérine la décision de lancer le projet.33

33 MBIKAYI, Cours de Méthode de Conduite de Projet Informatique, L2 Conception, ISS-KIN,

inédit, 2021-2022
 36

1.2.2. Étape de conception et de planification

• L’équipe projet : définit dans le détail ce qui doit être fait, comment et
avec quels moyens. Elle planifie dans le temps les étapes et la
mobilisation de ressources. 34
• Le chef de projet : affine en particulier le budget financier en intégrant
les différentes charges : prestations internes, support interne (lorsque des
refacturations entre services sont appliquées), les moyens matériels et les
autres achats.

Tous ces éléments sont consignés dans un plan projet comprenant :

• Une liste des grandes phases ;

• Les activités à mener, les dépendances entre les tâches ;
• Les livrables ;
• Un plan de communication projet ;
• Un plan de gestion des risques.

En complément, un plan qualité peut être construit afin de maitriser

le processus et ses livrables.

1.2.3. Étape de réalisation du projet

Il s’agit de la mise en œuvre concrète des éléments planifiés.

Séances créatives, ateliers de travail, analyse de la valeur…le groupe de
projet œuvre dans la recherche et déploiement de solutions pour satisfaire les
objectifs définis. Le chef de projet contrôle l’avancée des activités, le respect
du planning, des dépenses, des résultats au regard du plan de projet initial et
l’ajuste si nécessaire. Il suit attentivement le tableau de bord agrégeant les
principaux indicateurs clés de performance pour s’assurer que l’exécution du
projet reste dans les clous. Régulièrement, il communique avec les parties
prenantes : il les tient informées de l’avancée du projet et de toute dérivée
majeure.

Une fois toutes les opérations réalisées et validées, le client interne

ou externe prend possession des livrables : livraison de solution, formation,
etc.35

1.2.4. Étape de clôture

C’est l’heure du bilan et de l’organisation de la fin des travaux. Un

projet s’achève avec la rédaction d’un rapport final. Celui-ci informe sur le

34 Idem
35 Ibidem
 37

déroulement des travaux et les résultats. Il rappelle les objectifs qui avaient
été fixés au départ et indique leur degré de réalisation. Il propose des
applications pratiques.36

Pour clôturer un projet, le gestionnaire de projet doit :

• Doit s’assurer que tous les produits ou services convenus, incluant la

formation du personnel, ont été livres ;
• Fournir les procédures d’exploitation et de maintenance ;
• Prévoir le soutien technique et le dépannage ;
• Assurer l’approvisionnement en matières premières et en instruments ;
• Facturer le client selon les modalités convenues ;
• Honorer tous les paiements et donner suite aux réclamations ;
• Réaffecter le personnel ;
• Organiser des activités de reconnaissance à l’égard du personnel ;
• Rédiger et remettre le rapport final ;
• Effectuer la clôture comptable du projet.

Des processus très stricts sont imposés à l’étape de la clôture du

projet, en raison des aspects légaux ou juridiques qu’ils comportent. Dans le
domaine construction, la clôture est divisée en deux phases : l’acceptation
provisoire de l’œuvre et l’acceptation définitive.

Section II : Planning prévisionnel de réalisation du projet

2.1. Méthode d’ordonnancement

Les méthodes d’ordonnancement permettent d’élaborer un

graphe qui représente l’ensemble des tâches composant le projet ainsi que
les liens qui existent entre elles. Sur le graphe, apparaissent également la
durée de chaque tâche, la date à laquelle elle peut débuter au plus tôt et
au plus tard.37

2.1.1. Planning d’ordonnancement

Il désigne une classe des problèmes concernant en particulier la

conception ou la réalisation des projets ou des grands ensembles complexes
nécessitant une multiple tâche ou opération soumise à de nombreuses
contraintes et qui mettent en jeu de nombreux capitaux des matériaux et

36 https://www.google.com,
37 Farouk H., Mira B., Techniques de gestion, Dalloz, Paris, 2016
 38

matériels variés, des hommes, des spécialistes et des compétences très

différentes.

2.1.2. Ordonnancement d’un projet

L’ordonnancement d’un projet complexe, de production ou

d’investissement par exemple, consiste à planifier, ordonner, rationnaliser
l’ensemble des tâches nécessaires à la réalisation du projet en respectant les
contraintes techniques, économiques et de délais, à déterminer la durée
globale et minimale de réalisation du projet.38

2.2. Présentation de la méthode PERT

Cette méthode, créée dans les années 50 dans l’objectif de gain

du temps pour les missiles à opération nucléaires. Depuis les années 1958 aux
États Unis d’Amérique (USA), principalement sous l’égide de la NASA, se sont
développé des méthodes dites : CPM (Critical Post Method) ou PERT
(Program Evaluation and Review Technic), l’une des premières applications
fut employé de ces méthodes pour la réalisation du programme de
recherche de construction du fusé POLARIS.

Dans notre étude, nous avons choisi la méthode PERT (Program

Evaluation and Review Technic), qui consiste à mettre en ordre sous la forme
de graphe. Cette méthode permet de définir les activités nécessaires à
l’exécution de chacune d’elle, les complexes, les durées d’exécution, les
dates au plus tôt, dates au plus tard du lancement de chaque tâche ainsi
que le chemin critique. Un projet est un ensemble d’opérations qui doivent
permettre d’atteindre un objectif clairement exprimable et représentant un
certain caractère d’unicité.

Pour que l’objectif fixé soit atteint, il faut que toutes les tâches
constituant ce projet soient exécutées dans le temps et avec les moyens
nécessaires. Par conséquent, il est important d’identifier et d’étudier toutes les
tâches avant la mise en œuvre du projet.

38 https://www.tifawt.com,
 39

2.2.1. Identifications et classement des taches

Tableau I.1. Identification et classement des tâches

Code tâche Désignation des tâches Durée par jour Tâches antérieures
01 Prise de contact 4 ---
02 Étude d’opportunité 30 ----
03 Proposition et choix de la meilleure 4 T2
solution
04 Étude de faisabilité 10 T3
05 Conception du nouveau système 40 T1, T4
06 Élaboration du cahier de charge 10 T5
07 Appel d’offre 14 T6
08 Aménagement des locaux 10 T7
09 Dépouillement et choix des offres 5 T8
10 Passation de la commande 7 T9
11 Acquisition des matériels 7 T10
12 Installation des programmes et 7 T11
configuration réseau
13 Installation physique du logiciel 7 T12
14 Tests 7 T13
15 Formation du personnel 14 T14
16 Lancement de projet 1 T15
 40

2.2.2. Construction du graphe PERT

94 94 T7(14) 108 108 T8(10) 118 118

0 0
4 44
6 7 8
1
T6(10) T9(5)

34 34 T4 44 44 T5 84 84
0 0 0 0 (10) 0 0 (40) 0 0 123 123
3 4 5
0 9
T3
(4)
T10(7)
30 30
0 0
2
172 172 T16(1) 173 173 130 130

15 16 10

T15(14) T11(7)

Figure I.1. Graphe PERT

158 158 T14(7) 151 151 T13(7) 144 144 T12(7) 137 137

14 13 12 11
 41

2.2.3. Détermination des niveaux du graphe

Pour déterminer les différents niveaux nous allons successivement

supprimer du tableau toutes les tâches qui n’ont pas de prédécesseur. Toutes
les taches supprimées à une étape vont constituer les taches de ce niveau.
Par rapport au principe évoqué ci –haut, nous avons identifiés 14 niveaux qui
sont les suivantes :

• Niveau 1 = { T1, T2 }
• Niveau 2 = { T3 }
• Niveau 3 = { T4 }
• Niveau 4 = { T5 }
• Niveau 5 = { T6 }
• Niveau 6 = { T7 }
• Niveau 7 = { T8 }
• Niveau 8 = { T9 }
• Niveau 9 = { T10 }
• Niveau 10 = { T11 }
• Niveau 11 = { T12 }
• Niveau 12 = { T13 }
• Niveau 13 = { T14 }
• Niveau 14 = { T15 }
 42

2.3. Matrice d’antériorité

Tableau I.2. Matrice d’antériorité

IL FAUT AVOIR FAIT NIVEAUX

T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 T13 T14 T15 T16 N1 N2 N3 N4 N5 N6 N7 N8 N9 N10 N11 N12 N13 N14
T1 * * * * * * * * * * * * * * * * 0
T2 * * * * * * * * * * * * * * * * 0
T3 * 1 * * * * * * * * * * * * * * 1 0
T4 * * 1 * * * * * * * * * * * * * 1 1 0
T5 1 * * 1 * * * * * * * * * * * * 2 1 1 0
POUR FAIRE

T6 * * * * 1 * * * * * * * * * * * 1 1 1 1 0
T7 * * * * * 1 * * * * * * * * * * 1 1 1 1 1 0
T8 * * * * * * 1 * * * * * * * * * 1 1 1 1 1 1 0
T9 * * * * * * * 1 * * * * * * * * 1 1 1 1 1 1 1 0
T10 * * * * * * * * 1 * * * * * * * 1 1 1 1 1 1 1 1 0
T11 * * * * * * * * * 1 * * * * * * 1 1 1 1 1 1 1 1 1 0
T12 * * * * * * * * * * 1 * * * * * 1 1 1 1 1 1 1 1 1 1 0
T13 * * * * * * * * * * * 1 * * * * 1 1 1 1 1 1 1 1 1 1 1 0
T14 * * * * * * * * * * * * 1 * * * 1 1 1 1 1 1 1 1 1 1 1 1 0
T15 * * * * * * * * * * * * * 1 * * 1 1 1 1 1 1 1 1 1 1 1 1 1 0
T16 * * * * * * * * * * * * * * 1 * 1 1 1 1 1 1 1 1 1 1 1 1 1 1
 43

2.4. Délai de réalisation du projet

Tableau I.3. Délai de réalisation du projet

Code Désignation des tâches Durée Tâches Nombre de Coût Coût total
tâche par jour antérieures personne unitaire ($)
01 Prise de contact 4 --- 1 $5,00 $20,00
02 Étude d’opportunité 30 ---- 1 $15,00 $450,00
03 Proposition et choix de la
4 T2 1 $10,00 $40,00
meilleure solution
04 Étude de faisabilité 10 T3 1 $10,00 $100,00
05 Conception du nouveau
40 T1, T4 1 $10,00 $400,00
système
06 Élaboration du cahier de
10 T5 1 $10,00 $100,00
charge
07 Appel d’offre 14 T6 1 $10,00 $140,00
08 Aménagement des locaux 10 T7 1 $10,00 $100,00
09 Dépouillement et choix des
5 T8 1 $10,00 $50,00
offres
10 Passation de la commande 7 T9 1 $10,00 $70,00
11 Acquisition des matériels 7 T10 1 $10,00 $70,00
12 Installation des programmes
7 T11 1 $10,00 $70,00
et configuration réseau
13 Installation physique du
7 T12 1 $20,00 $140,00
logiciel
14 Tests 7 T13 1 $30,00 $210,00
15 Formation du personnel 14 T14 1 $40,00 $560,00
16 Lancement de projet 1 T15 1 $50,00 $50,00
COUT TOTAL DU PROJET $2 570,00

2.4.1. Calcul de dates au plus tôt et plus tard

2.4.1.1. Détermination des dates au plus tôt

On appelle date au plus tôt d’une tâche, la première date à

laquelle il est possible de démarrer la tâche étant donné les contraintes et la
durée des tâches. 39

Date au plus tôt = Date début plus tôt de la tâche précédente + durée de la
tâche précédente

39 Bruno WARIN, Méthode PERT, Paris, PUF, 2014.

 44

2.4.1.2. Détermination des dates au plus tard

On appelle date au plus tard d’une tâche, la date à laquelle il faut

impérativement démarrer la tache si on veut déterminer absolument le projet
dans sa durée minimale. 40

Date au plus tard =date au plus tard de la tâche suivante – durée de la

tâche.

2.5. Élaboration des marges libres et totales

2.5.1. Marge totale

Pour une tâche, une marge totale est le retard tolérable sur la
tâche tel que cela ne porte pas préjudice à la date de fin du projet.41

Marge totale = Date au plus tard – Date au plus tôt.

2.5.2. Marge libre

La marge libre pour une tâche c’est le délai de retard qu’elle peut
prendre sans provoquer de retard à aucun de ses successeurs. La marge libre
est plus sévère que la marge totale.

Marge totale = Date de fin au plus tard – Durée de la tâche – Date de début
au plus tôt

40 Bruno WARIN, Méthode PERT, Paris, PUF, 2014.

41 Idem
 45

2.5.3. Détermination des dates au plus tôt, datent au plus tard, marge totale et
marge libre

Tableau I.4. Détermination des dates au plus tôt, datent au plus tard, marge totale et
marge libre

F(X) (Tâche F(X)(Tâche T’ (Date T’’ (Date

Code tâche Durée/jour MT(X) ML(X)
précédente) suivante) plus tôt) plus tard)
Début - - T1, T2 0 0 0 0
1 4 D T5 4 44 40 40
2 30 D T3 30 30 0 0
3 4 T2 T4 34 34 0 0
4 10 T3 T5 44 44 0 0
5 40 T1, T4 T6 84 84 0 0
6 10 T5 T7 94 94 0 0
7 14 T6 T8 108 108 0 0
8 10 T7 T9 118 118 0 0
9 5 T8 T10 123 123 0 0
10 7 T9 T11 130 130 0 0
11 7 T10 T12 137 137 0 0
12 7 T11 T13 144 144 0 0
13 7 T12 T14 151 151 0 0
14 7 T13 T15 158 158 0 0
15 14 T14 T16 172 172 0 0
16 1 T15 F 173 173 0 0
Fin - - - - - - -

2.5.4. Détermination du chemin critique et des tâches critiques

On appelle chemin critique, tout chemin allant du début à la fin de

longueur maximale, par contre une tâche critique c’est tout sommet d’un
chemin critique. Les tâches critiques sont les tâches qui n’admettent aucun
retard dans leur démarrage, si non tout le programme se trouve retardé.
C’est -à –dire, les tâches dont la marge totale est nulle.

Après avoir appliqué l’algorithme de Ford, nous avons obtenus une

longueur maximale de 173, qui par conséquent est la durée minimum de
l’exécution de notre projet. Le chemin critique est : (D T2, T3, T4, T5, T6, T7, T8,
T9, T10, T11, T12, T13, T14, T15, F). Les tâches critiques : (D T2, T3, T4, T5, T6, T7, T8,
T9, T10, T11, T12, T13, T14, T15, F).
 46

94 94 T7(14) 108 108 T8(10) 118 118

0 0
6 7 8

T6(10) T9(5)

34 34 T4 44 44 T5 84 84
0 0 0 0 (10) 0 0 (40) 0 0 123 123
3 4 5
D 9
T3
(4)
T10(7)
30 30
0 0
2
172 172 T16(1) 173 173 130 130

15 F 10

T15(14) T11(7)

Figure I.2. Chemin critique et tâches critiques 158 158 T14(7) 151 151 T13(7) 144 144 T12(7) 137 137

14 13 12 11
 47

2.6. Tableau synthétique de la réalisation du projet

2.6.1. Calendrier de réalisation du projet

En considérant que la date du démarrage du projet est le 04 avril

2022, l’unité de temps est fixée en jour (hormis les samedis) et les dimanches
comme jours fériés, le calendrier de réalisation de notre projet se présente
comme suit :

Tableau I.5. Calendrier de réalisation du projet

Date du début Tâches à exécuter Date de fin

04 avril 2022 Prise de contact 07 avril 2022
04 avril 2022 Étude d’opportunité 13 mai 2022
16 mai 2022 Proposition et choix de la meilleure solution 19 mai 2022
20 mai 2022 Étude de faisabilité 02 juin 2022
03 juin 2022 Conception du nouveau système 28 juillet 2022
29 juillet 2022 Élaboration du cahier de charge 11 août 2022
12 août 2022 Appel d’offre 31 août 2022
01 septembre 2022 Aménagement des locaux 14 septembre 2022
15 septembre 2022 Dépouillement et choix des offres 21 septembre 2022
22 septembre 2022 Passation de la commande 30 septembre 2022
03 octobre 2022 Acquisition des matériels 11 octobre 2022
12 octobre 2022 Installation des programmes et configuration 20 octobre 2022
réseau
21 octobre 2022 Installation physique du logiciel 31 octobre 2022
01 novembre 2022 Tests 09 novembre 2022
10 novembre 2022 Formation du personnel 29 novembre 2022
30 novembre 2022 Lancement de projet 30 novembre 2022
 48

CHAPITRE II : ANALYSE ET SPECIFICATION DES BESOINS

Dans le présent chapitre, nous allons procéder à l’analyse de notre
domaine d’étude et procéder à quelques spécifications des besoins liés à la
gestion collective des droits d’auteur, principalement à l’organe qui a habilité
de ladite gestion dans notre pays.

Section 1 : Présentation de l’entreprise

La SOCODA est la Société Congolaise des Droits d’auteur et des

Droits Voisins, seul organisme chargé de la perception et la répartition des
droits d’Auteur en République Démocratique du Congo (conformément à
l’Ordonnance-Loi n°11/022 du 18 mars 2011 portant autorisation de la
création d’une société coopérative dénommée Société Congolaise des
Droits d’Auteur et des Droits Voisins, en sigle « SOCODA »).

La SOCODA est une société coopérative (privée) constituée de

tous les créateurs des œuvres de l’esprit protégées par la loi et dotée d’une
personnalité juridique.

1.1. Aperçu historique

L’histoire de la gestion collective du droit d’auteur en R.D. CONGO

remonte à l’époque coloniale avec l’installation des studios d’enregistrement
des œuvres musicales à Kinshasa : Le premier studio d’enregistrement
dénommé « Olympia » fut installé en 1939. Plusieurs autres studios tels que
Loningisa, Opika, Esengo furent créés par la suite. C’est grâce à ces studios
que les premiers musiciens tels que Wendo kolosoy, Manuel d’Oliveira, Adou
Elenga enregistrèrent des œuvres avec un succès international.

La circulation intensive de ces disques amena l’autorité coloniale à

réglementer le secteur avec le décret royal du 21 juin 1948 qui fixa les règles
de droit d’auteur principalement en faveur des musiciens. Ce fut le premier
texte juridique sur le droit d’auteur en R.D. CONGO.

En 1954, la société belge des droits d’auteur sur la musique (SABAM)

ouvrit une représentation à Kinshasa pour assurer la gestion collective des
œuvres musicales produites localement. A l’indépendance en 1960, la
SABAM ferma sa représentation, laissant la place à la société des auteurs
congolais (SACO) créée dans la précipitation le 12 décembre 1961.

A cause de la mauvaise gestion, cette société fut dissoute et

remplacée en 1963 par l’office national des droits d’auteur (ONDA). Cet
office ne survit pas longtemps à cause des mêmes problèmes de mauvaise
gestion. C’est dans ce contexte que le Président Mobutu autorisa en 1969 la
 49

création d’une nouvelle société coopérative dénommée Société Nationale

des Editeurs, Compositeurs et Auteurs en abrégé « SONECA », par
l’ordonnance n°69-064 du 06 décembre 1969, créée pour une durée de 30
ans qui pouvait être prorogée.

Cette société coopérative avait pour objet la protection,

l’exploitation, l’administration et la gestion de tous les droits d’auteur et des
droits voisins en R.D.CONGO et à l’étranger. Elle avait aussi la mission de
percevoir et de répartir tous les droits. Le Gouvernement lui accorda une
subvention en vue de sa mise en place. En 1975, le dysfonctionnement de
ladite société apparut au grand jour ; les causes en étaient le non-paiement
du personnel, le non-respect des Statuts de la société, la mauvaise gestion, la
dissipation des fonds…

Afin de la redresser, le Gouvernement décida de prendre en

charge les salaires du personnel en transformant la société coopérative en un
service public du Ministère de la Culture et des Arts ; par la même occasion,
les organes de ladite société (Assemblée Générale et le Conseil
d’Administration) furent suspendus en 1982. Dix ans après, en 1992, à la
demande des artistes, l’Etat congolais réhabilita les deux organes suspendus.
Malgré cette présence des sociétaires dans les organes de gestion, la
mauvaise gestion persista jusqu’à l’an 1999. Cette année constituait aussi la
fin du terme de 30 ans de la durée de vie de ladite société.

Au lieu de convoquer une Assemblée Générale afin de proroger la

durée de la société pour un nouveau terme de 30 ans, les sociétaires se
livrèrent plutôt à des querelles interminables qui amenèrent le m3inistre de la
Culture et des Arts à nommer un Comité de Coordination qui fut succédé par
plusieurs comités de liquidation ayant tous la même mission : celle de mettre
en place une nouvelle structure capable de gérer les droits des artistes.
L’autorisation de la création de la nouvelle société coopérative dénommée
« Société Congolaise des Droits d’Auteur et des Droits Voisins » en sigle
SOCODA COOP-CA, par l’ordonnance présidentielle n°11/022 interviendra le
18/03/2011.

Depuis lors, la nouvelle société a mis en place ses organes, à savoir

l’Assemblée Générale, le Conseil d’Administration et la Direction Générale. Il
y a lieu de signaler que la SOCODA a souffert et continue à souffrir de la
campagne de dénigrement menée par le dernier liquidateur de la SONECA
qui a démobilisé beaucoup d’usagers, outrepassant même les pouvoirs qui lui
avaient été reconnus par le Ministre de la Culture et des Arts : tel qu’il en
ressort de l’analyse ci-dessous sur la liquidation de la SONECA.
 50

Considérant l’impérieuse nécessité d’assurer une gestion efficiente

des Droits d’Auteur et des Droits Voisins afin de permettre non seulement à
leurs efforts titulaire de tirer profit de leurs prestations mais aussi, contribuer de
par leurs efforts au développement de la nation que la SOCODA a été créée.

1.2. Situation géographique

Le siège de la société est établi à Kinshasa, capitale de la

République démocratique du Congo, sur avenue KIDISHO n°03 dans la
Commune de la Gombe. Il peut être transféré sur proposition du Conseil
d’Administration à l’Assemblée Générale Extraordinaire à tout autre lieu du
territoire national.

1.3. Objet et missions de la société

La Société Congolaise des Droits d’Auteur et des Droits voisins a

pour objet de :

– Promouvoir et de défendre les intérêts moraux et matériels des auteurs

tant au plan national qu’international ;
– Établir entre les membres et les usagers les relations nécessaires à la
protection de leurs droits ;
– Assurer la gestion collective des droits d'auteur, des droits voisins et
veiller à l’exploitation des expressions du patrimoine culturel traditionnel
appartenant au patrimoine national ;
– Assurer sur le territoire national la gestion, l’administration et
l'exploitation des droits des auteurs, des artistes interprètes ou
exécutants, des producteurs de phonogrammes et de vidéogrammes
conformément à la législation en vigueur relative à la protection des
droits d’auteur et des droits voisins ;
– Gérer sur le territoire national, les intérêts des organismes professionnels
de gestion collective étrangers dans le cadre des accords de
réciprocité dont elle est appelée à convenir avec eux, ainsi que par
présomption de gestion sans mandat ;
– Valoriser par des moyens propres, le répertoire de la Société et à en
assurer la promotion auprès du public à l’échelle nationale et
internationale par l’organisation des actions culturelles ;
– Bénéficier s’il échet de l’accompagnement, de la collaboration et de
l’appui de l’État congolais.

En outre, elle a reçu mission de gérer, à titre exclusif, tous les droits
dont l'exercice lui est confié en application de l’article 111 de l’Ordonnance-
Loi n°86-033 du 05 avril 1986 portant protection de droits d’auteur et des droits
voisins.
 51

Elle est notamment chargée de :

– Fixer le barème tarifaire des redevances des droits d’auteur et des

droits voisins ;
– Percevoir et répartir au profit des titulaires des droits, des redevances
provenant de l’exploitation de leurs œuvres, ainsi que les droits de
rémunération pour copie privée ;
– Procéder aux contrôles effectifs sur les exploitations ou les utilisations
des œuvres de l’esprit protégées par la loi auprès des utilisateurs ;
– Ester en justice, afin d’assurer la défense des droits individuels de ses
membres et des intérêts et droits de la généralité de ses associés d’une
part et diligenter toutes procédures d’intérêt général ayant trait
notamment à la protection et à la défense des auteurs et de leurs
ayants droit d’autre part ;
– Informer et conseiller les membres de la SOCODA COOP-CA, les
utilisateurs des œuvres protégées sur toutes les questions relatives aux
droits d'auteur, aux droits voisins et aux droits relatifs aux expressions du
patrimoine culturel traditionnel …

1.4. Organisation structuro-fonctionnelle

En parlant de l’organisation structuro-fonctionnelle, nous voyons ici

une vue d’ensemble sur l’organisation de tous les services de l’entreprise.
Cette vue est représentée succinctement par un organigramme.
 52

1.4.1. Organigramme général

ASSEMBLEE GENERALE

CONSEIL D’ADMINISTRATION

CONSEIL DE SURVEILLANCE

SECRETARIAT DU CONSEIL

DIRECTION GENERALE

ASSISTANCE SECRETARIAT DE DIRECTION RECEPTION

COMMUNICATION CELLULE INFORMATIQUE

DIRECTION TECHNIQUE DIRECTION DIRECTION JURIDIQUE DIRECTION DE

COOPERATION ET ADMINISTRATIVE ET DOCUMENTATION ET
FORMATION FINANCIERE REPARTITION

DELEGATIONS PROVINCIALES

Source : Secrétariat
 53

1.4.2. Organigramme spécifique

DIRECTION DE LA DOCUMENTATION ET RÉPARTITION

SERVICE DE LA DOCUMENTATION
SERVICE DE REPARTITION
• AFFILIATION
• DECLARATION DES ŒUVRES • RELEVE DES PROGRAMMES
• REPERTOIRE DES AYANTS- • REPARTITION DES DROITS
DROITS ET DES ŒUVRES

Source : Secrétariat

1.4.3. Description de poste

1. DIRECTEUR REPARTITEUR

Le Directeur Répartiteur est chargée de superviser et coordonner

l'affiliation des nouveaux membres sociétaires ainsi que la déclaration de
leurs œuvres de l'esprit. En outre, il est chargé de :

• Proposer les dossiers d'application des nouveaux membres à la signature

du Président du Conseil d'Administration et au paraphe du Directeur
Général ;
• Recevoir les feuilles de répartition venant des sociétés sœurs ;
• Transmettre les feuilles de répartition au service concerné ou
compilation et traitement des dossiers ;
• Vise les feuilles y relatives ;
• Faire rapport au Directeur Général.

2. CHEF DE SERVICE DOCUMENTATION

Le Chef de Service documentation gère le répertoire général des

membres sociétaires ainsi que leurs œuvres par discipline. Puis, il est chargé
de :

• Réceptionner les bulletins d'adhésion et déclaration d'œuvres des

membres, les saisir en les conservant en mode numériques ;
• Conserver les supports enregistrés ;
• Etablir une situation mensuelle, trimestrielle et annuelle des membres ;
• Faire rapport au Directeur Répartiteur ;
• Assister le Directeur Répartiteur.
 54

a. AFFILIATION

Ce service est chargé de :

• Assurer les formalités d'affiliation et d'adhésion des artistes et autres

créateurs des œuvres de l'esprit protégées par la loi ;
• Veiller aux conditions d'admission pour les sociétaires et les adhérents
tels que prévue dans le règlement général ;
• Aider les membres à remplir les différents formulaires d'adhésion et de
déclaration des œuvres ;
• Recevoir les formulaires de demande d'affiliation (remplis et signés) et
s'assure qu’elles soient correctement remplies ;
• Reçoit les échantillons des œuvres déposées par les artistes et veille à
leur bonne conservation ;
• Fait rapport au cher de service documentation.

b. COMMIS AU REPERTOIRE DES AYANTS DROIT ET DES OEUVRES

• Gérer les données physiques et numériques des ayants - droit et des

œuvres ;
• Procéder à la mise à jour du fichier des ayants droit et des œuvres ;
• Saisir les différentes lettres de service ;
• Veiller au bon fonctionnement des ordinateurs ;
• Faire rapport au chef de service documentation.

3. CHEF DE SERVICE REPARTITION

• Recevoir les feuilles de répartition venues des sociétés sœurs des usagers
locaux transmises par le Directeur Répartiteur ;
• Contrôler tous les éléments avec exactitude ;
• Trier les différents dossiers à traiter ;
• Transmettre les dossiers triés pour exécution au commis à la répartition
des droits d'auteur et des droits voisins ;
• Faire rapport au Directeur Répartiteur.

a) COMMIS AU RELEVE DES PROGRAMMES

• Relever les programmes auprès des usagers tels que les chaines de Tv
et les Radios ainsi que d'autres programmes récupérés par les
percepteurs ;
• Remettre les programmes au chef de service répartition ;
• Fait rapport au chef de service répartition ;

b) COMMIS A LA REPARTION DES DROITS

• Compiler les paquets de programmes et feuilles de répartition pour

préparer la répartition ;
 55

• Proposer le calcul de répartition au prorata des programmes et feuilles

de répartition ;
• Faire rapport au chef de service répartition.

Section 2 : Analyse de l’existant

2.1. Étude des moyens utilisés

Dans le présent point, nous allons essayer d’avoir une vue

d’ensemble de tous les moyens utilisés par la gestion collective des droits
d’auteur au sein de la SOCODA COOP-CA.

2.1.1. Moyens humains

La Société Congolaise des Droits d’Auteur et des Droits Voisins

dispose d’un personnel composé de plus de cinq cents (500) agents à travers
le pays. La ville de Kinshasa en elle-même regorge plus de cent (100) agents.

Mais dans la Direction de la Documentation et Répartition où nous

avons effectué nos recherches, il a un personnel propre composé de quatre
(4) personnes que voici :

• Un Directeur de la Documentation et Répartition ;

• Un Répartiteur ;
• Deux documentalistes.

2.1.2. Moyens matériels

La SOCODA COOP-CA a un cadre bien aménagé dans lequel les

activités se déroulent normalement, pour le bon fonctionnement de ses
services. Elle dispose dix (10) ordinateurs dont cinq (5) de bureau de marque
HP (pentium Windows 7 comme S.E) et cinq (5) portables.

2.1.3 Moyens financiers

Les ressources financières de la SOCODA COOP-CA proviennent

de paiement des redevances dues aux auteurs des œuvres de l’esprit
protégés. Dès lors que l’usager paie, la SOCODA bénéficie 30% de toutes les
recettes réparties comme suit :

- 25 % pour le fonctionnement de la société et

- 5 % pour la constitution d’une caisse d’entraide sociale en faveur des
artistes membres de la société.

Les 70 % restant sont destinés à la répartition des droits au profit des

ayants droits (sociétaires), conformément au règlement général de la
société.
 56

2.2. Études des documents

La Société Congolaise des Droits d’Auteur et des Droits Voisins,

SOCODA COOP-CA en sigle, utilise bon nombre des documents pour la
perception de redevance due aux droits d’auteur allant de l’identification, la
déclaration et l’enregistrement des œuvres de l’esprit avec les auteurs, en
passant par l’identification et taxation des usagers qui posent les actes qui
génèrent les droits d’auteur, pour finir par la répartition. Étant donné que
notre étude se base plus sur la Direction de la Documentation et Répartition,
nous allons essayer de donner les quelques documents utilisés dans ce
service.

1. Lettre de demande d’adhésion

a) Rôle

Ce document permet au créateur d’œuvre de l’esprit de pouvoir

demander son adhésion à la société. Il contient ses informations afin que la
société puisse décider si ce dernier remplit les conditions pour pouvoir
adhérer à la société.

b) Description

Tableau II.1. Description lettre de demande d’adhésion

Code propriété Propriété Nature Taille

Nm Nom AN 30
PstNm Post nom AN 30
PreNom Prénom AN 30
Pseudo Pseudonyme AN 30
Adress Adresse AN 100
NumTel Numéro de téléphone N 15
Mail E-mail AN 30
Nat Nationalité AN 30
Qual. Qualité AN 20
Fil. Filière AN 100
Œuv. Œuvres AN 100
Date Date AN 10

2. Adhésion aux Statuts et acte d’apports

a) Rôle

Par ce document, l’auteur d’œuvre de l’esprit accepte les

conditions se trouvant dans les Statuts de la Société ainsi il fait apport à la
société.
 57

b) Description

Tableau II.2. Description d’adhésion aux Statuts et acte d’apports

Code propriété Propriété Nature Taille

Nm Nom AN 30
PstNm Post nom AN 30
PreNom Prénom AN 30
Pseudo Pseudonyme AN 30
Group Groupe AN 50
Disc Discipline AN 100
Fil. Filière AN 100
DatNai Date de Naissance AN 10
LieuNai Lieu de naissance AN 30
Pays Pays AN 30
Nat Nationalité AN 30
Adress Adresse AN 100
NumTel Numéro de téléphone N 15
Mail E-mail AN 30
AdreSite Adresse site AN 30
Qual. Qualité AN 20
Mont Montant payé N 5
MontLe Montant payé en lettre AN 100
Date Date AN 10

3. Contrat de cession entre créateur et SOCODA COOP-CA

a) Rôle

Par ce document, l’auteur d’œuvre de l’esprit cède et transfère

l’exploitation, l’administration, la gestion et la défense de ses droits d’auteur
sur ses œuvres présentes et futures.
 58

b) Description

Tableau II.3. Description du contrat de cession entre créateur et SOCODA COOP-CA

Code propriété Propriété Nature Taille

Nms Noms AN 120
Adress Adresse AN 100
Ville Ville AN 50
Prov Province AN 50
Qual. Qualité AN 20
Sieg Siège de la société AN 50
Aven Avenue AN 100
Num Numéro N 5
Quart Quartier AN 50
Com Commune AN 30
Repres. Représentant AN 100
Qual. Qualité AN 20
Date Date AN 10

4. Relevés des œuvres déclarées

a) Rôle

Ce document présente toutes œuvres déclarées, cédées et

transférées à la SOCODA COOP-CA pour sa gestion.

b) Description

Tableau II.4. Description des relevés des œuvres déclarées

Code propriété Propriété Nature Taille

Titre Titre de l’œuvre AN 100
Genre Genre de l’œuvre AN 50
Aut Auteur de l’œuvre AN 100

2.3. Diagnostic de l’existant

Dans le présent point, nous allons porter un jugement objectif sur

l’organisation qui vient d’être présentée. Le but est de déceler les causes qui
sont à la base de son dysfonctionnement et de son alourdissement. Ici, la
critique doit être bien mené car, c’est grâce à elle que l’on arrivera à
implanter un système plus performant et d’une fiabilité élevée.
 59

2.3.1. Critique des moyens humains

Loin de nous l’idée d’affirmer d’emblée que tout va mal dans le

service actuel. Toutefois, le nombre des tâches à exécuter et le personnel
actuel alloué à ces tâches ne sont pas parallèles c’est-à-dire il y a moins de
personnel pour des tâches aussi complexes dans un domaine aussi
complexe.

Sur terrain, il y a plus de personnel tandis que dans l’administration,

il y a une carence de main d’œuvre humaine.

2.3.2. Critique des moyens matériels

Compte tenu du volume des données à traiter, les moyens mise à

disposition ne sont loin d’être suffisants et satisfaisants pour un traitement
rapide des dossiers dans l’ensemble de la société.

2.3.3. Critique des moyens financiers

Vivant avec 25% de subventions de recettes perçues, la société vit

du jour le jour, surtout que la notion des droits d’auteur n’étant pas connue
par beaucoup d’usagers. Cela constitue un manque à gagner à terme de
temps car pour payer, certains assujettis prennent plus du temps et cela
coûte aussi aux finances de la société.

2.3.4. Critique de l’organisation

Pour ce qui concerne l’organisation nous avons constaté une

bonne organisation dans la procédure de la gestion et que chaque direction
respecte la procédure à suivre.

2.3.5. Critique des documents

Les documents utilisés dans la gestion des artistes sont bien

présentés mais leur conservation pose problème compte tenu du volume de
dossier dont la société a à sa disposition.

2.3.6. Critique de la circulation des informations

Les informations circulent correctement et permettent un bon

fonctionnement de tous les services de la société.

Section 3 : Proposition des solutions

Apres avoir analysé l’actuel système, nous allons examiner deux

différentes solutions, notamment la solution manuelle et la solution
informatique.
 60

3.1. Solution manuelle améliorée

Quoi que nous envisagions la solution d’informatiser dans un

premier temps et d’automatiser les différentes tâches de la SOCODA COOP-
CA, il nous serait impossible de nous passer totalement de la gestion
manuelle.

a) Ses avantages

• Moins couteux ;
• Peu exigeant ;
• Pas de formation particulière ;
• Sans électricité, le travail peut continuer à se faire.

b) Ses inconvénients

• Perte de temps ;
• Gaspillage d’énergie humaine ;
• Erreur et omission ;
• Difficultés d’établir plusieurs documents en un temps record.

3.2. Solution informatique

Cette solution s’appuie sur l’utilisation de l’ordinateur en vue de

traitement automatique des informations afin de permettre aux gestionnaires
au sein de la SOCODA COOP-CA d’avoir des informations fiables en temps
opportun et de bien gérer le service de documentation et répartition, qui est
très important.

a. Ses avantages

• Bonne conservation des informations sur des supports magnétiques

réduisant aussi l’encombrement ;
• Offre la sécurité des informations contre les indiscrétions ;
• Possibilité de faire la mise à jour des données en temps réel ;
• Rapidité dans le traitement des informations, la production de résultat ;
• Assure l’exactitude dans l’opération de calcul.

b. Ses inconvénients

• Perte des informations en cas de malveillance des matériels

d’automatisation ou par de virus informatique ;
• La charge coûteuse dans la maintenance ;
• Entraine d’autres dépenses supplémentaires liées à la formation du
personnel, les achats du logiciels ou matériel informatique ;
• Cout élevé.
 61

3.3. Choix de la meilleure solution

La meilleure solution est celle qui présente beaucoup plus

d’avantage que des inconvénients. Par conséquent, nous suggérons la
solution informatique. Celle-ci va consister à transmettre dans l’ordinateur
tout ce qui était traité auparavant manuellement après validation de
l’étude. Retenons que certaines tâches seront automatisées de manière à
faciliter la manipulation de l’information dans un temps record avec fiabilité
et confidentialité.
 62

TROISIEME PARTIE :
NOTION OPERATIONNELLE
 63

CHAPITRE I : CONCEPTION ET MODELISATION DU NOUVEAU SYSTEME

Dans le présent chapitre, nous allons modéliser notre système avec
le langage UML. En effet, dans la conception d'un système d'information,
la modélisation des données est l'analyse et la conception de
l'information contenue dans le système afin de représenter la structure de ces
informations et de structurer le stockage et les traitements informatiques.

I.1. Contexte

Afin de bien mener sa mission dans la gestion des œuvres de

l’esprit, la SOCODA COOP-CA a besoin des données concernant les auteurs
des œuvres ainsi que desdites œuvres couvertes par l’Ordonnance-Loi n°86-
033 du 05 avril 1986 portant protection des droits d’auteur et des droits voisins.
C’est ces données qui vont permettre à la société de percevoir les
redevances dues aux droits d’auteur.

Bien que la société ayant des entités dans l’ensemble du pays,

l’adhésion à la société requiert l’approbation de la Direction Générale qui a
compétence pour traiter les dossiers de tous les nouveaux adhérents ainsi
que l’authentification de leurs œuvres afin d’éviter le plagia.

Afin de bien décrire le contexte de notre système, nous avons

identifié les acteurs suivants :

 Le Documentaliste : est chargé d’assurer les formalités d'affiliation et

d'adhésion des artistes et autres créateurs des œuvres de l'esprit
protégées par la loi, veiller aux conditions d'admission pour les
sociétaires et les adhérents tels que prévue dans le règlement général.
 Le Directeur de la Documentation : ce dernier se charge d’examiner le
dossier de l’adhérent pour toute fin utile.
 Le Directeur Général : il est chargé de répondre à l’adhérent, suivant le
rapport du Directeur de la Documentation, si ce dernier a rempli les
critères ou pas pour adhérer à la société.
 La caissière : est chargé de percevoir les frais administratifs pour les
formalités d’adhésion.
 Le Percepteur : est chargé d’identifier toutes les sociétés qui posent les
actes qui génèrent le paiement de la redevance due aux droits
d’auteur et procède à la négociation avec lesdites sociétés puis à leur
taxation.
 L’Inspecteur : est chargé de faire le suivi auprès des usagers, les
sociétés qui posent les actes qui génèrent la redevance des droits
d’auteur, pour savoir si ces derniers ont payé leur redevance.
 64

- Suivi auprès des usagers pour

- Répondre aux adhérents pour leur connaître si le paiement est
informer s’ils ont rempli les critères effectué ou pas
pour adhérer à la société

L’Inspecteur
Le Directeur
Général

- Examiner le dossier de tous GEST.DR. - Identifier toutes les sociétés qui

les adhérents pour doivent payer la redevance
connaître l’authenticité des AU. due aux droits d’auteur
œuvres à déclarer. - Négociation avec les usagers et
les taxer.

Le Directeur de la
Documentation Le Percepteur

- Assurer les formalités d’affiliation - Percevoir les frais administratifs

et d’adhésion des artistes et pour les formalités d’adhésion
autres créateurs d’œuvre d’esprit
- Veiller aux conditions d’admission La Caissière
Le Documentaliste

Context Diagram Mémoire AMUNDALA SAÏDI Joscal

SYSMIGRA

Figure I.1. : Diagramme de contexte GEST.DR.AU.

I.2. Spécification initiale du système

A ce niveau, il est vital de répondre à certaines questions utiles afin

de mieux comprendre les spécificités du système que nous allons mettre en
place.

1. A qui l’application est – elle destinée ?

Cette application destinée à la SOCODA COOP-CA afin de faciliter

l’adhésion pour des auteurs d’œuvre de l’esprit ainsi que l’identification des
usagers ou assujettis ou encore sociétés qui posent des actes qui génèrent le
paiement de redevance due aux droits d’auteur.
 65

2. Quels problèmes l’application résoudra – t – elle ?

Cette application a pour but de permettre une bonne gestion des

droits d’auteur allant de l’enregistrement des auteurs ainsi que de leurs
œuvres jusqu’au paiement de leur redevance. Elle permettra également aux
responsables des différentes entités de pouvoir fournir un bon rapport à leur
hiérarchie pour une bonne prise de décision.

3. Où l’application sera – t – elle utilisée ?

L’application sera répartie sur le réseau d’ordinateur de SOCODA

COOP-CA, chaque site aura une interface spécifique lui permettant soit de
fournir les données soit d’en récupérer pour un usage particulier.

4. Pourquoi l’application est – elle attendue ?

Avec une amélioration dans la disponibilité des données sur la

gestion collective des droits d’auteur, le nouveau système permettra à la
SOCODA COOP-CA d’optimiser la gestion des auteurs d’œuvre de l’esprit.
Ceci a pour principal avantage d’assurer en temps record la disponibilité des
données dans les différentes entités ou délégations pour faciliter la gestion
collective des droits d’auteur.

5. Comment l’application fonctionnera – t – elle ?

Le nouveau système fonctionnera selon une architecture client-

serveur, précisément architecture 3-tiers, avec une couche de données, une
couche présentation et un client web.

I.3. Cahier des charges

De ce qui précède, nous pouvons élaborer dans les lignes qui

suivent le cahier de charges de notre système.

Le Directeur Général est chargé de la gestion quotidienne de la

société. Il représente la société dans ses rapports avec toute personne
morale ou physique, conclut les accords de représentation réciproque avec
les sociétés sœurs puis répond aux diverses courriers, beaucoup plus aussi
pour celui concernant l’adhésion suivant le rapport du Directeur de la
Documentation. Le Directeur Général est identifié par un nom, un post nom
et un prénom.

Le Directeur de la Documentation est chargé d’examiner le dossier

des adhérents ainsi que tous les ayants-droits avec leurs œuvres. Il est
identifié par un numéro matricule, un nom, un post nom et un prénom.

Le Documentaliste est chargé d’assurer les formalités d'affiliation et

d'adhésion des artistes et autres créateurs des œuvres de l'esprit protégées
 66

par la loi, veiller aux conditions d'admission pour les sociétaires et les
adhérents tels que prévue dans le Règlement Général. Il est identifié par un
numéro matricule, un nom, un post nom et un prénom.

La caissière est chargée de percevoir tous les frais administratifs

pour tout ce qui concerne les formalités administratives. Elle est identifiée par
un numéro matricule, un nom, un post nom et un prénom.

Le Percepteur est chargé d’identifier toutes les sociétés qui posent

les actes qui génèrent les droits d’auteur et procède à la négociation avec
lesdites sociétés puis à leur taxation. Il est identifié par un numéro matricule,
un nom, un post nom et un prénom.

L’Inspecteur est chargé de faire le suivi auprès des usagers, les

sociétés qui posent les actes qui génèrent la redevance des droits d’auteur,
pour savoir si ces derniers ont payé leur redevance. Il est identifié par un
numéro matricule, un nom, un post nom et un prénom.

Le système doit pouvoir produire les différents rapports pour la

traçabilité de chaque opération réalisée dans le système.

I.4. Détermination de la technologie.

Pour faciliter la mise en place de notre système, nous avons choisi

d’utiliser les technologies et outils suivants :

• Le langage UML pour modéliser notre système.

Se définissant comme étant un langage de modélisation
graphique et textuel destiné à comprendre et décrire des besoins, spécifier
et documenter des systèmes, esquisser des architectures logicielles,
concevoir des solutions et communiquer des points de vue, le langage UML,
pour Unified Modeling Language, permet d’une manière générale de faire
plusieurs projections d’un système informatique. Et cela principalement à
travers deux vues dont l’une permet de voir dynamiquement le
fonctionnement du système à mettre en place et l’autre statique permet la
représentation physique du futur système. C’est le langage le plus
recommandé en ingénierie des logiciels.

UML unifie des méthodes objet, et plus particulièrement les

méthodes Booch’93 de Grady Booch, OMT -2 (Object Modeling Technique)
de James Rumbaugh et OOSE (Object- Oriented Software Engineering)
d’Ivar Jacobson. UML est à présent un standard adopté par l'Object
Management Group (OMG). UML 1.0 a été normalisé en janvier 1997 ; UML
2.0 a été adopté par l'OMG en juillet 2005. La dernière version de la
spécification validée par l'OMG est UML 2.5.1 (2017).
 67

• MySQL étant un système de gestion de base de données utilisé comme

serveur de base de données de notre système.

La seule raison que nous avons opté pour MySQL est sa souplesse,
sa maintenance et la facilité de mettre en place une base de données.

• C# comme plateforme de programmation.

Nous l’avons choisi vu sa simplicité de mise en place des
applications.

I.5. Définition de l’architecture du système.

Les notions sur l’architecture du système distribué ayant été

abordées à la première partie de ce travail, cela nous permet de présenter
ici d’une manière brève l’architecture de notre système.

De toutes ces architectures, nous avons opté utiliser l’architecture

client-serveur pour la simple raison, la bonne maintenance du futur système
et la facilitation dans la gestion des droits d’auteur au niveau de la SOCODA
COOP-CA.

Avec
Figure I.2 : Architecture du Système GEST.DR.AU.
navigateur
I.6. Analyse de domaine

a. Diagramme de cas d'utilisation

• Le cas d’utilisation pour la déclaration

Le processus de déclaration d’une œuvre par un artiste à la
SOCODA COOP-CA se présente comme suit :

« L’artiste se présente dans à la SOCODA COOP-CA et remplit un formulaire

de demande d’adhésion avec l’exemplaire de l’œuvre à déclarer qui sera
présenter au Directeur Général. Le Directeur Général demande au Directeur
de la Documentation de vérifier si l’œuvre n’est pas déjà enregistrée au nom
d’un autre artiste. Après réponse de la Documentation, si ce n’est pas
l’œuvre n’a jamais été déclarée par un autre artiste, alors le Directeur
Général répond à l’artiste pour autoriser son adhésion à la société pour la
 68

déclaration des œuvres. L’artiste se présente chez la Documentaliste qui va

lui remettre les formulaires d’adhésion, de contrat de cession et par la fin les
relevés des œuvres déclarées ».

Tableau I.1. Tableau de scenario du processus de déclaration

Cas Déclaration

Résumé Procédure de déclaration d’œuvre décrite ci-haut jusqu’à

l’adhésion

Acteur primaire Artiste (Créateur)

Acteur secondaire Directeur Général, Directeur de la Documentation et

Documentaliste

Précondition Vérification de l’œuvre à déclarer et de l’artiste (créateur)

Résultat Adhésion et déclaration des œuvres

Exception Pas de déclaration d’œuvre si l’œuvre a déjà été déclarée

par un autre artiste (créateur)

Description 1. L’artiste (créateur) présente sa demande d’adhésion

2. La demande d’adhésion est envoyée chez le Directeur
Général
3. Le Directeur Général envoie le dossier pour vérification
auprès du Directeur de la Documentation
4. Le Directeur de la Documentation répond au Directeur
Général que l’œuvre n’a pas été déclarée par quelqu’un
d’autre ;
5. Le Directeur Général répond à l’artiste

Remise formulaire
Demande
d’adhésion
d’adhésion « include »
 69

Figure I.3. : Diagramme de cas d’utilisation pour la déclaration

• Le cas d’utilisation pour la taxation et paiement des redevances

Le processus pour la taxation et le paiement des redevances dues
aux droits d’auteur se présente comme suit :

« Le percepteur procède à l’identification des usagers ou des sociétés qui

posent des actes qui génèrent le paiement de la redevance des droits
d’auteur. Après identification des usagers, il recueille les actes générateurs
de ce dernier puis établit un procès-verbal de constat des actes générateurs
puis procède à la taxation de chaque acte générateur sur base du barème
tarifaire. Après taxation, l’usager peut négocier pour le montant à payer
après quoi, la caisse va élaborer une note de perception pour le paiement
de la redevance. L’usager, après réception de la note de perception,
procède au paiement de la redevance ».

Tableau I.2. Tableau de scenario du processus de taxation et paiement

Cas Taxation et paiement

Résumé Procédure de taxation et paiement de la redevance des

droits d’auteur

Acteur primaire Usager

Acteur secondaire Percepteur, Caissière

Précondition Identification des actes générateurs

 70

Résultat Taxation et paiement de la redevance des droits d’auteur

Exception Pas de paiement si l’usager ne pose aucun acte qui

génère le paiement de la redevance.

Description 1. Le percepteur identifie un usager

2. Le percepteur établit un procès-verbal de constat des
actes générateurs, calcule la redevance à payer sur
base d’un barème tarifaire puis procède à la taxation
3. L’usager négocie sur le montant à payer
4. La caisse établit une note de perception pour l’usager
5. L’usager procède au paiement de la redevance

Utilisation « include » Identifier

d’œuvre
usager

« include » « include »

Établissement de Agent
Poser un acte procès-verbal (Percepteur)
générateur

Usager
Fixation barème
tarifaire
Paiement
redevance Taxation

« include » Percevoir la
P.M P.P redevance
« include »
Négociation
Légende : de barème Authentification Agent
« include »
(Caissier)
- P.M :
Établissement de
Personne note de perception
Morale
- P.P : Personne
physique
Figure I.4. : Diagramme de cas d’utilisation pour la taxation et le paiement
 71

b. Diagramme de classes
Déclarer Taxer
1 … 1 … 1 … 1 … 1 … Identifier 1
Artiste Œuvre Usager Agent
* * * * *
# IdArt int # IdOeuv int # IdUs int # Matr string
+ Nom string + Titre string + NmUs string + Nom string
+ PstNom string Déclaration + Genre string Taxation + Adress string + PstNom string
+ PreNom string + NumTel int + PreNom string
# IdArt int + Enregistrer() : void # IdAss int
+ Pseudo string + Email string + Adress string
# IdOeuv int + Modifier() : void # IdOeuv int
+ Adress string + Afficher() : string + Activ string + NumTel int
+ DateDecl date + DateTax date
+ NumTel int + FormJu string + Email string
+ Barem string
+ Email string + Enregistrer() : void + Secteur string + Fonct string
+ Obs string
+ Filier string + Grad string
+ Discipl string + Enregistrer() : void + Enregistrer() : void
+ Modifier() : void + Enregistrer() : void
+ Afficher() : string + Modifier() : void
+ Enregistrer() : void
+ Modifier() : void + Afficher() : string
+ Afficher() : string 1 …
*

Payer
Paiement
# IdUs int
# IdRed int
Adhérent Sociétaire 1 …
+ DatePaie date
*
+ Motif string
# IdAdh int # IdSoc int Redevance + Obs string
+ QualAdh string + QualSoc string
# IdRed int + Enregistrer() : void
+ Enregistrer() : void + Enregistrer() : void + LibRed string
+ Modifier() : void + Modifier() : void
+ Afficher() : string + Afficher() : string + Enregistrer() : void
+ Modifier() : void
+ Afficher() : string

Figure I.5 : Diagramme de classes

 72

c. Diagramme de séquence

• Diagramme de séquence pour le cas de la déclaration

Agent Agent Agent

Artiste (Documentaliste) (Directeur Général) (Dir. Documentation)

Demande d’adhésion
() Envoie requête demande ()

Vérification disponibilité ()
Avis favorable ()

Présenter œuvre () Vérification

œuvre existante
Œuvre non enregistrée ()
()
Autorisation d’enregistrer ()
Remise formulaire
()

Remplir formulaire () Traitement ()

Œuvre déclarée ()

Signer contrat ()
Contrat de cession envoyé ()
Validation ()
Adhésion à la société ()

Figure I.6 : Diagramme de séquence pour la déclaration

• Diagramme de séquence pour le cas de la taxation et paiement

Usager Percepteur Caissier

1: Identification ()

2: Taxation ()

3: Négociation ()

4: Transmission Note de Perception ()

4.1: Paiement redevance

Figure I.7 : Diagramme de séquence pour la taxation et le paiement

 73

d. Diagramme d'activités

• Diagramme d’activités pour la déclaration

Demande d’adhésion

Vérification de la demande

Indisponible

Disponible

Présentation de l’œuvre

Invalide

Valide

Remplir formulaire

Signer contrat

Figure I.8 : Diagramme d’activités pour la déclaration

 74

• Diagramme de séquence pour le cas de la taxation et paiement

Identification usager

Acte non posé

Acte posé

Procès-verbal de constat

Taxation

Négociation

Non aboutie

Aboutie

Transmission note de perception

Paiement redevance

Figure I.9 : Diagramme d’activités pour la taxation et le paiement

e. Diagramme de déploiement

MySQL
Server
WEB SERVICE
SOAP / WSDL
Site A

SQL
Server

Site B

Figure I.10 : Diagramme de déploiement

 75

CHAPITRE II : IMPLEMENTATION DU NOUVEAU SYSTEME

Dans le présent chapitre, nous allons décrire les différentes étapes
d’implémentation de notre application qui au final un service web hébergé
dans un serveur et se connectant à une base des données MySQL Server
précisément. Ce service web est en sorte une plateforme permettant à nos
différents sites de pouvoir se communiquer en vue d’obtenir une seule
plateforme gérant la déclaration, la taxation et le paiement des redevances.

II.1. Implantation d'une base de données

II.1.1. Choix de Système de Gestion de Base de Données

MySQL est un système de gestion de bases de données

relationnelles (SGBDR). Il est distribué sous une double licence GPL et
propriétaire. Il fait partie des logiciels de gestion de base de données les plus
utilisés au monde, autant par le grand public (applications web
principalement) que par des professionnels, en concurrence avec Oracle
et/ou Microsoft SQL Server.

Son nom vient du prénom de la fille du Co créateur Michael

Widenius, My (Sv) (prononcer [My]). SQL fait référence au Structured Quercy
Language, le langage de requête utilisé.

II.1.2. Création de la base de données et des tables

Voici ci-dessous quelques scripts de la création des tables de notre

base de données :
CREATE DATABASE `bd_memoire`;

CREATE TABLE `bd_memoire`.`artiste` ( `Id_Art` INT(5) NOT NULL AUTO_INCREME

NT , `Nm_Art` VARCHAR(30) NOT NULL , `PstNm_Art` VARCHAR(30) NOT NULL , `Pr
eNm_Art` VARCHAR(30) NOT NULL , `Pseudo_Art` VARCHAR(30) NOT NULL , `Sex_Ar
t` VARCHAR(10) NOT NULL, `Adress_Art` VARCHAR(100) NOT NULL , `NumTel_Art`
INT(10) NOT NULL , `Email_Art` VARCHAR(30) NOT NULL , `Filier_Art` VARCHAR
(30) NOT NULL , `Discipl_Art` VARCHAR(50) NOT NULL , `Typ_Art` VARCHAR(30)
NOT NULL , PRIMARY KEY (`Id_Art`)) ENGINE = InnoDB;

CREATE TABLE `bd_memoire`. `declaration`( `Id_Art` INT(5) NOT NULL , `Id_Oe

uv` INT(5) NOT NULL , `DatDecl` DATE NOT NULL , INDEX `Id_Art` (`Id_Art`),
INDEX `Id_Oeuv` (`Id_Oeuv`)) ENGINE = InnoDB;

CREATE TABLE `bd_memoire`.`usager` ( `Id_Us` INT(5) NOT NULL AUTO_INCREMENT

,
Matr_Agent` INT(5) NOT NULL, `Nm_Us` VARCHAR(30) NOT NULL , `Adress_Us` VAR
CHAR(100) NOT NULL , `NumTel_Us` INT(10) NOT NULL , `Email_Us` VARCHAR(30)
NOT NULL , `Activ_Us` VARCHAR(30) NOT NULL , `FormJu_Us` VARCHAR(30) NOT NU
 76

LL , `Secteur_Us` VARCHAR(30) NOT NULL , PRIMARY KEY (`Id_Us`),

INDEX `Matr_Agent` (`Matr_Agent`)) ENGINE = InnoDB;

CREATE TABLE `bd_memoire`.`agent` ( `Matr_Agent` INT(3) NOT NULL AUTO_INCRE

MENT , `Nm_Agent` VARCHAR(30) NOT NULL , `PstNm_Agent` VARCHAR(30) NOT NULL
, `PreNm_Agent` VARCHAR(30) NOT NULL , `Sex_Agent` VARCHAR(10) NOT NULL ,
`Adress_Agent` VARCHAR(100)NOT NULL , `NumTel_Agent` INT(10) NOT NULL , `Em
ail_Agent` VARCHAR(30) NOT NULL , `Fonct_Agent` VARCHAR(30) NOT NULL , `Gra
d_Agent` VARCHAR(30) NOT NULL , PRIMARY KEY (`Matr_Agent`)) ENGINE = InnoDB
;

• Table Artiste

• Table Déclaration
 77

• Table Usager

• Table Agent

II.1.4. Relation entre les tables

Voici ci-dessous quelques scripts de la création de relation entre les

tables de notre base de données :
ALTER TABLE `usager` ADD CONSTRAINT `usager_agent` FOREIGN KEY (`Id_Us`) RE
FERENCES `agent`(`Id_Us`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `oeuvre` ADD CONSTRAINT `oeuvre_artiste` FOREIGN KEY (`Id_Oeuv’

) REFERENCES `declaration`(`Id_Oeuv`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `oeuvre` ADD CONSTRAINT `oeuvre_usager` FOREIGN KEY (`Id_Oeuv`)

REFERENCES `taxation`(`Id_Oeuv`) ON DELETE CASCADE ON UPDATE CASCADE;
78
 79

II.2. Programmation

II.2.1. Présentation des différents outils de développement

Comme outils de développement, nous avons choisi les langages

C# et Java afin d’implémenter notre web service.

II.2.2. Implémentation de service

Notre service web RestFul sera créer via le langage de

programmation Java, mais pour ce faire nous allons commencer par la
connexion avec notre base de données en utilisant la méthode API JPA en
passant par le design pattern.

Voici ci-dessous quelques étapes essentielles pour la création de

notre web service.

1. Création projet avec JAVA

a. Ajouter une bibliothèque (API JDBC)

 80

b. Ajouter les entités émanant de la base des données

c. Création de la connexion avec la base des données

d. Transfert des tables

 81

e. Les classes émanant de la base des données

f. La représentation finale de notre projet

g. Script de la table Agent importée

/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package tables;

import java.io.Serializable;
import javax.persistence.Basic;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.NamedQueries;
 82

import javax.persistence.NamedQuery;
import javax.persistence.Table;
import javax.xml.bind.annotation.XmlRootElement;

/**
*
* @author hp
*/
@Entity
@Table(name = "agent")
@XmlRootElement
@NamedQueries({
@NamedQuery(name = "Agent.findAll", query = "SELECT a FROM Agent a"),
@NamedQuery(name = "Agent.findByMatrAgent", query = "SELECT a FROM Agent a
WHERE a.matrAgent = :matrAgent"),
@NamedQuery(name = "Agent.findByIdUs", query = "SELECT a FROM Agent a WHERE
a.idUs = :idUs"),
@NamedQuery(name = "Agent.findByNmAgent", query = "SELECT a FROM Agent a
WHERE a.nmAgent = :nmAgent"),
@NamedQuery(name = "Agent.findByPstNmAgent", query = "SELECT a FROM Agent a
WHERE a.pstNmAgent = :pstNmAgent"),
@NamedQuery(name = "Agent.findByPreNmAgent", query = "SELECT a FROM Agent a
WHERE a.preNmAgent = :preNmAgent"),
@NamedQuery(name = "Agent.findBySexAgent", query = "SELECT a FROM Agent a
WHERE a.sexAgent = :sexAgent"),
@NamedQuery(name = "Agent.findByAdressAgent", query = "SELECT a FROM Agent a
WHERE a.adressAgent = :adressAgent"),
@NamedQuery(name = "Agent.findByNumTelAgent", query = "SELECT a FROM Agent a
WHERE a.numTelAgent = :numTelAgent"),
@NamedQuery(name = "Agent.findByEmailAgent", query = "SELECT a FROM Agent a
WHERE a.emailAgent = :emailAgent"),
@NamedQuery(name = "Agent.findByFonctAgent", query = "SELECT a FROM Agent a
WHERE a.fonctAgent = :fonctAgent"),
@NamedQuery(name = "Agent.findByGradAgent", query = "SELECT a FROM Agent a
WHERE a.gradAgent = :gradAgent")})
public class Agent implements Serializable {

private static final long serialVersionUID = 1L;

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Basic(optional = false)
@Column(name = "Matr_Agent")
private Integer matrAgent;
@Basic(optional = false)
@Column(name = "Id_Us")
private int idUs;
@Basic(optional = false)
@Column(name = "Nm_Agent")
private String nmAgent;
@Basic(optional = false)
@Column(name = "PstNm_Agent")
private String pstNmAgent;
@Basic(optional = false)
@Column(name = "PreNm_Agent")
private String preNmAgent;
@Basic(optional = false)
@Column(name = "Sex_Agent")
private String sexAgent;
@Basic(optional = false)
@Column(name = "Adress_Agent")
private String adressAgent;
@Basic(optional = false)
@Column(name = "NumTel_Agent")
private int numTelAgent;
@Basic(optional = false)
 83

@Column(name = "Email_Agent")
private String emailAgent;
@Basic(optional = false)
@Column(name = "Fonct_Agent")
private String fonctAgent;
@Basic(optional = false)
@Column(name = "Grad_Agent")
private String gradAgent;

public Agent() {
}

public Agent(Integer matrAgent) {

this.matrAgent = matrAgent;
}

public Agent(Integer matrAgent, int idUs, String nmAgent, String pstNmAgent,

String preNmAgent, String sexAgent, String adressAgent, int numTelAgent, String
emailAgent, String fonctAgent, String gradAgent) {
this.matrAgent = matrAgent;
this.idUs = idUs;
this.nmAgent = nmAgent;
this.pstNmAgent = pstNmAgent;
this.preNmAgent = preNmAgent;
this.sexAgent = sexAgent;
this.adressAgent = adressAgent;
this.numTelAgent = numTelAgent;
this.emailAgent = emailAgent;
this.fonctAgent = fonctAgent;
this.gradAgent = gradAgent;
}

public Integer getMatrAgent() {

return matrAgent;
}

public void setMatrAgent(Integer matrAgent) {

this.matrAgent = matrAgent;
}

public int getIdUs() {

return idUs;
}

public void setIdUs(int idUs) {

this.idUs = idUs;
}

public String getNmAgent() {

return nmAgent;
}

public void setNmAgent(String nmAgent) {

this.nmAgent = nmAgent;
}

public String getPstNmAgent() {

return pstNmAgent;
}

public void setPstNmAgent(String pstNmAgent) {

this.pstNmAgent = pstNmAgent;
}

public String getPreNmAgent() {

 84

return preNmAgent;
}

public void setPreNmAgent(String preNmAgent) {

this.preNmAgent = preNmAgent;
}

public String getSexAgent() {

return sexAgent;
}

public void setSexAgent(String sexAgent) {

this.sexAgent = sexAgent;
}

public String getAdressAgent() {

return adressAgent;
}

public void setAdressAgent(String adressAgent) {

this.adressAgent = adressAgent;
}

public int getNumTelAgent() {

return numTelAgent;
}

public void setNumTelAgent(int numTelAgent) {

this.numTelAgent = numTelAgent;
}

public String getEmailAgent() {

return emailAgent;
}

public void setEmailAgent(String emailAgent) {

this.emailAgent = emailAgent;
}

public String getFonctAgent() {

return fonctAgent;
}

public void setFonctAgent(String fonctAgent) {

this.fonctAgent = fonctAgent;
}

public String getGradAgent() {

return gradAgent;
}

public void setGradAgent(String gradAgent) {

this.gradAgent = gradAgent;
}

@Override
public int hashCode() {
int hash = 0;
hash += (matrAgent != null ? matrAgent.hashCode() : 0);
return hash;
}

@Override
public boolean equals(Object object) {
 85

// TODO: Warning - this method won't work in the case the id fields are
not set
if (!(object instanceof Agent)) {
return false;
}
Agent other = (Agent) object;
if ((this.matrAgent == null && other.matrAgent != null) ||
(this.matrAgent != null && !this.matrAgent.equals(other.matrAgent))) {
return false;
}
return true;
}

@Override
public String toString() {
return "tables.Agent[ matrAgent=" + matrAgent + " ]";
}

2. Création service web RESTful

a. Création d’une connexion Pool via GlassFish

 86

b. Création de JDBC ressource

 87

c. Etape de la création du web service RESTful

 88

d. Transfert table

e. Résultat
 89

f. Code AbstractFacade.java
/*
* To change this license header, choose License Headers in Project Properties.
* To change this template file, choose Tools | Templates
* and open the template in the editor.
*/
package entites.service;

import java.util.List;
import javax.persistence.EntityManager;

/**
*
* @author hp
*/
public abstract class AbstractFacade<T> {

private Class<T> entityClass;

public AbstractFacade(Class<T> entityClass) {

this.entityClass = entityClass;
}

protected abstract EntityManager getEntityManager();

public void create(T entity) {

getEntityManager().persist(entity);
}

public void edit(T entity) {

getEntityManager().merge(entity);
}

public void remove(T entity) {

getEntityManager().remove(getEntityManager().merge(entity));
}

public T find(Object id) {

return getEntityManager().find(entityClass, id);
}

public List<T> findAll() {

javax.persistence.criteria.CriteriaQuery cq =
getEntityManager().getCriteriaBuilder().createQuery();
cq.select(cq.from(entityClass));
return getEntityManager().createQuery(cq).getResultList();
}

public List<T> findRange(int[] range) {

javax.persistence.criteria.CriteriaQuery cq =
getEntityManager().getCriteriaBuilder().createQuery();
cq.select(cq.from(entityClass));
javax.persistence.Query q = getEntityManager().createQuery(cq);
q.setMaxResults(range[1] - range[0] + 1);
q.setFirstResult(range[0]);
return q.getResultList();
}

public int count() {

javax.persistence.criteria.CriteriaQuery cq =
getEntityManager().getCriteriaBuilder().createQuery();
 90

javax.persistence.criteria.Root<T> rt = cq.from(entityClass);
cq.select(getEntityManager().getCriteriaBuilder().count(rt));
javax.persistence.Query q = getEntityManager().createQuery(cq);
return ((Long) q.getSingleResult()).intValue();
}

II.2.3. Interface Homme-machine et quelques codes sources

a) Chargement

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace SOCODA
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

private void timer1_Tick(object sender, EventArgs e)

{
panel2.Width += 3;

if (panel2.Width >= 1000)

{
timer1.Stop();
Connection page = new Connection();
page.Show();
this.Hide();
}
}
}
}
 91

b) Formulaire de connexion

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace SOCODA
{
public partial class Connection : Form
{
public Connection()
{
InitializeComponent();
}

private void QuitterBtn_Click(object sender, EventArgs e)

{
if (MessageBox.Show("Quitter l'application ?", "Gestion des droits
d'auteur", MessageBoxButtons.YesNo, MessageBoxIcon.Stop) == DialogResult.Yes)
{
this.Close();
Application.Exit();
}
}

private void guna2CheckBox1_CheckedChanged(object sender, EventArgs e)

{
if(guna2CheckBox1.Checked)
 92

{
maskedTextBox1.UseSystemPasswordChar = false;
}
else
{
maskedTextBox1.UseSystemPasswordChar = true;
}
}

private void ConnecterBtn_Click(object sender, EventArgs e)

{
if(textBox1.Text == "" || maskedTextBox1.Text =="")
{
MessageBox.Show("Veuillez remplir le formulaire !");
}
else
{
if(textBox1.Text =="Joscal" && maskedTextBox1.Text =="joskitoko")
{
Menu amu = new Menu();
amu.Show();
this.Hide();
}
else
{
MessageBox.Show("Information incorrecte !!!");
}

}
}
}
}

c) Enregistrement Artiste

using System;
 93

using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

// importer la base des données

using MySql.Data.MySqlClient;

namespace SOCODA
{
public partial class Artiste : Form
{
public Artiste()
{
InitializeComponent();
}

private void EnregistBtn_Click(object sender, EventArgs e)

{
MySqlConnection connect = new
MySqlConnection("database=bd_memoire;server=localhost;user
id=root;pwd=;SslMode=none");

string requete2 = "Insert into artiste(Nm_Art,

PstNm_Art,PreNm_Art,Pseudo_Art,Sex_Art,Adress_Art,NumTel_Art,Email_Art,Filier_Art
,Discipl_Art,Typ_Art)" +
"values (@Nm_Art,
@PstNm_Art,@PreNm_Art,@Pseudo_Art,@Sex_Art,@Adress_Art,@NumTel_Art,@Email_Art,@Fi
lier_Art,@Discipl_Art,@Typ_Art)";

MySqlCommand cmd2 = new MySqlCommand(requete2, connect);

cmd2.Parameters.AddWithValue("@Nm_Art", Nm.Text);
cmd2.Parameters.AddWithValue("@PstNm_Art", PstNm.Text);
cmd2.Parameters.AddWithValue("@PreNm_Art", PreNm.Text);
cmd2.Parameters.AddWithValue("@Pseudo_Art", PsdNm.Text);
cmd2.Parameters.AddWithValue("@Sex_Art", Sex.Text);
cmd2.Parameters.AddWithValue("@Adress_Art", Adress.Text);
cmd2.Parameters.AddWithValue("@NumTel_Art", Tel.Text);
cmd2.Parameters.AddWithValue("@Email_Art", Mail.Text);
cmd2.Parameters.AddWithValue("@Filier_Art", Fil.Text);
cmd2.Parameters.AddWithValue("@Discipl_Art", Disc.Text);
cmd2.Parameters.AddWithValue("@Typ_Art", TypArt.Text);

Nm.Clear();
PstNm.Clear();
PreNm.Clear();
PsdNm.Clear();
Adress.Clear();
Tel.Clear();
Mail.Clear();
Disc.Clear();

int n = 0;

try
{
connect.Open();
n = cmd2.ExecuteNonQuery();
connect.Close();

if (n > 0)
 94

{
MessageBox.Show("Enregistrement effectué avec succès !");
}
}
catch (Exception ex)
{
connect.Close();
MessageBox.Show(ex.Message);
}
}

MySqlConnection connect = new

MySqlConnection("database=bd_memoire;server=localhost;user
id=root;pwd=;SslMode=none");

private void Afficher_Click_1(object sender, EventArgs e)

{

try
{

connect.Open();
string requete = "Select * from artiste";
MySqlCommand cmd = new MySqlCommand(requete, connect);
MySqlDataReader reader = cmd.ExecuteReader();
DataGridView1.Rows.Clear();
while (reader.Read())
{
DataGridView1.Rows.Add(reader[0].ToString(),
reader[1].ToString(), reader[2].ToString(), reader[3].ToString(),
reader[4].ToString(),
reader[5].ToString(), reader[6].ToString(),
reader[7].ToString(), reader[8].ToString(), reader[9].ToString(),
reader[10].ToString(),
reader[11].ToString());
}
connect.Close();
}
catch
{
connect.Close();
MessageBox.Show("Desolé le serveur est éteint !");
}
}

int a;
private void DataGridView_CellContentClick(object sender,
DataGridViewCellEventArgs e)
{
a=e.RowIndex;
DataGridViewRow row = DataGridView1.Rows[a];
Nm.Text = row.Cells[1].Value.ToString();
PstNm.Text = row.Cells[2].Value.ToString();
PreNm.Text = row.Cells[3].Value.ToString();
PsdNm.Text = row.Cells[4].Value.ToString();
Sex.Text = row.Cells[5].Value.ToString();
Adress.Text=row.Cells[6].Value.ToString();
Tel.Text=row.Cells[7].Value.ToString();
Mail.Text=row.Cells[8].Value.ToString();
Disc.Text=row.Cells[9].Value.ToString();
TypArt.Text = row.Cells[10].Value.ToString();
}

private void SupBtn_Click(object sender, EventArgs e)

{
 95

if (MessageBox.Show("Voulez-vous supprimer ?", "Gestion des droits

d'auteur", MessageBoxButtons.YesNo, MessageBoxIcon.Stop) == DialogResult.Yes)
{
a = Convert.ToInt32(DataGridView1.CurrentRow.Cells[0].Value);
string requete = "delete from artiste where id =" + a;
MySqlCommand cmd = new MySqlCommand(requete, connect);

try
{
connect.Open();
cmd.ExecuteNonQuery();
connect.Close();
}
catch (Exception ex)
{
connect.Close();
MessageBox.Show(ex.Message);
}
}

private void Quit_Click(object sender, EventArgs e)

{
if (MessageBox.Show("Quitter l'application ?", "Gestion des droits
d'auteur", MessageBoxButtons.YesNo, MessageBoxIcon.Stop) == DialogResult.Yes)
{
this.Close();
Application.Exit();
}
}

private void Retour_Click(object sender, EventArgs e)

{
Enregistrement amu = new Enregistrement();
amu.Show();
this.Hide();
}

private void Home_Click(object sender, EventArgs e)

{
Menu mainMenu = new Menu();
mainMenu.Show();
this.Hide();
}

private void ModifBtn_Click(object sender, EventArgs e)

{
a = Convert.ToInt32(DataGridView1.CurrentRow.Cells[0].Value);
string requete = "Update artiste set Nm_Art=@Nm,
PstNm_Art=@PstNm,PreNm_Art=@PreNm,Pseudo_Art=@PsdNm,Sex_Art=@Sex,Adress_Art=@Adre
ss," +

"NumTel_Art=@Tel,Email_Art=@Mail,Filier_Art=@Fil,Discipl_Art=@Disc,Typ_Art=@TypAr
t where id = @id" + a;
MySqlCommand cmd = new MySqlCommand(requete, connect);

cmd.Parameters.AddWithValue("@id", MySqlDbType.Int32);
cmd.Parameters.AddWithValue("@Nm", Nm.Text);
cmd.Parameters.AddWithValue("@PstNm", PstNm.Text);
cmd.Parameters.AddWithValue("@PreNm", PreNm.Text);
cmd.Parameters.AddWithValue("@PsdNm", PsdNm.Text);
cmd.Parameters.AddWithValue("@Sex", Sex.Text);
cmd.Parameters.AddWithValue("@Adress", Adress.Text);
cmd.Parameters.AddWithValue("@Tel", Tel.Text);
 96

cmd.Parameters.AddWithValue("@Mail", Mail.Text);
cmd.Parameters.AddWithValue("@Fil", Fil.Text);
cmd.Parameters.AddWithValue("@Disc", Disc.Text);
cmd.Parameters.AddWithValue("@TypArt", TypArt.Text);

Nm.Clear();
PstNm.Clear();
PreNm.Clear();
PsdNm.Clear();
Adress.Clear();
Tel.Clear();
Mail.Clear();
Disc.Clear();

try
{
connect.Open();
cmd.ExecuteNonQuery();
connect.Close();
}
catch (Exception ex)
{
connect.Close();
MessageBox.Show(ex.Message);
}
}
}

d) Enregistrement Usager

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
 97

using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

//importer la base de données

using MySql.Data.MySqlClient;

namespace SOCODA
{
public partial class Usager : Form
{
public Usager()
{
InitializeComponent();
}

int a = 0;
MySqlConnection connect = new
MySqlConnection("database=bd_memoire;server=localhost;user
id=root;pwd=;SslMode=none");

private void DataGridView1_CellContentClick(object sender,

DataGridViewCellEventArgs e)
{
a = e.RowIndex;
DataGridViewRow row = DataGridView1.Rows[a];
Nm.Text = row.Cells[1].Value.ToString();
Adress.Text = row.Cells[2].Value.ToString();
Tel.Text = row.Cells[3].Value.ToString();
Mail.Text = row.Cells[4].Value.ToString();
Activ.Text = row.Cells[5].Value.ToString();
FormJu.Text = row.Cells[6].Value.ToString();
SecActiv.Text = row.Cells[7].Value.ToString();
}

private void Afficher_Click(object sender, EventArgs e)

{
try
{

connect.Open();
string requete = "Select * from usager";
MySqlCommand cmd = new MySqlCommand(requete, connect);
MySqlDataReader reader = cmd.ExecuteReader();
DataGridView1.Rows.Clear();
while (reader.Read())
{
DataGridView1.Rows.Add(reader[0].ToString(),
reader[1].ToString(), reader[2].ToString(), reader[3].ToString(),
reader[4].ToString(),
reader[5].ToString(), reader[6].ToString(),
reader[7].ToString());
}
connect.Close();
}
catch
{
connect.Close();
MessageBox.Show("Desolé le serveur est éteint !");
}
}

private void EnregistBtn_Click(object sender, EventArgs e)

 98

{
string requete2 = "Insert into usager(Nm_Us,
Adress_Us,NumTel_Us,Email_Us,Activ_Us,FormJu_Us,Secteur_Us)" +
"values (@Nm,
@Adress,@NumTel,@Email,@Activ,@FormJu,@Secteur)";

MySqlCommand cmd2 = new MySqlCommand(requete2, connect);

cmd2.Parameters.AddWithValue("@Nm", Nm.Text);
cmd2.Parameters.AddWithValue("@Adress", Adress.Text);
cmd2.Parameters.AddWithValue("@NumTel", Tel.Text);
cmd2.Parameters.AddWithValue("@Email", Mail.Text);
cmd2.Parameters.AddWithValue("@Activ", Activ.Text);
cmd2.Parameters.AddWithValue("@FormJu", FormJu.Text);
cmd2.Parameters.AddWithValue("@Secteur", SecActiv.Text);

Nm.Clear();
Adress.Clear();
Tel.Clear();
Mail.Clear();
Activ.Clear();
FormJu.Clear();
SecActiv.Clear();

int n = 0;

try
{
connect.Open();
n = cmd2.ExecuteNonQuery();
connect.Close();

if (n > 0)
{
MessageBox.Show("Enregistrement effectué avec succès !");
}
}
catch (Exception ex)
{
connect.Close();
MessageBox.Show(ex.Message);
}
}
}
}
 99

CONCLUSION
Etant à une période où les avancées technologiques croissent
chaque jour, l’être humain est appelé à s’investir afin d’automatiser le
traitement de l’information au moyen de l’ordinateur.

Touchant au terme de notre travail qui portait sur la mise en œuvre

d’une architecture orientée service dans un système distribué pour la gestion
des droits d’auteur avec comme cas la SOCODA COOP-CA, nous nous
sommes donné de la peine d’élaborer un travail visant la conception et
implémentation d’un système informatisé suivant l’approche objet. Cela nous
a été rendu possible grâce au langage de modélisation UML. Nous avons fait
évoluer l’application en fonction des besoins réels des utilisateurs et des
progrès technologiques. Nous avons dû créer les bases de données en
MySQL SERVER 5.5, la programmation a été faite en C# 2022 et mettant en
place un système de réseau type client/serveur.

Bien qu’il soit difficile qu’un travail scientifique soit exhaustif, nous
pensons avoir mis à la disposition de la SOCODA COOP-CA un outil qui pourra
assouplir les tâches, accroitre la productivité et remédier aux difficultés
constatées dans le système existant.

Pour les chercheurs, étudiants et autres, ce présent travail pourra

leur servir dans leurs recherches, études en ce qui concerne la mise en place
des applications informatiques appliquées à la gestion dans un système
distribué. Enfin, aucune œuvre humaine n’est infaillible, nous restons ouverts à
toutes préoccupations, remarques ou suggestions qui nous seront certes
bénéfiques.
 100

BIBLIOGRAPHIE
I. Ouvrages

1. Bruno WARIN, Méthode PERT, Paris, PUF, 2014.

2. Farouk H., Mira B., Techniques de gestion, Dalloz, Paris, 2016
3. G. Coulouris, J. Dollimore, T. Kindburg, G, Blair, « Distributed systems :
Concepts and Design », Addison-Wesley : United States of America,
2012
4. L. Junon, « Les systèmes distribués », ISEP, 2009

II. Notes de cours

5. C. Gavoille, « Algorithmes distribués », LaBRI : Université de Bordeaux,

inédit, Mars 2019
6. F. SINGHOFF, Cours d’Introduction aux systèmes repartis, Université de
Brest, 2015
7. Houda EL BOUHISSI, Cours SOA et Services web, Université
Abderrahmane Mira de Bejaia, inédit, 2020-2021
8. KANYINDA, API et Web service, Stage académique, ISS-KIN, 2022, inédit
9. MBIKAYI, Cours de Méthode de Conduite de Projet Informatique, L2
Conception, ISS-KIN, inédit, 2021-2022
10. OSOKONDA, Cours des méthodes de Recherche en Sciences
Sociales(MRS), L1 INFO, ISS/KIN, 2020-2021
11. Ousmane THIARE, Principes et mécanismes de base de système
distribué, Université Saint-Louis, Sénégal, 2020

III. Articles, Mémoires et Thèse

12. Article, Service Web (SOAP), Cours : NFE107 Urbanisation & Architecture
des Systèmes d’Information, 2008-2009.
13. BALOLA NDUSHA Moïse, Conception et développement d'une
application pour la gestion des artistes et de leurs œuvres « cas de la
division provinciale de la culture et des arts », UCB-Bukavu, 2013-2014,
inédit
14. BOUKHEDOUMA Saida, « Adaptation et Restructuration de Modèles de
Processus Workflow dans un Contexte Inter-Organisationnel », Thèse de
Doctorat, Université de Nantes, 2015, inédit
15. EYEME LENDU Ernest, Mise en place d'un LAN avec connexion internet
au sein d'une entreprise privée cas de SYNERGY GROUP, ISIPA-Kinshasa,
2013-2014, inédit

IV. Webographie

16. fr.acervolima.com, consulté le 10 juillet 2022 à 15h12’

 101

17. https://web.maths.unsw.edu.au, consulté le 07 août 2022 à 13h01’

18. https://www.google.com,
19. https://www.redhat.com, consulté le 07 août 2022 à 10h05’
20. https://www.tifawt.com,
21. www.lebigdata.fr, consulté le 08 août 2022 à 18h30’
22. www.mulesoft.com, le 07 août 2022 à 15h10’
23. www.wikipedia.com, consulté le 07 août 2022 à 09h00’
 102

TABLE DES MATIÈRES

EPIGRAPHE ............................................................................................................................. I
IN MEMORIAM ...................................................................................................................... II
DEDICACES .......................................................................................................................... III
REMERCIEMENTS ................................................................................................................. IV
LISTE DES SIGLES ET ACRONYMES........................................................................................ V
LISTE DES FIGURES ............................................................................................................... VI
LISTE DES TABLEAUX ........................................................................................................... VII
INTRODUCTION .................................................................................................................... 1
1.GENERALITES..................................................................................................................... 1
2.PROBLEMATIQUE ............................................................................................................... 1
3.HYPOTHESES DU SUJET ........................................................................................................ 2
4.CHOIX ET INTERET DU SUJET.................................................................................................. 3
4.1.Choix du sujet ........................................................................................................ 3
4.2.Intérêt du sujet ....................................................................................................... 3
5.DELIMITATION DU TRAVAIL. .................................................................................................. 3
6.METHODES ET TECHNIQUES UTILISEES ..................................................................................... 3
6.1.Méthodes utilisées ................................................................................................. 3
6.2.Techniques utilisées ............................................................................................... 4
7.ETAT DE LA QUESTION ......................................................................................................... 4
8.DIFFICULTES RENCONTREES .................................................................................................. 5
9.SUBDIVISION DU TRAVAIL..................................................................................................... 6
PREMIERE PARTIE : NOTION FONDAMENTALE ..................................................................... 7
CHAPITRE I : SYSTEME DISTRIBUE .......................................................................................... 8
I.1. INTRODUCTION SUR LE SYSTEME DISTRIBUE ........................................................................... 8
I.2. DEFINITION DE CONCEPTS. ............................................................................................... 8
a. Système distribué ................................................................................................... 8
b. Système reparti ...................................................................................................... 9
c. Système centralisé................................................................................................. 9
I.3. TYPE DES SYSTEMES DISTRIBUES ........................................................................................... 9
I.3.1. Système embarqué distribué ............................................................................. 9
I.3.2. Système d'information distribué ......................................................................... 9
I.3.3. Systèmes informatiques distribués ....................................................................10
I.4. INTERETS ET INCONVENIENTS DES SYSTEMES DISTRIBUES ..........................................................10
a. Intérêts ...................................................................................................................10
b. Inconvénients .......................................................................................................11
I.5. CARACTERISTIQUES DES SYSTEMES DISTRIBUES .....................................................................12
I.5.1. Interopérabilité...................................................................................................12
I.5.2. Partage des ressources .....................................................................................12
I.5.3. Ouverture ...........................................................................................................12
I.5.4. Expansibilité ........................................................................................................12
I.5.5. Performance ......................................................................................................13
I.5.6. Transparence .....................................................................................................13
 103

I.5.7. Sécurité ..............................................................................................................13

I.6. MODÈLE D’ARCHITECTURE D’UN SYSTÈME DISTRIBUÉ ............................................................13
1. Client-serveur ........................................................................................................13
2. Peer-to-Peer ..........................................................................................................17
CHAPITRE II : ARCHITECTURES ORIENTEES SERVICES......................................................... 19
II.1. DEFINITION ...................................................................................................................19
a. Architecture ..........................................................................................................19
b. Service ...................................................................................................................19
c. Architecture orientée service ..............................................................................20
II.2. PRINCIPES GENERAUX D’UNE ARCHITECTURE ORIENTEE SERVICES ..........................................20
II.3. AVANTAGES D’UNE ARCHITECTURE ORIENTEE SERVICE ........................................................21
II.4. LES CONCEPTS DE BASE ..................................................................................................21
II.4.1. SOA et service ...................................................................................................21
II.4.2. Web service .......................................................................................................22
II.4.3. Approche Orientée Objet................................................................................24
II.4.4. Les composants ................................................................................................24
II.5. DEFINITION DES ROLES ....................................................................................................25
II.6. LES APPORTS DU SOA ....................................................................................................26
II.6.1. Les apports métiers ...........................................................................................26
II.6.2. Les apports techniques ....................................................................................26
II.7. PRESENTATION GENERALE DU PROTOCOLE SOAP..............................................................26
II.7.1. Présentation et fonctionnement de SOAP .....................................................27
II.7.2. Le protocole WSDL............................................................................................28
II.7.3. Le protocole UDDI.............................................................................................30
II.7.4. Différence entre IIOP et SOAP .........................................................................31
II.7.5. Protocoles utilisés par SOAP .............................................................................32
II.7.6. Problèmes posés par SOAP ..............................................................................32
DEUXIEME PARTIE : ETUDE PREALABLE ET CADRAGE DU PROJET ...................................... 34
CHAPITRE I : CADRAGE DU PROJET ................................................................................... 35
SECTION I : ÉVALUATION DU PROJET .......................................................................................35
1.1. Introduction..........................................................................................................35
1.2. Cycle de vie d’un projet .....................................................................................35
SECTION II : PLANNING PRÉVISIONNEL DE RÉALISATION DU PROJET ..............................................37
2.1. Méthode d’ordonnancement ...........................................................................37
2.2. Présentation de la méthode PERT ......................................................................38
2.3. Matrice d’antériorité ...........................................................................................42
2.4. Délai de réalisation du projet .............................................................................43
2.5. Élaboration des marges libres et totales ...........................................................44
2.6. Tableau synthétique de la réalisation du projet ...............................................47
CHAPITRE II : ANALYSE ET SPECIFICATION DES BESOINS .................................................. 48
SECTION 1 : PRÉSENTATION DE L’ENTREPRISE ............................................................................48
1.1. APERÇU HISTORIQUE .....................................................................................................48
1.2. SITUATION GÉOGRAPHIQUE ............................................................................................50
 104

1.3. OBJET ET MISSIONS DE LA SOCIÉTÉ ...................................................................................50

1.4. ORGANISATION STRUCTURO-FONCTIONNELLE ...................................................................51
1.4.1. Organigramme général...................................................................................52
1.4.2. Organigramme spécifique ..............................................................................53
1.4.3. Description de poste ........................................................................................53
SECTION 2 : ANALYSE DE L’EXISTANT ......................................................................................55
2.1. ÉTUDE DES MOYENS UTILISÉS ............................................................................................55
2.1.1. Moyens humains ...............................................................................................55
2.1.2. Moyens matériels ..............................................................................................55
2.1.3 Moyens financiers ..............................................................................................55
2.2. ÉTUDES DES DOCUMENTS................................................................................................56
1. Lettre de demande d’adhésion .........................................................................56
2. Adhésion aux Statuts et acte d’apports ............................................................56
3. Contrat de cession entre créateur et SOCODA COOP-CA .............................57
4. Relevés des œuvres déclarées ...........................................................................58
2.3. DIAGNOSTIC DE L’EXISTANT ............................................................................................58
2.3.1. Critique des moyens humains .........................................................................59
2.3.2. Critique des moyens matériels ........................................................................59
2.3.3. Critique des moyens financiers .......................................................................59
2.3.4. Critique de l’organisation ................................................................................59
2.3.5. Critique des documents ..................................................................................59
2.3.6. Critique de la circulation des informations ....................................................59
SECTION 3 : PROPOSITION DES SOLUTIONS ..............................................................................59
3.1. Solution manuelle améliorée ..............................................................................60
3.2. Solution informatique ..........................................................................................60
3.3. Choix de la meilleure solution ............................................................................61
TROISIEME PARTIE : NOTION OPERATIONNELLE ................................................................ 62
CHAPITRE I : CONCEPTION ET MODELISATION DU NOUVEAU SYSTEME .......................... 63
I.1. CONTEXTE.....................................................................................................................63
I.2. SPÉCIFICATION INITIALE DU SYSTÈME ..................................................................................64
1. A qui l’application est – elle destinée ? .............................................................64
2. Quels problèmes l’application résoudra – t – elle ? ..........................................65
3. Où l’application sera – t – elle utilisée ? .............................................................65
4. Pourquoi l’application est – elle attendue ? ......................................................65
5. Comment l’application fonctionnera – t – elle ? ..............................................65
I.3. CAHIER DES CHARGES ....................................................................................................65
I.4. DETERMINATION DE LA TECHNOLOGIE. ..............................................................................66
I.5. DEFINITION DE L’ARCHITECTURE DU SYSTEME.......................................................................67
I.6. ANALYSE DE DOMAINE ...................................................................................................67
a. Diagramme de cas d'utilisation ..........................................................................67
b. Diagramme de classes ........................................................................................71
c. Diagramme de séquence ...................................................................................72
d. Diagramme d'activités ........................................................................................73
e. Diagramme de déploiement ..............................................................................74
 105

CHAPITRE II : IMPLEMENTATION DU NOUVEAU SYSTEME .................................................. 75

II.1. IMPLANTATION D'UNE BASE DE DONNEES ..........................................................................75
II.1.1. Choix de Système de Gestion de Base de Données .....................................75
II.1.2. Création de la base de données et des tables .............................................75
II.1.4. Relation entre les tables ...................................................................................77
II.2. PROGRAMMATION ........................................................................................................79
II.2.1. Présentation des différents outils de développement ...................................79
II.2.2. Implémentation de service ..............................................................................79
II.2.3. Interface Homme-machine et quelques codes sources ..............................90
CONCLUSION..................................................................................................................... 99
BIBLIOGRAPHIE .................................................................................................................100
TABLE DES MATIÈRES .........................................................................................................102